TL;DR

• Next.js 16 sort en octobre 2025 avec Turbopack comme bundler par defaut. Webpack n'est plus le defaut, mais reste disponible.
• Turbopack apporte 5-10x de gain en temps de build dev et un Hot Module Replacement quasi-instantane.
• Les Cache Components avec use cache et le Partial Pre-Rendering (PPR) changent la facon dont on pense le rendu et le cache.
• Les Devtools MCP permettent aux agents IA d'interagir directement avec le serveur de dev Next.js. C'est un signal fort de la direction que prend l'ecosysteme.
• Ce site tourne sur Next.js 15. Je te raconte la migration vers 16 et ce que ca change concretement.

Turbopack : de l'experimental au defaut

Ca fait trois ans qu'on entend parler de Turbopack. Annonce en grande pompe a Next.js Conf 2022, marque comme experimental pendant deux ans, puis beta dans Next.js 15. Avec la version 16, c'est termine : Turbopack est le bundler par defaut.

La promesse etait ambitieuse : remplacer Webpack, le bundler que tout le monde utilise et que tout le monde deteste. Webpack, c'est puissant mais c'est lent. Sur un gros projet, un cold start du serveur de dev peut prendre 30 secondes. Un Hot Module Replacement peut prendre 2-3 secondes. Dans un monde ou on veut du feedback instantane, c'est une eternite.

Turbopack est ecrit en Rust (via le framework Turbo de Vercel). Il utilise une architecture de calcul incrementale : au lieu de re-bundler tout le projet quand un fichier change, il ne recalcule que ce qui est impacte. Le resultat est spectaculaire.

Sur mon blog (ce site que tu lis), les chiffres :

Le gain en dev est enorme. Le build production est moins impressionnant parce que Turbopack en mode production est plus recent et n'a pas encore toutes les optimisations de Webpack. Mais le dev, c'est la ou tu passes 8 heures par jour. Et 50ms de HMR, ca change ta facon de travailler.

Le vrai impact sur le workflow

Quand le HMR est quasi-instantane, tu changes de workflow. Au lieu de sauvegarder, attendre, verifier -- c'est sauvegarde et le resultat est deja la. Tu peux iterer sur du CSS, du layout, du contenu MDX avec un feedback immediat.

Ca parait anodin, mais sur une journee de dev frontend, tu economises des centaines de micro-attentes. Et surtout, tu ne perds plus le flow. Le cerveau n'a pas le temps de se distraire entre l'edit et le rendu. Tu restes concentre.

Pour un site Next.js comme le mien, avec du MDX, des composants dynamiques et du Tailwind, c'est un vrai plaisir. Avant, chaque modification de contenu MDX prenait une seconde et demie. Maintenant c'est instantane.

Cache Components et use cache

La deuxieme grande nouveaute, c'est les Cache Components. C'est la suite logique du travail sur les Server Components et le Partial Pre-Rendering (PPR).

Le concept : tu peux marquer un composant ou une fonction avec la directive use cache. Next.js va automatiquement cacher le resultat et le reutiliser tant que les donnees sous-jacentes n'ont pas change.

// Avant : revalidation manuelle avec ISR
export const revalidate = 3600; // revalider toutes les heures

async function BlogPosts() {
  const posts = await getPosts();
  return <PostList posts={posts} />;
}

// Apres : cache granulaire avec `use cache`
async function BlogPosts() {
  "use cache";
  const posts = await getPosts();
  return <PostList posts={posts} />;
}

// Tu peux aussi cacher au niveau de la fonction
async function getExpensiveData(id: string) {
  "use cache";
  // Ce resultat est cache automatiquement
  return await db.query(`SELECT * FROM data WHERE id = ?`, [id]);
}

L'avantage par rapport a l'ISR classique, c'est la granularite. Tu ne caches plus une page entiere -- tu caches des morceaux independants. Un composant peut etre cache pendant une heure, un autre pendant une minute, et un troisieme en temps reel. Le tout sur la meme page.

Combine avec le PPR (Partial Pre-Rendering), ca donne des pages ou le shell est statique et instantane, les parties dynamiques se chargent en streaming, et le cache est gere composant par composant. C'est elegant.

Devtools MCP : quand l'IA entre dans le serveur de dev

C'est la feature la plus surprenante de Next.js 16. Vercel integre un serveur MCP (Model Context Protocol) directement dans les devtools de Next.js. Ca signifie qu'un agent IA -- Claude Code, Cursor, ou n'importe quel client MCP -- peut interagir directement avec ton serveur de dev.

Concretement, l'agent peut :

