Node.js 27 : une seule version majeure par an dès 2027

Node.js change de rythme. À partir de Node.js 27, le projet ne publiera plus qu'une seule version majeure par an, et chacune deviendra LTS. Le canal alpha de Node.js 27 ouvre le 28 octobre 2026, pour une version stable attendue le 22 avril 2027. Cette réforme met fin à la distinction entre versions paires et impaires héritée de la fusion avec io.js en 2015. Elle est expliquée par le projet dans son annonce officielle et résumée par InfoQ.

Calendrier de Node.js 27 : alpha, Current, LTS

Le nouveau cycle comporte trois phases enchaînées, que le tableau ci-dessous résume pour Node.js 27.

Phase.	Période.	Rôle.
Alpha.	D'octobre 2026 à mars 2027, environ six mois.	Tests précoces, changements majeurs de compatibilité autorisés.
Current.	D'avril à octobre 2027, environ six mois.	Version stable, publiée le 22 avril 2027.
LTS.	À partir d'octobre 2027, pendant 30 mois.	Support long, recommandé pour la production.

Les numéros de version suivent désormais l'année civile de la sortie en phase Current : 27.0.0 en 2027, 28.0.0 en 2028. Les versions alpha utilisent le format de préversion de semver, par exemple 27.0.0-alpha.1. Pour un projet qui s'appuie sur Node.js, le développeur Node.js freelance que vous mandatez doit maîtriser ce calendrier.

Ce qui change avec la fin des versions paires et impaires

Jusqu'ici, seules les versions paires devenaient LTS. Les équipes devaient savoir quelle version choisir pour la production et laisser les versions impaires aux essais. Avec le nouveau modèle, chaque version majeure suit le même parcours, et le choix devient plus simple : on attend la phase LTS.

Pourquoi le projet change son rythme.

Node.js est maintenu en grande partie par des bénévoles. Entretenir en parallèle plusieurs lignes de version, avec des correctifs à reporter sur chacune, représente une charge réelle. Passer à un flux unique réduit ce travail sans retirer l'essentiel : la version que la plupart des équipes utilisaient déjà en production était la ligne paire en LTS.

Quoi faire sur vos projets Node.js dès maintenant

Node.js 26, publié en mai 2026, passe en LTS actif le 28 octobre 2026, comme dernière version régie par l'ancien système. C'est la cible raisonnable pour la production actuelle. Pour préparer l'arrivée de Node.js 27, quelques actions suffisent.

• Vérifier la version de Node.js utilisée en développement, en intégration continue et en production.
• Planifier le passage vers Node.js 26 si vous êtes sur une version plus ancienne, en suivant notre guide de migration vers Node.js 26.
• Tester Node.js 27 en alpha sur une branche, sans le déployer en production.
• Contrôler la compatibilité des dépendances natives, qui cassent le plus souvent lors d'un changement de version.

Effets sur les pipelines, Docker et la maintenance

Un cycle annuel simplifie la planification. Une équipe peut prévoir une montée de version par an, au moment où la nouvelle ligne devient LTS, au lieu de suivre deux lignes avec des rythmes différents. Cela facilite aussi la communication avec les clients : un seul rendez-vous annuel pour la mise à jour de l'environnement d'exécution.

• Figer la version dans les images Docker et dans la configuration de l'intégration continue.
• Prévoir dans le calendrier du projet une fenêtre annuelle de montée de version, après le passage en LTS.
• Tester les dépendances natives et les outils de build à chaque changement de version majeure.
• Surveiller les dates de fin de support de la version utilisée, pour ne jamais rester sans correctifs de sécurité.

Une règle simple pour les équipes.

N'utilisez jamais une version alpha ou Current en production. Servez-vous-en pour tester vos dépendances et anticiper les changements, puis attendez la phase LTS pour déployer. Avec le nouveau calendrier, cette règle devient plus claire encore, puisque toutes les versions finissent par devenir LTS.

Ce que cela change pour le choix d'un prestataire

Un prestataire sérieux doit connaître le calendrier de support des versions qu'il livre et vous indiquer la date de fin de support de votre environnement d'exécution. Il doit aussi proposer un plan de mise à jour, plutôt que de laisser l'application vieillir jusqu'à la prochaine faille. Posez la question lors de la signature d'une mission : quelle version, pour combien de temps, et qui assure la mise à jour ?

Pensez aussi à la documentation du projet. Notez dans le dépôt la version cible, la date de fin de support et la procédure de montée de version. Ce petit fichier évite que la connaissance reste dans la tête d'une seule personne, et il accélère le prochain changement, qu'il soit fait par vous ou par un prestataire.

Les équipes qui hébergent plusieurs applications ont intérêt à harmoniser leurs versions. Un parc homogène, tenu sur la même ligne LTS, se met à jour en une seule opération au lieu d'une série de chantiers distincts.

Votre application dépend de Node.js et vous voulez vérifier sa feuille de route ? Contactez-moi pour un point rapide sur vos versions et votre plan de mise à jour.

Sources

Les faits de cet article proviennent des publications suivantes, consultées en octobre 2026.

• Node.js : annonce officielle du nouveau calendrier de versions.
• InfoQ : Node.js passe à une version majeure par an.
• BEX : passage de Node.js 26 en LTS actif.
• DEV Community : lecture du changement par la charge des mainteneurs.