Si votre organisation fonctionne avec Microsoft, le parcours agents commence probablement là : Copilot pour les utilisateurs, Copilot Studio ou Foundry pour construire, peut-être une évaluation d’Agent Framework pour le custom. C’est un point de départ raisonnable — et rien sur cette page vous dit d’abandonner cela.
Cette page couvre la partie du parcours que la stack Microsoft ne couvre pas : ce qui se passe quand vos agents doivent être gouvernés en tant que tout — y compris ceux qui n’ont pas été construits à Redmond.
Reconnaissance où elle est due
Microsoft a fait plus que quiconque pour faire des agents des citoyens de première classe de l’entreprise. Mi-2026, Entra Agent ID donne des identités d’annuaire réelles avec owners, RBAC et Conditional Access, et Agent 365 enveloppe registre, logs d’audit et compliance Purview — disponible avec prix publié par utilisateur. Si vous attendiez une identité agent réelle et supportée — c’est maintenant.
La question n’est pas si Microsoft peut gouverner des agents. C’est quels agents — et ce qui suit la gouvernance.
Trois questions avant de verrouiller le chemin
1. Combien de produits pour la chaîne complète — et qui possède le tout ?
L’histoire agents Microsoft couvre Agent 365, Entra Agent ID, Foundry, Copilot Studio et Purview. Chacun est bon dans son rôle. Mais l’assemblage est à vous : architecture, intégration, owner interne du résultat combiné. Avant de committer : qui dans l’organisation possède le tout — pas chaque produit, le tout ? Dans notre expérience la réponse honnête est souvent « floue », et l’écart apparaît tard, en production.
2. Et les agents que les équipes ont déjà construits ailleurs ?
Dans beaucoup d’organisations les agents ne attendent pas la décision plateforme. Marketing a un agent research dans Claude. Un ingénieur exécute trois via OpenAI. Ils existent aujourd’hui, font un travail réel et sont hors du plan de gouvernance Microsoft. La réponse Microsoft est d’amener les workloads dans la stack — Foundry peut héberger des frameworks externes, et la sync de registre cross-cloud est en preview (août 2026). La direction est vers l’intérieur. Si votre réalité est des agents dans plusieurs stacks — qui y restent — vous avez besoin d’une couche conçue pour ne pas se soucier où un agent a été construit.
3. Où une personne métier approuve ce qu’un agent fait ?
L’Agent Framework Microsoft donne de solides primitives human-in-the-loop — tool approval, request/response ports. Mais c’est du plumbing SDK : votre équipe conçoit, construit et maintient la surface où un humain dit oui ou non. Demandez à voir cette surface comme produit pour un owner métier, pas un développeur. Puis décidez si vous voulez du budget engineering pour le construire et le posséder.
Où Copyl s’intègre — à côté, pas en remplacement
Copyl est une couche opérationnelle indépendante et européenne pour les agents. Elle ne remplace pas Copilot Studio ni Foundry — ce sont encore d’excellents endroits pour construire. Elle se situe au-dessus, et au-dessus de toute autre plateforme de build, avec un job : faire de n’importe quel agent un membre gouverné et accountable de l’organisation.
Concrètement aujourd’hui : prenez la définition d’un agent — construit dans Copilot Studio, Claude, ChatGPT ou manuellement — exprimez-la en JSON ouvert Agent Manifest, et exécutez dans un sandbox gouverné. Zéro credentials, chaque appel externe capturé plutôt qu’exécuté, transcription complète et proposition de ce que l’agent aurait besoin pour exécuter réellement. Environ une minute du paste à la première exécution gouvernée. Les décisions risquées — comptes réels, scopes réels — viennent après avoir vu que ça fonctionne, et le chemin vers la production se construit sur des grants explicites et sign-off.
Deux choses structurelles suivent de l’indépendance. Copyl traite chaque plateforme de build pareil — Microsoft inclus — car nous n’avons pas de modèle ou cloud vers lequel vous orienter ; un vendor avec une stack à vendre ne peut être une couche neutre au-dessus des concurrents. Pour les organisations européennes, notamment publiques, la gouvernance agents sous un vendor EU indépendant est une posture de souveraineté différente de la gouvernance intégrée dans le plan d’identité d’un hyperscaler US.
Sur le coût : une distinction compte plus que les chiffres — Microsoft price la stack par utilisateur humain plus consommation. Décision de gouvernance et modèle de coût sont la même décision. Comparez le coût du travail qu’un agent réalise, avec les lignes de consommation incluses — pas seulement la ligne licence.
Quand Agent 365 suffit
Honnêtement : si vos agents sont construits dans les outils Microsoft, n’agissent que sur des systèmes Microsoft, sont utilisés par des utilisateurs Copilot déjà licenciés et vous n’avez pas besoin d’indépendance de stack ou de gouvernance souveraine EU — utilisez la stack native. Elle est intégrée, dans votre renewal, et une couche neutre n’ajouterait que de la complexité.
La couche neutre gagne sa place quand une assomption se brise : agents de plus d’une plateforme, systèmes au-delà des vendors, exigences de souveraineté, ou un chemin que vous n’êtes pas prêt à verrouiller.
Essayez sans rien décider
La façon la plus rapide d'évaluer n'est pas une présentation — c'est votre propre agent dans un sandbox gouverné. Prenez une définition que vous avez déjà (ou l'exemple complet dans la référence manifest) et exécutez-la :
Importer votre agent →Pas de credentials, pas de migration, pas de décision de plateforme. Votre roadmap Microsoft reste telle quelle — vous voyez vos agents, tous, gouvernés au même endroit.
Construisez votre agent n'importe où. Exécutez-le gouverné. · Référence Agent Manifest