Ce que change réellement la fin de vie de Node.js 20
Node.js suit un cycle public : une ligne paire entre en Active LTS en octobre, passe en Maintenance LTS un an plus tard, puis s'arrête. Node.js 20 est entré en Maintenance LTS le 22 octobre 2024 et a atteint sa fin de vie le 30 avril 2026. Depuis, une faille du runtime n'est plus corrigée en amont : ni dans le moteur V8, ni dans la bibliothèque TLS embarquée, ni dans le parseur HTTP. Le code tourne toujours, mais chaque vulnérabilité publiée y reste ouverte.
Ce que coûte un runtime figé
- Failles non corrigées — les vulnérabilités publiées après le 30 avril 2026 ne recevront plus de correctif amont ; seule une montée de version les referme.
- Paquets qui décrochent — les mainteneurs relèvent le champ
enginesde leurpackage.jsonvers les lignes encore supportées ; une installation neuve finit par échouer ou par vous figer sur d'anciennes versions. - Images de base immobiles — une image
node:20ne reçoit plus de correctif, ni pour le runtime ni pour les paquets système en dessous ; votre analyse de vulnérabilités le signale à chaque build. - Audits qui coincent — un runtime en fin de vie est un risque non accepté dans les revues de sécurité et les questionnaires fournisseurs.
- Migration d'urgence — plus l'écart grandit, plus la bascule coûte cher ; la conduire aujourd'hui est un chantier planifié, la subir après un incident ne l'est plus.
Savoir ce que vos serveurs exécutent vraiment
node -v dans un shell ne dit qu'une partie de l'histoire : le binaire de votre session n'est pas forcément celui qui sert la production. Un gestionnaire de processus garde la version avec laquelle il a démarré, nvm en installe plusieurs par utilisateur, un Dockerfile fige la sienne dans un FROM node:20. Recensez chaque source : pm2 jsonlist pour les process vivants, un grep -r 'FROM node' sur vos Dockerfiles, le champ engines de chaque package.json, et la version épinglée en CI ou dans vos runtimes managés.
Migrer sans casser la production
Dresser l'inventaire avant de toucher au reste
Listez, application par application : la version réellement exécutée, le gestionnaire de processus, l'image de base, et les dépendances natives — node-gyp, sharp, better-sqlite3. Ce sont elles qui fixent le calendrier, pas votre code : un module compilé sans binaire prêt pour la nouvelle ligne bloque toute la bascule.
Choisir la version cible
Node.js 24 est en Active LTS depuis le 28 octobre 2025 et sa fin de vie est fixée au 30 avril 2028 : c'est la cible par défaut. Node.js 22, en Maintenance LTS depuis le 21 octobre 2025, est supporté jusqu'au 30 avril 2027 — un palier acceptable si une dépendance native ne suit pas encore, jamais une destination. Node.js 26 n'entre en LTS que le 28 octobre 2026 : pas en production aujourd'hui.
Rejouer la suite de tests sur la version cible
Ajoutez la version cible à la matrice de votre CI avant de retirer l'ancienne : les deux doivent passer au vert en même temps. Réinstallez à froid (rm -rf node_modules puis npm ci) pour forcer la recompilation des modules natifs : c'est là qu'apparaissent les ruptures, rarement dans les tests unitaires. Lisez les avertissements de dépréciation — ce sont les erreurs de la ligne suivante.
Basculer un service à la fois
nvm install 24 installe la nouvelle ligne à côté de l'ancienne sans la retirer. Relancez ensuite le daemon du gestionnaire de processus (pm2 update) puis recréez le service (pm2 delete puis pm2 start) : un simple pm2 restart conserve l'interpréteur enregistré. Régénérez le script de démarrage (pm2 startup, pm2 save), puis vérifiez avec pm2 jsonlist que la version rapportée a changé.
Surveiller, puis nettoyer
Gardez les logs d'erreur et la courbe mémoire sous les yeux 48 heures : un changement de ligne V8 déplace le profil du ramasse-miettes plus souvent qu'il ne casse une API. Une fois la bascule confirmée, désinstallez Node.js 20 pour qu'aucun déploiement ne le rappelle par accident. Si vous préférez repartir d'un serveur propre plutôt que migrer sur place, notre guide deployer-nodejs-vps reprend la chaîne complète.
Épingler la version, pas seulement la migrer
Une montée de runtime est le bon moment pour resserrer ce qui l'entoure. Épinglez la version cible dans un .nvmrc versionné avec le code et alignez le champ engines de votre package.json : le serveur, la CI et les postes de développement cessent de diverger en silence — c'est cette dérive qui laisse un runtime en fin de vie survivre à sa propre migration. Faites tourner l'application sous un utilisateur dédié, sans droit d'écriture sur son dossier de code.
Faire de la fin de vie un rendez-vous, pas une surprise
Le calendrier de Node.js est public : une ligne paire devient LTS en octobre, puis s'arrête trente mois plus tard, toujours un 30 avril. Node.js 22 s'arrêtera le 30 avril 2027, Node.js 24 le 30 avril 2028 : ces deux échéances peuvent entrer dès aujourd'hui dans votre calendrier d'exploitation. Récurrente et budgétée, la montée de version tient en quelques jours par an ; subie dans l'urgence, elle coûte bien davantage.
