Ton fournisseur t'écrit que son agent parle déjà A2A et que le tien peut s'y brancher demain. On dirait de la tuyauterie, l'affaire d'un après-midi d'ingénierie. Mais dès que deux agents de deux organisations différentes négocient une tâche — une commande, un rendez-vous, une réclamation —, la question qui compte n'est plus comment voyagent les messages. C'est qui répond quand le message est juste et le résultat faux.
La thèse en une phrase : le protocole A2A pour des agents entre entreprises règle le transport et laisse intact le vrai problème, qui est contractuel. Pour presque toutes les PME, aujourd'hui, la décision n'est pas technique : c'est ce que tu signes avec celui qui fait tourner l'autre agent, quelles permissions tu donnes au tien, et comment tu reconstitueras une conversation qu'aucune des deux parties ne voit en entier.
Protocole A2A et agents entre entreprises : ce qu'il règle et ce qu'il laisse ouvert
A2A (Agent2Agent) est un protocole ouvert qui permet à un agent de confier du travail à un autre sans savoir comment il est construit à l'intérieur. Né chez Google, il a vu la Linux Foundation annoncer le 9 avril 2026 sa version 1.0, la première spécification stable, avec plus de 150 organisations qui le soutiennent selon la fondation elle-même. Attention au chiffre : il vient d'un communiqué de ceux qui promeuvent le standard, et il mesure des soutiens, pas un usage en production.
Il repose sur deux pièces. La « carte d'agent », un document qui dit qui est l'agent, ce qu'il sait faire et comment s'authentifier, et qui peut être signée dans la 1.0. Et un cycle de vie des tâches avec des états standard : en cours, terminée, échouée, rejetée, en attente de données, en attente d'autorisation.
Ce qu'il ne fait pas pèse autant que ce qu'il fait. Selon sa spécification, chaque agent collabore sans accéder à l'état interne, à la mémoire ni aux outils de l'autre. C'est une vertu technique — chacun protège son implémentation — et c'est aussi le problème de gouvernance : l'agent de ton fournisseur est, par conception, une boîte noire pour toi, et le tien en est une pour lui.
| Question | Ce qu'apporte A2A | Ce qui reste pour ton contrat |
|---|---|---|
| Qui est l'autre agent ? | Carte d'agent, signable | Qui l'émet et qui répond de sa véracité |
| Comment demande-t-on et livre-t-on le travail ? | Messages et états de tâche standard | Ce qui compte comme « livré » et le délai pour le contester |
| Qui peut demander quoi ? | Schémas d'authentification et d'autorisation courants sur le web | Quel périmètre est accordé, à qui, et comment il est révoqué |
| Et s'il se trompe ? | États « échouée » ou « rejetée » | Qui assume l'erreur quand la tâche apparaît comme « terminée » et qu'elle est fausse |
| Comment l'audite-t-on ? | Rien de spécifique | Ce que chaque partie enregistre et pendant combien de temps |
Cette dernière colonne n'est pas qu'une opinion de notre part. La spécification s'en tient au protocole et laisse la confiance, la responsabilité et l'audit entre organisations à celui qui le déploie, et les analyses indépendantes du secteur s'accordent à dire que la sécurité entre organisations reste la question non résolue.
En quoi A2A diffère-t-il de MCP ?
Réponse courte : MCP relie ton agent à tes outils ; A2A relie ton agent à l'agent d'une autre organisation. Avec MCP, c'est toi qui décides quels outils existent, ce qu'ils font et avec quels identifiants ; on l'explique dans ce qu'est le MCP et pourquoi il change les agents d'entreprise. Avec A2A, de l'autre côté, quelqu'un décide de son côté, avec son propre modèle, ses propres erreurs et son propre calendrier de changements. C'est la différence entre acheter un outil et sous-traiter à un atelier.
Un exemple hypothétique, sans noms
L'agent achats d'un client demande à l'agent commercial de son distributeur de « réapprovisionner ce matériel au meilleur prix ». Le second répond avec un prix et un délai, et la tâche est marquée comme terminée. Ce prix engage-t-il ? Le délai est-il un engagement ? Qui a vérifié que l'agent du distributeur appliquait le bon tarif ? Rien de tout cela ne voyage dans le message. Tout cela, c'est du contrat, et si ce n'est pas écrit, c'est celui qui réclame le plus fort qui tranche.
Quatre questions de contrat avant de connecter ton agent à celui d'un tiers
1. Qui répond du résultat ?
Quand la tâche arrive comme terminée et que le résultat est faux — un prix mal confirmé, un rendez-vous en double, une commande pour la mauvaise quantité —, le protocole n'a pas d'avis. Le contrat doit en avoir un : ce qui compte comme livraison, qui la vérifie et combien de temps on a pour la contester.
2. Que se passe-t-il si l'agent de l'autre se trompe ?
Ton agent agit sur ce que l'autre lui dit. Si l'autre invente un délai de livraison et que le tien le promet à ton client, l'erreur est déjà la tienne aux yeux du client. Décide à l'avance ce que ton agent peut faire seul avec une réponse externe et ce qui exige une confirmation humaine : c'est la logique des niveaux d'autonomie d'un agent, appliquée à une source que tu ne contrôles pas.
3. Comment audite-t-on une conversation entre deux boîtes noires ?
Chaque partie ne voit que sa moitié. Pour reconstituer ce qui s'est passé, il faut conserver ce que ton agent a envoyé, ce qu'il a reçu, sous quelle identité et avec quel résultat, et convenir que l'autre partie garde le sien pendant une durée donnée. Sans cela, le premier litige se règle avec deux récits incompatibles. La base, c'est la traçabilité des décisions de l'IA ; pour la durée, combien de temps conserver les logs d'un agent IA.
4. Que peut demander chacun, et comment cela se révoque-t-il ?
Un agent qui parle à l'extérieur ouvre une surface nouvelle. Donne-lui une identité propre, un périmètre par tâche et une révocation testée, comme le détaille le guide sur les permissions d'un agent IA, et exige la même chose de l'autre. Une carte d'agent signée atteste de qui est l'agent ; elle n'atteste pas qu'il mérite le périmètre qu'il demande.
Quand tu n'as PAS besoin d'A2A (pour l'instant)
Trois situations où l'adopter, c'est devancer un problème que tu n'as pas :
- L'autre côté propose une API classique. Si ton client ou ton fournisseur expose un service avec des entrées et des sorties définies, une intégration classique coûte moins cher, s'audite plus facilement et ne dépend pas de deux modèles qui se comprennent. A2A se justifie quand le travail est ouvert et qu'il y a négociation, pas pour une requête à réponse fermée.
- Tous tes agents vivent dans ton entreprise. La coordination interne se règle par l'orchestration, pas par un standard entre organisations. Commence par orchestrer plusieurs agents IA et par te demander s'il te faut un agent ou plusieurs.
- Personne n'a demandé que ton agent parle à un autre. Un protocole avec beaucoup de logos de soutien n'équivaut pas à beaucoup de cas en production : l'analyse du secteur elle-même distingue soutenir un standard et le maintenir en production après le premier vrai incident.
Que faire cette semaine
- Demande à tes fournisseurs clés si leur agent propose A2A et ce qu'il propose dès aujourd'hui par API. Si la réponse est « on étudie la question », tu connais le calendrier.
- Pour le premier cas candidat, écris les quatre questions ci-dessus avec des noms et des prénoms : qui vérifie, qui assume l'erreur, ce qui est enregistré et quel périmètre est accordé.
- Définis quelles décisions de ton agent exigent une confirmation humaine quand la donnée vient de l'extérieur, et teste-le avec une réponse volontairement fausse.
- Vérifie que ton journal conserve ce qui est envoyé et reçu, avec l'identité de l'agent qui a agi. Sinon, corrige-le avant d'ouvrir la moindre connexion.