Node.js 26 a été publié en mai 2026 comme version « Current », mais c'est maintenant que ça devient sérieux : selon le calendrier officiel des releases, elle entre en phase LTS (Long Term Support) en octobre 2026, avec une date précise avancée par plusieurs observateurs du projet, le 28 octobre. Dans le même mouvement, Node.js 24 — la LTS en place depuis l'an dernier — bascule en maintenance le 20 octobre. Pendant quelques jours, les deux lignes se chevauchent, puis Node.js 26 devient la version « Active LTS » recommandée pour la production.

Si tu gères des services Node en production, cette bascule n'est pas qu'une ligne de changelog : elle détermine quand tu peux raisonnablement planifier ta prochaine migration, et surtout, elle embarque des changements qui touchent du code que beaucoup de projets utilisent encore sans le savoir. Le plus visible : Temporal, l'API qui remplace Date, est désormais active par défaut, sans flag. Le moins visible : plusieurs API historiques disparaissent.

Cet article fait le tour de ce qui change vraiment avec Node.js 26, avec un angle pratique : qu'est-ce qui risque de casser ton code, et comment t'y préparer avant la bascule en LTS.

Pourquoi s'en préoccuper maintenant plutôt qu'en novembre ? Parce que la plupart des équipes suivent la ligne LTS pour leurs images Docker et leurs runners de CI, et que les changements listés plus bas — retraits d'API, mise à jour d'Undici, nouvelle chaîne de compilation — ont plus de chances de te surprendre en pleine mise à jour de routine que lors d'un test isolé. Mieux vaut les connaître avant qu'ils ne deviennent un incident de production.

Temporal, enfin sans flag

Temporal était disponible en expérimental depuis plusieurs versions de Node (et de V8). Avec Node.js 26, l'API est stable et active par défaut : plus besoin de flag ni de polyfill pour l'utiliser dans du code serveur.

Le gain concret par rapport à Date : des objets immuables, une distinction claire entre instant, date civile et fuseau horaire, et une arithmétique qui ne te force plus à jongler avec des millisecondes.

// Avant : Date, mutable et ambigu sur les fuseaux
const d = new Date();
d.setDate(d.getDate() + 30); // mutation en place, piège classique

// Avec Temporal, disponible nativement en Node.js 26
const aujourdhui = Temporal.Now.plainDateISO();
const dans30jours = aujourdhui.add({ days: 30 }); // immuable, pas de mutation

console.log(dans30jours.toString()); // ex: 2026-11-15

Pour un calcul avec fuseau horaire, Temporal sépare clairement l'instant absolu (Temporal.Instant) de sa représentation locale (Temporal.ZonedDateTime), ce qui évite la majorité des bugs classiques liés au décalage horaire ou au changement d'heure été/hiver :

const maintenant = Temporal.Now.zonedDateTimeISO("Europe/Paris");
const heureNewYork = maintenant.withTimeZone("America/New_York");

console.log(heureNewYork.toString());

Si ton code utilise encore des bibliothèques tierces pour gérer les dates (moment.js, date-fns pour les cas complexes de fuseaux), ce n'est pas la fin de ces outils, mais Node.js 26 est la première version où tu peux sérieusement envisager de t'en passer côté serveur.

Les méthodes upsert sur Map et WeakMap

Autre nouveauté liée à la mise à jour de V8 vers la version 14.6 : les méthodes dites « upsert » apparaissent sur Map et WeakMap. L'idée : éviter le pattern classique « je vérifie si la clé existe, sinon je l'insère », qui demande deux accès à la map et souvent une condition maladroite.

// Avant : pattern get-or-set manuel
function getCompteur(map, cle) {
  if (!map.has(cle)) {
    map.set(cle, 0);
  }
  return map.get(cle);
}

// Avec getOrInsert : une seule opération atomique
function getCompteur(map, cle) {
  return map.getOrInsert(cle, 0);
}

