Next.js 16 : ce qui change vraiment, et faut-il migrer

Next.js 16 est sorti le 21 octobre 2025, et la version 16.3 le 3 août 2026. Trois choses comptent vraiment. Turbopack est devenu le bundler par défaut. Le cache est devenu explicite, avec une directive à activer soi-même au lieu d'un cache implicite difficile à prévoir. Et une série de ruptures oblige à passer par un outil de migration automatique plutôt qu'à bumper une version.

Si vous êtes en Next.js 15, la migration vaut le détour, surtout pour le temps de build et la mémoire en développement. Si vous êtes déjà en 16, passez en 16.3 : l'essentiel des gains arrive sans toucher une ligne de code. Voici ce qui change, ce que nous avons activé sur ce site, et ce que nous avons volontairement laissé de côté.

Ce que vous gagnez sans rien changer

C'est la partie la plus simple à arbitrer, parce qu'elle ne demande aucune modification applicative. La version 16.3 apporte quatre gains mesurés par l'équipe Next.js.

• La mémoire en développement. Jusqu'à 90 % de RAM en moins sur les longues sessions, grâce au cache disque et à l'éviction mémoire activés par défaut. Sur le tableau de bord de Vercel, 21,5 Go avant, 2 Go après. Sur nextjs.org, 4 600 Mo contre 840 Mo.
• Les builds répétés. Le cache disque s'applique désormais à la compilation de production. Sur les projets mesurés par Vercel, de 21 à 9,2 secondes pour nextjs.org, et de 30 à 5,5 secondes sur un de leurs sites, soit un facteur 5,5.
• Le rendu serveur. Le passage aux flux natifs de Node à la place des flux web permet de tenir jusqu'à 22 % de requêtes en plus sous charge, sans changement de code.
• La vérification de types. TypeScript 7, port natif annoncé dix fois plus rapide, peut désormais servir au typage pendant le build.

Sur un projet où le build conditionne le délai de mise en production, ces chiffres se traduisent directement en minutes gagnées à chaque déploiement.

Turbopack par défaut, et ce que ça implique

Turbopack est stable en développement comme en production, et c'est désormais le bundler par défaut. La note de version 16 annonce des builds de production 2 à 5 fois plus rapides et un rafraîchissement à chaud jusqu'à 10 fois plus rapide. Au moment de la sortie, plus de la moitié des sessions de développement et 20 % des builds de production sur Next.js 15.3 et au-delà tournaient déjà dessus.

Le point de vigilance concerne les projets avec une configuration webpack maison. Ils peuvent continuer avec webpack en ajoutant l'option correspondante aux commandes, mais c'est une dette : autant profiter de la migration pour regarder si la configuration personnalisée se justifie encore.

Le vrai changement de modèle : le cache devient explicite

C'est la rupture conceptuelle de cette version majeure, et elle est bienvenue. Dans les versions précédentes de l'App Router, le cache était implicite : certaines requêtes étaient mises en cache par défaut, d'autres non, et comprendre pourquoi une page servait des données périmées relevait de l'enquête.

Le nouveau modèle, appelé Cache Components, inverse la logique. Tout le code dynamique s'exécute à la requête par défaut, et vous déclarez explicitement ce qui doit être mis en cache avec la directive use cache, applicable à une page, un composant ou une fonction. Le compilateur se charge de générer les clés de cache. Il faut l'activer dans la configuration, c'est entièrement optionnel.

Ce modèle complète le rendu partiellement pré-rendu, qui permet qu'une page largement statique contienne des zones dynamiques sans sacrifier la rapidité du premier affichage. En 16.3, l'ensemble s'étend à la navigation, avec un préchargement plus fin, des coquilles de chargement extraites automatiquement et des outils pour repérer les navigations lentes. L'équipe annonce que ces comportements deviendront le défaut dans une future version majeure.

Ce que nous avons activé sur ce site, et ce que nous n'avons pas activé

Autant être concret, puisque ce site tourne sur la version en question. Nous sommes en Next.js 16.3 avec React 19.2, en sortie autonome dans une image Docker déployée sur notre propre infrastructure, avec Payload comme CMS.

Nous avons pris tous les gains gratuits : Turbopack, le cache disque, les flux natifs, le nouveau préchargement. Nous avons aussi renommé notre interception de requêtes en proxy, conformément au nouveau nom de fichier qui remplace l'ancien middleware.

Nous n'avons pas activé Cache Components, et la raison est instructive. Ce site rend ses pages à la requête pour pouvoir injecter un jeton unique dans sa politique de sécurité de contenu à chaque réponse. Dans cette configuration, une bonne partie du bénéfice du cache de rendu tombe, puisque le document HTML ne peut pas être servi tel quel d'une requête à l'autre. S'ajoute le fait que le contenu vient d'un CMS, avec une invalidation déjà gérée au niveau applicatif.

La leçon générale est là : Cache Components n'est pas un interrupteur qui rend un site plus rapide. C'est un modèle qui paie sur les pages à fort trafic dont le contenu change peu, et qui apporte peu sur une application personnalisée par utilisateur ou soumise à des contraintes de sécurité qui imposent le rendu à la requête. La question à poser n'est pas « faut-il l'activer » mais « quelles pages en bénéficieraient ».

Les ruptures à prévoir

Une migration depuis la 15 n'est pas un simple changement de numéro. Voici les points qui demandent du travail, par ordre de fréquence constatée.

