Hier à Londres, à l’occasion de sa première conférence développeurs hors des États-Unis (Code with Claude), Anthropic a annoncé deux nouvelles fonctionnalités pour ses Claude Managed Agents : des self-hosted sandboxes en bêta publique, et des tunnels MCP en research preview. La presse spécialisée — française en tête — a immédiatement saisi l’angle souveraineté. Le Journal du Net parle d’« Anthropic qui joue la carte souveraineté », L’Usine Digitale d’un « écart creusé dans l’agentique » sur le terrain européen.
Le récit est séduisant mais simplificateur. Les deux annonces ne se valent pas, et même prises ensemble elles ne déplacent qu’une partie limitée du curseur souveraineté. Plutôt que d’opposer un récit « marketing » à un récit « critique », essayons de poser proprement ce qui change, ce qui ne change pas, et où se situe réellement la frontière juridique.
Anatomie d’un agent Claude managed : trois plans qu’il faut distinguer
Pour comprendre la portée des deux annonces, il faut découper ce qu’Anthropic appelle un Managed Agent en trois plans distincts :
- L’inférence du modèle — chaque tour de raisonnement de l’agent invoque l’API Claude. Tout ce qui transite dans le prompt (instructions, contexte récupéré, observations des outils) est traité par les modèles d’Anthropic, sur leur infrastructure aux États-Unis.
- L’orchestration — la boucle « plan / appel d’outil / observation / replan » que pilote Anthropic, avec gestion de contexte, retry, reprise sur erreur. C’est l’« agent loop » au sens technique.
- L’exécution des outils — l’environnement où l’agent va effectivement faire quelque chose : lancer du code, lire un fichier, appeler une API métier, interroger une base.
Avant les annonces de Londres, les trois plans tournaient chez Anthropic. C’est cette répartition qui pose problème pour beaucoup de DSI sérieusement engagés sur les sujets de confidentialité et de souveraineté.
Self-hosted sandboxes : la vraie nouveauté
Les self-hosted sandboxes (en bêta publique) déplacent l’exécution des outils hors d’Anthropic. Concrètement, l’agent appelle ses outils dans une sandbox que vous déployez sur votre propre infrastructure — ou chez un partenaire managed comme Cloudflare, Daytona, Modal ou Vercel. Le code exécuté, le système de fichiers, les requêtes réseau sortantes : tout reste dans votre périmètre.
C’est une vraie avancée. Dans une équipe où la compliance impose qu’aucun code métier ne s’exécute hors du SI, c’est exactement le verrou qui empêchait jusqu’ici l’usage de Claude pour la plupart des cas d’usage agentique. The New Stack note que les clients pilotes nommés par Anthropic — Clay, DoorDash, Rogo — sont tous américains. Le signal européen reste à venir.
Mais attention : la sandbox déplace l’exécution, pas l’orchestration ni l’inférence. Le plan d’action que la sandbox exécute reste calculé chez Anthropic, à partir de prompts qui passent par les serveurs d’Anthropic. Et le résultat de l’exécution est renvoyé à l’orchestrateur Anthropic pour générer le tour suivant. Donc même avec une sandbox self-hosted, les données pertinentes que l’agent manipule transitent par Anthropic — à un cycle près sur trois.
Tunnels MCP : sécurité réseau, pas souveraineté
Les tunnels MCP (en research preview) résolvent un autre problème : permettre à l’agent Claude d’accéder à un serveur Model Context Protocol hébergé dans votre réseau privé — un PostgreSQL interne, une API métier, un Zabbix, un IBM i — sans l’exposer sur Internet. Vous déployez une gateway légère dans votre environnement ; elle établit une unique connexion sortante chiffrée vers Anthropic ; Claude joint votre MCP en empruntant ce tunnel à l’envers.
C’est élégant et utile. C’est aussi exactement le modèle de Cloudflare Tunnel, Tailscale Funnel, Ngrok ou de tout VPN inversé d’entreprise depuis dix ans. Le mérite d’Anthropic n’est pas d’avoir inventé quelque chose de neuf, mais de l’avoir packagé pour son cas d’usage.
Mais ne nous trompons pas sur ce qui est résolu. Les tunnels MCP réduisent votre surface d’attaque externe ; ils ne changent rien à ce qui devient des données envoyées au modèle. Les prompts, les contextes, les résultats d’appels d’outils — tout ce que le tunnel ramène — transitent par les serveurs d’Anthropic pour être ingérés par le modèle. C’est précisément le but ; sinon le tunnel ne servirait à rien.
Trois angles morts que le récit « souveraineté » occulte
Le CLOUD Act s’applique toujours. Anthropic est une entreprise américaine. Les autorités fédérales américaines peuvent lui demander, sous mandat, l’accès à des données détenues ou traitées par elle — où qu’elles soient stockées physiquement. Que vos données arrivent par un endpoint public, par un tunnel sortant ou via une sandbox qui les ré-injecte dans un prompt ne fait aucune différence sur ce plan juridique. L’analyse de Prem AI sur la résidence des données IA est claire sur ce point : l’extraterritorialité américaine reste l’éléphant dans la pièce.
L’orchestration reste opaque. Anthropic conserve le plan d’action de chaque agent et la boucle de décision. Vous pouvez logger tout ce qui sort de chez vous par le tunnel et tout ce qui rentre dans la sandbox ; vous n’avez aucun moyen indépendant de vérifier ce que le modèle a effectivement « pensé », ni qui a accédé à ces traces côté Anthropic. L’auditabilité reste asymétrique.
Le modèle lui-même tourne aux États-Unis. C’est le point que le débat « Claude dans Microsoft 365 Copilot » a remis brutalement sur la table pour l’écosystème enterprise européen : tant que l’inférence ne tourne pas dans une région EU (Bedrock Frankfurt, Vertex AI EU), aucune sandbox ni aucun tunnel ne résout le problème de fond pour les organisations soumises au RGPD strict.
Ce qu’en disent les analystes les plus crédibles
Simon Willison — l’une des voix les plus crédibles sur l’écosystème LLM en 2026 — pointe par ailleurs un problème structurel de MCP qui mérite d’être rappelé ici : « Tool descriptions take up significant context space in agents, and chaining multiple MCP tools together passes responses through context, consuming more tokens and introducing opportunities for LLM mistakes. » Il a même cessé d’utiliser MCP dans ses workflows de coding au profit de simples CLI et de bibliothèques Python.
Sur la sécurité MCP spécifiquement, Invariant Labs et Willison ont également flagué le risque de rug-pull updates : un serveur MCP peut changer son comportement après installation sans re-validation, parce qu’aucune signature ou versionning des manifestes n’est imposé par le protocole. Tunnel ou pas, c’est un sujet de chaîne d’approvisionnement logicielle qu’aucune des deux annonces ne traite.
La vraie question souveraineté
Pour les DSI qui se posent sérieusement la question — et c’est de plus en plus le cas en 2026 — la souveraineté ne se joue pas au niveau du tuyau, ni même de la sandbox. Elle se joue sur trois plans en parallèle :
- Où tourne le modèle ? US (Anthropic SaaS), EU (Bedrock Frankfurt, Vertex AI EU), ou on-prem (Mistral, Llama, Qwen).
- Sous quelle juridiction ? CLOUD Act + Patriot Act, ou RGPD européen, ou souveraineté française stricto sensu.
- Quelle visibilité avez-vous sur la chaîne d’orchestration et de décision ? Boîte noire, partial logs, ou full reproducibility.
Les réponses crédibles aujourd’hui :
- Les modèles auto-hébergés — Mistral, Llama, Qwen — déployés sur votre propre infrastructure ou chez un hébergeur souverain. C’est la voie que nous explorons chez Sensor Factory pour notre POC OpsCenter, avec une stack Mistral envisagée sur DGX Spark. Le compromis est sur la performance brute : un Mistral Large local ne joue pas dans la même cour qu’un Claude Opus 4.7 sur les tâches les plus complexes. Mais les trois plans (modèle + orchestration + exécution) restent sous votre contrôle.
- Claude sur AWS Bedrock EU Frankfurt ou GCP Vertex AI EU avec engagement contractuel adapté. C’est le workaround officiellement recommandé pour les exigences GDPR strictes. On retombe dans le débat extraterritorialité dès qu’on creuse (AWS est aussi US), mais on gagne au moins la résidence des données.
- Une architecture mixte — LLM souverain pour les requêtes touchant à de la donnée sensible, LLM frontier (Claude, GPT, Gemini) pour le reste, avec une couche de routage qui arbitre selon la classification de la donnée. C’est probablement le modèle réaliste à moyen terme pour la plupart des entreprises.
En pratique
Faut-il pour autant rejeter sandboxes et tunnels MCP ? Non — et je vais probablement les utiliser pour certains de nos déploiements. Pris ensemble, ils résolvent un vrai problème opérationnel : permettre à un agent Claude d’accéder à des MCP internes et d’exécuter des outils dans le SI client, sans projet d’exposition publique et sans code métier qui sort du périmètre. Pour un client qui a déjà fait le choix d’utiliser Claude — et qui assume ce choix en pleine connaissance de cause — c’est un net progrès. Moins de plomberie réseau, moins de surface exposée, déploiement plus rapide.
Mais le vendre comme une réponse à la souveraineté, c’est un raccourci marketing qui se retournera contre celui qui le tient. Un DSI un peu sérieux verra que tant que l’inférence tourne aux US et que l’orchestration reste opaque, le périmètre juridique n’a pas bougé. L’erreur dans ce genre de discussion est rarement pardonnée — surtout face à des achats publics ou OIV qui ont leurs propres référentiels (SecNumCloud, ANSSI, CRA européen) à appliquer.
Distinguons donc proprement ce qu’on fait. Sécurité réseau, oui : un tunnel MCP ferme une porte d’entrée. Confinement de l’exécution, oui aussi : la sandbox self-hosted garde votre code dans votre périmètre. Souveraineté de la donnée, non : pour ça, il faut s’occuper d’où tourne le modèle, sous quelle juridiction, et de la visibilité réelle sur la chaîne d’orchestration — pas de comment on lui apporte ses biscuits.
Matthieu Noirbusson est co-fondateur et CEO de Sensor Factory. L’entreprise développe la plateforme SenHub et accompagne ses clients dans leurs projets de supervision, d’observabilité et d’intégration d’agents IA.
