--- title: "Node.js 26.4.0 'Current' livre le sous-système node:vfs (Matteo Collina), les package maps pour les hooks de loader ESM (Maël Nison), la compression de certificat TLS, TCP_KEEPINTVL/TCP_KEEPCNT, et argon2 stable" description: "Node.js 26.4.0 (Current), publié le 2026-06-24 par @aduh95, apporte huit changements SEMVER-MINOR : un sous-système node:vfs minimal qui permet de monter des systèmes de fichiers virtuels fournis par l'application (PR #63115, Matteo Collina) ainsi qu'un suivi qui redirige node:fs/promises vers les instances VFS montées (PR #63537), les package maps pour les hooks de loader ESM qui routent les spécificateurs bruts à travers les hooks de loader (PR #62239, Maël Nison), certificateCompression TLS qui câble la compression zlib et zstd de la RFC 8879 à travers la configuration de build OpenSSL (PR #62217, Tim Perry), le support de TCP_KEEPINTVL et TCP_KEEPCNT dans net.Socket.setKeepAlive (PR #63825, Guy Bedford), des buffers fournis par l'appelant dans fs.readFile / fs.readFileSync (PR #63634, Matteo Collina), closeIdleConnections qui ferme désormais aussi les sockets pre-request (PR #63470, semimikoh), net.BlockList promu au statut Release Candidate (PR #63050), et crypto argon2 + KEM encap/decap marqués stable (PR #63924, Filip Skokan). La release ajoute aussi WebCrypto cSHAKE (PR #63988), listEndpoints QUIC (PR #63536) et des handles X509Certificate (PR #63191), dgram connectSync / bindSync (PRs #63838 + #63932, Guy Bedford), net.BoundSocket pour un binding TCP précoce (PR #63951), un chemin expérimental d'appel FFI rapide pour AArch64 et x86_64 (PRs #63068 + #63941, Paolo Insogna), npm 11.17.0 (PR #63857), sqlite 3.53.2 et libffi 3.6.0." date: 2026-06-25 image: "/images/heroes/2026-06-25--node-js-26-4-current-vfs-loader-package-maps.png" author: lschvn tags: ["runtimes", "tooling", "security"] tldr: - "Node.js 26.4.0 'Current', publié le 2026-06-24 par @aduh95, est la première release de la ligne 26.x à ajouter un sous-système `node:vfs` minimal ([PR #63115](https://github.com/nodejs/node/pull/63115), Matteo Collina) et à rediriger `node:fs/promises` vers des instances VFS montées par l'application ([PR #63537](https://github.com/nodejs/node/pull/63537)). Les deux PR VFS arrivent la même semaine que la [release Node.js 24.18.0 'Krypton' LTS](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake), ce qui veut dire que les primitives de sandboxing portées par la ligne Current ne sont plus qu'à un cycle de la ligne LTS que les utilisateurs en production déploient." - "L'autre chantier SEMVER-MINOR principal est la [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, le créateur de Yarn), qui implémente les package maps pour les hooks de loader ESM. Les auteurs de loaders peuvent maintenant lire la même map `imports` que Node.js utilise déjà pour résoudre les spécificateurs bruts dans le graphe applicatif, et c'est la première fois que les hooks de loader ESM exposent la machinerie des package maps comme API de première classe. La release ajoute aussi certificateCompression TLS par-dessus le travail de compression OpenSSL ([PR #62217](https://github.com/nodejs/node/pull/62217), Tim Perry), et expose TCP_KEEPINTVL et TCP_KEEPCNT dans `net.Socket.setKeepAlive` ([PR #63825](https://github.com/nodejs/node/pull/63825), Guy Bedford)." - "Autres changements concrets : `crypto.argon2` et `crypto.encap` / `crypto.decap` sont marqués stable ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan) ; WebCrypto gagne cSHAKE et les longueurs de digest non-octets ([PR #63988](https://github.com/nodejs/node/pull/63988)) ; `net.BlockList` passe en Release Candidate ([PR #63050](https://github.com/nodejs/node/pull/63050)) ; QUIC expose une API `listEndpoints` et renvoie des handles X509Certificate au lieu de handles OpenSSL bruts ([PR #63536](https://github.com/nodejs/node/pull/63536), [PR #63191](https://github.com/nodejs/node/pull/63191)) ; `dgram` reçoit `connectSync` / `bindSync` synchrones ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford) ; un chemin expérimental d'appel FFI rapide arrive pour AArch64 et x86_64 ([PRs #63068](https://github.com/nodejs/node/pull/63068) + [#63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna) ; npm livre la 11.17.0, sqlite passe en 3.53.2, libffi en 3.6.0, et la [ligne Node.js 25 est marquée End-of-Life dans la doc](https://github.com/nodejs/node/pull/63692)." faq: - question: "Quel est le changement phare de Node.js 26.4.0 'Current' ?" answer: "Il y a deux chantiers principaux, selon la surface qui vous concerne. Pour l'architecture runtime, le nouveau sous-système [node:vfs](https://github.com/nodejs/node/pull/63115) (Matteo Collina) est le titre : une couche VFS minimale qui permet au code applicatif de monter des systèmes de fichiers virtuels, plus un suivi ([PR #63537](https://github.com/nodejs/node/pull/63537)) qui redirige les appels `node:fs/promises` vers les instances VFS montées au lieu du disque réel. C'est la fondation sur laquelle viendront se brancher les futures API de fichiers en sandbox dans Node.js. Pour l'écosystème des loaders ESM, la [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, le créateur de Yarn) implémente les package maps pour les hooks de loader ESM, la première fois que les hooks de loader obtiennent une API de première classe pour lire la même map `imports` que le runtime hôte utilise pour résoudre les spécificateurs bruts. Les auteurs d'outillage (Vite, Rolldown, esbuild, swc, oxc) et les auteurs de frameworks qui construisent leurs propres loaders ont pour la première fois un chemin uniforme à travers les hooks de loader." - question: "Que fait le sous-système node:vfs, et pourquoi est-ce important ?" answer: "Le nouveau sous-système `node:vfs` est une couche de système de fichiers virtuel minimale que le code applicatif peut monter et démonter à l'exécution. La [PR #63115](https://github.com/nodejs/node/pull/63115) ajoute le sous-système lui-même : un petit registre in-process d'instances VFS montées, plus le module public `node:vfs` qui expose `mount`, `unmount`, `getMount`, et `getMounts`. La [PR #63537](https://github.com/nodejs/node/pull/63537) câble la couche dans `node:fs/promises`, si bien qu'un appel `readFile` sur un chemin qui commence par un préfixe monté est redirigé vers l'instance VFS plutôt que vers l'OS. La pièce est la fondation côté runtime pour l'exécution sandboxée : les outils de build peuvent passer à un loader un système de fichiers virtuel qui contient l'arborescence du projet, les plateformes serverless peuvent passer à un handler de requête un système de fichiers virtuel qui ne contient que la portée de la requête, et les serveurs de langage d'IDE peuvent passer à une sonde de debugger un système de fichiers virtuel qui contient le fichier en cours de débogage. L'interface de l'instance VFS est volontairement minimale dans cette première coupe ; les sémantiques plus riches (liens symboliques, watch, résolution real-path) sont attendues dans les Current releases suivantes." - question: "Comment fonctionnent les package maps pour les hooks de loader ESM ?" answer: "La [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison) implémente les package maps pour les hooks de loader ESM. Le runtime a déjà une map `imports` de style `package.json` qui permet au graphe applicatif de résoudre les spécificateurs bruts (`#internal/api`, `lodash/sortBy`) ; les hooks de loader devaient auparavant réimplémenter la lookup de map eux-mêmes parce que la résolution était interne au module loader. La nouvelle API expose la même résolution comme appel de première classe sur les hooks de loader, si bien qu'un loader qui a besoin de savoir si un spécificateur se résout en un chemin remappé (ou en un sous-chemin) peut lire directement le résultat sans parcourir le `package.json` lui-même. Pour les auteurs d'outils de build, c'est la pièce manquante pour implémenter des import maps Node.js-compatibles au-dessus d'un bundler ; le spec des import maps définit déjà le format, et Node.js expose désormais la même forme que celle que les import maps navigateur consomment. La description de la PR la présente comme le côté hooks de loader du même travail d'import maps que le [`build.chunkImportMap` de Vite 8.1](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode) livre à la couche build-output." - question: "Qu'est-ce que la compression de certificat TLS, et quand aide-t-elle ?" answer: "La compression de certificat TLS est l'extension [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879) qui permet à la handshake TLS d'envoyer la chaîne de certificats serveur sous forme compressée. Elle est surtout utile quand la chaîne inclut une grande signature post-quantique, ce qui est la raison pour laquelle Chrome et Firefox l'ont déployée ces derniers mois. La [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry) ajoute une option `certificateCompression` sur `tls.createSecureContext` et `https.Server` qui accepte un tableau d'algorithmes de compression (`'zlib'` et `'zstd'`), et met à jour la configuration de build OpenSSL pour que les primitives de compression OpenSSL soient liées au binaire Node.js. Le suivi [PR #63255](https://github.com/nodejs/node/pull/63255) déjà livré en 24.18.0 a câblé ML-DSA, ML-KEM, ChaCha20-Poly1305 et AES-KW pour les builds BoringSSL, mais le travail de compression de la 26.4.0 est la première fois que le build path OpenSSL expose la même surface. Les serveurs qui l'activent sur une chaîne contenant une signature post-quantique devraient voir un handshake TLS sensiblement plus court." - question: "Pourquoi l'exposition de TCP_KEEPINTVL et TCP_KEEPCNT est-elle importante ?" answer: "La [PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford) ajoute `TCP_KEEPINTVL` et `TCP_KEEPCNT` aux options acceptées par `net.Socket.setKeepAlive(enable, initialDelay)`. Avant la 26.4.0, `setKeepAlive` n'acceptait que l'argument de délai initial, et l'intervalle entre probes ainsi que le nombre de probes avant qu'une connexion soit déclarée morte étaient les défauts OS. Sur Linux les défauts sont 75 secondes entre probes et 9 probes avant drop, ce qui veut dire qu'une connexion à moitié ouverte survit ~11 minutes ; sur macOS les défauts sont similaires. Les auteurs de bibliothèques (drivers de bases de données, brokers de messages, runtimes edge, clients QUIC) ne pouvaient pas tuner ces valeurs sans tomber sur un module natif. Avec les nouvelles options, le code applicatif peut raccourcir l'intervalle entre probes à quelques secondes et le nombre à un petit chiffre, qui est la configuration que les drivers de bases de données en production réclamaient depuis des années. La [PR #63951](https://github.com/nodejs/node/pull/63951) complémentaire ajoute `net.BoundSocket`, une primitive synchrone de binding TCP précoce pour les chemins de code qui ont besoin de binder un port avant de yield l'event loop." - question: "Qu'est-ce que la release stabilise côté crypto ?" answer: "La [PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) marque `crypto.argon2` (Argon2id, Argon2i, Argon2d) et `crypto.encap` / `crypto.decap` (encapsulation de clé pour ML-KEM et RSA-OAEP) comme stable. Les deux étaient derrière un drapeau expérimental depuis le cycle 22.x, et la stabilisation est le prérequis pour que des bibliothèques puissent en dépendre sans les flags `--experimental-argon2` et `--experimental-encap-decap`. La release ajoute aussi le support WebCrypto cSHAKE ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), ce qui aligne Node.js avec le même cSHAKE que le [travail Web Crypto de Node.js 24.18.0 LTS](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) a étendu. net.BlockList passe en Release Candidate ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), la dernière étape avant stable dans la prochaine Current release." - question: "Qu'est-ce que le travail fast FFI, et pourquoi est-il en 26.x Current plutôt qu'en LTS ?" answer: "Les [PR #63068](https://github.com/nodejs/node/pull/63068) et [PR #63941](https://github.com/nodejs/node/pull/63941) (Paolo Insogna) ajoutent une API expérimentale d'appel FFI rapide pour AArch64 et x86_64. Le travail expose un module `node:ffi` qui permet à JavaScript d'appeler des fonctions C natives sans passer par `node-addon-api`, avec le coût d'un appel indirect au lieu du round-trip V8 / libuv / N-API / nan que le chemin addon existant prend. Le benchmark de la description de la PR cite environ 50 % de la latence d'appel du chemin addon existant sur x86_64 Linux. La feature est en 26.x Current d'abord parce que la surface d'API (convention d'appel, câblage backend libffi, règles de lifetime) est encore en cours de façonnage ; la [PR #63794](https://github.com/nodejs/node/pull/63794) de suivi porte la même machinerie sur riscv64 et autres architectures. Les utilisateurs en production sur la ligne v24 LTS n'ont rien à faire ; le chemin est gardé derrière `--experimental-ffi` et l'API passera par au moins un cycle Current avant d'être candidate pour la ligne LTS." - question: "Quel travail QUIC est livré en 26.4.0 ?" answer: "Trois changements QUIC arrivent sur la ligne Current. La [PR #63536](https://github.com/nodejs/node/pull/63536) (James M Snell) ajoute une API `listEndpoints` qui renvoie les endpoints UDP locaux actuellement utilisés par le QuicEndpoint. La [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) change l'accesseur de certificat QUIC pour renvoyer un handle JavaScript `X509Certificate` au lieu du handle OpenSSL brut que l'alpha antérieur exposait, ce qui clôt une vieille doléance des utilisateurs QUIC qui voulaient inspecter la chaîne de certificats sans passer par `tls.getPeerCertificate`. Les [PR #63946](https://github.com/nodejs/node/pull/63946) et [PR #63950](https://github.com/nodejs/node/pull/63950) (Tim Perry) corrigent deux vrais bugs : un souci `get_reader` qui droppait des données sur FIN, et un deadlock de backpressure reader sur connexions idle. Le travail QUIC s'appuie sur le [suivi libuv reuse-port de Node.js 24.18.0](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) et sur le travail QUIC CI qui arrive sur la ligne v24 depuis deux mois." - question: "Que doivent faire aujourd'hui les utilisateurs sur la ligne v24 LTS ?" answer: "Rien ne change pour les utilisateurs en production sur la ligne v24 LTS ; la v26.4.0 est la ligne Current et les nouvelles features (VFS, package maps, compression de certificat TLS, fast FFI) prendront des mois à être backportées. La release v24.18.0 livrée il y a deux jours reste la cible stable recommandée. Les deux suivis à surveiller côté v24 sont le sous-système VFS (qui finira par remonter dans la ligne LTS) et la compression de certificat TLS (que la [release de sécurité Node.js de juin 2026](/articles/2026-06-18--node-js-june-2026-security-releases) a couverte pour la ligne v22). La ligne v24.18.0 LTS récupérera ces éléments quand la ligne Current les aura stabilisés, ce qui est le même cycle qui a produit le [Buffer.poolSize 64 Kio par défaut](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) sur v24.18.0 après deux mois sur Current." - question: "Que contient d'autre la 26.4.0 ?" answer: "Plusieurs pièces plus petites méritent d'être signalées. La [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) ajoute le support de buffer fourni par l'appelant à `fs.readFile` et `fs.readFileSync`, la première fois que l'API de lecture de fichier laisse l'appelant passer le buffer destination au lieu de laisser Node.js allouer en interne. La [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) fait que `http.closeIdleConnections` ferme aussi les sockets pre-request, corrigeant un vrai bug où des sockets keep-alive idle restaient ouvertes après que la requête qui les possédait s'était terminée. npm livre la 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite passe en 3.53.2, libffi en 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), et acorn en 8.17.0. La release marque aussi [Node.js 25 comme End-of-Life dans la doc](https://github.com/nodejs/node/pull/63692) et livre un long patch d'optimisation stream (Matteo Collina, James M Snell, Trivikram Kamat) qui réduit les allocations sur les chemins chauds WHATWG streams, corrige le stall Utf8Stream après une écriture complète de données multi-octets, et raffine la backpressure `stream/iter`. La [PR #62986](https://github.com/nodejs/node/pull/62986) complémentaire corrige le `desiredSize` de `Writable.toWeb()` pour les streams en non-object-mode, un vieux bug qui se manifestait dès que l'adaptateur WHATWG streams était utilisé avec un stream binaire." --- [Node.js 26.4.0 'Current'](https://github.com/nodejs/node/releases/tag/v26.4.0), publié le 2026-06-24 à 23 h 38 UTC par @aduh95 avec @aduh95, @targos et @jasnell comme stewards de release, est la deuxième Current release de juin sur la ligne v26 et la plus grosse du cycle depuis la [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) du 2026-06-01. Elle livre huit changements SEMVER-MINOR : un sous-système [node:vfs](https://github.com/nodejs/node/pull/63115) minimal (Matteo Collina) plus un suivi qui redirige `node:fs/promises` vers les instances VFS montées ([PR #63537](https://github.com/nodejs/node/pull/63537)), les [package maps pour les hooks de loader ESM](https://github.com/nodejs/node/pull/62239) (Maël Nison, le créateur de Yarn), [certificateCompression TLS](https://github.com/nodejs/node/pull/62217) par-dessus le travail de compression OpenSSL (Tim Perry), `TCP_KEEPINTVL` et `TCP_KEEPCNT` dans [net.Socket.setKeepAlive](https://github.com/nodejs/node/pull/63825) (Guy Bedford), les buffers fournis par l'appelant dans `fs.readFile` ([PR #63634](https://github.com/nodejs/node/pull/63634), Matteo Collina), `closeIdleConnections` qui ferme désormais aussi les sockets pre-request ([PR #63470](https://github.com/nodejs/node/pull/63470), semimikoh), `net.BlockList` avancé en Release Candidate ([PR #63050](https://github.com/nodejs/node/pull/63050)), et `crypto.argon2` ainsi que `crypto.encap` / `crypto.decap` marqués stable ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan). La release arrive deux jours après [Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0) du 2026-06-23, et le timing est le schéma habituel : la ligne Current porte le travail expérimental qui finit par être backporté en LTS. Le [Buffer.poolSize 64 Kio par défaut](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) en est l'exemple canonique, livré sur Current en [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) le 2026-06-01 et sur LTS en 24.18.0 il y a deux jours. Le sous-système VFS, les package maps pour les loaders ESM, et la compression de certificat TLS sont du même type de travail : suffisamment significatifs pour mériter leur propre Current release, mais encore assez expérimentaux pour ne pas atteindre la ligne v24 LTS avant au moins un cycle de plus. ## `node:vfs`, un nouveau sous-système core Le changement le plus significatif en termes d'architecture dans la 26.4.0 est le nouveau sous-système `node:vfs`. La [PR #63115](https://github.com/nodejs/node/pull/63115) (Matteo Collina) ajoute une couche VFS in-process minimale que le code applicatif peut monter et démonter à l'exécution. Le sous-système expose quatre fonctions : `mount(prefix, vfsInstance)`, `unmount(prefix)`, `getMount(prefix)` et `getMounts()`. Le `vfsInstance` est un objet JavaScript qui implémente une petite interface async (`readFile`, `stat`, `readdir`, plus une poignée d'autres), et Node.js redirige les appels `node:fs/promises` dont le chemin commence par le préfixe monté vers l'instance plutôt que vers le système de fichiers de l'OS. Le suivi [PR #63537](https://github.com/nodejs/node/pull/63537) (Matteo Collina) câble directement la couche dans `node:fs/promises`. Un appel `readFile('/vfs/project/src/index.ts')` sur un préfixe monté avec une instance VFS in-memory qui contient l'arborescence du projet renvoie le contenu in-memory sans toucher au disque. L'intégration est la fondation côté runtime pour l'exécution sandboxée : les outils de build peuvent passer à un loader un système de fichiers virtuel qui contient l'arborescence du projet, les plateformes serverless peuvent passer à un handler de requête un système de fichiers virtuel qui ne contient que la portée de la requête, les serveurs de langage d'IDE peuvent passer à une sonde de debugger un système de fichiers virtuel qui contient le fichier en cours de débogage. Les utilisateurs en production sur la ligne v24 LTS ne verront pas cela avant au moins un cycle de release, mais la ligne Current a maintenant la primitive sur laquelle viendra se brancher le prochain round de travail d'outillage. L'interface de l'instance VFS est volontairement minimale dans cette première coupe. La description de la PR est explicite : les liens symboliques, le file watching et la résolution real-path sont hors scope et arriveront dans les Current releases suivantes. La PR de documentation complémentaire décrit la surface comme « le plus petit VFS viable qui nous permette de remplacer le monkey-patching fs ad-hoc dans l'outillage » et note que l'API passera par au moins un cycle Current avant d'être candidate à la stabilisation. ## Package maps pour les hooks de loader ESM Le deuxième changement architectural est la [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison), qui implémente les package maps pour les hooks de loader ESM. Le runtime a déjà une map `imports` de style `package.json` qui permet au graphe applicatif de résoudre les spécificateurs bruts (`#internal/api`, `lodash/sortBy`, `react/jsx-runtime`) ; les hooks de loader devaient auparavant réimplémenter la lookup de map eux-mêmes parce que la résolution était interne au module loader. La nouvelle API expose la même résolution comme appel de première classe sur les hooks de loader, si bien qu'un loader qui a besoin de savoir si un spécificateur se résout en un chemin remappé (ou en un sous-chemin) peut lire directement le résultat sans parcourir le `package.json` lui-même. Pour les auteurs d'outils de build, c'est la pièce manquante pour implémenter des import maps Node.js-compatibles au-dessus d'un bundler. Le [spec des import maps](https://html.spec.whatwg.org/multipage/webappapis.html#import-maps) définit déjà le format, et les implémentations navigateur livrent des import maps depuis des années. Node.js avait le champ `imports` sous-jacent depuis la même période, mais l'API des hooks de loader n'a jamais exposé le chemin de résolution que le runtime hôte utilisait ; les auteurs de loaders devaient parcourir le `package.json` et réimplémenter la map. Maël Nison, qui a authored le package manager Yarn et était le contributeur principal du mécanisme [Yarn `resolutions`](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/), est l'auteur idoine pour ce travail, et la PR est la première fois que les hooks de loader ESM exposent la machinerie des package maps comme API de première classe. La description de la PR la présente comme le côté hooks de loader du même travail d'import maps que le [`build.chunkImportMap` de Vite 8.1](https://github.com/vitejs/vite/releases/tag/v8.1.0) livre à la couche build-output (couvert dans [notre article sur Vite 8.1 stable](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode)). Le chunkImportMap de Vite 8.1 est une feature côté bundler qui émet une import map navigateur pour la résolution des URLs de chunks ; les loader package maps de la 26.4.0 sont le côté runtime hôte qu'un bundler viendrait consommer en tournant sous Node.js. Les deux pièces sont indépendamment utiles, mais elles se placent à des couches différentes de la même stack. ## Compression de certificat TLS Le troisième changement SEMVER-MINOR est la [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry), qui ajoute une option `certificateCompression` à `tls.createSecureContext` et `https.Server`. L'option prend un tableau d'algorithmes de compression (`'zlib'` et `'zstd'`), et la PR câble l'extension [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879) à travers la configuration de build OpenSSL pour que les primitives de compression soient liées au binaire Node.js. Le commit complémentaire `e44b5d487e` met à jour la configuration de build OpenSSL pour supporter la compression ; sans cela, le support côté OpenSSL ne serait pas disponible à la couche TLS de Node.js. La compression de certificat TLS est surtout utile quand la chaîne inclut une grande signature post-quantique, ce qui est la raison pour laquelle Chrome et Firefox l'ont déployée ces derniers mois. Les serveurs qui l'activent sur une chaîne contenant une signature ML-DSA-65 ou ML-DSA-87 (les signatures primaires de la NIST FIPS 204) devraient voir un handshake TLS sensiblement plus court. La PR est aussi la première fois que le build path OpenSSL expose la même surface TLS que celle que [le chemin BoringSSL supporte déjà](https://github.com/nodejs/node/pull/63255), ce qui veut dire qu'un même binaire Node.js peut servir la même option `certificateCompression` quel que soit le backend TLS avec lequel il a été build. ## `TCP_KEEPINTVL` et `TCP_KEEPCNT` dans `setKeepAlive` Le quatrième changement SEMVER-MINOR est la [PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford), qui ajoute `TCP_KEEPINTVL` et `TCP_KEEPCNT` aux options acceptées par `net.Socket.setKeepAlive(enable, initialDelay)`. Avant la 26.4.0, `setKeepAlive` n'acceptait que l'argument de délai initial, et l'intervalle entre probes ainsi que le nombre de probes avant qu'une connexion soit déclarée morte étaient les défauts OS. Sur Linux les défauts sont 75 secondes entre probes et 9 probes avant drop, ce qui veut dire qu'une connexion à moitié ouverte survit ~11 minutes ; sur macOS les défauts sont similaires. Les auteurs de bibliothèques (drivers de bases de données, brokers de messages, runtimes edge, clients QUIC) ne pouvaient pas tuner ces valeurs sans tomber sur un module natif. Avec les nouvelles options, le code applicatif peut raccourcir l'intervalle entre probes à quelques secondes et le nombre à un petit chiffre, qui est la configuration que les drivers de bases de données en production réclamaient depuis des années. La [PR #63951](https://github.com/nodejs/node/pull/63951) complémentaire (Guy Bedford) ajoute `net.BoundSocket`, une primitive synchrone de binding TCP précoce pour les chemins de code qui ont besoin de binder un port avant de yield l'event loop. Les deux pièces sont les premiers changements `net` substantiels sur la ligne v26 Current et s'inscrivent dans la même famille que le [travail TCP keep-alive](https://github.com/nodejs/node/pull/63155) que la [ligne v24.18.0 LTS](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) a livré. ## Stabilisation crypto, QUIC, dgram et FFI Les cinq autres pièces SEMVER-MINOR complètent le tableau. La [PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) marque `crypto.argon2` (Argon2id, Argon2i, Argon2d) et `crypto.encap` / `crypto.decap` (encapsulation de clé pour ML-KEM et RSA-OAEP) comme stable. Les deux étaient derrière un drapeau expérimental depuis le cycle 22.x, et la stabilisation est le prérequis pour que des bibliothèques puissent en dépendre sans les flags. La release ajoute aussi le support WebCrypto cSHAKE ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), qui étend le [travail cSHAKE Web Crypto](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) livré sur la ligne v24. `net.BlockList` passe en Release Candidate ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), la dernière étape avant stable dans la prochaine Current release. Côté QUIC, la [PR #63536](https://github.com/nodejs/node/pull/63536) (James M Snell) ajoute une API `listEndpoints` et la [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) change l'accesseur de certificat pour renvoyer un handle `X509Certificate` au lieu du handle OpenSSL brut. `dgram` reçoit `connectSync` et `bindSync` synchrones ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford). Le travail expérimental fast FFI ([PR #63068](https://github.com/nodejs/node/pull/63068) + [PR #63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna) arrive pour AArch64 et x86_64, avec la [PR #63794](https://github.com/nodejs/node/pull/63794) de suivi (Stewart X Addison) qui porte la même machinerie sur riscv64. Le chemin est gardé derrière `--experimental-ffi` et l'API passera par au moins un cycle Current avant d'être candidate à la ligne LTS. ## Autres changements dans la 26.4.0 La release livre une longue traîne de changements plus petits. La [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) ajoute le support de buffer fourni par l'appelant à `fs.readFile` et `fs.readFileSync`, la première fois que l'API de lecture de fichier laisse l'appelant passer le buffer destination au lieu de laisser Node.js allouer en interne. La [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) fait que `http.closeIdleConnections` ferme aussi les sockets pre-request, corrigeant un vrai bug où des sockets keep-alive idle restaient ouvertes après que la requête qui les possédait s'était terminée. npm livre la 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite passe en 3.53.2, libffi en 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), et acorn en 8.17.0. La release marque aussi [Node.js 25 comme End-of-Life dans la doc](https://github.com/nodejs/node/pull/63692) et livre un long patch d'optimisation stream (Matteo Collina, James M Snell, Trivikram Kamat) qui réduit les allocations sur les chemins chauds WHATWG streams, corrige le stall Utf8Stream après une écriture complète de données multi-octets, et raffine la backpressure `stream/iter`. La [PR #62986](https://github.com/nodejs/node/pull/62986) complémentaire corrige le `desiredSize` de `Writable.toWeb()` pour les streams en non-object-mode, un vieux bug qui se manifestait dès que l'adaptateur WHATWG streams était utilisé avec un stream binaire. Le [calendrier de release Node.js 26](https://github.com/nodejs/release) complet prévoit la maintenance Current jusqu'en octobre 2026, date à laquelle la v26 entrera en Active LTS. Les utilisateurs en production sur la ligne v24 LTS doivent rester sur la 24.18.0 (la [release Node.js 24.18.0 'Krypton' LTS](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) que nous avons couverte il y a deux jours) pour au moins le prochain trimestre ; le suivi v24.19.0 reprendra le travail expérimental de la Current 26.x à mesure qu'il se stabilisera.