MCP et A2A : la boîte à outils et le carnet d’adresses de votre agent IA

Un artisan arrive sur un chantier avec deux choses. Une caisse à outils, qu’il ouvre lui-même : la scie coupe quand il l’actionne, elle ne discute pas. Et un carnet d’adresses, où figurent un électricien et un carreleur. L’un s’utilise. L’autre se rappelle, se négocie, et rend un travail trois jours plus tard.

Un agent IA a exactement les deux mêmes besoins. Et depuis 2025, il existe un protocole pour chacun. Le premier s’appelle MCP, le second A2A. Cet article explique la différence, et pourquoi elle compte même si vous ne codez pas.

La définition, à trois niveaux

Niveau 1 — Tout public

Un logiciel intelligent a besoin de deux sortes de branchements : un pour se servir d’outils, un pour parler à d’autres logiciels intelligents. MCP est le premier branchement. A2A est le second.

Niveau 2 — Manager, décideur

MCP standardise la connexion entre un agent et les outils ou données de votre système d’information. A2A standardise la délégation d’une tâche d’un agent vers un autre agent, y compris hors de votre organisation. Deux couches, une même finalité : ne plus recâbler chaque intégration à la main.

Niveau 3 — Définition académique

MCP et A2A sont deux protocoles d’interopérabilité agentique. MCP suit un modèle client-serveur pour l’invocation typée d’outils. A2A définit un échange entre pairs, sur HTTP, où un agent client délègue une tâche à un agent distant découvert au moyen d’une carte de capacités déclarative.

L’analogie de la boîte à outils et du carnet d’adresses

Reprenons notre artisan. Appelons-le chef de chantier, puisque c’est ainsi que nous avons déjà décrit un agent IA : quelqu’un qui reçoit un objectif, le décompose, et le mène à terme.

Sa caisse à outils. Elle contient une scie, une perceuse, un mètre. Chaque outil a un mode d’emploi simple : on l’actionne, il produit un résultat, l’affaire est réglée en quelques secondes. L’outil n’a pas d’agenda. Il ne demande pas de précisions. Il ne rappelle jamais le lendemain pour dire qu’il a fini. Vous ne négociez pas avec une perceuse.

C’est le rôle de MCP. Un agent branché en MCP peut interroger votre base clients, envoyer un message, lire un fichier. À chaque fois, le schéma est le même : appel, réponse, terminé. C’est une relation verticale, entre quelqu’un qui commande et quelque chose qui exécute.

Son carnet d’adresses. Rien à voir. L’électricien du carnet n’est pas un outil, c’est un pair. Notre chef de chantier ne l’actionne pas, il le mandate. Il lui confie une mission — « refais le tableau électrique du deuxième » — pas une instruction. L’électricien, lui, garde sa méthode, son planning et son jugement. Il peut rappeler pour demander une précision. Il peut annoncer trois jours de délai. Il peut refuser. Et à la fin, il rend un livrable, pas une valeur de retour.

C’est le rôle d’A2A. La formule sur laquelle le milieu s’est accordé tient en une phrase : MCP relie les agents aux outils, A2A relie les agents à leurs pairs. Un outil s’invoque et répond. Un pair se délègue et négocie.

Comment on entre dans le carnet. Un artisan sérieux a une plaquette : ce qu’il sait faire, ses certifications, ses horaires, comment le joindre. Dans A2A, chaque agent publie l’équivalent, appelé Agent Card — une fiche lisible par une machine, qui décrit ses capacités, les types de tâches acceptés, les formats attendus et les conditions d’authentification. Un agent qui cherche un partenaire lit cette fiche avant de déléguer quoi que ce soit. C’est le mécanisme de découverte, et c’est aussi le point sensible, nous y reviendrons.

Et la mission a une vie. Une commande passée à un artisan n’est pas un événement instantané : elle est acceptée, elle démarre, elle progresse, elle produit parfois un point d’étape, elle s’achève ou elle échoue. A2A modélise exactement cela. Une tâche déléguée possède un cycle de vie et un identifiant, elle peut durer des heures, et l’agent distant peut envoyer des nouvelles en cours de route. Un outil MCP, lui, n’a pas d’états d’âme : il répond ou il ne répond pas.

