A2A : Agent-à-Agent, un guide pratique pour les bâtisseurs

Début 2026, j’avais cessé de compter le nombre de revues d’architecture d’entreprise qui commençaient par le même diagramme. Une boîte pour l’agent du fournisseur CRM. Une boîte pour l’agent du fournisseur de traitement de documents. Une boîte pour l’agent de l’équipe interne de science des données, celui qu’ils ont construit sur LangGraph et dont ils sont très fiers. Et puis un ensemble de flèches entre les boîtes qui, quand on demande quel protocole elles représentent, s’avèrent signifier « un endpoint REST que quelqu’un écrira plus tard ».

Chaque fournisseur livre désormais un agent. Cette partie est acquise et ne changera pas. Ce que je constate sur le terrain, principalement dans les banques et les assurances, c’est le problème de second ordre : aucun de ces agents ne peut communiquer avec les autres. Chaque paire de boîtes nécessite une colle sur mesure, et chaque morceau de colle appartient à l’équipe qui a perdu la négociation. Les transferts sont des prompts ad-hoc et des payloads JSON assemblés, non versionnés et non audités. Lorsqu’un examinateur demande « quel agent a pris cette décision, sur la base de quelle entrée », personne ne peut répondre à partir des logs. Ce n’est pas un problème d’IA. C’est un problème d’intégration déguisé en problème d’IA, et nous avons déjà résolu des problèmes d’intégration. Nous les résolvons avec des protocoles.

A2A (Agent2Agent) est le protocole qui a émergé pour cette couche. J’ai co-écrit une série en deux parties à ce sujet pour le blog Camunda avec Joyce Johnson, couvrant le framework de décision et une implémentation complète de prêt hypothécaire, et j’ai maintenant construit des systèmes hypothécaires multi-agents basés sur ces idées à deux reprises : une fois comme démo Camunda orchestrée, et une fois comme projet de hackathon Gemini 3 autonome avec de vraies Agent Cards et des contrats JSON-RPC. Ce guide en est la distillation : ce que A2A spécifie réellement, sa position par rapport à MCP, AG-UI et AP2, les deux modèles d’orchestration que j’utilise, la couture de confidentialité des données qu’il rend possible, et le modèle de menace que personne ne met sur la diapositive de lancement.

Multi-agent est un problème d’intégration avant d’être un problème d’IA

Voici l’affirmation que je continue de défendre dans des salles remplies de gens qui veulent parler de modèles : la partie difficile des systèmes multi-agents en entreprise n’est pas l’intelligence des agents. C’est que différentes équipes possèdent les agents, les grands modèles linguistiques et les sources de données, et que ces équipes ont des cycles de publication différents, des postures de sécurité différentes et des définitions différentes de ce qui est « terminé ».

Sans standard, vous obtenez N agents et jusqu’à N×(N-1) intégrations point à point, chacune avec sa propre forme de payload, sa sémantique de réessai et son comportement en cas d’échec. J’ai vu ce film à l’ère de la SOA et à nouveau à l’ère des microservices. L’intrigue ne change jamais. Les intégrations qui étaient « temporaires » deviennent porteuses de charge. L’équipe qui a écrit la colle est réorganisée. Deux ans plus tard, une revue d’incident découvre que l’agent de décision de crédit recevait des prompts assemblés par concaténation de chaînes dans un service que personne ne possède.

Dans les industries réglementées, les enjeux sont plus élevés car les transferts eux-mêmes constituent la surface de conformité. Une décision hypothécaire qui passe par quatre agents nécessite un enregistrement reconstructible de chaque étape : ce qui a été envoyé, ce qui est revenu, quelle version de quel agent l’a produite. L’intégration ad-hoc rend cet enregistrement coûteux ou impossible. Un protocole en fait un sous-produit du travail.

Ce qu’est A2A

A2A est un protocole ouvert permettant aux agents de se découvrir, d’échanger des messages et d’exécuter des tâches au-delà des limites de processus, d’équipe et d’organisation. Google l’a annoncé en avril 2025 avec des dizaines de partenaires de lancement et l’a fait don à la Linux Foundation en juin 2025, où il vit désormais comme un projet open-source neutre. La spécification a atteint la version 1.0 en 2026.

