Après MCP, A2A : pourquoi les agents IA vont devoir apprendre à travailler entre eux

MCP relie un agent à un outil, A2A relie un agent à un autre agent

MCP standardise la façon dont une application IA accède à des outils et à des sources de contexte. A2A s’intéresse à la communication entre agents, où l’interlocuteur n’est plus une fonction mais une entité qui possède ses propres capacités et son propre cycle d’exécution.

Un exemple rend la distinction concrète. Un agent commercial prépare une réponse à un appel d’offres. Il sollicite un agent spécialisé dans la recherche documentaire, transmet certains éléments à un agent juridique, demande à un troisième de vérifier les contraintes tarifaires, puis agrège les résultats. Ce n’est plus un agent avec des outils : c’est une organisation.

Les deux protocoles n’ont ni la même origine ni le même périmètre. MCP a été publié par Anthropic en novembre 2024 pour connecter une application IA à des outils et à des sources de données. A2A, pour Agent2Agent, a été annoncé par Google en avril 2025, puis transféré en juin 2025 à la Linux Foundation aux côtés d’AWS, Cisco, Microsoft, Salesforce, SAP et ServiceNow. Ce point de gouvernance compte plus qu’il n’y paraît : un protocole censé faire dialoguer les agents de fournisseurs concurrents n’a d’intérêt durable que s’il n’appartient à aucun d’entre eux.

En résumé, MCP relie un agent à un outil, quand A2A relie un agent à un autre agent. La différence n’est pas cosmétique : appeler une fonction produit un résultat, alors que solliciter un agent engage un interlocuteur qui décide. La frontière n’est pas étanche pour autant. Rien n’interdit d’exposer un agent derrière une interface MCP et de l’appeler comme un outil ; la vraie question est de savoir quelle couche prend alors en charge l’état de la conversation et le suivi des tâches.

Pourquoi ne pas construire un seul agent qui fait tout ?

La question est légitime : si un modèle peut accéder à dix outils, pourquoi en introduire cinq ? La spécialisation devient intéressante quand les domaines divergent réellement. Un agent juridique n’a ni les mêmes instructions, ni les mêmes sources, ni les mêmes garde-fous qu’un agent commercial ; un agent IT accède à des outils que les autres n’ont aucune raison de toucher.

Cette séparation permet de délimiter les responsabilités, et elle permet surtout à des systèmes construits par des équipes ou des fournisseurs différents de collaborer sans être fusionnés dans une application unique. C’est cet argument-là, plus que la performance, qui justifie généralement le découpage.

Découper ne divise pas la complexité, cela la déplace

Répartir un problème sur cinq agents ne le rend pas cinq fois plus simple. Il faut désormais décider quel agent reçoit la tâche, quelles informations lui transmettre, comment suivre son état, que faire lorsqu’il échoue, et comment agréger des résultats hétérogènes.

Une expérimentation publiée en juillet 2026 par une équipe de l’université d’York donne un ordre de grandeur de ce que coûte cette coordination. Les chercheurs ont implémenté deux fois le même workflow multi-agents, une fois avec MCP et une fois avec A2A, puis comparé les deux versions. A2A offre des abstractions natives plus riches pour la coordination avec état et sur plusieurs tours, en particulier la notion de tâche et son cycle de vie, là où MCP impose de gérer explicitement l’état conversationnel dans le code applicatif. Cette richesse se paie : dans leur scénario, la version A2A représentait environ 50 % de code en plus et mobilisait nettement plus de primitives de coordination.

Ces chiffres méritent d’être lus pour ce qu’ils sont. Ils portent sur un seul scénario de collaboration, volontairement étroit : déléguer une tâche, itérer avec des retours, faire valider le résultat. Les auteurs présentent d’ailleurs eux-mêmes leurs résultats comme des observations de conception issues d’un retour d’expérience, et non comme un benchmark ou comme une règle valable pour toutes les architectures multi-agents. On ne peut donc pas en conclure qu’A2A est plus lourd en général, ni que MCP suffirait partout. Ce que l’expérience montre, plus modestement, c’est que la coordination ne disparaît jamais : soit le protocole la prend en charge et son implémentation s’alourdit, soit il ne la prend pas en charge et c’est le code applicatif qui l’absorbe.

