A2A (Agent2Agent) : comment les agents IA communiquent entre eux

« Quand un agent Salesforce Agentforce délègue une escalade au service IT à un agent ServiceNow ITSM, sans code custom, sans intégration spécifique : c’est A2A en production. » En avril 2026, 150+ organisations utilisent le protocole A2A en production, dont Salesforce, SAP, ServiceNow, AWS, Microsoft, IBM et Deutsche Bank. Le protocole a été lancé par Google il y a tout juste un an, transféré à la Linux Foundation en juin 2025, et constitue désormais le standard de fait pour la communication inter-agents en entreprise.

Pourtant, beaucoup d’organisations qui industrialisent leurs agents IA confondent encore A2A avec MCP, ou pensent que c’est un « truc Google ». Cet article clarifie tout : à quoi sert A2A, comment ça fonctionne techniquement, pourquoi votre cabinet de conseil ou votre éditeur SaaS doit s’en soucier dès aujourd’hui.

Cet article approfondit le pilier MCP, A2A, function calling, RAG : architecture des agents IA expliquée et complète notre guide sur MCP.

En bref

• A2A (Agent2Agent) est un protocole open-source pour faire communiquer des agents IA entre eux, indépendamment du framework ou du fournisseur sous-jacent.
• Lancé par Google le 9 avril 2025, transféré à la Linux Foundation en juin 2025, version 1.2 stable en avril 2026.
• 150+ organisations en production : AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow, Deutsche Bank.
• Complémentaire à MCP, pas concurrent : MCP connecte les agents aux outils, A2A connecte les agents entre eux.
• Architecture client-remote basée sur JSON-RPC 2.0, avec Agent Cards comme document de découverte.
• Support natif intégré dans Google ADK, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, AutoGen.
• Pour structurer votre stratégie multi-agents A2A en entreprise, Proactive Academy propose une formation aux agents IA et protocoles d’interopérabilité.

Pourquoi votre cabinet de conseil ou éditeur SaaS doit s’intéresser à A2A

Pour comprendre pourquoi A2A compte, regardons un cas concret qui touche les éditeurs et cabinets de conseil.

Le cas Salesforce ↔ ServiceNow ↔ Workday

Imaginez un workflow client critique pour vos comptes ETI : un employé signale un problème technique via Salesforce Service Cloud. Le ticket doit être pris en charge par un technicien ServiceNow, qui constate qu’il faut commander un nouvel équipement, et qu’une demande d’achat doit être créée dans Workday.

Avant A2A, ce workflow nécessitait 3 intégrations point-à-point (Salesforce ↔ ServiceNow, ServiceNow ↔ Workday, Salesforce ↔ Workday) avec du code custom à maintenir, des API spécifiques à chaque éditeur, des risques de désynchronisation, et des semaines de développement.

Avec A2A, les agents IA des trois plateformes se parlent via un protocole standard. Pas de glue code. Pas de connecteurs sur mesure. Le ticket est créé, qualifié, routé, équipé et clos en autonomie inter-agents.

Pourquoi c’est structurant pour les éditeurs SaaS multi-clients

Pour un cabinet de conseil ou un éditeur SaaS qui sert des dizaines de clients, chaque client a sa propre stack. Certains sont sur Salesforce, d’autres sur HubSpot. Certains sur ServiceNow, d’autres sur Jira. Certains sur Workday, d’autres sur SAP SuccessFactors.

Construire des intégrations spécifiques à chaque stack est insoutenable financièrement. A2A change ça : si vos agents respectent le protocole, ils communiquent avec n’importe quel agent compliant chez vos clients, sans intégration sur mesure.

Selon Salesforce officiel : « Custom integrations can bridge the gap, but they don’t scale cleanly across systems. A2A gives agents a common way to interact ». L’éditeur a parfaitement résumé l’enjeu.

L’origine du protocole et son adoption en 12 mois

A2A a été annoncé par Google le 9 avril 2025 au Google Cloud Next. Selon Google Developers Blog : « Today, we’re launching a new, open protocol called Agent2Agent (A2A), with support and contributions from more than 50 technology partners ».

Une trajectoire exceptionnelle

Selon le communiqué officiel Linux Foundation du 9 avril 2026 :

• 50 partenaires au lancement (avril 2025)
• Transfert à la Linux Foundation en juin 2025
• 22 000+ stars GitHub sur le dépôt officiel
• 5 SDK production-ready : Python, JavaScript, Java, Go, .NET
• A2A v1.0 stable en cours 2025 puis v1.2 en avril 2026
• 150+ organisations en production en avril 2026

