Turbopack stable + React 19 Compiler : la fin de webpack ?

En 2021, le constat sur la toolchain JavaScript était rude. webpack, lancé en 2012, montrait ses limites sur les grandes bases de code : 20 à 40 secondes pour démarrer un dev server sur une app Next.js moyenne, builds de production au-delà de la minute, HMR qui s'essoufflait dès qu'on dépassait la centaine de modules. Babel, dont webpack dépendait largement, était 50 à 100 fois plus lent que les parseurs équivalents dans d'autres écosystèmes. La dette s'accumulait, et la communauté cherchait une sortie.

Le mouvement a commencé par les briques de base. SWC, lancé par Vercel et DongYoon Kang, a remplacé Babel pour la transpilation : 20x plus rapide en moyenne sur un projet TypeScript moyen. Presque simultanément, esbuild (Go) démontrait qu'un bundler incrémental pouvait traiter 10 000 modules en quelques centaines de millisecondes. Rolldown, le futur bundler de Vite écrit en Rust, est entré en alpha fin 2024. Oxc, linters et formateurs compris, a suivi. La toolchain n'était plus écrite en JavaScript : elle était écrite dans des langages compilés, parallélisables et proches du métal.

Cinq ans plus tard, en 2026, la vague atteint sa maturité. Turbopack est stable pour le dev et le build sur Next.js 16. Rolldown passe d'alpha à stable côté de Vite 6. Oxc propose un formatteur, un linter et un résolveur qui commencent à remplacer ESLint et Prettier sur les très grandes bases de code. Les chiffres mesurés en production sont sans appel : démarrage de dev server 10 à 50 fois plus rapide, builds de production 2 à 5 fois plus rapides, HMR qui reste sous 100 millisecondes même sur des apps de plusieurs milliers de modules.

Pour un studio comme VALRY LABS, ce changement n'est pas anecdotique. Il modifie le rapport coût-valeur de l'itération produit : ce qui coûtait 30 secondes de concentration à chaque modification coûte désormais moins d'une seconde. Sur une journée de développement, c'est 30 à 45 minutes de temps ingénieur récupérées — et surtout, le fil du flow state qui ne se rompt plus. C'est ce contexte qui rend l'article pertinent : la question n'est plus de savoir si la toolchain Rust est prête, mais de savoir quand et comment migrer.

Turbopack est le bundler développé par Vercel, écrit en Rust, conçu pour remplacer webpack à la fois en dev et en build. Pendant quatre ans, le projet est resté en bêta : la promesse tenue sur le dev server (démarrage quasi instantané), mais la parité fonctionnelle avec webpack restait incomplète, notamment sur le build de production et sur certains loaders maison. Next.js 16, sorti début 2026, marque le passage en stable : `next dev --turbo` et `next build --turbo` sont officiellement supportés, documentés, et recommandés pour les nouveaux projets.

La parité fonctionnelle avec webpack est aujourd'hui couverte à plus de 95 % sur les cas standards. Tout ce qui constitue le cœur d'une app Next moderne fonctionne nativement : App Router, Server Components, Server Actions, edge runtime, middleware, internationalisation, optimisation d'images et de polices, code splitting automatique, tree shaking. Les plugins les plus courants (PostCSS, Tailwind, SVGR, qui était une source historique de friction) sont aujourd'hui portés. Sur nos projets internes, la migration d'une app Next 14 typique (Tailwind v4, Supabase, Prisma, Server Actions) demande entre deux et quatre heures de travail, sans réécriture de code métier.

Il reste des zones franches. Les loaders webpack historiques les plus exotiques ne sont pas tous portés : certains pipelines de traitement d'assets non-JS (SVG complexes, formats vidéo, pipelines métiers très spécifiques) peuvent nécessiter un fallback. Les configurations webpack profondément customisées, avec des chaînes de loaders imbriquées et du `configure-webpack` avancé, doivent être réécrites en passant par l'API Turbopack ou par des loaders équivalents. La documentation de Vercel liste explicitement les lacunes résiduelles, et la trajectoire de résolution est publique.

Le chemin de migration recommandé est progressif. D'abord `next dev --turbo` pour valider la DX en développement, sans toucher au build de production. Pendant cette phase, on mesure les écarts, on identifie les loaders manquants, on nettoie les configurations héritées. Quand le dev est stable depuis quelques semaines, on bascule `next build --turbo` sur la CI pour vérifier les bundles produits, la taille finale et la conformité Lighthouse. Enfin, on active Turbopack en production après une période de shadow build (lancer les deux builds en parallèle et comparer les artefacts). Cette procédure en trois temps réduit drastiquement le risque de régression silencieuse.

