Fondamentaux de l’IA
Qu’est-ce que Agent2Agent (A2A) ? Comment les agents IA communiquent et collaborent
Agent2Agent est un protocole ouvert permettant aux agents de se découvrir mutuellement, d’échanger des messages et de coordonner le travail entre systèmes. Découvrez comment A2A diffère de MCP et pourquoi les agents interopérables sont importants.

Agent2Agent (A2A) est un protocole ouvert qui permet aux agents IA de se découvrir mutuellement, d’échanger des messages, de déléguer des tâches, de rendre compte de l’avancement et de renvoyer les résultats au‑delà des frontières du système. Il est conçu pour les situations où un agent a besoin d’aide d’un autre sans que l’une ou l’autre partie doive exposer son raisonnement interne, sa mémoire ou son implémentation.
À mesure que les organisations déploient des agents spécialisés, la communication devient un problème d’infrastructure. Un agent d’approvisionnement peut avoir besoin d’informations d’un agent de conformité ; un agent du service client peut avoir besoin d’un agent logistique pour enquêter sur un envoi. A2A offre un moyen commun de coordonner ce travail même lorsque les agents utilisent différents cadres, fournisseurs ou modèles.
Pourquoi les agents ont besoin d’une norme de communication
Les API traditionnelles exposent des fonctions et des données, mais une interaction agent‑à‑agent peut être plus ouverte. L’agent récepteur peut devoir interpréter un objectif, décider comment le résoudre, poser des questions de suivi, travailler pendant des minutes ou des heures, diffuser des mises à jour et renvoyer plusieurs artefacts.
Sans protocole partagé, chaque plateforme définirait ses propres formats pour l’identité, la découverte des capacités, les tâches, les messages, le statut et les erreurs. Cette fragmentation rend la délégation inter‑plateformes difficile et enferme les agents utiles dans des produits individuels.
A2A standardise la couche de communication tout en permettant à chaque agent de rester une boîte noire. La spécification A2A actuelle définit les objets et interactions de base du protocole.
Les rôles clés dans A2A
Cette séparation est ce qui rend A2A différent d’un simple appel de fonction. Le participant distant peut gérer une tâche de longue durée, demander des informations supplémentaires, négocier les types de contenu pris en charge et renvoyer un ou plusieurs artefacts. L’agent client suit cette tâche tout en préservant l’identité et l’autorité de l’utilisateur ou de l’application qui l’a initiée.
Une interaction A2A implique généralement deux rôles logiques :
- Agent client : l’agent ou l’application demandant le travail.
- Agent distant : l’agent qui reçoit la requête et exécute ou coordonne le travail.
Les termes « client » et « distant » décrivent l’interaction actuelle, pas une hiérarchie permanente. Le même agent peut demander du travail dans un contexte et servir un autre agent dans un contexte différent.
Cartes d’agent : découverte des capacités
Avant de déléguer une tâche, un client doit savoir ce qu’un agent distant peut faire et comment communiquer avec lui. A2A utilise une carte d’agent pour publier des métadonnées descriptives et opérationnelles.
Une carte d’agent peut décrire le nom d’un agent, son point de terminaison, les fonctionnalités de protocole prises en charge, les attentes en matière d’authentification, les compétences et les types de contenu acceptés. Une compétence est un domaine de capacité déclaré, tel que la traduction d’un document, la vérification d’un contrat ou la recherche d’un marché.
La découverte ne prouve pas la qualité ou la fiabilité. Une carte d’agent est une affirmation de capacité, pas une certification indépendante. Les systèmes de production ont toujours besoin d’identité, d’autorisation, de contrôles de politique, de réputation et d’évaluation.
Messages, tâches et artefacts
A2A représente la collaboration à travers plusieurs objets fondamentaux.
Messages
Les messages transportent la communication entre les agents. Ils peuvent contenir du texte et d’autres parties structurées, permettant aux agents d’échanger des instructions, des clarifications ou du matériel contextuel.
Tâches
Une tâche représente une unité de travail dont l’état peut évoluer au fil du temps. Un agent distant peut accepter le travail, poursuivre le traitement, demander davantage d’entrée, le terminer, échouer ou l’annuler. Une identité de tâche persistante est utile pour les opérations de longue durée, car le client peut se référer au même travail lors des mises à jour.
Artefacts
Les artefacts sont les résultats produits par le travail, tels qu’un rapport, un jeu de données, une image, un correctif de code ou une recommandation structurée. Séparer les artefacts des messages conversationnels facilite l’identification et la consommation des livrables finaux par le client.
Comment fonctionne une interaction A2A
| A2A | Coordonne le travail et les messages entre agents autonomes. |
|---|---|
| MCP | Connecte un hôte IA aux outils, ressources et invites. |
| Besoin partagé | Identité, permission délimitée, messages structurés et résultats audités. |
| Défaillance | Un agent récepteur fait confiance à une requête ou un artefact sans vérifier son autorité ni ses preuves. |
Supposons qu’un agent de planification de voyage ait besoin d’un spécialiste pour vérifier les exigences d’entrée.
- Le client découvre un agent distant et lit sa Carte d’Agent.
- Il vérifie que l’agent propose la capacité pertinente et une méthode d’interaction compatible.
- Le client s’authentifie et envoie un message décrivant la tâche, les voyageurs, les dates et le résultat requis.
- L’agent distant crée ou met à jour une tâche et commence le travail.
- L’agent distant peut diffuser la progression ou demander un détail manquant.
- Le client fournit la clarification tout en préservant le contexte de la tâche.
- L’agent distant termine la tâche et renvoie un artefact structuré avec son résultat.
- Le client évalue ce résultat avant de l’utiliser dans le plan de voyage global.
L’agent distant décide comment accomplir son mandat. Il peut appeler ses propres outils, consulter des données privées ou coordonner d’autres agents. A2A n’exige pas que ces étapes internes soient révélées.
A2A vs. MCP
Les protocoles peuvent se situer à différents niveaux de la même architecture. Un agent de planification de voyage pourrait déléguer une tâche de recherche de visa à un spécialiste via A2A. Cet agent spécialiste pourrait alors utiliser les connexions MCP pour interroger des bases de données approuvées et récupérer les documents de politique. A2A coordonne la responsabilité entre agents ; MCP standardise l’accès entre un hôte IA et les capacités.
A2A et le Protocole de Contexte de Modèle résolvent différents problèmes d’intégration.
- MCP connecte une application IA aux outils et au contexte. Un client découvre des capacités telles que fonctions, ressources et invites provenant d’un serveur MCP.
- A2A connecte des agents à des agents. Un client délègue une tâche orientée objectif à un agent distant qui peut gérer son propre processus et renvoyer un résultat.
La différence ressemble à l’utilisation d’un outil versus l’embauche d’un spécialiste. Une calculatrice expose une opération ; un analyste accepte un objectif et décide quelles opérations sont nécessaires. Dans les systèmes réels, un agent A2A distant peut utiliser MCP en interne pour accéder à ses propres outils et données.
A2A vs. API ordinaires
Une API conventionnelle est idéale lorsque l’appelant connaît l’opération exacte et le format d’entrée : récupérer un enregistrement, calculer un devis ou mettre à jour un champ. A2A est utile lorsque la requête est conversationnelle, étatful, asynchrone ou orientée résultat.
A2A ne remplace pas toutes les API. Les agents distants appellent souvent des API ordinaires pour accomplir leur travail, et les organisations peuvent exposer directement des services déterministes lorsque la discrétion de l’agent n’apporte aucune valeur.
Pourquoi l’interopérabilité est importante
Les écosystèmes d’agents seront hétérogènes. Différentes équipes optimiseront pour différents domaines, modèles, frontières de sécurité et environnements de déploiement. Un protocole partagé permet aux organisations de préserver cette spécialisation tout en facilitant la collaboration.
L’interopérabilité peut également réduire le couplage d’intégration. Un client peut se fier à une compétence déclarée et au comportement du protocole au lieu d’importer le cadre de l’agent distant ou de dupliquer sa logique interne. La présentation du projet A2A décrit cet objectif comme permettant aux agents construits sur différentes piles de communiquer comme des pairs ; la mise à jour du projet en 2026 concernant l’adhésion à la Agentic AI Foundation reflète la volonté d’une gouvernance neutre et intersectorielle.
Défis de sécurité et de confiance
La délégation crée une chaîne de responsabilité. Le client doit vérifier l’identité de l’agent distant et la capacité annoncée, minimiser le contexte partagé et préserver l’autorisation de l’utilisateur initiateur. L’agent distant ne doit pas hériter de privilèges étendus simplement parce qu’un autre agent a demandé la tâche. Chaque saut nécessite une authentification, des identifiants limités, une traçabilité et une règle claire sur ce qui se passe lorsque les exigences sont en conflit ou que la confiance est faible.
La délégation d’agent à agent crée une chaîne d’autorité. Un client peut accidentellement partager un contexte sensible, accorder à un agent distant plus de discrétion que prévu, ou agir sur un artefact peu fiable. L’agent distant peut également recevoir des instructions ou des fichiers malveillants d’un client non fiable.
Les déploiements robustes nécessitent des contrôles à plusieurs niveaux :
- Identité et authentification : vérifier quel agent et quelle organisation participent.
- Autorisation : limiter les compétences, les données, les actions et le périmètre des tâches disponibles pour chaque appelant.
- Minimisation des données : partager uniquement le contexte dont l’agent distant a besoin.
- Provenance : enregistrer qui a demandé le travail, quel agent l’a produit et quelles sources le soutiennent.
- Validation des sorties : traiter les artefacts distants comme non fiables jusqu’à ce qu’ils passent les vérifications appropriées.
- Limites de délégation : contrôler si un agent distant peut impliquer d’autres agents ou services.
- Approbation humaine : mettre en pause avant des actions financières, juridiques, externes, destructrices ou autrement conséquentes.
La compatibilité du protocole n’implique pas la confiance organisationnelle. Un agent peut parler correctement le A2A et rester inapproprié pour une tâche particulière.
Quand les équipes devraient-elles utiliser A2A ?
A2A est le plus convaincant lorsque des agents indépendants doivent collaborer au-delà des frontières de produit, de fournisseur ou d’organisation ; lorsque le travail est de longue durée ; ou lorsque le système récepteur doit conserver la liberté quant à la manière dont il produit le résultat.
Il peut être superflu pour une fonction simple, un flux de travail interne fixe ou des composants étroitement couplés au sein d’une même application. Dans ces cas, une API ordinaire, un bus d’événements ou un appel direct d’outil peut être plus facile à gérer et à évaluer.
Ce qu’il faut retenir sur ce qu’est Agent2Agent (A2A)
A2A fournit un langage commun permettant aux agents de découvrir des capacités et de coordonner un travail orienté vers des objectifs sans partager leur machinerie interne. Sa valeur principale n’est pas que plusieurs agents soient automatiquement meilleurs qu’un seul, mais que des spécialistes construits indépendamment puissent collaborer à travers une frontière stable.
Cette frontière doit transporter plus que des messages. Elle nécessite une identité, l’état des tâches, des artefacts, des autorisations, la provenance et la gestion des échecs. A2A fournit la base du protocole ; les organisations doivent encore fournir le modèle de confiance.