Trois grandes plateformes cloud ont intégré A2A nativement : Azure AI Foundry (Microsoft), Amazon Bedrock AgentCore (AWS) et Google Cloud (Vertex AI / Gemini Enterprise Agent Platform).

Les frameworks agentiques compatibles nativement

Selon TheNextWeb (avril 2026), le support A2A est désormais embarqué dans :

• Google ADK (Agent Development Kit) v1.0 stable
• LangGraph (LangChain)
• CrewAI
• LlamaIndex Agents
• Microsoft Semantic Kernel
• AutoGen

Pour les équipes qui choisissent un de ces frameworks, A2A est natif : pas de code supplémentaire pour exposer ou consommer des agents A2A.

L’architecture technique : client-remote, Agent Cards, tasks

L’architecture A2A est volontairement minimaliste. Trois concepts suffisent : client-remote, Agent Cards, tasks.

Le modèle client-remote

Selon la spécification officielle A2A, le protocole définit deux rôles :

• Client agent : agent qui identifie une tâche à déléguer et envoie la requête
• Remote agent : agent qui reçoit la tâche, l’exécute et retourne les résultats

Concrètement, un agent peut être les deux selon le contexte. Un agent Salesforce qui délègue une tâche IT à ServiceNow est client pour cette tâche. Mais il devient remote quand un autre agent lui délègue une qualification de lead.

Selon Salesforce : « Its internal logic remains opaque ; the protocol defines how agents communicate, not how they think ». C’est essentiel : aucun agent ne doit exposer sa logique interne pour collaborer.

Les Agent Cards : la carte d’identité d’un agent

Chaque agent A2A publie un Agent Card à l’URL standard /.well-known/agent.json (ou agent-card.json selon les versions). C’est un document JSON qui décrit :

• Name et description : ce que l’agent fait, en langage humain
• Capabilities / skills : quels types de tâches l’agent peut accepter
• Endpoint URL : où envoyer les requêtes
• Authentication : méthodes supportées (OAuth, API keys, mTLS)
• Modalities : formats d’entrée et de sortie supportés

Selon RapidClaw (mai 2026) : « Agent Card — a JSON document served at /.well-known/agent.json describing skills, inputs, outputs, auth, and SLAs ».

Innovation A2A v1.2 : les Signed Agent Cards avec signatures cryptographiques pour vérification d’identité. Cela résout un problème de confiance majeur : comment vérifier qu’un Agent Card est bien émis par l’organisation qui prétend l’émettre.

Les tasks : unité de travail avec cycle de vie

Une task A2A comprend :

• Un goal (objectif clair en langage naturel)
• Une thread de messages (échanges entre client et remote)
• Des artifacts typés (résultats produits par le remote agent)
• Un cycle de vie défini : pending → in-progress → completed / failed / canceled

Le client peut suivre l’évolution en temps réel via Server-Sent Events (SSE), ce qui permet des tâches longues (recherche profonde, analyse multi-étapes sur plusieurs heures).

Le transport : JSON-RPC 2.0 sur HTTPS

A2A utilise JSON-RPC 2.0 comme format de message, transporté sur HTTPS. Selon Galileo : « A2A est construit sur des technologies web familières (HTTP/HTTPS, JSON-RPC 2.0) ». C’est volontaire — l’objectif est d’utiliser les standards web déjà maîtrisés par les équipes IT (sécurité, monitoring, observabilité).

A2A vs MCP : la complémentarité, pas la concurrence

C’est la confusion la plus fréquente. Levons-la clairement.

Le pitch officiel Google

Selon Google Developers Blog : « A2A is an open protocol that complements Anthropic’s Model Context Protocol (MCP), which provides helpful tools and context to agents ».

MCP et A2A résolvent deux problèmes distincts :

La règle qui aide à choisir

Selon DEV Community (avril 2026) : « In practice, MCP and A2A are used together. Individual agents access their tools and data via MCP, while task delegation and result sharing between agents happens through A2A ».

Concrètement, dans une architecture moderne :

• L’agent Salesforce utilise MCP pour accéder à ses tools Salesforce internes
• L’agent ServiceNow utilise MCP pour accéder à ses tools ServiceNow internes
• Les deux agents se parlent via A2A pour coordonner leurs actions

Les deux protocoles, ensemble, forment la stack d’interopérabilité agents IA de 2026.

Trois patterns d’usage A2A en cabinet de conseil et éditeur SaaS

Pour un cabinet de conseil ou un éditeur SaaS multi-clients, A2A débloque des cas d’usage qui étaient économiquement non viables avant 2025.

Pattern 1 : Délégation cross-platform

Selon Atlan (avril 2026) : « A high-level orchestrator agent breaks a complex request into sub-tasks and delegates each to the most capable specialized agent, regardless of which vendor built it ».

