MCP + A2A : Les deux protocoles derrière chaque système d'IA agentique en production

Points clés

• MCP compte 10 000+ serveurs publiés, 97M de téléchargements SDK mensuels et 300+ clients — la mise à jour de l'écosystème d'Anthropic (décembre 2025) a confirmé le support multi-vendeurs d'OpenAI, Google, Microsoft et Cursor.
• A2A a dépassé 150 organisations lors de sa première année — annonce de Linux Foundation (avril 2026), avec des déploiements en production sur les plateformes Google, Microsoft et AWS.
• Google a explicitement positionné A2A comme complémentaire à MCP — MCP connecte les agents aux outils ; A2A connecte les agents aux agents. Les deux sont désormais sous la gouvernance de Linux Foundation.
• 23% des organisations ont des pilotes actifs d'agents IA — Capgemini, 2026. La question des protocoles n'est plus théorique ; c'est une décision d'architecture.
• L'enquête Stacklok 2026 montre que 41% des organisations logicielles sont en production limitée ou étendue avec des serveurs MCP — l'empreinte entreprise est réelle, pas spéculative.

Deux protocoles ont été lancés à six mois d'intervalle et ont redéfini la façon dont les agents IA se connectent. Anthropic a publié le Model Context Protocol (MCP) en novembre 2024 comme standard ouvert pour connecter les agents IA aux outils et données. Google a publié le Agent2Agent Protocol (A2A) en avril 2025 comme standard ouvert pour connecter les agents IA entre eux. Les deux sont désormais sous la gouvernance de Linux Foundation. Les deux sont open source. Les deux sont adoptés par des géants concurrents — OpenAI, Google, Microsoft et Anthropic supportent les deux.

L'analogie qui persiste : MCP est l'USB-C de l'IA. A2A est le HTTP des agents. Cet article explique comment ils s'emboîtent dans un système d'IA agentique en production, ce que les chiffres d'adoption disent sur l'état de l'écosystème, et le pattern d'architecture pour les combiner dans un déploiement B2B.

La pile de protocoles à deux couches

Le diagramme montre la pile à deux couches : A2A en haut (coordination entre agents), MCP au milieu (accès agent-outil), et les systèmes externes et agents spécialisés en bas. Un agent reçoit une tâche via A2A, délègue des sous-tâches à d'autres agents via A2A, et utilise MCP pour appeler des outils qui accèdent à NetSuite, HubSpot, BigCommerce, ou l'un des 10 000+ serveurs MCP.

MCP : la couche d'accès aux outils

MCP résout le problème d'intégration M×N. Avant MCP, chaque modèle d'IA avait besoin de code d'intégration sur mesure pour chaque outil qu'il appelait — M modèles × N outils = M×N intégrations. MCP remplace cela par une solution M+N : les fournisseurs d'outils créent N serveurs MCP, les développeurs d'applications IA créent M clients MCP, et n'importe quel client peut appeler n'importe quel serveur via le protocole standardisé.

Les chiffres d'adoption ne sont plus spéculatifs :

Métrique	Valeur	Source
Serveurs MCP publics actifs	10 000+	Mise à jour de l'écosystème Anthropic, décembre 2025
Téléchargements SDK mensuels	97M+ (Python + TypeScript)	Anthropic, décembre 2025
Clients MCP	300+	Plusieurs traceurs d'écosystème
Dépôts GitHub avec le sujet mcp-server	15 926	GitHub Search API, 24 mai 2026
Production entreprise (limitée ou étendue)	41% des organisations logicielles	Enquête Stacklok State of MCP 2026
Enregistres de serveurs au registre officiel	9 652	MCP Registry API, mai 2026

Le release candidate de MCP du 28 juillet 2026 rend la couche de protocole stateless — supprimant le handshake de session, introduisant des handles explicites pour les workflows avec état, et rendant OAuth 2.1 avec PKCE obligatoire. Pour les déploiements B2B, cela signifie pas de sessions sticky, pas de stores de session partagés, et un scaling horizontal stateless derrière des load balancers round-robin simples.

A2A : la couche de coordination des agents

A2A comble le vide que MCP ne couvre pas. MCP connecte un agent aux outils. A2A connecte un agent à un autre agent. Un agent qui a besoin d'une capacité spécialisée — logique de tarification, recherche de catalogue, traitement de RFQ — peut déléguer le travail à un agent distant qui expose cette capacité via un endpoint A2A, recevoir le résultat comme une tâche A2A, et continuer son propre workflow.

L'annonce de Linux Foundation (9 avril 2026) a confirmé :

• 150+ organisations supportant le standard lors de sa première année
• Déploiements en production sur les plateformes Google, Microsoft et AWS
• 50+ partenaires de lancement dont Salesforce, PayPal, Atlassian, Accenture, BCG, Deloitte, McKinsey et PwC
• Intégration profonde dans Google Cloud (Vertex AI, Agent Engine, Agent Development Kit)

A2A définit trois primitives centrales :

• Agent Card — un document JSON à /.well-known/agent-card.json décrivant l'identité, les capacités et l'endpoint de l'agent. C'est ainsi que les agents se découvrent mutuellement.
• Task — l'unité de travail, envoyée via message/send (non-streaming) ou message/stream (streaming). Les tâches transitent par des états : submitted, working, input-required, completed, failed, canceled.
• Artifact — sortie structurée produite pendant l'exécution de la tâche, streamée au client au fur et à mesure de sa disponibilité.