Fait	Détail
Origine	Annoncé par Google, avril 2025 ; fait don à la Linux Foundation, juin 2025
Gouvernance	Linux Foundation (le projet A2A, a2aproject sur GitHub)
Spécification actuelle	1.0 (versions déployées antérieures : 0.2, 0.3 ; s’attendre à des écarts sur le terrain)
Transport	JSON-RPC 2.0 sur HTTP(S) ; liaisons gRPC et HTTP+JSON/REST ajoutées plus tard dans la vie de la spécification
Découverte	Agent Card : métadonnées JSON servies à /.well-known/agent-card.json
Unité de travail	Tâche, avec un cycle de vie défini et un ID unique
Résultats	Artefacts (sorties structurées), distincts des messages conversationnels
Streaming	Server-Sent Events sur la liaison HTTP ; streaming serveur sur gRPC
Travail de longue durée	Notifications push vers un webhook client, plus réabonnement pour la reconnexion
Authentification	Déclarée dans l’Agent Card : clé API, HTTP Basic/Bearer, OAuth 2.0, OpenID Connect, TLS mutuel

Deux choix de conception importent plus que les autres. Premièrement, A2A est opaque par intention : les agents n’exposent pas leur état interne, leurs poids de modèle ou leurs outils les uns aux autres. Ils exposent des capacités et échangent des résultats. Cette opacité est ce qui permet à un agent construit par un fournisseur, sur un modèle que vous ne contrôlez pas, de participer à votre processus sans que vous ayez besoin de faire confiance à ses internes, mais seulement à son contrat. Deuxièmement, A2A est orienté tâche plutôt qu’orienté chat. L’objet central du protocole est une tâche avec un cycle de vie, pas un fil de messages. Ce choix unique est ce qui le rend utilisable pour le travail en entreprise, car le travail en entreprise n’est pas une conversation. C’est une unité de travail avec un état, un propriétaire et une échéance.

La pile de protocoles : A2A, MCP, AG-UI, AP2

Le cadre le plus utile que j’ai trouvé, et celui que je continue de dessiner sur les tableaux blancs, est une pile. Chaque protocole répond à une question différente, et ils se composent plutôt que de se concurrencer.

Protocole	Couche	Question à laquelle il répond	Analogie approximative
MCP	Agent-à-outil	Comment un agent appelle-t-il des outils et accède-t-il aux sources de données ?	USB-C pour les capacités
A2A	Agent-à-agent	Comment les agents pairs se découvrent-ils et délèguent-ils des tâches ?	HTTP entre services
AG-UI	Agent-à-utilisateur	Comment un agent diffuse-t-il l’état dans une interface utilisateur ?	WebSocket vers le front-end
AP2	Agent-à-commerçant	Comment un agent prouve-t-il son autorité de paiement et effectue-t-il des transactions ?	Mandats signés s’appuyant sur les couches inférieures

Un passage concret à travers la pile : un utilisateur demande à un agent courtier une recommandation hypothécaire (AG-UI transporte l’interaction vers l’UI). Le courtier délègue l’analyse de risque à un agent souscripteur (A2A). Le souscripteur extrait le dossier du demandeur d’un magasin de documents interne (MCP). Si le flux se terminait par le paiement d’un rapport de crédit par l’agent au nom de l’utilisateur, l’autorité de paiement voyagerait sous forme de mandats AP2. Quatre protocoles, quatre frontières, un processus.

La conséquence pratique du cadrage par pile est la discipline architecturale. Quand quelqu’un propose d’exposer une base de données interne comme « un agent », la pile vous donne le vocabulaire pour dire non : c’est un outil, mettez-le derrière MCP. Quand quelqu’un propose de connecter deux agents fournisseurs avec un webhook personnalisé, la pile dit : c’est une délégation de pair, utilisez A2A et obtenez le cycle de vie des tâches gratuitement. J’ai écrit une analyse approfondie distincte sur la couche de paiement dans le guide de terrain AP2 ; ce guide reste sur la couture agent-à-agent.

