A2A vs MCP : comparatif agent-outil et agent-agent

A2A et MCP sont deux protocoles ouverts et complémentaires pour les agents IA. MCP (Model Context Protocol, créé à l'origine par Anthropic, novembre 2024) relie un agent à des outils, des données et du contexte : c'est le niveau agent-outil. A2A (Agent2Agent, créé à l'origine par Google, avril 2025) permet à des agents autonomes de coopérer entre eux : c'est le niveau agent-agent. Ils ne se font pas concurrence. Ils résolvent des problèmes différents et, dans la pratique, sont utilisés ensemble.

Une fois que tu as intégré qu'il s'agit de deux couches de la même stack, et non de deux camps dans une guerre des standards, tu prends vite de meilleures décisions d'architecture.

• MCP donne des outils à un agent. Il standardise la manière dont un agent interroge une base de données, lit un CRM, ouvre un fichier ou lance une recherche web.
• A2A permet aux agents de collaborer. Il standardise la manière dont un agent délègue une tâche à un autre agent autonome, y compris au-delà des frontières entre systèmes et fournisseurs.
• Les deux se complètent. La documentation d'A2A le résume ainsi : A2A s'adresse aux agents qui travaillent ensemble sur des tâches, MCP aux agents qui utilisent des capacités. IBM confirme la même ligne après la fusion de son projet ACP.

Le modèle mental : des mains face à une langue commune

Une image facile à retenir : MCP donne à un agent des mains, c'est-à-dire la capacité de saisir, de lire et d'agir dans le monde extérieur. A2A donne à plusieurs agents une langue commune, c'est-à-dire la capacité de se confier mutuellement des missions et de renvoyer des résultats, sans qu'aucun n'ait à dévoiler à l'autre ses prompts, ses modèles ou sa mémoire.

Le choix conceptuel décisif d'A2A, c'est que la logique interne de l'agent distant reste opaque. A2A définit comment les agents se parlent, pas comment ils pensent. C'est précisément ce qui permet à un agent Salesforce d'appeler un agent SAP sans qu'aucun des deux ait à divulguer ses prompts internes. MCP, à l'inverse, expose un outil avec un schéma clairement décrit. Ici, la transparence sur la capacité est justement tout l'intérêt.

Comparatif technique : dimension, MCP et A2A

Les deux protocoles reposent sur JSON-RPC 2.0 et relèvent de la Linux Foundation. Cela souligne qu'ils sont pensés comme une seule et même stack.

MCP a connu en 2025 une véritable explosion de son adoption : OpenAI l'a adopté en mars 2025, Google DeepMind en avril 2025, sans oublier Microsoft Copilot Studio, Cursor, Zed, Replit et bien d'autres. A2A est désormais soutenu par plus de 100 entreprises ; les membres fondateurs du projet de la Linux Foundation sont AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow.

Pourquoi « complémentaire » est à prendre au pied de la lettre

Il existe une zone grise technique qui sème souvent la confusion dans les discussions : on peut exposer un agent comme serveur MCP et le rendre ainsi accessible à d'autres agents sous forme d'outil. Cela fonctionne, mais ce n'était pas la finalité de MCP, et Google comme Microsoft misent sur A2A pour une véritable collaboration entre pairs.

La raison tient à la sémantique. MCP connaît l'appel d'outil : une requête entre, une réponse sort. A2A connaît un cycle de vie des tâches complet, avec des états intermédiaires, conçu pour une coopération de longue durée qui peut impliquer des demandes de précision, y compris l'état input-required lorsque l'agent distant a besoin d'une clarification. Reconstruire l'agent-agent sur MCP, c'est perdre précisément cette mécanique.

Historiquement, un troisième protocole a brièvement existé : ACP d'IBM (Agent Communication Protocol, mars 2025). Il a fusionné avec A2A le 29 août 2025 sous l'égide de LF AI & Data. Les principes de conception d'ACP (REST, asynchrone par défaut) perdurent dans A2A. Le tableau pour 2026 est donc clair : MCP + A2A constitue la stack convergente. AGNTCY (Cisco, entre autres) est une couche d'identité, de découverte et d'observabilité au-dessus d'A2A et de MCP, pas un concurrent. NANDA (MIT Media Lab) relève de la recherche et n'a pas sa place dans les décisions de production en 2026.

Exemple combiné : gestion des sinistres avec les deux protocoles

Un exemple concret et simplifié rend cette interaction tangible. Imagine un workflow d'assurance inspiré du projet documenté « Nemo » d'Allianz, qui mobilise sept agents spécialisés (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) et traite un sinistre en moins de cinq minutes (avec un humain dans la boucle pour la décision finale d'indemnisation).

Le déroulement, du point de vue de l'architecture :

1. Niveau A2A : l'orchestrateur envoie via A2A trois tâches à des agents pairs spécialisés : « Vérifier la couverture pour le dossier #4711 » au coverage_agent, « Vérifier les indicateurs de fraude #4711 » au fraud_agent et « Données météo à la date du sinistre » au weather_agent.
2. Niveau MCP : chaque agent pair accède en interne à ses outils via MCP. Le coverage_agent interroge le serveur MCP « Base de données des polices », le fraud_agent utilise le serveur MCP « API de scoring de fraude », le weather_agent le serveur MCP « API du service météo ».
3. Retour : chaque tâche parcourt le cycle de vie A2A submitted → working → completed. Les résultats reviennent sous forme d'artefacts A2A, et l'orchestrateur les consolide.

La répartition des tâches entre les agents passe par A2A : l'orchestrateur ne sait pas, et n'a pas besoin de savoir, quel modèle ou quel prompt se cache dans l'agent Fraud. Mais dès qu'un agent individuel interroge la base de données des polices ou sollicite une API météo, cela passe par MCP. A2A coordonne les têtes, MCP actionne les mains. C'est précisément cette séparation nette qui explique pourquoi les deux protocoles sont considérés comme complémentaires.

Pour situer le rapport coûts-bénéfices : le système de recherche multi-agents documenté d'Anthropic (Claude Opus 4 comme agent principal, sous-agents parallèles avec Claude Sonnet 4) a surpassé de 90,2 % un agent Opus 4 seul lors de l'évaluation de recherche interne. En contrepartie, il a consommé environ 15 fois plus de tokens qu'une interaction de chat normale, contre environ 4 fois pour un agent seul. L'architecture multi-agents (et donc A2A) est surtout rentable pour des tâches parallélisables et de grande ampleur, pas comme une fin en soi.

La réalité européenne : la complémentarité a un coût en conformité

Pour les décideurs B2B en Europe, une conséquence importante est rarement nommée avec franchise dans les architectures de référence centrées sur les États-Unis : lorsque des agents tournent via A2A chez différents fournisseurs et déclenchent au passage des appels d'outils MCP, le flux de données franchit, pour chaque tâche, plusieurs frontières de traitement et, le cas échéant, de résidence des données.

Chaque saut A2A et chaque serveur MCP est potentiellement un sous-traitant à part entière au sens du RGPD (art. 28). Dans la pratique, la complémentarité au niveau des protocoles implique donc une chaîne de contrats de sous-traitance plus longue et, pour les sauts transfrontaliers, une question de transfert propre à chaque saut (art. 44–49). Si tu exploites un environnement hybride Salesforce, SAP et Microsoft, tu as intérêt à journaliser ces sauts dès le départ avec un trace ID unique de bout en bout et à documenter la chaîne de contrats de sous-traitance pour chaque agent.

Pour les agences et les décideurs B2B

La recommandation pratique est sans ambiguïté : MCP pour les outils, A2A pour les agents. En 2026, tout le reste constitue un écart délibéré par rapport à la stack convergente et doit être justifié. Pour les PME européennes, cela signifie concrètement développer d'abord des compétences MCP (tu écriras ou consommeras de toute façon des serveurs MCP) et introduire A2A dès que des agents doivent coopérer au-delà des frontières entre systèmes et fournisseurs.

Pour les agences et les fournisseurs de produits liés à l'IA, le principal levier stratégique consiste à publier une AgentCard pour chaque agent proposé comme produit. Ainsi, l'environnement d'un client peut appeler ton agent directement depuis Agentforce, Joule ou Copilot Studio via A2A, sans intégration spécifique coûteuse. Si tu veux concevoir une stratégie multi-agents pour ton entreprise ou pour tes clients, c'est exactement ici qu'il faut commencer : séparation claire des protocoles, chaînes de contrats de sous-traitance documentées et agents découvrables via A2A dès le premier jour. Contacte-nous si tu veux mettre en place cette architecture de manière solide dans ton contexte.