Protocole A2A : prévisions 2026–2028, qui suit et qui reste à l'écart

L'adoption d'A2A désigne la mesure dans laquelle le protocole Agent2Agent s'impose comme standard ouvert de communication entre agents IA autonomes. En 2026, A2A est placé sous l'égide de la Linux Foundation et porté par Google, Microsoft, AWS, Salesforce, SAP, ServiceNow et Cisco. Cet article analyse les moteurs, les freins et les scénarios d'adoption jusqu'en 2028, explicitement comme une prévision et non comme un fait établi.

Avertissement important : tout ce qui dépasse les faits vérifiables aujourd'hui (taux d'adoption, parts de marché, échéances d'une interopérabilité productive entre fournisseurs) relève d'une estimation assortie de marges d'incertitude importantes. Les prévisions sur l'IA à un horizon de 18 à 24 mois sont fragiles. Les directions structurelles sont plus fiables que les jalons précis.

Réponses rapides

• Qui suit ? Les grands fournisseurs de plateformes : Google (initiateur), Microsoft, AWS, Salesforce, SAP, ServiceNow et Cisco comme membres fondateurs. Au total, plus de 150 organisations soutiennent le standard (état en avril 2026). A2A est ainsi le quasi-standard de la collaboration entre agents de plateformes différentes.
• Qui ne suit pas (encore) pleinement ? OpenAI n'est pas membre fondateur. En août 2025, un mainteneur d'OpenAI a déclaré qu'il n'y avait pas de projet immédiat pour A2A dans l'Agents SDK. Au sein de l'Agentic AI Foundation, OpenAI est cofondateur et y a apporté AGENTS.md. Anthropic pousse avant tout MCP et se rapproche d'A2A via des modèles de passerelle. Même des membres fondateurs dotés d'un écosystème propre solide, comme Salesforce (Atlas) et Microsoft (handoffs de Copilot Studio), n'utilisent pour l'instant A2A qu'en périphérie et gardent l'orchestration interne pour eux.
• Quel est le plus grand risque ? La fragmentation par des extensions propriétaires d'AgentCard. Pas de guerre entre fournisseurs, plutôt une différenciation rampante au sein du standard.

Ce qu'est A2A et où il se situe dans la pile de protocoles

Le protocole Agent2Agent a été présenté par Google en avril 2025 lors de Cloud Next avec plus de 50 partenaires, puis donné à la Linux Foundation le 23 juin 2025 lors de l'Open Source Summit North America à Denver. Google a transmis la spécification, les SDK (Python, TypeScript) et l'outillage pour développeurs. Les membres fondateurs du projet de la Linux Foundation sont AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow.

Techniquement, A2A repose sur JSON-RPC 2.0 via HTTPS, avec du streaming par Server-Sent Events et des notifications push optionnelles pour les tâches de longue durée. Chaque agent publie une AgentCard, un document JSON indiquant son point de terminaison, ses capacités, les skills prises en charge, les modalités et les schémas d'authentification. Les tâches suivent un cycle de vie défini (submitted → working → input-required → completed | failed | canceled). L'étape conceptuelle décisive : la logique interne de l'agent distant reste opaque. A2A définit comment les agents se parlent, pas comment ils pensent. Un agent Salesforce peut ainsi appeler un agent SAP sans que l'un révèle à l'autre ses prompts, ses modèles ou sa mémoire.

A2A n'est pas seul. Avec MCP, il forme une pile convergente :

