Protocole A2A (Agent-to-Agent) : le standard 2026

Le protocole A2A (Agent-to-Agent) est un standard ouvert qui permet à des agents IA de communiquer et de se déléguer des tâches entre eux, quels que soient le fournisseur et le framework qui les ont construits. Créé par Google et annoncé le 9 avril 2025, il est aujourd’hui gouverné par la Linux Foundation avec le soutien de plus de 50 partenaires technologiques.

Là où le MCP connecte un agent à ses outils, A2A connecte les agents entre eux. C’est la brique qui manquait pour passer d’agents isolés à des systèmes multi-agents qui collaborent vraiment. Dans ce guide, je vous explique ce qu’est A2A, comment il fonctionne concrètement, en quoi il se distingue du MCP, et ce que ce standard change pour vos architectures d’agents.

Pourquoi le protocole A2A émerge maintenant

A2A répond à un problème précis : en 2026, les agents IA se multiplient, mais ils ne savent pas se parler. Chaque fournisseur a son framework, son format de messages, sa manière de déléguer une tâche. Résultat : un agent construit avec CrewAI ne peut pas coopérer nativement avec un agent Semantic Kernel ou un agent maison, sans intégration sur mesure.

Ce cloisonnement devient un frein dès que l’on veut construire des systèmes ambitieux. Gartner estime que 40 % des applications d’entreprise intégreront des agents IA d’ici fin 2026, contre moins de 5 % en 2025. Sans standard de communication, chaque intégration entre deux agents redevient un cas particulier coûteux et fragile.

A2A applique aux agents la même logique que le MCP a appliquée aux outils : un langage commun. Google a annoncé le protocole en avril 2025, puis en a fait don à la Linux Foundation le 23 juin 2025 pour garantir sa neutralité. En 2026, le projet rejoint l’Agentic AI Foundation, la fondation qui gouverne déjà le MCP. Le comité technique réunit des acteurs concurrents : AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP et ServiceNow.

Ce point est important : quand des rivaux directs s’accordent sur un standard, c’est généralement le signe qu’il va durer.

Ce qu’est réellement le protocole A2A

A2A est un protocole de communication pair-à-pair entre agents. Concrètement, il définit comment un agent en découvre un autre, lui envoie une demande, suit l’avancement d’une tâche et récupère le résultat, le tout via un format standardisé.

Le protocole repose sur un principe clé : les agents opaques. Un agent A2A expose ce qu’il sait faire et comment l’appeler, mais jamais sa logique interne, ses prompts ou ses modèles. Deux agents peuvent collaborer sans se révéler mutuellement leur fonctionnement, ce qui est essentiel pour l’interopérabilité entre entreprises concurrentes.

A2A est publié sous licence Apache 2.0 et a atteint sa version 1.0. La documentation officielle précise aussi ce qu’A2A n’est pas : ce n’est ni un kit de développement d’agents, ni un protocole de sous-agents, ni un remplacement du MCP, ni une plateforme de messagerie interactive.

L’Agent Card : la carte de visite de l’agent

L’Agent Card est le point de départ de toute interaction A2A. C’est un fichier JSON de métadonnées, publié à l’adresse /.well-known/agent-card.json (selon la convention RFC 8615; l’ancienne convention /.well-known/agent.json reste répandue), qui décrit l’agent de façon lisible par la machine.

Une Agent Card déclare :

• Les compétences (skills) de l’agent, avec leurs modes d’entrée et de sortie
• Les points d’entrée (endpoints) pour communiquer avec lui
• Les schémas d’authentification supportés
• Les capacités de tâches disponibles

Un agent qui souhaite en solliciter un autre commence par lire son Agent Card. Il sait alors ce que l’agent distant peut faire et comment l’appeler, avant même d’ouvrir une connexion. C’est le même principe de découverte que les Server Cards du MCP, appliqué aux agents.

Une interaction A2A enchaîne quatre étapes : lecture de l’Agent Card, ouverture d’une Task, échange de Messages multimodaux, puis renvoi d’un Artifact.

Tâches, messages et artefacts

Une fois la découverte faite, la collaboration s’organise autour de trois objets.

La Task (tâche) est l’unité de travail. Elle suit un cycle de vie défini : en attente, en cours, terminée ou échouée. Pour les opérations longues, l’agent client suit l’avancement en temps réel via un flux Server-Sent Events (SSE).

Le Message porte les échanges entre agents. Il se compose de Parts (parties) qui peuvent contenir du texte, des images, des données structurées ou d’autres formats. Le protocole est donc multimodal par conception.

L’Artifact est le conteneur de résultat. Un agent peut renvoyer un document, une image, du code exécutable ou un jeu de données structuré, avec des métadonnées sur le type de contenu et l’encodage.

Transport et authentification

A2A s’appuie sur des standards du web bien établis, ce qui facilite son adoption :

• JSON-RPC 2.0 sur HTTP/HTTPS pour les échanges requête-réponse
• Server-Sent Events (SSE) pour le streaming des mises à jour de progression
• Push notifications pour les tâches très longues ou asynchrones

