Ce qui a changé à l’insu de votre pipeline
Après une mise à jour, certaines des pannes les plus frustrantes viennent de petits changements que personne n’avait prévus. Une valeur par défaut bouge. Une date de fin de support passe. Un numéro de version ne veut plus dire la même chose que l’an dernier.
Illustration conceptuelle générée par IA d’un pipeline formé de trois modules reliés. Ce n’est le schéma d’aucun système ni produit réel.
Trois changements de ce type sont arrivés ces deux dernières semaines. Node.js modifie la façon dont il numérote et prend en charge ses versions. Docker Desktop a changé la manière dont il stocke par défaut les journaux (logs) des conteneurs. Et Go 1.25 a cessé de recevoir des correctifs de sécurité au moment même où un grand lot de correctifs était publié.
Aucun de ces changements n’est une crise. Chacun passe facilement inaperçu, et chacun se vérifie rapidement.
Les trois ont un point commun : les dates de support et les valeurs par défaut. Un outil auquel vous n’avez pas touché peut tout de même changer sous vos pieds, parce que ce dont il dépend a bougé. Cet article examine chaque changement l’un après l’autre, indique qui est concerné et se termine par une courte liste de vérifications.
Node.js : un nouveau modèle de publication entre en vigueur
Le projet Node.js a annoncé plus tôt cette année un nouveau calendrier de publication, avec une seule version majeure par an au lieu de deux. Ce changement commence maintenant à s’appliquer. Node.js 26 est la dernière version publiée selon l’ancien modèle. À partir de la version 27, une version majeure sortira chaque mois d’avril, et chaque version deviendra une version à support à long terme (LTS).
LTS signifie que le projet s’engage à continuer de corriger les bogues graves et les problèmes de sécurité pendant longtemps. Dans l’ancien modèle, seules les versions paires bénéficiaient du LTS, et les versions impaires avaient une durée de vie courte. Beaucoup d’équipes sautaient les versions impaires, mais les bénévoles qui font tourner Node.js devaient tout de même les maintenir.
Le nouveau modèle supprime cette distinction entre versions paires et impaires. Les numéros de version correspondront aussi à l’année : 27.0.0 arrivera en 2027, 28.0.0 en 2028.
Une nouvelle phase de test précoce, appelée Alpha, fait aussi son apparition. Chaque future version passera six mois en Alpha, puis six mois en Current, puis 30 mois en LTS. Les builds Alpha portent des noms comme 27.0.0-alpha.1. Ils sont destinés aux tests, pas à la production, et le projet précise que leur comportement peut changer d’un build à l’autre.
Pour les prochaines semaines, les dates comptent davantage que le modèle. Elles proviennent du calendrier de publication de Node.js :
| Version | Passage en LTS | Passage en Maintenance | Fin de vie |
|---|---|---|---|
| 22 | 29 oct. 2024 | 21 oct. 2025 | 30 avr. 2027 |
| 24 | 28 oct. 2025 | 20 oct. 2026 | 30 avr. 2028 |
| 26 | 28 oct. 2026 | 20 oct. 2027 | 30 avr. 2029 |
La phase Maintenance est la dernière avant la fin de vie. Une version en Maintenance reçoit encore les correctifs critiques, mais le développement de nouveautés s’arrête. Node.js recommande de n’exécuter les applications de production que sur une version Active LTS ou en Maintenance : Node.js 24 reste donc un choix sûr au 20 octobre.
Ma lecture de ce calendrier est que, pendant huit jours, du 20 au 28 octobre, aucune branche de Node.js n’est en Active LTS. Node.js 22 et 24 sont toutes deux en Maintenance, et Node.js 26 est encore en Current. Ce n’est pas un problème en soi. Mais quiconque conseille « prenez simplement l’Active LTS » doit attendre le 28 octobre pour avoir une réponse claire.
Que faire. Si vous exécutez Node.js 24 en production, tout va bien, mais commencez à préparer le passage à la version 26 une fois qu’elle sera devenue Active LTS le 28 octobre. Si vous exécutez Node.js 22, notez que sa fin de vie tombe le 30 avril 2027. Si vous maintenez une bibliothèque, ajoutez tôt la branche Alpha à vos tests. Le projet le dit lui-même : si vous ne testez que sur les versions LTS, vous découvrez les bogues après vos utilisateurs.
Docker Desktop : le pilote de journalisation par défaut a changé
C’est ce changement qui risque le plus de vous surprendre ; c’est donc lui qui occupe le plus de place.
Chaque conteneur écrit des messages sur sa sortie. Docker stocke ces messages au moyen d’un pilote de journalisation. Pendant des années, la valeur par défaut sur la plupart des configurations a été json-file, qui écrit chaque message sous forme d’une ligne JSON dans un simple fichier.
Ce fichier grossit sans limite, sauf si vous en fixez une. Les collecteurs de journaux, c’est-à-dire les programmes qui lisent les journaux des conteneurs et les envoient ailleurs, lisent souvent ces fichiers directement.
Docker Desktop 4.94, publié le 5 octobre, a fait d’un pilote appelé local la valeur par défaut pour les nouveaux conteneurs Linux. Les notes de version en donnent la raison : activer la rotation automatique des journaux. La rotation consiste à supprimer ou à compresser les anciens journaux pour qu’ils ne remplissent pas le disque. Par défaut, local conserve jusqu’à cinq fichiers de 20 Mo chacun et compresse les plus anciens, soit environ 100 Mo par conteneur.
C’est raisonnable, mais le pilote local ne stocke pas les journaux sous la même forme. La documentation de Docker indique que ses fichiers sont conçus pour être utilisés uniquement par le démon Docker, et avertit que des outils externes qui y touchent risquent d’interférer. Les fichiers sont dans un format binaire, et non en lignes JSON.
Un test mené par un tiers montre ce que cela peut signifier pour un collecteur qui lit des fichiers. L’équipe de DevOps Daily a fait tourner Fluent Bit, un collecteur de journaux courant, avec sa configuration standard pour les fichiers de journaux Docker. Face à des conteneurs json-file sans limite de taille, il a lu les 500 000 lignes de test. Face à des conteneurs local, il n’en a lu aucune, car son motif de fichiers habituel ne correspond pas aux fichiers qu’écrit le pilote local.
Quand l’équipe l’a fait pointer directement sur le fichier local, il a lu des enregistrements mais n’a pu en décoder aucun. Il s’agit d’un seul test, exécuté sur Docker Engine 29.9.0 sur un Raspberry Pi, et non sur Docker Desktop, et il ne portait que sur Fluent Bit. Les collecteurs qui lisent les journaux via l’API Docker, plutôt qu’à partir des fichiers, n’ont pas été testés.
Un deuxième type de dysfonctionnement est déjà apparu dans du code. La bibliothèque Docker pour Python ne renvoie rien depuis containers.run() lorsque le conteneur utilise le pilote local, car elle ne lit la sortie que pour json-file et un autre pilote. Un outil nommé DataHub s’est heurté à ce problème dans sa vérification d’installation et a imposé json-file pour son conteneur éphémère, en guise de contournement. Un correctif a été proposé dans la bibliothèque.
Les personnes concernées sont surtout les développeurs sous Docker Desktop 4.94 ou ultérieur dont l’environnement local reproduit un pipeline de journalisation de production. Les serveurs qui exécutent Docker Engine ne sont pas modifiés par cette version.
Le changement ne s’applique par ailleurs qu’aux nouveaux conteneurs. Les conteneurs que vous avez déjà conservent le pilote avec lequel ils ont été créés, jusqu’à ce que vous les recréiez.
Ce qu’il faut vérifier. Exécutez cette commande pour voir la valeur par défaut sur votre machine :
docker info --format '{{.LoggingDriver}}'Et celle-ci pour voir le pilote de chacun de vos conteneurs existants :
docker ps -aq | xargs docker inspect --format '{{.Name}} {{.HostConfig.LogConfig.Type}}'Si vous trouvez local et que votre collecteur lit des fichiers de journaux, vous avez deux possibilités. Vous pouvez passer à un collecteur qui lit via l’API Docker. Ou vous pouvez définir json-file avec une limite de taille, ce qui conserve l’ancien format de fichier. La limite entraîne bien la suppression des lignes les plus anciennes :
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}Définissez cette configuration dans les paramètres du démon Docker, puis recréez vos conteneurs pour qu’ils la prennent en compte. Pour un seul service, vous pouvez plutôt définir les mêmes options dans un fichier Compose.
Un mot rapide sur une autre version. Docker Engine 29.9.1, publié le 14 octobre, est une mise à jour distincte de Docker Desktop 4.94. Elle fait passer containerd, le composant qui exécute les conteneurs, à la version 2.4.2.
Cela corrige un plantage lors du téléchargement d’une image dont le descripteur contient un condensat d’annotation malformé (CVE-2026-95839), ainsi que deux autres problèmes qu’un registre malveillant pourrait exploiter pour faire planter containerd ou remplir un disque. Si vous exécutez Docker Engine sur des serveurs, c’est cette mise à jour qu’il faut planifier.
Go : la version 1.25 ne recevra plus de correctifs
Le 8 octobre, l’équipe Go a publié les versions 1.27.2 et 1.26.9. Ensemble, elles corrigent 15 problèmes de sécurité. La plupart se trouvent dans le code serveur et client web de la bibliothèque standard, dans net/http. L’annonce de Go en recense huit à cet endroit, les autres touchant crypto/tls, la commande go, les modèles HTML, l’analyse de texte et de contenus multipart, plus un propre à Windows.
Celui dont la plupart des équipes entendront parler est CVE-2026-97032. Dans un serveur HTTP/2, deux parties du code modifiaient la même table en même temps, sans coordination. Un client malveillant peut s’en servir pour faire planter le serveur. Un plantage provoqué par un client distant s’appelle un déni de service.
Il a été signalé par RyotaK, de GMO Flatt Security. Le correctif figure dans Go 1.26.9, Go 1.27.2 et la version 0.60.0 du paquet golang.org/x/net, pour les programmes qui utilisent directement son code HTTP/2.
Go prend en charge chaque version majeure jusqu’à ce que deux versions majeures plus récentes existent. Go 1.27.0 est sorti le 19 août : Go 1.25 se trouve donc désormais hors de cette fenêtre. Sa dernière version date du même jour. Ces correctifs ne seront donc pas intégrés à Go 1.25.
La fiche de vulnérabilité n’indique pas si Go 1.25 lui-même est touché par le problème HTTP/2. Inutile de chercher à le savoir. Un service qui tourne sur un runtime non pris en charge ne recevra pas non plus de correctif pour le prochain problème.
Deux avertissements avant de mettre à jour. Certains de ces correctifs modifient volontairement le comportement :
- Le client et le serveur HTTP/1 ferment désormais la connexion après toute requête CONNECT.
- Le proxy inverse de
net/http/httputilrépond désormais aux requêtes CONNECT entrantes par 405 Method Not Allowed. - Les requêtes comportant plus de 200 plages d’octets dans un en-tête Range sont désormais ignorées par les fonctions intégrées de service de fichiers. Un réglage nommé
GODEBUG=httpservecontentmaxranges=0désactive ce comportement.
Si vous exploitez des proxys ou quoi que ce soit qui manipule des requêtes CONNECT, testez après la mise à jour. Pour tous les autres, il s’agit d’une mise à jour de routine.
Ce qu’il faut vérifier. Exécutez go version sur vos machines de build et dans vos images de conteneur. Si la commande affiche 1.25 ou une version antérieure, planifiez la migration. Si possible, lancez l’outil govulncheck de Go sur votre code : il ne signale que les problèmes connus que votre code appelle réellement.
Jusqu’où approfondir le sujet
Connaître : tout développeur devrait savoir que les dates de support et les valeurs par défaut changent, et que ces trois changements existent. Inutile de connaître le détail de chacun.
Appliquer : les personnes responsables d’un pipeline, d’une image de base ou d’un runtime ont besoin d’une connaissance pratique. Cela veut dire savoir quelle branche de Node.js vous exécutez, quel pilote de journalisation Docker vos conteneurs utilisent et avec quelle version de Go vos services ont été compilés.
Maîtriser : les responsables de plateforme qui fixent la politique de versions pour de nombreuses équipes doivent comprendre les compromis. Par exemple : combien de temps rester sur une version en Maintenance, quand figer une valeur par défaut pour qu’elle ne puisse plus bouger, et comment tester tôt sur des builds Alpha ou des versions candidates.
Ce que vous pouvez ignorer pour l’instant
Vous pouvez laisser de côté l’Alpha de Node.js 27, sauf si vous maintenez une bibliothèque. Vous pouvez laisser de côté le détail des différents problèmes de Go, sauf si vous exploitez des serveurs HTTP/2 exposés à Internet. Et vous pouvez ignorer les changements de journalisation de Docker si vos conteneurs tournent sur Docker Engine et que vos journaux passent déjà par l’API Docker.
Que faire ensuite
Choisissez, parmi les trois lignes suivantes, celles qui vous concernent et exécutez-les cette semaine :
node -v, puis comparez le résultat avec le tableau ci-dessus.docker info --format '{{.LoggingDriver}}', puis vérifiez votre collecteur.go version, en cherchant 1.25 ou une version antérieure.
Si votre équipe ne tient aucune liste des versions de runtime en service, c’est là le vrai constat. Un court tableau « ce que nous exécutons et quand cela prend fin » repérera le prochain changement discret avant qu’il ne vous prenne au dépourvu.
Sur des sujets proches, lisez GitHub Actions évolue (en anglais), qui traite d’un autre changement de plateforme touchant les pipelines, et OpenTelemetry : pourquoi maîtriser son pipeline de télémétrie, qui examine où doivent circuler les journaux et les autres signaux.
Pour aller plus loin
- Evolving the Node.js Release Schedule, projet Node.js. La description officielle du nouveau modèle. Consulté le 18 octobre 2026.
- Node.js release schedule, groupe de travail Release de Node.js. La source des dates du tableau ci-dessus. Consulté le 18 octobre 2026.
- Node.js previous releases, projet Node.js. La recommandation de n’utiliser en production que des versions Active LTS ou Maintenance LTS. Consulté le 18 octobre 2026.
- Docker Desktop release notes, Docker. Version 4.94.0, 5 octobre 2026. Consulté le 18 octobre 2026.
- Local file logging driver, documentation de Docker. Les valeurs par défaut et la mention d’un accès réservé au démon. Consulté le 18 octobre 2026.
- Docker Engine 29.9.1 release, projet Moby. La mise à jour de containerd et les correctifs de sécurité. Consulté le 18 octobre 2026.
- docker-py issue 3455, projet docker-py. containers.run() renvoie None avec le pilote local ; ticket ouvert le 13 octobre 2026, avec un correctif d’une ligne dans la pull request 3456. Consulté le 18 octobre 2026.
- DataHub pull request 20403, projet DataHub. Impose le pilote json-file pour le conteneur de vérification d’installation ; fusionnée le 13 octobre 2026. Consulté le 18 octobre 2026.
- Moby local logger documentation, projet Moby. Décrit les enregistrements de journaux encodés en protobuf qu’écrit le pilote local. Consulté le 18 octobre 2026.
- Go release history, projet Go. Les versions 1.27.2 et 1.26.9, et la politique de support. Consulté le 18 octobre 2026.
- Go 1.27.2 and Go 1.26.9 security announcement, équipe Go, publiée le 8 octobre 2026. Les 15 correctifs de sécurité et les changements de comportement. Consulté le 18 octobre 2026.
- GO-2026-6617 (CVE-2026-97032), base de données des vulnérabilités de Go. La situation de concurrence sur la table HTTP/2 et les versions corrigées. Consulté le 18 octobre 2026.
- docker-log-driver-check, DevOps Daily. Le test de Fluent Bit mené par un tiers et décrit plus haut. Un seul test, sur Docker Engine. Consulté le 18 octobre 2026.