• MCP (Model Context Protocol, publié à l'origine par Anthropic en novembre 2024, donné le 9 décembre 2025 à l'Agentic AI Foundation sous l'égide de la Linux Foundation) régit la relation agent-outil.
• A2A régit la relation agent-agent.

La lecture officielle, défendue de manière constante par Google, Salesforce et Microsoft, est la suivante : « MCP pour les capacités, A2A pour la collaboration. » Les recommandations de Microsoft le formulent sans détour : MCP pour l'accès aux outils et aux données, Linux Foundation A2A pour la messagerie d'agent à agent entre plateformes.

Les moteurs institutionnels : pourquoi A2A bénéficie d'un vent porteur structurel

Le moteur le plus important est la gouvernance de la Linux Foundation. C'est la protection structurelle la plus forte qu'on puisse imaginer contre une guerre entre fournisseurs et contre un contrôle unilatéral. Le projet concurrent d'IBM, ACP, a fusionné avec A2A dès le 29 août 2025 sous LF AI & Data. L'équipe ACP a arrêté le développement actif et apporté sa technologie à A2A. Résultat : une pile de protocoles ouverts, réduite et cohérente, au lieu d'une guerre des standards.

Le deuxième moteur est l'ancrage dans les plateformes d'entreprise que les entreprises européennes exploitent déjà. A2A y est déjà, pour l'essentiel, une fonctionnalité produit (état en octobre 2026) :

• Salesforce Agentforce 360 utilise A2A comme handshake entre fournisseurs pour déléguer à des agents tiers, tandis que les transferts internes restent sur l'Atlas Reasoning Engine.
• SAP Joule reçoit un A2A bidirectionnel : les agents tiers pourront appeler les agents Joule et inversement. La disponibilité générale des fonctions A2A dans Joule est prévue au T4 2026. Les agents du nouveau Joule Studio, présenté par SAP lors de Sapphire 2026, doivent prendre en charge MCP et A2A nativement. Selon SAP, Anthropic Claude doit devenir une capacité principale de raisonnement et d'agents dans Joule.
• Microsoft Copilot Studio et Microsoft Foundry (anciennement Azure AI Foundry) ont intégré A2A.
• Google Gemini Enterprise, dans lequel Agentspace a été intégré en octobre 2025, connecte des agents externes via A2A.
• ServiceNow Now Assist utilise également A2A, et le runtime AWS Bedrock AgentCore héberge des serveurs A2A.

C'est un point central : les environnements SAP, Salesforce, Microsoft et ServiceNow sont les points d'entrée par lesquels les entreprises découvrent A2A.

Les freins : là où l'adoption coince vraiment

Frein 1 : la fragmentation par des extensions propriétaires. C'est le principal risque non résolu. La gouvernance protège le cœur, mais chaque membre fondateur (Salesforce, SAP, Microsoft, Google, AWS, ServiceNow, Cisco) a un intérêt commercial à se différencier par des extensions d'AgentCard, des états de tâche propres ou des capacités « A2A-plus ». Si les AgentCards deviennent spécifiques à chaque fournisseur, on perd précisément la portabilité qui justifie le choix du protocole. Le signal à surveiller en 2026 est donc concret : AgentCard restera-t-il un document JSON portable ou deviendra-t-il spécifique à chaque fournisseur ?

Frein 2 : la concurrence des écosystèmes propriétaires. Beaucoup de déploiements « multi-agents » ne sont en réalité qu'un seul agent doté de nombreuses intégrations d'outils. Nous appelons cela du multi-agent marketing. Ces systèmes n'ont pas du tout besoin d'A2A. Tant que l'orchestration interne (Salesforce Atlas, handoffs de Copilot Studio, SAP Joule en interne) reste propre à chaque plateforme et qu'A2A n'est utilisé qu'en périphérie, l'utilisation réelle d'A2A reste moins profonde que ne le suggèrent les annonces.

Frein 3 : des questions non résolues de gouvernance et de frontières de confiance. Chaque pair A2A est opaque pour les autres. C'est bon pour la confidentialité, mais compliqué pour les pistes d'audit, les frontières de confiance et, dans le contexte européen, pour la souveraineté des données. Lorsqu'un agent Salesforce appelle un agent SAP qui déclenche à son tour une étape de raisonnement Claude via A2A, le flux de données d'une seule tâche peut franchir plusieurs frontières de sous-traitants et de résidence des données. Au regard de l'art. 28 du RGPD, la chaîne de sous-traitance s'allonge d'autant. Si un saut transfère des données personnelles vers un pays tiers, les art. 44 à 49 du RGPD s'appliquent en plus : sans décision d'adéquation au titre de l'art. 45 pour le pays de destination, ce saut exige sa propre analyse des transferts. Les sauts au sein de l'UE et de l'EEE ne déclenchent aucune analyse des transferts. Cela freine l'adoption en production dans les secteurs réglementés.

Délimitation : MCP vs A2A, AGNTCY et NANDA

Une confusion fréquente consiste à voir A2A comme un concurrent de MCP, d'AGNTCY ou de NANDA. C'est faux. Les rôles sont clairement répartis :

• AGNTCY (Cisco, donné à la Linux Foundation le 29 juillet 2025) n'est pas un protocole concurrent, mais la couche d'identité, de découverte et d'observabilité au-dessus d'un maillage A2A. Les agents A2A et les serveurs MCP sont repérables via les annuaires AGNTCY.
• NANDA (MIT Media Lab) est surtout un projet de recherche : une vision à long terme d'une identité décentralisée des agents, et non un protocole utilisé en production dans les piles des entreprises européennes (état en 2026).

Notre analyse pour les décisions d'architecture en 2026 : MCP + A2A est la pile convergente du secteur. AGNTCY est le complément rationnel lorsque l'identité entre fournisseurs compte. NANDA a sa place dans la liste de veille, pas sur le chemin critique.

Paysage des acteurs : position et signal

Le tableau suivant est un instantané prospectif fondé sur les signaux documentés (état en 2026), et non une feuille de route garantie.

Scénarios d'ici 2028

Scénario A : convergence (direction la plus probable). MCP + A2A s'imposent comme un monde à deux protocoles. Un état propre à deux protocoles est selon nous la situation la plus probable en 2027. AgentCard reste portable ; AGNTCY prend en charge l'identité et l'observabilité là où la fédération entre fournisseurs compte. L'adoption progresse, portée par les environnements SAP, Salesforce et Microsoft.

Scénario B : fragmentation silencieuse. A2A reste formellement le standard, mais des extensions propriétaires d'AgentCard et des fonctions « A2A-plus » créent un verrouillage de fait. L'interopérabilité entre fournisseurs fonctionne en démo, mais pas en production sur plusieurs environnements de grands groupes. Une question ouverte départage A et B : SAP Joule, Agentforce et Copilot Studio livreront-ils d'ici fin 2026 un véritable A2A entre fournisseurs en production, ou le nombre de déploiements multi-agents en production dans tout le DAX 40 restera-t-il à un chiffre ?

Scénario C : domination des plateformes plutôt que du protocole. Si une ou deux plateformes d'hyperscalers rendent leur orchestration interne si dominante qu'A2A ne reste qu'une fonction marginale, l'importance stratégique du standard ouvert diminue. Moins probable compte tenu de la large coalition fondatrice, mais pas exclu.

Exemple concret : l'économie des sauts A2A dans un grand groupe européen

Un assureur exploite une architecture multi-agents hiérarchique, comme Allianz avec « Project Nemo » (sept agents spécialisés dans les sinistres liés à la perte de denrées alimentaires après des catastrophes naturelles, en production en Australie depuis juillet 2025, déployé en moins de 100 jours, avec une réduction documentée de 80 % du délai de traitement et de règlement pour les sinistres éligibles de perte de denrées inférieurs à 500 AUD, et un humain dans la boucle pour le paiement). Transposé à un cas multi-fournisseurs :

```
Demande client
→ Agent principal Agentforce (Salesforce, en interne Atlas)
→ Saut A2A 1 → Agent de couverture SAP Joule (frontière de sous-traitant + éventuel transfert transfrontalier)
→ Saut A2A 2 → Étape de raisonnement Claude (frontière de sous-traitant + éventuel transfert transfrontalier)
→ Agent d'audit (trace complète, un seul ID de trace pour tous les sauts)
→ Un humain décide du paiement
```

Chaque saut A2A qui transmet des données personnelles à un autre prestataire ajoute un maillon à la chaîne des contrats de sous-traitance. Si un saut mène en outre vers un pays tiers sans décision d'adéquation, il exige sa propre analyse des transferts. L'exemple ci-dessus comporte deux sauts : deux maillons supplémentaires dans la chaîne de sous-traitance et, si les deux mènent vers de tels pays tiers, deux analyses d'impact des transferts. Si tous les sous-traitants restent dans l'UE ou l'EEE, l'analyse des transferts tombe, mais la chaîne reste plus longue. Ce calcul passe facilement à la trappe dans la conception multi-agents. La conséquence opérationnelle : figer les versions des modèles dans les flux de production, journaliser tous les prompts des sous-agents, les appels d'outils et les AgentCards utilisées, et les corréler via un seul ID de trace.

Pour les agences et les décideurs B2B

Pour les décideurs B2B : considère A2A en 2026 comme un standard probable, mais pas garanti. La séquence par défaut la plus rationnelle consiste à standardiser la politique des serveurs MCP, à introduire A2A d'abord au sein d'un même environnement, à publier des AgentCards et seulement ensuite à étendre à un deuxième environnement. Inscris dans tes contrats d'achat la question suivante : le contrat Agentforce, Joule ou Copilot Studio garantit-il l'interopérabilité A2A et la conformité au standard MCP, et que se passe-t-il en cas de sortie ? Garde 15 à 25 % du budget IA en réserve, débloquée sur déclencheurs, pour les événements liés aux protocoles et aux fournisseurs.

Pour les agences marketing et IA, A2A est le principal levier de stratégie produit : publie une AgentCard pour chaque agent proposé comme produit, afin que les environnements de tes clients puissent appeler tes agents directement depuis Agentforce, Joule ou Copilot Studio, sans intégration sur mesure. Si tu rends tes agents découvrables via A2A dès le premier jour, tu ne restes pas éternellement coincé derrière une intégration spécifique.

Depuis Vienne, Blck Alpaca accompagne les entreprises de toute l'Europe précisément dans cet arbitrage : des architectures multi-agents souveraines et auditables fondées sur MCP et A2A, avec une séparation nette entre faits établis et estimations prospectives. Parle-nous avant de t'engager sur un outil 24 mois à l'avance. La direction est fixée, les détails bougent encore.