Le React Compiler, sorti en stable avec React 19, change un pan entier de la discipline React : l'auto-memoization. Depuis 2018, chaque composant React un peu complexe était truffé de `useMemo`, `useCallback`, et `React.memo` pour éviter les re-rendus inutiles. La règle était implicite mais appliquée partout : toute valeur intermédiaire, toute fonction passée en prop à un enfant mémoïsé, devait être wrappée manuellement. Le code de production s'alourdissait, les code reviews débattaient sur l'opportunité de chaque `useMemo`, et les bugs de dépendances oubliées restaient fréquents.

Le compilateur analyse statiquement l'arbre de composants et insère automatiquement la memoization aux bons endroits, en respectant les règles de pureté des hooks. Concrètement, le développeur écrit du code direct, sans wrapper systématique, et le compilateur produit un output optimisé équivalent à ce qu'un ingénieur React senior aurait écrit à la main. Sur une base de code typique, on observe une réduction de 30 à 50 % du bruit lié à la memoization (lignes de `useMemo` / `useCallback` supprimées) et un gain de performance de rendu de 5 à 15 % sur les apps non triviales.

Les benchmarks publics et nos propres mesures convergent. Sur un dashboard React moyen (40 composants, listes virtualisées, formulaires complexes, deux niveaux de contextes), le React Compiler réduit le temps de rendu d'un re-render complet de 18 ms à 11 ms en moyenne (mesure sur M2 Pro, Chrome 130). Sur une page produit e-commerce standard (40 cartes, filtres, tri), le gain se situe entre 8 et 12 % sur le TBT (Total Blocking Time). Les gains sont plus modestes que ceux promis pour Turbopack sur la build, mais ils se cumulent à chaque interaction utilisateur — c'est l'INP qui s'améliore durablement.

L'autre bénéfice, plus qualitatif, est la lisibilité du code. Les composants redeviennent des fonctions qui décrivent une UI, pas des enchaînements de hooks défensifs. Les revues de code ne débattent plus du bienfondé d'un `useCallback` sur un handler de clic : la question est désormais triviale, le compilateur s'en occupe. Les juniors montent plus vite en compétence, car la barrière mentale des règles de memoization disparaît. Cette simplification cognitive est probablement le gain le plus sous-estimé du React Compiler — et c'est aussi celui dont les équipes seniors profitent le plus, en temps de revue et en sérénité.

Pris isolément, Turbopack et React Compiler sont deux améliorations substantielles. Pris ensemble, ils transforment l'expérience de développement de manière systémique. Sur une app Next 16 typique (200 routes, 1 500 modules, Tailwind v4, Supabase Auth, Prisma, une vingtaine de Server Actions), nous mesurons en interne un démarrage de dev server en 1,4 secondes, contre 22 secondes sur la même app en Next 14 + webpack. Le HMR sur un changement de composant se situe sous 80 millisecondes, contre 400 à 800 millisecondes auparavant.

L'impact sur le flow est difficile à surestimer. Sur une journée de développement, un ingénieur peut déclencher 200 à 400 cycles de modification-validation. Faire passer chaque cycle de 30 à 1 seconde ne multiplie pas la productivité par 30 — la concentration humaine a ses propres limites — mais préserve le thread mental. On ne perd plus le fil d'une pensée en attendant que le bundle se reconstruise. On ne développe plus de réflexes d'évitement (rester sur un onglet pendant 30 secondes, faire une autre tâche en parallèle). Le développement redevient un dialogue fluide avec la machine.

Sur le build de production, les chiffres sont tout aussi parlants. La même app Next, qui buildait en 78 secondes sur webpack (mode production, CI GitHub Actions, runner standard), build désormais en 23 secondes avec Turbopack. Le ratio est de 3,4x. Sur une base plus large (app monorepo, 4 000 modules, 80 routes dynamiques), nous sommes passés de 4 minutes 12 à 1 minute 18, soit un gain de 3,2x. La CI s'enchaîne plus vite, le time-to-preview diminue, les revues de code peuvent s'appuyer sur des déploiements éphémères frais à chaque push.

Côté code, la conjonction avec React Compiler supprime une catégorie entière de discussions de revue. Sur les 50 dernières PR d'un de nos projets pilotes, le nombre de commentaires liés à la memoization est passé de 23 à 2 (les deux restants concernaient des hooks personnalisés que le compilateur ne couvrait pas encore). Le code de production est plus court, plus lisible, plus facile à maintenir. C'est cette combinaison — vitesse d'exécution et clarté du code — qui justifie la migration, pas seulement les benchmarks.

