Catégorie : Azure DevOps

Un admin active Autofix sur un repo, un développeur clique sur « Generate fix » face à une alerte de dépendance vulnérable, et quinze minutes plus tard une pull request atterrit avec un changement de version, une explication et un score de priorité. C’est la promesse de l’Agentic Autofix, annoncée le 21 octobre 2026 par Laura Jiang sur le blog Azure DevOps. Pas une nouvelle fonctionnalité isolée : une refonte du moteur qui pilotait déjà Copilot Autofix pour GitHub Advanced Security depuis juin, cette fois avec un agent qui va fouiller ton code avant de répondre.

Ce qui change par rapport à l’ancien Autofix

La première version d’Autofix, lancée en juin 2026, générait des correctifs pour un ensemble limité de règles CodeQL. Elle lisait l’alerte, proposait un diff, point final. La version agentique s’appuie sur le moteur du Copilot coding agent : il explore le dépôt pour comprendre le contexte autour de l’alerte, rédige une proposition, puis la relit et l’ajuste avant de te la soumettre. Concrètement, ça veut dire qu’il peut repérer qu’une fonction de validation d’entrée existe déjà ailleurs dans ton code et s’en servir, plutôt que d’inventer son propre patch isolé.

Deuxième changement, plus structurant : Autofix ne se limite plus à CodeQL. Il traite aussi les alertes de code scanning remontées par des outils tiers, et couvre les vulnérabilités de dépendances — ce que l’ancienne version ne faisait pas du tout. Tu peux aussi le guider avec des instructions personnalisées et des « skills » placées dans les emplacements `.github` ou `.agents` de ton repo. Microsoft donne deux exemples concrets dans son billet : pointer l’agent vers un helper de validation d’entrée déjà approuvé par l’équipe, ou lui fournir une skill qui encode la procédure interne de mise à jour de paquets avec ses vérifications de compatibilité.

Dépendances vulnérables : le score EPSS plutôt que le seul CVSS

Sur une alerte de dépendance supportée, tu sélectionnes « Generate fix » et l’agent ouvre une pull request avec le changement proposé et une explication — qui passe ensuite par ta revue de code habituelle, rien n’est mergé automatiquement. Ce qui change vraiment la donne pour trier parmi des dizaines d’alertes, c’est l’affichage du percentile EPSS quand la donnée est disponible : plus le percentile est élevé, plus la probabilité d’exploitation relative de cette CVE est classée haut par rapport aux autres failles connues. Ce n’est pas une probabilité d’attaque en soi, juste un rang — Microsoft le précise explicitement dans son billet, et c’est la bonne nuance à transmettre à ton équipe avant qu’elle ne confonde les deux.

Azure DevOps distingue aussi désormais les dépendances de développement des dépendances d’exécution sur les écosystèmes supportés, via un badge « Development » et un filtre Scope. Le billet suggère une méthode de triage simple et plutôt juste : combiner le filtre Runtime avec une plage de percentile EPSS élevé, puis pondérer avec la sévérité et l’exposition réelle de l’application. Une dépendance de build jamais exposée en prod avec un EPSS élevé reste moins urgente qu’une dépendance runtime avec un EPSS moyen sur un service exposé à Internet — le score seul ne suffit jamais à trancher.

Activer Agentic Autofix sur ton organisation

L’activation se fait en un bouton, au niveau organisation, projet ou dépôt, et couvre à la fois les alertes de dépendances et de code scanning. Une fois l’option activée côté admin, c’est au niveau du dépôt que les alertes individuelles sont sélectionnées pour passer par Autofix. Le déploiement s’étale sur deux à trois semaines selon Microsoft — les organisations déjà dans la preview publique limitée peuvent demander des correctifs dès maintenant sur les alertes supportées, la preview publique générale, elle, commence en novembre 2026.

Le billet ne précise ni les langages exacts couverts pour la génération de fix, ni les noms des outils de code scanning tiers pris en charge, ni les paliers de licence requis — trois détails qu’on attend encore en pratique avant de pouvoir chiffrer sérieusement un déploiement à l’échelle d’une organisation.

Ce que ça coûte vraiment en crédits IA

Générer un correctif consomme des crédits IA. Activer Autofix sur un repo ne déclenche rien tout seul : tant que personne ne clique sur « Generate fix », aucun crédit n’est consommé. Toutes les demandes n’aboutissent pas non plus à un correctif exploitable. Et la responsabilité ne change pas de camp : chaque suggestion générée par l’agent doit être relue, buildée et testée avant merge, exactement comme n’importe quelle PR humaine — Autofix accélère la proposition, pas la revue.

Pour une équipe qui gère déjà des centaines d’alertes de dépendances sans jamais les traiter faute de temps, le calcul reste simple : même avec un taux d’échec non négligeable sur les correctifs générés, chaque PR qui atterrit toute prête vaut mieux qu’une alerte qui dort depuis huit mois. L’outil ne remplace pas un programme de gestion des vulnérabilités, il réduit juste la friction du dernier kilomètre — celui où la plupart des équipes calent, pas par manque de volonté mais par manque de temps.

FAQ

Agentic Autofix remplace-t-il complètement l’ancien Copilot Autofix ?

Oui, c’est une évolution du même produit, pas un outil parallèle. Le nom et le bouton restent « Copilot Autofix », mais le moteur sous-jacent est désormais celui du Copilot coding agent, avec exploration de contexte et relecture avant proposition.

Faut-il GitHub Advanced Security pour en profiter ?

Oui, Agentic Autofix s’appuie sur GitHub Advanced Security for Azure DevOps, qui fournit déjà le code scanning et la détection de dépendances vulnérables sous-jacents.

Un correctif généré peut-il être mergé automatiquement ?

Non. Chaque proposition passe par ta pull request et ton processus de revue habituel — build, tests, relecture humaine du diff complet avant tout merge.

Où signaler un problème ou un retour d’expérience ?

Microsoft indique trois canaux dans son billet : les commentaires du blog, l’email, ou la Azure DevOps Developer Community.

Pour aller plus loin

Si ta vraie bataille porte sur les alertes de code plutôt que de dépendances, l’autre moitié de l’équation Copilot côté Azure Repos — la revue de pull request automatisée — vaut le détour : on l’avait couverte au moment de sa preview publique en septembre. Et si le problème vient plutôt de paquets npm compromis en amont plutôt que de CVE déjà connues dans tes dépendances, le GitHub Package Firewall couvert la semaine dernière attaque le sujet par un autre bout, en amont de la CI plutôt qu’après coup sur une alerte déjà ouverte.

