Sandboxes, MCP Tunnels, Stainless : Anthropic creuse l'écart dans l'agentique

Quarante-huit heures, trois annonces, un seul signal : Anthropic ne se contente plus de construire le meilleur modèle. La conférence Code with Claude London du 19 mai 2026, précédée la veille par l’annonce du rachat de Stainless, a confirmé une ambition plus large, celle d’assembler la stack complète de l’agentique. Sandboxes auto-hébergés, MCP Tunnels, acquisition de Stainless : trois pièces d’un même puzzle qui changent concrètement la façon dont les entreprises vont déployer des agents en production.

Sandboxes auto-hébergés : l’exécution sort d’Anthropic

Jusqu’ici, faire tourner un agent Claude avec des outils (lecture de fichiers, exécution de code, appels réseau) impliquait de laisser cette exécution se passer dans l’infrastructure d’Anthropic. Pour beaucoup d’entreprises soumises à des exigences de conformité, c’était un blocage net.

Les sandboxes auto-hébergés changent l’équation. Le principe est simple à comprendre une fois qu’on distingue deux couches distinctes. La boucle agent, c’est-à-dire la gestion du contexte, le raisonnement, l’orchestration des appels successifs, reste côté Anthropic. En revanche, l’exécution réelle des outils, les fichiers que l’agent lit, le code qu’il fait tourner, les requêtes réseau qu’il lance, s’effectue dans l’infrastructure du client. L’exécution du code, le filesystem et le trafic réseau restent dans ton périmètre ; seuls les inputs et outputs d’outils que le modèle doit voir transitent vers Anthropic.

Pour les équipes qui ne veulent pas gérer elles-mêmes cette couche d’exécution, Anthropic propose des providers managés en public beta : quatre au lancement (Cloudflare, Daytona, Modal et Vercel), une dizaine aujourd’hui (E2B, AWS Lambda, GKE Agent Sandbox, Blaxel…). Chacun prend en charge l’isolation et la scalabilité, sans que tu aies à maintenir la plomberie.

Quelques limites à noter pour la version actuelle : les sandboxes auto-hébergés ne sont pas disponibles sur la plateforme AWS Claude, et le module Memory n’est pas encore supporté dans ce mode.

Le “so what” pour les builders est direct. Des secteurs entiers, banque, santé, défense, administration, ne pouvaient pas sérieusement envisager de passer leurs données sensibles dans un environnement cloud tiers. Avec cette séparation nette entre orchestration et exécution, le verrou saute. Les agents deviennent déployables là où la conformité l’exige, sans sacrifier les capacités du modèle.

Concrètement, les cas d’usage qui deviennent réalistes pour les entreprises soumises à des contraintes réglementaires sont nombreux. Un groupe pharmaceutique peut déployer un agent d’analyse de données cliniques sans que ces données quittent ses serveurs, ce qui était jusqu’ici incompatible avec les exigences RGPD et les réglementations sectorielles comme HDS en France ou HIPAA aux États-Unis. Un cabinet d’avocats peut faire analyser ses contrats confidentiels par Claude sans violer son obligation de secret professionnel. Une entreprise industrielle peut faire tourner des agents sur ses formules, ses plans de fabrication ou ses brevets en cours, des actifs dont la moindre fuite représente une perte stratégique majeure. Un hôpital peut enfin envisager d’automatiser des workflows autour des dossiers patients sans devoir passer par une procédure d’exception auprès de son RSSI.

Ce qui change structurellement, c’est l’interlocuteur dans la vente enterprise. Jusqu’ici, convaincre un DSI ou un DPO d’adopter des agents Claude se heurtait systématiquement à la question du périmètre des données. Cette question a désormais une réponse technique vérifiable, et non plus seulement contractuelle.

MCP Tunnels : tes systèmes privés deviennent des outils agents

Le protocole MCP (Model Context Protocol) permet aux agents de se connecter à des sources de données et des outils externes. Le problème jusqu’ici : pour qu’un agent cloud puisse atteindre ton serveur MCP, ce serveur devait être accessible sur internet. Pour une base de données interne, une API privée ou un système de tickets derrière un firewall, c’était soit exposer l’infrastructure, soit renoncer à l’intégration.

MCP Tunnels, annoncé en research preview, résout ce problème sans contournements. Le mécanisme repose sur un gateway léger déployé côté client, dans ton réseau privé. Ce gateway établit une connexion sortante chiffrée vers Anthropic. Le trafic circule dans ce tunnel : l’agent cloud peut interroger tes systèmes internes, et ton firewall ne laisse passer aucune connexion entrante non autorisée.

Les cas d’usage qui deviennent réalistes immédiatement : un agent qui consulte une base de données PostgreSQL interne pour générer des rapports, un agent couplé à ton instance Jira ou Linear sans proxy exposé, des appels à des APIs internes de facturation ou de CRM qui n’ont jamais eu vocation à être publiques.

