On dit que l’isolation par container reste le critère de sécurité numéro un pour choisir une infrastructure d’agents IA. Cloudflare vient de démontrer l’inverse avec ses propres outils. Avec @cloudflare/computer, publié en open source le 3 août 2026, le container ne sert plus qu’à moins de 10 % du travail d’un agent ; le reste tourne dans des isolates Workers reliés à un filesystem partagé. Concrètement, un agent qui édite un dépôt Git et pilote un MCP server n’a plus besoin d’une machine dédiée à chaque étape : il lit et écrit dans un système de fichiers persistant, adossé à des Durable Objects et à SQLite ; isolate et container y accèdent tour à tour selon la tâche. Ce glissement déplace l’endroit où se joue la concurrence entre plateformes d’agents.
Ce que Cloudflare vient de changer avec @cloudflare/computer
Une équipe qui pilote ses prompts depuis 14 fiches Notion différentes sait déjà que la cohérence de sortie d’un agent tient moins au moteur de langage utilisé qu’à l’environnement dans lequel il exécute ses actions. Cloudflare a publié le 3 août 2026 un billet de blog qui formule ce constat sans détour : donner un container à chaque agent ne passera pas à l’échelle des centaines de millions, puis des milliards, d’agents concurrents que promettent les plateformes d’IA agentique. La pénurie touche la ressource CPU ; le GPU ne pose pas le même problème d’échelle.
« Les agents les plus capables ont un point commun : on leur donne leur propre ordinateur pour travailler. » (Cloudflare Blog, 3 août 2026)
@cloudflare/computer répond à ce constat par une bibliothèque open source, distribuée sous licence MIT, qui abstrait le choix entre isolate, container ou, plus rarement, navigateur derrière une seule API. L’objectif annoncé par Cloudflare : ramener la part de travail confiée à un container en dessous de 10 % de la charge totale d’un agent. Les 90 % restants, génération de code et manipulation de documents pour l’essentiel, tournent dans des isolates qui se mettent en veille dès que l’agent est inactif.
Comment le sandbox devient une brique optionnelle parmi d’autres
Cloudflare rappelle dans son billet un choix architectural vieux de 10 ans. L’entreprise a parié sur les isolates V8 dès le lancement de Workers, puis a étendu ce pari il y a six ans avec les Durable Objects, l’année dernière avec la capacité pour un isolate d’attacher un container à la demande. La combinaison de ces trois briques rend le sandbox optionnel aujourd’hui.
- Les isolates Workers exécutent le raisonnement de l’agent et la plupart des tâches légères, avec un démarrage quasi instantané et une mise en veille automatique.
- Les Durable Objects portent l’état de l’agent, sa mémoire de session, sa file d’attente d’actions, sans base de données externe à provisionner.
- Un container reste attaché. Il n’intervient que comme un outil ponctuel, invoqué pour les tâches qui exigent un environnement Linux complet : compilation lourde, dépendances système, exécution de code non fiable.
Le sandbox conteneurisé n’a pas disparu : son rôle a changé, il n’intervient plus à chaque action de l’agent, seulement quand la tâche l’exige. Même bascule que celle qui a fait passer, il y a 10 ans, le calcul serverless généraliste vers les fonctions edge, appliquée cette fois à l’exécution d’agents.
Le filesystem partagé, nouveau centre de gravité
Un Durable Object stocke ses données dans une base SQLite plafonnée à 10 Go. Les fichiers y sont découpés en fragments de 512 Kio, chacun identifié par un hash SHA-256, ce qui permet de ne synchroniser que les fragments modifiés entre un isolate et un container. Des montages adossés à R2, le service de stockage objet de Cloudflare, permettent en complément de pré-remplir l’espace de travail avec des données en lecture seule. Ce mécanisme reste invisible pour l’agent : il continue de lire et d’écrire dans ce qui ressemble, de son point de vue, à un seul système de fichiers.
Le filesystem partagé devient le point de différenciation. Deux isolates distincts peuvent opérer sur les mêmes fichiers sans synchronisation manuelle ni API de transfert. Un container attaché accède au même répertoire dès qu’il est invoqué. Un rapport généré dans un isolate reste accessible au container qui doit ensuite le compiler en PDF. La sécurité se déplace vers un autre niveau : les permissions accordées à chaque opération lisant ou écrivant ce filesystem partagé comptent désormais davantage que l’étanchéité d’une seule machine virtuelle.
Ce que ça change pour les workflows MCP et l’orchestration multi-agents
Une équipe marketing qui connecte un agent à plusieurs serveurs MCP (Model Context Protocol) pour automatiser du reporting et de la génération de contenu se heurte vite au même angle mort : chaque outil produit ses propres fichiers, ses propres formats de sortie, sans registre commun. L’orchestration multi-agents échoue moins souvent sur le raisonnement des modèles que sur la coordination des artefacts qu’ils produisent.
Un filesystem partagé change cette mécanique. Un agent chargé de la recherche écrit ses notes dans un fichier ; un second agent, chargé de la rédaction, les lit directement sans passer par un webhook ou une base intermédiaire. Le même répertoire sert ensuite de socle à la mise en forme finale, quand le workflow prévoit un troisième agent pour cette étape. Même logique qu’un fichier CLAUDE.md, qui centralise le contexte d’un projet pour un agent de code : un point d’ancrage unique, lisible par tous les composants de la chaîne, plutôt qu’une suite d’appels API à synchroniser à la main. Le context window de chaque modèle reste limité ; le système de fichiers porte la mémoire longue de l’agent, bien au-delà de ce qu’un prompt peut retenir.
Cloudflare face à E2B, Modal, Daytona : le comparatif chiffré
Le marché du sandboxing pour agents ne se résume pas à Cloudflare. E2B et Modal dominent l’exécution de code isolée pour les plateformes d’agents en 2026, aux côtés de Daytona, positionné sur les coûts les plus bas du secteur. Chacun a fait un pari d’architecture différent ; ce pari se lit directement dans le prix.
| Critère | Cloudflare (Sandbox + @cloudflare/computer) | E2B | Modal | Daytona |
|---|---|---|---|---|
| Isolation de base | Isolates V8 (Workers), container attaché à la demande | MicroVM Firecracker | gVisor (noyau en espace utilisateur) | Container par défaut, Kata ou Sysbox en option |
| Modèle de facturation | CPU actif, facturation à la seconde de travail réel de l’agent | 0,000014 dollar/s par vCPU, RAM facturée séparément à 0,0000045 dollar/Gio/s (E2B, 2026) | 0,0000131 dollar/core/s (Modal, pricing juillet 2026) | 0,0504 dollar/vCPU-heure (Developers Digest, 2026) |
| État persistant | Filesystem partagé isolates/containers via Durable Objects et SQLite | Session éphémère, snapshot manuel | Volumes attachés, sans filesystem partagé natif entre sandboxes | Espace de travail persistant par sandbox |
| Accès GPU dans le sandbox | Non annoncé à ce jour | Non | Oui, seul acteur du comparatif | Non |
Cloudflare mise sur des isolates plutôt que sur des microVM sans pour autant sacrifier l’isolation à la vitesse. Modal, seul acteur du comparatif à exposer un GPU dans son sandbox, couvre un besoin que ni Cloudflare ni Daytona ne traitent pour l’instant. L’écart se situe ailleurs : ce que chaque plateforme laisse persister entre deux invocations de l’agent compte plus que le niveau brut d’isolation affiché.
La faille qui relativise le narratif
La même semaine que la publication de @cloudflare/computer, le 6 août 2026, Check Point Research a rendu publiques 5 vulnérabilités de corruption mémoire dans workerd, le runtime open source qui exécute le code des Workers, dont Code Mode, la fonctionnalité qui traduit les appels d’outils d’un agent en code TypeScript exécuté directement dans l’isolate. Les chercheurs, qui ont présenté leurs travaux à Black Hat USA 2026, rappellent que Workers porte plus de 10 % du trafic total du réseau Cloudflare. Les 5 failles ont été signalées via HackerOne entre février et mars 2026, corrigées avant la divulgation publique.
Cet épisode complète la thèse de Cloudflare plutôt qu’il ne la dément. Déplacer la charge des containers vers des isolates concentre le risque sur une seule surface, celle du runtime qui exécute désormais l’essentiel du travail agentique, sans le faire disparaître. @cloudflare/computer reste en preview ouverte. Cloudflare le présente lui-même comme une expérimentation lancée pour apprendre aux côtés de ses premiers clients. La bibliothèque reste loin d’une brique stabilisée pour de la production critique.
Cloudflare a aussi annoncé avec Anthropic, dès mai 2026, des sandboxes dédiées aux Claude Managed Agents (Mediavenir, 2026) : ce chantier distinct dispose déjà d’une documentation développeur dédiée, sans se confondre avec @cloudflare/computer.
