A2A vs MCP : Deux protocoles complémentaires pour l'écosystème d'agents émergent

L'adoption croissante des agents IA — des entités logicielles autonomes ou semi-autonomes qui effectuent des raisonnements et des actions pour le compte des utilisateurs — engendre une nouvelle couche dans l'architecture des applications.

Au début de 2025, deux protocoles distincts ont émergé pour répondre à cela — A2A (Agent-to-Agent) et MCP (Model Context Protocol). Une façon simple de comprendre leurs rôles est :

A2A : Comment les agents interagissent entre eux

MCP : Comment les agents interagissent avec les outils ou le contexte externe

référence : https://google.github.io/A2A/#/topics/a2a_and_mcp

Ils répondent au défi central de construire des systèmes avec plusieurs agents, plusieurs LLMs et plusieurs sources de contexte — tous devant collaborer.

Une manière de l'encadrer est : « MCP fournit une intégration verticale (application-au-modèle), tandis qu'A2A fournit une intégration horizontale (agent-à-agent)

Que vous soyez développeur ou non, toute personne construisant des produits IA ou des systèmes agentiques devrait comprendre l'architecture fondamentale — car elle façonne comment nous concevons des produits, des interactions utilisateur, des écosystèmes et la croissance à long terme.

Cet article présente les deux protocoles de manière simple et facile à comprendre et met en évidence les principaux enseignements pour les développeurs et les constructeurs de produits IA.

Qu'est-ce que l'A2A (Agent-to-Agent) ?#

A2A (Agent-to-Agent) est un protocole ouvert développé par Google et plus de 50 partenaires industriels. Son objectif est de permettre l'interopérabilité entre agents — indépendamment de qui les a construits, où ils sont hébergés, ou quel cadre ils utilisent.

Mécanisme du protocole A2A#

A2A utilise JSON-RPC 2.0 sur HTTP(S) comme mécanisme de communication, avec prise en charge des Server-Sent Events (SSE) pour diffuser des mises à jour.

Modèles de communication A2A#

A2A définit un modèle structuré pour comment deux agents interagissent. Un agent prend le rôle d'agent “client”, qui initie une demande ou tâche, et un autre agit en tant qu'agent “distant”, qui reçoit la demande et tente de la réaliser. L'agent client peut d'abord effectuer une découverte de capacité pour déterminer quel agent est le mieux adapté pour une tâche donnée.

Là se pose la question, comment les agents se découvrent-ils. Chaque agent peut publier une Carte d'Agent (un document de métadonnées JSON, souvent hébergé à une URL standard comme /.well-known/agent.json) décrivant ses capacités, compétences, points d’accès API et exigences d’authentification.

En lisant une Carte d'Agent, un agent client peut identifier un agent partenaire approprié pour la tâche en cours – essentiellement un répertoire de ce que cet agent sait ou peut faire. Une fois qu'un agent cible est choisi, l'agent client formule un objet Tâche à envoyer.

référence : https://google.github.io/A2A/#/

Gestion des tâches#

Toute interaction dans A2A est orientée autour de l'exécution de tâches. Une tâche est un objet structuré (défini par le schéma du protocole) qui inclut les détails de la demande et suit son état.

Dans A2A, chaque agent joue l'un des deux rôles :

• Agent Client : initie une tâche
• Agent Distant : reçoit et traite la tâche

Les tâches peuvent inclure toute forme de travail : générer un rapport, récupérer des données, initier un flux de travail. Les résultats sont retournés sous forme d'artefacts, et les agents peuvent envoyer des messages structurés durant l'exécution pour se coordonner ou clarifier.

Collaboration et négociation de contenu#

A2A prend en charge plus que des simples demandes de tâches — les agents peuvent échanger des messages riches et multipartites qui incluent du texte, JSON, images, vidéo ou contenu interactif. Cela permet une négociation de format basée sur ce que chaque agent peut gérer ou afficher.

Par exemple, un agent distant pourrait retourner un graphique soit sous forme de données brutes soit d'image, ou demander d'ouvrir un formulaire interactif. Cette conception prend en charge une communication flexible, indépendante de la modalité, sans exiger que les agents partagent des outils internes ou de la mémoire.

