React Compiler élimine useMemo et useCallback dans React 19. Voici comment l'activer dans Next.js App Router, ses limites et les pièges à éviter en 2026.
Le React Compiler mémorise automatiquement vos composants et vos valeurs, sans que vous ayez à écrire un seul useMemo ou useCallback. Concrètement : le compilateur analyse votre code à la build et insère lui-même la mémorisation là où elle a du sens, ce qui devrait réduire drastiquement le nombre de re-renders inutiles dans une app React 19.
Mais est-ce que ça marche vraiment dans une app Next.js App Router en production, aujourd'hui ? On a creusé la question, testé sur un projet réel, et voici ce qu'on en retient, activation, limites, et cas où il vaut mieux ne pas y toucher.
Qu'est-ce que le react compiler, concrètement
Le React Compiler est un outil qui tourne au moment du build et transforme votre code source pour y injecter automatiquement de la mémorisation. Pas de nouvelle API à apprendre, pas de hook supplémentaire. Il lit vos composants tels que vous les écrivez aujourd'hui, avec des props, des states, des dépendances, et déduit lui-même où un useMemo ou un useCallback manuel aurait été nécessaire.
Avant le compilateur, un développeur devait deviner quels calculs coûteux méritaient d'être mémorisés, et lister à la main les dépendances de chaque hook. Deviner, c'est le mot juste. On a tous déjà oublié une dépendance dans un tableau useCallback et debuggé un state périmé pendant deux heures.
Le compilateur retire cette responsabilité humaine. Il applique une règle simple : si un composant respecte les règles de React (pas de mutation directe des props, pas d'effets de bord dans le rendu), il peut être analysé statiquement et mémorisé automatiquement.
Ce qui change vraiment pour votre équipe : le code devient plus court, plus lisible, et surtout plus difficile à casser par erreur. Une observation qui surprend souvent les équipes qui migrent : retirer manuellement tous les useMemo existants améliore parfois les performances, parce que le compilateur fait un travail plus fin que ce qu'un humain pressé aurait écrit à la main.
Ce que le compilateur ne fait pas
Il ne remplace pas la logique métier. Il ne devine pas non plus vos intentions business, si votre composant a un bug de logique, le compilateur ne le corrigera jamais. Il optimise le rendu, point.
Comment l'activer dans une app next.js app router
L'activation se fait au niveau du build, via un plugin Babel dédié configuré dans votre projet. Sur un projet Next.js App Router existant, la démarche typique ressemble à ça :
- Installer le plugin du compilateur React comme dépendance de développement.
- L'activer dans la configuration Next.js (
next.config.js), en général via une option expérimentale tant que la fonctionnalité continue de mûrir. - Lancer un build complet et comparer le bundle avant/après, le compilateur ajoute du code de mémorisation, le poids du bundle peut légèrement augmenter.
- Tester en profondeur les composants avec state complexe : formulaires multi-étapes, listes filtrables, tout ce qui dépend de re-renders précis.
- Retirer progressivement les
useMemo/useCallbackmanuels existants, pas tous d'un coup.
Le point 5 est celui que tout le monde rate. On a envie de nettoyer le code d'un coup après activation. Mauvaise idée. Le compilateur coexiste très bien avec du code déjà mémorisé manuellement, donc rien n'oblige à tout réécrire le jour de l'activation.
Les pièges qu'on a rencontrés en testant le compilateur
Ici, il faut être honnête : ça ne se passe pas magiquement bien partout.
Premier piège : les composants qui violent discrètement les règles de React, mutation directe d'un objet passé en props, effet de bord planqué dans un rendu conditionnel, ne sont tout simplement pas optimisés par le compilateur. Pire, ils peuvent produire des comportements incohérents entre le mode dev et le mode compilé, ce qui rend le debug plus difficile qu'avant.
Deuxième piège : les librairies tierces. Si votre app dépend de composants externes qui ne respectent pas ces règles, le compilateur les laisse simplement de côté. Vous n'avez donc pas un gain uniforme sur toute l'app, mais un gain concentré sur votre propre code.
Troisième piège, plus subtil : sur un projet où les développeurs avaient déjà fait un travail rigoureux de mémorisation manuelle, le gain de performance mesuré était faible. Le compilateur brille surtout là où l'équipe n'avait pas le temps ou la discipline de mémoriser correctement, ce qui est le cas de la majorité des projets, soyons honnêtes.
Cette approche a une limite claire : elle ne fonctionne pas bien si votre codebase contient beaucoup de composants de classe hérités, ou du code qui manipule le DOM directement en dehors du cycle de rendu React. Dans ce cas, migrer vers des composants fonctionnels standards avant d'activer le compilateur reste un préalable obligatoire.
Tableau comparatif : mémorisation manuelle vs react compiler
| Critère | Mémorisation manuelle (useMemo/useCallback) | React Compiler |
|---|---|---|
| Effort développeur | Élevé, chaque cas à identifier et coder | Faible, automatique à la build |
| Risque d'erreur | Dépendances oubliées, bugs de state périmé | Réduit, mais dépend du respect des règles React |
| Lisibilité du code | Alourdie par des hooks partout | Code source plus proche du rendu naturel |
| Couverture | Ciblée là où le dev a pensé à l'ajouter | Uniforme sur tout composant conforme |
| Compatibilité librairies tierces | Non concerné | Ne s'applique pas aux composants externes non conformes |
| Maturité en 2026 | Standard depuis des années | Disponible mais encore marqué comme expérimental sur certaines configs |
Conclusion
Trois choses à retenir avant d'activer le React Compiler sur votre prochain projet Next.js. D'abord, il ne remplace pas la rigueur : un code qui viole les règles de React reste un code que le compilateur ne peut pas sauver. Ensuite, le gain réel dépend de l'état actuel de votre codebase, plus votre mémorisation manuelle était bâclée, plus le gain sera visible. Enfin, la migration doit être progressive : activer, tester, puis nettoyer le code existant, jamais l'inverse.
Si votre équipe travaille déjà sur une migration Next.js plus large, on en parlait justement dans notre article sur la fin de vie de Next.js 15 et le plan de migration vers la version 16, le compilateur fait partie des chantiers à intégrer dans cette feuille de route plutôt que de le traiter comme un projet séparé. Et si le sujet du build et du compilateur en général vous intéresse, on avait aussi creusé ce que change le compilateur TypeScript natif en Go pour vos temps de build.
Besoin d'un audit avant de migrer votre app vers le React Compiler ? Contactez fstck.co pour qu'on regarde ensemble si votre codebase est prête.
Questions fréquentes
Le react compiler fonctionne-t-il avec les composants de classe react ?
Non. Le compilateur analyse uniquement les composants fonctionnels et les hooks. Une base de code avec beaucoup de composants de classe hérités doit d'abord être migrée vers des composants fonctionnels avant de pouvoir bénéficier du compilateur.
Faut-il retirer tous les usememo et usecallback existants après avoir activé le compilateur ?
Non, et c'est même déconseillé de le faire d'un coup. Le compilateur coexiste sans problème avec du code déjà mémorisé manuellement. Mieux vaut activer, mesurer, puis nettoyer progressivement composant par composant.
Le react compiler ralentit-il le temps de build sur un gros projet next.js ?
Oui, l'analyse statique ajoute un coût au build, généralement modéré sur des projets de taille moyenne. Sur de très gros monorepos, ce coût mérite d'être mesuré avant la mise en production, en comparant les temps de build avant/après sur votre CI.
Peut-on utiliser le react compiler avec next.js pages router, ou seulement app router ?
Le compilateur agit au niveau du build Babel, indépendamment du routeur utilisé. Il fonctionne donc en théorie avec Pages Router aussi, mais l'essentiel des retours d'expérience et de la documentation se concentre sur des projets App Router en 2026.
Comment savoir si mon code respecte les règles de react nécessaires au compilateur ?
Un plugin ESLint dédié permet de détecter les violations avant même d'activer le compilateur en build. C'est la première étape recommandée : lancer le linter sur toute la codebase, corriger les violations signalées, puis seulement ensuite activer le compilateur.