Les limites de cette image

Un électricien humain engage sa responsabilité, défend sa réputation et refuse un chantier absurde. Un agent pair ne fait rien de tout cela : sa « plaquette » est un fichier déclaratif que personne ne vérifie par défaut, et il n’a aucune réticence à accepter une mission mal formulée.

Autre écart : entre artisans, la confiance repose sur des années de travail commun. Entre agents, elle repose sur des jetons d’authentification et des schémas de données. C’est vérifiable, mais ce n’est pas de la confiance au sens humain — et il ne faut pas confondre les deux.

Les cinq pièces, traduites

Composant technique	Dans notre analogie	En réalité
Serveur MCP	La caisse à outils	Une prise standard qui expose une base, une API ou un fichier à l’agent. Appel, réponse, fin.
Agent pair (A2A)	L’électricien du carnet	Un autre agent, souvent d’un autre éditeur, à qui l’on confie un objectif sans lui dicter sa méthode.
Agent Card	La plaquette du prestataire	Une fiche lisible par machine : capacités, types de tâches, formats acceptés, mode d’authentification.
Découverte	Trouver le bon artisan	L’agent client lit les fiches disponibles et choisit le pair qui correspond au besoin du moment.
Tâche déléguée	Le bon de commande et ses jalons	Un objet suivi dans le temps : accepté, en cours, points d’étape, terminé ou échoué.

Ce que ça change pour vous

1. Vous avez une question à poser à vos prestataires. « Votre agent expose-t-il une Agent Card, et parle-t-il MCP ? » Cette seule question vous dit si vous achetez une brique interopérable ou une impasse. Un agent qui ne parle aucun protocole standard devra être recâblé à la main pour chaque outil et chaque partenaire.

2. Le risque d’enfermement chez un fournisseur a diminué. A2A a été introduit par Google en avril 2025, puis confié quelques mois plus tard à la Linux Foundation. MCP, né chez Anthropic, a suivi le même chemin. Les deux protocoles, ainsi qu’ACP, relèvent aujourd’hui d’une gouvernance commune qui réunit des acteurs concurrents. Ce n’est pas une garantie, mais c’est une différence réelle avec un format propriétaire.

3. Votre pilotage change de nature. Superviser un outil, c’est vérifier un résultat. Superviser une délégation, c’est autre chose : il faut savoir à qui la tâche a été confiée, avec quelles données, et sur quel critère elle a été jugée terminée. Les questions de traçabilité que vous posiez à un sous-traitant humain deviennent des questions de conception logicielle.

4. Et la surface d’attaque s’élargit. Un outil que vous avez installé, vous l’avez choisi. Un pair découvert par sa fiche déclarative, beaucoup moins. La description d’un partenaire est du texte que votre agent va lire et prendre au sérieux : elle doit être traitée comme une entrée à vérifier, versionnée et réapprouvée à chaque changement. C’est le sujet d’un prochain billet de cette rubrique.

Questions que posent les étudiants

Mais A2A, ce n’est pas juste une API de plus ?▼

Une API classique décrit des fonctions précises à appeler dans un ordre précis. A2A décrit une mission confiée à une entité qui décidera elle-même de sa méthode. La différence est la même qu’entre commander une pièce sur catalogue et confier un chantier. Techniquement, oui, ça circule en HTTP. Conceptuellement, non, ce n’est pas le même geste.

Si MCP fait déjà le travail, pourquoi un second protocole ?▼

Parce qu’on ne demande pas la même chose à une perceuse et à un électricien. MCP suppose une réponse rapide et un appelant qui sait ce qu’il veut. A2A prévoit l’attente, les allers-retours, les tâches longues et un partenaire qui garde sa propre logique. Faire entrer le second cas dans le premier oblige à bricoler.

Les agents vont donc discuter entre eux sans nous ?▼

