React Compiler en 2026 : mémoïsation automatique et questions d'entretien

Le React Compiler a atteint sa version stable v1.0 en octobre 2025, transformant radicalement l'approche de l'optimisation des performances dans les applications React. Pour les entretiens techniques en 2026, la compréhension du fonctionnement interne du compilateur, de sa stratégie de mémoïsation et des cas où l'optimisation manuelle reste nécessaire constitue un avantage décisif.

Qu'est-ce que le React Compiler et comment optimise-t-il le code ?

Le React Compiler est un compilateur d'optimisation qui s'exécute au moment du build. Il analyse les composants et hooks React, puis insère de la mémoïsation granulaire là où cela s'avère bénéfique. Contrairement à la mémoïsation manuelle avec useMemo ou useCallback, le compilateur peut mémoïser de manière conditionnelle et à un niveau de granularité plus fin que ce qu'un développeur maintiendrait raisonnablement à la main.

Le compilateur fonctionne comme un plugin Babel (avec un support SWC croissant à partir de Next.js 15.3.1+). Il traite chaque composant de manière indépendante, transformant l'AST Babel en une représentation intermédiaire de haut niveau (HIR) personnalisée avant d'exécuter plusieurs passes d'optimisation.

Les résultats en production chez Meta confirment l'impact : le Quest Store a constaté jusqu'à 12 % d'accélération du chargement initial et plus de 2,5x d'amélioration de la vitesse d'interaction. Sanity Studio a rapporté une réduction de 20 à 30 % du temps de rendu sur 1 231 composants compilés.

Structure de réponse en entretien : Définir le compilateur, expliquer qu'il opère au moment du build (pas au runtime), mentionner le pipeline HIR et citer des métriques concrètes.

Le pipeline de compilation : du code source au code optimisé

Cette question évalue la compréhension en profondeur. Le pipeline du React Compiler comporte sept phases distinctes :

1. Code source vers AST — Babel analyse le JavaScript/TypeScript en un arbre syntaxique abstrait (AST)
2. AST vers HIR — Le compilateur transforme l'AST en sa représentation intermédiaire de haut niveau, conçue spécifiquement pour le modèle de composants React
3. Transformation SSA — L'assignation statique unique garantit que chaque variable n'est assignée qu'une seule fois, permettant un suivi précis du flux de données
4. Inférence de type et analyse des effets — Le compilateur classifie les opérations selon leurs effets : lecture, stockage, capture, mutation, gel
5. Analyse réactive — Chaque expression est classée comme statique (constantes, imports) ou réactive (dérivée des props, du state, du contexte)
6. Découverte des scopes — Le compilateur identifie les scopes de mémoïsation indépendants pouvant être mis en cache et invalidés séparément
7. Génération de code — Le JavaScript optimisé avec mémoïsation automatique est émis

// Before compilation
function UserProfile({ user, theme }) {
  const fullName = user.firstName + ' ' + user.lastName;
  const style = { color: theme.primary, fontSize: 16 };
  return <div style={style}>{fullName}</div>;
}

// After compilation (simplified representation)
function UserProfile({ user, theme }) {
  const $ = useMemoCache(4);
  let fullName;
  if ($[0] !== user.firstName || $[1] !== user.lastName) {
    fullName = user.firstName + ' ' + user.lastName;
    $[0] = user.firstName;
    $[1] = user.lastName;
    $[2] = fullName;
  } else {
    fullName = $[2];
  }
  // style and JSX similarly memoized...
}

L'élément essentiel pour les entretiens : le compilateur mémoïse au niveau des valeurs, pas au niveau du composant. Chaque valeur calculée obtient son propre emplacement en cache, invalidé uniquement lorsque ses dépendances spécifiques changent. Cette granularité dépasse ce que useMemo permet d'atteindre en pratique.

Les règles de React : ce que le compilateur suppose

Le React Compiler effectue une analyse statique en partant du principe que les composants respectent les règles de React. Lorsque le code enfreint ces règles, le compilateur ignore l'optimisation de ce composant — silencieusement. Ce sujet revient fréquemment en entretien.

Les trois règles fondamentales :