Exemple d'utilisation#

Voici un exemple réel de comment l'A2A pourrait être utilisé dans un scénario d'entreprise :

Un nouvel employé est embauché dans une grande entreprise. Plusieurs systèmes et départements sont impliqués dans l'intégration :

• Les RH doivent créer un dossier et envoyer un email de bienvenue
• Le service informatique doit mettre à disposition un ordinateur portable et des comptes d'entreprise
• Les services généraux doivent préparer un bureau et un badge d'accès

Traditionnellement, ces étapes sont traitées manuellement ou via des intégrations étroitement liées entre systèmes internes.

Au lieu d'API personnalisées entre chaque système, chaque département expose son propre agent utilisant le protocole A2A :

Un système multi-agent — appelons-le OnboardingPro (par exemple onboarding-agent.company.com) — coordonne l'ensemble du flux de travail d'intégration.

1. Découverte : Il lit chaque .well-known/agent.json des agents pour comprendre les capacités et l'authentification.
2. Délégation de tâches :
   • Envoie une tâche createEmployee à l'agent RH.
   • Envoie les tâches setupEmailAccount et orderHardware à l'agent informatique.
   • Envoie assignDesk et generateBadge à l'agent des services généraux.
3. Diffusion des mises à jour : Les agents diffusent les progrès en utilisant les événements envoyés par le serveur (par exemple, « ordinateur portable expédié », « bureau attribué »).
4. Collecte des artefacts : Les résultats finaux (par exemple, badge PDF, emails de confirmation, identifiants de compte) sont retournés sous forme d'artefacts A2A.
5. Achèvement : OnboardingPro informe le responsable du recrutement lorsque l'intégration est terminée.

Qu'est-ce que MCP (Model Context Protocol) ?#

MCP (Model Context Protocol), développé par Anthropic, aborde un problème différent : comment les applications externes peuvent fournir un contexte et des outils structurés à un agent basé sur un modèle linguistique en temps réel.

Plutôt que de permettre la communication entre agents, MCP se concentre sur la fenêtre de contexte — la mémoire de travail d'un LLM. Son objectif est :

• Injecter dynamiquement des outils, documents, fonctions API ou état utilisateur pertinents dans la session d'inférence d'un modèle
• Permettre aux modèles d'appeler des fonctions ou de récupérer des documents sans codage en dur de l'indice ou de la logique

Architecture clé de MCP#

Pour comprendre MCP, il faut d'abord comprendre l'architecture globale — comment toutes les pièces fonctionnent ensemble.

Hôte MCP : « L'IA avec laquelle vous discutez »#

Pensez à l'Hôte MCP comme à l'application IA elle-même — comme Claude Desktop ou votre assistant de codage.

C'est l'interface que vous utilisez — l'endroit où vous tapez ou parlez.

Il veut intégrer des outils et des données qui aident le modèle à fournir de meilleures réponses.

Client MCP : « Le connecteur »#

Le Client MCP est la pièce logicielle qui connecte votre hôte IA (comme Claude) au monde extérieur. C'est comme un standard téléphonique — il gère des connexions sécurisées, individuelles avec différents serveurs MCP. Lorsque l'IA veut accéder à quelque chose, elle passe par le client.

Il est utile de penser à des outils comme ChatGPT, Claude chat, ou Cursor IDE comme des hôtes MCP — ils fournissent l'interface avec laquelle vous interagissez. En coulisses, ils utilisent un client MCP pour se connecter à différents outils et sources de données via des serveurs MCP.

référence : https://modelcontextprotocol.io/introduction

Serveur MCP : « Le fournisseur d'outils »#

Un Serveur MCP est un petit programme ciblé qui expose un outil ou une capacité spécifique — comme :

• Rechercher des fichiers sur votre ordinateur
• Consulter des données dans une base de données locale
• Appeler une API externe (comme météo, finance, calendrier)

Chaque serveur suit le protocole MCP, afin que l'IA puisse comprendre ce qu'il peut faire et comment l'appeler.