Reste la question du moment : activer Autofix aujourd’hui, en preview, sur un repo critique ? Si ton backlog d’alertes de dépendances dépasse la centaine et que personne n’y touche depuis des mois, oui, ça vaut le test — le pire qui puisse arriver est une PR non mergée. Si ton équipe a déjà un processus de triage qui tourne, attends plutôt la preview générale de novembre pour avoir une image plus claire des langages et outils réellement couverts.

Le 8 octobre 2026, Microsoft a mis en preview publique un nouvel éditeur pour le Wiki d’Azure DevOps. Rien de révolutionnaire dans l’annonce — un composant d’édition qui change — mais le détail compte : c’est Monaco, le moteur qui fait tourner Visual Studio Code dans un navigateur, qui remplace l’ancien éditeur. Concrètement, ton Wiki de documentation interne récupère une partie de l’expérience d’édition que tu as déjà sur ton poste, sans rien installer.

Ce que Monaco change concrètement dans l’éditeur Wiki

La liste des ajouts tient en une poignée de points, mais chacun répond à une frustration précise de l’ancien éditeur :

• Coloration syntaxique du Markdown et numéros de ligne, comme dans VS Code — fini l’édition à l’aveugle sur un bloc de code imbriqué dans une liste.
• Recherche et remplacement natifs, directement dans la page en cours d’édition.
• Annuler et rétablir qui couvrent enfin le formatage, le collage, les pièces jointes et l’autocomplétion — pas seulement le texte brut.
• Autocomplétion déclenchée par caractère : ! pour une pull request, @ pour une personne, # pour un item de travail, en plus des liens Wiki et des modèles de page.
• Préférences persistantes pour le retour à la ligne automatique et le défilement synchronisé entre l’édition et l’aperçu.

Sur le papier, c’est un simple rattrapage : ce sont des fonctionnalités qu’un éditeur de texte sérieux propose depuis longtemps. Dans les faits, pour une équipe qui écrit sa documentation d’architecture, ses runbooks ou ses post-mortems directement dans le Wiki d’Azure DevOps plutôt que dans un outil externe, la différence entre corriger un formatage cassé à la main et un Ctrl+Z qui fonctionne vraiment change l’envie de documenter au jour le jour, pas seulement le confort.

Pourquoi Monaco précisément

Monaco est le composant d’édition open source que Microsoft a extrait de VS Code pour le réutiliser ailleurs — dans GitHub.dev, dans le Cloud Shell du portail Azure, et maintenant dans le Wiki. Réutiliser ce composant plutôt qu’un éditeur Markdown générique a un avantage direct : les raccourcis clavier, le comportement de l’autocomplétion et la gestion de la sélection multi-curseur te sont probablement déjà familiers si tu passes tes journées dans VS Code. Rien à réapprendre pour profiter du nouvel éditeur.

Activer la preview

Le nouvel éditeur se branche depuis le menu Preview features d’Azure DevOps, activable pour ton compte personnel ou pour toute l’organisation. Une fois activé au niveau organisation, il s’applique à toutes les pages Wiki sans distinction — pas de bascule page par page.

Microsoft ne communique encore aucune date de disponibilité générale ni de date de fin de preview. Les retours passent par les commentaires du billet officiel ou par le portail Developer Community, le canal habituel pour ce genre de requête produit chez Microsoft.

Ce que l’annonce ne couvre pas

Pas un mot sur l’aperçu Markdown en lui-même (il existait déjà avant Monaco et n’a visiblement pas changé), pas de liste d’extensions ou de support de diagrammes, et aucune mention de limitation connue à ce stade de la preview. Si ton Wiki contient beaucoup de tableaux Markdown complexes ou de blocs Mermaid, vérifie leur rendu avant de généraliser l’activation à toute l’organisation — rien dans le billet officiel ne garantit qu’ils aient été spécifiquement testés avec le nouvel éditeur.

Ce changement s’inscrit dans une tendance plus large sur Azure DevOps cette année : moderniser les interfaces historiques une par une plutôt que de tout refaire d’un coup. On l’a vu récemment avec la nouvelle page de couverture de code des Pipelines, et avec l’arrivée de l’IA dans la revue de pull requests via Copilot Code Review.

FAQ

Le nouvel éditeur Wiki est-il disponible sur Azure DevOps Server, la version self-hosted ?

L’annonce officielle ne mentionne qu’Azure DevOps Services, la version SaaS. Pour Azure DevOps Server, mieux vaut suivre les notes de version dédiées plutôt que de supposer une disponibilité simultanée.

Est-ce que j’ai besoin de droits d’administration pour l’activer ?

Pour toi seul, non — l’activation individuelle se fait depuis ton propre menu Preview features. Pour l’activer au niveau de toute l’organisation, il faut les droits d’administration d’organisation.

Le contenu Markdown existant est-il affecté par le changement d’éditeur ?

Non, seul le composant d’édition change. Le contenu Markdown stocké reste identique — tu peux désactiver la preview et retrouver l’ancien éditeur sans perte de contenu.

Si tu gères un Wiki volumineux, le plus simple reste d’activer la preview sur ton compte perso quelques jours avant de la proposer à toute l’équipe — le temps de vérifier que les pages les plus utilisées, runbooks et procédures d’astreinte en tête, s’affichent et s’éditent sans surprise. Les détails complets de l’annonce sont sur le billet officiel Azure DevOps Blog.

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.

Depuis le 1er octobre 2026, Azure Pipelines propose un second pool d’agents à côté du pool Azure Pipelines classique : GitHub-hosted Agents, facturé à la minute, avec des machines plus costaudes que les agents Microsoft-hosted historiques — jusqu’à 16 cœurs côté Linux et Windows, et de l’Apple Silicon côté macOS. Les SKU macOS sont en disponibilité générale, les SKU Linux et Windows encore en preview publique, d’après l’annonce officielle d’Azure DevOps. Voici ce que ça change concrètement, et surtout combien ça coûte.

Un second pool, pas un remplacement

Le pool GitHub-hosted Agents tourne sur la même infrastructure que les runners GitHub Actions, dans les mêmes régions que le pool Microsoft-hosted existant. Chaque job démarre sur une VM fraîche, hébergeant un seul agent, réimagée dès la fin du job — même modèle d’isolation que ce que tu connais déjà sur Azure Pipelines.

Point important : activer ce pool ne touche à rien de ton côté. Tes pipelines existants restent sur leur pool actuel tant que tu ne changes pas explicitement le champ pool dans ton YAML. Aucune bascule automatique, aucune facturation tant qu’un job n’a pas réellement tourné sur une de ces machines.

Les tarifs, SKU par SKU

La facturation se fait à la minute d’exécution, par SKU — pas de ticket forfaitaire, pas de palier. Voici le tableau complet publié par Microsoft :