Ils échangent des messages structurés, pas une conversation autonome sur leurs projets. Chaque délégation part d’un objectif fixé en amont par un humain, et le périmètre de ce qu’un agent a le droit de confier reste un paramètre de configuration. La question utile n’est pas « parlent-ils entre eux » mais « qui a défini leurs droits, et qui peut les relire ».

C’est un protocole de Google, donc c’est fermé ?▼

Google l’a introduit, puis l’a confié à la Linux Foundation quelques mois plus tard. La spécification est publique et sa gouvernance est partagée entre plusieurs entreprises concurrentes. La bonne question n’est plus « qui l’a écrit » mais « qui l’a adopté » — et l’adoption est large.

Dois-je apprendre ça si je ne code pas ?▼

Vous n’avez pas à savoir l’implémenter. Vous avez intérêt à savoir que la distinction existe, parce qu’elle détermine ce que vous achetez, ce que vous pouvez remplacer et ce que vous devez surveiller. C’est une notion d’architecture, au même titre que la différence entre un salarié et un sous-traitant.

Deux textes fondateurs

1. L’ancêtre oublié (1994)

Au début des années 1990, un programme de recherche américain cherche à faire coopérer des logiciels conçus séparément. L’équipe de Tim Finin propose KQML, un langage de communication entre agents.

L’idée centrale est restée : un message entre deux programmes doit dire explicitement ce qu’il veut obtenir, et pas seulement transmettre des données. Demander, informer, réclamer une action sont des intentions différentes, et le message doit les distinguer.

Ce papier montre que le problème posé par A2A a trente ans. Ce qui a changé, ce n’est pas la question, c’est que les agents sont enfin assez capables pour que la réponse serve.

✅ Finin, T., Fritzson, R., McKay, D., & McEntire, R. (1994). KQML as an agent communication language. Proceedings of the Third International Conference on Information and Knowledge Management (CIKM ’94), 456–463. https://doi.org/10.1145/191246.191322

2. La carte du terrain actuel (2025)

Publié en mai 2025, quelques semaines après l’annonce d’A2A, ce panorama compare les quatre protocoles alors en concurrence : MCP, ACP, A2A et ANP.

Son apport principal est de montrer qu’ils ne se disputent pas la même place. Les auteurs proposent une adoption par étapes : MCP d’abord pour l’accès aux outils, A2A ensuite pour l’exécution de tâches en collaboration.

C’est le texte qui a installé la lecture en couches, aujourd’hui devenue la manière standard de présenter le sujet.

✅ Ehtesham, A., Singh, A., Gupta, G. K., & Kumar, S. (2025). A survey of agent interoperability protocols: Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol (A2A), and Agent Network Protocol (ANP). arXiv. https://doi.org/10.48550/arXiv.2505.02279

Trois prompts pour explorer

Explique-moi la différence entre MCP et A2A avec une analogie tirée du monde du bâtiment, puis dis-moi où cette analogie devient fausse.

🎯 Objectif : explorer | 📚 Ce qu’on apprend : à distinguer les deux couches, et à repérer qu’une analogie a toujours un point de rupture.

Je vais te donner cinq situations. Dis-moi à chaque fois si c’est un appel d’outil ou une délégation à un pair, et pourquoi. Corrige-moi si je me trompe ensuite.

🎯 Objectif : tester sa compréhension | 📚 Ce qu’on apprend : à appliquer le critère « ça répond » contre « ça négocie ».

Rédige la fiche de capacités (Agent Card) d’un agent qui traiterait les réclamations clients d’une enseigne de retail. Puis liste ce qu’un acheteur devrait vérifier avant de lui confier une tâche.

🎯 Objectif : cas pratique management | 📚 Ce qu’on apprend : qu’une fiche déclarative n’est pas une garantie, et quoi vérifier avant de déléguer.

Note méthodologique. Cet article a été rédigé avec l’assistance d’un modèle de langage, sur la base d’un gabarit éditorial défini par l’autrice. Les deux références fondatrices ont été vérifiées individuellement (existence, auteurs, lieu de publication, DOI). L’analogie, la structure et les arbitrages pédagogiques relèvent de l’autrice.