Les mécanismes qui comptent

La spécification est longue. Quatre éléments font l’essentiel du travail en pratique.

Agent Cards : la découverte comme contrat

Une Agent Card est un document JSON, servi à https://{host}/.well-known/agent-card.json, qui décrit ce qu’est un agent, ce qu’il peut faire et comment lui parler en toute sécurité. C’est l’équivalent A2A d’un document OpenAPI, sauf qu’il décrit des capacités et des compétences plutôt que des endpoints et des schémas.

{
  "name": "Underwriter Agent",
  "description": "Analyzes applicant risk from income, debts, and credit score",
  "url": "https://agents.example.com/underwriter",
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "securitySchemes": { "oauth": { "type": "oauth2" } },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "risk-analysis",
      "name": "Mortgage risk analysis",
      "description": "Produces a structured risk assessment for a loan applicant",
      "tags": ["underwriting", "risk"]
    }
  ]
}

Dans mon implémentation de hackathon, le test de fumée pour l’ensemble du système est littéralement curl http://localhost:4001/.well-known/agent-card.json | jq '.name'. Si la carte se résout, l’agent est découvrable ; tout le reste se construit là-dessus. La carte déclare également les exigences d’authentification de l’agent et si elle prend en charge le streaming et les notifications push, ce qu’un client doit vérifier avant de s’appuyer sur l’un ou l’autre. La spécification actuelle prend en charge les cartes signées (une signature JWS sur le contenu de la carte) afin qu’un client puisse vérifier qu’une carte a été émise par celui qu’elle prétend être. Utilisez cela. Je reviendrai sur le pourquoi dans le modèle de menace.

Le cycle de vie des tâches

Chaque délégation dans A2A est une tâche avec un ID et une machine à états. Les états définis, dans leurs formes JSON :

État	Signification	Terminal ?
submitted	Accusé de réception, pas encore démarré	Non
working	En cours de traitement actif	Non
input-required	En pause, en attente d’une entrée supplémentaire du client	Non (interrompu)
auth-required	En pause, en attente d’une autorisation supplémentaire	Non (interrompu)
completed	Terminé avec succès, artefacts disponibles	Oui
failed	Terminé avec une erreur	Oui
canceled	Annulé avant achèvement	Oui
rejected	L’agent a refusé la tâche	Oui

Deux états méritent une attention particulière car ils encodent une réalité d’entreprise que les protocoles de type chat ignorent. input-required signifie qu’une tâche peut se mettre en pause en cours de route et demander plus d’informations, ce qui est la façon dont un agent de souscription distant demande un document manquant sans faire échouer toute la tâche. rejected signifie qu’un agent peut refuser un travail pour lequel il n’est pas qualifié ou autorisé, ce qui est le point d’ancrage au niveau du protocole pour l’application des politiques. Un client qui ne gère pas ces deux états n’a pas implémenté A2A ; il a implémenté la démo.

Messages, parties, artefacts

La communication au sein d’une tâche utilise des messages (rôle : utilisateur ou agent), et chaque message contient des parties : texte, octets bruts, une référence de fichier ou des données structurées arbitraires. Les résultats reviennent sous forme d’artefacts, qui sont également composés de parties mais sont distincts de la conversation. Cette séparation semble bureaucratique jusqu’à ce que vous construisiez quelque chose de réel. La conversation est la façon dont les agents ont négocié ; les artefacts sont ce sur quoi vous agissez et ce que vous auditez. Dans le système hypothécaire, l’artefact du souscripteur est une évaluation structurée des risques. Les étapes en aval consomment l’artefact, jamais le bavardage qui l’a produit.

Streaming et tâches de longue durée

Pour le travail interactif, la liaison HTTP diffuse des objets TaskStatusUpdateEvent et TaskArtifactUpdateEvent via Server-Sent Events (dans la liaison JSON-RPC, message/stream). C’est ce qui alimente une UI de progression en direct : la liste de contrôle de souscription animée de ma démo hypothécaire est rendue directement à partir des mises à jour de statut diffusées.

