Ton pipeline Azure Pipelines qui build une image Docker depuis un job conteneurisé tournait très bien la semaine dernière. Depuis l’agent v5.279.0, il peut échouer sans prévenir sur un job Linux — parce que /var/run/docker.sock n’est plus monté par défaut. Ce n’est pas un bug, c’est un changement de comportement volontaire glissé dans la mise à jour de sprint de septembre, et il n’est pas seul : Node.js 16 sera retiré des agents le 24 novembre 2026, date à laquelle des tâches qui tournent sans problème depuis des années peuvent tout simplement planter.
Le socket Docker ne se monte plus tout seul
Si tes pipelines lancent du Docker-in-Docker — build d’image, tests d’intégration qui démarrent des conteneurs, scan de sécurité d’image — depuis un container job sur agent Linux, ce changement te concerne directement. Jusqu’à l’agent v5.279.0, mapDockerSocket valait true par défaut : le socket Docker de l’hôte était monté automatiquement dans le conteneur du job. Depuis cette version, la valeur par défaut passe à false, et il faut l’activer explicitement :
resources:
containers:
- container: my_container
image: ubuntu:22.04
mapDockerSocket: true
Si ton job conteneurisé n’a jamais eu besoin de parler au démon Docker de l’hôte, tu n’as rien à faire — c’est exactement le cas que Microsoft cherche à sécuriser par défaut, puisque monter ce socket donne de fait un accès root à la machine hôte depuis l’intérieur du conteneur. Mais si une seule étape de ton pipeline fait un docker build ou lance un conteneur depuis l’intérieur du job, mieux vaut ajouter la ligne avant que ça casse en silence sur ta prochaine mise à jour d’agent.
Node.js 6, 10 et 16 : la date à cocher dans ton calendrier
Deuxième nouveauté, plus structurante : Node.js 6, 10 et 16 atteignent leur fin de support et seront retirés de l’agent Azure Pipelines le 24 novembre 2026. Passé cette date, toute tâche qui cible une de ces versions tournera sur un runtime Node plus récent — ce qui peut suffire à casser une tâche personnalisée mal préparée, ou à produire un comportement inattendu sans message d’erreur clair.
Le plus efficace n’est pas d’attendre le 24 novembre pour découvrir quelles tâches sont concernées. Microsoft a ajouté un réglage dédié pour les identifier à l’avance : dans Organization settings > Pipelines > Settings, l’option « Restrict out of support Node.js versions in pipeline tasks » fait tourner, dès son activation, les tâches ciblant ces versions sur le nouveau runtime — et le journal du pipeline affiche un avertissement pour chaque tâche affectée. Active-le dans un projet non critique d’abord, regarde ce qui remonte, puis généralise : c’est littéralement conçu pour servir de test avant le couperet, pas uniquement pour appliquer la restriction.
Ce qui change aussi, plus discrètement
La mise à jour de sprint publiée début septembre embarque trois autres changements qui méritent une ligne chacun.
GitHub Copilot Code Review passe en disponibilité générale en preview publique pour Azure Repos — accessible à tous les clients Azure DevOps sans inscription à un accès anticipé, contrairement à la preview technique qu’on avait couverte à son lancement fin septembre. La version publique ajoute l’activation granulaire (organisation, projet ou dépôt), le support des Managed DevOps Pools pour exécuter les revues sans passer par les agents hébergés Microsoft, des instructions personnalisées par chemin de fichier, et le déclenchement automatique via les politiques de branche — y compris sur les pull requests en brouillon.
Le serveur MCP distant d’Azure DevOps — celui qui permet de connecter un assistant IA à tes projets, qu’on avait détaillé dans cet article — sait désormais détecter quand une requête approche la limite de débit du service et renvoyer une consigne d’attente à l’agent appelant, au lieu de simplement échouer.
Enfin, les pull requests multi-commits héritent automatiquement d’un titre basé sur le nom de la branche source, plutôt que de rester vides tant que personne n’y touche — un détail, mais un de ceux qui évitent les PR anonymes dans l’historique.
FAQ
Mon pipeline va-t-il casser immédiatement avec le changement de mapDockerSocket ?
Seulement si une étape de ton job conteneurisé Linux a besoin d’accéder au démon Docker de l’hôte (build d’image, lancement de conteneurs imbriqués). Les jobs conteneurisés qui n’utilisent pas Docker-in-Docker ne sont pas affectés.
Que se passe-t-il si je ne fais rien avant le 24 novembre pour Node.js ?
Tes tâches ciblant Node 6, 10 ou 16 continueront à s’exécuter, mais sur un runtime Node plus récent qu’elles n’ont jamais été testées pour utiliser — le risque va de l’échec franc à un comportement silencieusement différent, selon ce que fait la tâche.
Le serveur MCP Azure DevOps est-il disponible par défaut ?
Son activation dépend de ta configuration d’organisation et de l’assistant IA utilisé ; voir notre article dédié pour la mise en place.
Passe à l’action
Deux choses à faire cette semaine, pas dans six mois : grep tes fichiers YAML pour repérer les jobs conteneurisés qui lancent du Docker, et active le réglage de restriction Node.js sur un projet test pour voir ce qui remonte dans les logs. Les deux prennent moins d’une heure et t’évitent une mauvaise surprise le jour où l’agent se met à jour tout seul.
Laisser un commentaire