A2A vs MCP : Choisir le bon protocole pour la communication entre agents

La plupart des systèmes d'agents de production nécessitent deux protocoles, pas un seul. Le Model Context Protocol (MCP) donne à un agent l'accès aux outils et aux sources de données — enregistrements NetSuite, contacts HubSpot, catalogues de fournisseurs, requêtes Redshift. L'Agent2Agent Protocol (A2A) donne aux agents un moyen de déléguer du travail à d'autres agents — un agent de devis demandant à un agent de catalogue des pièces de substitution, un agent d'approvisionnement demandant à un agent de conformité de vérifier une certification GMP. Confondre les deux conduit à des architectures fragiles : utiliser A2A pour appeler une base de données, ou utiliser MCP pour coordonner deux agents indépendants, produit des systèmes qui luttent contre la conception de leur propre protocole.

Le 1er août 2026, OpenAI a confirmé Astra — sa prochaine famille de modèles majeure, explicitement conçue pour les tâches multi-agents de longue durée qui travaillent sur des problèmes pendant des heures ou des jours. Une version interne a résolu dix problèmes ouverts précédemment non résolus en mathématiques et en informatique théorique, avec un coût total de tokens d'environ 2 000 $. Astra coordonne plusieurs agents sur des périodes prolongées, ce qui est exactement le modèle où A2A (délégation agent-à-agent) et MCP (accès agent-à-outil) doivent travailler ensemble. La couche de modèle est désormais construite pour le modèle à deux protocoles.

Cet article est un cadre de décision pour les équipes qui choisissent entre A2A et MCP — ou, plus couramment, qui décident où chacun va dans un système multi-agents. Il suppose que vous comprenez les bases de chaque protocole. Si vous avez besoin d'une présentation d'intégration, le pont A2A Hermes Agent et la vue d'ensemble de la pile de protocoles MCP + A2A couvrent le côté implémentation.

La distinction en une ligne

MCP connecte un agent aux outils. A2A connecte les agents aux agents. MCP est un protocole d'appel d'outils — un agent demande une ressource ou invoque une fonction, et un serveur répond avec des données structurées. A2A est un protocole de délégation de tâches — un agent envoie une unité de travail à un autre agent, reçoit une sortie en streaming et suit la tâche via une machine à états. Le modèle de production, confirmé sur plus de 150 organisations A2A et plus de 10 000 serveurs MCP, est : A2A entre agents, MCP entre agents et outils.

Où chaque protocole s'intègre