Cas type pour un cabinet de conseil :

• Vous développez un agent orchestrateur pour vos consultants
• Cet agent délègue à un agent Microsoft 365 pour les documents
• Au agent Salesforce pour le CRM client
• Au agent ServiceNow pour les tickets internes

Chacun de ces agents existe déjà chez l’éditeur. Vous n’avez rien à intégrer côté éditeur, vous orchestrez via A2A.

Pattern 2 : Marketplace d’agents pour vos clients

Si vous êtes un éditeur SaaS, A2A vous permet de proposer votre agent comme service interopérable dans les architectures multi-agents de vos clients.

Concrètement : votre agent expose son Agent Card public. N’importe quel client peut le découvrir et le brancher dans son orchestrateur A2A. Votre offre devient nativement compatible avec Salesforce Agentforce, Microsoft Copilot, Google Vertex AI, etc.

Pour les éditeurs B2B, c’est un changement structurel : votre roadmap d’intégrations passe de N intégrations à construire à 1 protocole à respecter.

Pattern 3 : Coordination multi-tenant pour services managés

Pour les MSP (Managed Service Providers) qui gèrent des dizaines de clients : A2A permet à votre agent superviseur de coordonner des actions sur les stacks de chaque client sans avoir à connaître les détails internes.

Votre agent envoie des tâches A2A vers les agents installés chez vos clients. Chaque agent client traite la tâche dans son contexte, retourne les résultats, sans exposer la logique métier interne. Vous gardez la coordination centralisée, vos clients gardent leur souveraineté.

Sécurité et gouvernance A2A en 2026

Authentification : du basique à la cryptographie avancée

A2A supporte plusieurs mécanismes d’authentification, du plus simple au plus renforcé :

• API Keys : pour les cas simples avec confiance entre parties
• OAuth 2.0 : pour les contextes utilisateur-final avec autorisation
• mTLS (mutual TLS) : pour les communications service-à-service à haute sécurité

Selon Galileo (janvier 2026) : « A2A est conçu pour supporter l’authentification enterprise-grade et l’autorisation, avec parité avec les schémas d’authentification d’OpenAPI ».

Signed Agent Cards : la nouveauté A2A v1.2

Les Signed Agent Cards résolvent un problème de confiance critique. Selon Linux Foundation (avril 2026) : « Features include Signed Agent Cards for cryptographic identity verification ».

Avant Signed Agent Cards : vous ne pouviez pas vérifier qu’un Agent Card prétendant venir de Salesforce était bien émis par Salesforce. Maintenant : signature cryptographique, vérification d’identité de domaine, traçabilité.

AP2 : l’extension paiements

Selon Linux Foundation : « The introduction of the Agent Payments Protocol (AP2) enables secure, agent-driven transactions, with more than 60 organizations across payments and financial services already supporting the initiative ».

AP2 étend A2A pour les transactions financières inter-agents, avec preuve cryptographique du consentement utilisateur. C’est l’évolution majeure pour les cas d’usage e-commerce, paiement B2B et finance régulée.

Gouvernance d’entreprise

Pour une organisation qui déploie A2A en production, 5 bonnes pratiques :

• Catalogue interne des Agent Cards autorisés : pas tous les agents publics auto-discoverable
• Audit logging sur toutes les invocations A2A inter-agents
• Allow-list par client agent : qui peut appeler quoi
• Monitoring de latence et taux d’échec par couple client-remote
• Versioning explicite des Agent Cards avec migration path

Comment démarrer A2A dans votre organisation

Trois scénarios selon votre profil et votre maturité.

Scénario 1 : éditeur SaaS qui veut exposer ses agents

Étape 1 : auditer votre architecture agents actuelle. Combien d’agents en production, quels frameworks, quelles APIs externes ?

Étape 2 : choisir un framework A2A-natif (Google ADK, LangGraph, CrewAI…). Si vous démarrez avec vos agents, choisissez nativement compatible.

Étape 3 : publier les Agent Cards de vos agents principaux. Documenter capabilities, auth, modalities.

Étape 4 : promouvoir auprès de vos clients. « Nos agents sont nativement compatibles A2A » devient un argument commercial différenciant.

Coût type : 15-40 K€ pour exposer 3-5 agents avec gouvernance correcte. ROI : élimination des intégrations sur mesure côté éditeur.

Scénario 2 : cabinet de conseil qui orchestre du multi-éditeur

Étape 1 : cartographier la stack de vos clients prioritaires. Quels éditeurs A2A-compatibles utilisent-ils ?

Étape 2 : développer un agent orchestrateur central dans votre framework de choix (ADK, LangGraph…).

