La plupart des systèmes d'IA actuels sont des agents uniques. Un seul modèle, une seule boucle d'invite, un seul ensemble d'outils. Cela fonctionne jusqu'à ce que la tâche soit trop importante pour un seul agent, ou jusqu'à ce que vous ayez besoin d'un agent construit par une autre équipe pour gérer une étape que votre agent ne peut pas. Alors vous butez sur un mur : il n'existe pas de moyen standard pour deux agents indépendants de se trouver, d'échanger du travail et de rendre des comptes. Agent2Agent (A2A) est le protocole conçu pour abattre ce mur.
Ce guide explique ce qu'est l'A2A, le problème qu'il résout, comment il fonctionne en coulisses et en quoi il diffère du MCP. Si vous souhaitez tester un agent A2A après cette lecture, le guide du débogueur A2A Apidog prend le relais là où cet article se termine.
Qu'est-ce qu'Agent2Agent (A2A) ?
Agent2Agent (A2A) est un protocole ouvert de communication entre agents IA. Il définit comment un agent annonce ses capacités, comment un autre agent s'y connecte, comment les deux échangent des messages et des fichiers, et comment l'état des tâches est renvoyé à l'appelant.
Le mot clé est *entre*. L'A2A ne consiste pas à donner plus d'outils à un agent. Il s'agit de permettre à des agents distincts, souvent construits sur des frameworks différents par des équipes différentes, de travailler ensemble sans que l'une ou l'autre partie ne connaisse les rouages internes de l'autre.
Considérez-le comme le protocole HTTP pour le trafic d'agents. HTTP permet à un navigateur de communiquer avec n'importe quel serveur web sans se soucier du langage utilisé par le serveur. L'A2A permet à un agent LangGraph de communiquer avec un agent CrewAI sans se soucier de la manière dont cet agent a été construit. Les deux parties s'accordent sur l'enveloppe ; aucune des deux parties ne divulgue son implémentation.
Google a introduit l'A2A en 2025 et l'a ensuite transféré à la Linux Foundation en tant que projet neutre vis-à-vis des fournisseurs. La spécification est disponible en open source sur le dépôt GitHub d'A2A, et des implémentations de référence sont publiées sur le site du projet A2A.
Le problème que l'A2A résout
Avant l'A2A, connecter deux agents impliquait d'écrire du code "glue". Chaque appairage était personnalisé. Si votre agent avait besoin d'appeler l'agent de recherche d'une équipe partenaire, quelqu'un écrivait un client sur mesure, choisissait une forme de charge utile, inventait un schéma d'authentification et maintenait le tout manuellement. L'appairage suivant recommençait à zéro.
Cette approche échoue rapidement :
- Pas de découverte. Il n'y avait pas de moyen standard pour un agent de demander « que peux-tu faire ? » avant d'envoyer du travail.
- Pas de modèle de tâche partagé. Un agent renvoyait une chaîne de caractères simple, un autre un blob JSON personnalisé, un troisième diffusait des jetons. L'appelant devait gérer chaque cas de manière spécifique.
- Pas d'authentification commune. Chaque intégration réinventait les identifiants et les en-têtes.
- Pas d'interopérabilité. Un agent construit sur AutoGen ne pouvait pas remplacer un agent construit sur LangGraph, même s'ils faisaient le même travail.
L'A2A résout ce problème de la même manière qu'OpenAPI a résolu les intégrations REST : un contrat convenu, de sorte que tout agent conforme puisse communiquer avec tout autre agent conforme.
Comment l'A2A fonctionne
L'A2A repose sur quatre concepts fondamentaux. Une fois que vous les connaissez, tout le protocole tient dans votre tête.
La carte d'agent
La carte d'agent est un document JSON qu'un agent publie pour se décrire. C'est le point d'entrée de la découverte. Elle liste le nom de l'agent, sa description, ses capacités, ses compétences déclarées, les types d'entrée et de sortie pris en charge, les exigences d'authentification et la version du protocole.
Par convention, la carte se trouve à un chemin bien connu, souvent `https://your-agent.example.com/.well-known/agent.json`. Un agent appelant récupère d'abord cette URL, lit la carte et apprend exactement ce qu'il peut demander avant d'envoyer un seul message.
Les tâches
Une tâche est l'unité de travail dans l'A2A. Lorsqu'un agent demande à un autre de faire quelque chose, cette requête devient une tâche avec son propre ID et un statut qui passe par des états tels que `soumise`, `en cours`, `entrée-requise` et `terminée`. L'appelant peut interroger la tâche ou s'abonner aux mises à jour. Ce modèle de tâche partagé est ce qui rend les agents A2A interchangeables ; l'appelant gère le statut de la même manière, quel que soit l'exécutant.
Messages et artéfacts
Un message transporte le contenu réel entre les agents. Un message est composé de parties : une partie texte, une partie fichier, des données structurées ou un mélange. L'agent récepteur lit les parties dont sa compétence a besoin.
Lorsque l'agent a terminé, il renvoie des artéfacts ; les sorties structurées de la tâche. Un artéfact peut être un document généré, un tableau de données, un résumé ou une référence de fichier. Les artéfacts sont également construits à partir de parties, de sorte que le format reste cohérent dans les deux sens.
Streaming et mises à jour
Les tâches de longue durée n'ont pas à bloquer. L'A2A prend en charge les événements envoyés par le serveur, de sorte qu'un agent peut diffuser des résultats partiels et des changements de statut au fur et à mesure de la progression du travail. Un agent de recherche peut émettre « 3 sources trouvées » avant d'émettre le rapport final. L'appelant affiche la progression au lieu de regarder un curseur tourner.
En résumé, un échange A2A typique se présente comme suit :
- L'agent A récupère la carte d'agent de l'agent B et lit ses compétences.
- L'agent A envoie un message qui crée une tâche.
- L'agent B traite la tâche et diffuse les mises à jour de statut.
- L'agent B renvoie les artéfacts lorsque la tâche atteint l'état `terminée`.
- L'agent A consomme les artéfacts et passe à autre chose.
Toute la conversation est en JSON sur HTTP. Rien d'exotique.
A2A vs MCP
L'A2A et le protocole de contexte de modèle (MCP) sont constamment confondus car tous deux impliquent des agents et sont tous deux des protocoles ouverts. Ils résolvent des problèmes différents.
| A2A | MCP | |
|---|---|---|
| Connecte | Agent à agent | Agent aux outils et données |
| Question à laquelle il répond | « Un autre agent peut-il faire cette étape pour moi ? » | « Quels outils et ressources cet agent peut-il atteindre ? » |
| Usage typique | Workflows multi-agents entre équipes | Un seul agent appelant une base de données, un système de fichiers ou une API |
| Unité d'échange | Tâches, messages, artéfacts | Appels d'outils, ressources, invites |
MCP est la façon dont un agent accède *à* des systèmes externes. L'A2A est la façon dont un agent accède *à* un autre agent. Un véritable système de production utilise souvent les deux : un agent utilise MCP pour interroger une base de données et A2A pour confier une sous-tâche à un agent spécialisé. Le comparatif entre serveur MCP et A2A couvre la décision en profondeur, et le débogueur client MCP d'Apidog montre le côté MCP en pratique.
Collaboration multi-agents dans la nature
L'A2A est un moyen de faire collaborer des agents, mais pas le seul. Certains systèmes utilisent plutôt l'orchestration directe, où un agent planifie le travail et le délègue explicitement à un autre.
Un exemple open-source clair est Codex-Claude-Collab, une compétence qui coordonne un flux de travail en temps réel entre OpenAI Codex et Claude Code. Codex planifie la tâche, délègue l'implémentation à Claude Code, puis examine les différences et vérifie le résultat avant de répondre à l'utilisateur. C'est une boucle étroite de planificateur-constructeur entre deux agents de codage différents.
Ce modèle est une orchestration câblée ; une partie sait exactement qui est l'autre. L'A2A généralise la même idée : au lieu que Codex sache qu'il appelle spécifiquement Claude Code, un appelant A2A lit une carte d'agent et travaille avec tout agent conforme qui répond. L'orchestration est excellente lorsque vous contrôlez les deux extrémités. L'A2A est ce que vous voulez lorsque les agents sont indépendants, appartiennent à des équipes différentes ou doivent être interchangeables. La plupart des systèmes matures finissent par avoir les deux : l'orchestration au sein d'une équipe, l'A2A à travers les limites des équipes.
Comment tester un agent A2A
Une fois que vous avez construit ou consommé un agent A2A, vous devez visualiser le trafic. Les journaux de console masquent les champs structurés, et les scripts de test sur mesure se dégradent. C'est là qu'un débogueur A2A visuel trouve sa place.
Apidog intègre un débogueur A2A dans son client standard. Vous collez une URL de carte d'agent, cliquez sur Connecter, et Apidog lit la carte et affiche le nom, les capacités et les compétences de l'agent. Vous envoyez un message test, joignez des fichiers, ajoutez des métadonnées et lisez la réponse sous trois vues : un aperçu lisible, le contenu brut et la charge utile JSON-RPC complète. Il gère les en-têtes Bearer Token, Basic Auth et clé API sans curl.
Le but est l'isolation. Lorsqu'un agent se comporte mal, vous voulez savoir si le transport est en cause ou si la logique de l'agent est défaillante. Voir la charge utile exacte sur le fil répond à cette question en quelques secondes. Le guide du débogueur A2A Apidog décrit un cycle complet de connexion-envoi-lecture, et le principe plus large du test des agents IA qui appellent vos API applique la même discipline de "confirmer d'abord le fil".
Démarrer avec A2A
Si vous souhaitez construire ou connecter un agent A2A, voici un chemin court :
- Lisez la spécification A2A pour connaître les champs requis de la carte d'agent et le cycle de vie des tâches.
- Exécutez l'un des agents d'exemple de référence localement. La plupart démarrent en quelques minutes et exposent une carte d'agent fonctionnelle.
- Pointez un débogueur A2A vers l'URL de la carte d'agent de l'exemple et envoyez un message « bonjour ». Confirmez que vous pouvez voir l'aller-retour.
- Construisez votre propre agent, exposez une carte d'agent valide et testez-le de la même manière avant de l'intégrer à un workflow.
- Ajoutez l'authentification, les pièces jointes et le streaming une fois que le chemin en texte brut fonctionne.
L'A2A est jeune, mais il est soutenu par une fondation neutre vis-à-vis des fournisseurs et une liste croissante d'intégrations de frameworks. Traiter le trafic d'agents comme un protocole de première classe vous évitera de devoir réécrire des solutions personnalisées plus tard. L'article Les agents IA sont les nouveaux consommateurs d'API développe l'argument, et concevoir des API pour les agents IA couvre ce qui change lorsque votre consommateur est un agent plutôt qu'un humain.
Questions fréquentes
L'A2A est-il développé par Google ?
Google a introduit l'A2A en 2025, puis l'a fait don à la Linux Foundation en tant que projet ouvert et neutre vis-à-vis des fournisseurs. La spécification est développée en open source, et tout fournisseur peut l'implémenter.
Ai-je besoin de l'A2A si je n'ai qu'un seul agent ?
Non. L'A2A résout la communication d'agent à agent. Un seul agent avec un ensemble d'outils a besoin du MCP, pas de l'A2A. Vous utilisez l'A2A lorsqu'un deuxième agent entre en jeu.
Quels frameworks prennent en charge l'A2A ?
L'A2A est agnostique vis-à-vis des frameworks par conception. Tout agent qui publie une carte d'agent valide et parle le protocole peut participer, donc LangGraph, CrewAI, AutoGen et les agents personnalisés fonctionnent tous. Le framework interne de l'agent est invisible pour les appelants.
L'A2A est-il identique au MCP ?
Non. Le MCP connecte un agent à des outils et des sources de données. L'A2A connecte les agents entre eux. Ils sont complémentaires, et de nombreux systèmes utilisent les deux simultanément.
Comment déboguer une intégration A2A ?
Utilisez un débogueur A2A visuel tel que le Débogueur A2A Apidog. Collez l'URL de la carte d'agent, envoyez des messages de test et examinez la requête et la réponse brutes afin de distinguer les bogues de transport des bogues de logique d'agent.
L'A2A prend-il en charge les tâches de longue durée ?
Oui. Le modèle de tâche a des états de statut explicites, et le protocole prend en charge les événements envoyés par le serveur pour le streaming des résultats partiels et les mises à jour de progression, de sorte que les tâches longues ne bloquent pas l'appelant.