Next.js 16 : toutes les nouveautés que tu vas devoir encaisser

Next.js 16 est tombé et, surprise, tu n'as pas ton mot à dire. La doc officielle annonce la couleur : toutes les nouveautés sont listées dans le guide d'upgrade et il va falloir t'y plonger sérieusement. Je t'épargne le marketing : voici ce que tu dois encaisser pour rester dans la course.

Environnement : plus d'excuses

Tu tournes encore sur Node 18 ? Mauvaise pioche. Next.js 16 impose Node 20.9 minimum, TypeScript 5.1+ et des navigateurs modernes (Chrome/Edge/Firefox 111+, Safari 16.4+). Autrement dit, si ton parc ne suit pas, tu restes bloqué en 15 et tu assumes les failles. Pas de compromis.

Turbopack devient la norme

Fini les drapeaux --turbopack. Le moteur est activé par défaut en dev et en build, avec une config désormais au niveau racine (turbopack au lieu de experimental.turbopack). Si tu trimbales encore un webpack custom, la build casse expressément pour que tu arrêtes de l'oublier. Tu peux toujours rajouter --webpack pour repousser l'inévitable, mais Turbopack devient la voie officielle, avec au passage du cache disque en dev et la fin des imports Sass avec tilde.

APIs HTTP 100 % asynchrones

Next.js 15 avait laissé une compatibilité synchrone provisoire pour cookies, headers, draftMode, params et searchParams. C'est fini : tout passe en async, y compris dans opengraph-image, twitter-image, icon et apple-icon. Tu utilises encore la signature legacy ? Prépare tes await. Bonus : next typegen génère désormais des helpers (PageProps, LayoutProps, RouteContext) pour ne pas te noyer dans les types.

Côté React : 19.2 et compilateur stabilisé

Next.js 16 embarque React 19.2 (canary) et la panoplie qui va avec : View Transitions, useEffectEvent, Activity. En prime, le React Compiler passe en option stable (reactCompiler: true). Oui, ça rajoute du temps de build parce que Babel transpile derrière, mais tu obtiens une mémoïsation automatique sans tripoter memo à la main.

Cache Components et navigation plus futée

Le vieux flag experimental_ppr disparaît. À la place, Next.js introduit cacheComponents pour activer la nouvelle itération du Partial Pre-Rendering. Les transitions SPA profitent d'un préchargement plus malin : déduplication des layouts, préfetch incrémental… Résultat, plus de requêtes mais beaucoup moins de volume transféré. Tu voulais du confort : c'est fait, sans une ligne de code à changer.

Nouvelles API de cache : revalidateTag, updateTag, refresh

La couche cache se muscle :

• revalidateTag(tag, cacheLife) accepte un profil de durée pour rafraîchir tranquillement tes contenus.
• updateTag(tag) arrive pour offrir un read-your-writes immédiat dans les Server Actions.
• refresh() te laisse rafraîchir le router côté client juste après une action serveur.
• cacheLife et cacheTag sortent enfin du purgatoire unstable_.

Bref, soit tu profites pour clarifier ta stratégie de revalidation, soit tu continues à bricoler en priant pour que l'état ne parte pas en vrille.

middleware est mort, vive proxy

Les fichiers middleware.{js,ts} deviennent proxy. Le runtime est figé sur nodejs, l'edge n'est plus invité à la fête (pour l'instant). Même combat pour les options : skipMiddlewareUrlNormalize devient skipProxyUrlNormalize. La doc te mâche le boulot, mais oui, tu vas renommer des fichiers à la chaîne.

Images : serrage de vis

La vache sacrée next/image encaisse plusieurs changements :

• Les query strings sur les images locales nécessitent désormais images.localPatterns.search.
• minimumCacheTTL grimpe par défaut à 4 h pour calmer la frénésie de revalidation.
• L'entrée 16 dégage de imageSizes, les qualities se limitent à [75] par défaut, et les IP locales sont bloquées sans dangerouslyAllowLocalIP.
• Les redirections sont capées à 3 et next/legacy/image tire sa révérence.
• images.domains est déprécié au profit de remotePatterns.

Bref, si tu avais laissé cette config en roue libre, attends-toi à des surprises en production.

DX : dev/build séparés, ESLint à la main, scroll respecté

next dev et next build écrivent désormais dans des dossiers distincts (.next/dev pour le dev) et se verrouillent mutuellement pour éviter deux instances simultanées. Le chargement du next.config est rationalisé, donc oublie les détections process.argv.includes('dev') foireuses.

Côté lint, next lint disparaît. Tu passes sur l'ESLint CLI (ou Biome si ça t'amuse) et tu migres vers la flat config que @next/eslint-plugin-next impose désormais. Et si tu tenais à forcer le scroll instantané, ajoute data-scroll-behavior="smooth" sur <html> car Next.js laisse enfin ton CSS tranquille.

Alpha et petits bonus

• Build Adapters API (alpha) : un crochet expérimental pour que ton infra bidouille la pipeline de build.
• Modern Sass API grâce à sass-loader v16.
• AMP, next lint, serverRuntimeConfig/publicRuntimeConfig, devIndicators exotiques, experimental.dynamicIO et unstable_rootParams partent à la benne.

Tu voulais du "full-stack framework" ? Next.js 16 te rappelle qu'il mène la danse. Tu peux râler, ou tu t'alignes, tu mets à jour tes scripts (npm install next@latest react@latest react-dom@latest, puis @types si tu es à la mode TypeScript), tu lances le codemod npx @next/codemod@canary upgrade latest, et tu assumes. On se revoit à la prochaine salve.