Nous passons beaucoup de temps à réfléchir à la façon de donner aux agents IA un accès sécurisé aux systèmes réels. C’est en partie de la curiosité personnelle, et en partie le fruit de notre travail chez Arcade.dev, où nous construisons de l’infrastructure pour agents (en particulier les parties qui ont tendance à lâcher dès qu’on sort des démos jouets).
Quand Docker a lancé les Docker Sandboxes, qui permettent aux agents de coding IA de s’exécuter dans un conteneur isolé plutôt que directement sur votre machine, nous avons voulu les tester vraiment. Pas en démo, mais sur une vraie codebase, pour faire le genre de choses qu’on demande de plus en plus aux agents.
Nous l’avons testé avec Claude Code. Voici ce que cette expérience a vraiment donné.
TL;DR
- L’installation est franchement simple
- L’isolation fonctionne exactement comme annoncé
- Au début, c’est fluide. On oublie qu’on est dans un sandbox.
- Les workflows de dev réels révèlent vite les aspérités
- Configuration d’environnement, binaires et accès API : ça fait mal
- Une base solide, mais pas quelque chose qu’on utiliserait au quotidien (pour l’instant)
Pourquoi nous l’avons testé
L’une des grandes inquiétudes autour des agents de coding, ce n’est pas tant leur capacité à modifier des fichiers : c’est ce qu’ils pourraient faire sans le vouloir une fois qu’ils ont un vrai accès.
En pratique, les problèmes qu’on observe ne viennent généralement pas d’un agent qui supprime des fichiers hors de son workspace (le sandboxing contraint déjà ça). Ce qui est plus préoccupant : des agents qui touchent les mauvais systèmes, utilisent les mauvaises credentials, ou exécutent des commandes dans des contextes qu’ils ne maîtrisent pas vraiment.
Les Docker Sandboxes promettent de réduire une partie de ce risque en isolant l’exécution. Ça valait la peine de vérifier.
Installation : étonnamment fluide
Démarrer était simple :
- Mettre à jour Docker vers la dernière version
- Lancer
docker sandbox run claude - Se connecter à Claude Code
Une fois le sandbox démarré, Claude ne voyait queles fichiers de notre répertoire de travail, rien d’autre sur la machine.
Du point de vue de la sécurité d’exécution, c’est une vraie victoire. Aucune ambiguïté sur ce que l’agent peut toucher en local, et ça instaure immédiatement la confiance.
Au début, ça paraît presque magique
Pour les tâches simples, l’expérience est presque impossible à distinguer d’un Claude lancé directement.
Claude modifie des fichiers, lit du code, propose des changements sans friction perceptible. On a sincèrement oublié pendant un moment qu’on travaillait dans un sandbox, ce qui est probablement le plus beau compliment qu’on puisse faire à ce genre d’outil.
Réussir l’isolation sans la rappeler en permanence, c’est difficile. Docker s’en sort très bien sur ce point.
Là où les choses ont commencé à se dégrader
Dès qu’on a demandé à Claude de faire quelque chose de plus proche d’un vrai travail de développement, le tableau a changé.
On lui a fait écrire des tests, puis on lui a demandé de lancer notre suite de tests avec make test.
, ça a planté immédiatement : make n’était pas installé dans le sandbox.
Claude a essayé de s’en sortir en lançant les commandes de test manuellement, mais ça a aussi échoué, car certaines de nos dépendances de dev ne supportent pas l’OS du sandbox.
Rien de surprenant si vous avez l’habitude des conteneurs, mais c’est un rappel que l’isolation d’exécution et la parité d’environnement sont deux problèmes très différents.
La configuration d’environnement, c’est là que la friction se voit vraiment
La vraie douleur est apparue quand les API sont entrées dans l’équation.
L’un des tests nécessitait une clé API. Comme le sandbox n’avait pas été démarré avec cette variable d’environnement, on ne pouvait pas simplement l’ajouter.
À la place, nous avons dû :
- Stopper le sandbox
- Le supprimer
- Le redémarrer avec la variable d’env
- Perdre toute la conversation Claude
Du point de vue du workflow agent, c’est une pénalité sévère pour une petite erreur de configuration.
Les agents fonctionnent par nature de façon itérative. Perdre le contexte à cause d’un changement d’environnement casse cette boucle d’une façon que les humains tolèrent mal.
Une hypothèse qu’on n’avait pas conscientisée
On a aussi réalisé qu’on avait fait une hypothèse discrète : on s’attendait à ce que Claude travaille dans un git worktree, pas directement dans notre répertoire de travail.
Or le sandbox monte le code directement.
Ça crée quelques problèmes :
- On ne peut pas facilement laisser l’agent travailler sur des tâches longues en arrière-plan
- On se retrouve en concurrence avec l’agent si on essaie de modifier les mêmes fichiers en local au même moment
- Si l’agent supprime ou réécrit de larges pans du dépôt, l’impact est immédiat
À ce stade, on commence à voir la frontière de ce que le sandboxing d’exécution protège vraiment, et ce qu’il ne couvre pas.
Ce que les Docker Sandboxes réussissent
Pour être honnête, il y a beaucoup à apprécier :
- L’installation initiale est simple
- L’isolation du filesystem fonctionne comme annoncé
- L’intégration avec Claude est naturelle
- Pour les petits projets ou les projets greenfield, c’est probablement suffisant
- On oublie souvent qu’on est dans un sandbox
Si votre préoccupation principale est la sécurité locale, les Docker Sandboxes répondent à un vrai problème.
Là où ça coince aujourd’hui
Du point de vue du dev au quotidien, il reste quelques aspérités :
- Support uniquement pour Claude
- Réinstallation de binaires déjà présents en local
- Variables d’environnement nécessitant un redémarrage complet
- CLI très orientée Docker pour la configuration de base
- Perte du contexte agent quand le sandbox doit être redémarré avec une configuration modifiée
Aucun de ces points n’est catastrophique pris isolément, mais ensemble ils limitent la fréquence à laquelle on penserait à l’utiliser dans un vrai travail.
Ce que le sandboxing ne résout pas
Ce que cette expérience nous a confirmé, c’est que la sécurité du filesystem est souvent la partie la moins intéressante du risque agent.
En pratique, ce qui nous préoccupe bien davantage :
- quels services un agent peut contacter
- quelles credentials il utilise
- s’il comprend la différence entre test et production
- quelles actions il est autorisé à effectuer au nom d’un utilisateur
Le sandboxing d’exécution répond à *« Où ce code peut-il s’exécuter ? »* Il ne répond pas à « Que devrait avoir le droit de faire cet agent ? »
Cette distinction devient très claire dès qu’on essaie d’utiliser ces outils sur de vrais systèmes. C’est d’ailleurs une raison clé pour laquelle de nombreuses entreprises ont choisi d’implémenter Arcade.
Pour finir
Les Docker Sandboxes représentent une avancée importante. L’isolation d’exécution fonctionne, et l’intégration avec Claude est soignée.
Mais les workflows de développement réels sont désordonnés. Ils s’appuient sur la parité d’environnement, un contexte persistant, des API, des credentials et des permissions qui ne s’intègrent pas proprement dans un conteneur bien rangé.
De notre point de vue, c’est une infrastructure solide, juste une couche parmi d’autres que les équipes devront assembler à mesure que les agents passent des expérimentations aux workflows réels.
_________________________________________________________
Vous voulez mieux cerner le risque agent dans votre entreprise ? Démarrez gratuitement avec Arcade
