Vos work items Azure DevOps,
traités par l'agent que vous choisissez
Le sprint vit dans Azure Boards. Les user stories et les bugs qui vous sont assignés y sont, avec leurs étapes de reproduction, leurs critères d'acceptation et leurs captures. Ce que vous voulez, c'est un agent sur chacun, sur votre propre machine, dans le CLI qui convient à la tâche.
AgentsRoom importe ces work items dans le backlog du projet, avec leur description, leurs étapes de reproduction, leurs critères d'acceptation et leurs fichiers joints. Chacun devient un ticket que vous confiez à Claude Code, Codex, GitHub Copilot CLI, Cursor ou un autre CLI d'agent, un agent par ticket. L'import ne fait que lire : rien n'est jamais réécrit dans Azure DevOps.
Deux projets Azure DevOps, une requête WIQL, un agent par ticket : l'import lit Azure DevOps et n'y écrit jamais.
Azure Boards, c'est là que beaucoup d'équipes de l'écosystème Microsoft planifient le travail : le backlog, le sprint, le bug arrivé ce matin. Claude Code, Codex et les autres CLI d'agents, c'est là que, de plus en plus, ce travail se fait. Entre les deux, la méthode habituelle reste le copier-coller : le titre dans un prompt, les étapes de reproduction derrière, et les captures perdues en route.
L'import Azure DevOps fait cette étape à votre place. Vous connectez votre organisation avec un jeton d'accès personnel, vous choisissez un projet ou écrivez une requête WIQL, vous prévisualisez les work items et vous les importez. Ils arrivent dans la colonne À faire du backlog du projet comme des tickets ordinaires, avec la description, les étapes de reproduction et les critères d'acceptation convertis en Markdown et les fichiers joints téléchargés, et vous lancez un agent sur chacun comme sur n'importe quel ticket.
Ce n'est pas une synchronisation dans les deux sens. AgentsRoom n'envoie à Azure DevOps que des requêtes de lecture : aucun changement d'état, aucun commentaire, aucun champ modifié. Si vous voulez qu'un agent commente un work item ou le ferme, c'est le rôle du serveur MCP Azure DevOps de Microsoft, et les deux fonctionnent ensemble, comme expliqué plus bas.
Ce que fait l'import Azure DevOps
Une source de plus pour le backlog, à côté de Jira, Linear, GitHub Issues et Notion.
Un projet ou votre propre WIQL
Choisissez un de vos projets dans la liste, avec un champ de recherche quand il y en a des dizaines, et la requête s'écrit toute seule : tout ce qui est encore ouvert dans ce projet, le plus récemment modifié en tête. Ou écrivez le WIQL vous-même : un chemin de zone, une itération, un tag, ou AND [System.AssignedTo] = @Me pour ne garder que vos work items.
Un seul work item, par son numéro
Vous n'avez besoin que du bug qu'on vient de vous confier ? Collez 1234, #1234, AB#1234 ou le lien du work item avec le bouton d'import de la colonne À faire. Il arrive tout seul, en haut de la colonne, sans toucher à l'import enregistré.
Étapes de reproduction et critères d'acceptation compris
Azure DevOps range la spec dans plusieurs champs HTML. L'import convertit la description, les étapes de reproduction et les critères d'acceptation en Markdown, puis ajoute un court bloc de contexte : type, état, zone, itération, priorité, story points et parent. L'agent lit la spec telle que l'équipe l'a écrite.
Des pièces jointes que l'agent peut ouvrir
Les fichiers joints au work item, et les images collées dans son texte, sont derrière votre connexion Azure DevOps : un lien ne servirait à rien à l'agent. L'import les télécharge sur votre ordinateur et les joint au ticket, jusqu'à 10 par work item.
Un type et un état qui ont du sens
Bug, User Story, Product Backlog Item, Feature, Epic, Task : les types intégrés des processus Basic, Agile, Scrum et CMMI donnent le type du ticket, et le type du work item reste en tag. Le statut terminé se lit dans la catégorie de l'état, pas dans son nom : un work item fermé dans votre processus arrive terminé, que l'état s'appelle Closed, Done ou porte un nom à vous.
Lecture seule, jeton sur votre machine
Le jeton n'a besoin que de deux droits de lecture, rien de plus. Il est chiffré sur votre ordinateur et n'atteint jamais nos serveurs ; seule la requête suit le projet sur vos autres machines, où vous collez le jeton à nouveau.
Comment ça marche
Quatre étapes. Les deux premières se font une fois par machine.
- 1
Créer un jeton d'accès personnel
Dans Azure DevOps, ouvrez User settings, puis Personal access tokens, et créez un jeton pour votre organisation avec deux droits : Work Items (Read) et Project and Team (Read). Aucun droit d'écriture n'est nécessaire.
- 2
Connecter votre organisation
Dans le backlog du projet, cliquez sur Importer des tickets et choisissez Azure DevOps. Saisissez le nom de l'organisation (ce qui suit dev.azure.com/, ou collez l'adresse complète) et le jeton.
- 3
Choisir et prévisualiser
Choisissez un projet ou écrivez une requête WIQL, puis cliquez sur Aperçu. Cherchez dans la liste par numéro ou par titre, cochez les work items voulus et importez-les, jusqu'à 500 à la fois.
- 4
Confier chaque ticket à un agent
Les work items sont maintenant des tickets dans À faire, chacun avec un lien vers Azure DevOps. Choisissez un agent et un modèle, cochez Coder dans un worktree séparé pour cette tâche si vous la voulez sur sa propre branche, et glissez le ticket dans En cours. Actualiser remet le tableau à jour plus tard.
Ce que Microsoft et les CLI d'agents font déjà de leur côté
Microsoft publie un serveur MCP pour Azure DevOps (microsoft/azure-devops-mcp sur GitHub). Pour le serveur local, sa documentation donne claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp contoso pour Claude Code et codex mcp add azure-devops -- npx -y @azure-devops/mcp contoso pour Codex, où contoso est le nom de votre organisation ; par défaut, un navigateur s'ouvre pour vous connecter avec votre compte Microsoft. L'agent reçoit alors des outils pour les work items, les dépôts, les pipelines, les wikis et les plans de test, depuis sa session.
Microsoft fait aussi tourner une version hébergée de ce serveur, disponible pour tous depuis le 5 août 2026. Son annonce précise que Claude Code, Claude Desktop, ChatGPT et Cursor ne peuvent pas encore s'y connecter, parce qu'il leur faut un enregistrement OAuth que Microsoft Entra ne leur propose pas pour l'instant : ces utilisateurs restent donc sur le serveur local. Azure Boards peut aussi envoyer un work item à l'agent de code GitHub Copilot avec le bouton Copilot du work item, disponible pour tous depuis décembre 2025 : le code doit être dans un dépôt GitHub, et l'agent répond par une pull request en brouillon sur GitHub, pas par une session sur votre ordinateur.
L'import AgentsRoom répond à un autre besoin : les work items sur un tableau, à côté de vos autres tickets, avec un agent par work item sur votre propre machine et dans le CLI que vous choisissez, y compris les CLI qui n'ont aucune intégration Azure DevOps, et que le code soit dans Azure Repos, sur GitHub ou ailleurs. Les deux ne s'excluent pas : importez les work items pour planifier et lancer le travail, et donnez à un agent le serveur MCP de Microsoft quand il doit commenter ou fermer son work item lui-même.
À savoir
- Azure DevOps Services uniquement (dev.azure.com). Azure DevOps Server, installé sur vos propres serveurs, n'est pas pris en charge.
- Une organisation par ordinateur. Pour importer depuis une deuxième organisation, connectez-la à la place de la première.
- Dans un seul sens : rien ne repart vers Azure DevOps, même une fois le ticket livré ici. Fermez le work item vous-même, ou donnez à l'agent le serveur MCP de Microsoft.
- Le jeton reste sur l'ordinateur qui l'a connecté. Sur une autre machine, le bouton du tableau affiche Reconnecter, avec un badge Azure DevOps non connecté, tant que vous n'y avez pas collé un jeton.
- Jusqu'à 500 work items par import, et jusqu'à 10 fichiers joints par work item.
- Les commentaires, le responsable, les liens autres que le parent et l'historique ne sont pas importés : le ticket porte le titre, la description, les étapes de reproduction, les critères d'acceptation, le bloc de contexte, les tags et les fichiers.
- Connecter Azure DevOps et écrire la requête se font sur le desktop. Depuis le téléphone, vous pouvez actualiser l'import ou faire venir un work item par son numéro ; les deux tournent sur votre ordinateur, qui doit être allumé.
Questions fréquentes
Est-ce la même chose que le serveur MCP Azure DevOps de Microsoft ?
Non. Le serveur MCP de Microsoft donne à un agent des outils pour lire et modifier Azure DevOps depuis sa session, sur les CLI qui prennent en charge MCP. L'import AgentsRoom fait venir les work items sur le backlog du projet avant qu'un agent démarre, pour que vous puissiez les planifier, confier chacun à un agent différent et les suivre sur le tableau. Vous pouvez utiliser les deux : l'import pour organiser le travail, le serveur MCP pour un agent qui doit commenter ou fermer son work item.
Claude Code peut-il utiliser Azure DevOps ?
Oui, de deux façons. Dans une session, ajoutez le serveur MCP local de Microsoft avec claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp contoso (le nom de votre organisation à la place de contoso) : l'agent peut alors chercher, lire et modifier des work items lui-même. Le serveur MCP hébergé de Microsoft n'accepte pas encore Claude Code, selon son annonce du 5 août 2026. Avant la session, importez les work items dans AgentsRoom et confiez chacun à un agent Claude Code : la description, les étapes de reproduction, les critères d'acceptation et les fichiers arrivent à l'agent avec sa tâche.
AgentsRoom met-il à jour le work item quand l'agent a terminé ?
Non. L'import n'envoie que des requêtes de lecture, avec un jeton qui n'a que des droits de lecture : aucun changement d'état, aucun commentaire, aucun champ modifié. Quand le ticket est livré ici, vous faites avancer le work item dans Azure DevOps vous-même, ou vous laissez un agent le faire par le serveur MCP de Microsoft.
Puis-je importer seulement les work items qui me sont assignés ?
Oui, en WIQL : choisissez le projet, puis ajoutez AND [System.AssignedTo] = @Me à la requête qu'il écrit. Vous pouvez aussi filtrer sur un chemin d'itération, un chemin de zone ou un tag. La requête est enregistrée avec le projet : Actualiser la rejoue plus tard.
Puis-je faire venir seulement le work item qu'on vient de m'assigner ?
Oui. Utilisez le bouton d'import de la colonne À faire et collez son numéro (1234, #1234 ou AB#1234) ou son lien. Il arrive en haut de À faire sans changer l'import enregistré, et il peut être actualisé seul plus tard depuis le ticket.
Mon jeton Azure DevOps quitte-t-il mon ordinateur ?
Non. Il est stocké chiffré sur l'ordinateur qui l'a connecté, avec le nom de l'organisation, et n'atteint jamais nos serveurs. Les pièces jointes ne sont téléchargées que depuis l'organisation connectée : le jeton n'est jamais envoyé à un autre hôte. Seule la requête d'import est enregistrée sur votre compte, pour que l'import suive le projet sur vos autres machines, où vous collez le jeton à nouveau.
Quels CLI d'agents peuvent travailler sur un work item importé ?
Les 17 CLI d'agents pris en charge par AgentsRoom (Claude, Codex, GitHub Copilot CLI, Cursor et 13 autres). Un work item importé est un ticket ordinaire : il tourne sur l'agent et le modèle que vous lui assignez, dans la copie de travail partagée ou dans son propre worktree git.
Est-ce que ça marche avec Azure DevOps Server ou Team Foundation Server ?
Pas aujourd'hui. L'import parle à Azure DevOps Services, sur dev.azure.com. Les équipes sur Azure DevOps Server, installé sur leurs propres serveurs, peuvent toujours donner à un agent un serveur MCP Azure DevOps qui prend en charge leur installation.
Vous aimerez aussi
Import de tickets
Faites venir vos tickets Jira, Linear, GitHub Issues, Azure DevOps ou Notion sur un seul backlog et confiez chacun à Claude Code, Codex, Cursor ou un autre CLI d'agent, sur votre machine. Lecture seule.
Import Jira
Importez vos issues Jira Cloud dans AgentsRoom et confiez chacune à Claude Code, Codex, Cursor ou un autre CLI d'agent, sur votre machine. Projet ou JQL, pièces jointes comprises. Lecture seule.
Gestion de tâches
Tableau kanban visuel pour orchestrer vos agents IA par glisser-deposer. Créez des tâches dans TODO, glissez-les vers En Cours pour lancer automatiquement un agent Claude, et suivez l'avancement dans les colonnes En Attente et Termine. Développement pilote par le backlog avec du codage IA en parallele.
Worktrees git
Donnez à chaque agent IA ou ticket son propre worktree git, prêt à compiler (dépendances installées, .env copiés), puis relisez, commitez et fusionnez-le dans une seule fenêtre.
Serveurs MCP
Déclarez un serveur MCP une seule fois et donnez-le à Claude Code, Codex et tous les CLI d'agent. Choisissez-le dans le registre MCP officiel, gardez les clés dans le Gestionnaire de secrets, et connectez les serveurs OAuth comme Notion ou Linear avec un seul bouton Connecter.
Confiez vos work items Azure DevOps à vos agents
Téléchargez AgentsRoom, ouvrez votre dépôt comme projet, puis cliquez sur Importer des tickets dans son backlog et choisissez Azure DevOps.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.