L’élément qui importe le plus pour les entreprises est le cas des tâches de longue durée. Les tâches réelles dans une banque ne se terminent pas en une seule connexion HTTP. Une vérification KYC peut prendre des jours. Une évaluation immobilière implique qu’un humain se rende à une maison. A2A gère cela avec des notifications push : le client enregistre un webhook, le serveur POSTe des événements de statut et d’artefact à mesure que la tâche progresse, et un client se reconnectant peut se réabonner à une tâche par ID. Aucune connexion n’a besoin de rester ouverte, et aucune des deux parties n’a besoin de fonctionner en continu.

Mais notez ce que le protocole ne fait pas ici : il ne se souvient de rien pour vous. Si votre processus client plante le deuxième jour d’une tâche de trois jours, A2A livrera joyeusement l’événement de complétion à un webhook qui ne sait plus pourquoi il s’en soucie. L’état durable côté client est votre problème, et c’est exactement le problème pour lequel les moteurs de workflow ont été conçus. C’est la raison technique pour laquelle la question de l’orchestration vient ensuite.

Orchestration versus essaim

Il existe deux façons de connecter les agents A2A à un système, et ce choix est plus important que tout autre dans ce guide.

Dans le modèle d’essaim, les agents se délèguent mutuellement des tâches en pair-à-pair. Le courtier appelle le souscripteur, le souscripteur décide de lui-même d’appeler un agent de documents, l’agent de documents appelle autre chose. Le flux de contrôle est émergent. Dans le modèle d’orchestration, un moteur de processus possède le flux et appelle les agents A2A comme des étapes. Le moteur décide ce qui s’exécute, dans quel ordre, avec quel timeout ; les agents font la réflexion à l’intérieur de chaque étape. Ma version en une ligne, et le modèle que j’ai démontré dans la série Camunda : le processus est l’orchestrateur.

Dans la série de blogs en deux parties, nous avons décomposé cela en une heuristique de décision que j’utilise toujours textuellement. Si la question à une étape donnée est « appeler cet agent maintenant, attendre jusqu’à X minutes, réessayer Y fois et escalader en cas d’échec », cette étape appartient à un flux de processus déterministe avec A2A invoqué comme une tâche de service. Si la question est « quel agent devrais-je même appeler, et que devrions-nous faire ensuite », cette étape appartient à un sous-processus d’agent IA où A2A est un outil parmi plusieurs et l’agent choisit à l’exécution. Dans l’implémentation Camunda, ce sont littéralement deux modes de connecteur (autonome versus outil d’agent), mais le modèle est agnostique au moteur : sur Temporal, c’est une activité versus un workflow enfant piloté par un planificateur LLM ; sur LangGraph, c’est une arête fixe versus un nœud routeur. Les modèles d’abord, les produits ensuite.

Les deux modèles sont complémentaires, pas concurrents. Mes systèmes en production utilisent les deux : une dorsale déterministe pour le chemin critique, une sélection d’outils pilotée par agent à l’intérieur des poches exploratoires.

Ce à quoi je m’oppose fermement, c’est l’essaim pur dans les environnements réglementés. Trois modes de défaillance apparaissent dans chaque revue sérieuse :

Auditabilité. Dans un essaim, reconstituer « quel agent a pris cette décision, sur la base de quoi » signifie corréler les logs entre des services appartenant à différentes équipes, ou différentes entreprises. Dans un flux orchestré, chaque appel A2A est une étape dans une instance de processus : les entrées, les sorties, le timing et les réessais sont enregistrés comme état de processus par construction. Lorsque j’ai construit la démo hypothécaire, chaque résultat d’agent intermédiaire atterrissait dans une variable de processus nommée qu’un opérateur pouvait inspecter. Ce n’était pas un travail supplémentaire. Cela découlait de l’architecture.

