A2A et MCP : les deux protocoles clés pour vos agents IA
MCP structure l’accès d’un agent à ses outils et données. A2A définit comment plusieurs agents se coordonnent entre eux. Ces deux protocoles ouverts répondent à deux problèmes distincts et complémentaires : MCP seul suffit pour un agent simple, mais dès que votre architecture devient multi-agents, A2A devient indispensable. Cet article décrypte les mécanismes de chaque protocole, explique pourquoi ils se complètent, et donne les ressources pour les intégrer à vos projets.
Source :
A2A vs MCP: AI Agent Communication Explained
· IBM Technology · Publié le 2 mars 2026
· 11min
MCP est devenu la colonne vertébrale du développement d’agents IA. Lancé par Anthropic en novembre 2024, il résout le problème M×N qui paralysait l’écosystème : plutôt que de multiplier les intégrations spécifiques entre chaque LLM et chaque outil, MCP fournit une couche standardisée. Vous écrivez un serveur MCP une fois pour un CRM, une base de données ou un dépôt Git, et n’importe quel client compatible peut l’utiliser sans réécriture. L’adoption a été rapide — des milliers de serveurs MCP open source disponibles en quelques mois, une intégration native dans les principaux IDEs et frameworks. C’est ce standard qui a rendu les agents pratiquement utilisables à grande échelle.
Mais MCP ne couvre qu’une moitié du problème agentique. Dès qu’on passe à plusieurs agents spécialisés qui doivent se coordonner, déléguer des tâches et s’échanger des résultats, MCP seul ne suffit plus. C’est exactement ce que résout A2A (Agent-to-Agent), le protocole lancé par Google en avril 2025. En 2026, MCP et A2A forment ensemble le socle de référence pour tout développement agentique sérieux. Les comprendre tous les deux, c’est comprendre l’architecture de l’IA distribuée qui se construit en ce moment. Ce ne sont pas des options pour les équipes qui construisent des systèmes agentiques réels : ce sont les fondations.
Pourquoi les agents IA ont-ils besoin de protocoles standardisés ?
Un agent IA, pris isolément, sait raisonner et générer des réponses. Ce qu’il ne sait pas faire nativement, c’est parler à votre base de données, interagir avec votre dépôt Git, ou déléguer une tâche à un autre agent qui tourne dans un framework différent. Sans standardisation, chaque connexion devient une intégration sur mesure. Avec cinq agents et dix outils, vous gérez potentiellement cinquante connecteurs différents à écrire et maintenir à chaque montée de version.
Le problème était particulièrement aigu dans les architectures multi-agents. Un agent construit avec Salesforce qui devait déléguer à un agent ServiceNow nécessitait un pont écrit manuellement. Un agent Vertex AI ne pouvait pas se coordonner avec un agent AWS Bedrock sans une couche d’adaptation sur mesure. Comme le montrait notre revue de presse sur l’IA agentique de mai 2026, ce problème de fragmentation était identifié comme le principal frein au passage à l’échelle des systèmes multi-agents. MCP a résolu une première couche pour les ressources. A2A est venu compléter la solution pour la coordination inter-agents.
A2A : comment les agents se découvrent et se coordonnent-ils ?
A2A résout la coordination horizontale entre agents. Son mécanisme central est l’agent card : un manifeste JSON standardisé que chaque agent publie pour décrire ses capacités, ses entrées attendues et ses sorties. D’autres agents découvrent ces cards dynamiquement, identifient les compétences disponibles et délèguent des tâches sans configuration préalable. C’est, pour reprendre la formule de Martin Keen dans la vidéo IBM Technology, “un CV pour les agents” : chaque agent affiche ce qu’il sait faire, et les autres décident de la division du travail en temps réel.
Le transport repose sur HTTP classique avec JSON-RPC 2.0 pour les payloads. N’importe quelle infrastructure web standard peut donc héberger un agent A2A, avec tous les bénéfices associés : routing, load balancing, authentification, logging. Pas de serveur propriétaire supplémentaire. Pour les workflows longs, A2A supporte les Server-Sent Events (SSE) : un agent peut pousser des mises à jour progressives à un autre en quasi-temps réel pendant qu’il traite sa tâche, sans que l’agent coordinateur ait à attendre le résultat final pour avancer.
Les échanges A2A sont également modality agnostic. Deux agents traitant des types de données différents — texte, images, fichiers structurés, objets JSON — peuvent se coordonner sans conversion manuelle. Un agent génère un design, un autre le révise, un troisième gère la validation client : tout dans un même flux, réparti entre agents spécialisés qui ne partagent pas nécessairement le même framework ni le même fournisseur.
MCP : comment un agent accède-t-il à ses outils et ses données ?
Là où A2A gère la coordination entre agents, MCP gère la connexion verticale d’un agent avec ses ressources. L’architecture distingue deux composants : le MCP host (l’application dans laquelle l’agent tourne) et le MCP server (le service qui sait interagir avec une ressource spécifique). L’agent appelle les primitives que le serveur MCP expose — il n’a pas besoin de connaître les détails d’implémentation d’une base de données ou d’une API tierce.
Ces primitives sont au nombre de trois. Les tools sont des fonctions invocables : chercher dans une base de données, committer du code, envoyer un message Slack. Les resources sont des données accessibles en lecture : fichiers, enregistrements, état d’application. Les prompts sont des templates pré-construits pour des interactions récurrentes. L’avantage clé : vous écrivez un serveur MCP une fois pour un CRM, et tout client compatible peut l’utiliser. On ne réécrit pas l’intégration quand on change de modèle ou d’application hôte.
Le transport varie selon l’emplacement du serveur : stdin/stdout pour les serveurs locaux (un plugin IDE accédant au système de fichiers, par exemple), HTTP avec streaming pour les serveurs distants. L’écosystème compte aujourd’hui des milliers de serveurs MCP open source pour GitHub, Slack, des bases de données relationnelles, des systèmes de fichiers — prêts à l’emploi sans réécrire le connecteur.
A2A et MCP sont-ils concurrents ou complémentaires ?
La confusion vient du fait que les deux protocoles semblent répondre à des questions proches. En réalité, ils opèrent sur des couches différentes et se combinent naturellement. Pour reprendre la formule synthétique de la vidéo IBM Technology : “A2A for agents talking to agents, MCP for agents talking to tools and data.” MCP est vertical (agent vers ressource), A2A est horizontal (agent vers agent).
Un exemple concret clarifie leur complémentarité. Dans un système de gestion de stock pour un retailer : un agent inventaire utilise MCP pour lire et écrire dans une base de données produits. Quand il détecte un niveau de stock bas, il utilise A2A pour notifier un agent de commande interne. Cet agent « commande » utilise A2A à son tour pour contacter des agents fournisseurs externes — construits par des entreprises tierces, avec des frameworks différents. Chacun de ces agents externes utilise MCP pour accéder à ses propres outils. Les deux protocoles s’articulent sans friction, chacun dans son périmètre propre.
Comment démarrer avec A2A et MCP dans vos projets ?
Pour MCP, le point d’entrée est la documentation officielle sur modelcontextprotocol.io, avec des SDKs en Python et TypeScript. Si vous travaillez déjà avec Claude Code ou un IDE intégrant MCP, des serveurs peuvent être configurés directement dans votre environnement. L’annonce de la spec MCP 2026-07-28 lors de Google I/O 2026 a d’ailleurs introduit des évolutions importantes sur la gestion des états et le streaming, qui simplifient encore le développement de serveurs.
Pour A2A, le dépôt officiel est github.com/a2aproject/A2A. Cinq SDKs officiels couvrent les langages principaux : Python, TypeScript/JavaScript, Java, .NET et Go. Depuis juin 2025, le projet est sous la gouvernance de la Linux Foundation, licence Apache 2.0 — ce qui garantit une évolution ouverte, indépendante des intérêts d’un seul éditeur. Côté frameworks, Google ADK offre un support natif d’A2A, CrewAI l’a intégré dans ses versions récentes, LangGraph interopère via des adapters, et AutoGen/AG2 ainsi que l’OpenAI Agents SDK progressent vers une compatibilité A2A. La plupart supportent aussi MCP, ce qui facilite l’adoption des deux protocoles dans un même projet. La stratégie pragmatique : démarrer par MCP pour connecter vos agents à vos ressources, puis introduire A2A quand votre architecture passe en mode multi-agents.
“A2A for agents talking to agents, MCP for agents talking to tools and data.” — Martin Keen, IBM Technology
“It turns out we weren’t competing. We were complimenting.” — Anna Gutowska et Martin Keen, IBM Technology
Questions fréquentes
Qui a développé A2A ?
A2A (Agent-to-Agent) est un protocole open source initié par Google, annoncé le 9 avril 2025 lors de Google Cloud Next. Au lancement, 50 partenaires fondateurs avaient déjà rejoint le projet, parmi lesquels LangChain, PayPal, Salesforce, SAP et Atlassian. En juin 2025, Google a contribué le projet à la Linux Foundation, où il est maintenu sous licence Apache 2.0 par l’organisation a2aproject. Ce transfert de gouvernance garantit une évolution ouverte et indépendante des intérêts d’un seul éditeur — un signal fort sur la volonté de faire d’A2A un standard partagé, comparable à ce que l’AAIF a fait pour MCP en décembre 2025.
Quels SDK et frameworks supportent A2A ?
Cinq SDK officiels sont disponibles dans le dépôt a2aproject sur GitHub : Python, TypeScript/JavaScript, Java, .NET et Go. Côté frameworks, Google ADK (Agent Development Kit) offre un support natif d’A2A et constitue le point d’entrée recommandé dans l’écosystème Google Cloud. CrewAI a ajouté le support A2A dans ses versions récentes. LangGraph peut interopérer via des adapters A2A. AutoGen/AG2 et l’OpenAI Agents SDK progressent également vers une compatibilité A2A. La plupart de ces frameworks supportent aussi MCP, ce qui rend l’adoption des deux protocoles dans un même projet tout à fait réaliste.
Dois-je utiliser A2A et MCP ensemble, ou seulement l’un des deux ?
Cela dépend de votre architecture. Un agent unique qui accède à des outils et données n’a besoin que de MCP. Dès que vous introduisez plusieurs agents qui se coordonnent — surtout s’ils sont construits avec des frameworks différents ou par des équipes différentes — A2A devient pertinent. Les architectures agentiques réelles finissent presque toujours par utiliser les deux : MCP pour la couche outils et données, A2A pour la couche coordination inter-agents. Il n’y a pas de conflit entre eux : ils opèrent sur des couches distinctes conçues pour fonctionner ensemble.
A2A remplace-t-il les API REST entre services ?
Non. A2A s’appuie sur HTTP et JSON-RPC 2.0, donc votre infrastructure REST existante reste valide. Ce qu’A2A ajoute par-dessus est spécifique aux architectures agentiques : la découverte des agents via l’agent card, le format standardisé des échanges de tâches, la gestion du streaming via SSE. REST seul ne résout pas la découverte dynamique de capacités ni la coordination structurée de tâches entre agents autonomes — c’est le vide qu’A2A vient combler.
MCP et A2A convergent vers le même objectif : rendre les architectures agentiques composables, interopérables et maintenables à l’échelle. L’un structure la relation entre un agent et ses ressources, l’autre structure la relation entre agents. Les principaux frameworks les adoptent, la Linux Foundation les gouverne. Que vous partiez d’un agent simple en anticipant une montée en complexité, ou que vous construisiez d’emblée un système multi-agents, comprendre ces deux protocoles vous place du bon côté de la courbe d’adoption — celle qui va définir l’infrastructure de l’IA agentique pour les années à venir.
