Protocole Agent-to-Agent (A2A)

Qu'est-ce que le protocole Agent-to-Agent (A2A) ?

Le protocole Agent-to-Agent (A2A) est un standard ouvert qui définit la manière dont des agents IA autonomes communiquent entre eux, par-delà les frontières entre processus, systèmes, plateformes et éditeurs. Alors qu'un agent isolé accède aux outils, aux données et aux systèmes externes via le Model Context Protocol (MCP), A2A régit la couche supérieure : la collaboration entre agents indépendants. L'apport conceptuel central d'A2A, c'est qu'il définit comment les agents se parlent, et non comment ils pensent. La logique interne d'un agent distant (prompts, modèle, mémoire) reste opaque. C'est précisément ce qui permet, par exemple, à un agent Salesforce d'appeler un agent SAP sans qu'aucune des deux parties ne dévoile ses structures internes.

A2A a été présenté en avril 2025 lors de Google Cloud Next avec plus de 50 partenaires et était d'abord piloté par Google. Dès le 23 juin 2025, Google a transmis la spécification, les SDK (Python, TypeScript) et l'outillage pour développeurs à la Linux Foundation. A2A n'est donc plus le standard d'un éditeur, mais un standard ouvert géré de manière neutre. C'est un argument de poids pour les décideurs qui évaluent l'indépendance vis-à-vis des plateformes sur le long terme.

Communication d'agent à agent : le cœur technique

A2A s'appuie délibérément sur des standards web éprouvés afin de limiter les obstacles pour les entreprises. Les briques principales :

• Transport. JSON-RPC 2.0 sur HTTPS. Le streaming passe par les Server-Sent Events (SSE) ; des notifications push optionnelles sont prévues pour les tâches de longue durée.
• Cycle de vie des tâches. Les tâches passent par des états définis : submitted → working → input-required → completed | failed | canceled. Ce cycle de vie explicite constitue le noyau contractuel entre deux agents ; il indique clairement quand un agent attend une précision (input-required) et quand un résultat est disponible.
• Messages et artefacts. A2A prend en charge des messages en plusieurs parties (texte et contenus multimodaux, par exemple des formulaires). Le résultat d'une tâche se compose d'un ou plusieurs artefacts.
• Trois modes d'interaction. Synchrone (requête/réponse unique), polling asynchrone ainsi que streaming/push pour les tâches de longue durée.

Cette architecture permet d'exposer vers l'extérieur un flux multi-agents interne (par exemple une orchestration LangGraph avec état persistant) sous la forme d'un endpoint A2A doté d'une AgentCard ; les couches interne et externe s'articulent proprement.

Agent Cards et découverte

Au cœur de la découvrabilité (discovery) dans A2A se trouve l'AgentCard. Chaque agent publie un document JSON qui décrit :

• l'endpoint par lequel l'agent est joignable,
• ses capacités (capabilities) et les skills qu'il prend en charge,
• les modalités (texte, formulaires, multimodal),
• les schémas d'authentification pris en charge.

Grâce à l'AgentCard, un agent appelant découvre ce que sait faire un autre agent et comment il peut s'adresser à lui, sans voir l'intérieur de son implémentation. En pratique, l'AgentCard est donc le levier décisif : si un fournisseur publie une AgentCard pour chacun de ses agents en production, les systèmes clients comme Salesforce Agentforce, SAP Joule ou Microsoft Copilot Studio peuvent appeler ces agents depuis leur propre environnement, sans devoir développer une intégration spécifique au client.

Un point reste ouvert pour 2026 : certains éditeurs ont un intérêt commercial à doter les AgentCards d'extensions propriétaires. Le signal clé à surveiller pour la portabilité d'A2A consiste donc à savoir si l'AgentCard reste un document JSON portable ou devient spécifique à chaque éditeur.

A2A vs MCP : complémentaires, pas concurrents

