écrits/blog/2026/05
Blog30 mai 2026·6 min

Sandboxes Claude auto-hébergés : agents IA dans votre périmètre

Les sandboxes Claude auto-hébergés d'Anthropic permettent aux entreprises d'exécuter les outils d'agents IA dans leur périmètre — Cloudflare, Daytona, Modal, Vercel.

Pendant la majeure partie de 2025 et le début de 2026, le même schéma se rejouait dans chaque entreprise régulée qui voulait livrer un agent Claude. L'ingénierie adorait. La sécurité signalait. Le juridique escaladait. Le pilote gelait pendant six à douze semaines pendant que les équipes de gouvernance des données tentaient de concilier une jolie boucle d'agent avec une contrainte rédhibitoire : l'exécution des outils se faisait à l'intérieur du cloud d'Anthropic, touchant des fichiers et services qui n'étaient jamais censés quitter le périmètre de l'entreprise.

Le 19 mai 2026, lors de Code with Claude London, Anthropic a livré la réponse. Les sandboxes auto-hébergés pour Claude Managed Agents sont entrés en bêta publique, aux côtés des tunnels MCP en préversion de recherche. L'argumentaire est simple et l'architecture l'est encore plus : gardez le cerveau de l'agent sur l'infrastructure d'Anthropic, déplacez les mains à l'intérieur de votre périmètre. Pour les banques MENA, les prestataires de santé, les sous-traitants gouvernementaux et toute équipe opérant sous des règles de résidence des données, c'est le déblocage qui a transformé une conversation pilote de 12 semaines en une conversation de 12 jours.

La séparation cerveau-mains

Jusqu'à présent, Claude Managed Agents exécutait toute la boucle sur des sandboxes cloud gérés par Anthropic. L'agent raisonnait sur une tâche, appelait un outil, l'outil s'exécutait dans l'environnement Anthropic, et le résultat alimentait l'étape de raisonnement suivante. Propre, rapide, et difficile à vendre à tout responsable conformité qui lit réellement les contrats fournisseurs.

Les sandboxes auto-hébergés coupent cette boucle en deux. Anthropic possède toujours ce qu'ils appellent la couche d'orchestration — gestion du contexte, inférence du modèle, récupération d'erreurs, la prise de décision effective de l'agent. Vous possédez la couche d'exécution — chaque appel bash, read, write, edit, glob et grep, le système de fichiers que l'agent touche, et la sortie réseau du sandbox. Les fichiers sensibles ne quittent jamais votre réseau. Les services internes ne sont jamais exposés. L'agent raisonne sur vos données privées sans que vos données privées ne traversent jamais le cloud d'Anthropic.

La formulation d'Anthropic — "découpler le cerveau des mains" — est le bon modèle mental. Le cerveau est portable et sans état. Les mains restent à la maison.

Quatre fournisseurs managés, quatre formes de sandbox

Vous pouvez construire vous-même la couche d'exécution sur n'importe quel runtime de conteneurs, mais Anthropic a livré des intégrations de premier ordre avec quatre fournisseurs de sandbox managés. Ils ne sont pas interchangeables ; chacun optimise pour une forme de charge différente.

Cloudflare apporte l'isolation microVM, l'injection de secrets zero-trust et des proxies de sortie personnalisables. L'agent s'exécute dans des isolats légers sur le réseau Cloudflare et peut atteindre les services internes via Cloudflare Tunnel sans les exposer publiquement. Bon choix pour les équipes qui font déjà tourner leur stack sur Cloudflare et veulent les contrôles réseau associés.

Daytona propose des sandboxes à état long, accessibles par SSH ou par URL de prévisualisation authentifiées, avec pause-et-reprise qui conserve l'état complet entre les sessions. Construit pour les agents qui doivent maintenir un environnement de travail vivant à travers les tours — flux de type IDE, analyses de plusieurs jours, tout ce où reconstruire l'état à chaque session serait du gâchis.

Modal est la spécialiste des charges IA. Démarrage sub-seconde sur n'importe quelle image de conteneur, des centaines de milliers de sandboxes concurrents, CPU et GPU à la demande. Si l'agent déclenche des builds coûteux, exécute de la génération d'images, ou entraîne de petits modèles en tant qu'appel d'outil, c'est Modal qui absorbe la pointe sans vous avertir au sujet du quota.

