Managed DevOps Pools : la fin de la maintenance des agents Azure Pipelines

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

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.