L'architecture complémentaire

Google a explicitement positionné A2A comme complémentaire à MCP : "A2A est un protocole ouvert qui complète le MCP d'Anthropic." Le positionnement est précis — ils opèrent à différentes couches :

Dimension	MCP	A2A
Ce qu'il connecte	Agent aux outils/données	Agent à agent
Direction	Verticale (agent vers le bas aux systèmes)	Horizontale (agent latéralement aux agents)
Découverte	Liste d'outils (tools/list)	Agent Card (/.well-known/agent-card.json)
Unité de travail	Appel d'outil (tools/call)	Task (message/send, message/stream)
Sortie	Résultat d'outil (JSON)	Artifact (streamé, structuré)
Transport	STDIO, Streamable HTTP	JSON-RPC 2.0 sur HTTP/SSE
Auth	OAuth 2.1 + PKCE (obligatoire le 28 juillet)	Authentification Agent Card (définie par le framework)
État	Stateless (28 juillet RC) + handles explicites	Cycle de vie de tâche (submitted à completed)
Soutenu par	Anthropic	Google
Gouvernance	Linux Foundation (Agentic AI Foundation)	Linux Foundation
Adoption	10 000+ serveurs, 97M téléchargements	150+ organisations, 50+ partenaires de lancement

Le pattern d'architecture pour les combiner dans un déploiement B2B :

1. Un agent spécialisé (par exemple, un agent de traitement de RFQ) expose ses capacités via une A2A Agent Card. D'autres agents le découvrent et lui délèguent des tâches.
2. L'agent RFQ utilise MCP pour appeler des outils qui accèdent à NetSuite (recherche de catalogue, création de devis, réservations de disponibilité), HubSpot (recherche de segments clients) et BigCommerce (catalogue de produits). Le pattern de modules MCP fournit des schémas typés, des limites de débit, des logs d'audit et le pattern de handles explicites pour les workflows avec état.
3. L'agent orchestrateur reçoit une tâche de haut niveau via A2A, délègue des sous-tâches à des agents spécialisés via A2A, et chaque agent spécialisé utilise MCP pour interagir avec les systèmes sous-jacents. L'orchestrateur ne touche jamais NetSuite directement — il délègue à l'agent RFQ, qui délègue à ses outils MCP.

C'est le pattern que l'article de bridge A2A existant démontre : comment exposer l'API native d'un framework comme une A2A Agent Card. La pièce manquante dans la plupart des déploiements est la couche MCP en dessous — les modules typés qui rendent les outils sûrs à appeler, auditableables et gouvernés.

Pourquoi les deux protocoles comptent pour le B2B

Un déploiement B2B qui utilise uniquement MCP a des agents qui peuvent appeler des outils mais ne peuvent pas se coordonner entre eux. Chaque workflow est un monolithe à agent unique. Un déploiement qui utilise uniquement A2A a des agents qui peuvent déléguer des tâches mais ne peuvent pas accéder aux systèmes externes sans code d'intégration sur mesure pour chaque outil. Les deux protocoles sont nécessaires.

La recherche Capgemini 2026 a trouvé que 23% des organisations ont des pilotes actifs d'agents IA. Le Anthropic 2026 State of AI Agents Report a trouvé que 46% des organisations identifient l'intégration comme la barrière #1 à l'adoption. Les deux protocoles abordent exactement cette barrière : MCP standardise l'intégration des outils, A2A standardise la coordination des agents. Ensemble, ils réduisent la charge d'intégration de M×N connexions personnalisées à M+N connexions standardisées.

Pour une entreprise B2B de mid-market construisant un système d'agents en production, la question des protocoles n'est pas "lequel ?" — c'est "comment s'emboîtent-ils ?" La réponse est la pile à deux couches : A2A pour la délégation entre agents, MCP pour l'accès agent-outil, et le pattern de modules MCP comme la couche gouvernée qui rend les outils sûrs à appeler.

Lectures connexes

• Integrating A2A with Existing Agent Frameworks: A Hermes Agent Demonstration — le pattern de bridge pour exposer l'API native d'un framework comme une A2A Agent Card, avec Hermes Agent comme exemple
• MCP 2026-07-28: What the Stateless Protocol Means for B2B Agent Deployments — la release du protocole stateless et le pattern de handles explicites pour les workflows avec état dans la couche MCP
• MCP Module Code Standard — le pattern de modules qui rend les outils MCP prêts pour la production avec des schémas typés, des limites de débit et des logs d'audit

---

Un distributeur de mid-market déploie un agent de traitement de RFQ qui reçoit des tâches via A2A d'un agent orchestrateur, utilise des modules MCP pour appeler NetSuite (catalogue, tarification, réservations de disponibilité), HubSpot (segments clients) et BigCommerce (catalogue de produits), et stream le devis complété comme un artifact A2A. L'agent orchestrateur ne touche jamais NetSuite directement — il délègue à l'agent RFQ via A2A, et les modules MCP de l'agent RFQ gèrent les appels d'outils avec des logs d'audit, des limites de débit et le pattern de handles explicites pour le cycle de vie des réservations de disponibilité. Cette réalisation correspond aux Phases 2 à 4 de la méthode en quatre étapes et est généralement en production en 5 à 8 semaines.

Découverte d'une semaine. 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.