OS	SKU	Tarif/min	vCPU	RAM	SSD	Image
macOS	Standard	0,062 $	3 (arm64, M1)	7 Go	14 Go	macos-26-arm64
macOS	XLarge	0,102 $	5 + 8 cœurs GPU (arm64, M2)	14 Go	14 Go	macos-26-arm64-xl
Linux	8 cœurs	0,022 $	8 (x64)	32 Go	300 Go	ubuntu-24.04-8-core
Linux	16 cœurs	0,042 $	16 (x64)	64 Go	600 Go	ubuntu-24.04-16-core
Windows	8 cœurs	0,042 $	8 (x64)	32 Go	300 Go	windows-2025-8-core
Windows	16 cœurs	0,082 $	16 (x64)	64 Go	600 Go	windows-2025-16-core

Compare ça à un agent Microsoft-hosted classique (2 vCPU, 7 Go de RAM, 14 Go de disque, gratuit dans la limite de tes jobs parallèles) : le Linux 8 cœurs coûte 1,32 $ pour un job d’une heure. Pour un build qui tourne 20 fois par jour, ça grimpe vite — fais le calcul avant de migrer tes pipelines les plus actifs par réflexe.

Les images ubuntu-26.04-8-core, ubuntu-26.04-16-core, windows-2025-8-core et windows-2025-16-core sont encore en cours de déploiement et pas disponibles partout. Ubuntu 24.04 et Windows Server 2025 + Visual Studio 2026 le sont, eux, pour toutes les organisations ayant activé le pool.

Ce qui ne change pas côté facturation

Cette facturation à la minute est totalement séparée de tes jobs parallèles payants habituels — pas besoin d’en acheter, et ces jobs-là ne consomment pas ton quota existant. En contrepartie, il n’y a aucun palier gratuit : contrairement au pool Microsoft-hosted, tu payes dès la première minute sur GitHub-hosted Agents.

Activer le pool

Trois étapes, avec une subtilité à ne pas rater sur le délai :

1. Va dans Organization settings > Billing (il te faut la permission billing-settings).
2. Active Enable GitHub-hosted agents et enregistre.
3. Le provisionnement du pool peut prendre jusqu’à 24 heures — ne t’attends pas à voir le pool disponible instantanément après avoir cliqué.

Une fois le pool prêt, référence-le dans ton YAML par son nom et le label d’image qui correspond à l’OS et au SKU voulus :

pool:
  name: GitHub-hosted Agents
  vmImage: ubuntu-24.04-8-core

steps:
  - script: echo "Build sur agent GitHub-hosted 8 cœurs"

Pour du macOS XLarge par exemple, il suffit de remplacer la valeur par xcode-27-xlarge ; pour du Windows 16 cœurs avec Visual Studio 2026, par windows-2025-vs2026-16-core.

Surveiller la consommation

Deux endroits à connaître pour ne pas découvrir la facture en fin de mois : l’onglet Analytics du pool GitHub-hosted Agents, qui filtre les minutes consommées par SKU, projet et pipeline, et Azure Cost Management, qui permet de poser des budgets et des alertes par organisation et par projet. Mets au moins une alerte de budget avant de laisser une équipe entière basculer ses pipelines — le pay-as-you-go n’a pas de garde-fou intégré.

Faut-il migrer tes pipelines dessus ?

Pas systématiquement, et certainement pas tout de suite pour tout. Si tes builds actuels tiennent dans les 2 vCPU / 7 Go du pool Microsoft-hosted et restent sous ta limite de jobs parallèles, il n’y a aucune raison de payer à la minute pour la même chose. L’intérêt réel est ailleurs : les builds iOS/macOS qui ont besoin d’Apple Silicon natif plutôt que d’une émulation, les gros monorepos qui saturent 2 vCPU et passent leur temps à attendre l’I/O disque, ou les pipelines de build Docker multi-étapes qui tireraient vraiment parti de 16 cœurs et 600 Go de SSD. Pour ces cas-là, le calcul coût/temps gagné penche vite en faveur du pool GitHub-hosted, même en payant à la minute.

FAQ

Le pool GitHub-hosted remplace-t-il les agents Microsoft-hosted classiques ?

Non. Les deux coexistent. Le pool Azure Pipelines reste gratuit dans la limite de tes jobs parallèles ; GitHub-hosted Agents est une option payante en plus, pas un remplacement forcé.

Est-ce que j’ai des minutes gratuites avec GitHub-hosted Agents ?

Aucune. C’est facturé dès la première minute d’exécution, à la différence du pool Microsoft-hosted qui offre un quota mensuel gratuit selon ton plan.

Les images Ubuntu 26.04 et Windows Server 2025 (nouvelle vague) sont-elles disponibles chez moi ?

Pas forcément tout de suite : Microsoft les déploie progressivement. Vérifie leur disponibilité dans ton organisation avant de les référencer dans un pipeline critique.

Comment éviter une facture surprise ?

Pose un budget et une alerte dans Azure Cost Management dès l’activation du pool, et surveille l’onglet Analytics les premières semaines pour repérer les pipelines qui consomment le plus.

Si tu gères déjà des pools d’agents self-hosted pour éviter la queue du pool partagé, ça vaut le coup de comparer le coût réel du pay-as-you-go à celui de ta maintenance actuelle — les Managed DevOps Pools visaient déjà à alléger cette charge d’un autre côté. Et si le sujet qui te préoccupe plutôt, c’est la lisibilité de tes résultats de build, la nouvelle page de couverture de code d’Azure Pipelines publiée début octobre va dans le même sens d’amélioration continue du produit. Active le pool sur un seul projet test cette semaine, compare la facture réelle à tes jobs parallèles existants, et tu sauras en un cycle de sprint si la bascule vaut le coup pour le reste de ton organisation.

Pendant des années, consulter la couverture de code sur Azure Pipelines voulait dire télécharger un rapport HTML en artefact et le faire tourner en local pour y voir quelque chose de lisible. Depuis le sprint 278, ce détour n’est plus nécessaire : l’onglet Code Coverage a été refondu, avec une navigation par dossier/fichier, un aperçu du code source ligne par ligne et une vraie vue de détail par module. Le déploiement s’étale sur 2 à 3 semaines selon les organisations, donc tu l’as sans doute déjà sous les yeux — ou tu l’auras d’ici peu.

Ce qui change concrètement

