Lors du Google Cloud Next 2026, le 22 avril, Google a mis en production la version 1.2 du protocole Agent2Agent (A2A) en tant que projet de la Linux Foundation. 150 organisations utilisent déjà A2A en production, dont Microsoft, AWS, Salesforce, SAP et ServiceNow. Le support natif existe dans Google Agent Development Kit, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel et AutoGen. Pour les architectes cloud de la région DACH (Allemagne, Autriche, Suisse), une question se pose désormais de manière concrète, alors qu’elle n’était que théorique depuis l’annonce initiale d’A2A l’année dernière : A2A nécessite-t-il une couche d’infrastructure dédiée en plus du service mesh existant, ou peut-il s’intégrer dans le modèle sidecar actuel ?

Ce qu’est réellement A2A sur le plan technique

Qu’est-ce que le protocole Agent2Agent (A2A) ? A2A est un protocole d’application ouvert basé sur HTTP/JSON pour la communication entre agents d’IA autonomes de différents fournisseurs. Il définit des standards pour les Agent-Cards (métadonnées, capacités, points de terminaison), la délégation de tâches, le retour de résultats et la vérification de signature. A2A 1.2 introduit des Agent-Cards signées cryptographiquement avec liaison de domaine, permettant à un agent Salesforce de reconnaître authentiquement un agent Google Vertex sans que les deux systèmes se connaissent en interne. Le protocole est sous l’égide de la Linux Foundation Agentic AI Foundation depuis Cloud Next 2026.

La caractéristique architecturale décisive : A2A fonctionne au niveau 7, soit au-dessus de la couche Service-Mesh. Une configuration Istio classique (mTLS, Envoy-Sidecar, Control-Plane) reste entièrement intacte. A2A utilise la connexion TLS fournie par le mesh ; sur celle-ci repose sa propre chaîne de signature. Ceux qui voient A2A comme un concurrent du Service-Mesh interprètent mal le protocole. A2A est une abstraction de la couche Application pour l’interopérabilité des agents, et non une alternative à la couche Transport.

Un bref aperçu des notes de version d’A2A 1.2 : les Agent-Cards signées contiennent un Agent-DID (Decentralized Identifier) avec liaison au domaine. La chaîne de signature est validée via des enregistrements DNS-TXT ou par un Well-Known-Endpoint. En pratique, cela signifie qu’un agent A2A propre doit fournir une Agent-Card accessible publiquement, dont la signature est contresignée avec une clé de domaine. Ceux qui utilisent DNSSEC et un Well-Known-Endpoint ont déjà la condition technique dans leur standard interne.

La différence avec MCP, souvent négligée par les architectes

Le Model Context Protocol (MCP) d’Anthropic, établi depuis 2024, décrit l’interface entre un agent unique et des outils ou sources de données externes. A2A, en revanche, régit la communication entre deux agents, même au-delà des frontières de plateformes et d’organisations. Un scénario typique : un agent Salesforce sur Agentforce reçoit une tâche d’un agent Vertex AI via A2A, interroge un outil CRM interne via MCP, et renvoie le résultat via A2A. Les deux protocoles se complètent. Planifier l’un sans l’autre entraîne des coûts d’intégration inutiles.

Trois chiffres pour comprendre

Toute bonne architecture web peut être esquissée sur un Post-It. Sinon, c’est qu’il y a trop d’abstraction. A2A fait partie de cette esquisse en tant que couche fine au-dessus du Mesh, pas en tant que second Mesh à côté.

Intégration dans un service mesh existant : trois décisions architecturales

La question pratique qui domine actuellement l’agenda des discussions d’architecture dans les pays DACH (Allemagne, Autriche, Suisse) est la suivante : comment intégrer A2A dans un setup Istio ou Linkerd existant sans compromettre le design du mesh ? Trois décisions concrètes sont à prendre.

Décision 1 : Séparer le service Agent-Card ou l’intégrer dans la découverte existante

A2A nécessite un endpoint Agent-Card accessible pour chaque agent publié. Deux modèles se sont établis depuis la version 1.0. Premièrement, un service Agent-Card dédié en tant que déploiement distinct derrière l’Ingress, avec son propre cache et sa propre politique de limitation de débit. Deuxièmement, l’intégration de l’Agent-Card dans la découverte de service existante (Consul, Istio Workload Entries), où la carte est traitée comme un attribut de métadonnées. Notre expérience montre que le service séparé est plus propre à exploiter et à auditer, car il isole les modèles d’accès. Pour une introduction en greenfield, nous recommandons le service séparé ; pour un brownfield avec une forte présence de Consul, la solution de métadonnées suffit.

Décision 2 : Validation de la signature dans le sidecar ou dans le runtime de l’agent

