Next.js 15, publié en octobre 2024 par Vercel, marque une étape décisive dans la maturation du framework React côté serveur. En 2026, il s’est imposé comme la référence pour les applications web fullstack en JavaScript, avec Turbopack stable, un modèle de cache repensé et une intégration poussée des React Server Components. Pour les équipes qui maintiennent des projets sous Next.js 14 ou des versions antérieures, comprendre les nouveautés de la version 15 est essentiel pour planifier une migration en toute sérénité et tirer parti des gains de performance.
Turbopack stable : un bundler Rust 10x plus rapide
Turbopack, le bundler écrit en Rust qui remplace webpack dans Next.js, atteint enfin la stabilité de production avec la version 15. Après deux ans de développement et une phase bêta longue, il passe le seuil du million de tests et affiche des performances remarquables : démarrage à froid jusqu’à 76% plus rapide que webpack, et temps de rechargement à chaud (HMR) réduit de 96% sur les grandes applications. Pour les projets de plus de 500 composants, le passage de webpack à Turbopack est transparent et la différence de vitesse est immédiatement perceptible.
L’activation de Turbopack se fait simplement avec le flag –turbopack dans la commande next dev. La migration est non-destructive : si votre projet utilise des loaders webpack personnalisés, Next.js 15 propose un mécanisme de compatibilité qui traduit automatiquement les configurations webpack les plus courantes. Les plugins comme sass-loader, svgr ou le support des fichiers MDX ont été portés nativement dans Turbopack, ce qui couvre la grande majorité des projets existants.
En production, Turbopack n’est pas encore activé par défaut pour next build, qui utilise toujours le pipeline webpack optimisé. Vercel travaille sur la stabilisation du build de production pour Next.js 16. Néanmoins, le simple fait d’utiliser Turbopack en développement réduit significativement la friction du cycle développement-test-déploiement, surtout dans les équipes qui lancent de nombreuses feature branches en parallèle.
// next.config.ts (TypeScript config, nouveau dans Next.js 15)
import type { NextConfig } from 'next'
const config: NextConfig = {
experimental: {
ppr: 'incremental', // Partial Prerendering opt-in par route
useCache: true, // nouvelle directive "use cache"
},
// Turbopack actif en dev via : next dev --turbopack
}
export default configNouveau modèle de cache : opt-in plutôt qu’opt-out
L’un des changements les plus importants de Next.js 15 est le renversement de la philosophie de cache. Dans Next.js 14, les requêtes fetch étaient mises en cache par défaut, forçant les développeurs à ajouter cache: « no-store » explicitement pour obtenir des données fraîches. Avec la version 15, les requêtes fetch ne sont plus mises en cache par défaut. Pour activer le cache, il faut désormais le spécifier explicitement avec next: { revalidate: 3600 } ou force-cache. Cette inversion réduit les bugs subtils liés à des données obsolètes affichées à tort.
Le comportement des routes dynamiques a également changé : par défaut, les routes qui utilisent searchParams, cookies() ou headers() sont rendues de manière dynamique sans nécessiter de configuration supplémentaire. La directive « use cache » introduite expérimentalement dans Next.js 15 permet de marquer des composants serveur ou des fonctions comme pouvant être mis en cache de manière granulaire. C’est une approche plus explicite et moins source d’erreurs que le système précédent.
Ces changements de cache nécessitent une attention particulière lors de la migration depuis Next.js 14. Il est recommandé d’auditer chaque appel fetch dans l’application et de vérifier si le comportement attendu est toujours garanti. Vercel propose un guide de migration automatisé via le codemods npx @next/codemod@latest upgrade qui identifie les patterns à risque et propose des corrections automatiques pour la majorité des cas courants.
React 19 et les nouvelles APIs serveur
Next.js 15 est la première version à prendre en charge React 19 de manière stable. Cette version majeure de React apporte l’API use(), qui permet d’attendre des Promises directement dans les composants sans useEffect, ainsi que les actions de formulaires natives avec les attributs action et formAction qui peuvent pointer vers des Server Actions. Pour les développeurs, cela simplifie radicalement la gestion des formulaires et des mutations de données côté serveur.
Les Server Actions, stabilisées dans Next.js 14 et affinées dans la version 15, bénéficient avec React 19 d’un meilleur support pour la gestion des états d’attente et d’erreur via le hook useActionState. Ce hook remplace useFormState (désormais déprécié) et offre une API plus claire pour afficher un état de chargement, gérer les erreurs de validation côté serveur et mettre à jour l’interface après une action réussie, le tout sans une seule ligne de code d’appel API manuel.
La directive « use client » et « use server » fonctionnent désormais de manière plus fine dans Next.js 15. Il est possible de créer des composants « hybrides » qui s’hydratent partiellement, avec certaines parties restant des îlots statiques. Cette architecture, inspirée par Astro et Islands Architecture, réduit le JavaScript envoyé au navigateur et améliore le Time To Interactive, particulièrement crucial pour les applications mobiles.
Améliorations du App Router et des layouts
Le App Router de Next.js, introduit en version 13 et stabilisé progressivement, reçoit dans la version 15 plusieurs améliorations de qualité de vie. La gestion des erreurs parallèles avec error.tsx est plus prévisible et les groupes de routes (route groups) supportent désormais les layouts partagés entre sous-groupes sans duplication de code. Les développeurs qui ont structuré des applications complexes avec des espaces d’administration et des espaces publics apprécieront ces clarifications.
Le Partial Prerendering (PPR), introduit expérimentalement dans Next.js 14, passe en disponibilité générale dans la version 15 sous forme de fonctionnalité opt-in. PPR permet de pré-rendre une coquille statique de la page (header, navigation, contenu critique) lors du build, tout en différant le rendu des parties dynamiques (fil d’actualité, données utilisateur) au moment de la requête. Le résultat est un TTFB immédiat combiné à un contenu dynamique fraîchement rendu, sans compromettre la personnalisation.
Les redirects et rewrites configurés dans next.config.js bénéficient d’une meilleure performance grâce au motage au niveau du serveur. Next.js 15 peut désormais déléguer certaines redirections au CDN Vercel ou à des intermédiaires compatibles Edge Middleware, réduisant la latence de redirection de plusieurs dizaines de millisecondes dans des contextes géo-distribués. Pour les sites e-commerce avec des règles de redirection complexes, cet gain est immédiatement visible dans les métriques Core Web Vitals.
Instrumentation et observabilité avec OpenTelemetry
Next.js 15 stabilise le support d’OpenTelemetry via le fichier instrumentation.ts à la racine du projet. Ce fichier s’exécute une seule fois au démarrage du serveur et permet d’initialiser des providers de traçage comme @opentelemetry/sdk-node sans hack de configuration. Les Server Actions, les routes API et les Server Components génèrent automatiquement des spans avec les métadonnées pertinentes (nom de route, méthode HTTP, durée), facilitant le débogage en production.
L’intégration avec des outils comme Datadog, Sentry ou Honeycomb devient plus directe grâce à des SDK qui exploitent nativement les traces OpenTelemetry de Next.js 15. Il est par exemple possible de corréler une erreur frontend avec la Server Action correspondante en production, ou d’identifier les composants serveur les plus lents à partir d’un tableau de bord de performance distribué. Pour les équipes qui opèrent des applications Next.js à grande échelle, cette observabilité native change radicalement le débogage.
Next.js 15 expose également des métriques de performance via le hook onRequestError dans instrumentation.ts, permettant d’enregistrer toutes les erreurs non gérées côté serveur avec leur contexte complet. Combiné avec un service d’alerting, cela permet de détecter les régressions en production quelques secondes après un déploiement, bien avant que les utilisateurs ne les signalent. C’est une avancée majeure pour les équipes qui font du déploiement continu sans fenêtre de maintenance.
TypeScript et ESLint 9 : configuration modernisée
Next.js 15 adopte ESLint 9 avec son nouveau format de configuration plat (flat config) dans le fichier eslint.config.mjs, remplaçant l’ancien .eslintrc.json. Cette migration unifie la configuration ESLint avec les conventions du tooling JavaScript moderne et simplifie la composition de règles entre le projet principal et les packages d’un monorepo. Le plugin next/eslint-config-next a été mis à jour pour exposer des presets compatibles avec le format plat.
Le support de TypeScript 5.6+ apporte dans Next.js 15 des bénéfices concrets : les types des Server Actions sont désormais inférés automatiquement, réduisant le boilerplate de définition de types pour les mutations. Les types de configuration de next.config.ts (oui, TypeScript dans la config !) permettent une validation statique des options au moment de l’écriture du code, avec autocomplétion dans VSCode. Pour les grandes équipes, cela élimine une classe entière de bugs de configuration difficiles à détecter.
Next.js 15 introduit également une vérification statique des routes au moment de la compilation. Le plugin TypeScript inclus génère des types pour toutes les routes de l’application, ce qui permet de détecter une route mal orthographiée dans un appel useRouter().push() ou dans une balise Link. Dans un projet avec des dizaines de routes dynamiques, cette vérification évite des 404 silencieux qui peuvent impacter le référencement ou l’expérience utilisateur.
Quand migrer depuis Next.js 14 ?
La migration depuis Next.js 14 vers la version 15 est recommandée dès maintenant pour les projets en développement actif. Le codemods officiel (npx @next/codemod@latest upgrade) automatise la majorité des changements cassants : mise à jour des imports React, adaptation des appels fetch sans cache, renommage des APIs dépréciées. Pour un projet de taille moyenne, la migration guidée prend généralement une demi-journée, y compris les tests de non-régression.
Pour les projets en production avec une forte contrainte de stabilité, une stratégie de migration progressive est recommandée. Commencer par activer Turbopack uniquement en développement (–turbopack dans next dev) pour valider la compatibilité sans toucher au build de production. Ensuite, identifier les routes qui s’appuient sur le cache implicite de Next.js 14 avec un audit des appels fetch, et les adapter explicitement avant de déployer en production.
Les applications qui utilisent le Pages Router (pages/) plutôt que le App Router (app/) sont entièrement compatibles avec Next.js 15 sans changement. Vercel maintient le Pages Router pour des raisons de compatibilité ascendante, mais la feuille de route à long terme privilégie le App Router. Pour les nouveaux projets, démarrer directement avec l’App Router de Next.js 15 est la recommandation officielle, en particulier si vous souhaitez bénéficier du PPR et des dernières optimisations de Server Components.
Performance réelle : benchmarks et retours d’expérience
Les benchmarks indépendants publiés en 2025-2026 montrent que Next.js 15 avec Turbopack réduit les temps de build de développement de 60 à 80% par rapport à Next.js 13 avec webpack, sur des applications de 200 à 500 composants. Le rechargement à chaud après modification d’un composant passe de 800ms-2s à moins de 100ms dans la plupart des cas. Pour une équipe de 5 développeurs qui passent 8 heures par jour à coder, la réduction du temps perdu à attendre les rebuilds représente plusieurs heures de productivité récupérées chaque semaine.
En production, le Partial Prerendering de Next.js 15 améliore significativement les scores Largest Contentful Paint (LCP) mesurés par Google Search Console. Des équipes ayant migré des pages e-commerce vers PPR rapportent des gains de 0,3 à 0,8 seconde sur le LCP, ce qui peut se traduire en amélioration de position dans les résultats Google selon les études de corrélation Core Web Vitals / SEO. Pour les sites avec un trafic organique important, l’impact business peut être substantiel.
Les retours d’expérience de la communauté sur les versions candidates de Next.js 15 signalent quelques points de vigilance : les applications qui utilisent intensivement les middlewares Edge doivent vérifier la compatibilité avec les nouvelles APIs, et les projets avec des configurations webpack très personnalisées peuvent nécessiter un travail d’adaptation avant de basculer sur Turbopack. Dans l’ensemble, la migration est considérée comme stable et bénéfique par la grande majorité des équipes qui l’ont effectuée.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.