Docker Cloud Sandboxes fait basculer le travail long des agents du laptop vers le cloud en une commande
Le 24 septembre 2026, Docker étend ses Sandboxes au cloud : le même environnement microVM, exécuté sur du calcul géré par Docker, avec une seule commande pour déplacer un projet entre le poste et le cloud. Les équipes qui délèguent des tâches de plusieurs heures à des agents de codage n’ont plus à choisir entre un laptop qui dort et une isolation qu’il faudrait réinventer.
24 septembre 2026. Docker publie Cloud Sandboxes, une extension de ses Sandboxes lancés plus tôt dans l’année. Timir Karia et Srini Sekaran, qui signent l’annonce, résument le point de bascule en une phrase : les agents de codage sont passés de tâches de quelques secondes à des tâches qui durent des heures. Pourquoi c’est important : là où la question était jusqu’ici « le modèle tient-il la tâche ? », elle devient désormais « où ces heures se déroulent-elles ? » — et un laptop n’est pas construit pour répondre à cette question.
Le problème : des agents qui travaillent plus longtemps que votre ordinateur
Le changement le plus marquant des douze derniers mois n’est pas la qualité des modèles, c’est leur autonomie. Une refactorisation lourde, une migration de dépendances, une suite de tests qui met une heure à tourner : autant de tâches qu’on pouvait désormais confier à un agent et relire à la fin, au lieu de le surveiller toutes les cinq minutes.
Ce passage du court au long change la nature de la contrainte. Un laptop est construit autour d’une personne : il s’endort quand on ferme le couvercle, il ralentit sur batterie, il se déconnecte quand on se déplace. Rien de tout cela ne compte pour une tâche de trente secondes. Tout compte pour une tâche qui doit tourner toute la nuit.
Docker avait répondu à la première question — « est-il sûr de faire tourner un agent sans surveillance ? » — avec les Sandboxes : des environnements microVM dotés de leur propre noyau et de leur propre démon Docker, isolés de la machine hôte. Cloud Sandboxes répond à la seconde : comment lancer une douzaine d’agents à la fois, cinq, dix ou vingt et une heures chacun, sans en surveiller aucun.
Cloud Sandboxes : le même microVM, ailleurs
La décision d’architecture est la clef de l’annonce. Cloud Sandboxes n’est pas un produit distinct avec ses propres commandes : c’est le même microVM, exécuté cette fois sur du calcul géré par Docker. Le modèle d’isolation est identique, la CLI est identique. Ce qui change, c’est que les machines en dessous restent allumées en permanence, et qu’il y en a autant qu’on en a besoin.
La conséquence pratique tient en une commande. Pour déplacer un projet en cours du poste vers le cloud :
sbx move my-project --to cloudLe move capture le système de fichiers du sandbox et le recrée de l’autre côté, dans les deux sens. On peut donc itérer avec un agent sur le code qu’on a sous les yeux, puis confier les tâches longues et les boucles à un agent en arrière-plan, et fermer le laptop.
Docker insiste sur le fait qu’il ne s’agit pas de deux gammes d’un même produit. Le travail interactif appartient au laptop ; le travail qui dure des heures appartient au cloud. La plupart des développeurs ont besoin des deux, et désormais ils n’ont plus à choisir. La confiance qu’on accorde à un agent ne devrait pas dépendre de l’endroit où il se trouve.
Ce qu’un agent autonome exige
Un agent qui travaille de longues heures sans personne a besoin de trois choses : démarrer sans rien installer, disposer de ses outils, et rester limité dans ce qu’il peut atteindre. Cloud Sandboxes embarque les trois.
Les Kits. Un kit est un sandbox préconfiguré et préconstruit pour un agent. Les principaux agents de codage sont prêts dès aujourd’hui — Claude Code, Codex, Copilot, Antigravity, Open Code et Hermes — et chacun peut ajouter le sien. Lancer une instance tient en une ligne, par exemple sbx --cloud run codex.
Le MCP. Les serveurs MCP dont les agents ont besoin — Jira, Linear, Grafana, incident.io ou n’importe quel endpoint HTTP streamable — se connectent une seule fois, et tous les agents y accèdent à travers une passerelle unique, qu’ils tournent dans le cloud, en local ou dans d’autres clients.
Les secrets. Les clefs et jetons sont stockés une fois. Le proxy de Cloud Sandboxes les injecte à la requête, de sorte que les agents ne voient jamais le secret lui-même. Une injection de prompt ne peut pas atteindre un secret que l’agent n’a jamais possédé.
Les politiques. Les règles réseau définissent les endpoints auxquels les agents peuvent accéder, une fois pour toutes. La gouvernance centralisée pour les entreprises arrivera via Docker AI Governance.
Une grille tarifaire à la seconde
Cloud Sandboxes est facturé à l’usage, à la seconde, et rien d’autre. Un sandbox en pause ne coûte rien, et les volumes, l’egress ainsi que l’hébergement d’images et de kits publics sont gratuits. On peut apporter sa propre clef de modèle et conserver son fournisseur d’inférence.
| Taille | vCPU | Mémoire | Par heure |
|---|---|---|---|
| Micro | 1 | 2 Gio | 0,07 $ |
| Small (défaut) | 2 | 4 Gio | 0,14 $ |
| Medium | 4 | 8 Gio | 0,28 $ |
| Large | 8 | 16 Gio | 0,56 $ |
| XL | 16 | 32 Gio | 1,12 $ |
Les sandboxes tournent une heure par défaut et jusqu’à 24 heures par session. L’installation côté terminal passe par brew install docker/tap/sbx ; côté navigateur, on choisit un kit dans la console web et on clique sur Run.
Pourquoi maintenant, et pas avant
Le timing n’est pas un hasard. Docker avait lancé ses Sandboxes plus tôt dans l’année pour répondre à une question de sécurité : un agent peut-il tourner sans surveillance dans un microVM isolé de la machine ? La question de Cloud Sandboxes est différente, et plus récente : un agent peut-il tourner pendant vingt et une heures sans qu’aucune machine locale ne soit allumée ?
Les deux questions découlent de la même évolution. Les agents de codage sont devenus assez fiables pour qu’on leur confie des tâches de fond — refactorisation, migration, génération de tests — qui durent plus longtemps qu’une session de travail. À ce stade, c’est l’infrastructure locale qui devient le facteur limitant, pas le modèle. Cloud Sandboxes est la réponse de Docker à ce déplacement du goulot : le même contrat d’isolation, mais sur des machines qui ne dorment jamais.
L’autre raison du timing tient au MCP. L’adoption du Model Context Protocol a standardisé la façon dont les agents se branchent sur leurs outils — Jira, Linear, Grafana — et c’est précisément cette standardisation qui rend une passerelle unique viable. Sans elle, chaque agent exigerait sa propre intégration, et un sandbox dans le cloud perdrait une grande partie de son intérêt opérationnel.
Verdict
Si vous faites tourner des agents de codage sur des tâches longues — refactorisation, migration, suite de tests nocturne — Cloud Sandboxes mérite un test immédiat : l’isolation est identique à celle que vous connaissez en local, et le coût horaire d’une instance Small reste inférieur à celui d’un café, avec facturation à la seconde et pause gratuite. Si vous n’utilisez des agents que de façon interactive, sur votre poste, les Sandboxes locaux suffisent : ne payez le cloud que lorsque vos tâches débordent de la durée de vie d’un laptop. Le point d’architecture à retenir est ailleurs : en refusant de faire de Cloud Sandboxes un produit séparé, Docker prend position sur une question que la plupart des équipes vont devoir trancher — l’isolation d’un agent ne doit pas dépendre de l’endroit où il s’exécute.