Docker a lancé Cloud Sandboxes, une extension vers le cloud de son environnement en microVM destiné aux agents de programmation. Le produit vise un problème qui devient plus important à mesure que les agents travaillent pendant des heures plutôt que quelques minutes : où l'exécution continue-t-elle lorsque l'ordinateur portable se met en veille, change de réseau ou ne peut tout simplement pas accueillir de nombreux travaux simultanés ?
Docker affirme que Cloud Sandboxes conserve la même abstraction que la version locale, avec le même CLI et un modèle d'isolation par microVM. Un développeur peut commencer localement puis déplacer le sandbox vers l'infrastructure gérée par Docker avec sbx move. Selon l'entreprise, l'opération capture le système de fichiers du sandbox et recrée l'environnement de l'autre côté. Docker présente aussi le service comme une base pour exécuter de nombreux agents en parallèle, chacun avec son propre environnement, ses secrets et sa politique réseau.
Le sandbox a désormais une destination dans le cloud
La nouveauté principale n'est pas une nouvelle interface de coding agent. C'est la séparation entre l'environnement de travail de l'agent et la machine physique du développeur.
Docker Sandboxes exécute déjà l'agent dans une microVM avec son propre noyau Linux et son propre daemon Docker. Cloud Sandboxes étend ce modèle à du calcul hébergé. Docker indique qu'un développeur peut commencer une tâche localement, la transférer dans le cloud, se déconnecter puis revenir examiner le résultat. Le déplacement fonctionne dans les deux sens.
Cela crée un modèle d'exécution plus continu. Une refactorisation importante, une migration de dépendances ou une suite de tests de plusieurs heures n'a plus besoin de rester attachée à la machine sur laquelle le travail a commencé. Pour les équipes qui essaient plusieurs agents simultanément, Docker retire aussi une partie du travail de provisioning : la présentation du produit décrit explicitement l'exécution de nombreux travaux isolés en parallèle sans devoir préparer à l'avance une infrastructure séparée.
Les agents de longue durée transforment l'infrastructure en choix d'architecture
La conséquence dépasse le confort d'utilisation. Dès qu'un agent peut travailler cinq, dix ou vingt heures, la qualité du modèle n'est plus l'unique limite. L'infrastructure devient une partie du workflow.
Un ordinateur portable est un mauvais worker de longue durée : il se met en veille, fonctionne sur batterie, change de réseau et partage ses ressources avec le travail interactif. Un sandbox géré peut continuer lorsque l'utilisateur est absent. En revanche, déplacer l'exécution dans le cloud change aussi la frontière opérationnelle. Il faut gérer la durée de vie du sandbox, les identifiants auxquels il a accès, les réseaux qu'il peut joindre, la manière dont l'état est déplacé et la responsabilité de l'arrêt des ressources.
La conclusion d'Aipolix est que les agents à long horizon transforment l'orchestration du sandbox en problème d'infrastructure. Le modèle reste important, mais le cycle de vie de l'environnement, l'isolation, les politiques et le coût deviennent eux aussi des paramètres d'architecture.
L'isolation compte davantage quand personne ne surveille l'agent
Docker explique que chaque sandbox s'exécute dans une microVM avec son propre noyau, au lieu de partager directement celui de l'hôte comme un conteneur classique. Sa documentation de sécurité décrit plusieurs couches d'isolation pour les processus, le système de fichiers, le réseau et les identifiants. L'agent dispose de larges droits à l'intérieur de son environnement, tandis que la frontière de la VM doit empêcher l'accès aux ressources de l'hôte qui n'ont pas été explicitement partagées.
Dans le cloud, une machine séparée ne suffit pas. Un agent utile a besoin d'accès réseau et de secrets. Docker indique pouvoir appliquer une politique réseau par sandbox et injecter des secrets via un proxy afin que l'agent ne reçoive pas directement la valeur du secret.
Ces mécanismes ne démontrent pas que n'importe quel workload devient automatiquement sûr. Les affirmations sur l'isolation viennent de Docker et le lancement ne fournit pas de comparaison de sécurité indépendante. Chaque organisation doit toujours décider quels dépôts, services MCP, identifiants et systèmes externes sont accessibles à l'agent.
Le prix rend le compromis d'infrastructure mesurable
Docker facture Cloud Sandboxes comme du calcul à l'usage. L'annonce affiche des tailles allant d'un vCPU et 2 Gio de mémoire à 0,07 dollar par heure jusqu'à 16 vCPU et 32 Gio à 1,12 dollar par heure. Docker indique que le calcul est mesuré à la seconde, qu'un sandbox en pause ne coûte rien et que les volumes et l'egress ne sont pas facturés séparément dans la tarification de lancement.
Le sandbox par défaut à deux vCPU est affiché à 0,14 dollar par heure. Une tâche de dix heures représenterait donc environ 1,40 dollar de calcul, avant le coût d'inférence du modèle. Docker autorise l'utilisation de la propre clé de modèle du client, ce qui garde l'inférence séparée du prix de l'environnement d'exécution.
L'annonce indique aussi une durée maximale de 24 heures par session cloud. Cette limite couvre de nombreux travaux de fond, mais reste une contrainte de cycle de vie que les orchestrateurs d'agents doivent prendre en compte.
L'abstraction d'exécution est plus avancée que la gouvernance initiale
Cloud Sandboxes simplifie le passage du local au cloud, mais ne supprime pas le travail de gouvernance. L'isolation d'un sandbox, la politique réseau et la gestion des secrets sont des contrôles d'exécution. Une gouvernance d'entreprise doit aussi répondre à d'autres questions : qui peut créer un environnement cloud, quels agents ou kits sont approuvés, quelles politiques sont obligatoires et comment l'usage est audité.
Il est donc plus juste de considérer Cloud Sandboxes comme une couche d'infrastructure pour les agents que comme un système complet de gouvernance des agents.
Son intérêt architectural vient de la portabilité du lieu d'exécution. Le même modèle de sandbox peut accompagner le travail depuis la machine du développeur vers du calcul géré, sans obliger l'équipe à changer complètement de workflow.
Pour les équipes qui construisent des coding agents de longue durée, le choix ne concerne plus seulement le modèle. Il faut aussi choisir où l'agent travaille, comment son autorité est limitée, quel état le suit et combien coûte une exécution sans surveillance.