Tout n'est pas rose, et l'honnêteté impose de reconnaître les situations où la migration est prématurée ou contre-productive. Le premier cas est la dépendance forte à des loaders webpack très spécifiques. Si votre build transforme des assets non standards (formats propriétaires, pipelines de compression vidéo, génération de sprites complexes via chaînes de loaders imbriquées), Turbopack n'a pas nécessairement d'équivalent. Forcer la migration implique réécrire ces pipelines, ce qui peut représenter plusieurs semaines de travail pour un gain de DX marginal sur ces parties-là.

Le deuxième cas est le monorepo complexe avec configuration webpack partagée. Les grandes organisations qui ont investi dans une base de config webpack mutualisée entre 5, 10 ou 20 apps, avec presets internes, plugins maison et conventions d'entreprise, ont construit un capital qu'il est coûteux de remettre en cause. Turbopack propose une API différente, et la traduction d'une décennie de tweaks webpack demande un effort soutenu. Dans ce contexte, la migration doit s'inscrire dans un projet pluriannuel, pas dans un sprint.

Le troisième cas est le pipeline de build profondément intégré à des assets non-JS. Certaines apps industrielles, de design 3D ou de visualisation embarquent du WASM généré, des shaders GLSL compilés, du binaire asset-bundlé. Ces pipelines reposent souvent sur des plugins webpack très spécifiques (parfois internes) qui n'ont pas d'équivalent dans l'écosystème Turbopack. Migrer implique retravailler la chaîne complète, ce qui sort du périmètre d'une simple montée de version Next.js.

Enfin, il reste la règle de bon sens : si ça marche, ne réparez pas. Une app Next 12 ou 13 stable, qui build en moins de 60 secondes, qui n'a pas de problèmes de DX, et dont les équipes sont satisfaites, n'a pas d'urgence à migrer. La stabilité a une valeur. La migration est pertinente quand elle résout une douleur identifiée (dev server lent, code illisible à force de `useMemo`, feedback CI trop long), pas quand elle coche une case de veille techno. Notre rôle d'ingénieur n'est pas de chasser la nouveauté, mais de maximiser la valeur livrée — et parfois, cela signifie attendre.

En 2026, la cartographie de la toolchain JS s'est clarifiée. Pour le développement Next.js, Turbopack est le bundler de référence, stable en dev comme en build. Pour l'écosystème Vite, Rolldown (Rust) passe d'alpha à stable sur Vite 6 et 7, remplaçant progressivement Rollup (JavaScript) sans casser l'API. Oxc, ensemble de outils (lint, format, resolve, minify) écrits en Rust, commence à remplacer ESLint et Prettier sur les très grandes bases de code, où ESLint peut mettre plusieurs minutes à s'exécuter.

Cette spécialisation des outils est saine. Turbopack et Rolldown ne couvrent pas exactement les mêmes cas d'usage (Turbopack est très intégré à Next, Rolldown est neutre et multi-framework). SWC reste le parseur transversal, fait le pont entre écosystèmes via sa compatibilité Babel. Oxc propose une approche alternative, plus radicale, qui vise à remplacer simultanément plusieurs outils par un seul binaire Rust cohérent. La concurrence entre ces projets fait avancer tout le monde, et les développeurs en sont les bénéficiaires directs.

Et webpack, dans tout ça ? Il reste pour les applications legacy, et c'est très bien ainsi. webpack n'est pas mort, il est maintenu, il fonctionne, et il existe des milliers d'apps en production qui tournent dessus sans souci. La communauté webpack continue de sortir des versions (webpack 6 est attendu fin 2026), les plugins sont documentés, les ingénieurs le connaissent. Pour une organisation qui a un build stable et des contraintes faibles, rester sur webpack reste un choix raisonnable. La fin de webpack n'est pas un événement brutal, c'est un déclin lent et assumé.

Pour VALRY LABS, la ligne directrice est claire : tout nouveau projet démarre en Next 16 + Turbopack + React Compiler. Les projets existants sur Next 14 ou 15 migrent au rythme de leur roadmap produit, en commençant par `next dev --turbo` comme exposition à froid. Les cas lourds (configurations webpack très customisées, monorepos patrimoniaux) restent sur leur stack actuelle tant qu'aucune douleur ne justifie l'investissement. C'est cette discipline — adopter vite, migrer prudemment, conserver l'héritage quand il fonctionne — qui transforme une hype en avantage compétitif durable.