• Les paramètres deviennent asynchrones. Les props de route et les accès au contexte de requête doivent être attendus. C'est la modification la plus répandue, et celle que l'outil automatique traite le mieux.
• Les versions minimales montent. Node 20.9 et TypeScript 5.1 au minimum, avec un socle navigateur relevé.
• Plusieurs commandes et options disparaissent. La commande de lint intégrée est retirée et le build ne lance plus le lint, les anciennes configurations d'exécution sont supprimées au profit des variables d'environnement, et le support AMP n'existe plus.
• Les valeurs par défaut des images changent. Durée de cache minimale portée de 60 secondes à 4 heures, qualités réduites à une seule valeur par défaut, nombre de redirections limité, restrictions nouvelles sur les sources locales. Vos images peuvent changer d'apparence ou de poids sans que vous ayez touché au code.
• Les routes parallèles exigent un fichier par défaut. Sans lui, le build échoue, là où la version précédente tolérait l'absence.
• L'invalidation par étiquette change de signature. La fonction attend désormais un profil de durée de vie en second argument, et une nouvelle fonction permet de lire immédiatement les données fraîches après écriture.

Dans notre expérience, l'essentiel se traite avec l'outil de migration fourni, et le reste tient dans une demi-journée sur une application de taille moyenne. Ce sont les valeurs par défaut des images et les routes parallèles qui réservent les mauvaises surprises, parce qu'elles passent la compilation et se voient seulement à l'exécution.

La méthode que nous recommandons pour migrer

Commencez par geler le reste. Une montée de version majeure dans une branche qui contient aussi des fonctionnalités est impossible à relire et difficile à annuler.

Lancez ensuite l'outil de migration officiel, puis faites passer le typage et les tests avant même de regarder le rendu. La plupart des changements asynchrones se voient à la compilation, c'est le filet le plus rapide.

Vérifiez ensuite trois choses au navigateur, parce qu'elles échappent au typage : les images, les routes parallèles, et toutes les pages qui dépendaient implicitement du cache. Mesurez enfin avant et après, sur le build et sur les pages réelles. Si vous suivez vos Core Web Vitals, c'est le moment de relever les valeurs de référence.

Gardez Cache Components pour un second temps, dans une branche à part. Mélanger la montée de version et le changement de modèle de cache revient à déboguer deux choses à la fois.

Trois nouveautés discrètes qui servent tous les jours

Au-delà des grands titres, la 16.3 apporte des détails qui changent le quotidien d'une équipe, et dont on parle peu.

Les paramètres racine, d'abord. Sur un site bilingue, la langue vit dans le segment le plus haut de l'URL, et il fallait jusqu'ici la faire descendre de composant en composant. Elle se lit désormais directement depuis n'importe quel composant serveur, sans passer par les propriétés. Pour un site comme le nôtre, où chaque page existe en français et en anglais, cela supprime une quantité notable de plomberie.

Les limites d'erreur personnalisées, ensuite. Auparavant, une limite d'erreur interférait avec les redirections et les pages introuvables, et ne savait réinitialiser que l'état côté client. La nouvelle interface permet de définir une limite qui n'interfère plus avec ces mécanismes et qui expose une fonction pour réessayer, y compris en refaisant le rendu des composants serveur concernés. C'est le genre de détail qui transforme une page d'erreur subie en récupération propre.

Enfin, la documentation versionnée pour les agents de code. Au démarrage du serveur de développement, Next écrit et maintient lui-même un bloc dans le fichier d'instructions destiné aux agents, pointant vers la documentation de la version exactement installée. C'est surprenant la première fois qu'on le voit apparaître dans un diff, et c'est pensé pour éviter qu'un assistant de code réponde avec les conventions d'une version précédente. Nous en parlions dans notre article sur les agents de codage IA : le problème n'est pas la génération de code, c'est le contexte sur lequel elle s'appuie.

Faut-il migrer maintenant ?

Si vous êtes en Next.js 15 sur une application en production, oui, et le plus tôt sera le mieux : l'écart ne se réduira pas, et les gains de build et de mémoire se constatent dès le premier jour. Si vous êtes en 16.0 ou 16.1, passer en 16.3 est presque sans risque, c'est une version mineure avec des gains automatiques.

Si vous êtes sur le Pages Router, le sujet n'est pas la version de Next mais le modèle d'architecture, et il mérite un arbitrage à part. Nous expliquons les différences de fond dans notre article Next.js ou React.

Si vous partez d'un outil sans code, la question ne se pose pas dans ces termes : le sujet est la migration elle-même, que nous détaillons dans notre guide sur le passage du no-code à Next.js.

Ce que nous en retenons

Next.js 16 et sa version 16.3 forment une bonne nouvelle pour les équipes : des builds plus rapides, un serveur de développement enfin raisonnable en mémoire, un rendu serveur plus efficace, et surtout un modèle de cache compréhensible après des années d'implicite.

La migration demande une demi-journée de travail réel sur une application moyenne, plus une vérification attentive des images et des routes parallèles. Cache Components est une décision à prendre séparément, page par page, et pas forcément en votre faveur si votre application rend tout à la requête, comme la nôtre.

Nous travaillons sur cette stack au quotidien, sur nos projets comme sur ce site. Si vous avez une application Next.js à faire monter de version ou à reprendre, notre page agence Next.js détaille la façon dont nous intervenons, et vous pouvez en parler avec nous.