Sources de données locales : « Vos propres fichiers et services »#

Certains serveurs MCP se connectent à des éléments sur votre propre machine — comme :

• Documents et dossiers
• Projets de code
• Bases de données ou applications locales

Cela permet à l'IA de rechercher, récupérer ou calculer des éléments sans télécharger vos données dans le cloud.

Services à distance : « API et outils en ligne »#

D'autres serveurs MCP sont connectés à Internet — ils dialoguent avec :

• API (par ex. Stripe, Notion, GitHub)
• Outils SaaS
• Bases de données d'entreprise dans le cloud

Ainsi, l'IA peut dire, par exemple : « Appelle le serveur GitHub et récupère la liste des PR ouvertes. »

MCP prend désormais en charge la connexion à des serveurs MCP distants. Cela signifie qu'un client MCP peut acquérir des capacités plus puissantes. En théorie,

Avec le bon ensemble de serveurs MCP, les utilisateurs peuvent transformer chaque client MCP en une « application tout-en-un.

référence : https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Assembler le tout#

Voyons maintenant avec un diagramme comment tout fonctionne ensemble.

1. Vous demandez quelque chose de complexe à l'IA
2. L'IA (l'hôte) demande de l'aide au client
3. Le client appelle le serveur MCP approprié — peut-être un qui vérifie des fichiers ou accède à une API
4. Le serveur renvoie des données ou exécute une fonction
5. Le résultat retourne au modèle pour l'aider à accomplir la tâche

A2A vs MCP — Comparaison#

Comment ils fonctionnent ensemble#

Plutôt que d'être des alternatives, A2A et MCP sont complémentaires. Dans de nombreux systèmes, ils seront utilisés ensemble.

Exemple de flux de travail#

1. Un utilisateur soumet une demande complexe dans une interface d'agent d'entreprise.
2. L'agent orchestrateur utilise A2A pour déléguer des sous-tâches à des agents spécialisés (par exemple, analytique, RH, finances).
3. L'un de ces agents utilise MCP en interne pour invoquer une fonction de recherche, récupérer un document, ou calculer quelque chose en utilisant un modèle.
4. Le résultat est renvoyé sous forme d'artefact via A2A, permettant une collaboration entre agents de bout en bout avec accès modulaire aux outils.

Cette architecture sépare la communication inter-agents (A2A) de l'invocation de capacités intra-agent (MCP) — facilitant la composition, l'évolutivité et la sécurité du système.

Conclusion#

A2A concerne les agents qui communiquent avec d'autres agents via un réseau — de manière sécurisée, asynchrone et centrée sur la tâche.

MCP consiste à injecter des capacités structurées dans une session de modèle, laissant les LLMs raisonner sur les outils et les données contextuellement.

Utilisés ensemble, ils prennent en charge des systèmes multi-agents composables à la fois extensibles et interopérables.

Comment l'infrastructure de base MCP + A2A pourrait façonner l'avenir des marchés de produits d’agents#

Enfin, je souhaite évoquer comment cette fondation technique de base pourrait façonner l'avenir du marché de l'IA — et ce que cela signifie pour les personnes construisant des produits IA.

Le changement d'interaction humain-ordinateur#

Un exemple clair de ce changement peut être vu dans les flux de travail des développeurs et des services. Avec les serveurs MCP désormais intégrés dans les IDE et les agents de codage, la manière dont les développeurs interagissent avec les outils change fondamentalement.

Auparavant, un flux de travail typique impliquait de rechercher le bon service, de configurer l'hébergement, de lire la documentation, d'intégrer les API manuellement, d'écrire du code dans l'IDE et de configurer des fonctionnalités via un tableau de bord low-code. C'était une expérience fragmentée, nécessitant des changements de contexte et des lourdeurs techniques à chaque étape.

Désormais, avec les agents de codage connectés au MCP, beaucoup de cette complexité peut être abstraite. Les développeurs peuvent découvrir et utiliser des outils plus naturellement à travers des invites conversationnelles. L'intégration API devient partie intégrante du flux de codage lui-même — souvent sans nécessiter d'interface utilisateur séparée ou de configuration manuelle. (Pensez seulement à la complexité des tableaux de bord AWS ou Microsoft.). L'interaction devient plus fluide — plus axée sur la direction du comportement que sur l'assemblage des fonctionnalités.