La question la plus fréquente des tech leads est : « A2A ou MCP ? » La réponse des fournisseurs de référence (Google, Salesforce, Microsoft, IBM) est claire et constante : les deux, pour des couches différentes. La formule officielle : « MCP sert aux capacités (agent-to-tool). A2A sert à la collaboration (agent-to-agent). » Les propres lignes directrices de Microsoft pour les systèmes multi-agents le formulent de manière opérationnelle : « Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging. »

MCP est parfois aussi utilisé pour la communication d'agent à agent, en exposant un agent comme « serveur » MCP doté de capacités sous forme d'outils. Cela fonctionne, mais ce n'est pas la vocation de MCP. Google et Microsoft recommandent A2A pour une véritable collaboration entre pairs. Dans la stack convergente de 2026, la règle est donc : MCP comme standard pour la couche outils, A2A comme standard pour la couche agents.

La Linux Foundation et la consolidation du paysage des protocoles

A2A est au centre d'un effort de standardisation remarquable. Lors du transfert à la Linux Foundation le 23 juin 2025 (Open Source Summit North America, Denver), AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow en étaient les membres fondateurs ; plus de 100 entreprises soutiennent aujourd'hui le protocole (source : Linux Foundation, 2025). Le dépôt et la documentation de référence se trouvent respectivement sous github.com/a2aproject/A2A et a2a-protocol.org.

Ce regroupement a consolidé un paysage de protocoles fragmenté :

• ACP → A2A. L'Agent Communication Protocol (ACP, mars 2025) d'IBM a été intégré à A2A le 29 août 2025 sous l'égide de LF AI & Data. Le blog officiel de la LF : « the ACP team is winding down active development and contributing its technology and expertise to A2A. » Les principes de conception d'ACP (REST, async-by-default) perdurent dans A2A.
• AGNTCY comme surcouche. Le projet AGNTCY de Cisco (donné à la Linux Foundation le 29 juillet 2025, avec Dell, Google Cloud, Oracle et Red Hat comme membres initiaux) ne concurrence pas A2A : c'est une couche au-dessus, dédiée à la découverte, à l'identité et à l'observabilité. L'Open Agent Schema Framework (OASF) accepte explicitement les AgentCards A2A et les descriptions de serveurs MCP comme formats d'entrée : « A2A agents and MCP servers are discoverable through AGNTCY directories. »
• NANDA, une vision de recherche. Le projet NANDA du MIT Media Lab s'appuie conceptuellement sur MCP et A2A, mais reste en 2026 essentiellement au stade de la recherche et ne constitue pas une base pour des décisions d'architecture en production.

L'état des lieux honnête en 2026 : MCP et A2A forment le standard convergent du secteur, AGNTCY est le complément rationnel là où l'identité inter-éditeurs compte, NANDA reste une vision à long terme.

A2A sur le terrain en Europe : plateformes et déploiements

Pour les entreprises en Europe, A2A est le protocole inter-agents qu'elles rencontrent le plus souvent, car leurs environnements Salesforce, SAP, Microsoft et ServiceNow existants en sont les points d'entrée. Exemples concrets :

• SAP Joule Studio 2.0 / Joule Work (Sapphire 2026, GA au T4 2026) : A2A bidirectionnel, de sorte que des agents tiers peuvent appeler nativement des agents Joule et inversement. Pour la région DACH (Allemagne, Autriche, Suisse), très marquée par SAP, c'est l'une des évolutions les plus importantes de 2026 en matière de plateformes multi-agents.
• Salesforce Agentforce 360 Multi-Agent Orchestration : A2A comme handshake inter-éditeurs pour déléguer à des agents tiers ; les transferts internes passent par l'Atlas Reasoning Engine.
• Microsoft Agent 365 / Copilot Studio : prise en charge d'A2A dans Work IQ depuis avril 2026.
• Google Gemini Enterprise (anciennement Agentspace) et ServiceNow Now Assist : respectivement A2A natif et A2A comme handshake inter-plateformes.

Conformité et audit (à titre informatif, sans valeur de conseil juridique)

Les remarques suivantes sont fournies à titre informatif et ne remplacent pas un conseil juridique. Les chaînes A2A ont des conséquences structurelles en matière de conformité, souvent négligées dans les architectures de référence centrées sur les États-Unis :

