A2A fete son premier anniversaire. Aucun SDK majeur ne l'integre.

Le protocole A2A de Google a soufflé sa première bougie le 9 avril. Cent cinquante organisations signataires. Vingt-deux mille étoiles GitHub. Cinq SDK de production. Le protocole concurrent ACP d'IBM a fusionné dedans sous l'égide de la Linux Foundation. Azure AI Foundry et Amazon Bedrock AgentCore l'intègrent tous les deux.

Selon tous les indicateurs sauf celui qui compte, A2A a gagné.

L'indicateur qui compte : aucun SDK majeur d'agents n'intègre nativement A2A aujourd'hui. Pas un seul. Le protocole censé permettre à n'importe quel agent IA de découvrir et déléguer des tâches à n'importe quel autre agent — quel que soit le fournisseur — a passé toute sa première année à collectionner des logos pendant que les SDK réellement utilisés par les développeurs partaient dans la direction opposée.

Treize jours, quatre fossés

Entre le 3 et le 15 avril 2026, quatre entreprises ont livré leurs propres fonctionnalités de délégation multi-agents. Aucune n'est interopérable.

Le 3 avril, Microsoft a publié Agent Framework v1.0 — le seul framework qui tente même une coordination multi-fournisseurs, avec des connecteurs pour Claude, GPT, Gemini et Bedrock. Support A2A ? « Bientôt disponible. » Le 8 avril, Anthropic a lancé Managed Agents en bêta publique : exécution en sandbox, persistance d'état, coordination multi-agents — exclusivement Claude, aucune mention d'A2A. Le 9 avril, A2A lui-même a fêté son premier anniversaire avec un communiqué de presse bourré de chiffres et zéro intégration SDK. Puis le 15 avril, OpenAI a livré Agents SDK v0.14 avec les Sandbox Agents et des primitives de handoff — théoriquement agnostique côté modèle, zéro A2A en pratique.

Quatre fournisseurs. Treize jours. Quatre dialectes incompatibles de la même idée. Et le protocole conçu pour les unifier regardait le spectacle depuis son coin, entouré de ses 150 soutiens organisationnels.

À quoi ressemble le « zéro adoption » dans le code

Voici le modèle de délégation d'Anthropic. Tu crées un managed agent via leur API REST — il tourne dans la sandbox d'Anthropic — et ton coordinateur délègue via des sessions :

import anthropic

client = anthropic.Anthropic()

# Créer un managed agent (tourne dans le sandbox cloud d'Anthropic)
agent = client.agents.create(
    model="claude-sonnet-4-20260514",
    instructions="You are a research specialist.",
    tools=[{"type": "web_search"}],
)

# Démarrer une session — le coordinateur envoie une sous-tâche
session = client.sessions.create(
    agent_id=agent.id,
    messages=[{"role": "user", "content": "Analyze A2A adoption metrics"}]
)

Maintenant l'approche OpenAI — runtime différent, philosophie radicalement différente :

from openai_agents import Agent, handoff

research_agent = Agent(name="researcher", model="gpt-4.1")
coding_agent = Agent(name="coder", model="gpt-4.1")

# Handoff : research_agent transfère le contrôle total à coding_agent
research_agent.handoffs = [handoff(coding_agent)]

Deux blocs de code. Deux écosystèmes. Zéro surface d'interface commune. Ton agent Claude ne peut pas faire handoff() vers un agent OpenAI, et ton agent OpenAI ne peut pas faire sessions.create() sur l'infra d'Anthropic. Ils ne partagent littéralement pas un seul appel de méthode.

A2A définit des AgentCards pour la découverte, un cycle de vie des tâches pour la délégation, et du streaming — le tout vendor-neutral. Il a été conçu pour être la couche qui rend les deux snippets ci-dessus inutiles. Au lieu de ça, les deux SDK ont livré sans même reconnaître son existence.

Pourquoi 150 logos n'ont rien donné

A2A a tout ce qu'il faut pour un standard, sauf ce qui fait qu'un standard s'impose : une intégration sans friction au point d'utilisation. Aucun pip install a2a ne se branche sur un projet Anthropic ou OpenAI. Aucun middleware ne traduit automatiquement un handoff() en tâche A2A. Le protocole vit dans son propre dépôt, avec ses propres SDK, obligeant les développeurs à construire et maintenir des couches de traduction entre leur framework d'orchestration réel et le modèle de tâches d'A2A.

Si tu essaies de relier les SDK des différents fournisseurs via A2A aujourd'hui, tu te heurtes au classique problème en N² : chaque paire de SDK nécessite un bridge dédié. Trois fournisseurs, ça fait six bridges. Quatre, ça fait douze. Ça scale à peu près aussi bien que les fax.

Ensuite il y a la latence. Chaque saut de traduction protocolaire ajoute un overhead mesurable — suffisant pour que l'enchaînement de trois agents à travers des couches de bridge brûle un temps perceptible avant même que la moindre réflexion ne commence. Pour les boucles agentiques qui itèrent sur du raisonnement et de l'utilisation d'outils, ça se cumule vite.

Et la gouvernance reste un angle mort généralisé. Ton agent coordinateur ne peut pas inspecter le raisonnement d'un sous-agent qui tourne sur l'infrastructure d'un autre fournisseur. Tu fais confiance à un output que tu ne peux fondamentalement pas auditer. La spec d'A2A n'adresse pas ce problème non plus.

Le pari de Microsoft — et pourquoi c'est intéressant

L'Agent Framework v1.0 de Microsoft est l'outsider à surveiller. C'est le seul framework en production qui coordonne Claude, GPT, Gemini et Bedrock dans un seul graphe de délégation. Il n'utilise pas encore A2A — la mention « bientôt disponible » fait beaucoup de travail — mais il prouve que l'orchestration multi-fournisseurs est techniquement faisable quand un seul acteur contrôle la couche de routage.

Le hic : quelqu'un doit posséder la couche de routage. Microsoft se porte volontaire. Ce n'est pas de l'interop — c'est une forme différente de lock-in, un étage plus haut.

L'architecture pragmatique

La décision pour quiconque construit aujourd'hui est simple mais amère : choisis l'orchestration mono-fournisseur et utilise les outils MCP comme soupape d'interopérabilité. Le framework d'un seul fournisseur gère le graphe de délégation, MCP s'occupe de l'accès aux données et aux outils externes. C'est exactement le lock-in que la promesse du multi-modèle était censée empêcher.

MCP a prouvé que l'accès aux outils pouvait être standardisé — un protocole, tous les fournisseurs l'ont adopté en quelques mois. La délégation agent-à-agent est le même problème un étage plus haut, et A2A est le candidat évident pour le résoudre. La spec est solide. La gouvernance est réelle. Le soutien organisationnel est large.

Mais un protocole qui n'est pas embarqué dans les SDK que les développeurs utilisent est un protocole qui n'existe que sur le papier. A2A a soufflé sa première bougie. Il a tout, sauf la seule chose qui compte : une ligne dans l'import de quelqu'un d'autre.