Microsoft a ajouté des interpréteurs de code sandboxés aux workflows d'agents d'Azure Logic Apps, avec Python, JavaScript, C# pis PowerShell qui roulent dans des sessions Hyper-V isolées sur les session pools d'Azure Container Apps (ACA). Le détail sous le capot qui compte pour les bâtisseurs : c'est de l'isolation au niveau VM, pas au niveau conteneur — des garanties plus fortes contre le breakout pis le code malveillant piloté par prompt injection que le typique sandbox Docker ou gVisor. La sélection de modèle par workflow est supportée, donc pas de lock-in à un provider LLM spécifique au-delà de la plateforme Azure elle-même.
L'exécution de code sandboxée a été le goulot chronique pour les workflows d'agents qui doivent calculer, transformer, ou visualiser. Jusqu'à récemment, les bâtisseurs assemblaient E2B, Modal, l'interpréteur de code d'OpenAI, ou roulaient le leur avec Firecracker ou des microVMs. L'intégration Logic Apps positionne l'interpréteur comme outil dans la boucle d'agent — le LLM génère du code, exécute en isolation, retourne le résultat, continue. Avec l'isolation réseau activée sur le session pool ACA, « les données ne quittent jamais les frontières réseau définies », c'est le phrasing compliance pour garder les données entreprise hors de la surface de leak d'agent. Le framing d'architecte dans l'annonce vise l'orchestration multi-systèmes entreprise — ERP, CRM, bases de données, APIs avec retry logic pis audit trails — pas le tooling d'agent greenfield.
La lecture écosystème, c'est que l'interpréteur de code VM-isolé devient une primitive cloud-native, pas un line item à bâtir soi-même. Hyper-V est plus lourd que les conteneurs — cold start plus lent, coût par exécution plus haut, mais l'architecture sécurité, c'est ce dont le déploiement d'agent entreprise a besoin une fois que les attaques prompt injection sur les surfaces tool-use deviennent réelles. AWS pis GCP ont des primitives analogues à des maturités variées (App Runner avec isolation, Cloud Run sandboxing, Sandbox API), pis la convergence des providers cloud sur des primitives d'interpréteur de code au niveau VM veut dire que la question « devrait-on utiliser E2B ou rouler le notre » obtient une troisième réponse : utilise la primitive cloud native si t'es déjà là. Le coût du lock-in est réel — Logic Apps + ACA = Azure-only — mais pour les orgs déjà sur Azure avec des besoins audit pis compliance, ça enlève une catégorie de risque « rouler son propre sandbox ».
Si tu bâtis des agents sur Azure lundi matin : c'est le changement qui fait de « l'agent exécute du code » une checkbox plutôt qu'un projet d'intégration de service. Si tu bâtis sur AWS ou GCP : track les équivalents pis attends-toi au même pattern architectural. Le shift, c'est l'exécution de code sandboxée qui passe de la responsabilité du bâtisseur d'agent à primitive du provider cloud, pis ce shift est structurel.