A2A : le protocole open source qui fait dialoguer vos agents IA entre eux
Le protocole Model Context Protocol (MCP) a réglé la question de connecter un agent à ses outils. Restait une autre brique : comment faire collaborer plusieurs agents autonomes, développés par des équipes ou des éditeurs différents, sans tout réécrire à chaque intégration. C’est exactement le rôle d’Agent2Agent (A2A), un protocole ouvert désormais hébergé par la Linux Foundation.
D’où vient A2A et pourquoi le regarder maintenant
A2A a été annoncé par Google en avril 2025, puis donné à la Linux Foundation en juin 2025, sous licence Apache 2.0. Le projet est donc gouverné par une fondation neutre et ouvert aux contributions de toute la communauté, ce qui limite le risque de verrouillage par un éditeur. En moins d’un an, il est passé d’une première version à un standard de production : plus de 150 organisations le soutiennent, parmi lesquelles Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday et IBM.
Le problème que A2A résout
Dès qu’une organisation déploie plusieurs agents, par exemple un agent de tri documentaire, un agent de recherche et un agent de rédaction, se pose la question de leur coordination. Sans standard commun, chaque connexion devient une intégration sur mesure, fragile et coûteuse à maintenir. A2A fournit une couche d’interopérabilité horizontale : un agent peut en découvrir un autre, lui déléguer une tâche, et suivre son avancement, même si les deux sont écrits dans des frameworks différents et hébergés sur des infrastructures distinctes.
Comment ça marche, concrètement
A2A réutilise des standards éprouvés plutôt que d’inventer une nouvelle pile technique : tout passe par HTTP, avec JSON-RPC 2.0 comme format d’échange et Server-Sent Events pour le streaming des réponses longues. Trois notions suffisent pour comprendre l’essentiel.
- L’Agent Card : un document JSON publié par chaque agent, qui décrit son identité, ses capacités, ses compétences, son point d’accès et ses exigences d’authentification. C’est la carte de visite qui permet à un agent client de repérer le bon interlocuteur pour une tâche donnée.
- La Task : l’unité de travail fondamentale, identifiée par un identifiant unique. Une tâche est avec état et suit un cycle de vie défini, ce qui permet aux agents de rester synchronisés sur l’avancement, y compris pour des traitements de longue durée.
- Le transport : le client envoie une requête JSON-RPC 2.0 en HTTP POST vers le point d’accès du serveur, qui répond soit par une réponse classique, soit par un flux SSE pour les méthodes en streaming.
A2A et MCP : complémentaires, pas concurrents
La confusion est fréquente, alors qu’il s’agit de deux couches distinctes. MCP normalise la connexion verticale entre un agent et ses outils ou services externes : il aide à construire un agent puissant. A2A normalise la délégation horizontale entre agents autonomes : il aide à construire un système d’agents. Dans une architecture mûre, les deux cohabitent : MCP pour donner des capacités à chaque agent, A2A pour orchestrer leur collaboration.
À retenir : si vous déployez déjà des serveurs MCP, A2A est la suite logique le jour où vous passez d’un agent isolé à plusieurs agents qui doivent se parler. Standard ouvert, licence Apache 2.0, gouvernance par la Linux Foundation : les conditions d’une adoption sereine et souveraine sont réunies.
Par où commencer
La spécification, les SDK et des exemples sont publics sur le dépôt officiel du projet. Une première approche utile consiste à publier l’Agent Card d’un agent existant, puis à écrire un agent client minimal qui le découvre et lui délègue une tâche simple. C’est le meilleur moyen de mesurer ce que A2A change dans une architecture multi-agents avant de l’industrialiser.