La fonctionnalité est accessible sur demande pour l’instant. L’accès en research preview implique une sélection des cas d’usage ; ce n’est pas encore un déploiement général.

Le “so what” : le dilemme “soit tu exposes, soit tu n’intègres pas” disparaît. Les équipes qui avaient écarté les agents Claude parce que leurs données critiques vivent derrière un firewall ont désormais une voie d’intégration qui ne compromet pas leur posture de sécurité. C’est un déblocage massif pour les cas d’usage enterprise qui concentrent pourtant l’essentiel de la valeur.

Stainless : le coup stratégique qui prive les concurrents d’infra

Des trois annonces, la plus commentée est aussi la plus stratégiquement intéressante. Anthropic a racheté Stainless pour plus de 300 millions de dollars selon The Information (montant jamais confirmé officiellement), annoncé le 18 mai.

Stainless est une startup new-yorkaise fondée en 2022 par Alex Rattray, ancien de Stripe. Son produit : automatiser la génération et la maintenance de SDKs à partir de spécifications OpenAPI. En pratique, si tu as une API bien documentée, Stainless produit des librairies clientes dans plusieurs langages, les maintient à jour à chaque évolution de l’API, et garantit une cohérence que les équipes humaines peinent à assurer sur la durée.

Ce qui rend cette acquisition particulièrement intéressante : les clients actuels de Stainless incluent OpenAI, Google et Cloudflare. Ces entreprises utilisaient Stainless pour générer et maintenir leurs propres SDKs. Anthropic coupe le service hébergé. Les clients existants gardent leurs SDKs avec droits complets, mais la machine qui les produisait et les faisait évoluer automatiquement n’est plus disponible.

C’est un coup à double effet. Anthropic récupère une technologie qui va lui permettre d’industrialiser ses propres SDKs, d’accélérer leur maintenance, et de garantir une expérience développeur cohérente sur toutes les surfaces de son API. En parallèle, OpenAI et Google perdent l’accès à l’outil qu’ils utilisaient pour faire exactement la même chose.

La question technique pour les concurrents n’est pas simple. Internaliser cette capacité implique de recruter des profils rares, capables à la fois de comprendre les spécifications OpenAPI en profondeur et de générer du code idiomatique dans une dizaine de langages. Forker le code existant de Stainless n’est pas non plus trivial : la valeur du produit tient à l’outillage propriétaire de synchronisation entre l’API et les SDKs, pas seulement aux SDKs eux-mêmes. Trouver une alternative externe crédible au niveau de maturité de Stainless est difficile à court terme. En pratique, OpenAI et Google vont probablement absorber le coût d’une maintenance plus manuelle pendant plusieurs trimestres, avec un risque réel de glissement de cohérence entre les langages, notamment Python, TypeScript, Go et Java. Ce genre de dette technique est invisible pour l’utilisateur final au départ, puis douloureuse à mesure que l’API évolue.

Ce n’est pas une acquisition défensive. Anthropic ne rachète pas Stainless pour empêcher un concurrent de l’acquérir. C’est un mouvement offensif qui crée un avantage opérationnel durable tout en fragilisant l’expérience développeur chez les principaux rivaux.

Pour un développeur qui utilise les SDKs Anthropic aujourd’hui, le changement est concret. La vitesse à laquelle les SDKs officiel Python et TypeScript d’Anthropic vont s’aligner sur les nouvelles fonctionnalités de l’API va s’accélérer. La cohérence entre les langages va s’améliorer : moins de comportements légèrement différents entre le client Python et le client TypeScript sur des fonctionnalités comme le streaming ou la gestion des erreurs. Et surtout, l’intégration MCP dans les SDKs a toutes les chances d’être traitée comme une priorité de premier rang, avec la même rigueur que les fonctionnalités cœur. En résumé, choisir les SDKs Anthropic dans les prochains mois, c’est choisir la plateforme dont l’outillage développeur va s’améliorer le plus rapidement.

Le fil rouge : Anthropic assemble la stack complète

Pris séparément, chacun de ces trois mouvements est significatif. Ensemble, ils révèlent une architecture claire.

Anthropic construit désormais trois couches distinctes. Le cerveau : le LLM, Claude Opus, Sonnet, Haiku, le cœur du raisonnement. Les mains : les sandboxes auto-hébergés, l’exécution des outils dans l’infra du client. Les sens : MCP et MCP Tunnels, la connexion aux systèmes privés et aux données réelles. Et maintenant l’outillage développeur : Stainless, pour que les SDKs qui exposent tout ça soient irréprochables.

L’écart avec OpenAI n’est plus seulement une question de benchmark de modèle. Il se creuse sur l’infrastructure agentique complète. Déployer des agents Claude en production dans un contexte enterprise, avec des contraintes de conformité, des systèmes internes, et des exigences de fiabilité, devient sensiblement plus simple qu’avec la concurrence.

Pour les builders qui construisent des produits IA aujourd’hui, c’est le signal à retenir : choisir sa plateforme agentique, c’est choisir une stack, pas juste un modèle.