La gouvernance comme condition d'entrée dans l'IA d'entreprise
Microsoft a pris une décision discrète lors de Build 2026 qui mérite bien plus d'attention qu'elle n'en a reçue : plutôt que de présenter un modèle plus puissant ou un agent plus capable, l'entreprise a mis en disponibilité générale l'Agent 365 SDK et l'a entouré de contrôles d'identité, de politique et de données qui s'activent au moment de la conception — et non pas lorsque l'agent a déjà causé des dégâts en production. Le pari implicite est que la capacité du modèle a cessé d'être le goulet d'étranglement pour les grandes organisations. Ce qui freine les projets d'agents n'est pas la puissance du système, mais l'incapacité à démontrer que quelqu'un sait ce que fait cet agent, avec quelles données, sous quelle autorisation et au nom de qui.
Ce n'est pas un argument technique. C'est un argument d'architecture du pouvoir au sein des organisations.
Car la raison pour laquelle les projets d'agents s'arrêtent en revue juridique, en comités de risque ou sur le bureau d'un RSSI n'est pas que le modèle soit mauvais. C'est que personne ne peut répondre à trois questions fondamentales : qui a approuvé l'existence de cet agent, ce qu'il peut toucher, et comment cela peut être démontré lors d'un audit. Microsoft a identifié ce goulet d'étranglement et a décidé de construire sa plateforme autour de lui.
Ce que Microsoft a compris et que ses concurrents continuent de résoudre par la vitesse
L'Agent 365 SDK arrive avec un registre centralisé que Microsoft décrit comme la « source de vérité » pour l'inventaire des agents d'entreprise. Ce registre se connecte avec Defender, Purview, Entra et Foundry, ce qui signifie que les contrôles de sécurité, d'identité et de conformité qu'une grande entreprise a déjà déployés n'ont pas besoin d'être répliqués pour les agents : ils s'étendent à eux. Chaque agent peut avoir une identité unique, séparée de tout utilisateur humain. Les administrateurs peuvent définir quels agents sont découverts, lesquels sont mis en quarantaine, qui les crée et dans quelles conditions ils opèrent.
Le registre détecte également les agents déjà en cours d'exécution sans que personne ne les ait approuvés. Microsoft indique que le système reconnaît plus de 20 types d'agents locaux, y compris les serveurs de Model Context Protocol, qui sont exactement le type d'infrastructure que les équipes d'ingénierie déploient rapidement sans passer par les achats. Parler d'« agent sprawl » est la manière élégante de dire que les organisations ont déjà des agents opérant en dehors de tout cadre de contrôle, et que c'est un problème de gouvernance avant même d'être un problème de sécurité.
Comparé à Google Cloud, qui a construit sa plateforme d'agents autour d'identités cryptographiques uniques par agent, et à AWS, qui a misé sur un chemin plus rapide et plus léger avec Bedrock AgentCore, Microsoft a choisi le terrain sur lequel il gagne déjà : l'infrastructure de contrôle que ses plus grands clients d'entreprise ont déjà installée et en laquelle ils ont déjà confiance. Ce n'est pas un avantage technique. C'est un avantage de capital social accumulé auprès des équipes de sécurité d'entreprise depuis deux décennies.
Le schéma qui émerge n'est pas le fruit du hasard. Les trois grands fournisseurs de cloud convergent vers la même architecture conceptuelle : un plan de contrôle pour les agents qui reproduit ce que Kubernetes a représenté pour les conteneurs. La différence est que Microsoft arrive avec Entra, Intune, Defender et Purview déjà intégrés dans la majorité des grandes entreprises. La gouvernance des agents n'arrive pas comme une nouvelle plateforme à justifier dans le budget. Elle arrive comme une extension de ce que l'équipe de sécurité opère déjà aujourd'hui.
Qui était dans la salle quand cela a été conçu, et ce que cela révèle
C'est ici que l'histoire devient plus intéressante du point de vue de la conception structurelle. L'Agent 365 SDK a été construit pour résoudre le problème de l'acheteur d'entreprise, et non celui du développeur qui veut aller vite. Les fonctionnalités que Microsoft a priorisées — le registre, le contrôle d'accès, la prévention des pertes de données en temps d'exécution, les contrôles Windows au niveau du système d'exploitation — sont conçues pour convaincre un RSSI, une équipe juridique ou un responsable de la conformité que l'agent est déployable. C'est un choix de conception qui révèle qui détient le droit de veto dans le cycle d'adoption.
Ce n'est pas un détail mineur. Quand une plateforme est conçue pour réduire la friction de l'auditeur avant celle du développeur, cela revient à reconnaître explicitement que le pouvoir de blocage dans les grandes organisations ne réside pas dans l'équipe technique. Il réside dans les fonctions de contrôle. Microsoft a parié qu'il gagnerait plus de parts de marché en convainquant l'équipe risques qu'en convainquant l'équipe ingénierie — et ce pari a des implications sur la façon dont d'autres entreprises devraient envisager l'adoption de leurs propres outils d'agents.
La question structurelle que cela soulève est de savoir qui était absent de cette salle de conception. Le SDK déclare une compatibilité avec n'importe quelle plateforme d'agents, et pas seulement celle de Microsoft, ce qui constitue un signal d'ouverture tactique. Mais l'architecture de contrôle la plus puissante opère à l'intérieur du périmètre de Windows, Entra et Microsoft Foundry. Une entreprise qui fait tourner des agents sur AWS, sur Google Cloud et sur un ensemble d'outils SaaS hérités gagne en visibilité à l'intérieur de la frontière Microsoft, et hérite simultanément d'une dépendance plus profonde envers cette frontière. La gouvernance multi-cloud reste, dans les faits, un problème non résolu par aucun des trois grands fournisseurs. Des éditeurs indépendants comme Saviynt ou TrueFoundry existent précisément parce que cette demande est réelle et n'est pas satisfaite par les plateformes des hyperscalers.
Il y a autre chose qui mérite d'être nommé avec précision : Microsoft a lancé l'Agent Governance Toolkit en tant que projet open source sous licence MIT en avril 2026, avant Build. L'entreprise le positionne comme le premier toolkit répondant aux dix risques de l'IA agentique identifiés par l'OWASP avec une application de politiques déterministe en moins d'une milliseconde. C'est un mouvement pour définir le standard avant que quiconque d'autre ne le fasse. Lorsqu'un acteur dominant publie le cadre de référence de la sécurité en open source, il ne fait pas preuve de générosité. Il place son architecture conceptuelle au centre de la conversation de l'industrie.
Le coût de la gouvernance qu'aucune présentation commerciale ne mentionne
Microsoft ne résout pas tous les problèmes qu'il crée. Il existe trois sources de friction que toute organisation adoptant cette architecture devrait nommer avant de s'y engager.
La première est qu'une partie importante de ce qui a été annoncé lors de Build 2026 est encore en version préliminaire, et non en disponibilité générale. L'intégration entre Defender et GitHub Code Security est disponible. Windows 365 pour les Agents est disponible. Mais le système MDASH de scanning agentique avec plus de 100 agents spécialisés, les contrôles d'exécution de Purview et plusieurs capacités de Defender restent en version préliminaire ou avec des dates à confirmer. Un plan de gouvernance construit sur des capacités en préversion est un plan avec un espace laissé en blanc.
La deuxième friction est opérationnelle. Chaque couche de contrôle qui protège l'organisation ralentit également le développeur. Les équipes qui surparamètrent les contrôles verront leurs ingénieurs chercher des chemins alternatifs, déployant des agents en dehors du registre parce que le processus d'approbation prend trois semaines. La gouvernance qui crée une friction excessive produit exactement le sprawl d'agents non gérés que le registre a été conçu pour détecter. C'est un problème de conception organisationnelle, et non de technologie.
La troisième friction est stratégique. Les organisations qui adoptent Agent 365 comme couche de contrôle gagnent une visibilité réelle à l'intérieur du périmètre Microsoft. Ce qu'elles héritent simultanément, c'est une dépendance plus profonde envers ce périmètre. Ce n'est pas un argument contre la plateforme. C'est une variable qui devrait apparaître dans toute décision d'architecture honnête. La portabilité de la gouvernance, à travers des standards comme Model Context Protocol que les trois grands fournisseurs affirment prendre en charge, peut ne pas être aussi disponible en pratique que dans les communiqués de presse.
L'identité non humaine comme nouvelle frontière du contrôle d'entreprise
Ce que Microsoft est en train de construire, lorsqu'on le décrit sans la terminologie produit, est un système d'identité et d'autorisation pour des entités qui ne sont pas humaines mais qui peuvent agir comme si elles l'étaient : lire des données sensibles, invoquer des outils, déclencher des processus, prendre des décisions au nom de l'organisation. Ce problème n'existait pas à cette échelle il y a deux ans.
L'implication budgétaire est directe. Les dépenses qui allaient à l'accès aux modèles et à l'expérimentation nécessitent désormais une ligne pour la couche d'identité et de gouvernance qui transforme les expérimentations en déploiements approuvés. Ces dépenses ne sont pas discrétionnaires dès lors que les agents peuvent lire des données et déclencher des actions de manière autonome. L'identité non humaine devient un problème de première importance, avec la même urgence avec laquelle les organisations traitent l'identité humaine depuis que le périmètre d'entreprise a cessé d'être un mur physique.
Le mouvement de Microsoft ne résout pas la question de savoir dans quelle mesure la gouvernance fonctionne bien lorsque l'organisation opère dans plusieurs clouds avec des dizaines d'outils SaaS et des agents construits sur des plateformes tierces. Mais il révèle bien la mécanique du pouvoir qui va déterminer quelles organisations pourront faire passer les agents à l'échelle, et lesquelles resteront piégées dans le cycle de projets pilotes qui meurent en revue juridique. La capacité à démontrer ce que chaque agent a fait, avec quelles données et sous quelle autorisation — avant qu'un régulateur ou un conseil d'administration ne le demande — est le critère qui va séparer ceux qui déploient de ceux qui expérimentent indéfiniment.
L'architecture que Microsoft a présentée lors de Build 2026 n'est pas la seule façon de résoudre ce problème. Mais c'est la première qui arrive packagée avec l'infrastructure de contrôle que les plus grandes organisations ont déjà installée. Cet avantage de distribution n'est pas technique. Il est structurel, et il est bien plus difficile à reproduire qu'un benchmark de sécurité.