• Les composants et les hooks doivent être purs — Avec les mêmes entrées, le rendu doit produire la même sortie. Aucune lecture ni écriture d'état mutable externe pendant le rendu.
• Les hooks doivent respecter les conventions d'appel — Les hooks ne peuvent pas être appelés conditionnellement, dans des boucles ou dans des fonctions imbriquées.
• Les props et le state sont immuables au sein d'un rendu — Ne jamais muter les props ou le state directement ; toujours utiliser les fonctions setter.

// Rule violation: mutating during render
function BadCounter({ items }) {
  // The compiler will skip this component
  items.sort(); // Mutates the prop array!
  return <ul>{items.map(i => <li key={i}>{i}</li>)}</ul>;
}

// Correct: create a new sorted array
function GoodCounter({ items }) {
  const sorted = [...items].sort();
  return <ul>{sorted.map(i => <li key={i}>{i}</li>)}</ul>;
}

Intégration ESLint : détecter les violations avant le build

Le package autonome eslint-plugin-react-compiler est obsolète depuis fin 2025. Toutes les règles de lint liées au compilateur sont désormais intégrées dans eslint-plugin-react-hooks@latest.

Configuration avec ESLint flat config :

import reactHooks from 'eslint-plugin-react-hooks';
import { defineConfig } from 'eslint/config';

export default defineConfig([
  reactHooks.configs.flat.recommended,
]);

Les règles alimentées par le compilateur détectent trois schémas critiques :

• set-state-in-render — Appel de setState pendant le rendu, provoquant des boucles infinies
• set-state-in-effect — Calculs coûteux dans les effets déclenchant des re-rendus en cascade
• refs — Accès à .current sur les refs pendant le rendu (les refs sont des échappatoires mutables, pas sûres pour le rendu)

Pour les entretiens, la stratégie d'adoption recommandée : activer d'abord les règles ESLint, corriger toutes les violations, puis activer le compilateur. Cette approche progressive minimise les surprises.

Quand l'optimisation manuelle reste nécessaire

Le compilateur n'élimine pas tout le travail de performance. Plusieurs scénarios requièrent encore une intervention manuelle :

1. Abonnements aux stores externes

Le compilateur ne suit que le state React, les props et le contexte. Les stores externes (Redux, Zustand, MobX) nécessitent useSyncExternalStore ou le mécanisme de sélecteur propre au store pour optimiser les rendus.

2. Calculs coûteux avec de grands ensembles de données

Bien que le compilateur mémoïse les valeurs de retour, il ne mesure pas le coût d'exécution. Une fonction filtrant 100 000 éléments s'exécute toujours lorsque ses dépendances changent. Pour les opérations véritablement coûteuses, useMemo avec des dépendances explicites reste valide — le compilateur ne dupliquera pas la mémoïsation.

3. Logique impérative basée sur les refs

Les refs sont intentionnellement exclues du modèle réactif du compilateur. Les animations, le dessin sur canvas et l'intégration de bibliothèques DOM tierces nécessitent toujours un contrôle manuel.

4. Mémoïsation inter-composants

Le compilateur mémoïse au sein d'un seul composant ou hook. Le partage de valeurs calculées entre composants nécessite toujours la remontée d'état, le contexte ou des couches de cache externes.

// The compiler handles this automatically
function ProductCard({ product, currency }) {
  const formattedPrice = formatCurrency(product.price, currency);
  const discount = product.originalPrice - product.price;
  return (
    <div>
      <span>{formattedPrice}</span>
      {discount > 0 && <Badge>Save {discount}</Badge>}
    </div>
  );
}

// Manual optimization still needed: expensive external computation
function DataGrid({ rows }) {
  const processedRows = useMemo(
    () => rows.map(row => heavyTransform(row)), // O(n) with large n
    [rows]
  );
  return <VirtualList items={processedRows} />;
}

Comment activer le React Compiler dans différents frameworks

Les recruteurs testent souvent les connaissances pratiques de configuration :

Next.js (15.3.1+) : Support natif SWC. Activation dans next.config.js :

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};
export default nextConfig;

Vite 8 avec @vitejs/plugin-react v6 : Depuis la v6 qui a abandonné Babel interne pour oxc, le compilateur nécessite @rolldown/plugin-babel :

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';
import { reactCompilerPreset } from 'babel-plugin-react-compiler';

