Pendant dix ans, le calendrier de Node.js tenait en une règle : deux versions majeures par an, les impaires vivant six mois, les paires devenant des versions à support long (LTS). Cette règle vit ses derniers jours. À partir de Node.js 27, le rythme devient annuel.
L’ancien modèle, jusqu’à Node.js 26
Jusqu’à Node.js 26 inclus :
- une nouvelle version majeure sortait en avril et une autre en octobre ;
- les versions impaires (23, 25…) n’étaient plus maintenues au bout de six mois ;
- les versions paires (22, 24, 26…) passaient en LTS active, puis en maintenance.
C’est ce qui explique que Node.js 25, sortie le 15 octobre 2025, soit déjà en fin de vie, alors que Node.js 24, sortie en mai 2025, est en LTS.
Le nouveau modèle, à partir de Node.js 27
D’après la page officielle des versions de Node.js :
- une seule version majeure par an ;
- chaque version passe par six mois de phase Alpha, puis six mois de phase Current ;
- toutes les versions passent ensuite en LTS, sans distinction paire/impaire ;
- une LTS garantit en général les correctifs critiques pendant 30 mois au total.
Fini le piège des versions impaires « éphémères » qu’on installait par erreur en production : chaque version majeure aura droit à son support long.
Où en sont les versions aujourd’hui
| Version | Statut |
|---|---|
| Node.js 20 | Fin de vie |
| Node.js 22 | LTS |
| Node.js 24 | LTS |
| Node.js 25 | Fin de vie |
| Node.js 26 | Current, passage en LTS attendu fin octobre 2026 |
La règle d’or ne change pas : en production, n’utilisez que des versions LTS (active ou maintenance). Une version « Current » sert à préparer la suite, pas à faire tourner votre application métier.
Ce que ça change concrètement
Moins de montées de version subies
Avec une seule version par an, il n’y a plus qu’une montée de version majeure annuelle à préparer. Pour une petite équipe, c’est un cycle plus simple à tenir : on teste la nouvelle version pendant sa phase Current, on bascule une fois qu’elle passe en LTS.
Un calendrier à caler
Profitez du changement pour formaliser votre cycle :
- Inventoriez les versions de Node.js utilisées en développement, en CI et en production. Elles divergent souvent.
- Fixez la version dans le projet : champ
enginesdupackage.json, fichier.nvmrcou.node-version, image Docker à version explicite (jamaislatest). - Programmez une revue annuelle : quand la nouvelle version passe en LTS, testez-la en CI, puis planifiez la migration.
- Sortez des versions en fin de vie : une application encore sur Node.js 20 ne reçoit plus de correctifs de sécurité.
Pour planifier une tâche de vérification récurrente sur vos serveurs, notre outil d’explication des expressions cron traduit une ligne de crontab en français et affiche ses prochaines exécutions.
Les dépendances suivront
Les bibliothèques de l’écosystème alignent souvent leur support sur les LTS de Node.js. Un cycle plus lisible devrait simplifier leur maintenance… et la vôtre.
Notre conseil
Si vos applications tournent sur Node.js 22 ou 24, rien ne presse : ce sont des LTS maintenues. Mettez simplement Node.js 26 à l’essai dans votre intégration continue dès maintenant, pour basculer sereinement une fois sa LTS active.
Et si vos outils internes reposent encore sur des versions abandonnées, c’est le bon moment pour faire le point : c’est précisément le genre de chantier de modernisation que nous accompagnons.
Source
- Node.js, « Previous releases » et calendrier des versions : https://nodejs.org/en/about/previous-releases