// Pour une valeur coûteuse à calculer, getOrInsertComputed
// n'exécute le callback que si la clé est absente
const cache = new Map();
function resultatCoute(cle) {
  return cache.getOrInsertComputed(cle, () => calculLourd(cle));
}

Point important à avoir en tête avant de t'en servir en production : au moment de la rédaction, cette proposition (upsert) est encore au stade 2.7 à TC39, pas encore finalisée en stage 4. Elle est implémentée dans V8 et donc disponible dans Node.js 26, mais tant qu'elle n'est pas figée dans la norme ECMA-262, un détail de comportement peut encore évoluer d'ici sa finalisation officielle. Utilise-la pour du code interne ou des outils, mais vérifie le changelog si tu l'adoptes dans une librairie publiée.

Ce qui casse : la checklist avant de migrer

Node.js 26 retire plusieurs API jugées obsolètes depuis longtemps. Avant de passer ta CI ou ta prod sur cette version, vérifie ces points :

Les modules internes _stream_* (_stream_readable, _stream_writable, etc.) sont retirés. Ils n'étaient jamais censés être importés directement — si un outil ancien du projet le fait encore, c'est le moment de le remplacer par le module public stream.
http.Server.prototype.writeHeader() disparaît. Ce n'était qu'un alias historique de writeHead() ; un simple remplacement texte suffit si ton code s'en servait encore.
Le flag --experimental-transform-types est retiré. Si ton build ou tes outils de dev l'utilisaient pour exécuter des fichiers .ts directement, bascule vers le support natif des types stabilisé dans les versions précédentes, sans ce flag expérimental.
La chaîne de compilation native change : le support de Python 3.9 pour builder Node depuis les sources est abandonné, et la version minimale de GCC requise passe à 13.2. Ça ne concerne que les projets qui compilent Node ou des addons natifs eux-mêmes — vérifie tes images Docker de build si c'est ton cas.
Undici, le client HTTP intégré utilisé par fetch(), passe en version majeure 8.0.x. Si tu dépends de comportements internes non documentés d'Undici (plutôt que de l'API fetch standard), relis son changelog de migration.

Et le modèle de permissions ?

Le modèle de permissions (--permission) continue sa progression avec un support étendu pour QUIC, utile si tu restreins déjà les accès réseau de tes processus Node. Rien de bloquant ici, mais si tu maintiens une allowlist fine de permissions, revérifie-la après la mise à jour : chaque nouvelle brique protégée peut faire apparaître une permission manquante qui passait inaperçue avant. Le réflexe à garder : lance ton service avec --permission en environnement de test avant de le faire en prod, pour voir apparaître les refus dans les logs plutôt que chez l'utilisateur.

Planifier la migration sans se précipiter

La bascule en LTS ne veut pas dire qu'il faut migrer le jour même. Node.js 24 reste supporté en maintenance pendant encore plusieurs mois après octobre 2026 ; tu as donc une fenêtre confortable pour tester avant de changer la version par défaut de tes pipelines de déploiement.

Une approche raisonnable :

Ajoute Node.js 26 à ta matrice de CI en parallèle de ta version actuelle, sans encore la rendre obligatoire.
Fais tourner ta suite de tests avec le flag de dépréciation runtime activé (--pending-deprecation) pour repérer les appels aux API qui viennent de disparaître ou qui sont en sursis.
Grep ton code et tes dépendances directes pour _stream_, writeHeader et experimental-transform-types — ce sont les trois points de rupture les plus probables pour un projet web classique.
Si tout est vert, bascule ton image de base (Dockerfile, .nvmrc, engines dans package.json) une fois la version LTS effective, pas avant.

Dernier point utile pour ta planification à plus long terme : à partir de Node.js 27, le projet passe à un rythme d'une seule version majeure par an, chacune devenant directement LTS. Le cycle « Current puis LTS six mois plus tard » que tu viens de vivre avec la 26 ne se reproduira donc pas exactement de la même façon pour la suite — un détail à garder en tête si tu construis un calendrier de montée de version pour ton équipe.

Node.js 26 devient LTS : Temporal par défaut, ce qui casse