Node.js 26 passe en LTS

Aujourd'hui, 28 octobre 2026, Node.js 26 entre en support à long terme, le statut « Active LTS » du calendrier officiel. Le même jour, Node.js 24 recule d'un cran et ne reçoit plus que des correctifs de sécurité et de bogues graves. Node.js 22, lui, est dans cette phase depuis un an et s'arrête le 30 avril 2027. Pour qui exploite une API NestJS, un site Next.js ou un bot en production, c'est le moment de l'année où l'on décide quelle version tournera jusqu'à l'été.

Cet article donne le calendrier exact, ce qu'apporte et ce que retire Node.js 26, et une méthode de migration qui tient compte de ce qui casse vraiment lors d'un changement de version majeure : les modules natifs et les images Docker, rarement le code applicatif.

Le calendrier, version par version

Les dates ci-dessous sont celles du fichier de calendrier publié par le projet Node.js, consulté ce 28 octobre.

Node.js 26 : sortie le 5 mai 2026, Active LTS depuis le 28 octobre 2026, maintenance à partir du 20 octobre 2027, fin de vie le 30 avril 2029. Le nom de code de la ligne n'était pas encore renseigné dans le calendrier au moment d'écrire.
Node.js 24 « Krypton » : Active LTS depuis le 28 octobre 2025, en maintenance depuis le 20 octobre 2026, fin de vie le 30 avril 2028.
Node.js 22 « Jod » : en maintenance depuis le 21 octobre 2025, fin de vie le 30 avril 2027.

Ce que ces statuts veulent dire en pratique. Une ligne « Active LTS » reçoit les nouveautés rétroportées, les correctifs et les mises à jour de sécurité : c'est la version à viser pour un nouveau projet ou une montée planifiée. Une ligne « en maintenance » ne reçoit plus que les correctifs critiques et de sécurité : on y reste sans honte, mais on ne s'y installe pas. Une ligne en fin de vie ne reçoit plus rien, y compris pour une faille comme celle du décodeur Brotli corrigée le 21 octobre, que la CISA a inscrite le 27 octobre dans son catalogue des failles exploitées.

Pour un serveur en production, la règle est simple : jamais sur une ligne impaire (23, 25, 27), qui n'a pas de phase LTS, et jamais sur une ligne en fin de vie. Entre 22, 24 et 26, tout dépend de l'horizon : un projet qu'on ne retouchera pas avant l'été peut rester en 24 ; un projet vivant gagne à passer en 26 pendant qu'on a le temps de tester.

Ce qu'apporte Node.js 26

