Si vous développez avec React ou Next.js depuis quelques années, vous connaissez bien ce moment : vous lancez npm run dev, et vous attendez. 5 secondes. 10 secondes. Parfois 30 secondes pour les gros projets.
C'est la faute de Webpack.
Webpack a été un outil révolutionnaire. Il a permis l'essor des applications modernes en gérant les modules, les assets, le code splitting. Mais il a un défaut majeur : il est écrit en JavaScript.
Et JavaScript, pour des tâches de calcul intensif comme parser des milliers de fichiers, a ses limites.
Annoncé par Vercel (les créateurs de Next.js) et Tobias Koppers (le créateur de... Webpack !), Turbopack se présente comme le successeur spirituel de Webpack.
La différence majeure ? Il est écrit en Rust.
Rust est un langage système, comparable au C++ en termes de performances, mais avec une gestion de la mémoire plus sûre.
Vercel a annoncé que Turbopack était jusqu'à 700 fois plus rapide que Webpack pour certaines mises à jour. C'est un chiffre marketing, certes, mais la réalité est quand même impressionnante.
Sur un projet Next.js de taille moyenne (3000 modules), voici ce qu'on observe généralement :
| Action | Webpack (Next.js 12) | Turbopack (Next.js 16) | Gain |
|---|---|---|---|
| Cold Start (démarrage serveur) | 4.5s | 0.8s | ~5.6x |
| HMR (modification fichier) | 1.2s | 0.05s | ~24x |
Le gain le plus perceptible est sur le HMR (Hot Module Replacement). Quand vous modifiez un fichier CSS ou un composant, le changement est quasi instantané dans le navigateur. On ne perd plus le "flow" de développement.
Turbopack utilise une architecture de calcul incrémental inspirée des systèmes de build comme Bazel (Google) ou Buck (Facebook).
Au lieu de re-calculer tout le bundle à chaque changement, Turbopack garde en cache le résultat de chaque fonction. Si vous changez un fichier, il ne re-calcule que ce qui est strictement nécessaire, et réutilise tout le reste.
Comme il est écrit en Rust, il peut utiliser le multi-threading de manière beaucoup plus efficace que Node.js.
C'est la grande question.
Avec Next.js 16, Turbopack est stable pour le serveur de développement (next dev --turbo). C'est d'ailleurs devenu le défaut sur les nouveaux projets.
Pour le build de production (next build), Turbopack commence à être utilisé pour certaines parties, mais Webpack reste encore utilisé sous le capot pour garantir la compatibilité maximale avec l'immense écosystème de plugins existants.
L'objectif final est de remplacer totalement Webpack, mais la transition prendra du temps. L'écosystème Webpack est gigantesque (loaders, plugins).
Si vous utilisez Next.js, la question ne se pose même pas : vous l'utilisez déjà ou vous allez l'utiliser sans effort.
Pour utiliser Turbopack en dev dès maintenant :
next dev --turbo
Si vous avez des configurations Webpack très complexes (next.config.js avec beaucoup de modifications webpack personnalisées), vous pourriez rencontrer des incompatibilités. Turbopack ne supporte pas les plugins Webpack. Il faut utiliser les équivalents natifs ou attendre que le support s'améliore.
On ne peut pas parler de Turbopack sans parler de Vite (qui utilise esbuild, écrit en Go).
Vite a révolutionné le dev server en n'utilisant PAS de bundling en développement (il utilise les modules ES natifs du navigateur). C'est extrêmement rapide au démarrage.
Turbopack, lui, bundle quand même le code en développement, mais il le fait extrêmement vite.
L'avantage de l'approche Turbopack : l'environnement de dev est plus proche de la production. Avec Vite, vous pouvez avoir des bugs qui n'apparaissent qu'au build de production (car Rollup est utilisé pour le build, esbuild pour le dev). Avec Turbopack, la logique est plus unifiée.
Nous vivons une transition majeure dans l'outillage frontend. Les outils écrits en JS (Webpack, Babel, ESLint, Prettier) sont progressivement remplacés ou accélérés par des outils écrits en langages systèmes (Rust, Go).
Pour nous développeurs, c'est une excellente nouvelle : nos outils deviennent invisibles par leur rapidité. Moins d'attente, plus de code.
Besoin d'aide ?
Container queries, :has(), nesting natif, view transitions — le CSS de 2026 fait ce que JavaScript et Sass faisaient avant. Tour d'horizon des fonctionnalités qui changent la donne.
Les sites statiques appartiennent au passé. Découvrez comment les micro-interactions fluides avec Framer Motion augmentent l'engagement utilisateur et le taux de conversion.
Un site WordPress qui mettait 12 secondes à charger est passé à 1,8 seconde en corrigeant trois erreurs courantes. Voici lesquelles.