Dimension	MCP	A2A
Ce qu'il connecte	Agent → outil, source de données, API	Agent → agent
Unité de travail	Appel d'outil (requête/réponse)	Tâche (cycle de vie avec état)
Corps du protocole	Anthropic (spec ouverte, final 2026-07-28)	Google (spec ouverte, Linux Foundation, 150+ organisations)
Transport	STDIO, Streamable HTTP (SSE déprécié, sunset 12 mois)	JSON-RPC 2.0 sur HTTP, streaming SSE
Découverte	Le serveur enregistre les outils ; le client découvre	Agent Card à /.well-known/agent-card.json
État	Sans état (spec 2026-07-28) ; l'état vit dans le client	Machine à états de tâche : submitted → working → input-required → completed/failed/canceled
Streaming	Les résultats d'outils sont des réponses uniques	message/stream pour la livraison en temps réel des tokens et artefacts
Humain dans la boucle	Pas un concept de premier ordre	INPUT_REQUIRED est un état de tâche de premier ordre
Authentification	Par serveur ; OAuth 2.1 dans la spec, jetons porteurs en pratique	Par agent ; l'Agent Card déclare les schémas d'authentification, la passerelle gère l'application
Adoption	10 000+ serveurs, 4 SDK Tier 1 (TypeScript, Python, Go, C#)	150+ organisations, gouvernance Linux Foundation

Le tableau répond à la première question que la plupart des équipes posent : si votre intégration est « un agent doit interroger NetSuite pour un enregistrement client », c'est MCP. Si votre intégration est « un agent d'approvisionnement demande à un agent de tarification d'évaluer trois devis de fournisseurs et de renvoyer une recommandation », c'est A2A. La distinction est de savoir si la chose de l'autre côté a son propre raisonnement, ou si c'est une source de données qui répond à une requête structurée.

Les cinq questions qui déterminent la répartition

1. L'autre côté raisonne-t-il ou répond-il ?

Un serveur MCP NetSuite ne raisonne pas. Il reçoit un appel d'outil (get_customer, search_items), interroge l'API et renvoie du JSON structuré. L'agent qui l'a appelé fait le raisonnement. Un agent de tarification A2A raisonne — il reçoit une tâche (« évaluez ces trois devis par rapport aux prix historiques et à la fiabilité du fournisseur »), exécute sa propre inférence de modèle, peut appeler ses propres outils MCP et renvoie une recommandation avec le raisonnement attaché.

Si l'autre côté est une source de données ou une API, utilisez MCP. Si l'autre côté est un agent autonome avec son propre modèle, ses propres outils et sa propre prise de décision, utilisez A2A. Le test pratique : la chose que vous appelez a-t-elle son propre prompt ? Si oui, A2A. Si non, MCP.

2. Avez-vous besoin d'une sortie en streaming ?

Les appels d'outils MCP sont requête/réponse. Le serveur traite la requête et renvoie un résultat unique. Il n'y a pas d'état intermédiaire, pas de streaming token par token, pas d'artefacts partiels. C'est bien pour interroger une base de données ou récupérer un enregistrement — vous voulez le résultat complet, pas un flux de fragments.

A2A prend en charge message/stream, qui livre les deltas de tokens et les artefacts au fur et à mesure de leur production. Un agent de tarification qui prend 30 secondes pour évaluer trois devis peut diffuser son raisonnement pendant qu'il travaille, afin que l'agent appelant (et l'humain qui observe) puisse voir la progression, détecter les erreurs tôt et annuler si le raisonnement dérive. Si votre flux de travail produit une sortie au fil du temps et que vous devez agir sur des résultats partiels, A2A est le protocole qui le prend en charge nativement.

3. Y a-t-il une porte d'approbation humaine ?

MCP n'a pas de concept de premier ordre pour l'humain dans la boucle. Vous pouvez construire une logique d'approbation dans l'agent qui appelle les outils MCP — l'agent s'interrompt, demande à un humain, puis procède — mais le protocole lui-même ne l'encode pas. L'état d'approbation vit dans votre code d'application, pas dans le protocole.

A2A définit INPUT_REQUIRED comme un état de tâche de premier ordre. Lorsqu'un agent atteint une décision qui nécessite une approbation humaine — une autorisation d'achat, une approbation de devis, une décision d'accès aux données — il fait passer la tâche à INPUT_REQUIRED. L'agent appelant (ou l'opérateur humain derrière lui) voit un état de protocole standard, pas un détail spécifique au framework. Quand l'humain répond, la tâche reprend. Si votre flux de travail inclut des portes d'approbation qui traversent les frontières des agents, A2A transporte ces portes de manière transparente. Le pont A2A de Hermes Agent mappe les demandes d'approbation natives de Hermes à l'état INPUT_REQUIRED d'A2A, de sorte qu'une chaîne de délégation d'agents peut inclure un point de contrôle humain quel que soit le framework sur lequel chaque agent s'exécute.

4. Combien de temps prend le travail ?

Les appels d'outils MCP sont conçus pour des opérations courtes et synchrones — interroger une API, récupérer un enregistrement, exécuter un calcul. La spec 2026-07-28 a rendu MCP explicitement sans état, ce qui signifie que le serveur ne maintient pas le contexte de conversation entre les appels. L'état vit dans le client (l'agent), pas dans le serveur. C'est la bonne conception pour les outils : un serveur NetSuite ne devrait pas se souvenir que vous avez interrogé un client il y a cinq minutes.

Les tâches A2A sont conçues pour un travail plus long avec une gestion explicite du cycle de vie. Une tâche passe par submitted → working → completed (ou failed, canceled, input-required). La machine à états fait partie du protocole. Une évaluation de tarification qui prend deux minutes, une vérification de conformité qui prend une heure, ou une tâche de recherche multi-agents qui prend un jour — celles-ci correspondent au modèle de tâche A2A. Astra d'OpenAI, confirmé le 1er août, est conçu pour des tâches qui travaillent sur des problèmes pendant des heures ou des jours. Le modèle de coordination multi-agents d'Astra correspond directement au cycle de vie de tâche A2A, pas au modèle d'appel d'outils sans état de MCP.

5. Appelez-vous un système ou coordonnez-vous plusieurs agents ?

Si votre agent doit parler à NetSuite, HubSpot et BigCommerce, ce sont trois serveurs MCP. Chaque serveur expose des outils ; l'agent les appelle au besoin. L'agent fait la coordination — il décide quel outil appeler, quand et dans quel ordre. Les serveurs MCP ne se connaissent pas entre eux.

Si vous avez un agent d'approvisionnement qui doit déléguer à un agent de catalogue, un agent de tarification et un agent de conformité — chacun avec son propre modèle et ses propres outils — ce sont trois endpoints A2A. L'agent d'approvisionnement envoie des tâches, reçoit des résultats en streaming et coordonne la chaîne de délégation. Les agents de catalogue, de tarification et de conformité peuvent chacun utiliser MCP pour accéder à leurs propres sources de données. Les deux protocoles opèrent à des couches différentes : A2A gère la délégation agent-à-agent, MCP gère l'accès agent-à-outil au sein de chaque agent.

Quand utiliser les deux : le modèle de production

Le modèle de production, confirmé par le guide enterprise de tyk.io et visible à travers les 150+ organisations A2A, est une architecture à deux couches :

Chaque agent spécialisé est un endpoint A2A (expose une Agent Card, accepte des tâches, diffuse des résultats). Chaque agent spécialisé utilise également MCP pour se connecter à ses propres sources de données. L'agent orchestrateur ne parle jamais directement à NetSuite — il délègue à l'agent de tarification, qui utilise MCP pour interroger NetSuite. Cette séparation maintient la surface d'outils de chaque agent gouvernée et auditable, tandis que la couche A2A gère la coordination inter-agents.

L'implémentation de référence du pont A2A de Hermes Agent démontre ce modèle : une passerelle gère la surface du protocole A2A (Agent Card, dispatch JSON-RPC, streaming SSE, machine à états de tâche), et des handlers enfichables traduisent la sémantique de tâche A2A en l'API native de chaque framework. Ajouter un nouveau framework d'agent signifie écrire une classe handler — le protocole, la passerelle et la machine à états sont une infrastructure partagée. La même passerelle peut router vers Hermes Agent, OpenClaw ou tout handler futur sans changer la surface client A2A.

Quand un seul agent suffit

Tous les systèmes n'ont pas besoin d'A2A. La recherche de Princeton NLP a constaté qu'un seul agent égalait ou surpassait un système multi-agents sur 64 % des tâches benchmarkées — à 2× le coût pour la configuration multi-agents. Si votre flux de travail est un seul agent qui interroge NetSuite, rédige un devis et le soumet pour approbation, vous avez besoin de MCP (pour la connexion NetSuite) et d'une porte d'approbation au niveau de l'application. Vous n'avez pas besoin d'A2A.

A2A devient nécessaire lorsque vous avez des agents avec des modèles différents, des surfaces d'outils différentes ou des limites de propriété différentes qui ont besoin de se coordonner. L'agent d'approvisionnement de l'équipe d'achat et l'agent de conformité de l'équipe financière appartiennent à des groupes différents, peuvent s'exécuter sur des infrastructures différentes et ont des sélections de modèles différentes. A2A leur donne un protocole pour déléguer et suivre le travail sans partager de base de code ou de déploiement. Si tous vos agents sont le même modèle sur la même infrastructure avec le même propriétaire, un seul agent avec des outils MCP est plus simple et moins coûteux.

La spec MCP 2026-07-28 finale : ce qui a changé pour cette décision

La spécification MCP est publiée comme finale le 28 juillet 2026. Les quatre SDK Tier 1 (TypeScript, Python, Go, C#) parlent 2026-07-28. La spec a rendu MCP explicitement sans état — les serveurs ne maintiennent pas l'état de session entre les appels. La politique de dépréciation SSE de 12 mois est active : le transport Streamable HTTP remplace SSE, et les déploiements SSE existants ont jusqu'à juillet 2027 pour migrer.

Pour la décision A2A vs MCP, la spec finale confirme la superposition : MCP est un protocole d'outils sans état. Si vous utilisiez les sessions MCP pour maintenir l'état de conversation de l'agent, la spec dit d'arrêter — l'état appartient à l'agent (le client MCP), pas au serveur. Cela rend la couche A2A plus clairement nécessaire : la coordination longue durée avec état entre agents n'est pas quelque chose que MCP est conçu pour porter. La machine à états de tâche A2A comble ce vide.

Une note sur le chevauchement de transport

Les deux protocoles utilisent HTTP et SSE, ce qui peut causer de la confusion quant à savoir s'ils sont en concurrence. Ils ne le sont pas — le chevauchement de transport est superficiel. MCP utilise HTTP pour les appels d'outils (requête → réponse) et migre de SSE vers Streamable HTTP pour les notifications initiées par le serveur. A2A utilise JSON-RPC 2.0 sur HTTP pour la distribution des tâches et SSE pour la sortie de tâche en streaming. Le transport est de la plomberie ; la sémantique du protocole est différente. MCP transporte les appels d'outils. A2A transporte les cycles de vie des tâches. Vous pouvez exécuter les deux sur la même passerelle — l'implémentation de référence fait exactement cela, la passerelle gérant HTTP et SSE pour les deux protocoles tandis que la couche pont traduit vers l'API native de chaque framework.

Ce que cela signifie pour votre architecture

Si vous construisez un système d'agents B2B — automatisation des RFQ, flux d'approvisionnement, support client avec des graphes de connaissances, orchestration de pipelines de données — la décision de protocole suit la forme du flux de travail :

• Un agent, plusieurs sources de données → MCP uniquement. L'agent utilise des modules MCP pour se connecter à NetSuite, HubSpot, BigCommerce et aux catalogues de fournisseurs. A2A n'est pas nécessaire.
• Plusieurs agents, même propriétaire, même infrastructure → MCP pour les outils, coordination au niveau application pour le travail inter-agents. Envisagez A2A si la logique de coordination devient suffisamment complexe pour qu'une machine à états au niveau protocole la simplifie.
• Plusieurs agents, propriétaires différents ou infrastructures différentes → A2A pour la délégation agent-à-agent, MCP pour l'accès aux outils de chaque agent. C'est le modèle de production pour les systèmes d'agents distribués.
• Tâches longue durée avec portes d'approbation humaine → A2A pour le cycle de vie de tâche et l'état INPUT_REQUIRED, MCP pour les appels d'outils au sein de chaque tâche. La porte d'approbation traverse les frontières des agents comme une transition d'état A2A, pas comme du code d'application personnalisé.

La confirmation d'Astra d'OpenAI le 1er août fait du modèle multi-agents longue durée la direction de conception des modèles frontière. Astra est conçu pour des tâches qui travaillent sur des problèmes pendant des heures ou des jours, coordonnant plusieurs agents sur des périodes prolongées. La pile de protocoles qui prend en charge ce modèle est A2A pour la coordination et MCP pour l'accès aux outils — l'architecture à deux protocoles que cet article décrit.

---

Un distributeur de taille moyenne a besoin d'un agent de devis qui parle à un agent de catalogue qui parle à un agent de conformité — chacun soutenu par un modèle différent, chacun possédé par une équipe différente, chacun se connectant à différents systèmes via des modules MCP. A2A donne à ces agents un protocole partagé pour la délégation et le streaming. MCP donne à chaque agent un accès gouverné à ses sources de données. Le modèle de pont permet à Hermes Agent, OpenClaw et tout autre framework de participer au réseau A2A sans réécrire leurs internes.

Demander une construction à portée définie

Une semaine de découverte. Vous obtenez un inventaire des systèmes, une carte des flux de travail et une portée fixe — que vous construisiez avec nous ou non.