Notre lecture est la suivante : le multi-agent n’est pas une sophistication gratuite, c’est un arbitrage, et cet arbitrage se pose avant même le choix du protocole.

Que faut-il transmettre à un agent quand on lui délègue une tâche ?

Lorsqu’un agent commercial sollicite un agent juridique, doit-il lui transmettre toute la conversation avec le client ? Presque jamais. Il doit fournir ce qui est nécessaire à la tâche, et rien de plus.

On retrouve les principes du Context Engineering, avec une dimension supplémentaire : le contexte franchit désormais la frontière entre deux agents. Chaque transfert pose donc trois questions distinctes. Que doit savoir l’agent destinataire ? Que n’a-t-il pas besoin de savoir ? Et surtout, qu’a-t-il le droit de savoir ? Cette dernière cesse d’être théorique quand les agents appartiennent à des domaines ou à des organisations différentes.

Quand cinq agents ont contribué à une erreur, qui en répond ?

Avec un agent unique, la chaîne de responsabilité se reconstruit facilement. Avec plusieurs, un résultat devient la conséquence d’une suite de décisions. L’agent A délègue à B, B interroge C, C renvoie une donnée erronée, B l’interprète correctement mais transmet une conclusion incomplète, et A tranche mal.

Quel composant a échoué ? Aucun, pris isolément. L’observabilité doit donc couvrir non seulement les actions de chaque agent mais la chaîne de délégation elle-même, faute de quoi le diagnostic devient impraticable. C’est une extension directe de ce que décrit notre décryptage sur l’observabilité agentique : reconstruire une trajectoire, mais cette fois à travers plusieurs systèmes.

Comment un agent sait-il ce que les autres agents savent faire ?

Dans un écosystème ouvert, un agent doit pouvoir comprendre les capacités des autres, ce qui suppose de les décrire de façon exploitable. Un agent commercial cherchant une expertise juridique doit identifier qui peut répondre et comment lui transmettre la tâche. A2A traite ce point avec l’Agent Card, un document de métadonnées dans lequel chaque agent déclare ses compétences, son point d’entrée et ses modalités d’authentification. Le mécanisme résout la découverte, pas la confiance : une carte décrit ce qu’un agent affirme savoir faire, jamais la qualité de ce qu’il produira.

C’est la problématique classique de la découverte de services dans les architectures distribuées, avec une différence notable : les services en question ont un comportement partiellement autonome, et il faut donc savoir non seulement qui peut faire quoi, mais qui a le droit de parler à qui. La question rejoint alors celle de l’identité des agents.

Plus d’agents ne veut pas dire de meilleurs résultats

L’engouement laisse parfois penser qu’un ensemble de spécialistes surpasse nécessairement un agent unique. Ce n’est pas une règle. Chaque agent ajouté introduit des appels de modèle, de la latence, des coûts et des points de défaillance supplémentaires.

Si un seul agent doté de quelques outils bien conçus accomplit la tâche correctement, le découper revient souvent à déplacer la complexité plutôt qu’à la réduire. La question reste architecturale : la spécialisation apporte-t-elle assez de valeur pour justifier la coordination qu’elle impose ?

À retenir

Après les modèles, les outils et les agents individuels, une couche de coordination émerge. Elle rend possibles des systèmes de spécialistes capables de traiter des tâches complexes, et elle introduit de nouvelles questions de contexte, d’identité, de responsabilité, de coût et d’observabilité.

Le défi des architectures multi-agents ne sera pas de faire parler les agents entre eux, mais de s’assurer qu’ils ne collaborent que lorsque cette collaboration apporte plus de valeur qu’elle ne coûte en complexité.