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.
Laisser un commentaire