A2A 1.2 introduit des Agent-Cards signées cryptographiquement. La validation de la signature peut se faire soit dans le sidecar Envoy via un filtre Lua ou un plugin WASM, soit directement dans le runtime de l’agent via le SDK officiel de l’agent. Pour les setups à haut débit (plus de 200 appels d’agent par seconde par service), nous recommandons la variante sidecar, car elle gère uniformément le cache et les listes de révocation. Pour les setups expérimentaux et de taille moyenne, la variante runtime est plus simple et plus rapide à déployer. Important : ceux qui choisissent la validation sidecar doivent synchroniser l’Agent-Card CRL (Certificate Revocation List) avec le cycle de mise à jour du mesh. Sinon, les cartes révoquées peuvent être retardées dans le système, ce qui fausse les pistes d’audit.

Décision 3 : Piste d’audit de délégation dans SIEM ou dédiée

La délégation d’agent à agent génère une piste d’audit qui n’est pas entièrement visible dans les journaux d’accès Istio classiques. Pour les exigences de conformité (DORA, NIS2, EU AI Act), la piste de délégation est un artefact d’audit séparé : quel agent a délégué quelle tâche à quel autre agent, avec quelle justification, quel résultat, quelle durée d’exécution. Nous observons deux modèles dans la pratique. Premièrement, l’exportation vers le SIEM via une pipeline d’événements A2A dédiée (topic Kafka plus parser). Deuxièmement, un outil d’observabilité des agents dédié (Arize, Helicone, LangSmith). Pour les secteurs réglementés, l’exportation vers le SIEM est souvent obligatoire, l’outil d’observabilité fonctionne en parallèle pour l’analyse des performances. Les deux ensemble coûtent réalistement entre 15 000 et 35 000 euros par an pour une PME, en fonction du volume de transactions.

Ce que cela signifie pour la feuille de route architecturale

Pour les architectes de la région DACH (Allemagne, Autriche, Suisse), les trois décisions entraînent une feuille de route concrète de huit à douze semaines. Semaines une à trois : Inventaire des agents existants et identification des premiers cas d’utilisation d’intégration (souvent un agent d’assistance plus un agent système). Semaines quatre à six : Service de carte d’agent en tant que déploiement séparé, configuration d’enregistrement DNS-TXT pour la chaîne de signature, intégration du SDK dans l’agent cible. Semaines sept à neuf : Activation de la validation Sidecar ou Runtime, tests de charge, pipeline d’observabilité. Semaines dix à douze : Export SIEM, revue des pistes d’audit, mise en production. Ceux qui terminent plus tôt ont soit un cas d’utilisation très simple, soit des compromis dans la documentation de conformité.

Ce qui change réellement dans le quotidien de Mesh-Ops

La question opérationnelle la plus passionnante pour les architectes cloud de la région DACH n’est pas « ai-je besoin d’A2A ? », mais « que change l’introduction d’A2A dans la réalité opérationnelle de mon Mesh ? ». Trois observations issues des premiers projets d’intégration. Premièrement, la latence du plan de contrôle augmente légèrement (trois à sept pour cent), car la validation de la signature produit des écritures de cache supplémentaires. Deuxièmement, les plugins Envoy-WASM nécessitent plus de revues que les filtres Lua classiques, car la sémantique A2A est complexe et les corrections de bugs peuvent prendre deux à trois jours. Troisièmement, l’équipe d’observabilité reçoit une nouvelle classe d’événements (événements de délégation d’agent) qui doit être intégrée dans les tableaux de bord existants. Ceux qui ne planifient pas cela de manière proactive se retrouvent avec deux interfaces d’observabilité parallèles.

Une recommandation concrète des revues : exploitez la première production A2A en mode Shadow pendant au moins trois semaines avant de faire passer le trafic réel. Le mode Shadow signifie que les appels d’agents réels sont traités en parallèle, mais les réponses ne sont pas transmises à la logique de l’application. Ainsi, l’équipe détecte les régressions dans le format de réponse, la gestion des signatures et la latence, sans risquer d’impact sur l’activité. Ces trois semaines sont bénéfiques dans presque tous les mandats, car les régressions deviennent visibles tôt, avant de devenir un problème lors de l’acceptation en production.

Un regard honnête sur le degré de maturité

Bien que A2A 1.2 soit en production, le protocole n’est pas terminé. Les éléments manquants que nous attendons dans les 18 prochains mois : des limites de débit standardisées pour les appels inter-organisations, un mécanisme de retour en arrière pour les délégations erronées, des règles de gouvernance plus claires pour la révocation des cartes d’agent. Ceux qui introduisent A2A aujourd’hui planifient ces lacunes comme des éléments supplémentaires. La bonne nouvelle : la gouvernance de la Linux Foundation a publié la feuille de route de manière claire ; les membres actifs (Google, Microsoft, AWS, Salesforce, SAP, ServiceNow) se sont engagés à fournir des mises à jour de la feuille de route chaque trimestre. C’est plus de discipline en matière de gouvernance que ce que l’on a vu avec la plupart des autres normes d’IA en 2025.

