Anthropic et Google viennent de sortir le même produit. À 2 semaines d'intervalle. Logos différents.

En avril 2026, Anthropic a lancé Claude Managed Agents en bêta publique. 3 semaines plus tard au Google I/O, Google a livré Managed Agents dans l'API Gemini, emballé dans une suite développeur appelée Project Antigravity. Si vous suivez l'évolution du vibe-coding (au-delà de la démo, vers la production), c'est le signal que vous attendiez.

Les deux keynotes ont utilisé des mots différents. Les deux pages de tarification semblent sans rapport. La presse les a couvertes comme des visions concurrentes.

Ce ne sont pas des visions concurrentes. Même architecture, 2 logos sur le conteneur.

J'ai passé quelques jours à lire les deux ensembles de docs côte à côte. Le niveau de convergence est trop flagrant pour être traité comme une coïncidence ou une curiosité. C'est un signal direct sur l'endroit où la capture de valeur réelle dans l'infrastructure IA atterrit vraiment en 2026.

Ce qui m'a frappé en lisant les deux ensembles de docs : les deux équipes savent exactement ce qu'elles font. Elles n'ont pas convergé par accident. Elles ont résolu le même problème de la même manière parce qu'il n'y a vraiment qu'une seule façon qui fonctionne. Et cette façon, ce n'est pas le modèle. C'est le runtime.

TLDR : Anthropic et Google ont livré des plateformes d'agents managés à 2 semaines d'intervalle. Enlevez le branding et vous obtenez 1 architecture identique : même sandbox, même fil MCP, même compteur de facturation 3-axes. Je ne sais pas quelle partie devrait vous inquiéter le plus : à quel point c'est évidemment identique, ou ce que cette similitude est réellement conçue pour posséder.

Le Diagramme Derrière les Deux Keynotes

Les deux produits implémentent la même séparation physique : le "cerveau" du modèle tourne sur le cloud du vendeur. Les "mains" d'exécution d'outils tournent dans un sandbox Linux éphémère que le vendeur possède aussi. Une session persistante connecte les 2 pendant des heures, des jours, ou des semaines.

Anthropic appelle ça "séparation du cerveau et des mains." Google ne se donne pas la peine de le nommer. C'est juste comme ça que l'API Managed Agents fonctionne. Formulation différente. Diagramme identique.

Dans les deux systèmes, vous faites un seul appel API pour provisionner un agent. Le vendeur lance un conteneur Linux isolé dans son propre centre de données. Le modèle décide quoi faire. Quand il veut exécuter des commandes shell, éditer des fichiers, naviguer sur le web, ou appeler un service externe, ces actions s'exécutent dans ce conteneur (pas sur vos serveurs, pas dans une image Docker que vous maintenez, pas dans un Lambda que vous avez provisionné). Le conteneur du vendeur, sur le réseau du vendeur, écrivant dans les logs d'audit du vendeur.

Vous récupérez un flux d'événements : le raisonnement du modèle, les appels d'outils, les sorties. Vous ne touchez jamais la machine. Vous ne pouvez pas. C'est ça le produit.

Pour quiconque a traversé le parcours vibe-coding-vers-production, ceci devrait s'enregistrer comme la décision d'infrastructure exacte que vous preniez déjà manuellement. Vibe Coding, For Real est où je suis entré exactement dans ce compromis, celui où "qui possède le runtime" cesse d'être théorique.

Les 5 Pièces Que Personne N'a Renommées

Une fois que vous acceptez le cadre cerveau-et-mains, le reste de la ressemblance en découle. Les deux plateformes livrent 5 composants, souvent avec des noms qui sont à peine des traductions déguisées l'un de l'autre.

Sandbox éphémère. Anthropic provisionne un conteneur Linux frais par session, monte des fichiers dans /workspace, et expose bash, les opérations de fichiers, et la navigation web comme outils natifs. Google fait pareil : un sandbox Linux, un outil code_execution, un outil google_search, un outil url_context. Les deux par défaut refusent tout le réseau. Les deux vous laissent monter des fichiers depuis le stockage cloud ou cloner un repo Git au démarrage.

