En explorant les nouveautés autour d’Azure Container Apps, je suis tombé sur une fonctionnalité particulièrement intéressante : Azure Container Apps Sandboxes.
Le concept peut sembler assez simple au départ : créer rapidement un environnement isolé dans lequel exécuter du code.
Mais en regardant un peu plus loin, on réalise que Microsoft propose quelque chose de beaucoup plus intéressant : des microVM isolées, programmables, capables de démarrer en moins d’une seconde, de conserver leur état et de revenir à zéro lorsqu’elles ne sont plus utilisées.
Et avec l’arrivée des agents IA capables d’exécuter du code, de manipuler des fichiers ou d’utiliser différents outils, je trouve que le timing est particulièrement intéressant.
Une Sandbox, concrètement, c’est quoi ?
Une Sandbox est essentiellement un environnement d’exécution isolé.
Chaque Sandbox dispose de sa propre frontière de sécurité et de son propre kernel. Elle peut être créée à partir d’une image OCI, exécuter des commandes, manipuler des fichiers et exposer des ports.
Mais ce qui m’intéresse particulièrement est son cycle de vie.
Une Sandbox peut être démarrée, arrêtée, suspendue, reprise ou supprimée.
On peut également créer un snapshot de son état, incluant la mémoire et le disque, puis restaurer cet environnement ultérieurement. Microsoft annonce un démarrage et une reprise en moins d’une seconde grâce à son architecture basée sur des pools préchauffés.
Et lorsqu’une Sandbox est arrêtée, elle ne génère plus de frais de CPU ou de mémoire.
C’est cette combinaison qui rend selon moi la fonctionnalité particulièrement intéressante :
isolation + démarrage rapide + état persistant + scale-to-zero.
Le premier cas d’utilisation évident : les agents IA
C’est probablement le scénario qui m’intéresse le plus.
Imaginez un agent IA auquel vous demandez :
Analyse ce dépôt, exécute les tests, modifie certains fichiers et vérifie que l’application compile toujours.
Le problème est assez évident.
À un certain moment, votre agent doit réellement exécuter quelque chose.
Et je n’ai certainement pas envie de lui donner directement accès au système qui héberge mon application principale.
Avec ACA Sandboxes, on peut imaginer une architecture dans laquelle chaque tâche ou chaque agent dispose de son propre environnement isolé.
L’agent peut y télécharger ou cloner des fichiers, lancer des commandes, installer ou utiliser des outils, compiler du code et produire des résultats.
Une fois son travail terminé, la Sandbox peut être suspendue.
Lorsque l’utilisateur revient quelques minutes ou quelques heures plus tard, elle peut être reprise avec son état précédent.
Microsoft positionne d’ailleurs explicitement les Sandboxes pour les AI Apps & Agents, avec des espaces de travail isolés et persistants capables de survivre entre plusieurs étapes d’une tâche.
Pour moi, c’est probablement l’un des scénarios les plus intéressants.
Exécuter du code généré par une IA sans faire confiance à ce code
Les LLM sont maintenant capables de générer du Python, du JavaScript, des scripts Bash ou même des applications complètes.
Mais générer du code et exécuter du code sont deux problèmes complètement différents.
Si mon application permet à un utilisateur de demander :
Analyse ce fichier Excel et génère-moi quelques graphiques.
Un LLM pourrait générer un script Python pour effectuer l’analyse.
Mais où vais-je exécuter ce script ?
Je ne veux évidemment pas exécuter du code généré dynamiquement directement sur mon serveur applicatif.
Une Sandbox permet justement de créer une frontière claire :
Application → Sandbox isolée → exécution du code → récupération du résultat → destruction ou suspension de la Sandbox.
Chaque Sandbox disposant de sa propre isolation, un problème dans l’environnement d’exécution ne doit pas compromettre les autres workloads.
C’est une approche que je trouve beaucoup plus naturelle pour construire des fonctionnalités de Code Interpreter ou des applications capables d’exécuter du code fourni par leurs utilisateurs.
Des environnements de développement à la demande
Autre scénario que j’aime beaucoup : les environnements de développement temporaires.
Imaginez une plateforme interne dans laquelle un développeur clique sur :
Create Development Environment
Quelques secondes plus tard, il dispose d’un environnement avec les outils nécessaires à son projet.
Il travaille pendant quelques heures puis ferme son environnement.
Au lieu de conserver une VM active toute la nuit, la Sandbox peut être suspendue.
Le lendemain, elle reprend avec son état précédent.
On obtient donc quelque chose qui ressemble à un environnement de développement personnel, mais avec une infrastructure capable de scale-to-zero lorsqu’elle n’est pas utilisée.
Microsoft cite justement les environnements de développement par utilisateur comme l’un des principaux scénarios de Sandboxes.
Je trouve le modèle particulièrement intéressant pour une Internal Developer Platform.
Une Sandbox par utilisateur
On peut pousser cette idée encore plus loin.
Certaines applications SaaS doivent fournir à chaque utilisateur un environnement de calcul relativement puissant et surtout isolé.
Un IDE dans le navigateur.
Un environnement Linux interactif.
Un laboratoire de formation.
Une plateforme permettant d’exécuter du code.
Un environnement d’analyse de données.
Plutôt que de partager le même runtime entre tous les utilisateurs, on peut créer une Sandbox par utilisateur ou par session de travail.
Microsoft indique que les Sandbox Groups peuvent contenir des milliers de Sandboxes et que la plateforme est conçue pour monter jusqu’à des milliers d’environnements concurrents.
C’est particulièrement intéressant pour les architectures multi-tenant où l’isolation entre utilisateurs est une exigence importante.
Des runners CI/CD éphémères
Autre cas d’utilisation qui m’a immédiatement interpellé : les pipelines CI/CD.
Un pipeline a souvent besoin d’un environnement temporaire pour :
cloner le code, restaurer les dépendances, compiler l’application, exécuter les tests et produire un artifact.
Puis l’environnement ne sert plus à rien.
C’est exactement le type de workload pour lequel des environnements éphémères ont du sens.
Microsoft cite d’ailleurs explicitement les CI runners parmi les scénarios possibles.
On pourrait imaginer créer une Sandbox pour chaque job ou pipeline, exécuter le build dans un environnement complètement isolé puis détruire l’environnement.
Pour des organisations qui utilisent aujourd’hui des pools de VMs dédiés uniquement pour fournir des agents de build, c’est une approche que je trouve particulièrement intéressante à surveiller.
Browser automation et agents autonomes
Un autre scénario auquel je pense immédiatement est l’automatisation de navigateurs.
Avec Playwright, Chromium ou d’autres outils similaires, un agent peut naviguer sur un site, effectuer des opérations et récupérer des informations.
Mais encore une fois, cela nécessite un environnement dans lequel lancer le navigateur et exécuter le code d’automatisation.
Une Sandbox devient alors un excellent candidat.
Une tâche → une Sandbox → un navigateur → exécution → résultat → destruction.
Microsoft mentionne d’ailleurs explicitement le browser automation parmi les workloads possibles.
Avec la montée des agents autonomes capables d’interagir avec des interfaces Web, ce scénario pourrait devenir beaucoup plus fréquent.
Les snapshots sont probablement l’une des fonctionnalités les plus intéressantes
C’est un aspect que j’aime particulièrement.
Une Sandbox peut être suspendue en conservant son état mémoire et son disque.
On peut également créer des snapshots et utiliser ceux-ci pour restaurer ou cloner des environnements.
Imaginez que je prépare un environnement avec :
.NET, Node.js, Python, Git, certains outils CLI et toutes les dépendances nécessaires à mon projet.
Je peux préparer cet environnement une fois puis utiliser son état comme point de départ pour plusieurs Sandboxes.
Cela ouvre des scénarios intéressants pour les environnements de développement, les laboratoires de formation, les tests reproductibles ou encore les agents IA.
Plutôt que de reconstruire l’environnement à chaque fois, je peux repartir d’un environnement déjà préparé.
Et le réseau ?
C’est évidemment une des premières questions que je me pose lorsque je découvre ce genre de service.
Une Sandbox capable d’exécuter du code non fiable ne devrait probablement pas avoir un accès Internet complètement ouvert.
Microsoft fournit justement un egress proxy permettant de contrôler les communications sortantes avec des règles d’autorisation ou de blocage par domaine et par réseau.
Encore plus intéressant : le mécanisme permet également de faire de la credential injection.
Cela signifie que la Sandbox peut accéder à certains services sans nécessairement stocker directement les credentials à l’intérieur de son environnement.
Et pour les architectures d’entreprise, les Sandbox Groups peuvent également être intégrés à un Azure Virtual Network afin d’accéder à des ressources privées. L’accès entrant peut lui aussi être privé grâce à un Private Endpoint.
C’est un point important, car cela permet d’imaginer les Sandboxes autrement que comme de simples environnements publics temporaires.
Sandboxes ou Dynamic Sessions ?
C’est probablement la question la plus importante si vous connaissez déjà Azure Container Apps.
ACA propose déjà les Dynamic Sessions, qui permettent elles aussi d’exécuter du code dans des environnements isolés.
Alors pourquoi avons-nous maintenant besoin des Sandboxes ?
La différence principale est selon moi assez simple.
Avec les Dynamic Sessions, Azure gère principalement le cycle de vie pour vous.
Une application appelle un pool, une session lui est attribuée, elle exécute son workload puis la session finit par disparaître après sa période d’inactivité.
C’est parfait pour quelque chose comme :
Requête → exécution Python → résultat.
Les Sandboxes sont différentes.
C’est vous qui contrôlez explicitement leur cycle de vie.
Vous pouvez créer une Sandbox, exécuter des commandes, gérer ses fichiers, exposer des ports, la suspendre, la reprendre, lui associer du stockage et créer des snapshots.
Je résumerais donc le choix ainsi :
Dynamic Sessions : j’ai besoin d’exécuter quelque chose rapidement dans un environnement isolé.
Sandboxes : j’ai besoin d’un véritable environnement de calcul isolé dont je veux contrôler le cycle de vie et potentiellement conserver l’état.
Cette distinction me semble importante.
Ce n’est pas simplement une autre façon de déployer une Container App
C’est également un point qui mérite d’être clarifié.
Je ne vois pas ACA Sandboxes comme un remplacement des Container Apps traditionnelles.
Pour une API, un microservice ou une application Web qui doit fonctionner continuellement, Azure Container Apps reste naturellement le bon modèle.
Pour un traitement batch qui démarre, effectue son travail puis termine, Container Apps Jobs est probablement plus naturel.
Pour une exécution de code courte et complètement managée, Dynamic Sessions est particulièrement adaptée.
Mais lorsque j’ai besoin d’un environnement isolé, programmable, potentiellement stateful et dont je contrôle explicitement le cycle de vie, Sandboxes devient beaucoup plus intéressant. Microsoft fait d’ailleurs cette même distinction entre Apps, Jobs, Dynamic Sessions et Sandboxes dans sa documentation.
Mon impression après cette première exploration
Ce que je trouve particulièrement intéressant avec ACA Sandboxes, ce n’est pas simplement la possibilité de lancer rapidement une microVM.
C’est la combinaison de plusieurs capacités :
isolation forte, démarrage rapide, scale-to-zero, snapshots, persistance, contrôle réseau et API programmable.
Et surtout, cette fonctionnalité arrive au moment où notre façon d’utiliser le compute est en train d’évoluer.
Pendant longtemps, nous avons principalement construit des infrastructures pour héberger des applications.
Avec les agents IA, nous commençons également à avoir besoin d’infrastructures capables de fournir des environnements de travail temporaires à des logiciels autonomes.
Un agent peut avoir besoin d’un environnement Linux pendant 30 secondes.
Un autre pendant trois heures.
Un développeur peut vouloir reprendre son environnement demain matin exactement dans l’état où il l’a laissé.
Un pipeline peut avoir besoin de 100 environnements pendant cinq minutes puis de zéro.
C’est précisément dans ce genre de scénarios qu’Azure Container Apps Sandboxes devient très intéressant.
La fonctionnalité est encore en Preview, et Microsoft précise que les Sandboxes créées pendant cette période pourraient devoir être recréées avec de futures versions. Les APIs et SDK peuvent également évoluer.
Je ne commencerais donc pas demain à migrer mes workloads critiques dessus.
Mais pour les agents IA, l’exécution de code non fiable, les environnements de développement à la demande, les runners CI/CD et les plateformes multi-tenant, c’est clairement une fonctionnalité que je vais suivre de très près.