Temporal activé par défaut. La nouvelle API de dates et d'heures du langage, conçue pour remplacer l'objet Date et ses pièges de fuseaux horaires et de mois numérotés à partir de zéro. Pour un back-office qui manipule des créneaux, des échéances ou des fuseaux, c'est l'argument le plus concret de cette version.
V8 14.6, le moteur JavaScript de Chromium 146, avec Map.prototype.getOrInsert() et getOrInsertComputed() (fin du motif « si la clé n'existe pas, crée-la puis relis-la ») et Iterator.concat().
Undici 8, l'implémentation de fetch intégrée, et des évolutions du module de chiffrement : export au format graine pour les algorithmes post-quantiques ML-KEM et ML-DSA, format de clé brute dans les API KeyObject.
Le module SQLite intégré gagne l'extension de percentiles. Pour un outil interne ou un cache local, Node.js embarque désormais une base relationnelle sans dépendance.

Ce que Node.js 26 retire, et qui peut casser

Le code applicatif survit presque toujours à un changement de version de Node.js. Ce qui casse, c'est ce qui est en dessous. Quatre points à vérifier avant de migrer :

Les modules natifs doivent être reconstruits. La version d'interface binaire (NODE_MODULE_VERSION) passe à 147. Tout module compilé pour une version précédente refuse de charger. Dans une pile NestJS ou Next.js typique, cela concerne argon2 ou bcrypt (mots de passe), sharp (images), les moteurs Prisma, better-sqlite3. Une réinstallation propre des dépendances suffit en général, à condition que l'éditeur du module publie un binaire pour la 26, ce qui est le cas des modules courants mais pas de tous.
Des API anciennes disparaissent. Les modules internes _stream_readable, _stream_writable et consorts sont supprimés ; une vieille bibliothèque qui les importait directement ne démarre plus. http.Server.prototype.writeHeader() est retiré au profit de writeHead(). L'option --experimental-transform-types n'existe plus.
Des avertissements apparaissent. module.register() passe en dépréciation à l'exécution : si votre démarrage l'utilise pour charger des hooks, attendez-vous à un message dans les journaux, et préparez la bascule.
La chaîne de compilation monte. Compiler des modules natifs sur la 26 demande GCC 13.2 au minimum et abandonne Python 3.9. Une image Docker de construction basée sur une distribution ancienne ne compilera plus ce qui n'a pas de binaire précompilé.

Migrer en six étapes

Inventorier. Quelle version de Node.js tourne réellement, dans chaque conteneur : docker exec <conteneur> node -v. Pas celle du poste de développement, pas celle du package.json.
Déclarer la cible. Le champ engines du package.json ("node": ">=26") et un fichier .nvmrc ou .node-version alignés : l'équipe et la CI utilisent la même version.
Changer l'image de base, par exemple node:26-bookworm-slim ou node:26-alpine, dans le Dockerfile de construction et dans celui d'exécution. Épinglez le condensat de l'image, pas seulement l'étiquette, pour que deux constructions donnent le même résultat.
Réinstaller sans cache et lancer les tests. pnpm install --frozen-lockfile dans une image neuve, puis la suite de tests complète. C'est à cette étape qu'un module natif sans binaire pour la 26 se révèle.
Lire les journaux de démarrage en préproduction : les avertissements de dépréciation de la 26 sont la liste des chantiers de l'année prochaine.
Déployer une application à la fois, en gardant l'image précédente sous la main pour revenir en arrière en une commande.

# Dockerfile, étape d'exécution
FROM node:26-bookworm-slim@sha256:<condensat>
ENV NODE_ENV=production
USER node
COPY --chown=node:node --from=build /app/dist ./dist
COPY --chown=node:node --from=build /app/node_modules ./node_modules
CMD ["node", "dist/main.js"]

Sur un monorepo qui porte plusieurs applications, la montée se fait application par application, mais la version de Node.js, elle, se décide une fois pour tout le dépôt : deux versions dans un même monorepo finissent toujours par produire un module natif compilé pour la mauvaise.

Et si on reste en 24 ?

C'est défendable jusqu'au printemps 2028, date de fin de vie de la ligne 24. Les correctifs de sécurité continueront d'arriver, et le risque de régression est nul puisque rien ne change. Ce qu'on perd : les nouveautés, et surtout l'habitude. Une équipe qui migre chaque automne, quand la nouvelle LTS arrive, passe une demi-journée dessus. Une équipe qui saute deux versions passe une semaine, parce que les dépréciations se sont accumulées et que les modules natifs ont changé deux fois. Le coût de la migration ne vient pas de la migration, il vient du retard.

Ce que j'en retiens

Au 28 octobre 2026, Node.js 26 est la version LTS à viser, la 24 est en maintenance jusqu'en avril 2028, la 22 s'arrête en avril 2027.
La 26 apporte Temporal par défaut, V8 14.6 et Undici 8, et retire quelques API anciennes.
Ce qui casse à la migration, ce sont les modules natifs et les images Docker : réinstaller dans une image neuve, tester, lire les avertissements.
Migrer chaque automne coûte une demi-journée ; attendre coûte une semaine.

Vous ne savez pas sur quelle version de Node.js tournent vos applications, ni si quelqu'un suit ces échéances ? Je peux faire l'inventaire, planifier la montée en 26 et la réaliser sans interruption de service. Décrivez-moi votre installation, je vous réponds rapidement.

Sources : calendrier officiel des versions du projet Node.js (dépôt nodejs/Release), notes de version de Node.js 26.0.0 du 5 mai 2026, avis de sécurité Node.js du 21 octobre 2026. Article à jour au 28 octobre 2026.

← Tous les articles