Dans ce modèle, l'interaction utilisateur ou développeur passe de la configuration des fonctionnalités à l'orchestration des comportements. Cela change aussi le rôle de la conception de produit.

Au lieu d'utiliser des interfaces pour « pallier » des défis techniques (par ex. « c'est trop difficile à coder, faisons un panneau de configuration »), nous devons maintenant :

• Penser à l'expérience de bout en bout
• Concevoir comment et quand les interactions IA + utilisateur devraient se réunir
• Laisser l'IA gérer la logique, et guider les utilisateurs à travers l'intention et le flux

Le défi devient de décider quand et comment l'IA et l'entrée utilisateur devraient se réunir, laisser l'IA gérer la logique, et guider les utilisateurs à travers l'intention et le flux et comment insérer les bonnes interactions au bon moment.

J'ai utilisé un service de développeur et un produit API comme exemple pour montrer comment l'interaction utilisateur pourrait changer — mais la même chose s'applique aux logiciels d'entreprise. Pendant longtemps, les outils d'entreprise ont été complexes et difficiles à utiliser. L'interaction en langage naturel a le potentiel de simplifier beaucoup de ces flux de travail.

Les paradigmes de produits agentiques et leur impact sur le SaaS#

Nous commençons à voir un nombre croissant de serveurs MCP émerger. Imaginez Airbnb offrant un serveur MCP de réservation, ou Google Maps exposant un serveur MCP de carte. Un agent (comme client MCP) pourrait se connecter à plusieurs de ces serveurs à la fois — débloquant des flux de travail qui nécessitaient auparavant des intégrations personnalisées ou des applications étroitement liées.

Comparé à l'ère du SaaS, où les intégrations étaient souvent manuelles et rigides, ce modèle permet des flux de travail plus autonomes et des connexions fluides entre services. Voici deux exemples :

1. Conception à partir de documents

   Vous écrivez un PRD dans Notion. Un agent Figma lit le document et crée automatiquement une maquette qui dispose les concepts de base — sans transfert manuel nécessaire.

2. Recherche de concurrents, de bout en bout

   Vous demandez une analyse concurrentielle. Un groupe d'agents recherche sur le web, s'inscrit à des services pertinents en votre nom (avec authentification sécurisée), collecte les résultats et livre les artefacts — déjà organisés dans votre espace de travail Notion.

Défis liés aux frontières d'authentification et d'autorisation#

Avec l'essor des connexions agent à agent, des connexions client MCP à serveur MCP, il y a un grand nombre de besoins sous-jacents concernant l'authentification et l'autorisation, car l'agent agira au nom de l'humain et les utilisateurs et les identifiants doivent être sécurisés tout au long de ce parcours.

Jusqu'à présent, il existe plusieurs scénarios spécifiques à la nouvelle montée de l'agent à agent et MCP.

1. Agent vs SaaS & ApplicationWeb
2. Client MCP (Agent) vs Serveur MCP
3. Utilisateur vs Agent
4. Agent vs Agent

Un autre cas d'utilisation intéressant est la fédération multi-identités mentionnée par Google :

Par exemple, l'utilisateur U travaille avec l'agent A nécessitant l'identifiant du système A. Si l'agent A dépend également de l'outil B ou de l'agent B qui nécessite l'identifiant du système B, l'utilisateur peut avoir besoin de fournir des identités pour les deux systèmes A et B en une seule demande. (Supposons que le système A soit une identité LDAP d'entreprise et le système B soit une identité de fournisseur SaaS).

Logto est un fournisseur OIDC et OAuth, bien adapté pour l'avenir des intégrations IA.

Avec son infrastructure flexible, nous élargissons activement ses capacités et avons publié une série de tutoriels pour aider les développeurs à démarrer rapidement.

Des questions ?

N'hésitez pas à nous contacter — ou plongez et explorez ce que vous pouvez construire avec Logto aujourd'hui.