export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset] }),
  ],
});

Expo SDK 54+ : Activé par défaut. Aucune configuration nécessaire.

React Compiler vs mémoïsation manuelle : comparaison pour entretien

| Aspect | React Compiler | Manuel (useMemo/useCallback) | |--------|---------------|----------------------------------| | Granularité | Au niveau des valeurs, par expression | Au niveau des blocs, défini par le développeur | | Mémoïsation conditionnelle | Supportée | Impossible | | Coût de maintenance | Nul — automatique | Élevé — tableaux de dépendances, composants wrapper | | Inter-composants | Scope d'un seul composant | Scope d'un seul composant | | Stores externes | Non suivis | Non suivis (utiliser useSyncExternalStore) | | Composants de classe | Non supportés | N/A (utiliser React.memo) | | Prérequis de build | Plugin Babel ou SWC | Aucun | | Plafond de performance | 20-60 % de re-rendus en moins (typique) | Dépend des compétences du développeur |

Le résumé prêt pour l'entretien : le compilateur automatise 80 à 90 % de la mémoïsation que les développeurs géraient auparavant manuellement, avec une meilleure granularité et un coût de maintenance nul. Les 10 à 20 % restants concernent les intégrations externes, les calculs véritablement coûteux et le travail impératif sur le DOM.

Questions fréquentes en entretien avec réponses concises

Q : Le React Compiler fonctionne-t-il au moment du build ou du runtime ? Au moment du build. Le compilateur est un plugin Babel qui transforme le code source pendant la compilation. Le code optimisé utilise un helper runtime (useMemoCache) pour stocker les valeurs en cache, mais toute l'analyse se fait avant le déploiement.

Q : Faut-il supprimer les appels existants à useMemo et useCallback ? L'équipe React recommande de conserver la mémoïsation manuelle existante. La supprimer peut modifier le résultat de la compilation de manière subtile. Pour le nouveau code, il convient de s'appuyer sur le compilateur et de n'ajouter de la mémoïsation manuelle qu'après avoir identifié un besoin spécifique par le profilage.

Q : Que se passe-t-il lorsque le compilateur rencontre du code qu'il ne peut pas optimiser ? Il ignore silencieusement ce composant ou hook. L'application fonctionne toujours correctement — cette partie spécifique s'exécute simplement sans mémoïsation automatique. Les règles ESLint révèlent ces cas pendant le développement.

Q : Comment le compilateur interagit-il avec les Server Components ? Les Server Components s'exécutent sur le serveur et produisent une sortie sérialisée — ils ne sont pas re-rendus côté client. Le compilateur cible les composants client où les re-rendus sont la principale préoccupation de performance. Les deux optimisations sont complémentaires : les Server Components réduisent la taille du bundle, le compilateur réduit le coût des re-rendus côté client.

Q : Le compilateur peut-il optimiser les hooks personnalisés ? Oui. Le compilateur analyse à la fois les composants et les hooks. Un hook personnalisé qui calcule un état dérivé verra ses valeurs de retour mémoïsées automatiquement, bénéficiant à chaque composant qui l'utilise.

Conclusion

• Le React Compiler v1.0 est un outil de build qui insère de la mémoïsation granulaire au niveau des valeurs via un pipeline de compilation en sept phases (AST, HIR, SSA, inférence de type, analyse des effets, analyse réactive, génération de code)
• Le compilateur suppose que les composants respectent les règles de React ; les violations entraînent un opt-out silencieux, détectable par eslint-plugin-react-hooks avec le preset recommended
• L'optimisation manuelle reste nécessaire pour les abonnements aux stores externes, les calculs coûteux avec de grands jeux de données, la logique impérative basée sur les refs et le cache inter-composants
• La configuration pratique varie selon le framework : natif SWC dans Next.js, @rolldown/plugin-babel dans Vite 8, activé par défaut dans Expo SDK 54+
• En entretien, il est essentiel d'articuler ce que le compilateur automatise (80-90 % de la mémoïsation) et ce qu'il ne couvre pas (état externe, calculs coûteux inter-composants, composants de classe)
• Le parcours d'adoption recommandé est : règles ESLint d'abord, puis activation du compilateur — les recruteurs posent régulièrement la question de cette stratégie progressive