On nous pose cette question à peu près à chaque deuxième discovery call : « Faut-il standardiser sur A2A ou MCP ? »
La prémisse de la question est fausse. Ce ne sont pas des concurrents. Ils résolvent des problèmes différents à des couches différentes, et un système à base d'agents IA en bonne santé utilise les deux.
À quoi sert MCP
MCP (Model Context Protocol) est un standard pour les surfaces d'outils. Il répond à : comment un agent basé sur un LLM découvre-t-il et appelle-t-il des outils qui ne font pas partie de son entraînement ? Récupération de documents, requêtes en base de données, APIs de calendrier, services internes — chaque outil publie un serveur MCP, l'agent se connecte, liste les capacités, invoque.
La forme : un agent ↔ plusieurs outils. L'outil est passif ; l'agent décide quand l'appeler.
MCP vous apporte : la découverte de schéma, des paramètres typés, des retours structurés, des frontières d'authentification, du sandboxing. C'est, en substance, un standard RPC ajusté pour les clients à base d'agents IA.
À quoi sert A2A
A2A (les protocoles Agent-to-Agent, dont il existe plusieurs — A2A de Google, AGNTCY, d'autres) est un standard pour la collaboration entre agents. Il répond à : comment plusieurs agents semi-autonomes se coordonnent-ils, se passent-ils des sous-tâches, et agrègent-ils des résultats ?
La forme : agent ↔ agent, avec état. Les deux côtés ont leurs propres boucles de raisonnement. Les handoffs portent du contexte, des résultats intermédiaires, parfois la propriété d'une sous-tâche.
A2A vous apporte : des agent cards (annonces de capacités), des cycles de vie de tâches, du passage de messages, du streaming optionnel et du human-in-the-loop. Ce n'est pas du RPC — c'est plus proche d'un système d'acteurs typés.
Pourquoi la confusion
Les deux impliquent des agents qui parlent à quelque chose par un protocole avec des payloads structurés. Les deux produisent du JSON. Les deux ont des rôles client et serveur. Vu de 10 000 mètres, ils se ressemblent.
Mais le niveau d'autonomie de chaque côté est la vraie distinction :
- Serveur MCP : passif. Répond aux appels. N'a pas de boucle de raisonnement propre.
- Agent A2A : actif. Peut refuser des tâches, proposer des alternatives, transférer à d'autres agents, demander des clarifications.
Si l'autre côté est « récupère cette ligne dans une base de données », c'est MCP. Si l'autre côté est « investigue cette anomalie et dis-moi ce que tu trouves », c'est A2A.
L'architecture qui marche vraiment
Dans chaque système multi-agents que nous avons livré, la décomposition ressemble à ceci :
- Sommet de la stack : un orchestrateur (souvent lui-même un agent) route les requêtes utilisateur vers les agents spécialistes.
- Les agents spécialistes communiquent via A2A. Les handoffs préservent le contexte ; les superviseurs suivent l'état des tâches.
- Les spécialistes utilisent des outils via MCP. L'agent de récupération a une connexion MCP vers une base vectorielle et une connexion MCP vers un service de recherche fulltext. L'« agent ops » a une connexion MCP vers un système de tickets.
A2A est la manière dont les agents se coordonnent. MCP est la manière dont chaque agent agit.
Le point de vue pragmatique
Adoptez MCP en premier — il résout le problème le plus immédiat (parler aux outils), il a aujourd'hui l'écosystème le plus large (la plupart des fournisseurs de LLM livrent un support MCP natif), et le chemin de mise à niveau depuis les « tool calls ad-hoc » vers MCP est direct.
Adoptez A2A quand vous avez plus d'un agent qui doit transférer du travail. Si votre système a un seul agent + beaucoup d'outils, A2A est de la sur-ingénierie — vous ne coordonnez personne. Dès l'instant où vous ajoutez un second agent spécialiste qui doit parler au premier, A2A commence à rentabiliser son coût.
Ne choisissez pas. Empilez-les.