• Lire les erreurs de build et de runtime en temps reel
• Inspecter les routes, les composants, et leur etat de cache
• Voir les metriques de performance (Core Web Vitals en dev)
• Lancer des builds partiels et verifier le resultat

C'est un signal fort de la direction que prend l'ecosysteme. Le serveur de dev n'est plus juste un outil pour humains -- c'est une interface pour agents. Et Next.js est le premier grand framework a l'integrer nativement.

Pour mon workflow avec Claude Code, c'est un game changer potentiel. Au lieu que l'agent doive lire les logs du terminal et deviner l'etat du serveur, il peut l'interroger directement via MCP. Le debug devient plus precis et plus rapide.

Migration de 15 vers 16 : retour d'experience

Ce site tourne sur Next.js 15 depuis sa creation. Voici comment s'est passe la migration vers 16.

Ce qui a marche sans rien toucher :

• Les Server Components existants
• Le routing App Router
• Les API routes
• Les composants MDX
• Tailwind CSS

Ce qui a demande des ajustements :

• next.config.mjs : la config Webpack custom doit etre adaptee pour Turbopack. Dans mon cas, j'avais un plugin MDX custom qui a necessite une reecriture mineure.
• Dependencies : certains packages qui hookaient dans le process Webpack ne fonctionnent plus. Pour moi, c'etait un plugin d'optimisation d'images qui n'etait de toute facon plus necessaire avec les optimisations natives.
• Tests : rien a changer cote tests unitaires. Les tests E2E qui s'appuyaient sur des timings specifiques du HMR ont du etre ajustes (le HMR est tellement plus rapide que certains waitFor etaient trop longs).

Temps total de migration : environ 2 heures, dont 1h30 a comprendre pourquoi le plugin MDX ne marchait plus et 30 minutes pour le fix effectif. Pour un site de cette taille, c'est tres raisonnable.

# La migration en 3 commandes
npm install next@16 react@latest react-dom@latest
npx @next/codemod@latest upgrade
npm run build

Le codemod de Next.js a fait 80% du travail. Il renomme les imports deprecies, ajuste les configs, et met a jour les types TypeScript. Le reste, c'est du debugging classique.

Ce que je n'utilise pas encore

Deux features de Next.js 16 que je n'ai pas encore adoptees :

Les Cache Components. Mon blog est essentiellement statique (SSG). Le cache granulaire est plus utile pour les applications dynamiques avec des donnees qui changent. Pour un blog, le build statique suffit.

Le Devtools MCP. J'attends que l'integration avec Claude Code soit plus mature. Actuellement, ca fonctionne mais c'est encore brut. Je prefere le workflow classique ou l'agent lit les fichiers et les logs directement.

Ce n'est pas une critique -- c'est juste que ces features sont plus pertinentes pour des applications complexes que pour un site de contenu.

Webpack est-il mort ?

Non. Et c'est important de le dire. Webpack reste disponible en fallback dans Next.js 16. Si tu as un projet avec une config Webpack complexe, des plugins custom, ou des loaders specifiques, tu peux continuer a utiliser Webpack en ajoutant un flag dans next.config.mjs.

Mais la direction est claire. Turbopack est le futur de Next.js. L'investissement en developpement est massivement sur Turbopack. Les nouvelles features (Cache Components, Devtools MCP) sont optimisees pour Turbopack en priorite.

Si tu demarres un nouveau projet, utilise Turbopack. Si tu migres un projet existant, teste Turbopack et fallback vers Webpack uniquement si tu rencontres un bloqueur.

Le bilan

Next.js 16 est la release la plus solide depuis le passage a l'App Router. Turbopack tient ses promesses apres trois ans de developpement. Les Cache Components sont une evolution naturelle des Server Components. Et le Devtools MCP montre que Vercel pense deja au monde ou les devs travaillent avec des agents IA.

Pour les utilisateurs de Next.js 15, la migration est douce. Pour les nouveaux projets, c'est un no-brainer. Et pour l'ecosysteme frontend en general, c'est un signal que le bundler n'est plus un probleme -- c'est une commodite.

Il reste des angles morts. Le build production Turbopack n'est pas encore a parite avec Webpack sur toutes les optimisations. L'ecosysteme de plugins est plus restreint. Et le Devtools MCP est encore en preview.

Mais la trajectoire est bonne. Et en tant que dev qui passe ses journees dans Next.js, c'est ce qui compte.

Ressources

• Next.js 16 Blog Post -- l'annonce officielle
• Turbopack Documentation -- la doc complete
• Next.js Devtools MCP -- le protocole MCP pour les devtools
• Upgrading Guide -- le guide de migration officiel
• Partial Pre-Rendering -- PPR en detail