Le contrôle de maturité en trois questions avant l’introduction : Le premier cas d’utilisation est-il un scénario intra-organisation (deux agents internes) ou déjà inter-organisations (agent partenaire) ? Quelle est la pression réglementaire sur la délégation (les banques, assureurs, secteur public sont ici beaucoup plus sensibles que l’industrie) ? L’équipe Mesh-Ops existante est-elle prête à gérer les plugins Sidecar et le cycle de vie des certificats A2A ? Ceux qui peuvent répondre clairement à ces trois questions ont la base pour une introduction propre. Ceux qui hésitent sur l’une des questions devraient commencer par un Proof-of-Concept et non par un déploiement en production.

Trois idées fausses qui apparaissent régulièrement dans les premiers projets

La première idée fausse concerne la séparation avec MCP : De nombreuses équipes supposent qu’A2A prend en charge la connexion des outils. Ce n’est pas techniquement correct. A2A décrit exclusivement les interactions agent-à-agent, chaque connexion d’outil se fait toujours via MCP ou des appels d’API directs. Ceux qui ne font pas cette distinction claire dans les discussions architecturales créent en trois mois deux couches de protocole superposées qui ne couvrent chacune que la moitié des interactions.

La deuxième idée fausse concerne les coûts de performance : De nombreuses équipes s’attendent à une augmentation linéaire par appel d’agent et dimensionnent l’infrastructure en conséquence. En pratique, le surcoût est sous-linéaire, car le cache de signature et le pooling de connexions créent des effets d’échelle. Ceux qui dimensionnent l’infrastructure dès le début pour le pire des cas linéaire paient 20 à 30 pour cent de trop pour les six premiers mois.

La troisième idée fausse concerne la gouvernance : De nombreuses organisations croient que la signature des cartes d’agent garantit automatiquement la conformité. Elle fournit la base technique, mais l’approbation organisationnelle (qui peut signer les cartes d’agent ? quels processus sont en place en cas de révocation de carte ?) doit être construite en parallèle. Sans ces processus, la signature est un tampon que personne ne surveille. Pour les organisations de la région DACH opérant dans des secteurs réglementés, nous recommandons de définir la couche de gouvernance avant même l’introduction technique, afin que la première mise en production ne devienne pas un goulot d’étranglement d’audit.

Foire aux questions

A2A nécessite-t-il obligatoirement Istio ou Linkerd ?

Non. A2A est agnostique en termes de Mesh et fonctionne sur toute infrastructure basée sur HTTP. Un Mesh simplifie la gestion opérationnelle (mTLS, observabilité, application des politiques) et réduit les efforts d’intégration, mais n’est pas une condition préalable. Pour les configurations Kubernetes cloud-natives, nous recommandons l’utilisation d’un Mesh. Pour les entreprises legacy utilisant AKS/EKS sans Mesh, A2A fonctionne également via un Ingress standard.

Quel est le coût de performance de la validation des signatures A2A dans le sidecar ?

Avec le plugin Envoy-WASM et un bon cache, nous estimons une latence supplémentaire de 2 à 5 millisecondes par appel, et moins de 1 milliseconde avec un cache chaud. Cela est généralement sans problème dans la plupart des scénarios d’entreprise. Pour le trading en temps réel ou les jeux à faible latence, la validation à l’exécution serait un meilleur choix, car elle ne s’active qu’en cas de besoin.

Comment A2A se positionne-t-il par rapport à l’EU AI Act ?

L’EU AI Act exige la transparence et la traçabilité des systèmes autonomes. A2A fournit deux des quatre composants obligatoires avec les cartes d’agent signées et l’audit des délégations. Les parties manquantes (identification du modèle et documentation des sorties) relèvent du niveau MCP et de l’agent d’application. Une instrumentation propre d’A2A plus MCP couvre environ 70 pour cent des exigences de documentation de l’AI Act.

Combien coûte réellement un déploiement A2A ?

Pour un contexte de PME avec un setup Istio existant, nous estimons un coût compris entre 40 000 et 90 000 euros pour le premier projet, en fonction de la complexité du cas d’usage et du nombre d’agents. Les scénarios cross-org avec plusieurs partenaires coûtent généralement le double, car la gouvernance et les aspects contractuels s’ajoutent.

Quels sont les risques d’une délégation A2A cross-org ?

Les trois principaux risques sont l’injection de prompts via l’agent externe, la fuite de données via la charge utile des tâches et l’escalade de confiance dans la chaîne de délégation. Les contre-mesures incluent la sanitisation des entrées avant l’appel de l’agent, une politique stricte de classification des données pour le contenu de la charge utile et une profondeur maximale de délégation dans le runtime de l’agent. Ces trois mesures sont documentées dans l’implémentation de référence officielle d’A2A et ne doivent pas être négligées lors de la mise en œuvre.

Réseau : Lire la suite dans cloudmagazin

• Contexte sur la poussée Commvault-Clumio sur Cloud Next 2026
• Vérification des faits sur l’évolution des prix de GCP et des conditions CUD en avril 2026
• Architectures dans le domaine multi-cloud en 2026 et plateformes de courtage

Source de l’image de couverture : Pexels / Christina Morillo (px:1181675)