Vercel combine la sécurité de niveau VM avec le peering VPC et le bring-your-own-cloud. Le pare-feu Vercel Sandbox injecte les identifiants à la frontière réseau, ce qui signifie que le sandbox lui-même ne voit jamais le matériel secret qu'il utilise pour authentifier les appels sortants. Bon choix pour les équipes qui font déjà tourner Next.js ou Vercel Functions et veulent que l'exécution de l'agent hérite de la même posture VPC et IAM.

Vous n'êtes pas enfermé. L'environnement self_hosted est une file de travail — tout processus capable d'interroger la file, d'exécuter un appel d'outil et de poster un résultat se qualifie comme worker. Les quatre fournisseurs existent parce qu'ils ont fait le travail d'intégration en amont.

Comment ça marche vraiment

Sous le capot, l'architecture est une file d'attente. Quand vous créez une session ciblant un environnement auto-hébergé, Anthropic met en file un work item. Votre worker — tournant sur votre infrastructure — réclame l'item, télécharge les skills de l'agent, exécute les appels d'outils localement, et poste les résultats en retour. La boucle d'agent côté Anthropic attend ces résultats et poursuit le raisonnement.

Il y a deux modèles de worker. Les workers toujours actifs interrogent la file en continu, idéal pour une charge stable. Les workers déclenchés par webhook se réveillent sur un événement session.status_run_started et commencent à interroger, idéal pour des charges en pics ou de faible volume où maintenir un poller vivant serait du gâchis.

Créer un environnement est un seul appel API :

const client = new Anthropic();
 
const environment = await client.beta.environments.create({
  name: "self-hosted",
  config: { type: "self_hosted" }
});
console.log(environment.id);

Exécuter un worker toujours actif avec le SDK TypeScript est tout aussi compact :

import Anthropic from "@anthropic-ai/sdk";
import { EnvironmentWorker } from "@anthropic-ai/sdk/helpers/beta/environments";
 
const environmentKey = process.env.ANTHROPIC_ENVIRONMENT_KEY!;
const environmentId = process.env.ANTHROPIC_ENVIRONMENT_ID!;
const client = new Anthropic({ authToken: environmentKey });
 
await new EnvironmentWorker({
  client,
  environmentId,
  environmentKey,
  workdir: "/workspace"
}).run();

Le worker s'authentifie avec une clé d'environnement limitée à un seul environnement, et non avec votre clé API Anthropic complète. Cela compte : la clé API sur un hôte worker exposerait un identifiant à l'échelle de l'organisation à tout ce que l'agent déciderait de faire avec bash. La clé d'environnement ne peut pas créer d'environnements, ne peut pas démarrer de sessions, et ne peut pas lire d'autres workspaces. C'est l'identifiant minimum dont le worker a besoin pour faire son travail.

Pour une isolation plus forte, exécutez chaque session dans son propre conteneur. Le ant CLI supporte un hook --on-work qui appelle un script de spawn par item réclamé, vous permettant de lancer un conteneur Docker neuf — ou une microVM Cloudflare, ou un sandbox Modal — pour chaque session. Les limites de système de fichiers et de ressources sont réinitialisées entre les exécutions, ce qui compte quand l'agent touche du code arbitraire ou des entrées non fiables.

Quand combiner avec les tunnels MCP

Les sandboxes auto-hébergés contrôlent où le code de l'agent tourne. Les tunnels MCP contrôlent comment l'agent atteint les serveurs MCP dans votre réseau. Ils sont orthogonaux — une session sur sandbox cloud peut toujours appeler des serveurs MCP privés via un tunnel, et une session auto-hébergée peut appeler des serveurs MCP publics si elle le souhaite. Utilisez les deux quand vous avez besoin que l'exécution et l'accès aux outils restent dans votre frontière.

Le tunnel lui-même est une passerelle légère qui fait une seule connexion sortante vers Anthropic avec chiffrement de bout en bout. Aucune règle de pare-feu entrante. Aucun endpoint public. Le serveur MCP repose sur un sous-réseau privé et l'agent l'atteint sans rien changer dans votre DMZ. Pour les équipes qui ont passé des années à débattre de l'exposition d'une API interne à un fournisseur SaaS, c'est une amélioration discrètement énorme.

Schémas d'entreprise réels

Anthropic a remonté trois exemples clients au lancement, et chacun correspond à un schéma différent qui mérite d'être emprunté.