Annulation atomique. Un client retire sa demande. Dans un flux orchestré, vous annulez l’instance de processus et le moteur annule les tâches A2A en cours (le protocole vous donne tasks/cancel ; le moteur vous donne quelqu’un pour l’appeler). Dans un essaim, l’annulation est une rumeur qui se propage à la vitesse du meilleur effort à travers des agents qui peuvent ou non l’honorer. Imaginez maintenant que la tâche annulée soit « soumettre la demande de crédit ».

Investigation d’incident. Lorsqu’un flux orchestré se rompt, l’incident a une adresse : instance de processus, étape, horodatage, payload. Lorsqu’un essaim se rompt, la première semaine de l’enquête consiste à établir ce qui s’est passé, et les logs narratifs des agents ne sont pas des preuves, ce sont des témoignages.

Commentaire de revue : si votre architecture multi-agents n’a pas d’endroit unique où quelqu’un peut répondre « quel est l’état de la demande de ce client en ce moment », vous n’avez pas construit un système. Vous avez construit un chat de groupe avec des clés API.

Rien de tout cela ne nécessite spécifiquement Camunda. Cela exige que quelque chose de durable et d’inspectable possède le flux. Camunda est l’endroit où je construis parce que c’est mon travail quotidien et parce que BPMN donne aux auditeurs un diagramme qu’ils peuvent lire, mais l’argument vaut pour tout moteur avec un état durable, des timers et une sémantique d’annulation.

Un modèle appliqué : le concierge hypothécaire

J’ai maintenant construit ce système deux fois, je vais donc décrire la forme généralisée et être honnête sur ce que chaque implémentation a prouvé et ce qu’elle a simulé.

Les acteurs, quatre agents et une frontière :

• Agent courtier. La porte d’entrée. Reçoit la demande du candidat, décide quels spécialistes engager et assemble la recommandation finale. Dans l’implémentation Camunda, il s’agit d’un sous-processus d’agent IA avec des clients A2A, des tables de décision DMN, un magasin vectoriel et une recherche CRM dans sa boîte à outils. Dans l’implémentation de hackathon, c’est un service orchestrateur autonome.
• Agent souscripteur (distant). Analyse de risque alimentée par Gemini sur les revenus, les dettes et le score de crédit. Dans l’implémentation de hackathon, cet agent charge un guide complet de réglementation hypothécaire (environ 85k tokens du Fannie Mae Selling Guide) en contexte via l’API Files et cite des codes de réglementation spécifiques, par exemple B3-6-02, dans sa sortie. Il est distant et il devrait l’être : il fonctionne entièrement à partir des données que le demandeur a choisi de soumettre, et il bénéficie du modèle le plus puissant disponible.
• Agent d’étude de marché (local). Trouve les taux applicables pour un profil de risque. Délibérément hébergé à l’intérieur de la limite de confiance. Plus de détails sur le pourquoi dans la section suivante.
• Agent juge. Évalue la sortie assemblée par le courtier et note sa confiance. Au-dessus du seuil, le processus se déroule automatiquement. En dessous, le processus est acheminé vers une tâche de révision humaine avec le contexte complet attaché. Dans la variante hackathon, ce rôle est un agent QA contradictoire qui vérifie les calculs (calculs dette/revenu, ratios prêt/valeur) et rejette les citations réglementaires hallucinées avant qu’un utilisateur ne les voie, renvoyant de manière autonome les sorties échouées pour correction.

Le juge est la pièce que les gens sous-estiment. Un repli humain basé sur la confiance convertit « le modèle se trompe parfois » d’une objection en un chemin conçu. Le seuil est une décision commerciale que vous pouvez ajuster par classe de risque, et la tâche de révision humaine est une étape de processus de première classe avec un SLA, pas un gestionnaire d’exceptions boulonné après le premier incident.

Honnêteté sur l’écart entre la démo et la production :

Dans mes démos	En production
Données de crédit saisies par le demandeur	Intégration avec les bureaux de crédit avec suivi du consentement
Un seul seuil de juge pour tout	Seuils par produit et classe de risque, détenus par le risque, révisés périodiquement
Agents découverts par des URLs de carte codées en dur	Un registre de cartes avec vérification de signature et liste blanche
Annulation de chemin nominal	Logique de compensation pour chaque étape avec effets secondaires
Une équipe possédant les quatre agents	Quatre propriétaires, quatre cycles de publication, tests de contrat sur chaque carte

La dernière ligne est celle qui change tout. Avec un seul propriétaire, A2A est une belle convention interne. Avec quatre propriétaires, c’est la seule chose qui vous sépare du problème de colle N×(N-1) du début de ce guide.

Le modèle de frontière de confidentialité des données

local-sensible / distant-public

C’est le modèle de l’implémentation hypothécaire qui se généralise le plus, et celui que je me retrouve à esquisser le plus souvent pour les banques.

Divisez vos agents par sensibilité des données, pas par fonction. Les agents qui touchent des données sensibles (informations personnelles identifiables de l’emprunteur, historique de compte, tout ce qui a des contraintes de résidence réglementaires) s’exécutent localement, à l’intérieur de votre limite de confiance, sur des modèles que vous hébergez ou sur des contrats que vous contrôlez. Les agents qui travaillent sur des données publiques (taux du marché, comparables immobiliers, textes réglementaires) peuvent s’exécuter à distance sur le modèle de pointe le plus puissant disponible. A2A est la couture entre les deux zones.

Le protocole rend cette couture propre d’une manière que l’intégration ad-hoc ne fait pas. L’Agent Card annonce une capacité sans exposer de données : le courtier distant sait que l’agent d’étude de marché local existe et quelles compétences il offre, mais chaque échange réel est une tâche A2A explicite et loguée dont vous contrôlez les parties de message. Les champs sensibles n’apparaissent simplement jamais dans les parties sortantes, et parce que tout le trafic transfrontalier passe par un seul protocole, vous pouvez l’appliquer avec une passerelle de sortie qui inspecte les payloads A2A à un point de contrôle unique plutôt que d’auditer une douzaine d’intégrations sur mesure.

Dans le système hypothécaire : l’agent souscripteur (distant, Gemini) voit les données financières que le demandeur a soumises exactement à cette fin. L’agent d’étude de marché (local) effectue sa récupération à l’intérieur de la limite et renvoie des taux, pas le contexte client, dans ses artefacts. Le juge voit les deux sorties mais s’exécute localement. Rien dans ce modèle n’est exotique. C’est de la segmentation réseau, appliquée aux agents, avec A2A comme protocole routable à la frontière. Cette familiarité est une caractéristique : votre équipe de sécurité sait déjà comment examiner cette conception.

Modèle de menace : les points difficiles

A2A vous donne une surface de contrat. Les surfaces de contrat sont attaquées. Voici les cinq problèmes que je soulève dans chaque revue de conception, à peu près dans l’ordre de la rapidité avec laquelle ils vous nuiront.

Usurpation d’Agent Card

La carte est un fichier JSON à une URL bien connue. Tout ce qui peut servir du JSON peut prétendre être votre souscripteur. TLS protège le canal, pas la revendication : une entrée DNS compromise, un sous-domaine détourné ou un service interne malveillant peut présenter une carte parfaitement formée pour un agent qu’il n’opère pas, et votre courtier lui enverra joyeusement des demandes de prêt. Mesures d’atténuation, par ordre croissant de gravité : épingler les URLs de carte plutôt que de suivre la découverte aveuglément ; vérifier les signatures de carte (la spécification prend en charge les cartes signées JWS) par rapport aux émetteurs que vous approuvez ; et gérer un registre de cartes interne qui agit comme une liste blanche, de sorte que « découvrable » et « appelable » soient des privilèges différents. Traitez une nouvelle Agent Card comme vous traiteriez une nouvelle dépendance en amont, car c’est ce que c’est.

Dérive des capacités

La carte indique la version 1.4.0 et annonce une compétence d’analyse de risque. Six semaines plus tard, l’équipe derrière elle échange le modèle, réécrit le prompt système et livre la version 1.4.1 avec un texte de carte identique et un comportement matériellement différent. Rien dans le protocole ne détecte cela ; le contrat qu’A2A applique est structurel, pas comportemental. La mesure d’atténuation est la même que celle que nous utilisons pour toute dépendance de service, adaptée à la non-déterminisme : des tests de contrat qui exécutent des tâches de référence contre l’agent en direct selon un calendrier et alertent sur les changements de distribution dans les artefacts, pas seulement les ruptures de schéma. Si vous consommez un agent que vous ne possédez pas, vous avez besoin d’une suite d’évaluation pour celui-ci. J’ai mesuré suffisamment d’échanges de modèles pour le dire clairement : même carte, même schéma, modèle différent est un agent différent.

Décalage de version

La spécification a évolué rapidement : de 0.2 à 0.3 à 1.0 en environ un an, et les changements n’étaient pas cosmétiques. Des liaisons de transport ont été ajoutées, et même le chemin de découverte bien connu a changé en cours de route (les premières implémentations servaient agent.json, la spécification actuelle dit agent-card.json). Dans un déploiement multi-propriétaires, vous aurez des agents sur différentes versions de spécification simultanément, c’est garanti. Enregistrez la version du protocole dans chaque log de tâche, testez explicitement le chemin de négociation de version, et ne supposez pas que les SDK de l’écosystème interprètent les cas limites de manière identique, car ce n’est pas le cas.

Observabilité à travers les frontières organisationnelles

À l’intérieur de votre limite, vous pouvez tout tracer. Dès qu’une tâche passe à l’agent d’un partenaire, votre trace se termine à leur porte d’entrée. A2A vous donne des ID de tâche et des ID de contexte pour la corrélation, mais la corrélation ne fonctionne que si les deux parties conservent et partagent les enregistrements. C’est une négociation de contrat, pas un problème de code : mettez-vous d’accord sur la propagation des ID de trace, la rétention des logs et l’accès avant de passer en production, car négocier cela pendant un incident est misérable. Ma position par défaut est que la partie qui possède le résultat client conserve un enregistrement faisant autorité de chaque tâche transfrontalière : requête, réponse, timing et version de la carte. L’orchestration rend cela presque gratuit ; un essaim en fait un projet.

Qui possède le SLA

Une tâche A2A contre un agent partenaire a un timeout que vous définissez et un temps d’achèvement qu’ils contrôlent. Lorsque l’agent souscripteur ralentit de quarante secondes à quatre cents, à qui appartient l’incident ? Le protocole ne vous le dira pas. Mettez des chiffres dans l’accord d’exploitation (percentiles de temps de réponse par compétence, débit, fenêtres de maintenance planifiées) et appliquez votre côté mécaniquement : budgets de timeout par étape, backoff basé sur des timers pour le polling, un nombre maximal de réessais, et un chemin d’escalade défini lorsque les réessais sont épuisés. Dans le modèle déterministe, tout cela vit dans le modèle de processus où les opérations peuvent le voir. Si votre seule application de SLA est l’espoir que l’agent distant est rapide, l’essaim a déjà gagné et vous avez déjà perdu.

Commentaire de revue : chacun de ces cinq points est un problème organisationnel avec une surface technique. Le protocole vous donne la surface. Il ne peut pas assister à la réunion de gouvernance pour vous.

Ce qu’A2A ne résout pas

Le moyen le plus rapide de perdre de la crédibilité auprès d’un comité d’architecture est de survendre un protocole. Voici la limite honnête de celui-ci.

Sémantique. A2A garantit qu’un message arrive avec une structure valide. Il ne garantit pas que les deux agents signifient la même chose par income. Brut ou net ? Annuel ou mensuel ? Ménage ou individuel ? Deux agents conformes à la spécification peuvent échanger du JSON impeccable et produire une mauvaise décision. Vous avez toujours besoin de vocabulaires partagés, et dans les domaines réglementés, vous devez les avoir écrits. Le protocole déplace le problème d’intégration d’un niveau ; il ne le dissout pas.

Confiance. Les cartes signées vous disent qui a publié une revendication de capacité. Elles ne vous disent pas si l’agent est compétent, si ses données d’entraînement étaient appropriées, ou si son opérateur existera toujours le trimestre prochain. La réputation, la certification et la responsabilité des agents sont des problèmes ouverts. Aujourd’hui, ils sont résolus par des contrats entre entreprises, comme toujours.

Paiements. A2A déplace des tâches, pas de l’argent. Lorsqu’un agent doit prouver qu’il est autorisé à dépenser au nom d’un utilisateur, c’est un problème différent avec des exigences cryptographiques différentes, et c’est à cela que sert AP2. J’ai rédigé cela séparément dans le guide de terrain AP2.

Qualité du modèle. Un pipeline parfaitement orchestré d’agents médiocres produit une médiocrité auditable. La couche protocolaire rend les échecs visibles et attribuables, ce qui a une grande valeur, mais le modèle d’agent juge et les évaluations honnêtes sont ce qui rend les sorties dignes de confiance. Prévoyez un budget pour les deux.

État de longue durée. Le protocole définit comment une tâche de plusieurs jours communique. Il ne persiste pas votre version de l’histoire. Quelque chose de durable doit se souvenir pourquoi vous avez démarré la tâche, ce qui en dépend, et quoi faire quand elle se termine ou échoue. Apportez un moteur de workflow, ou soyez prêt à en construire un par accident.

La version en un paragraphe

Chaque fournisseur livre un agent, donc le problème multi-agents en entreprise est un problème d’intégration avant d’être un problème d’IA, et les problèmes d’intégration sont résolus par des protocoles. A2A (Google, avril 2025 ; Linux Foundation, juin 2025 ; spécification maintenant à 1.0) est la couche agent-à-agent de la pile, aux côtés de MCP pour les outils, AG-UI pour les interfaces et AP2 pour les paiements : les agents publient des Agent Cards signées à /.well-known/agent-card.json, échangent des tâches via un cycle de vie défini (submitted à completed, failed, canceled, ou rejected, avec input-required et auth-required pour les pauses), diffusent la progression via SSE, et gèrent les tâches de plusieurs jours via des webhooks. Connectez ces agents avec un orchestrateur durable plutôt qu’un essaim pair-à-pair, car l’auditabilité, l’annulation atomique et l’investigation d’incidents sont ce pour quoi les industries réglementées paient réellement ; divisez les agents à travers une frontière de confidentialité des données (données sensibles locales, données publiques distantes, A2A comme couture) ; contrôlez la sortie autonome avec un juge noté en confiance qui se replie sur une révision humaine ; et soyez lucide sur ce que le protocole vous laisse à résoudre : la sémantique partagée, la confiance des agents, les SLAs à travers les frontières organisationnelles, et l’état durable qui se souvient pourquoi une tâche de trois jours a été démarrée du tout.

Références

• J’ai co-écrit la série en deux parties sur laquelle ce guide s’appuie avec Joyce Johnson : Utiliser A2A pour atteindre vos objectifs commerciaux, Partie 1 (le framework de décision : étapes A2A déterministes versus sélection d’outils pilotée par agent) et Partie 2 (l’implémentation complète de prêt hypothécaire, les deux modèles implémentés).
• Spécification du protocole A2A, la source faisant autorité pour les Agent Cards, les états de tâche, les transports et les schémas de sécurité ; source et SDKs sur github.com/a2aproject/A2A.
• gemini3-hackathon-mortgage-concierge, mon implémentation publique de pré-qualification hypothécaire multi-agents : agents courtier, vision et souscripteur avec des Agent Cards, des contrats JSON-RPC 2.0, un contexte réglementaire de 85k tokens via l’API Files, et une boucle QA contradictoire.
• AP2 : la couche de paiement, un guide de terrain, mon analyse approfondie complémentaire sur ce qui se passe lorsque les agents doivent déplacer de l’argent, pas seulement des tâches.