En bref
Le protocole Agent2Agent (A2A) standardise la communication directe entre agents IA indépendants. Annoncé par Google en avril 2025, il comble un angle mort que MCP (Model Context Protocol d’Anthropic) ne couvre pas : non plus la relation agent→outil, mais la relation agent→agent. Depuis juin 2025, A2A est gouverné par la Linux Foundation. En août 2025, le protocole concurrent ACP d’IBM y a fusionné, évitant une fragmentation du standard.
Pourquoi un protocole agent-to-agent ?
Imagine deux entreprises qui doivent collaborer sur un projet. Chacune a son intranet, ses formats de document, ses flux de validation. Sans courrier standardisé, chaque échange exige un connecteur dédié, refait à chaque évolution. Les agents IA sont dans la même situation : A2A joue le rôle du protocole postal universel — un format d’enveloppe, un cycle de vie de demande, une signature reconnue.
Deux agents construits sur des frameworks différents — LangGraph côté A, CrewAI côté B — ne parlent pas le même langage par défaut. Sans standard commun, chaque intégration inter-agents exige une couche de traduction ad hoc, non réutilisable et fragile dès que l’un des agents évolue. A2A fournit le contrat minimal : transport (HTTP/JSON-RPC 2.0), cycle de vie des tâches, découverte d’agents, et authentification déclarée.
En clair : MCP, c’est l’interface entre un agent et ses outils (calculatrice, base de données). A2A, c’est l’interface entre agents qui se sous-traitent du travail. Les deux sont complémentaires : un agent peut utiliser MCP en interne pour faire son boulot et A2A pour parler à un autre agent.
MCP ne résout pas ce problème. Il définit comment un agent interroge un outil ou une source
de données — périmètre d’un seul agent. A2A opère une couche au-dessus : un agent client
délègue une tâche à un agent serveur distant, qui peut lui-même utiliser MCP en interne pour
l’accomplir. Les deux protocoles sont conçus pour coexister, pas se remplacer. La documentation
officielle (a2a-protocol.org/topics/a2a-and-mcp/) et les analyses indépendantes (Auth0,
Composio, TrueFoundry) convergent sur cette position de complémentarité — sans contradiction
documentée entre les deux spécifications.
Architecture en trois briques
L’Agent Card est le point d’entrée de tout échange A2A. Chaque serveur publie un document JSON décrivant son identité, ses compétences (skills), son endpoint de service, et ses exigences d’authentification (OAuth 2.0, clés API via headers HTTP). En version 0.3, ces cartes peuvent être signées cryptographiquement — mesure qui adresse l’authenticité des agents mais pas l’ensemble des enjeux de compliance. La découverte peut se faire via URI normalisée (well-known), registre centralisé pour les déploiements enterprise, ou configuration directe pour les systèmes couplés.
La Task est l’unité de travail atomique. Elle porte un identifiant unique et passe par des
états explicites : submitted → working → input-required → completed → failed → canceled. Ce
cycle de vie stateful permet des workflows asynchrones et parallèles sans couplage temporel
entre les agents. Un contextId généré côté serveur regroupe les tâches liées et préserve le
contexte sur plusieurs échanges.
Les modes d’interaction sont au nombre de quatre, sélectionnés selon la contrainte de latence et de durée de la tâche :
- requête/réponse synchrone — opérations courtes, réponse complète en un échange
- polling asynchrone — client reçoit un accusé avec task ID, interroge jusqu’à completion
- Server-Sent Events (SSE) — connexion persistante pour résultats partiels en temps réel
- webhooks (push notifications) — serveur notifie une URL callback enregistrée par le client
Le client n’a pas besoin de connaître l’implémentation interne du serveur. Ce design délibérément opaque réduit les dépendances et permet l’évolution indépendante de chaque agent. Les outputs produits par un agent (Artifacts dans la terminologie A2A) sont composables en parties (texte, fichiers, JSON) et streamables de manière incrémentale via SSE.
En clair : trois pièces seulement à retenir. Une carte d’identité (Agent Card), une demande de service (Task) avec son cycle de vie soumis → en cours → terminé, et un choix de canal (synchrone, polling, streaming, webhook) selon que la tâche dure 2 secondes ou 2 heures.
| Mode d’interaction | Latence type | Quand l’utiliser |
|---|---|---|
| Requête/réponse synchrone | < 1 seconde | Lookup simple, tâche courte (recherche, calcul). |
| Polling asynchrone | Quelques secondes à minutes | Tâche moyenne, le client peut interroger périodiquement. |
| Server-Sent Events (SSE) | Streaming continu | Génération longue avec résultats partiels (rédaction, analyse). |
| Webhooks | Plusieurs heures à jours | Tâche très longue, le serveur rappelle quand c’est fini. |
Chronologie et gouvernance
Google annonce A2A le 9 avril 2025 avec 50+ partenaires au lancement : Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, Workday. À Google I/O 2025 (mai), la version 0.2 paraît avec un SDK Python officiel et un support d’authentification de style OpenAPI. L’Agent Development Kit (ADK) de Google intègre A2A nativement — Python ADK v1.0.0 déclaré production-ready à cette occasion.
En juin 2025, Google transfère le protocole à la Linux Foundation lors de l’Open Source Summit North America. Le Technical Steering Committee inclut IBM, Google, Microsoft, AWS, Cisco, Salesforce et SAP. En août 2025, le protocole ACP d’IBM (BeeAI), architecturalement similaire (JSON-RPC over HTTP/WebSockets, plan de contrôle dédié pour la découverte dynamique), fusionne officiellement dans A2A. [NON VÉRIFIÉ : influence architecturale concrète des contributions IBM sur la spécification A2A post-fusion — pas de source documentant les deltas]
La version 0.3 ajoute le support gRPC en complément de SSE, la signature cryptographique des Agent Cards, et un client SDK étendu. Anthropic n’est pas membre du TSC A2A. [NON VÉRIFIÉ]
Sécurité : les déficits documentés
Deux papiers arXiv (2505.12490, 2505.02279) et le threat modeling de la Cloud Security Alliance (framework MAESTRO, avril 2025) identifient des vulnérabilités structurelles.
Injection de prompt : les endpoints A2A exposés à Internet sont vulnérables si les implémentations ne traitent pas les inputs comme non fiables. Le fait que les clients attendus soient eux-mêmes des LLM aggrave le risque — les modèles sont susceptibles de suivre des instructions injectées dans les messages reçus d’agents distants.
Credentials de longue durée : faiblesse systémique dans les architectures distribuées. Un token long-lived compromis ouvre des accès non autorisés entre agents. La signature des Agent Cards en v0.3 réduit partiellement la surface d’attaque sans couvrir ce vecteur.
Compliance : [NON VÉRIFIÉ — source unique] A2A v0.3 ne fournirait pas nativement de mécanismes pour des régulations comme PSD2 : pas de transaction logging natif, pas de consent auditing. Les flows OAuth2/OIDC concrets dans A2A ne sont pas détaillés dans les sources secondaires disponibles.
En clair : A2A pose le standard de communication, pas la sécurité des agents. Si tu déploies un agent A2A exposé à Internet, tu hérites des mêmes risques qu’une API publique — injection, credentials volés, abus — avec en plus la spécificité que le client est un autre LLM qui peut être manipulé via prompt injection.
Limites de l’adoption actuelle
Les exemples documentés dans la littérature se concentrent sur les démos Google (codelabs, ADK) et les systèmes d’information boursière. Les implémentations tierces (LangChain, ServiceNow, Salesforce) citées comme partenaires ne sont pas détaillées dans les sources collectées. La stabilité à grande échelle en production reste non testée (arXiv:2505.02279).
[NON VÉRIFIÉ — source unique] : “il n’existe pas beaucoup d’implémentations A2A en production actuellement” et “A2A bénéficie probablement davantage aux agrégateurs et fournisseurs de modèles de base qu’aux applications SaaS individuelles.”
Un protocole concurrent, ANP (Agent Network Protocol), est cité dans arXiv:2505.02279 mais n’est pas couvert par les sources disponibles — son positionnement par rapport à A2A reste non documenté. [NON VÉRIFIÉ]
Ce qu’il faut retenir
A2A standardise la couche de communication que MCP ne couvre pas : la délégation directe de tâches entre agents IA hétérogènes, sur des frameworks et des serveurs distincts. Le protocole repose sur HTTP/JSON-RPC 2.0, publie l’identité des agents via des Agent Cards, et supporte quatre modes d’interaction adaptés à des contraintes de latence variées. La gouvernance Linux Foundation et la fusion avec ACP d’IBM réduisent le risque de fragmentation du standard — les acteurs majeurs (Google, IBM, Microsoft, AWS, Cisco) siègent au même TSC.
Les points de vigilance restent : la sécurité des endpoints exposés à l’injection de prompt, les credentials de longue durée dans les architectures distribuées, et l’absence de retours d’expérience sur des déploiements en production à grande échelle hors des démonstrations officielles Google.