L’ancien onglet se contentait d’un pourcentage global et d’un lien vers le rapport HTML brut. La nouvelle expérience ajoute trois choses utiles au quotidien : une arborescence dossier > fichier avec le taux de couverture agrégé à chaque niveau, une visualisation du code source où les lignes couvertes, partiellement couvertes et non couvertes sont surlignées directement, et une vue Détails qui permet de filtrer par module et par configuration de build. Le toggle vers l’ancien rapport HTML reste disponible, au cas où tu aurais des scripts ou des habitudes qui en dépendent.

Formats pris en charge pour profiter de l’expérience complète : Cobertura, JaCoCo, Clover, gcov, pcov et XML générique. Si tes rapports sont en .coverage, .cjson ou .covx, tu gardes l’onglet Code Coverage avec drill-down, mais seulement quand les mappings source sont disponibles — sinon tu restes sur l’ancien comportement.

Ce qu’il faut pour en profiter

Rien de nouveau à installer : la tâche Publish Code Coverage Results v2 suffit, et c’est elle qui alimente la nouvelle UI. Les tâches intégrées Visual Studio Test, .NET Core, Ant, Maven, Gulp, Grunt et Gradle savent déjà publier leur couverture dans un format compatible. Si ton pipeline utilise encore la v1 de la tâche, c’est le bon moment pour migrer — la v1 ne déclenche ni la nouvelle expérience ni la diff coverage sur les pull requests.

La diff coverage sur les pull requests, le vrai gain

Le point le plus intéressant n’est pas visuel, il est fonctionnel : tu peux maintenant imposer un seuil de couverture minimum sur les lignes modifiées d’une PR, pas sur l’ensemble du dépôt. Ça évite le découragement classique d’un vieux projet à 40 % de couverture globale où personne ne touchera jamais ce chiffre, tout en empêchant que du code neuf parte sans tests. La configuration se fait via un fichier à la racine du dépôt :

coverage:
  status:
    comments: on              # Off par défaut : poste le détail fichier par fichier en commentaire de PR
    diff:
      target: 60%              # Par défaut 70% : seuil minimum de couverture sur les lignes modifiées

Un target à 60 % plutôt que 70 % n’a rien d’arbitraire si ton équipe sort d’un legacy peu testé : mieux vaut un seuil réaliste qu’on respecte vraiment qu’un seuil ambitieux qu’on désactive après la première PR bloquée pour de mauvaises raisons.

Les limites à connaître avant de t’enthousiasmer

Cette diff coverage sur PR ne fonctionne aujourd’hui que pour Azure Repos — si ton code est sur GitHub avec un pipeline Azure DevOps qui le build, tu n’y as pas accès. Pour le reste, trois plafonds à garder en tête : 10 Go de pièces jointes par build pipeline au-delà desquels rien n’est traité, 7 Mo par fichier HTML au-delà desquels le rapport ne se charge plus dans la vue (télécharge l’artefact à la place), et plus de 100 fichiers modifiés dans une PR qui peut faire rester bloqué le contrôle de couverture — une limite qui va surprendre sur une grosse PR de refactoring. Et si ton pipeline est multi-stage, les résultats de couverture ne sont disponibles qu’une fois l’ensemble du pipeline terminé, pas stage par stage.

Dernier point pour les projets qui mixent .NET Core et .NET Framework : voir des DLL en double dans la vue est normal, ce n’est pas un bug de la nouvelle expérience.

FAQ

Dois-je changer quelque chose dans mon pipeline existant pour voir la nouvelle interface ?

Non, si tu utilises déjà Publish Code Coverage Results v2 avec un format supporté, la nouvelle vue s’affiche automatiquement dès que le rollout atteint ton organisation.

La diff coverage va-t-elle bloquer mes PR existantes dès son activation ?

Seulement si tu configures explicitement azurepipelines-coverage.yml avec une politique de branche associée à ce contrôle. Sans ce fichier, rien ne change dans ton comportement actuel.

Que se passe-t-il si mon rapport HTML dépasse 7 Mo ?

La vue HTML intégrée ne le charge pas. Tu dois télécharger l’artefact de rapport pour le consulter en local — vérifie aussi que tu ne publies pas des rapports non minifiés par erreur.

Pour aller plus loin

Si tu gères déjà tes agents de build via Managed DevOps Pools, c’est l’occasion de vérifier que tes images incluent bien les bons outils de génération de rapports de couverture (voir notre article sur Managed DevOps Pools). Et si Copilot Code Review tourne déjà sur tes PR (notre article sur sa mise en preview publique), la diff coverage est son complément naturel : l’un relit la qualité du code, l’autre vérifie que les lignes changées sont testées. Configure au moins un seuil réaliste sur tes dépôts Azure Repos actifs cette semaine — le fichier YAML tient en quatre lignes, il n’y a pas de bonne raison d’attendre.

Depuis le 26 août 2026, il n’y a plus besoin de s’inscrire sur une liste d’attente pour faire relire ses pull requests par une IA sur Azure Repos. GitHub Copilot Code Review est passé en preview publique, ouvert à tous les organisations Azure DevOps sans demande d’accès préalable. Concrètement : Copilot rejoint la liste des reviewers de ta pull request, lit le diff, et pose des commentaires ligne par ligne — exactement comme le ferait un collègue, sauf qu’il ne dort jamais et ne prend pas de café avant 9h.

Ce n’est pas un gadget marketing greffé sur Azure Boards. C’est une brique qui s’active en quelques clics, se facture au token, et s’intègre directement dans tes policies de branche existantes. Voici ce qu’il faut savoir avant de l’activer sur un vrai projet.

Ce que fait réellement Copilot Code Review

Une fois activé, GitHub Copilot apparaît comme reviewer disponible sur chaque pull request d’un dépôt Git (les dépôts TFVC ne sont pas supportés — encore une raison de migrer si tu es encore dessus). Tu peux le solliciter manuellement à la demande, ou laisser une policy de branche le déclencher automatiquement à chaque nouvelle PR.

Il pose ses commentaires directement sur les lignes concernées, et ces commentaires se comportent comme ceux d’un humain : tu peux y répondre, les résoudre, les masquer, réagir avec un emoji. Ce qu’il ne fait jamais en revanche, c’est bloquer une fusion ou approuver formellement une PR — sa review reste toujours au statut « Commentaire ». Et il ne relit pas automatiquement après un nouveau commit : si tu pousses un correctif, il faut redemander une review à la main. Pas de veille passive façon humain qui laisse traîner un onglet ouvert.

Trois niveaux d’effort, trois facturations différentes

Tu choisis entre Low, Medium et High au moment de la demande de review (ou tu fixes un niveau par défaut au niveau du projet ou du repo). Plus l’effort est élevé, plus Copilot consomme de tokens — et plus la facture grimpe. Pas de mystère marketing ici : Microsoft facture en GitHub AI credits, à 0,01 $ le crédit, calculés sur les tokens d’entrée, de sortie et les tokens mis en cache. La taille de la PR, tes instructions personnalisées et les mises à jour de modèle jouent aussi sur la note finale.

