Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- La fin de vie (EOL) de Nuxt 3 est prévue pour le 31 juillet 2026, date à laquelle les correctifs de sécurité pour le framework, Nitro, h3, l'intégration de Vue 3 et les dépendances intégrées cesseront d'être fournis.
- Pour les applications Nuxt 3 en bon état de fonctionnement sur une version récente de Node.js, la mise à niveau vers Nuxt 4 est vraiment simple. L'équipe Nuxt l'a conçue ainsi, avec une compatibilité optionnelle à partir de la version 3.12 et des outils de modification du code qui automatisent la majeure partie du travail.
- Trois situations font du support prolongé un choix plus judicieux que la mise à niveau : une décision stratégique de ne pas passer par Nuxt 4 et d'attendre Nuxt 5, des environnements soumis à des exigences de conformité qui ne permettent pas de fenêtres de migration, et une longue liste de modules Nuxt tiers qui n'ont pas encore été mis à jour vers la version 4.
Si vous utilisez Nuxt 3 en production, la date de fin de vie fixée au 31 juillet 2026 n’a probablement pas suscité la même panique que d’autres échéances liées à des frameworks. Tant mieux. Et c’est normal. L’équipe Nuxt a fait preuve de transparence quant à ce qu’implique la mise à niveau, et pour la plupart des applications, il s’agit d’un travail limité.
Cela dit, l'expression « la plupart des applications » revêt une importance particulière dans cette phrase. Il existe de réelles raisons pour lesquelles une équipe pourrait estimer que passer à Nuxt 4 dès maintenant n'est pas la bonne décision. Cet article traite de ces raisons et des options qui s'offrent à vous si vous vous trouvez dans l'une de ces situations.
Comment fonctionne réellement le système de gestion des versions de Nuxt
Politique de support de Nuxt : chaque version majeure bénéficie d'au moins six mois de support technique après la sortie de la version majeure suivante. Les correctifs sont publiés environ une fois par semaine et les versions mineures environ une fois par mois, les modifications importantes étant réservées aux versions majeures.
Nuxt 3 est disponible depuis novembre 2022, s'inscrivant dans le cadre d'une modernisation plus large de l'écosystème à la suite de la fin de vie (EOL) de Vue 2. Nuxt 4 est devenu la version majeure actuelle à la mi-2025. La fin de vie initiale de Nuxt 3 était fixée au 31 janvier 2026, mais l'équipe Nuxt l'a prolongée en réponse aux commentaires de la communauté, la date butoir étant désormais fixée au 31 juillet 2026. Après cette date, la version 3.x ne recevra plus de mises à jour.
Nuxt 5 est en cours de développement. Nitro v3 et h3 v2 sont presque prêts. Une fois que Nuxt 5 sera disponible, Nuxt 4 arrivera en fin de vie six mois plus tard. Ce calendrier est important pour la suite de cette discussion.
Ce que signifie réellement la fin de vie (EOL) de Nuxt 3
Après la date de fin de vie (EOL) de Nuxt 3, fixée au 31 juillet 2026, l'équipe Nuxt cessera de publier des correctifs de sécurité pour la version 3.x. Les vulnérabilités (CVE) divulguées après cette date ne feront l'objet d'aucun correctif en amont.
L'historique des vulnérabilités CVE de Nuxt 3 est bien réel, et non pas théorique. Voici trois exemples tirés des 18 derniers mois qui illustrent le type de problèmes pouvant survenir dans n'importe quel framework de production :
CVE-2025-27415 (CVSS 7,5, Risque élevé) : Une faille de type « cache poisoning » dans le CDN affectant les versions de Nuxt allant de 3.0.0 à 3.16.0. Un pirate envoie une requête du type https://yoursite.com/?/_payload.json. Nuxt renvoie une réponse au format JSON. Si la clé de mise en cache de votre CDN ne tient pas compte des chaînes de requête, ce JSON est mis en cache par rapport à l'URL de base et servi aux visiteurs légitimes, ce qui donne l'impression que votre site est hors service. Cette attaque ne nécessite aucune authentification et peut être automatisée pour maintenir une indisponibilité persistante. Problème corrigé dans Nuxt 3.16.0.
CVE-2024-34343 (CVSS 5.1, Risque modéré) : Une faille de type « cross-site scripting » dans navigateTo. La fonction a tenté de bloquer le javascript: protocole, mais s'appuyait sur une logique d'analyse qui renvoyait des valeurs vides pour les URL mal formées, ce qui permettait de contourner la vérification du protocole. Problème corrigé dans Nuxt 3.12.4.
CVE-2024-34344 (CVSS 8,8, Risque élevé) : Exécution de code à distance via le navigateur lors de l'exécution locale de Nuxt en mode test. Le NuxtTestComponentWrapper chargement de chemins d'accès aux composants sans validation suffisante, permettant à une page Web malveillante, ouverte dans le même navigateur, de déclencher du code JavaScript arbitraire sur le serveur de test. Problème corrigé dans la version 3.12.4.
Ces failles ont été détectées et corrigées pendant la période de support actif. La prochaine faille présentant un niveau de gravité similaire après le 31 juillet 2026 ne le sera pas.
Dans les environnements réglementés, cela devient un problème de conformité avant même d'être un problème de sécurité. La norme PCI DSS exige que les vulnérabilités à haut risque soient corrigées dans les 30 jours suivant leur divulgation. Les auditeurs SOC 2 signalent les logiciels non pris en charge dans les environnements de production. Les environnements FedRAMP considèrent les composants en fin de vie (EOL) comme des non-conformités.
La face cachée : l'arborescence des dépendances de Nuxt
Une application Nuxt 3 en production ne s'exécute pas à partir d'un seul paquet. Par défaut, nuxt L'installation inclut :
- Vue 3 et le
@vue/*les paquets en tant que couche de rendu - Nitro comme moteur de serveur
- h3 en tant que framework HTTP sous-jacent à Nitro
- Vite comme outil de compilation
- L'écosystème unjs (
ufo,c12,consola,defu,hookable,jiti, entre autres) pour les services communs - Le
@nuxt/*paquets de base (@nuxt/kit,@nuxt/schema,@nuxt/vite-builder,@nuxt/devtools)
Chacun de ces paquets s'appuie sur sa propre chaîne de dépendances. L'arborescence complète d'une application Nuxt 3 comprend des centaines de paquets. Toute vulnérabilité CVE présente dans cette arborescence, qu'elle soit directe ou transitive, constituera une faille de sécurité qui ne sera plus corrigée en amont après la fin de vie (EOL) de Nuxt 3, le 31 juillet 2026.
La vulnérabilité de type « cache poisoning » mentionnée ci-dessus se trouvait dans le cœur du système de gestion des requêtes de Nuxt. Le navigateTo La vulnérabilité CVE résidait dans l'interaction entre Nuxt et un utilitaire unjs. L'exposition à l'EOL touche l'ensemble de cette surface intégrée, et pas seulement le nuxt le paquet lui-même. Un correctif appliqué uniquement au framework ne sert à rien si la prochaine faille apparaît dans Nitro ou dans l'un des paquets unjs.
Modules optionnels installés séparément (@nuxt/image, @nuxt/content, @nuxt/ui, modules communautaires de @nuxtjs/* (et ailleurs) ne font pas partie de cet ensemble. Elles ont leurs propres calendriers de publication et leurs propres historiques CVE, et nécessitent une stratégie de correctifs spécifique.
Vos options à l'approche de la fin de vie de Nuxt 3
Trois voies possibles, chacune présentant des arguments clairs qui permettent de déterminer quand elle est la bonne.
Option 1 : Passer à Nuxt 4
Pour la plupart des équipes, c'est la bonne solution. L'équipe Nuxt a conçu Nuxt 4 spécialement pour faciliter cette migration. Vous pouvez adopter le comportement de Nuxt 4 à partir de la version 3.12 de Nuxt en utilisant compatibilityVersion: 4 dans votre nuxt.config.ts, testez en environnement isolé et effectuez la migration à votre rythme. Les outils de conversion de code officiels automatisent la restructuration des répertoires pour app/, les changements de nom des API et le passage à une réactivité superficielle pour useFetch.
Selon l'évaluation publiée par l'équipe Nuxt elle-même, la plupart des projets Nuxt 3 peuvent être mis à niveau avec un minimum d'efforts. Cela correspond aux retours des équipes qui ont déjà effectué cette mise à niveau.
Ce que vous devez réellement prévoir dans votre budget :
- Node.js 18.20 au minimum. Si votre chaîne d'outils est bloquée sur une version antérieure, cette migration est obligatoire.
- La réorganisation du répertoire vers
app/. Le codemod se charge de l'aspect technique. Il vous faudra toutefois vérifier les modèles de surveillance, les configurations de couches et les chemins d'accès personnalisés. - Réactivité superficielle par défaut.
useFetchetuseAsyncDataDans Nuxt 4, les données sont réactives en surface. Le code qui repose sur une réactivité profonde nécessite une activation explicite. - Compatibilité des modules. Propre
@nuxt/*Les modules sont à jour. Les modules communautaires varient. - Vérification de l'infrastructure de test.
Pour une application bien entretenue, fonctionnant sous une version récente de Node.js et comportant peu de modules, cela prend quelques jours, et non plusieurs semaines. Si cette section existe plutôt que de simplement vous renvoyer vers le guide de mise à jour, c'est parce que la description « bien entretenue, version récente de Node.js, peu de modules » ne s'applique pas à toutes les applications Nuxt 3 en production.
Option 2 : Migrer vers un autre cadre
Si vous envisagez déjà d'adopter un autre modèle de rendu ou un autre moteur d'exécution, la fin de vie de Nuxt 3 constitue un facteur déterminant pour prendre cette décision. Les options viables pour les équipes Vue sont plus limitées que pour les équipes React. Vous pouvez passer à Vue 3 « pur » avec Vite pour les applications SPA, opter pour Astro pour les sites riches en contenu, ou changer complètement d'écosystème.
Chacune de ces options implique les coûts habituels liés à la migration de framework : réécriture des composants, remplacement du routage et de la récupération des données, refonte de l'infrastructure de test et abandon de l'écosystème de modules spécifiques à Nuxt. Pour la plupart des équipes utilisant Nuxt 3 en production, le rapport coût-bénéfice ne plaide pas en faveur de cette voie. Elle est mentionnée ici par souci d'exhaustivité plutôt que comme une recommandation probable.
Option 3 : Assistance étendue avec TuxCare ELS
C'est l'option qui s'impose dans trois situations précises.
La stratégie consistant à passer directement de Nuxt 4 à Nuxt 5. L'équipe Nuxt a clairement indiqué que Nuxt 4 était une version de transition. Nuxt 5 intègre Nitro 3, l'API Environment de Vite 6 et des mises à jour des composants internes de h3. Le nombre de changements incompatibles entre la version 4 et la version 5 est plus important qu'entre la version 3 et la version 4. De plus, Nuxt 4 arrivera en fin de vie six mois après la sortie de Nuxt 5.
Si vous passez à la version 3 ou 4 dès maintenant, vous vous engagez à effectuer un nouveau cycle de migration dès que Nuxt 5 sera disponible. L'équipe Nuxt a indiqué que Nuxt 5 était en cours de développement et que Nuxt 4 arriverait en fin de vie six mois après la sortie de Nuxt 5. Concrètement, cela représente deux migrations en production dans un délai relativement court.
L'autre option consiste à rester sur Nuxt 3 avec la prise en charge d'ELS, à ignorer complètement Nuxt 4 et à passer directement de la version 3 à la version 5 une fois que Nuxt 5 sera stabilisé. Une seule migration au lieu de deux. La question qui se pose alors est de savoir si ELS est plus économique qu'une mise à niveau intermédiaire superflue, ce qui est clairement le cas pour la plupart des équipes en entreprise.
Environnements soumis à des exigences de conformité. Les normes PCI DSS, SOC 2, FedRAMP et autres cadres similaires exigent la preuve que les logiciels sont mis à jour et pris en charge. Elles ne tiennent pas compte d’un projet de migration de six semaines simplement parce que l’auditeur est arrivé. Si votre période d’audit tombe pendant la phase post-fin de vie (EOL) et que votre environnement ne peut pas mener à bien une migration vers Nuxt 4 dans ce délai, ELS fournit la source des correctifs et la trace documentaire nécessaires pour satisfaire aux exigences de contrôle.
Cela concerne également les environnements où les versions de Node.js sont verrouillées, les applications déployées par les clients ou en marque blanche pour lesquelles il n'est pas possible d'imposer des mises à jour de version, ainsi que tout contexte où le risque lié au changement doit être étalé dans le temps plutôt que pris en charge en une seule fois.
Retard de l'écosystème des modules. Lors de la sortie de Nuxt 4, le noyau @nuxt/* Les paquets ont été mis à jour sans problème. La mise à jour des modules propriétaires et communautaires facultatifs a pris plus de temps, et certains n’ont toujours pas été migrés. Si votre application dépend d’un grand nombre de ces modules, vous risquez d’être bloqué par des responsables de maintenance sur lesquels vous n’avez aucune emprise, jusqu’à ce qu’ils assurent la compatibilité avec Nuxt 4.
ELS pour Nuxt 3 assure la sécurité du framework et de ses dépendances intégrées pendant que vous attendez. Il n'applique pas de correctifs aux modules optionnels ou communautaires eux-mêmes, qui restent sous la responsabilité de leurs mainteneurs ou de votre propre équipe. Il permet simplement de supprimer la pression exercée par le framework pour que vous migriez avant que les dépendances de vos modules ne soient prêtes.
Aucun de ces cas ne s'applique à toutes les applications Nuxt 3. Ces trois cas sont bien réels, et chacun d'entre eux constitue une raison valable de planifier la fin de vie (EOL) de Nuxt 3 en s'appuyant sur le support prolongé, plutôt que de se précipiter dans une migration qui ne correspond pas à la situation de l'équipe.
Ce que TuxCare ELS apporte à Nuxt 3
Le support à vie proposé par TuxCare pour Nuxt 3 EOL garantit la poursuite de la mise à jour des correctifs de sécurité après la date butoir du 31 juillet 2026. La couverture inclut nuxt paquet, ses dépendances directes et leurs chaînes transitives : Vue 3 et le @vue/* paquets, Nitro, h3, Vite, le @nuxt/* les paquets de base, les utilitaires de l'écosystème unjs et les paquets plus complexes sur lesquels ceux-ci s'appuient. Les correctifs sont fournis via les workflows npm standard.
Modules optionnels installés séparément (@nuxt/image, @nuxt/content, @nuxt/ui, @nuxtjs/*, modules communautaires) ne font pas partie de l'étendue par défaut.
Voici quelques éléments qui constituent la norme TuxCare pour l'ensemble de la gamme ELS :
- Processus de correction. TuxCare surveille le NVD, les avis de sécurité GitHub et les canaux des éditeurs. Lorsqu’une vulnérabilité CVE affectant des paquets concernés est signalée, les correctifs rétroportés sont soumis au processus combiné d’automatisation et de révision par des experts de TuxCare. Chaque correctif est testé pour vérifier son intégrité, son bon fonctionnement et l’absence de régression avant d’être déployé dans vos dépôts.
- Mode de livraison. Les correctifs sont distribués via des référentiels compatibles npm hébergés par TuxCare. Aucune modification de l'infrastructure CI/CD, aucun nouvel outil, aucune refonte du pipeline de compilation.
- Documentation relative à la conformité. Chaque version comprend un relevé des vulnérabilités CVE corrigées et des paquets modifiés, conforme aux exigences en matière de preuves des normes PCI, SOC 2 et FedRAMP.
- Réponse conforme au SLA. Les vulnérabilités CVE critiques et à haut risque (CVSS 7.0+) font l'objet d'un délai de résolution défini.
Pour plus de détails techniques sur le processus de correction de TuxCare, le livre blanc consacré à la correction des logiciels libres en traite de manière exhaustive : « TuxCare Open Source Patching Process ».
Le bilan en toute honnêteté
Pour la plupart des applications Nuxt 3, passer à Nuxt 4 est la bonne décision. La migration est bien prise en charge et l'équipe Nuxt a fait le nécessaire pour la rendre facile à gérer.
Une prise en charge étendue est disponible pour les applications qui n'en bénéficient pas. Il s'agit notamment des équipes qui ont délibérément choisi de ne pas passer à Nuxt 4 et d'attendre Nuxt 5, des applications soumises à des délais de conformité qui ne permettent pas de migration, ou encore des bases de code dépendantes de modules communautaires qui n'ont pas encore rattrapé leur retard. Si votre situation correspond à l'un de ces cas, ELS vous offre un niveau de sécurité minimum en attendant le moment opportun ou la mise à jour en amont appropriée.
L'erreur consiste à considérer la date de fin de vie de Nuxt 3 comme une échéance impérative, alors qu'elle ne l'est pas. L'équipe Nuxt a conçu un processus de mise à niveau fluide. Elle a également clairement indiqué que Nuxt 4 est une version de transition et que Nuxt 5 est en préparation. Ces deux éléments doivent être pris en compte dans la décision de votre équipe, et non pas un seul.
Pour savoir si le service ELS pour Nuxt 3 est adapté à votre environnement, consultez la page « Endless Lifecycle Support for Nuxt » de TuxCare ou contactez-nous pour discuter de votre infrastructure.
