Tu choisis un framework d'agents ce mois-ci. OpenAI a open-sourcé le sien. Anthropic a verrouillé le sien sur Claude. Et Google a livré ADK — Agent Development Kit — une boîte à outils pour construire des agents IA qui font des trucs à ta place. Tu as arrêté de suivre les acronymes de Google après le troisième, et c'est compréhensible.

Mais voilà ce qui compte : ADK est le seul framework majeur qui parle nativement A2A et MCP — les deux protocoles que le reste de l'industrie traite comme le problème du voisin. A2A (Agent-to-Agent) permet aux agents IA de communiquer entre eux. MCP (Model Context Protocol) permet aux agents de se brancher sur des outils et données externes — comme des ports USB pour l'IA. Le SDK d'OpenAI intègre MCP mais ignore A2A. Le SDK d'Anthropic intègre MCP (ils l'ont inventé) et considère A2A comme optionnel. Google livre les deux clés en main.

C'est un vrai avantage technique. C'est aussi le coup d'ouverture de la stratégie de verrouillage la plus soigneusement conçue de la guerre d'infrastructure IA actuelle.

Trois stratégies de verrouillage

Chaque grand acteur de l'IA capture les développeurs différemment. Voici la taxonomie que personne ne dessine encore sur les tableaux blancs, et qui explique pourquoi l'avantage protocolaire d'ADK n'est pas de la philanthropie.

OpenAI capture au niveau du SDK. pip install openai, suis le quickstart, construis un truc en un après-midi. L'API est propre, la doc est bonne, l'écosystème est massif. Le temps que tu réalises que tu es piégé, t'as 40 000 lignes de code qui appellent des endpoints spécifiques à OpenAI. Migrer, c'est tout réécrire. Le SDK, c'est la douve.

Anthropic capture au niveau du modèle. Tu restes parce que Claude est bon dans ce dont tu as besoin — contexte long, suivi d'instructions, code. Le SDK est secondaire. La qualité du modèle, c'est la gravité. Si un meilleur modèle apparaît, tu pars. Sinon, tu restes. Physique élémentaire.

Google capture au niveau de l'infrastructure. ADK est gratuit. Les protocoles sont ouverts. Le chemin vers la production passe par Vertex AI Agent Engine — le runtime managé de Google — et le verrouillage par l'infrastructure est le plus dur à quitter. Tu ne vois pas les murs monter parce que chaque brique ressemble à une facilité.

Ce n'est pas de la spéculation. C'est de l'architecture.

Ce que "A2A natif" signifie concrètement

La plupart des comparatifs de frameworks s'arrêtent à "supporte A2A". Personne n'explique ce que ça veut dire quand tu ouvres un terminal.

Quand tu construis un agent ADK, tu l'exposes comme un serveur conforme A2A avec un simple décorateur. Le framework génère l'Agent Card requis — un manifeste JSON qui indique aux autres agents ce que le tien sait faire, quelles entrées il accepte, quelles sorties il retourne. Les autres agents conformes A2A découvrent le tien en interrogeant /.well-known/agent.json, lisent la carte, et démarrent une Task — l'unité de travail d'A2A.

Le 3 avril, Google a livré ADK v1.24.0 avec orchestration par graphe de workflows, auto-rendering d'interfaces, et un écosystème d'intégrations — AgentOps, Arize, MLflow, n8n, plus de 200 connecteurs SaaS via StackOne. Quatre langages : Python, TypeScript, Go, Java. Plus de 200 modèles via Model Garden — Gemini, Claude, GPT, Llama, Mistral.

Le framework gère le cycle de vie des tâches A2A (submitted → working → completed/failed), streame les résultats partiels via Server-Sent Events, et orchestre l'échange d'artifacts entre agents. MCP fonctionne en parallèle : ton agent appelle des outils externes via MCP tout en se coordonnant avec les agents pairs via A2A. Deux protocoles, un runtime, zéro code de liaison.

Sur le papier, c'est exactement ce dont les systèmes multi-agents ont besoin. En pratique, c'est la première couche d'un entonnoir très précis.

Comment le piège se referme

ADK tourne en open source sur ta machine. Tu peux développer, tester et prototyper sans toucher à Google Cloud. C'est voulu — la rampe d'accès est sans friction.

La production, c'est Vertex AI Agent Engine — où Google facture 0,00994 $/vCPU-heure avec les tokens LLM facturés séparément, tarification active depuis février 2026. Des tarifs raisonnables. Rien d'alarmant sur la facture.

Mais le piège, ce n'est pas le prix. C'est la gravité protocolaire.

Voilà comment ça marche : si ton système multi-agents dépend d'A2A pour la coordination, et que les agents ADK parlent A2A nativement, chaque nouvel agent que tu ajoutes tire vers ADK. Pas parce qu'ADK est meilleur pour la tâche — parce qu'ADK est meilleur pour le protocole. Tu choisis ADK pour l'Agent #3 parce que les Agents #1 et #2 parlent déjà A2A. Tu le choisis pour l'Agent #4 pour la même raison. Chaque agent renforce l'effet de réseau.

Chaque agent ADK en développement tourne nickel sur ton laptop. Chaque agent ADK en production tire vers Vertex. Google Cloud gère ton routage de tâches A2A, ton stockage d'artifacts, ta découverte d'agents. Plus tu déploies d'agents, plus l'intégration est profonde. Plus l'intégration est profonde, plus le coût de migration est élevé.

C'est l'économie de plateforme classique déguisée en open source. Le framework est gratuit. Le protocole est ouvert. Le runtime de production est celui de Google, et quand tu fais tourner quinze agents coordonnés via A2A sur Vertex, "il suffit de migrer sur AWS" est un projet de migration de six mois.

Google n'a pas construit un protocole ouvert pour l'interopérabilité. Google a construit un protocole ouvert pour l'adoption, et un runtime propriétaire pour le chiffre d'affaires.

Le fossé d'interopérabilité

L'avantage A2A d'ADK a un plafond pratique : le protocole connecte surtout des agents ADK à d'autres agents ADK. Ni le SDK d'Anthropic ni celui d'OpenAI n'exposent nativement des endpoints A2A. Câbler un maillage d'agents multi-éditeurs exige encore du middleware custom — exactement le code de liaison que le support natif du protocole promettait d'éliminer.

Cela n'invalide pas l'architecture d'ADK. Ça la contextualise. L'avantage protocolaire est réel au sein de l'écosystème Google. Inter-écosystèmes, tu écris encore des adaptateurs. La gravité tire vers l'intérieur, pas vers l'extérieur.

Ce que ça implique

Google Cloud Next commence le 22 avril. La session BRK3-022 promet la roadmap d'ADK et affirme que Google "utilise ADK pour son propre engineering interne". Le slide à surveiller, ce n'est pas la liste de fonctionnalités — c'est s'ils montrent un agent non-Google qui parle A2A à un agent ADK sans middleware custom. Cette démo existe ou elle n'existe pas.

Le support protocolaire d'ADK est véritablement en avance sur les offres d'OpenAI et d'Anthropic. L'architecture technique est solide. Support de quatre langages, compatibilité avec plus de 200 modèles, streaming SSE et échange d'artifacts sont des capacités réelles, pas du vaporware.

Mais la question n'a jamais été "ADK est-il bon ?" La question est "où est-ce qu'ADK-le-bon t'emmène ?" Et la réponse, c'est Vertex AI Agent Engine, facturé au vCPU-heure, avec des coûts de migration qui s'accumulent à chaque agent déployé.

Trois entreprises. Trois stratégies de verrouillage. OpenAI parie que tu ne réécrieras pas ton code. Anthropic parie que tu ne trouveras pas un meilleur modèle. Google parie que tu ne migreras pas ton infrastructure.

Le pari de Google est le plus patient. C'est aussi le plus dur à fuir — si tant est que quelqu'un essaie un jour.