Pour une équipe qui traite des dizaines de PR par jour, le choix du niveau d’effort par défaut n’est pas un détail cosmétique — c’est une ligne de budget. Autant commencer en Low sur les repos à fort volume et réserver High aux PR touchant du code sensible (auth, paiement, infra), plutôt que de l’activer partout en mode maximal dès le premier jour.

Activer la fonctionnalité : organisation, projet, ou dépôt

L’activation se fait à trois niveaux, du plus large au plus ciblé :

• Organisation : Organization settings → Repos → Repositories, bascule « Allow repositories in this organization to use Copilot code review ». L’option « Enable all » active la fonctionnalité pour tous les projets et dépôts d’un coup.
• Projet : Project settings → Repos → Repositories, bascule équivalente qui s’applique à tous les dépôts du projet, sauf override au niveau dépôt. Cette étape est facultative si l’organisation a déjà tout activé.
• Dépôt : même chemin, sélectionne le repo concerné, onglet Settings, bascule « Enable Copilot code review for pull requests in this repository ». Une fois actif, GitHub Copilot doit apparaître dans la liste des reviewers disponibles sur une PR.

Pour l’exécution des reviews, tu peux garder le pool Azure Pipelines hébergé par défaut, ou pointer vers un Managed DevOps Pool que tu contrôles déjà — utile si tu veux garder la main sur l’image et le dimensionnement des agents. Une contrainte à connaître avant de t’y engager : seules les images Ubuntu Server récentes sont supportées, les images Windows sont exclues, et il ne faut pas mélanger agents Ubuntu et Windows dans le même pool. Les pools self-hosted classiques, eux, ne sont pas éligibles du tout.

Les limites concrètes à connaître avant de généraliser

Avant de brancher ça sur ton repo monolithique de 8 Go avec des PR de 300 fichiers, quelques plafonds à vérifier :

• Taille du dépôt : 10 Go maximum
• Fichiers modifiés par PR : 100 maximum
• Changements totaux : 100 maximum
• Reviews simultanées par organisation : 5
• Reviews simultanées par utilisateur : 2
• Une seule review complétée par commit de fusion

Autre point qui a son importance dans un vrai workflow : les pull requests en brouillon ne sont pas prises en charge. La PR doit être active, sans conflit de fusion, pour que Copilot accepte de la relire. Si ton équipe a l’habitude de solliciter des retours dès le brouillon, il faudra soit changer cette habitude, soit accepter que Copilot n’intervienne qu’une fois la PR passée en revue « officielle ».

Suivre la facture sans surprise

Les coûts remontent dans Azure Cost Management avec un délai de 48 heures après la fin d’une review — pas en temps réel, donc pas de tableau de bord pour surveiller la dépense minute par minute. Filtre sur la catégorie de compteur GitHub et la sous-catégorie GitHub Copilot for AzDO, puis regroupe par tag Organization ou Project pour savoir quelle équipe consomme quoi. Si plusieurs équipes se partagent le même abonnement Azure, configurer une alerte de budget (seuils à 75 % et 90 % par exemple, sur le produit « GitHub Copilot for AzDO ») évite la mauvaise surprise en fin de mois — un réflexe qui rejoint ce qu’on évoquait récemment sur le pilotage FinOps des charges liées à l’IA.

Faut-il l’activer dès maintenant ?

Pour une équipe qui fait déjà de la revue de code sérieuse (branch policies, reviewers obligatoires, checks CI bloquants), oui — activer Copilot en complément d’une review humaine, pas à sa place, a du sens dès la preview publique : le risque est faible (il ne peut jamais fusionner ni bloquer), le coût est maîtrisable en Low, et le gain (attraper les fautes d’attention avant l’œil humain) est réel. Pour une petite équipe sans process de review formalisé, en revanche, poser d’abord des branch policies et des reviewers humains obligatoires rapporte plus, tout de suite, que d’ajouter un reviewer IA à un processus qui n’existe pas encore.

FAQ

Copilot Code Review peut-il bloquer une fusion ?

Non. Sa review reste toujours au statut « Commentaire », jamais « Approuvé » ni « Rejeté ». Il ne peut donc pas empêcher une fusion à lui seul — il faut une policy de branche distincte pour ça.

Ça fonctionne sur des dépôts TFVC ?

Non, uniquement sur des dépôts Git. Si ton équipe est encore sur TFVC, c’est une raison de plus d’envisager la migration.

Faut-il une licence GitHub Copilot séparée ?

La fonctionnalité est disponible en preview publique pour tous les clients Azure DevOps, sans inscription préalable, mais la consommation se facture en crédits IA GitHub via ton abonnement Azure — vérifie la documentation officielle Microsoft Learn pour le détail exact de la facturation selon ton contrat.

Peut-on désactiver la fonctionnalité si les retours ne conviennent pas ?

Oui, à trois niveaux : pour un utilisateur (désactiver les « Preview features » dans ses réglages personnels), pour un dépôt (bascule au niveau repo), ou pour toute l’organisation (bascule au niveau organisation, qui coupe la fonctionnalité pour tous les projets).

Si tu gères plusieurs projets Azure DevOps, le plus simple reste de tester d’abord sur un seul dépôt à faible enjeu, de calibrer le niveau d’effort par défaut sur quelques semaines de PR réelles, puis de généraliser une fois que le rapport signal/bruit des commentaires de Copilot te convient. Et surtout : configure l’alerte de budget avant, pas après avoir découvert la facture.

Depuis cet été, Azure DevOps ne se contente plus d’orchestrer tes pipelines : il peut aussi répondre directement à tes assistants IA. Le Azure DevOps MCP Server, passé en disponibilité générale le 5 août 2026 pour la version distante puis peu après pour la version locale, donne à des outils comme GitHub Copilot, Visual Studio ou Claude un accès sécurisé à tes work items, tes pull requests, tes builds et ta documentation — sans que tu aies à copier-coller des identifiants d’espace de travail ou à écrire toi-même l’intégration. Si tu géres une organisation Azure DevOps et que tu commences à intégrer des assistants IA dans ton flux de travail quotidien, c’est le genre de brique qui t’évite de réinventer la roue à chaque nouvel outil.

Dans cet article, tu vas voir ce qu’est concrètement ce serveur MCP, la différence entre la version distante et la version locale, comment l’activer selon ton client IA, et surtout comment il s’intègre dans un modèle de sécurité basé sur Entra ID plutôt que sur des tokens qui traînent dans des fichiers de config.

