Tu laisses Claude Code, Codex ou un autre agent modifier ton code en toute autonomie ? Alors tu connais la vraie question : ce n’est pas « est-ce qu’il va bien travailler », c’est « est-ce qu’il peut casser ma machine ». Docker vient de pousser sa réponse, Sandboxes : un bac à sable qui enferme chaque agent dans une microVM jetable, avec son propre noyau et son propre moteur Docker. Ta machine reste de l’autre côté de la vitre, même quand l’agent fait n’importe quoi.
Le produit n’est pas né hier, il tournait déjà au printemps, mais il monte en puissance cet été : support de six agents de codage majeurs, installation simplifiée sur macOS, Windows et Linux, et une CLI gratuite, même en usage commercial. Voilà pourquoi tout le monde en parle, et ce qu’il faut savoir avant de sauter le pas.
Pourquoi tu ne peux plus laisser un agent faire n’importe quoi
Un agent autonome installe des paquets, modifie des fichiers, exécute des scripts et peut même construire ses propres conteneurs. Tout ça sans te demander ton avis à chaque étape : c’est le principe du mode sans permission. Le problème, c’est ce qui se passe quand ça dérape. Le chercheur Johann Rehberger l’a montré avec une démonstration devenue célèbre : un agent d’usage général détourné par une page web piégée a téléchargé un programme, l’a rendu exécutable et l’a lancé sur la machine hôte.
Un conteneur classique ne protège pas vraiment. Tous les conteneurs d’une même machine partagent le noyau du système d’exploitation : une faille dans ce noyau expose toute la machine. Et si l’agent accède au moteur Docker de l’hôte, il récupère au passage ses permissions. Docker a donc choisi une autre barrière : la machine virtuelle, en version miniature.
Une microVM jetable pour chaque agent
Docker Sandboxes donne à chaque agent sa propre microVM : un petit système complet, avec son noyau, son moteur Docker et son réseau isolés. L’agent peut tout faire dedans — installer, compiler, lancer des services, créer des conteneurs — sans jamais toucher au système hôte. La microVM se détruit d’une commande, et on repart d’un environnement vierge. C’est la même famille de techniques qui fait tourner les fonctions serverless d’Amazon, appliquée au poste de travail.
Schéma : modèle de sécurité de Docker Sandboxes. Source : documentation officielle Docker — https://docs.docker.com/ai/sandboxes/security/
Les détails comptent. Ton dossier de travail est monté dans la machine virtuelle : les fichiers modifiés par l’agent arrivent en direct sur ton disque, comme s’il travaillait en local. Les clés d’API, elles, n’y entrent jamais : un proxy installé sur l’hôte intercepte les requêtes sortantes et injecte les identifiants au dernier moment. Même une microVM entièrement compromise ne contient donc aucune clé à voler. Côté réseau, c’est verrouillé par défaut : seuls les domaines autorisés passent, tout le reste est bloqué.
Ce que ça change pour toi
Concrètement, tu installes un petit outil en ligne de commande. Pas besoin de Docker Desktop, pas de licence : la CLI est gratuite, même pour le travail commercial, et elle tourne sur macOS, Windows et désormais Linux. Tu te places dans ton projet, tu lances l’agent de ton choix, et il travaille dans sa bulle. Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode et Kiro sont supportés directement, et l’agent peut lancer ses propres conteneurs sans demander de privilèges supplémentaires.
Illustration : bannière officielle de Docker Sandboxes. Source : Cloud Native Now, « The Questions Every Team Asks About Docker Sandboxes » — https://cloudnativenow.com/contributed-content/the-questions-every-team-asks-about-docker-sandboxes/
Le mode le plus permissif — surnommé « mode YOLO », avec un drapeau qui dit littéralement « saute les permissions » — est même activé par défaut. En temps normal, ce serait une très mauvaise idée. Dans un bac à sable, c’est acceptable : l’agent fait ce qu’il veut dans sa microVM, et ta machine reste de l’autre côté de la vitre. Si tu préfères un peu plus de contrôle, un mode « clone » monte ton dépôt en lecture seule et laisse l’agent travailler sur une copie privée.
Les limites à connaître avant de foncer
Ce n’est pas une baguette magique. Par défaut, le bac à sable isole le système, pas ton projet : l’agent écrit dans ton vrai dossier de travail. Les hooks Git, les scripts de build et les fichiers de configuration sont modifiables — relis toujours ce qu’il a changé avant de lancer quoi que ce soit. La liste des domaines autorisés par défaut est aussi assez large, et il vaut mieux la resserrer selon tes besoins.
Autre piège : les serveurs MCP locaux, ces ponts qui donnent aux agents accès à des outils, tournent sur l’hôte et pas dans la microVM. Ils restent donc dans le périmètre de confiance de ta machine. Enfin, la gestion centralisée des règles pour toute une équipe — réseau, fichiers, MCP — demande un abonnement séparé. Pour un usage personnel, la CLI gratuite suffit largement.
Le bac à sable devient la norme
Docker n’est pas seul sur ce terrain. E2B, Modal, Cloudflare, Vercel et le projet open source NanoClaw construisent tous des bacs à sable pour agents. Une analyse publiée le 10 août résume le mouvement : en un an, le bac à sable est passé d’une option technique à une catégorie de produit à part entière. La raison est simple — les agents ne se contentent plus de répondre, ils agissent, et chaque action est une surface d’attaque.
La leçon à retenir : l’autonomie, oui, mais dans une cage. Docker Sandboxes ne rend pas les agents plus intelligents. Il rend leurs erreurs moins chères, et leur donne enfin le droit de travailler sans surveillance. C’est exactement ce qu’on demande à une cage.
Sources
Docker, page produit Docker Sandboxes — https://www.docker.com/products/docker-sandboxes/ — présentation officielle : microVM, agents supportés, mode YOLO, CLI gratuite.
Docker, documentation officielle Sandboxes — https://docs.docker.com/ai/sandboxes/ — installation macOS, Windows, Linux, CLI sbx, gouvernance optionnelle.
Docker, « Security model » (documentation) — https://docs.docker.com/ai/sandboxes/security/ — frontière de confiance, injection des identifiants par proxy, réseau bloqué par défaut.
InfoWorld, « Docker Sandboxes and microVMs, explained » — https://www.infoworld.com/article/4177309/docker-sandboxes-and-microvms-explained.html — explication du fonctionnement des microVM et des usages au-delà des agents.
The New Stack, « NanoClaw and Docker team up to isolate AI agents inside MicroVM sandboxes » — https://thenewstack.io/nanoclaw-docker-sandboxes-ai-agents/ — l’intégration avec NanoClaw et la doctrine « l’agent est non fiable par défaut ».
Cloud Native Now, « The Questions Every Team Asks About Docker Sandboxes » — https://cloudnativenow.com/contributed-content/the-questions-every-team-asks-about-docker-sandboxes/ — lancement, kits, gestion des identifiants, limites.
Northeast Times, « Why AI agent sandboxes are suddenly everywhere in tech », 10 août 2026 — https://northeasttimes.com/2026/08/10/why-ai-agent-sandboxes-are-suddenly-everywhere-in-tech/ — analyse du 10 août sur la généralisation des bacs à sable d’agents.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet