Le 29 octobre 2026, l’équipe de publication de Node.js a mis en ligne une version que peu de développeurs avaient déjà vue passer : Node.js 27.0.0-alpha. Ce n’est pas une version de production, et le projet le dit noir sur blanc. C’est en revanche le premier pas visible d’un changement de rythme décidé au printemps : à partir de la ligne 27, Node.js ne sortira plus qu’une version majeure par an, et chacune deviendra une version LTS.
Pour une équipe qui forme, recrute ou maintient des applications JavaScript côté serveur, ce calendrier compte davantage que la liste des nouveautés. Voici ce qui change, et ce qu’il est raisonnable de faire dès maintenant.
Plan de l'article
Une majeure par an, fini la distinction pair/impair #
Jusqu’ici, Node.js publiait deux versions majeures par an. Les numéros pairs devenaient LTS (support long), les impairs restaient des versions « Current » de courte durée, utiles pour tester mais rarement déployées. Le billet officiel « Evolving the Node.js Release Schedule » acte la fin de ce modèle : « Starting with 27.x, Node.js will move from two major releases per year to one. » Et plus loin : « Every release becomes LTS. No more odd/even distinction. »
À lire Gemini 4 Carbon : Google réserve son modèle le plus puissant à la cyberdéfense
Node.js 26 est donc la dernière ligne publiée selon l’ancien modèle. Node.js 27 est la première du nouveau.
Les quatre phases d’une version
Le cycle de vie est désormais découpé en quatre temps, selon le même billet :
Alpha, pendant six mois, d’octobre à mars : c’est la période où les changements cassants (semver-major) sont encore acceptés. Current, pendant six mois, d’avril à octobre : la version se stabilise. LTS, pendant 30 mois, avec les correctifs de sécurité. Puis la fin de vie. Au total, une version est soutenue 36 mois à partir de sa première sortie Current.
Pour Node.js 27, cela donne une alpha ouverte en octobre 2026, une version 27.0.0 attendue en avril 2027, un passage en LTS en octobre 2027 et une fin de vie en avril 2030. Le projet précise que ce calendrier « n’est pas définitif » et peut encore être ajusté.
À lire Bun 1.4.4 intègre un formateur compatible Prettier et une vérification de types
Des numéros calés sur l’année
Autre détail qui facilitera les conversations en équipe : le numéro de version correspond désormais à l’année de la première sortie Current. Node.js 27 sortira en 2027, Node.js 28 en 2028. Plus besoin de se demander si « la 25 » était une LTS.
Ce que contient déjà l’alpha #
Les notes de version de la 27.0.0-alpha, signées par Rafael Gonzaga, donnent une bonne idée de ce qui attend les projets en 2027. Quelques points méritent l’attention dès aujourd’hui.
Un moteur V8 qui change de génération
Le moteur V8 passe en version 15.6, contre 14.6 dans Node.js 26. Il active par défaut Math.sumPrecise() et Iterator.zip(). Surtout, la limite de mémoire par défaut change quand --max-old-space-size n’est pas fixé : elle vaut la moitié de la mémoire physique, bornée entre 256 Mo et 4 Go, et les Buffer comptent désormais dans ce plafond. Les notes recommandent de fixer explicitement l’option si l’on dépendait de l’ancien comportement. Un service qui tourne dans un conteneur aux limites serrées est directement concerné.
Autre point sensible : structuredClone(), postMessage() et v8.serialize() utilisent un nouveau format que les anciennes versions de Node.js ne savent pas relire. Si deux services échangent des données sérialisées par V8 et ne migrent pas en même temps, il faudra le prévoir.
Crypto, HTTP et API retirées
Côté chiffrement, OpenSSL 3 au minimum devient obligatoire et Node.js adopte OpenSSL 4.1. Côté HTTP, le keepAliveTimeout par défaut passe à 65 secondes et req.headers n’a plus de prototype. Le module domain est déprécié à l’exécution, et le support de macOS sur processeurs Intel passe au statut expérimental. npm est livré en version 12.1. Le magazine Programmez! a résumé ces nouveautés le 30 octobre.
Que faire de cette alpha dans une équipe #
Le projet est clair sur la cible : l’alpha s’adresse aux auteurs de bibliothèques et aux chaînes d’intégration continue qui veulent tester la compatibilité avec les changements à venir. Elle n’est pas destinée à la production, et l’API peut encore bouger d’une alpha à l’autre. À la différence des builds « nightly », ces versions sont toutefois signées et étiquetées, ce qui les rend plus simples à intégrer proprement dans un pipeline.
Concrètement, trois gestes simples suffisent pour la plupart des équipes. Ajouter une tâche d’intégration continue non bloquante qui lance la suite de tests sous l’alpha, pour voir tôt ce qui casse. Vérifier les options de mémoire des services en conteneur, puisque le calcul par défaut change. Et repérer les dépendances qui utilisent encore domain ou des API marquées en fin de vie.
Et pour la formation ?
Pour un développeur qui se forme ou se reconvertit, le nouveau calendrier simplifie la règle à retenir : chaque année, une version sort au printemps et devient LTS à l’automne. Apprendre sur la dernière LTS reste le bon réflexe pour un projet réel. Suivre l’alpha est un excellent exercice pour comprendre comment un écosystème gère ses changements cassants, à condition de le faire dans un projet d’essai.
D’ici avril 2027, les alphas vont se succéder et la liste des changements va encore évoluer. Le document de référence reste le fichier schedule.json du dépôt de publication de Node.js, que le projet désigne lui-même comme la source qui fait foi.