Côté sécurité, A2A supporte OAuth 2.0, mutual TLS, tokens JWT, clés API et OpenID Connect, alignés sur les conventions OpenAPI. Cette compatibilité avec l’existant est un atout majeur pour les déploiements en entreprise, où l’identité et les permissions sont non négociables.

A2A vs MCP : deux protocoles complémentaires

A2A et MCP ne s’opposent pas : ils couvrent deux besoins différents. MCP standardise l’accès d’un agent à ses outils et données ; A2A standardise la communication entre agents autonomes. Le premier travaille en profondeur, le second en largeur.

Pour bien comprendre le MCP et son rôle, je vous renvoie à mon guide complet du Model Context Protocol, qui détaille l’architecture client-serveur, les serveurs MCP et la sécurité. Le tableau ci-dessous résume les différences essentielles entre les deux standards.

MCP donne à l’agent l’accès à ses outils (hub-and-spoke), A2A fait dialoguer les agents entre eux (pair-à-pair) : deux protocoles complémentaires réunis sous l’Agentic AI Foundation.

Critère	MCP (Model Context Protocol)	A2A (Agent-to-Agent)
Rôle	Connecter un agent à ses outils et données	Faire communiquer des agents entre eux
Modèle	Hub-and-spoke (agent au centre)	Pair-à-pair (agents égaux)
Question posée	« Comment j’accède à cet outil ? »	« Comment je délègue à cet agent ? »
Créateur	Anthropic	Google
Découverte	Server Card	Agent Card
Communication	Client vers serveur	Bidirectionnelle entre agents
Gouvernance	Agentic AI Foundation	Agentic AI Foundation (dès 2026)

L’exemple le plus parlant est celui d’un agent de support client. Cet agent utilise MCP pour accéder à sa base de connaissances, au système de tickets et à la base client. En parallèle, il utilise A2A pour coordonner des agents spécialisés qui gèrent les remboursements, les incidents techniques ou les litiges de facturation.

Autrement dit : MCP donne à un agent ses mains et ses yeux ; A2A lui donne des collègues. Un système multi-agents mature combine généralement les deux protocoles.

Ce que A2A change pour les architectures multi-agents

A2A transforme la question de la communication inter-agents, longtemps traitée par des mécanismes propriétaires. Jusqu’ici, chaque framework imposait sa propre manière de faire dialoguer les agents : mémoire partagée, passage de messages internes, état de graphe. Ces approches fonctionnent, mais elles enferment le système dans un seul écosystème.

C’est précisément l’une des erreurs que je décris dans mon guide des architectures multi-agents IA : négliger le protocole de communication entre agents est un facteur d’échec récurrent. A2A apporte une réponse standardisée à ce problème, en permettant des systèmes véritablement hétérogènes.

Trois changements concrets

L’interopérabilité entre fournisseurs. Un agent LangGraph, un agent CrewAI et un agent Semantic Kernel peuvent désormais collaborer sans intégration sur mesure. C’est la promesse la plus structurante d’A2A : composer une équipe d’agents issus de vendeurs différents.

La délégation sécurisée. Grâce au modèle des agents opaques et à l’authentification standard, un agent peut déléguer une tâche à un agent externe sans exposer sa logique ni ses données sensibles. Cela ouvre la porte à des collaborations entre organisations.

La découverte dynamique. Avec les Agent Cards, un orchestrateur peut découvrir les capacités d’un agent à la volée, plutôt que de tout câbler à l’avance. On passe d’architectures figées à des systèmes qui s’assemblent dynamiquement.

Les limites à garder en tête

Je reste mesuré sur la maturité du protocole. Début 2026, les déploiements A2A en production restaient limités, malgré le soutien de plus de 50 partenaires. L’implémentation la plus documentée passe par Semantic Kernel de Microsoft.

Le standard est jeune, l’outillage encore en construction, et l’interopérabilité réelle entre frameworks demande souvent des ajustements. A2A dessine la bonne direction, mais je recommande de le considérer comme une architecture cible plutôt que comme une solution clé en main pour un projet à livrer demain.

Mon avis sur le protocole A2A

A2A comble un vrai manque : jusqu’ici, aucun standard neutre ne définissait comment des agents IA de fournisseurs différents devaient se parler. Que des concurrents comme Google, Microsoft, AWS et Salesforce s’accordent sous l’égide de la Linux Foundation est le meilleur signal de sa pérennité.

Le duo A2A + MCP dessine l’infrastructure des systèmes multi-agents de demain : MCP pour l’accès aux outils, A2A pour la collaboration entre agents. C’est cohérent, et le fait que les deux protocoles rejoignent la même fondation en 2026 renforce cette vision unifiée.

Mon conseil : familiarisez-vous dès maintenant avec les concepts d’A2A (Agent Card, tâches, agents opaques), car ils structureront les architectures agentiques des prochaines années. Mais attendez que l’outillage mûrisse avant d’en faire le socle d’un projet critique. Pour l’instant, A2A est un standard à comprendre et à suivre de près, plus qu’à déployer en aveugle.