Fini le grand agent généraliste unique dans Azure Copilot. Depuis le 1er août 2026, Microsoft a retiré ce qu'elle appelait le « Agent mode » combiné, ce mode de chat unique capable d'endosser plusieurs rôles à la demande, pour le remplacer par une ligne de six agents nommés et spécialisés. Et pour les administrateurs, la manière de les activer change du tout au tout.
Un agent généraliste qui devient six agents experts
Jusqu'à fin juillet, Azure Copilot proposait un mode de conversation unique où l'assistant pouvait, selon la demande, se comporter comme un aide au déploiement, un outil de diagnostic ou un conseiller d'optimisation de coûts. Pratique sur le papier, mais flou dans les faits : difficile de savoir précisément ce que l'agent avait le droit de faire, et avec quel niveau de fiabilité, selon la tâche demandée.
Microsoft a tranché en éclatant cette expérience en six agents distincts, chacun avec son propre statut de release et son propre mode d'accès : un agent d'observabilité, un agent de déploiement, un agent de troubleshooting, un agent d'optimisation, un agent de résilience et un agent de migration.
Seul l'agent d'observabilité a atteint la disponibilité générale (GA) à ce stade. Les cinq autres — déploiement, troubleshooting, optimisation, résilience, migration — restent en préversion publique, ce qui signifie que leur comportement peut encore évoluer avant stabilisation.
Pourquoi ce découpage a du sens
Ce choix n'est pas qu'une question de branding. Un agent généraliste qui touche à tout — du diagnostic d'incident à la recommandation de migration — porte un risque diffus : des permissions larges, un comportement difficile à auditer, et une responsabilité floue en cas d'action malheureuse sur une ressource de production.
En nommant et en isolant chaque agent, Microsoft permet à une organisation d'activer, par exemple, uniquement l'agent d'observabilité pour son équipe SRE, sans ouvrir la porte à un agent qui pourrait proposer — voire déclencher — une migration de charge de travail. Chaque agent a son propre périmètre de permissions, ce qui facilite l'audit et réduit la surface d'erreur.
C'est une approche que je trouve plus saine que la course à l'agent « couteau suisse » qu'on voit ailleurs dans l'industrie. Un agent qui fait une chose bien, avec un statut de release clair (GA ou preview), est plus facile à faire confiance qu'un agent qui prétend tout savoir faire.
La fin de l'allowlisting : accès direct via l'Admin Center
Le second changement, plus discret mais tout aussi structurant, concerne l'administration. Avant le 1er août, l'accès à Azure Copilot passait par un processus d'allowlisting : une organisation devait faire une demande, attendre une validation, avant de pouvoir activer l'agent pour ses équipes.
Ce système disparaît. Microsoft lance un Azure Copilot Admin Center, une console où les administrateurs peuvent activer ou désactiver chaque agent individuellement, sans étape d'inscription ni délai d'attente. L'accès devient instantané et granulaire, agent par agent.
Pour un DSI ou un administrateur cloud, c'est à double tranchant. D'un côté, la friction disparaît : plus besoin d'attendre une validation pour tester l'agent de troubleshooting sur un environnement de test. De l'autre, cette facilité d'activation impose une vigilance accrue côté gouvernance : sans processus de validation externe, c'est à l'organisation elle-même de définir qui peut activer quoi, et sur quel périmètre de ressources.
Ce que ça change concrètement pour les équipes Azure
Pour les équipes qui utilisaient déjà le mode combiné, la transition demande un temps d'adaptation : les habitudes de prompt changent, puisqu'il faut désormais solliciter le bon agent pour la bonne tâche plutôt que de tout demander au même point d'entrée.
Pour celles qui n'avaient pas encore testé Azure Copilot, faute d'accès validé via l'ancien allowlisting, c'est l'occasion d'entrer directement par l'Admin Center et de commencer par l'agent d'observabilité, le seul en GA et donc le plus stable pour une première évaluation en conditions réelles.
Mon conseil : ne pas activer les cinq agents en préversion en même temps sur un tenant de production. Le statut « Public Preview » chez Microsoft veut dire exactement ce qu'il dit — comportement encore mouvant, pas de garantie de SLA. Tester d'abord sur un environnement non critique, agent par agent, avant de généraliser.
Ce qu'il faut retenir
Ce découpage d'Azure Copilot en agents spécialisés confirme une tendance de fond chez Microsoft : après l'euphorie des assistants généralistes, l'heure est à la granularité et à la gouvernance. Un agent, une responsabilité, un statut de release clair — c'est plus facile à administrer, plus facile à auditer, et probablement plus facile à faire adopter par des équipes IT prudentes.
À surveiller dans les prochaines semaines : le calendrier de passage en GA des cinq agents encore en préversion, et la manière dont l'Admin Center gèrera les journaux d'audit pour chaque agent activé.
