Azure pousse les plateformes à devenir agent-first et isole chaque exécution dans un microVM
Le 23 septembre 2026, Mike Hulme, directeur marketing produit d’Azure, décrit le basculement des applications vers des systèmes multi-agents qui agissent en continu, et la réponse de Microsoft : gouverner l’agent sur Foundry, l’exécuter dans un sandbox isolé d’Azure Container Apps. Pour les équipes plateforme, c’est une grille de lecture concrète sur ce qui doit changer quand l’agent remplace la requête.
23 septembre 2026. Mike Hulme, directeur général du marketing produit Azure chez Microsoft, publie un billet qui décrit moins un lancement qu’un basculement de paradigme. Depuis des décennies, les applications sont conçues pour attendre : un utilisateur clique, une requête arrive, le code tourne, une réponse repart. Ce qui change désormais, ce n’est pas l’infrastructure en dessous, mais le logiciel au-dessus : le travail qu’on encodait en code déterministe est réécrit en applications multi-agents qui décident de leurs étapes à l’exécution. Pourquoi c’est important : une application qui répond et un agent qui agit n’ont pas les mêmes besoins en dessous d’eux, et la plupart des plateformes sont encore construites sur les hypothèses de la première.
L’agent ne travaille pas comme une requête
Un agent, une fois un résultat fixé, raisonne sur le problème, le découpe en étapes, écrit du code pour le résoudre, exécute ce code, regarde le résultat, et recommence. Le travail se déroule dans une boucle à l’intérieur de laquelle aucun humain ne se tient. Mike Hulme pose le constat sans détour : « les organisations qui prennent de l’avance ne se contentent pas d’ajouter de l’IA à ce qu’elles ont déjà, elles conçoivent pour un autre type de logiciel ».
La difficulté n’est plus de faire fonctionner un agent. Une équipe peut brancher un modèle capable sur quelques outils, l’ancrer dans les données de l’entreprise, et obtenir un pilote convaincant en une semaine. La vraie distance se situe entre ce pilote et un agent dont l’entreprise dépend vingt-quatre heures sur vingt-quatre.
Un agent qui opère en continu au nom d’une société est tenu au même standard que tout le reste de la production. Il lui faut une identité propre, avec des permissions limitées à ce qu’il est autorisé à voir. Il doit être observé pendant qu’il travaille, pour tracer chaque étape, évaluer si le résultat était correct, et repérer la dérive qui apparaît silencieusement des semaines après la mise en ligne. Il lui faut des garde-fous appliqués à l’exécution. Et il doit passer les mêmes contrôles de sécurité et de conformité que le reste du parc — personne n’accordera d’exemption à un agent.
Deux couches distinctes : gouverner, puis exécuter
La réponse de Microsoft sépare deux responsabilités que la plupart des équipes confondent. Microsoft Foundry est l’endroit où les agents sont construits, ancrés dans la connaissance d’entreprise, dotés d’une identité de premier ordre via Entra Agent ID, puis tracés et évalués une fois en production. Le Foundry Control Plane gouverne l’agent — mais il ne dicte pas où le travail de l’agent s’exécute. C’est une décision distincte, et une couche distincte.
Là où le travail s’exécute, les choses se corsent. Dès qu’un agent cesse de répondre à des questions et commence à accomplir des tâches, il doit exécuter du code : cloner un dépôt, installer un paquet, lancer une analyse sur des données vivantes, appeler un système de référence. Cette exécution a besoin d’un environnement d’exécution — et dans la plupart des cas, elle hérite tout simplement de celui de l’application hôte, par le chemin de moindre résistance.
C’est là que la plupart des agents prometteurs calent. Faites tourner l’agent sur une infrastructure partagée et chaque charge hérite du rayon d’explosion de toutes les autres. Donnez-lui un accès large pour qu’il soit utile et vous avez remis à un processus autonome bien plus de portée que prévu. Verrouillez-le jusqu’à ce qu’il soit sûr, et l’agent ne peut plus faire le travail pour lequel vous l’avez construit.
Azure Container Apps Sandboxes : isoler l’exécution, pas le pouvoir
La réponse n’est pas de limiter ce que l’agent peut faire, mais de lui donner un environnement dédié, avec sa propre identité et ses propres garde-fous. Azure Container Apps Sandboxes fournit exactement cela. Chaque exécution d’agent reçoit un environnement entièrement isolé, créé en quelques secondes et disparu une fois le travail terminé. Il s’exécute sous une identité que vous contrôlez, ne peut atteindre que les systèmes que vous avez autorisés, et ne stocke jamais les identifiants qu’il utilise pour y accéder. Quand une tâche s’étale sur des heures ou des jours, l’environnement peut être mis en pause puis repris avec son contexte de travail intact.
Derrière, il y a de la vraie ingénierie : chaque environnement tourne dans son propre microVM à isolation matérielle, ce qui rend possible à la fois une séparation forte et un démarrage sub-seconde. Mais le mécanisme n’est pas le propos. L’isolation est intégrée à l’exécution plutôt qu’enroulée autour, pour que les équipes cessent de choisir entre un agent capable et un agent contrôlé. Et rien ne disparaît dans le sandbox : l’agent reste gouverné par Foundry, si bien que ce qu’il a envoyé dans le sandbox et ce qui en est revenu restent consignés avec chacune de ses autres étapes.
Le pattern qui émerge : deux cas d’école
La combinaison dessine un motif récurrent dans les grandes entreprises : construire et gouverner sur Foundry, étendre l’exécution dans un sandbox isolé d’Azure Container Apps. L’agent conserve son identité, ses permissions, sa supervision — seul le terrain sur lequel il s’exécute change. KPMG, via sa plateforme Digital Gateway, fait tourner plus de 30 000 sandboxes Azure Container Apps simultanément pour isoler les données clients par engagement. Cognite, pour ses opérateurs industriels, fait exécuter du code arbitraire par des agents Atlas AI dans des sandboxes qui isolent chaque utilisateur, chaque environnement et chaque donnée — transformant une enquête manuelle de plusieurs jours sur « quels puits sous-performent et pourquoi » en une réponse citée en quelques minutes.
Ce que l’isolation matérielle change vraiment
La nuance tient au mot « matérielle ». La plupart des sandboxes d’exécution — conteneurs, espaces de noms, machines virtuelles logicielles — isolent au niveau du noyau ou de l’hyperviseur, en partageant une partie de la surface d’attaque avec l’hôte. Azure Container Apps Sandboxes monte chaque exécution dans un microVM à isolation matérielle : la séparation est garantie par le processeur, pas seulement par une configuration logicielle.
Ce choix change la nature du compromis. Un sandbox logiciel démarre vite, mais sa frontière repose sur la qualité de la configuration et des correctifs. Un microVM à isolation matérielle conserve un démarrage sub-seconde tout en offrant une frontière que des charges de confiance différente ne franchissent pas — le genre de garantie qu’un RSSI accepte de voir partagée entre plusieurs clients sur une même infrastructure.
Le second effet est comptable. Quand l’isolation est matérielle, la confiance accordée à un agent ne dépend plus de l’endroit où il tourne ni de la charge qui tourne à côté. C’est ce qui permet de faire passer une organisation d’une poignée d’agents supervisés à des milliers d’exécutions concurrentes, sans demander aux équipes sécurité de renoncer à leurs standards.
Verdict
Si vous concevez une plateforme interne pour des agents, retenez la séparation : la gouvernance (identité, traçabilité, évaluation) est une couche, l’exécution isolée en est une autre, et les fusionner revient à faire hériter à chaque charge le rayon d’explosion de toutes les autres. Si vous êtes sur Azure, testez Azure Container Apps Sandboxes pour vos agents qui exécutent du code : le microVM à isolation matérielle avec démarrage sub-seconde résout le compromis « capable mais incontrôlable » qui bloque la plupart des passages en production. Si vous êtes ailleurs, le motif reste transposable : ce n’est pas l’agent qu’il faut restreindre, c’est le sol sous ses pieds qu’il faut isoler.