Le 2 juin 2026, Microsoft a ouvert son Build avec un message central : Windows devient une plateforme de premier niveau pour les agents IA. L'annonce phare est le lancement du Windows Agent Runtime et de son SDK MXC (Microsoft Execution Containers), une couche d'exécution sécurisée qui confine chaque agent dans un périmètre défini par politique, appliqué directement par le kernel Windows. Pour les DSI, CTO et équipes techniques qui réfléchissent à déployer des agents IA en entreprise, c'est un changement d'architecture structurant — et un signal fort sur la direction prise par l'écosystème Microsoft pour les années à venir.
Avant Build 2026, déployer un agent IA sur Windows signifiait superposer des couches de sécurité applicatives sur un OS qui n'avait pas été conçu pour ce type de logiciel autonome. Les agents IA, par nature, lisent des fichiers, appellent des API, écrivent dans des bases de données — souvent sans supervision humaine directe. L'absence de frontières natives posait un problème réel de traçabilité, de conformité et de réduction du rayon d'impact en cas d'erreur ou de compromission. MXC et le Windows Agent Runtime répondent à ce problème au niveau le plus bas de la pile logicielle.
Windows Agent Runtime : l'OS comme plateforme agentique
Le Windows Agent Runtime est le terme générique utilisé par Microsoft pour désigner la couche OS qui traite les agents IA comme des citoyens de premier rang, avec une identité forte, des frontières d'isolation et une gestion enterprise intégrée. C'est l'équivalent pour les agents de ce que Windows a fait pour les services NT dans les années 1990 : leur donner une place officielle dans l'architecture du système, avec les mécanismes de contrôle qui vont avec.
Cette approche tranche avec la pratique courante de 2025, où un agent IA tournait souvent dans un simple processus applicatif, sous les credentials de l'utilisateur qui l'avait lancé, avec un accès non délimité aux ressources locales. Le Windows Agent Runtime formalise un contrat entre l'agent et l'OS : l'agent déclare ce dont il a besoin, le système enforce ce périmètre, et toute activité est enregistrée sous une identité distincte.
Microsoft a également annoncé à Build 2026 que Copilot est désormais reconstruit comme une plateforme multi-modèles capable de router les tâches vers différents LLM selon le contexte — une architecture qui illustre concrètement la vision de Windows comme orchestrateur d'agents hétérogènes. Le Windows Agent Runtime fournit les briques de bas niveau qui rendent cette orchestration sécurisée et auditée.
MXC : un bac à sable kernel pour chaque agent
MXC (Microsoft Execution Containers) est un SDK qui permet aux développeurs de déclarer par configuration ce qu'un agent peut accéder — fichiers, réseau, API — le kernel Windows appliquant ces règles à l'exécution, sans que le code de l'agent lui-même n'ait à les gérer.
Le SDK s'articule autour d'un schéma de configuration JSON : le développeur spécifie les droits de l'agent (quels répertoires il peut lire ou écrire, quels domaines réseau il peut atteindre, quels niveaux d'API il peut appeler), et le runtime enforce ces limites. MXC offre plusieurs modes d'isolation selon le niveau de risque de la tâche :
- Isolation de processus : l'agent est séparé du bureau de l'utilisateur, du presse-papier et des périphériques d'entrée. Cette séparation bloque les vecteurs d'attaque classiques dans les environnements agentiques — UI spoofing, injection d'entrée clavier, fuite de données inter-sessions.
- Isolation de session : pour les agents à plus fort risque, une session dédiée garantit l'étanchéité complète vis-à-vis des autres processus utilisateur.
- Intégration Intune : les équipes IT peuvent définir des politiques MXC centralisées via Intune — règles sur le système de fichiers, restrictions réseau — exactement comme pour la gestion des postes de travail classiques.
L'un des avantages architecturaux de MXC par rapport aux approches basées sur des containers Docker non orchestrés est la profondeur de l'intégration OS : les politiques sont enforced par le kernel, pas par une couche logicielle tierce qui peut être contournée ou qui nécessite une mise à jour séparée.
Pour les équipes qui construisent des agents accédant à des données sensibles — ERP, CRM, documents RH, contrats clients — cette granularité de contrôle change le profil de risque du déploiement. Nous intégrons ce type de contrainte dès la phase de conception dans nos projets d'automatisation métier.
Identité, Entra et gouvernance d'entreprise
Chaque agent exécuté sous MXC se voit attribuer une identité distincte — locale ou cloud via Microsoft Entra ID — ce qui rend toutes ses actions traçables et auditables, séparément des actions des utilisateurs humains.
C'est l'un des points les plus structurants pour les DSI et les équipes de conformité. Aujourd'hui, beaucoup d'agents IA tournent sous les mêmes credentials que l'utilisateur humain qui les a initialisés. Résultat : impossible de distinguer dans les logs ce que l'humain a fait de ce que l'agent a fait, ce qui complique les audits et rend l'analyse post-incident peu fiable.
MXC résout ce problème en attribuant à chaque conteneur d'agent une identité propre, liée à Entra ID pour les organisations cloud. Cette identité est reconnue par l'ensemble de la chaîne Microsoft :
- Microsoft Defender surveille les activités de l'agent et peut détecter des comportements anormaux (accès inhabituels, tentatives d'escalade).
- Microsoft Purview peut appliquer des politiques de conformité sur les accès documentaires de l'agent — par exemple, empêcher un agent de lire des fichiers classifiés au-delà de son niveau d'autorisation.
- Les logs sont directement exploitables par le SIEM de l'entreprise (Microsoft Sentinel ou autre), avec l'identité agent clairement taggée pour chaque événement.
Cette intégration est annoncée en préversion pour juillet 2026, dans Windows 11 24H2 éditions Enterprise et Pro, avec l'intégration Defender, Entra, Intune et Purview disponible simultanément. Pour les organisations qui ont déjà déployé la suite Microsoft 365, il n'y a pas d'infrastructure supplémentaire à provisionner.
Le sujet de la gouvernance des agents IA est plus large que MXC seul — nous l'avons détaillé dans notre article sur la gouvernance et sécurité des agents IA en entreprise, qui couvre les patterns de contrôle d'accès, d'audit et de validation humaine pour des workflows agentiques critiques.
Ce que ça change pour les PME et ETI françaises
Pour une organisation déjà sur Microsoft 365, MXC est la première couche de sécurité native pour les agents IA, sans infrastructure supplémentaire, administrable depuis les outils IT existants (Intune, Entra, Defender).
Trois implications concrètes pour les PME et ETI françaises qui envisagent — ou ont déjà — des agents IA dans leurs processus :
1. Réduction du risque réglementaire : un agent qui accède à des fichiers RH, des données clients ou des contrats fournisseurs dans un périmètre non défini est un risque réglementaire direct — RGPD, NIS 2, ou simplement les obligations contractuelles vis-à-vis de vos clients grands comptes. MXC permet de définir précisément l'exposition dès la conception du système, et de le prouver documentairement.
2. Traçabilité pour les auditeurs : l'identité Entra distincte de l'agent produit des logs exploitables. Lors d'un audit de conformité ou d'un incident de sécurité, il devient possible de reconstruire exactement ce que l'agent a lu, modifié ou déclenché — sans dépendre de logs applicatifs maison potentiellement incomplets.
3. Pilotage centralisé depuis Intune : pas de nouveau panneau de contrôle à apprendre. Les politiques MXC s'administrent depuis la console Intune existante. Pour les équipes IT déjà rodées sur Microsoft 365, la courbe d'apprentissage est limitée et les processus d'approbation existants (change management, DSI) s'appliquent directement.
Un point de vigilance : MXC est encore en early preview et sa disponibilité générale n'est prévue que fin 2026. Les organisations qui déploient des agents IA dès maintenant ne peuvent pas encore s'appuyer sur MXC en production. Il reste pertinent de concevoir les architectures d'agents avec ces contraintes en tête pour faciliter la migration dès la disponibilité générale. Notre approche de développement sur mesure intègre ces contraintes dès la conception pour éviter des refactorisations coûteuses.
Disponibilité et feuille de route
MXC est disponible en early preview depuis juin 2026 pour les développeurs Windows. La disponibilité générale dans Windows 11 24H2 (éditions Enterprise et Pro) est prévue pour la fin 2026, suivie de Windows Server 2027.
Pour les équipes techniques qui veulent tester dès maintenant, le SDK MXC est accessible via le Windows Developer Blog. L'intégration complète Defender / Entra / Intune / Purview arrive en préversion en juillet 2026, couverte par les licences Microsoft 365 Enterprise existantes.
La feuille de route de Windows Agent Runtime s'inscrit dans un mouvement plus large de Microsoft vers un OS agentique. À Build 2026, Microsoft a également annoncé Microsoft Scout, un assistant personnel capable de surveiller des sources d'information (GitHub, Microsoft 365), de coordonner des tâches entre applications et de suivre l'avancement de projets à travers les outils de l'organisation. Scout s'appuiera sur Windows Agent Runtime et MXC pour son exécution locale sécurisée.
Pour les organisations qui évaluent dès maintenant comment intégrer des agents IA dans leurs processus métier de façon sécurisée et pérenne, notre travail sur les architectures d'agents pérennes et notre offre d'outil interne sur mesure constituent des points de départ concrets. La gouvernance par le kernel que propose MXC va dans le même sens que nos recommandations d'isolation des périmètres d'action des agents.
FAQ — Microsoft Build 2026 : MXC et Windows Agent Runtime sécurisent l'exécution de vos agents IA
À quoi sert concrètement le SDK MXC annoncé à Microsoft Build 2026 ?
MXC (Microsoft Execution Containers) est un SDK qui permet aux développeurs de déclarer par configuration ce qu'un agent IA peut accéder — fichiers, réseau, API — et au kernel Windows d'enforcer ces règles à l'exécution. L'objectif est de confiner chaque agent dans un périmètre précis, auditable, sans que le code de l'agent lui-même n'ait à gérer ces restrictions. C'est une couche de sécurité au niveau OS, pas au niveau applicatif.
MXC est-il disponible dès maintenant sur Windows 11 ?
MXC est en early preview depuis juin 2026. Sa disponibilité générale dans Windows 11 24H2 (éditions Enterprise et Pro) est prévue pour la fin 2026. L'intégration avec Defender, Intune, Entra et Purview arrive en préversion en juillet 2026. En attendant, les développeurs peuvent expérimenter avec le SDK via le Windows Developer Blog, mais MXC n'est pas encore destiné à la production.
Comment MXC s'intègre-t-il avec les outils de sécurité Microsoft existants ?
Chaque agent exécuté sous MXC reçoit une identité distincte liée à Microsoft Entra ID. Cette identité est reconnue par Defender (surveillance comportementale), Purview (politiques de conformité documentaire) et Intune (administration centralisée des politiques d'accès). Les logs produits sont directement exploitables par un SIEM comme Microsoft Sentinel. Pour les organisations déjà sur Microsoft 365, l'intégration ne nécessite pas d'infrastructure supplémentaire.
En quoi MXC diffère-t-il d'un container Docker pour exécuter un agent IA ?
Docker isole au niveau du système de fichiers et du réseau, mais ne s'intègre pas nativement aux systèmes d'identité et de conformité d'entreprise (Entra, Intune, Purview). MXC offre une isolation comparable avec une intégration profonde dans la chaîne Microsoft 365 : l'agent a une identité Entra, ses actions sont auditées par Defender, et ses politiques d'accès sont administrées centralement depuis Intune, comme n'importe quel autre asset Microsoft 365.
MXC est-il pertinent pour une PME qui n'est pas encore sur Microsoft 365 ?
MXC apporte le plus de valeur aux organisations déjà dans l'écosystème Microsoft 365 (Entra ID, Intune, Defender), car c'est là que l'intégration est la plus directe. Pour une organisation sans cet écosystème, les bénéfices de MXC sont plus limités à court terme. Dans ce cas, des approches alternatives de gouvernance des agents — isolation par design, contrôle d'accès applicatif, audit de logs — restent pertinentes indépendamment de l'OS.