A2A
Pourquoi c’est important
En profondeur
Le problème que traite A2A s'énonce simplement : à mesure que les organisations déploient plus d'agents, ces agents doivent se passer du travail, et chaque paire exige actuellement une intégration sur mesure. A2A définit un motif commun pour ce transfert. Un agent joue le rôle de client en formulant une tâche; un autre joue le rôle d'agent distant en l'exécutant. Les deux échangent contexte, instructions et résultats sur une infrastructure web ordinaire — HTTP avec JSON-RPC 2.0 comme format de transport, et les événements envoyés par le serveur pour les mises à jour en direct — de sorte que l'adoption n'exige ni nouvelle couche de transport ni environnement d'exécution partagé. Élément crucial, les agents restent opaques l'un pour l'autre : ils se coordonnent par des capacités déclarées et l'état des tâches, pas en partageant mémoire, poids ou raisonnement interne.
Fiches d'agent et découverte des capacités
La découverte dans A2A passe par la fiche d'agent : un petit document JSON, typiquement publié à un chemin bien connu comme /.well-known/agent.json sur le domaine de l'agent, qui décrit qui l'exploite, quelles compétences il offre, quels formats d'entrée et de sortie il accepte et quelle authentification il exige. Un agent client va chercher la fiche avant d'envoyer du vrai travail, ce qui lui permet de décider — par programmation ou par un planificateur à modèle de langage — si cet agent distant est seulement un candidat pour le travail. En pratique, les fiches font surface de deux façons : directement, quand un flux de travail connaît déjà l'adresse d'un agent partenaire, ou par des registres sélectionnés qu'une entreprise maintient pour ses agents approuvés. Le modèle de fiche est ce qui transforme A2A d'une convention de messagerie en une véritable couche de découverte, et il reflète la façon dont un agent autonome raisonne sur n'importe quelle autre ressource : lire une description, la confronter à l'objectif, puis agir.
Tâches, messages et artefacts
L'unité de travail dans A2A est la tâche, et elle a un cycle de vie explicite : soumise, en cours, entrée requise, terminée, échouée ou annulée. À l'intérieur d'une tâche, les deux agents échangent des messages, et chaque message est fait de parties plutôt que de texte brut — une partie texte pour le langage naturel, une partie fichier pour du contenu binaire, ou une partie données pour des charges utiles JSON structurées comme des formulaires et des soumissions de prix. Ce modèle par parties compte parce que les vrais flux de travail d'affaires roulent sur des données structurées, et A2A laisse les agents négocier sur de la sortie structurée au lieu de tout faire passer par de la prose conversationnelle. Quand une tâche se termine, ses résultats sont livrés sous forme d'artefacts : des sorties nommées, elles aussi bâties à partir de parties, que l'agent client peut consommer lui-même ou passer à l'étape suivante d'un flux agentique plus large.
Les états du cycle de vie gagnent leur vie sur le travail de longue haleine. Une tâche qui prend des minutes ou des heures peut diffuser des événements de progression vers le client par les événements envoyés par le serveur, ou livrer des mises à jour par notifications poussées vers un webhook quand le client ne peut pas garder une connexion ouverte, ce qui garde la diffusion en continu viable même pour des consommateurs déconnectés. L'état « entrée requise » est le subtil : il laisse l'agent distant faire une pause et poser une question de clarification en cours de tâche, et c'est ainsi que la négociation multitours entre agents se produit sans briser l'abstraction de tâche.
A2A ne remplace pas MCP
L'idée fausse la plus répandue au sujet d'A2A, c'est qu'il concurrence MCP. Ce n'est pas le cas — les deux protocoles opèrent à des couches différentes. MCP normalise la façon dont un agent unique se connecte aux outils et aux sources de données : appeler une fonction, lire une ressource, exécuter une requête. A2A normalise la façon dont deux agents indépendants se coordonnent, l'un déléguant une tâche à un pair qui peut appartenir à une équipe, un fournisseur ou un domaine de confiance entièrement différent. Le raccourci que vous entendrez, c'est que MCP est l'interface verticale (agent vers outil) tandis qu'A2A est l'horizontale (agent vers agent).
Un montage de production réaliste utilise les deux dans la même chaîne d'appels. Un agent orchestrateur pourrait utiliser MCP pour l'utilisation d'outils — interroger un système de gestion de la relation client, un index de recherche ou un dépôt de code — puis utiliser A2A pour sous-traiter à un agent spécialiste, comme un agent de révision de contrats exploité par le service juridique, qui s'appuie lui-même sur MCP et l'appel de fonctions à l'interne. Ni l'un ni l'autre des protocoles ne dicte ce qui se passe à l'intérieur de l'autre agent, et cette opacité est un choix de conception délibéré : elle permet aux organisations de collaborer sans exposer prompts, mémoire ou raisonnement propriétaire.
Gouvernance, écosystème et questions ouvertes
Google a publié A2A comme spécification ouverte avec des trousses de développement de référence en 2025, appuyée au lancement par plus de 50 partenaires technologiques couvrant des éditeurs de logiciels d'entreprise, des cadriciels comme LangChain et des cabinets-conseils. L'entreprise a ensuite fait don du projet à la Linux Foundation pour qu'aucun fournisseur unique n'en contrôle l'évolution. Ce geste de gouvernance compte pour l'adoption : les protocoles ne deviennent de la plomberie que lorsque des concurrents peuvent les implémenter sans craindre que les règles changent sous eux. La spécification, les trousses et les agents d'exemple sont tous publics, et la conception réutilise délibérément des normes web existantes plutôt que d'en inventer de nouvelles.
Les problèmes difficiles à venir portent moins sur les formats de messages que sur la confiance. Une fiche d'agent déclare quelle authentification un agent exige, mais rien dans le protocole ne vous dit s'il faut croire la fiche, ce qui fait du trafic A2A entre organisations une question de sécurité de l'IA autant qu'une question d'intégration. L'injection de prompt est un risque concret : un agent distant malveillant ou compromis peut intégrer des instructions hostiles dans des résultats de tâche que le modèle de l'agent client lira docilement. Les équipes qui bâtissent des systèmes multiagents sur A2A aujourd'hui contrent généralement ça en restreignant la découverte à des registres sélectionnés, en validant les artefacts avant qu'ils atteignent un modèle, et en traitant chaque agent distant comme non fiable par défaut.