Le Model Context Protocol, en deux mots

Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la façon dont un modèle de langage accède à des outils et des données externes. Concrètement, un serveur MCP expose un ensemble d’actions (lire un work item, lister des pull requests, lancer une recherche dans un dépôt) que n’importe quel client compatible — VS Code avec GitHub Copilot, Claude Desktop, Cursor, etc. — peut appeler de façon structurée, plutôt que de deviner la réponse à partir de son entraînement.

Pour toi, ça change la nature de la question que tu poses à ton assistant. Au lieu de lui décrire à la main l’état de ton sprint, tu peux littéralement lui demander « récupère les work items de mon sprint en cours, puis identifie ceux qui sont à risque de retard » et obtenir une réponse construite sur tes données réelles, pas sur des suppositions.

Serveur distant ou serveur local : lequel choisir ?

Azure DevOps propose deux façons de brancher le MCP Server, et le choix dépend surtout de ton client IA et de la structure de ton organisation.

Le serveur distant (recommandé par défaut)

Le serveur distant est un point de terminaison hébergé par Microsoft (transport HTTP en streaming), donc tu n’installes ni n’héberges rien toi-même — Microsoft gère les mises à jour. Il fonctionne nativement avec Visual Studio Code + GitHub Copilot, Visual Studio, Microsoft Foundry, Microsoft Copilot Studio, GitHub Copilot CLI et l’app GitHub Copilot. La configuration tient en quelques lignes dans ton fichier `mcp.json` :

{
  "servers": {
    "azure-devops": {
      "url": "https://mcp.dev.azure.com/{organisation}",
      "type": "http"
    }
  }
}

Point d’attention : le serveur distant s’authentifie via Microsoft Entra ID, ce qui suppose que ton organisation Azure DevOps soit adossée à un tenant Entra. Si tu es encore sur une organisation « compte Microsoft » (MSA) sans tenant Entra, ce mode n’est tout simplement pas disponible pour toi.

Le serveur local

Certains clients ne supportent pas encore l’enregistrement OAuth dynamique Entra requis par le flux d’authentification du serveur distant — c’est le cas de Claude Desktop, Claude Code, Cursor ou Codex au moment de la rédaction. Pour ces outils, Azure DevOps fournit un serveur MCP local qui tourne sur ta machine et couvre les mêmes catégories d’outils : work items, builds, recherche, dépôts et wiki. C’est un peu plus de friction à l’installation, mais ça te permet d’utiliser le même écosystème d’outils avec l’assistant de ton choix, en attendant que le support OAuth dynamique s’étende.

Ce que le serveur expose concrètement

Une fois connecté, ton assistant IA a accès à un ensemble d’outils qui couvrent la majorité de ce que tu ferais manuellement dans le portail Azure DevOps ou en ligne de commande avec l’extension Azure CLI :

• Consultation et mise à jour de work items (bugs, tâches, user stories)
• Lecture et gestion des pull requests
• Statut et déclenchement des builds/pipelines
• Plans de test
• Recherche dans le code et la documentation du projet (dont le wiki)

L’usage typique que Microsoft met en avant, c’est de rester dans ton éditeur ou ton interface de chat IA pour gérer des pull requests et des work items sans changer de contexte — un gain de temps réel si tu passes ta journée à jongler entre ton IDE et le portail web.

Sécurité : le vrai apport par rapport à un PAT dans un script

Ce qui rend ce serveur intéressant du point de vue admin/sécurité, ce n’est pas seulement le confort pour les développeurs — c’est le modèle d’authentification. Le serveur distant s’appuie sur Entra ID plutôt que sur des Personal Access Tokens à longue durée de vie stockés dans des fichiers de configuration ou des variables d’environnement. Ça rejoint une tendance de fond côté Azure DevOps cette année : le passage des connexions de service par PAT vers l’authentification par identité de charge de travail (workload identity federation), qu’on a déjà couverte en détail sur l’article sur les service connections fédérées. Le MCP Server suit la même logique : moins de secrets statiques à faire tourner, plus de contrôle centralisé via ton tenant.

Ceci dit, un assistant IA avec accès à tes work items et tes dépôts reste une surface d’attaque à prendre au sérieux si un prompt malveillant venait à circuler (via un ticket externe, par exemple). Microsoft documente d’ailleurs les bonnes pratiques de sécurité MCP dans sa note de blog sécurité dédiée — à lire avant de brancher ce type d’outil sur une organisation critique, et à mettre en regard des principes qu’on avait évoqués pour sécuriser les identités d’agents IA dans Entra ID.

Comment démarrer

Si ton client est déjà supporté nativement (VS Code + Copilot, Visual Studio, Foundry, Copilot Studio), la mise en route se limite à ajouter la configuration `mcp.json` pointant vers `https://mcp.dev.azure.com/{ton-organisation}` et à t’authentifier une première fois via Entra. Si tu utilises un client encore en attente de support OAuth dynamique (Claude Desktop/Code, Cursor, Codex), passe par le serveur local documenté sur la page officielle Microsoft Learn — l’installation prend quelques minutes et te donne accès aux mêmes catégories d’outils.

Dans les deux cas, commence par un projet non critique le temps de vérifier quels outils tu veux réellement exposer à ton assistant : Foundry, par exemple, te permet de sélectionner un sous-ensemble d’outils plutôt que d’ouvrir l’intégralité de la surface d’API — un réflexe de moindre privilège à appliquer systématiquement.

FAQ

Le MCP Server Azure DevOps est-il payant ?

Non, le serveur lui-même est gratuit. La tarification standard d’Azure DevOps s’applique à ton organisation et aux accès aux données ; selon la plateforme IA que tu utilises, des coûts séparés peuvent s’appliquer côté assistant.

Puis-je l’utiliser avec une organisation basée sur un compte Microsoft (MSA) plutôt qu’un tenant Entra ?

Pas avec le serveur distant, qui exige un tenant Entra ID. C’est une des raisons qui peuvent te pousser à migrer ton organisation vers un tenant Entra si ce n’est pas déjà fait.

Est-ce que ça remplace l’API REST Azure DevOps classique ?

Non, ça vient en complément. L’API REST reste la brique de base ; le MCP Server ajoute une couche standardisée pensée spécifiquement pour les clients IA agentiques, avec une gestion de contexte et de permissions adaptée à cet usage.

Pour aller plus loin

Le MCP Server est un bon indicateur de la direction que prend Azure DevOps : brancher l’IA directement sur les données de ton organisation, avec Entra ID comme socle de confiance plutôt que des secrets épars. Si tu pilotes des pipelines CI/CD et que tu commences à peine à explorer les assistants IA agentiques, c’est probablement l’un des points d’entrée les plus simples à tester cette semaine — sur un projet non critique, avec un sous-ensemble d’outils restreint pour commencer.

