A2A veut standardiser la collaboration entre agents IA

Agent2Agent, ou A2A, est un protocole ouvert qui permet à des agents IA de se découvrir, d’échanger des messages, de déléguer des tâches et de renvoyer des résultats sans exposer leur logique interne. Pensé pour des agents spécialisés qui doivent coopérer entre systèmes, il vise surtout les usages où un agent a besoin d’aide d’un autre, avec des modèles, des frameworks ou des fournisseurs différents. Dans ce contexte, A2A compte parce qu’il traite la communication entre agents comme une couche d’infrastructure, pas comme un bricolage d’intégration de plus.

Une réponse à la fragmentation des agents IA

Le problème que cible A2A est simple à formuler, moins simple à résoudre : dès que plusieurs équipes déploient des agents spécialisés, chaque plateforme risque d’inventer ses propres formats pour l’identité, les capacités, les tâches, les messages et les erreurs. Résultat, la délégation croisée devient coûteuse et les agents restent enfermés dans leur environnement d’origine. A2A standardise cette couche de communication tout en laissant chaque agent fonctionner comme une boîte noire.

Concrètement, un agent d’achat peut solliciter un agent de conformité, tandis qu’un agent du service client peut demander à un agent logistique de vérifier un colis. Le premier n’a pas besoin de connaître le moteur interne du second. Il lui suffit de savoir ce qu’il promet, comment le joindre et comment suivre l’exécution.

Des cartes d’agent, des tâches, puis des artefacts

Le protocole repose sur quelques objets centraux. L’Agent Card publie des métadonnées descriptives et opérationnelles : nom, point de terminaison, capacités, exigences d’authentification, compétences et types de contenu acceptés. Une compétence, dans ce cadre, désigne un domaine déclaré comme traduire un document, vérifier un contrat ou rechercher un marché.

Cette découverte ne vaut pas certification. Une carte d’agent reste une déclaration de capacité, pas une preuve de qualité ou de confiance. Les systèmes de production doivent donc ajouter leurs propres contrôles : identité, autorisation, réputation, politique d’accès et évaluation. Les promesses, en IA comme ailleurs, restent parfois très à l’aise sur papier.

Viennent ensuite les messages, qui transportent instructions, clarifications et contexte, puis les tâches, qui suivent un travail dans le temps. Une tâche peut être acceptée, bloquée, interrompue, terminée ou annulée. Enfin, les artefacts représentent la sortie finale : rapport, jeu de données, image, correctif de code ou recommandation structurée. Cette séparation entre dialogue et livrable facilite la lecture du résultat par l’agent client.

A2A ne remplace pas les API, il change de niveau

Le protocole se distingue d’une API classique par son niveau d’abstraction. Une API sert bien quand l’appelant connaît l’opération exacte et le format d’entrée attendu. A2A devient pertinent quand la demande est ouverte, asynchrone, orientée résultat ou susceptible de durer plusieurs minutes, voire plusieurs heures.

Le document de spécification illustre cette logique avec un scénario de voyage : un agent de planification découvre un spécialiste, lit sa carte, l’authentifie, transmet les détails utiles, puis suit l’avancement jusqu’au retour d’un artefact structuré. Ce fonctionnement permet au système distant de décider lui-même comment produire le résultat, en utilisant éventuellement ses propres outils, des données privées ou d’autres agents. La boundary n’est pas spectaculaire, mais elle change tout.

Pourquoi A2A est comparé à MCP

La comparaison avec le Model Context Protocol revient souvent, et pour cause. MCP relie un hôte IA à des outils, des ressources et des prompts ; A2A relie des agents entre eux pour déléguer un objectif. Dans un même système, les deux peuvent coexister : un agent A2A peut s’appuyer en interne sur MCP pour interroger des bases autorisées ou récupérer des documents de politique publique.

La différence tient à la nature de la relation. MCP standardise l’accès aux capacités. A2A standardise la coordination entre responsables d’un travail. Autrement dit, MCP ressemble à un outil bien rangé ; A2A à un spécialiste qu’on peut missionner sans lui dicter chaque geste.

Le vrai sujet : confiance, autorisation et traçabilité

Le protocole apporte une couche commune, mais il ne règle pas le fond du problème : dès qu’un agent délègue, il crée une chaîne de responsabilité. Le client doit vérifier l’identité du pair, limiter le contexte partagé et préserver l’autorisation de l’utilisateur initial. Le destinataire, lui, ne doit pas hériter de privilèges trop larges sous prétexte qu’un autre agent l’a sollicité.

Les déploiements sérieux devront donc combiner plusieurs garde-fous : authentification, autorisation par périmètre, minimisation des données, traçabilité des sources, validation des sorties, limites de délégation et approbation humaine pour les actions sensibles. Sans cela, un artefact mal vérifié peut se transformer en décision mal prise. Et comme souvent, le risque n’est pas qu’un agent se trompe : c’est qu’un autre lui fasse trop confiance.

Quand le protocole devient utile

A2A prend surtout du sens lorsque des agents indépendants doivent coopérer entre produits, fournisseurs ou organisations ; lorsque la tâche est longue ; ou lorsque le système récepteur doit garder la main sur sa manière de produire le résultat. En revanche, pour une fonction simple, un workflow fermé ou un composant étroitement couplé, une API classique, un bus d’événements ou un appel d’outil reste souvent plus simple à opérer.

Le cœur du projet est là : permettre à des spécialistes construits sur des piles différentes de travailler ensemble sans imposer une uniformité forcée. Le gain potentiel n’est pas seulement technique. Il touche aussi la gouvernance des agents, la réutilisation de capacités et la réduction du couplage entre équipes.