Next.js 15 perd son support officiel le 21 octobre 2026. Le plan concret pour auditer, migrer et sécuriser votre app avant l'échéance.
Next.js 15 perd tout support officiel le 21 octobre 2026, selon le calendrier de fin de vie publié par HeroDevs. Concrètement : plus aucun correctif de sécurité après cette date, même en cas de faille critique. Si votre application tourne encore dessus, ce texte vous donne un plan pour auditer, migrer et éviter les pièges classiques avant l'échéance.
Pourquoi cette date compte vraiment
Une version en fin de vie n'arrête pas de fonctionner du jour au lendemain. Elle continue de tourner, silencieusement, jusqu'au jour où une CVE sort et où personne ne la corrige pour vous.
C'est là le vrai risque : pas une panne immédiate, mais une fenêtre d'exposition qui s'ouvre sans prévenir. Les équipes sécurité de vos clients ou de vos partenaires B2B posent de plus en plus souvent la question du support des dépendances dans leurs audits fournisseurs. Un framework non maintenu peut faire échouer un audit SOC2 ou ISO 27001, indépendamment de la qualité de votre code.
Next.js 15 est actuellement en Maintenance LTS, ce qui veut dire : patchs de sécurité critiques seulement, plus aucune nouvelle fonctionnalité. Après le 21 octobre 2026, même ça s'arrête. Vous avez, à la date de rédaction de cet article, un peu moins de trois mois pour statuer.
Trois mois, ça paraît long. Ça ne l'est pas pour une équipe de moins de 5 devs qui doit aussi livrer ses features du trimestre.
Auditer avant de migrer : ce qu'il faut vérifier en premier
Migrer sans audit préalable, c'est le meilleur moyen de découvrir un breaking change en production un vendredi soir. Avant de toucher au package.json, passez en revue ces points.
L'usage du Pages Router résiduel. Beaucoup d'applications Next.js ont migré vers l'App Router en façade mais gardent des routes API ou des pages legacy sur l'ancien système. Ce sont les premières à casser lors d'une montée de version majeure.
Les dépendances tierces liées au rendu. Les librairies qui patchent le comportement de rendu de Next.js (certains SDK d'A/B testing, certains outils de personnalisation) sont souvent les dernières à publier une version compatible. Vérifiez leur changelog avant de vous engager sur un calendrier.
Les Server Actions et le cache de données. Le comportement de cache introduit avec l'App Router a évolué à plusieurs reprises depuis Next.js 13. Si votre équipe a mis en place des contournements manuels pour gérer la revalidation, ce sont des points de friction quasi garantis lors d'une migration majeure.
La version de Node.js et de React sous-jacente. Next.js 15 s'appuie sur React 19 ; une montée de version majeure du framework s'accompagne quasi systématiquement d'un relèvement de la version Node minimale supportée. Vérifiez votre runtime de production, y compris sur les environnements de preview.
Faites cet inventaire dans un simple tableau, ligne par ligne, avec une colonne "risque" et une colonne "effort estimé". Ça prend une demi-journée. Ça vous évite deux semaines de mauvaise surprise.
Les étapes concrètes d'une migration sans casse
Une fois l'audit fait, la migration elle-même suit un chemin assez balisé, à condition de ne pas sauter d'étapes.
Étape 1 : isoler un environnement de test représentatif
Ne migrez jamais directement sur une branche qui pointe vers la prod. Créez un environnement miroir avec un jeu de données réaliste, pas une base vide. Les bugs de cache et de revalidation n'apparaissent souvent qu'avec du trafic et des données réelles.
Étape 2 : monter de version par palier, pas en un saut
Si vous êtes encore sur Next.js 13 ou 14, ne visez pas directement Next.js 16 en un seul commit. Passez par Next.js 15 d'abord, stabilisez, puis enchaînez. Chaque saut de version majeure isolé est plus simple à déboguer qu'un saut cumulé de trois versions.
Étape 3 : utiliser les codemods officiels quand ils existent
Vercel publie historiquement des codemods pour automatiser une partie des migrations entre versions majeures (renommage d'imports, adaptation de config). Ça ne couvre jamais 100 % du travail, mais ça évite les erreurs de frappe sur des centaines de fichiers.
Étape 4 : tester le build de production, pas seulement le dev
Le mode développement masque certains problèmes de génération statique ou d'Edge Runtime. Un next build complet, suivi d'un déploiement sur un environnement de preview isolé, doit faire partie de la checklist avant tout merge.
Étape 5 : planifier un rollback avant le déploiement, pas après
Gardez l'ancienne version déployable en un clic pendant au moins deux semaines après la bascule. La plupart des régressions de cache ou de SEO (balises, sitemap, redirections) n'apparaissent qu'après plusieurs jours de trafic réel.
Une équipe produit avec une application de 200 pages et des Server Actions complexes comptera plusieurs semaines de travail réparties sur deux ou trois sprints. Un site vitrine de 15 pages sans logique métier lourde peut, lui, basculer en un seul sprint. L'écart de charge de travail entre ces deux cas est énorme, méfiez-vous des estimations génériques trouvées en ligne, elles ne tiennent presque jamais compte de la taille réelle du projet.
Rester sur next.js 15 ou migrer maintenant : le comparatif
| Critère | Rester sur Next.js 15 après le 21/10/2026 | Migrer vers Next.js 16 avant l'échéance |
|---|---|---|
| Correctifs de sécurité | Aucun après la date de fin de vie | Support actif, patchs réguliers |
| Compatibilité audits fournisseurs | Risque de non-conformité (SOC2, ISO 27001) | Conforme aux exigences de maintenance |
| Coût immédiat | Nul à court terme | Temps dev à mobiliser (semaines à mois) |
| Risque à moyen terme | Dette technique qui s'accumule, migration plus dure demain | Base de code à jour, migrations futures plus simples |
| Accès aux nouvelles fonctionnalités | Aucune | Oui, selon la roadmap Next.js |
Ce tableau n'a rien de neutre : dans l'immense majorité des cas, différer la migration ne fait que déplacer le problème et l'aggraver. La seule exception légitime, c'est un projet en fin de vie lui-même, qu'on prévoit de décommissionner avant l'échéance, auquel cas la question ne se pose même pas.
Ce qu'il faut retenir
Trois points à garder en tête. D'abord, la date du 21 octobre 2026 n'est pas une rumeur : c'est le calendrier officiel de fin de vie de Next.js 15. Ensuite, l'audit préalable, Pages Router résiduel, dépendances tierces, cache, version Node, détermine 80 % du succès de la migration, bien avant d'écrire la moindre ligne de code. Enfin, une migration par palier avec environnement de test représentatif reste la méthode la plus sûre, même si elle prend plus de temps qu'un saut direct.
Si votre équipe hésite encore sur le calendrier ou sur l'ampleur du chantier, on avait détaillé une approche similaire de montée de version dans notre article sur TypeScript 7.0 et le compilateur natif en Go, les mêmes principes d'audit et de palier s'appliquent.
Questions fréquentes
Que se passe-t-il concrètement si on reste sur next.js 15 après le 21 octobre 2026 ?
L'application continue de fonctionner normalement. Le risque, c'est l'absence de correctif en cas de faille de sécurité découverte après cette date, et une non-conformité potentielle lors d'audits fournisseurs qui vérifient le support actif des dépendances critiques.
Combien de temps prend une migration de next.js 15 vers next.js 16 ?
Ça dépend entièrement de la taille et de la complexité de l'application. Un site vitrine simple peut basculer en un sprint ; une application avec des Server Actions complexes et un Pages Router résiduel peut demander plusieurs sprints répartis sur quelques semaines.
Faut-il migrer directement vers next.js 16 si on est encore sur next.js 13 ?
Non, mieux vaut passer par Next.js 15 en premier, stabiliser, puis enchaîner. Un saut de version isolé est plus facile à déboguer qu'un cumul de plusieurs montées majeures en une seule fois.
Les codemods officiels suffisent-ils pour migrer sans intervention manuelle ?
Non. Les codemods automatisent une partie du travail, renommages d'imports, ajustements de configuration, mais ne couvrent jamais les cas métier spécifiques, notamment autour du cache et des Server Actions. Un passage manuel reste indispensable.
Comment tester une migration next.js sans risquer la production ?
En créant un environnement de preview isolé avec un jeu de données réaliste, en lançant un build de production complet (next build), et en gardant l'ancienne version déployable en rollback pendant au moins deux semaines après la bascule.