Si tes pipelines Azure DevOps utilisent encore des service connections basées sur un service principal avec secret ou pire, un Personal Access Token planqué dans une variable « secrète », tu portes une dette de sécurité qui n’a plus vraiment de raison d’être en 2026. Microsoft pousse depuis plusieurs mois une alternative sans secret, la Microsoft Entra Workload Identity Federation, désormais l’approche recommandée pour authentifier tes pipelines auprès d’Azure et même d’autres organisations Azure DevOps. Dans cet article, tu vas voir pourquoi ce changement compte, comment le mettre en place concrètement, et les pièges classiques à éviter.

Si tu es en train de revoir la façon dont tes pipelines s’exécutent, ça vaut aussi le coup de relire notre article sur les Managed DevOps Pools et la fin de la maintenance des agents : les deux sujets touchent à la même logique de simplification et de sécurisation de l’exécution de tes pipelines.

Le problème avec les service connections « classiques »

Une service connection Azure Resource Manager basée sur un service principal avec secret, c’est un identifiant et une chaîne secrète stockés côté Azure DevOps, avec une date d’expiration à surveiller manuellement. Deux soucis récurrents en découlent :

• Le secret doit être renouvelé régulièrement, et un oubli casse silencieusement tous les pipelines qui en dépendent, souvent un lundi matin.
• Le secret circule (portail Entra, connexion Azure DevOps, parfois des exports de configuration), ce qui élargit la surface d’attaque en cas de fuite.

Un Personal Access Token utilisé comme raccourci pose le même genre de problème, en pire : il est souvent lié à un compte personnel, avec des droits plus larges que nécessaire.

Ce que change le Workload Identity Federation

Avec la fédération d’identité, Azure DevOps n’a plus besoin de connaître un secret. Le pipeline s’authentifie via un jeton JWT éphémère, émis à la volée, vérifié par Microsoft Entra ID via une relation de confiance fédérée établie une fois pour toutes entre ton organisation Azure DevOps et ton tenant Entra. Concrètement, ça t’évite :

• de créer, stocker ou faire tourner un secret quel qu’il soit ;
• les pannes de pipeline liées à une expiration de secret non anticipée ;
• une bonne partie de la surface d’exposition en cas de fuite de configuration, puisqu’il n’y a simplement rien à voler.

Autre bénéfice concret : la fédération permet aussi de connecter proprement une organisation Azure DevOps à une autre organisation Azure DevOps (par exemple pour aller chercher un repo externe ou publier sur un flux d’artefacts partagé), sans passer par un PAT partagé entre équipes.

Mettre en place une service connection fédérée

La documentation officielle Microsoft détaille la procédure complète (Access Azure DevOps with Microsoft Entra workload identity), mais voici l’essentiel.

1. Ajouter le service principal ou la managed identity à l’organisation

Dans Organization Settings > Users > Add users, tu ajoutes l’identité (par son nom ou son Object ID Entra) avec un access level Basic, et tu l’assignes à un groupe avec les droits minimum nécessaires — évite de la mettre directement dans Project Collection Administrators par facilité.

2. Créer la connexion de service

Dans Project Settings > Service connections > New service connection, tu choisis le type Azure Resource Manager (ou Azure DevOps pour un accès cross-org) puis l’option workload identity federation, et tu sélectionnes l’identité créée à l’étape précédente.

3. L’utiliser dans un pipeline YAML

steps:
- task: AzureCLI@3
  inputs:
    connectionType: 'azureDevOps'
    azureDevOpsServiceConnection: 'my-azdo-connection'
    scriptType: 'pscore'
    inlineScript: |
      az devops project list --query "value[].{Name:name, Id:id}" -o table

Pour authentifier un flux d’artefacts NuGet, c’est tout aussi direct :

- task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: 'my-azdo-connection'

Managed identity ou service principal : lequel choisir ?

Les deux fonctionnent avec la fédération, mais la durée de vie du jeton diffère : environ 1h pour un service principal, contre 24h pour une managed identity. Si tes pipelines enchaînent des étapes longues (build + déploiement + tests d’intégration qui dépassent l’heure), préfère une managed identity pour éviter une expiration en plein milieu d’exécution.

Pièges et limitations à connaître

• Applications multi-tenant non supportées : configure ton app registration Entra en AzureADMyOrg, pas en AzureADMultipleOrgs.
• AADSTS700238 : un administrateur Entra doit explicitement autoriser la fédération d’identité de charge de travail au niveau du tenant avant que ça fonctionne — la même équipe qui gère tes politiques Conditional Access est généralement la bonne interlocutrice pour débloquer ce point.
• AADSTS70021 (« No matching federated identity record ») : le plus souvent une URL d’issuer ou un subject mal renseigné côté federated credential — à vérifier directement dans la boîte de dialogue d’édition de la connexion.
• Clouds souverains : certains environnements Azure souverains bloquent encore la fédération (erreur AADSTS900382) — vérifie la compatibilité avant de migrer un projet critique.
• Le service principal ou la managed identity doit être ajouté comme utilisateur dans chaque organisation Azure DevOps cible pour un accès cross-org, même si c’est la même identité Entra derrière.

Et côté sécurisation du code, quoi de neuf ?

Dans la même logique de renforcement de la sécurité des pipelines, Microsoft a aussi fait évoluer l’offre GitHub Advanced Security pour Azure DevOps, désormais disponible en deux produits indépendants plutôt qu’un seul bundle : GitHub Secret Protection (protection contre les fuites de secrets avant qu’elles n’arrivent) et GitHub Code Security (scan de dépendances et analyse CodeQL). Les clients existants ne sont pas impactés automatiquement — la bascule vers l’un ou l’autre produit se fait à la demande via le portail Azure. Plus de détails sur le blog officiel Azure DevOps.

FAQ

Le Workload Identity Federation remplace-t-il complètement les PAT ?

Pour l’authentification pipeline vers Azure ou vers une autre organisation Azure DevOps, oui, c’est l’option recommandée. Les PAT restent utiles pour certains scénarios d’automatisation en dehors des pipelines (scripts locaux, outils tiers), mais leur usage doit rester limité et avec une durée de vie courte.

Est-ce compatible avec les agents self-hosted ?

Oui, la fédération d’identité fonctionne aussi bien avec les agents Microsoft-hosted qu’avec des agents self-hosted ou des Managed DevOps Pools.

Ça coûte plus cher ?

Non, la fédération d’identité ne change rien à la facturation Azure DevOps — c’est une méthode d’authentification, pas un service payant.

En résumé