• Chaîne de sous-traitance RGPD (art. 28). Chaque fournisseur d'agents est potentiellement un sous-traitant ; le multi-agents allonge la chaîne de sous-traitance. Chaque saut A2A constitue potentiellement une relation de sous-traitance distincte, avec son propre contrat de sous-traitance.
• Transferts internationaux (art. 44–49). Dans une stack hybride Salesforce/SAP/Microsoft/Anthropic répartie sur des clouds américains et européens, chaque saut d'agent à agent qui transfère des données vers un pays tiers nécessite sa propre base juridique au titre du chapitre V du RGPD. Pour les destinataires américains certifiés dans le cadre de l'EU-US Data Privacy Framework, c'est la décision d'adéquation de la Commission européenne du 10 juillet 2023 (art. 45) qui s'applique. En l'absence de décision d'adéquation, tu as besoin de garanties appropriées au sens de l'art. 46, en pratique le plus souvent des clauses contractuelles types (CCT) accompagnées d'une analyse d'impact des transferts (Transfer Impact Assessment), et ce pour chaque saut séparément.
• Règlement européen sur l'IA (vue d'ensemble). Qui est fournisseur, qui est déployeur dans une composition A2A Salesforce → SAP → Anthropic ? La lecture prudente : chaque éditeur est fournisseur de son propre agent, l'organisation intégratrice est déployeur du système composé. En 2026, cette répartition n'est pas encore définitivement tranchée ; les affirmations en la matière sont à considérer comme provisoires jusqu'à ce que des actes d'exécution apportent de la clarté.
• Piste d'audit. Chaque message A2A peut être pertinent pour un audit. Il est recommandé de propager un identifiant de trace continu à travers chaque tâche A2A et chaque appel MCP, de figer les versions des modèles et de journaliser les AgentCards utilisées. L'auditabilité relève de la topologie des agents, pas seulement du pipeline de journalisation.

Allianz Project Nemo, en Australie, montre à quoi ressemble concrètement un agent d'audit dédié, même si l'utilisation d'A2A n'y est pas documentée publiquement. Il s'agit d'un système à sept agents hiérarchique (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) qu'Allianz Australie a lancé en juillet 2025 pour les sinistres liés à des denrées avariées après des coupures de courant dues aux intempéries. Il a été mis en production en moins de 100 jours et a permis une réduction de 80 % du temps de traitement et de règlement (source : Allianz, 2025). La décision de paiement revient toujours à un humain. Les assureurs en Europe peuvent reprendre ce modèle d'agent d'audit comme référence.

Perspectives et conseils pratiques

En 2026, A2A est passé d'un standard Google à un projet de la Linux Foundation géré de manière neutre vis-à-vis des éditeurs, avec plus de 100 soutiens. Sa garantie structurelle la plus solide, la gouvernance de la Linux Foundation, se heurte à des questions ouvertes : A2A parviendra-t-il à une véritable interopérabilité inter-éditeurs en production ou se fragmentera-t-il sous l'effet d'extensions propriétaires des AgentCards ? C'est le signal clé à surveiller au cours des prochains trimestres.

En pratique, la recommandation pragmatique est : MCP pour les outils, A2A pour les agents. Tout le reste constitue un écart délibéré par rapport à la stack convergente et doit être justifié. Si tu interviens comme fournisseur ou déployeur, tu devrais publier des AgentCards, car elles sont le contrat inter-systèmes qui détermine si un agent participe à l'écosystème d'entreprise de 2026. AGNTCY et NANDA méritent une place sur la liste de veille, mais n'ont pas leur place sur le chemin critique d'un programme multi-agents en 2026. La séquence d'adoption la plus judicieuse pour les grands groupes : standardiser d'abord la politique des serveurs MCP, puis introduire A2A au sein d'une plateforme, l'étendre ensuite à une deuxième, mettre en place un registre d'AgentCards et n'ajouter l'identité inter-éditeurs (AGNTCY) que lorsque le volume le justifie.