Nuxt 3 est en fin de vie depuis le 31 juillet 2026. Ce que cela change vraiment

  • vuetelemetry
  • Actu
  • 8 min de lecture

Nuxt 3 ne reçoit plus de mises à jour de sécurité depuis le 31 juillet 2026. Ce que la fin de vie signifie en pratique, pourquoi la date avait déjà été repoussée une fois, la commande officielle de mise à niveau et les codemods qui font une partie de la migration à votre place.

**Nuxt 3 a atteint sa fin de vie le 31 juillet 2026.** L'annonce vient de Daniel Roe, mainteneur principal du framework, dans la version 4.3.0 publiée le 22 janvier 2026. Si vous faites tourner une application Nuxt 3 en production, cette date est désormais passée.

La première chose à poser clairement, c'est ce que la fin de vie ne signifie **pas**. Rien ne casse. Votre application ne s'est pas arrêtée le 1er août, aucun paquet n'a été dépublié, et `npm install` fonctionne toujours. Une fin de vie est un engagement de support qui s'achève, pas un interrupteur.

Ce que la fin de vie signifie vraiment

Un poteau de bois portant deux panneaux fléchés en sens opposés, sur fond de ciel bleu. Rester sur une version sans support et migrer sont deux choix réels, mais un seul continue de recevoir des correctifs de sécurité.
Un poteau de bois portant deux panneaux fléchés en sens opposés, sur fond de ciel bleu. Rester sur une version sans support et migrer sont deux choix réels, mais un seul continue de recevoir des correctifs de sécurité.

Ce qu'elle signifie, c'est que **Nuxt 3 ne reçoit plus ni mise à jour de sécurité ni correction de bug critique**. Toute vulnérabilité divulguée à partir de maintenant sera corrigée dans la branche 4 et non rétroportée. C'est tout, et c'est suffisant : un framework non corrigé sur le chemin des requêtes d'une application publique est une dette qui grandit en silence, au calendrier de quelqu'un d'autre que le vôtre.

Il y a dans cette histoire un détail qui mérite plus d'attention qu'il n'en reçoit, parce qu'il dit quelque chose de la migration elle-même. **La date de fin de vie initiale était le 31 janvier 2026.** Les mainteneurs ont ouvert une discussion pour savoir comment se passait réellement le passage de la version 3 à la version 4, et ce qu'ils ont entendu les a conduits à prolonger le support de six mois, en continuant les mises à jour de sécurité et les correctifs critiques au-delà de la date déjà annoncée.

C'est une équipe de mainteneurs qui se comporte bien, et c'est aussi un signal à lire sans détour : la mise à niveau était assez difficile, pour assez de monde, pour justifier de déplacer une échéance publiée. Si vous la repoussez depuis des mois, vous n'êtes pas seul et le projet le savait.

L'échéance qui a déjà bougé une fois

Le corollaire est moins confortable. **Le report a été utilisé.** Une échéance déjà déplacée une fois, à la suite d'une consultation publique, n'est pas une échéance dont on peut attendre qu'elle bouge une seconde fois. Compter dessus reviendrait à compter sur la bonne volonté.

  • `nuxt/4/file-structure` - les changements d'arborescence introduits en version 4
  • `nuxt/4/default-data-error-value` - la nouvelle valeur par défaut de data et error
  • `nuxt/4/deprecated-dedupe-value` - suppression des valeurs de dedupe obsolètes
  • `nuxt/4/shallow-function-reactivity` - réactivité superficielle pour les fonctions
  • `nuxt/4/absolute-watch-path` - les chemins surveillés deviennent absolus
  • `nuxt/4/template-compilation-changes` - changements dans la compilation des templates

De l'autre côté de la migration, la version stable actuelle est **Nuxt 4.5.1**. La mise à niveau commence par une seule commande, que la documentation donne pour chaque gestionnaire de paquets : `npx nuxt upgrade`, ou ses équivalents `yarn`, `pnpm`, `bun x` et `deno x`.

Cette commande déplace la dépendance. Elle ne réécrit pas votre code, et c'est là que se trouve l'essentiel du travail réel. Nuxt publie des **codemods officiels** pour cette partie, réunis dans une recette de migration unique : `npx codemod@0.18.7 nuxt/4/migration-recipe`. Notez la version épinglée. La documentation la fige délibérément au lieu d'utiliser `@latest`, pour que la transformation exécutée soit celle qui a été testée contre cette migration.

La recette regroupe plusieurs codemods individuels, et il vaut la peine de les connaître séparément, car une base de code volumineuse demande souvent de les appliquer un par un plutôt que d'un bloc. Les voici.

La recette regroupe plusieurs codemods individuels, et il vaut la peine de les connaître séparément, car une base de code volumineuse demande souvent de les appliquer un par un plutôt que d'un bloc. Les voici.

- vuetelemetry

Migrer : la commande et les codemods

Rien de tout cela ne rend la migration automatique. Les codemods traitent les changements mécaniques, reconnaissables à un motif ; ils ne raisonnent pas sur votre application, vos modules, ni sur les paquets tiers de votre arbre de dépendances, qui ont leurs propres calendriers de compatibilité. Prévoyez du temps pour ce qu'un outil ne peut pas voir. Mais la partie mécanique est réellement couverte, et c'est justement celle que l'on croit le plus souvent devoir faire à la main.

Stack liée