Si tu gères encore des service connections avec secret qui expirent tous les six ou douze mois, c’est le moment de planifier la bascule. Commence par un projet non critique pour valider la configuration Entra, documente les groupes de droits, puis généralise. Tu gagnes en sécurité, tu perds une corvée récurrente de rotation de secrets — difficile de trouver un meilleur compromis.

Tu en as marre de mettre à jour l’agent Azure Pipelines sur ta VM self-hosted, de recréer l’image quand une dépendance casse, ou de payer pour des runners qui tournent 24h/24 alors que tes builds ne durent que quelques minutes par jour ? Microsoft a justement sorti une réponse à ce problème : Managed DevOps Pools. Dans cet article, on regarde ce que c’est concrètement, comment le mettre en place, et si ça vaut le coup de migrer tes pools self-hosted existants.

Managed DevOps Pools, c’est quoi exactement ?

Managed DevOps Pools est un service Azure qui te fournit des pools d’agents Azure Pipelines entièrement gérés, hébergés dans l’infrastructure Microsoft (et non dans ton abonnement), mais que tu configures et factures depuis ton propre tenant Azure. En clair : tu gardes le contrôle sur l’image, la taille de VM, la région et les règles réseau, mais tu n’as plus à gérer le patching, le scaling ou le cycle de vie des machines.

C’est la même logique que les Microsoft-hosted agents classiques, sauf que tu peux personnaliser l’image (y compris avec Azure Compute Gallery), rattacher le pool à ton propre réseau virtuel, et bénéficier d’agents « standby » qui réduisent fortement le temps d’attente avant le démarrage d’un job.

Pourquoi c’est différent d’un pool self-hosted classique

Aspect	Managed DevOps Pools	Self-hosted classique
Gestion de l’infrastructure	Entièrement prise en charge par Microsoft	À ta charge (patching, mises à jour de l’agent, disque plein…)
Scaling	Automatique selon la charge des jobs en file	Manuel ou via tes propres scripts d’autoscaling
Sécurité	Intégration native Azure Key Vault, IP statiques, certificats racine auto-importés	À configurer toi-même sur chaque image
Coût	Facturé à l’usage, avec option Spot VM à venir	Coût fixe des VM, même à l’arrêt si mal dimensionné

Mettre en place ton premier Managed DevOps Pool

Prérequis

• Un abonnement Azure actif, avec le fournisseur de ressources Microsoft.DevOpsInfrastructure enregistré
• Les droits pour créer des ressources dans ton abonnement (rôle Contributeur ou équivalent)
• Une organisation Azure DevOps où tu as les droits d’administration des pools d’agents

Tu peux enregistrer le fournisseur de ressources en une commande Azure CLI :

az provider register --namespace Microsoft.DevOpsInfrastructure

Créer le pool

La création se fait depuis le portail Azure (recherche « Managed DevOps Pools » dans la barre de recherche) ou via une template ARM/Bicep si tu préfères tout piloter en Infrastructure as Code. Si tu gères déjà ton infra Azure avec Terraform, garde en tête que le provider azurerm ne couvre pas encore nativement cette ressource : il faut passer par le provider azapi en attendant. Si tu es en pleine migration vers AzureRM 5.0, c’est un bon moment pour vérifier ce genre de dépendances — on en parle en détail dans notre guide de migration Terraform AzureRM 5.0.

Une fois le pool créé et nommé, il suffit de le référencer dans ton pipeline YAML exactement comme un pool self-hosted classique :

trigger:
- main

pool:
  name: mon-pool-managed-devops

steps:
- script: echo "Build lancé sur un agent Managed DevOps Pool"
  displayName: 'Étape de build'

Aucune modification du reste de ton pipeline n’est nécessaire : c’est un remplacement transparent pour tes définitions de pool existantes.

Choisir son image

Tu as le choix entre les images Marketplace proposées par Microsoft (Windows Server 2025, Ubuntu 24.04 LTS…) et tes propres images personnalisées publiées dans une Azure Compute Gallery — pratique si ton pipeline dépend d’outils spécifiques déjà préinstallés. Microsoft retire régulièrement les images en fin de vie (Windows Server 2019 et Ubuntu 20.04 sont déjà hors support sur le service), donc prévois de suivre le calendrier des versions supportées pour éviter une mauvaise surprise le jour où une image bascule en obsolète.

Ce qui arrive prochainement

La roadmap du service reste active. Les fonctionnalités déjà livrées en 2026 incluent la suppression des images obsolètes, l’intégration à Log Analytics pour le monitoring, et récemment la possibilité de donner un alias personnalisé à un pool. Sont annoncées pour la suite : le support de plusieurs tailles de VM dans un même pool (Instance Mix), le recyclage manuel des agents, des scripts de démarrage personnalisés, le support des VM Spot (jusqu’à -90% de coût) et, plus tard dans l’année, des agents conteneurisés. De quoi rapprocher encore un peu plus ce service d’un pool self-hosted mais sans l’astreinte de maintenance.

FAQ

Managed DevOps Pools remplace-t-il complètement les agents self-hosted ?

Pas forcément. Si tu as besoin d’un accès à du matériel très spécifique (GPU particulier, périphérique physique, réseau on-premises complexe sans passer par un VNet peering) ou d’agents qui tournent en permanence sans coût à l’usage, le self-hosted classique reste pertinent. Pour la majorité des cas d’usage CI/CD standards, Managed DevOps Pools réduit nettement la charge opérationnelle.

Est-ce compatible avec les Microsoft-hosted agents existants ?

Oui, tu peux faire cohabiter les trois types de pools (Microsoft-hosted, Managed DevOps Pools, self-hosted) dans la même organisation et répartir tes pipelines selon leurs besoins.

Dans quelles régions le service est-il disponible ?

La liste des régions s’étend régulièrement ; à ce jour, Managed DevOps Pools couvre notamment l’Europe du Nord, la Suède, le Royaume-Uni, le Brésil, le Japon, la Corée, la Norvège et les Émirats Arabes Unis. Vérifie la documentation officielle Microsoft Learn pour la liste à jour avant de planifier un déploiement.

En résumé

Managed DevOps Pools répond directement à la douleur la plus commune des équipes qui gèrent leurs propres agents Azure Pipelines : le temps passé à maintenir l’infrastructure plutôt qu’à livrer du code. Si tu gères aujourd’hui un pool self-hosted qui te demande plus d’attention que prévu, c’est le moment de tester une migration progressive — un seul pipeline non critique suffit pour valider que tout fonctionne avant de généraliser. Consulte le guide de démarrage rapide Microsoft Learn et le dépôt de documentation sur GitHub pour suivre les évolutions du service au fil des mises à jour.