Étape 3 : connecter votre orchestrateur aux Agent Cards de vos clients via A2A. Bénéfice immédiat : workflows transverses sans intégration custom.

Étape 4 : capitaliser sur l’expertise A2A comme service à valeur ajoutée.

Coût type : 30-80 K€ pour mettre en place l’orchestrateur initial. ROI : réduction massive du coût de mise en place de workflows transverses.

Scénario 3 : grand groupe avec dizaines d’agents internes

Étape 1 : auditer les agents internes existants. Lesquels sont déjà A2A-compatibles ? Lesquels doivent être upgradés ?

Étape 2 : choisir une plateforme A2A (Azure AI Foundry, Amazon Bedrock AgentCore, Google Vertex AI / Gemini Enterprise) ou self-host avec Google ADK.

Étape 3 : exposer les Agent Cards en interne dans un catalogue gouverné.

Étape 4 : industrialiser sur 6-12 mois avec gouvernance d’entreprise (allow-lists, audit, monitoring).

Coût type : 100-300 K€ pour une stack A2A d’entreprise complète sur 12 mois.

Les vraies limites de A2A en 2026

Soyons honnête sur ce que A2A ne fait pas encore.

Limite 1 : maturité de l’écosystème français

L’adoption A2A est forte chez les éditeurs US (Salesforce, ServiceNow, Workday, Microsoft). Côté français et européen, c’est plus parcellaire. Mistral, Dust et les acteurs français ont commencé à adopter A2A mais ne sont pas encore au niveau d’intégration native de Salesforce.

Limite 2 : pas de couche sémantique partagée

Selon Atlan : « A2A standardizes how agents communicate and delegate tasks. It does not govern what agents know ».

Si vos agents Salesforce et ServiceNow ont des définitions différentes de « client actif » ou « ticket prioritaire », A2A ne résoudra pas vos contradictions sémantiques. Il faut une couche sémantique partagée (catalogue de données, ontologie, glossaire) au-dessus du protocole.

Limite 3 : overhead réseau et latence

Chaque communication A2A est un appel HTTP. Pour des workflows à très faible latence (temps réel), cet overhead peut être significatif. Pour 95% des cas business B2B, c’est négligeable (centaines de millisecondes). Pour 5% de cas critiques (trading, gaming, contrôle industriel), benchmarker avant.

Limite 4 : courbe d’apprentissage

A2A demande de comprendre : architecture client-remote, Agent Cards, tasks, JSON-RPC, SSE, mécanismes d’auth. Comptez 5-7 jours de montée en compétence pour un développeur senior. Plus si l’équipe découvre les agents IA en même temps.

Limite 5 : versioning et migration

Le protocole évolue. Breaking changes possibles entre versions majeures. Pinning de version + roadmap de migration trimestrielle recommandés en production, comme pour MCP.

Comment former vos équipes à A2A

L’investissement formation A2A est plus court que sur les frameworks complets, car le protocole est volontairement minimaliste.

Le tech lead ou architecte solutions doit maîtriser le client-remote model, la conception d’Agent Cards, l’intégration avec un framework A2A-natif (ADK, LangGraph, CrewAI), la gouvernance et la sécurité. Comptez 3-5 jours de formation.

Le développeur doit savoir exposer un agent A2A, le consommer depuis un autre agent, gérer les tasks longues avec SSE, implémenter l’auth. Comptez 2-3 jours de formation.

Le DSI ou Chief Data & AI Officer doit comprendre la stratégie multi-agents A2A, l’arbitrage build vs buy vs partner sur les agents A2A-compatibles, la gouvernance des Agent Cards en interne. Comptez 1 jour d’atelier stratégique.

C’est le périmètre de notre parcours formation aux agents IA et protocoles d’interopérabilité pour entreprises, avec adaptation sectorielle.

FAQ : A2A en entreprise

A2A est devenu en 12 mois la couche d’interopérabilité standard des agents IA en entreprise. Pour les cabinets de conseil et éditeurs SaaS qui servent plusieurs clients, c’est une opportunité structurelle : votre offre devient nativement compatible avec les agents Salesforce, ServiceNow, Microsoft, Workday et autres sans intégration sur mesure. Pour les grands groupes qui déploient des dizaines d’agents internes, c’est le protocole qui rend la coordination multi-agents économiquement viable. Le standard est posé, l’écosystème accélère, les évolutions seront incrémentales. Pour structurer cette transformation dans votre organisation, maîtriser les enjeux des agents IA en formation Qualiopi avec Proactive Academy reste le moyen le plus direct de passer de l’intention stratégique à l’architecture qui scale.