Sessions avec état et checkpointing. Anthropic préserve le système de fichiers du conteneur, les packages installés, et l'historique de conversation à travers les déconnexions, gardant les checkpoints pendant 30 jours d'inactivité. Google fait pareil via l'API Interactions : passez un previous_interaction_id et le serveur reconstruit tout le contexte antérieur. Les deux appellent ça l'exécution "avec état". Les deux ont abandonné leurs APIs sans état originales comme primitive agentique.

Le protocole fil : MCP. Les deux produits ont convergé sur le Model Context Protocol (le standard qu'Anthropic a open-sourcé fin 2024) comme façon pour les agents de parler aux systèmes externes. Les deux exposent un Vault pour les identifiants, donc les clés API n'apparaissent jamais dans vos prompts d'agent ou votre code. Les deux injectent les identifiants à la frontière de sortie réseau. Google a ajouté "MCP Tunnels" pour l'accès réseau privé sortant uniquement en mai 2026. Anthropic a livré la même capacité sous le même nom le même mois. Si vous réfléchissiez à pourquoi les CLIs surpassent encore MCP managé pour certaines charges de travail, cette convergence change directement ce calcul.

La couche d'orchestration. L'orchestration multi-agents est passée de "framework tiers que vous boulonnez" à "fonctionnalité API native" dans les deux écosystèmes à presque exactement le même moment. Version d'Anthropic : un lead_agent déclare une liste de sous-agents et synthétise leurs sorties parallèles. Version de Google : le Shared Agent Harness d'Antigravity instancie des sous-agents parallèles depuis un seul projet. Les deux cannibalisent la raison d'être de LangGraph, CrewAI, et LlamaIndex.

Couches évaluateur et mémoire. Anthropic livre "Outcomes" : un second LLM qui note la sortie de l'agent contre une rubrique et boucle jusqu'à ce qu'elle passe. Google livre des hooks de cycle de vie (post_tool_call, post_turn) qui jouent essentiellement le même rôle, des checkpoints déterministes dans une boucle probabiliste. Anthropic livre "Dreaming" pour la consolidation de mémoire à long terme entre sessions. Google livre la compaction automatique de contexte à environ 135K tokens avec rétention des "variables d'état critiques." Mécanismes différents, même travail : empêcher l'agent de s'oublier et de soumettre confidemment des déchets. (Opus performe notablement mieux que Sonnet sur les boucles d'évaluateur, au fait. Factorisez ça dans votre routage de modèle avant de vous engager sur un niveau.)

Le Piège de Facturation 3-Axes

La plupart des builders sautent directement aux docs du sandbox. La page de facturation est où l'architecture se révèle.

Avant : les deux plateformes utilisaient une tarification simple par million de tokens. Vous pouviez estimer votre facture mensuelle sur une serviette. Votre équipe FinOps était à l'aise, relativement.

Après : les deux entreprises ont abandonné la facturation tokens-seulement exactement au même moment, et les deux l'ont remplacée par 3 compteurs simultanés :

• Tokens consommés (entrée et sortie, avec des remises de cache agressives sur le contexte répété)
• Secondes de runtime actives : Anthropic facture environ 0,08$ par heure de temps de conteneur pendant que status = running. Google facture les heures de conteneur essentiellement de la même façon via Vertex/AI Studio, avec le compteur qui se met en pause pendant les attentes inactives d'entrée utilisateur.
• Appels d'outils spécifiques : recherche web facturée à des fractions de centime par requête, en plus de tout le reste.

Le temps d'inactivité est gratuit dans les deux systèmes. Attendre une confirmation humaine est gratuit. L'horloge ne tourne que quand l'agent raisonne ou exécute activement. C'est une amélioration significative par rapport aux anciens modèles d'heures de conteneur.

Il y a un effet pervers de second ordre que les deux pages de tarification révèlent une fois que vous faites le calcul : les modèles moins chers peuvent coûter plus. Un agent Haiku ou Flash qui prend 5 itérations pour résoudre ce qu'Opus ou Pro résout en 1 finit par brûler 5x les secondes de runtime, 5x les appels d'outils, et une fraction non-triviale des économies de tokens. Le problème d'optimisation n'est plus "choisir le modèle le moins cher." C'est "trouver le modèle dont le taux d'échec par tâche est assez bas pour que le compteur de runtime ne mange pas vos économies." Aucun vendeur n'a un tableau de bord qui vous dit lequel c'est pour votre charge de travail. Vous le découvrirez sur la facture. 😅

Où Ils Divergent Vraiment

3 vraies différences. Ce sont celles qui devraient affecter votre choix.

Posture de conformité. Les Managed Agents d'Anthropic ne sont explicitement pas éligibles pour Zero Data Retention ou la couverture HIPAA BAA sous leur forme actuelle, parce que les checkpoints persistants doivent vivre quelque part, et ce quelque part est le stockage d'Anthropic. L'offre de Google passe par l'enveloppe de conformité existante de Vertex AI, qui est plus large en vertu du track record entreprise de GCP. Si vous êtes dans la santé, la défense, ou la finance réglementée, cet écart est la seule chose qui compte ce trimestre.

L'échappatoire auto-hébergée. Anthropic a reconnu le problème de conformité et a livré des sandboxes auto-hébergés en mai 2026 : le cerveau reste dans leur cloud, les mains bougent vers votre infrastructure via des partenaires comme Cloudflare, Modal, Vercel, et Daytona. Google n'a pas livré d'équivalent. Si garder l'exécution dans votre périmètre réseau est non-négociable, Anthropic gagne actuellement ceci.

La surface développeur. Google a emballé une app desktop (Antigravity 2.0), le CLI agy, et un SDK Python dans un seul écosystème avec sync bidirectionnelle. Anthropic livre une API et laisse l'écosystème construire les surfaces. Que ce soit une fonctionnalité ou un bug dépend entièrement de si vous voulez un IDE poli possédé par le vendeur ou une API flexible que vous wrappez dans vos propres outils.

Tout le reste : modèle de sandbox, axes de facturation, MCP, multi-agent, evals, mémoire, vault, checkpoints. Même produit.

Pourquoi Ils Ont Convergé

Ce n'est pas une coïncidence. C'est la forme naturelle du problème, et comprendre cette forme fait de vous un acheteur moins naïf.

Si vous êtes un vendeur de modèle fondamental en 2026, le modèle lui-même est la couche la plus facilement commoditisée de votre stack. Les clients routent Haiku pour les tâches bon marché, Sonnet pour le moyen, Opus pour le dur, Gemini pour le multimodal, GPT pour ce qui reste. Ils benchmarkent trimestriellement et changent de routes mensuellement.

Le modèle, vous le louez. Le runtime accumule du lock-in avec chaque appel d'outil et checkpoint. Donc les deux vendeurs ont fait la chose évidente et ont tendu la main vers le runtime au même moment, avec la même réponse architecturale, parce qu'il n'y a vraiment qu'une seule réponse architecturale qui fonctionne.

En fait, laissez-moi le dire différemment. La dynamique du runtime est la chose que les builders sont les plus lents à internaliser, et ça vaut le coup de s'y attarder une seconde. Une fois que votre client a câblé ses serveurs MCP dans votre Vault, stocké ses identifiants dans votre système de gestion de clés, écrit ses prompts d'agent contre votre sémantique de sandbox, configuré son pipeline d'audit contre votre schéma d'événements, et accumulé 30 jours d'état de checkpoint dans votre couche de stockage, changer de vendeur cesse de ressembler à un après-midi de changements de config et commence à ressembler à une migration cloud : projet multi-mois, sign-off cross-fonctionnel, implication du CFO, tout le tralala.

Les dommages collatéraux sont l'écosystème d'orchestration tiers. LangChain, LangGraph, LlamaIndex, CrewAI : ces frameworks existaient pour coller une API de modèle sans état avec un environnement d'exécution avec état que vous provisionniez vous-même. Les deux vendeurs viennent d'absorber les deux moitiés. La couche de colle n'a plus rien à coller.

En travaillant avec les deux écosystèmes ces 6 derniers mois, le pattern était déjà visible dans comment les deux entreprises étendaient discrètement leurs APIs pour absorber plus de stack. L'annonce du runtime managé était moins une surprise qu'une formalisation de quelque chose déjà en cours. L'écart de 2 semaines entre les lancements était une coïncidence de calendriers de release. La décision sous-jacente a été prise des mois plus tôt par les deux équipes, probablement indépendamment, après avoir fixé le même problème de tableau blanc.

(Petite digression qui n'a rien à voir avec les agents : une boulangerie près de mon appartement a changé de propriétaire deux fois en 3 ans. Chaque nouveau propriétaire, indépendamment, a apporté la même machine à espresso et la même recette de croissant. Ils ne s'étaient jamais parlé. Parfois il n'y a qu'une seule bonne réponse, et la convergence c'est juste à quoi ça ressemble quand 2 équipes séparées la trouvent.)

4 Choses à Faire Avant de Vous Engager

Traitez le runtime d'agent comme le risque de migration qu'il est. Architecturez vos prompts, outils, et serveurs MCP pour être portables. À la minute où vous commencez à utiliser des types d'événements spécifiques au vendeur ou des primitives d'orchestration sans analogues de l'autre côté, vous avez doublé votre coût de sortie.

Ne mettez pas votre seule copie d'état important dans un checkpoint vendeur. Persistez ce qui vous importe vraiment (sorties, pistes d'audit, artefacts intermédiaires) vers un stockage que vous contrôlez. Traitez l'état de session du vendeur comme un cache, pas une source de vérité.

Mesurez le coût de runtime par tâche, pas par token. La facturation 3-axes fait du coût token le nombre le moins informatif sur votre facture. Taguez chaque run d'agent avec un type de tâche et un choix de modèle, puis regardez les colonnes runtime-seconds et tool-call plus que la colonne token.

Choisissez le côté avec la posture de conformité dont vous avez besoin maintenant, pas celui avec la meilleure démo. Les démos sont interchangeables. Les docs de conformité ne le sont pas.

Si vous essayez encore de comprendre comment structurer vos prompts d'agent avant de vous engager sur un runtime managé, le framework de contrats de prompts que j'ai construit vaut la lecture d'abord. Y aller avec une approche structurée de l'architecture de prompts rend l'évaluation plus propre : vous saurez exactement ce que vous remettez.

---

Managed Agents, les deux versions, est un produit genuinement bon. Le gain de productivité est réel et large. Avant : provisionner un sandbox sécurisé, câbler la rotation d'identifiants, construire un pipeline d'événements debuggable. Des semaines de plomberie. Maintenant c'est 1 appel API. Difficile d'argumenter contre ça.

Le prix : votre runtime n'est plus le vôtre. Le sandbox est le leur, et tout ce qui est en aval de ce premier appel API aussi (identifiants, logs, votre état d'agent s'accumulant dans leurs checkpoints). Dans quelques années vous regarderez en arrière et penserez que ça ressemblait exactement à Lambda en 2019 : vous avez fait le même calcul, et c'était probablement le bon.

Donc choisissez votre vendeur. Mais choisissez avec le lock-in déjà pricé. Le modèle, vous pouvez le swapper n'importe quel lundi matin. Le runtime est une migration cloud, et vous ne faites pas ça entre 2 verres de Saint-Émilion.

Sources

• Documentation bêta publique Anthropic Managed Agents, avril 2026
• Google I/O 2026 : annonce Project Antigravity et Gemini Managed Agents
• Annonce sandboxes auto-hébergés Anthropic, mai 2026 (partenariats Cloudflare, Modal, Vercel, Daytona)

Ce post peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission — ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture.