Next.js 15 : ce qui change pour les développeurs front

Next.js 15 est sorti avec une liste de nouveautés qui, selon où on regarde, semblent soit mineures soit absolument fondamentales. La vérité est entre les deux. Certains changements modifient la façon dont vous devez architecturer vos apps ; d'autres sont des améliorations de confort qui réduisent la friction quotidienne.

Voici mon retour après plusieurs semaines sur des projets en production avec Next.js 15.

Turbopack stable : la fin du compromis vitesse / fiabilité

La nouvelle la plus impactante pour le developer experience : Turbopack passe de beta à stable. Ce bundler Rust-based, conçu comme successeur de Webpack, offre des améliorations significatives :

• Démarrage du serveur de développement : jusqu'à 76 % plus rapide sur de grands projets
• Hot Module Replacement : presque instantané même sur des codebase complexes
• Compilation initiale de pages : réduite de façon spectaculaire sur les projets avec beaucoup de dépendances

Dans la pratique, sur un projet de taille moyenne, la différence est nette mais pas spectaculaire — on passe de 3 à 4 secondes à moins d'une seconde au démarrage. Sur de grands projets, le gain est bien plus visible.

Turbopack ne remplace pas Webpack pour les configurations très personnalisées — si vous avez des loaders Webpack exotiques, vérifiez la liste de compatibilité avant de migrer.

React 19 et les nouvelles fonctionnalités

Next.js 15 supporte officiellement React 19, ce qui débloque plusieurs fonctionnalités attendues depuis longtemps.

Les Actions

Les Server Actions ont été stabilisées et formalisées. Elles permettent de gérer les mutations de données côté serveur directement depuis les composants, sans créer d'API routes manuelles. La syntaxe est plus ergonomique et la gestion des états pending/error/success est intégrée nativement.

use() et Suspense

Le hook use() de React 19 permet de consommer des Promises directement dans les composants, avec Suspense gérant l'état de chargement automatiquement. Combiné avec les Server Components et le streaming, cela produit des interfaces qui chargent de façon progressive — le contenu apparaît au fur et à mesure qu'il devient disponible.

Ref comme prop directe

Fini forwardRef — en React 19, les refs se passent directement comme n'importe quelle prop. Un changement mineur en surface, mais qui simplifie les bibliothèques de composants et élimine un pattern verbeux.

Caching : comportement repensé

Le système de cache de Next.js 14 était puissant mais souvent surprenant — les requêtes fetch étaient cachées par défaut, ce qui causait des comportements inattendus. Next.js 15 inverse ce défaut : les requêtes fetch et les routes ne sont plus cachées automatiquement.

Cette décision opinionée améliore la prévisibilité du comportement par défaut. Vous optez explicitement dans le cache :

• cache: force-cache pour les données statiques
• revalidate: 3600 pour les données semi-statiques (ISR)
• Par défaut : requête fraîche à chaque demande

Pour les apps existantes migrées depuis Next.js 14, vérifiez vos routes — du contenu qui semblait dynamique était peut-être caché sans que vous le sachiez.

Async Request APIs

cookies(), headers() et params dans les layouts et pages deviennent asynchrones en Next.js 15. C'est un breaking change — vous devrez ajouter await devant ces appels dans vos composants.

Le codemod officiel gère une grande partie de cette migration automatiquement : npx @next/codemod@canary upgrade latest. Utilisez-le avant de chercher à migrer manuellement.

Ce qui change pour vos projets

Si vous démarrez un nouveau projet, Next.js 15 est le choix évident — la configuration par défaut est plus sensée et les nouvelles APIs sont plus ergonomiques. Pour la migration depuis Next.js 14 :

• Exécutez le codemod officiel en premier
• Vérifiez votre stratégie de cache explicitement
• Testez les routes qui dépendent de cookies, headers ou params dynamiques

Next.js 15 ne révolutionne pas — il consolide et corrige. C'est souvent le type de release le plus utile.