Amplitude a construit un Design Agent qui génère de l'UI et des assets marketing conformes à la charte. L'auto-hébergement leur a donné une observabilité plus serrée sur ce que l'agent produit et des pistes d'audit complètes de chaque appel d'outil — les deux requis quand la sortie part vers les clients sous leur marque.

Clay a construit Sculptor, un agent d'ingénierie GTM qui construit et teste de façon autonome des flux outbound. Les données de signal propriétaires qui intéressent les clients de Clay ne traversent jamais hors de l'infrastructure de Clay, même quand Claude est celui qui orchestre le flux.

Rogo a construit un agent analyste pour la finance institutionnelle. Les données sont non-négociablement internes — portefeuilles clients, historiques de transactions, déclarations réglementaires. L'auto-hébergement n'était pas une fonctionnalité, c'était la seule architecture qui aurait passé leur revue de conformité.

Le schéma partagé : partout où la sensibilité des données est assez élevée pour que "faire confiance au périmètre du fournisseur" n'allait jamais voler, l'auto-hébergement retourne la question de "peut-on utiliser des agents IA ?" à "où voulons-nous exécuter les workers ?"

Ce qui manque encore

La version honnête : c'est de la bêta publique, et certaines choses ne sont pas encore là. La mémoire — la mémoire de session à long terme qui permet aux agents de rappeler le contexte à travers les exécutions — n'est pas supportée en mode auto-hébergé. Les tunnels MCP sont en préversion de recherche derrière un formulaire de demande. Les SDK Python et TypeScript ont des helpers worker complets ; C#, Java, PHP et Ruby doivent se rabattre sur le ant CLI pour le modèle toujours actif.

Attente réaliste : la plupart de ces éléments arriveront au cours du prochain trimestre. L'architecture est saine et la documentation est livrée. La mémoire en mode auto-hébergé est celle à surveiller — elle requiert un modèle de stockage différent et n'est pas une extension triviale.

Ce que cela signifie pour les entreprises MENA

Pour les équipes en Tunisie, en Arabie saoudite, aux Émirats et dans la région plus large, l'impact pratique est important. Les exigences de résidence des données qui rendaient auparavant Claude Managed Agents inenvisageable — régulateurs bancaires exigeant que les données clients restent dans le pays, lois de santé interdisant le départ des PHI du périmètre national, contrats gouvernementaux avec des clauses explicites de localité cloud — ont maintenant une voie propre. Vous exécutez le worker sur une VM locale, dans une zone Cloudflare ou Vercel régionale, ou sur votre propre matériel bare-metal. L'agent obtient toujours la boucle de raisonnement complète Claude Opus 4.7. Les données ne partent jamais.

Le changement plus grand est culturel. La conversation avec le CIO cesse d'être "sommes-nous à l'aise avec le départ de nos données clients vers un fournisseur IA" et devient "où déployons-nous les workers et qui détient les clés." C'est une conversation que les entreprises savent déjà avoir. C'est la même conversation qu'elles ont eue à propos de Kubernetes, de Terraform, de Postgres. Les sandboxes auto-hébergés tirent les agents IA vers une catégorie que les entreprises comprennent déjà : plan de contrôle managé, exécution possédée par le client.

Par où commencer

Si vous utilisez déjà Claude Managed Agents sur les sandboxes cloud d'Anthropic, la migration est petite. Créez un environnement auto-hébergé, générez une clé d'environnement, exécutez un worker sur toute machine qui peut atteindre api.anthropic.com, et pointez une nouvelle session vers l'environnement. Votre agent, vos prompts et vos skills existants fonctionnent sans changement.

Si vous n'avez pas déployé d'agents parce que la conformité a continué à bloquer le pilote, c'est votre moment. Choisissez le fournisseur qui correspond à votre stack — Cloudflare pour les équipes natives réseau, Vercel pour les boutiques Next.js, Modal pour les charges lourdes en calcul, Daytona pour les sessions longues à état — et prototypez un agent sur des données non productives. L'objection au niveau plateforme a disparu. Le travail restant est celui que vous auriez fait de toute façon : décider quels flux valent la peine d'être automatisés, quels outils l'agent peut appeler, et qui possède le journal d'audit quand il le fait.

Pour la plupart des entreprises MENA, le goulot d'étranglement de la dernière année n'était pas le modèle. C'était le périmètre. À partir de mai 2026, ce goulot est résolu.