Qu'est-ce que A2A ? Agent2Agent, sécurité et paiements 2026

A2A décrit officiellement sa répartition des rôles avec MCP ainsi : « MCP est vertical et approfondit un agent unique ; A2A est horizontal et relie des agents par-delà les frontières. » Dans A2A, la partie appelée est un agent « opaque » : il raisonne et gère son état lui-même, l'appelant ne voit pas quels modèles ou outils il utilise en interne, et les deux parties n'échangent, sur plusieurs tours, qu'à travers le cycle de vie d'une tâche (Task). Les documents officiels taïwanais traitent déjà d'A2A : le Manuel de référence pour les applications de l'IA dans le secteur public V1.0 du ministère des Affaires numériques (date de mise à disposition indiquée dans le document : 115-01-28, calendrier Minguo) comporte en page 14 une sous-section « A2A : protocole de communication entre agents IA », qui explique qu'il se concentre sur la communication « client–distant ».

La gouvernance d'A2A a connu trois étapes. Le 2025-06-23, la Linux Foundation a annoncé la reprise du projet, avec pour membres fondateurs AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow ; le 2025-08-29, ACP, piloté par IBM, a fusionné avec A2A et cessé d'être développé. Le pouvoir de décision réel appartient à un comité de pilotage technique (TSC) de 9 sièges, un siège par entreprise : Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM et Bloomberg. Les propositions sont votées avec gitvote dans des tickets GitHub étiquetés TSC Review ; par exemple, le ticket #1942 a regroupé 41 sujets en huit thèmes pour la v1.1 et a été adopté le 2026-06-25 par 5 voix pour et 0 contre (seuil de 51 %).

En août 2026, A2A a rejoint l'Agentic AI Foundation (AAIF) en tant que projet Growth Stage, sous la même fondation que MCP. Les sources divergent sur la date : le blog de l'AAIF et Axios indiquent 2026-08-17, le blog officiel d'A2A et la page de la spécification 2026-08-27, et l'article de Forbes est daté du 08-19. Il est possible que le 08-17 corresponde à l'annonce publique de la fondation et le 08-27 à la publication du projet lui-même, mais aucune source ne confirme cette explication ; cet article mentionne donc les deux dates sans choisir à la place du lecteur. Diginomica compte A2A comme le 5e projet hébergé par l'AAIF, après MCP, goose, AGENTS.md et agentgateway ; des sources secondaires soulignent aussi qu'il s'agit d'un simple ajustement organisationnel et que les deux spécifications n'ont pas fusionné.

Le document de gouvernance d'A2A précise que « la composition de la phase stable sera décidée 18 mois après la création ». À compter de juin 2025, l'échéance tombe vers décembre 2026, et l'annonce de l'AAIF ne dit pas si le TSC sera remanié. Il s'agit d'une déduction : la composition du TSC pourrait changer prochainement et mérite d'être suivie.

Toutes les méthodes d'A2A v1.0 ont été renommées : message/send devient SendMessage, message/stream devient SendStreamingMessage, tasks/resubscribe devient SubscribeToTask, et ListTasks a été ajoutée. Les chemins REST suivent désormais le style AIP, par exemple POST /tasks/{id}:cancel, et le préfixe /v1 a disparu. Le format d'erreur HTTP est passé d'application/problem+json selon la RFC 9457 à google.rpc.Status ; reason s'écrit en majuscules avec tirets bas (par exemple TASK_NOT_FOUND) et domain est fixé à "a2a-protocol.org". Les notes de recherche y voient une refonte d'A2A dans le style du guide de conception des API de Google ; il s'agit d'une déduction.

Le plus gros changement incompatible du modèle de données est l'aplatissement de Part. Les anciens TextPart, FilePart, DataPart et le champ discriminant kind ont tous été supprimés ; un même Part contient désormais un seul champ parmi text, raw (octets), url ou data, et le type se détermine par le champ présent plutôt qu'en lisant kind. mimeType est renommé mediaType, et file.fileWithUri devient url. Selon des retours de la communauté, de nombreux parseurs lisent encore part.kind, ce qui est la cause la plus fréquente d'échecs d'interopérabilité entre 0.3 et 1.0. L'Agent Card est désormais centrée sur supportedInterfaces[] : chaque interface porte ses propres url, protocolBinding, protocolVersion et un tenant facultatif ; les clients choisissent dans l'ordre du tableau et DEVRAIENT (SHOULD) implémenter un repli.

La négociation de version comporte une valeur par défaut peu remarquée : si l'en-tête A2A-Version est vide, il est traité comme 0.3. Les clients n'envoient que Major.Minor, et un serveur qui ne la prend pas en charge renvoie −32009 VersionNotSupportedError ; un même agent peut lister dans supportedInterfaces des interfaces avec des protocolVersion différents, ce qui permet à 0.3 et 1.0 de coexister. La migration officielle se fait en trois phases : d'abord analyser les deux formats, puis émettre en 1.0 tout en lisant 0.3, enfin ne garder que 1.0. Atlassian Forge et MuleSoft ont tous deux publié des guides de migration 0.3→1.0, signe que quelqu'un paie réellement le coût des changements incompatibles.

La sémantique des tâches comporte plusieurs détails qu'on ne découvre qu'en lisant toute la spécification. taskId est toujours généré par le serveur ; si le client fournit un contextId, l'agent peut seulement l'accepter ou le refuser, pas en générer un autre ; si taskId et contextId ne concordent pas, l'agent DOIT (MUST) refuser. Envoyer un message à une tâche dans l'un des quatre états finaux (COMPLETED, FAILED, CANCELED, REJECTED) renvoie UnsupportedOperationError ; pour poursuivre, on ouvre une nouvelle tâche dans le même contexte et on la relie à la tâche d'origine via referenceTaskIds. La machine à états comporte deux états « d'interruption », TASK_STATE_INPUT_REQUIRED et TASK_STATE_AUTH_REQUIRED, et un SendMessage bloquant rend aussi la main lorsqu'il atteint un état d'interruption.

Les garanties du streaming et du push sont plus faibles que ce que la plupart des gens imaginent. L'indicateur final de TaskStatusUpdateEvent a été supprimé en 1.0 : c'est désormais la « fermeture de la connexion » qui signale la fin du flux. Une coupure en pleine tâche ressemble donc, côté client, à une tâche terminée, et seul un nouvel appel à GetTask ou SubscribeToTask permet de les distinguer. La spécification n'a pas non plus de mécanisme de reprise par identifiant d'événement, ce qui figure parmi les thèmes de la v1.1 (#1986). Les notifications push envoient une StreamResponse au webhook du client par HTTP POST, avec le Content-Type application/a2a+json ; la spécification exige seulement que l'agent tente au moins une fois la livraison, avec un délai d'expiration qui DEVRAIT être d'environ 10 à 30 secondes, et le destinataire DEVRAIT traiter de façon idempotente et DOIT vérifier le taskId. Autrement dit, le push est « au moins une fois, sans garantie d'ordre, avec une charge utile non signée » ; c'est une déduction tirée de la spécification. L'idempotence n'est elle aussi qu'à moitié traitée : SendMessage « PEUT » (MAY) dédupliquer via messageId, sans obligation.

Les sources se contredisent sur deux points de date et de nombre. Date de sortie de la v1.0 : le CHANGELOG indique 2026-03-12, un article de synthèse (arXiv:2507.10644 v4) janvier 2026, et le communiqué du premier anniversaire de la Linux Foundation qualifie seulement la v1.0 de première version stable, sans date ; cet article retient le CHANGELOG comme source primaire. Nombre de SDK : la Linux Foundation évoquait en 2026-04 5 langages « production-ready », tandis que l'annonce officielle d'A2A en liste 6 (Python, Go, Java, JS, .NET et Rust), le SDK Rust testé en détail étant toutefois une version communautaire.

L'an dernier, on entendait souvent : « MCP a ajouté les Tasks, A2A n'est donc plus nécessaire. » Or la révision MCP 2026-07-28 va exactement dans le sens inverse. La révision MCP 2025-11-25 a bien introduit des Tasks expérimentales (SEP-1686) pour suivre les requêtes longues, interroger leur état et récupérer les résultats plus tard, avec des états (working, input_required, completed, failed, cancelled) qui correspondent presque un à un à ceux d'A2A. Mais la révision 2026-07-28 a supprimé les sessions et la poignée de main initialize, rendant MCP sans état (SEP-2567, SEP-2575), a sorti les Tasks du noyau pour en faire l'extension officielle io.modelcontextprotocol/tasks (SEP-2663), a remplacé les requêtes initiées par le serveur par MRTR (InputRequiredResult accompagné d'inputResponses joints lors du renvoi) (SEP-2322), et a déclaré Sampling, Roots et Logging dépréciés (SEP-2577).

Ces changements signifient que les mainteneurs de MCP ont délibérément renoncé à la voie « agentique » où le serveur emprunte le LLM de l'appelant pour raisonner ; il s'agit d'une déduction. Un serveur MCP qui veut raisonner doit apporter son propre modèle, et il devient alors de fait un agent opaque qui n'a que l'apparence d'un outil. La Task de MCP gère « la récupération différée d'un appel d'outil long » ; la Task d'A2A gère « une collaboration en plusieurs tours où chaque partie peut poser des questions », avec en plus la découverte par Agent Card, la déclaration des compétences et le streaming d'artefacts. Il existe aussi un mode d'échec dans l'autre sens : faire passer de force des requêtes déterministes, comme une demande de prix ou de taux de taxe, par le cycle de vie Task, Message et Artifact augmente la latence et le coût d'implémentation, et prive le LLM de l'appelant d'un schéma d'outil précis ; c'est aussi une déduction. Les notes de recherche n'ont trouvé aucun incident documenté du type « MCP utilisé d'agent à agent et échec » ou « outils encapsulés dans A2A et échec ».

Côté adoption, outre le nombre de topics GitHub, une comparaison PyPI non systématique montre environ 10,9 millions de téléchargements pour le SDK A2A contre environ 257 millions pour le SDK MCP. D'après des sources secondaires, le point de terminaison UCP de Shopify utilise MCP comme couche de transport : les agents de commerce grand public se connectent donc via MCP. Côté plateformes cloud : AWS AgentCore Runtime peut déployer des serveurs A2A (JSON-RPC, POST /, port 9000, OAuth 2.0 ou SigV4) ; la prise en charge d'A2A dans Microsoft Foundry est entrée en public preview en juin 2026 ; Google Agent Registry lit les cartes well-known, mais la découverte automatique est limitée au même projet. Parmi les grands fournisseurs de modèles couverts par les notes de recherche, Anthropic n'offre actuellement aucune prise en charge native d'A2A, et le ticket Claude Code correspondant, #104852, n'a été ouvert que fin octobre 2026.

En pratique, le choix est simple : pour que des assistants IA appellent vos fonctions déterministes (devis, taux de taxe, suivi d'envoi), utilisez MCP ; ce n'est que lorsque deux agents qui raisonnent chacun de leur côté et appartiennent à des organisations différentes doivent collaborer sur plusieurs tours qu'A2A devient nécessaire. Le MCP public de HowBridge relève de la première catégorie ; pour le connecter, voir notre tutoriel MCP sur le groupage de colis.

Une Agent Card A2A déclare via securitySchemes l'un des cinq schémas d'authentification : API Key, HTTP Auth, OAuth2, OIDC et mTLS. La v1.0 a supprimé les flux OAuth implicit et password, ajouté Device Code et recommande PKCE pour tous les clients. La spécification exige des serveurs « MUST authenticate every incoming request », mais l'autorisation est implementation-specific, et les identifiants doivent être obtenus hors bande (out-of-band) ; lorsqu'une tâche passe à l'état AUTH_REQUIRED, la spécification précise explicitement : « Agents MUST NOT treat the state transition alone as authorization ». La section 13, « Considérations de sécurité », ne mentionne ni l'injection de prompt, ni la délégation ou le token exchange, ni OpenTelemetry, et ne contient aucune exigence dédiée à l'isolation des locataires. Une analyse de Semgrep datant de la v0.3 relevait qu'A2A « supports but does not enforce Agent Card signing », que la durée de vie et la portée des jetons ne sont pas encadrées par le protocole et qu'une même tâche peut avoir plusieurs flux parallèles, si bien qu'un jeton de session volé permet d'écouter discrètement le flux de la victime.

Même une Agent Card signée n'est pas aujourd'hui garantie vérifiable d'un SDK à l'autre. La spécification canonise la carte selon la RFC 8785 (JCS), en excluant le champ signatures, puis applique JWS ; l'en-tête protégé DOIT contenir alg et kid. Le ticket #2122 (ouvert le 2026-08-10, toujours ouvert au 2026-10-31) documente des écarts mesurés : a2a-python 1.1.2 et @a2a-js/sdk 1.0.1 produisent des octets canonisés différents. Python échappe les caractères non ASCII en \uXXXX, trie par point de code plutôt que par unités UTF-16 et écrit les nombres sous la forme 1e-06, alors qu'ECMAScript écrit 0.000001 ; la spécification exige que les champs REQUIRED apparaissent même avec leur valeur par défaut, mais proto3 n'a pas de notion de présence, si bien que description: "" et skills: [] sont supprimés ; typ est en outre ambigu. La PR #2319 a corrigé les exemples de la spécification, mais la sortie d'a2a-go diffère toujours. Autre limite : une signature valide prouve seulement que la carte n'a pas été altérée, pas l'identité de son émetteur, et la communauté souligne que la spécification ne prévoit aucun mécanisme liant une carte à l'environnement d'exécution qui effectue réellement l'appel.

Certaines attaques fonctionnent tout en restant parfaitement conformes à la spécification. A2ABreak (arXiv:2609.10871, v3 2026-10-24) a utilisé un LLM pour extraire de la spécification en langage naturel 37 états, 76 transitions et 929 énoncés formels, et a trouvé 11 nouvelles vulnérabilités qui « ne nécessitent aucun défaut d'implémentation et peuvent être exploitées par un adversaire conforme à la spécification », comme l'injection de contexte entre clients due à des identifiants de contexte non protégés, la perte d'identité après plusieurs sauts dans une chaîne de délégation, ou des agents revendiquant des capacités non vérifiées. Une étude sur les collisions de noms (arXiv:2609.27624) souligne que la spécification présente name comme « human-readable metadata, not as a stable identity » sans définir de règle de collision ; dans 6 des 7 implémentations open source suivies par l'auteur, les intégrations de type client enverraient des requêtes vers un point de terminaison contrôlé par l'attaquant, ce que l'auteur qualifie de catégorie récurrente de vulnérabilité d'implémentation plutôt que de vulnérabilité générique du protocole. Unit 42, de Palo Alto Networks, a réalisé avec Google ADK une preuve de concept de session smuggling : un agent malveillant soutire des instructions système au moyen de « questions de clarification » et pousse le client à appeler buy_stock pour acheter 10 actions sans autorisation ; Unit 42 précise clairement qu'il ne s'agit pas d'une vulnérabilité du protocole, que tout protocole multi-tours avec état peut être concerné et qu'aucune exploitation dans la nature n'a été observée. La communauté a également signalé qu'un serveur malveillant peut cacher des instructions dans les champs description ou skills de l'Agent Card, que le LLM hôte exécute alors comme des instructions.

Les travaux académiques sur les attaques entre agents confirment eux aussi que « la confiance entre agents ne peut pas être présumée ». Triedman et al. (COLM 2025) ont montré qu'un contenu web malveillant peut détourner le flux de contrôle de systèmes multi-agents ; avec GPT-4o, l'exécution de code arbitraire a réussi dans 58 à 90 % des essais. La synthèse évaluée par les pairs de Ferrag et al. dans ICT Express (2026) retrace les attaques depuis l'injection de prompt jusqu'à la couche protocolaire, en couvrant MCP et A2A.

Les numéros de CVE du tableau ci-dessous sont repris tels quels des notes de recherche. Ces notes signalent elles-mêmes que ces numéros sont inhabituels et que certaines entrées n'apparaissent que dans une seule base (par exemple, la CVE-2026-90790 n'a pas de GHSA correspondant dans le dépôt a2a-python et n'apparaît que sur OpenCVE). Les requêtes sur les avis de sécurité des dépôts a2a-js, a2a-go et a2a-dotnet sont revenues vides, mais cela peut tenir à des droits insuffisants et ne signifie pas nécessairement qu'il n'existe aucune vulnérabilité. On peut tirer trois enseignements de ce tableau ; ce qui suit est une déduction. Premièrement, l'Agent Card est une entrée contrôlable par l'attaquant, jusqu'aux noms d'en-têtes que l'autre partie peut imposer. Deuxièmement, la spécification se contente d'écrire « SHOULD validate webhook URLs », et des SDK dans deux langages ont ainsi hérité d'une SSRF. Troisièmement, la spécification dit « l'autorisation relève de l'implémentation », et le SDK le plus utilisé, celui pour Java, n'appliquait par défaut aucune autorisation ; le correctif a de plus été contourné via une particularité de la plateforme Android.

Hors d'A2A, le problème de l'identité des agents se divise en trois couches. La première est l'identité des charges de travail, qui répond à « de quel programme s'agit-il ? » : les auteurs de draft-klrc-aiagent-auth viennent notamment d'Amazon, Zscaler, Ping Identity et OpenAI ; ce projet a été adopté par le groupe de travail WIMSE de l'IETF et remplacé par draft-ietf-wimse-aims, et son approche consiste à réutiliser les familles WIMSE et OAuth 2.0 existantes, « sans inventer de nouveau protocole ». La deuxième est l'autorisation et la délégation, qui répond à « au nom de qui, et pour faire quoi ? » : l'exemple de Ping Identity enregistre tout le chemin de délégation avec la claim act du token exchange de la RFC 8693 et restreint le saut suivant avec may_act ; mais la RFC 8693 a été conçue à l'origine pour des échanges entre serveurs « une fois le consentement déjà donné » et ne couvre pas nativement le consentement d'un utilisateur envers un agent précis.

La troisième couche est l'identité vérifiable de l'extérieur, qui répond à « pourquoi un inconnu lui ferait-il confiance ? ». Cloudflare Web Bot Auth signe les requêtes HTTP avec Ed25519 et la RFC 9421, mais Cloudflare ne vérifie pas actuellement le nonce et compte surtout sur une validité courte d'environ 1 minute contre le rejeu ; le projet ANS v2 vérifie les domaines via ACME et prévoit trois niveaux : Bronze, Silver (avec DANE) et Gold (avec un journal de transparence SCITT). A2A ne touche cette couche que par la signature des cartes, qui est facultative. Des produits commerciaux sont déjà sortis : Okta Agent SSO est disponible en version générale depuis le 2026-08-24 et utilise ID-JAG ; Microsoft Entra Agent ID ne prend pas en charge ID-JAG nativement, et les sources divergent sur sa date de disponibilité générale (2026-04 ou 2026-05). Pour faire de l'A2A entre entreprises, les deux parties devront donc probablement convertir les jetons chacune à sa frontière ; il s'agit d'une déduction.

Les pouvoirs publics s'emploient aussi à combler ce vide. Le 2026-02-17, le CAISI du NIST américain a annoncé l'AI Agent Standards Initiative, dont les trois piliers sont des normes portées par l'industrie, des protocoles open source portés par la communauté, et la recherche sur la sécurité et l'identité des agents ; mais la page de l'initiative n'emploie que des termes génériques comme « interoperable agent protocols » et ne cite ni A2A ni MCP. Le projet « Software and AI Agent Identity and Authorization » du NCCoE du NIST a publié le 2026-09-29 une synthèse des commentaires sur son document de cadrage, avec plus de 600 organisations ou particuliers répondants. Le billet de blog du NIST du 2026-10-27, « Design Tenets for Agent Identity Management Systems », énonce 10 principes de conception, dont : des agents dotés d'une identité propre liée à leur initiateur, avec des droits qui se réduisent à chaque étape de délégation ; le moindre privilège ; des autorisations de courte durée et révocables ; une intervention humaine déclenchée selon le risque ; des mandats signés délimitant le périmètre d'action ; et des traces infalsifiables. Il s'agit d'un billet de blog, pas d'une norme formelle.

La recherche académique va dans le même sens. South et al. proposent d'étendre OAuth 2.0/OIDC avec des identifiants propres aux agents et de construire des chaînes de délégation auditables, une version de position de ces travaux figurant dans l'ICML 2025 Position Paper Track ; Chan et al., à FAccT 2024, préconisent trois types de mesures – identifiants d'agents, surveillance en temps réel et journaux d'activité – pour accroître la visibilité des agents.

AP2 n'est plus la version dont on se souvient en 2025. La v0.2.0 refond le mécanisme autour des Checkout Mandates et Payment Mandates, chacun scindé en une étape ouverte (open) et une étape fermée (closed) et implémenté en SD-JWT, le mandat ouvert stockant la clé publique de l'agent dans la claim cnf. La principale nouveauté est le parcours Human-Not-Present : l'utilisateur signe d'abord, sur une interface de confiance et avec sa propre clé, un mandat ouvert où il fixe des conditions ; l'agent signe ensuite un mandat fermé avec la clé de l'agent, les deux étant liés par sd_hash. Le marchand ou le fournisseur d'identifiants peut renvoyer unresolved_constraint pour ramener le parcours à « humain présent ». La spécification recommande aussi aux marchands de signer le JWT de Checkout avec des signatures non déterministes (ECDSA) plutôt qu'avec Ed25519, afin de prévenir les attaques par table arc-en-ciel. Point essentiel : la spécification AP2 place le traitement des litiges, la conservation et la consultation hors périmètre (out of scope) et promet seulement une piste d'audit cryptographique non répudiable. Les notes de recherche relèvent en outre que la voie d'extension recommandée par la spécification AP2 est celle des extension points d'UCP, alors qu'A2A n'est même pas abordé dans le corps de la spécification ; AP2 glisse ainsi d'« une extension d'A2A » vers « une couche de sécurité au sein des protocoles de commerce ». Il s'agit d'une déduction.

Les extensions de paiement se greffent sur A2A par le mécanisme d'extension d'A2A lui-même : elles sont déclarées dans AgentCapabilities sous forme d'AgentExtension (uri, description, required, params), et le client en demande l'activation via l'en-tête A2A-Extensions. Une extension ne peut ni modifier les structures de données du noyau ni ajouter de valeurs enum, et ne peut agir que via metadata ; tout changement incompatible impose une nouvelle URI, et face à une version non prise en charge, la règle est « MUST NOT fall back ». a2a-x402 (spec v0.1) est une telle extension : le marchand envoie payment-required, le client signe et renvoie payment-submitted, puis, après règlement on-chain, le marchand renvoie payment-completed.

Les volumes de transactions x402 proviennent surtout de volume artificiel. Chainalysis dénombre plus de 100 millions de transactions x402 cumulées sur la chaîne Base jusqu'au premier trimestre 2026, mais le pic du quatrième trimestre 2025 était « principalement alimenté par le meme coin farming », et la rétention hebdomadaire est tombée de 87 % à 5 %. Coinbase a revendiqué fin avril 2026 environ 165 millions de transactions et environ 50 millions de dollars US cumulés ; il s'agit d'une affirmation du fournisseur. Artemis estime que plus de 95 % relèvent de signaux protocolaires ou de tests, et un autre site de suivi évalue le volume commercial réel à environ 28 000 dollars US par jour.

Dans les faits, réseaux de cartes et plateformes appliquent le principe « accepter plusieurs protocoles, avec une authentification forte en présence humaine comme soupape de sécurité ». En mars 2026, OpenAI a ramené Instant Checkout dans ChatGPT à un modèle d'Apps marchandes ; un porte-parole a déclaré : « Instant Checkout is moving to Apps ». Le 2026-07-02, Visa a annoncé que des agents avaient effectué de vrais achats en Europe, avec plus de 30 émetteurs partenaires, toutes les transactions utilisant des Payment Passkeys pour satisfaire à l'authentification forte du client (SCA). Le cadre de responsabilité reste vide : Chargebacks911 avertit que l'infrastructure de litiges et de responsabilité est « largely unaddressed » ; selon l'analyse de Taylor Wessing, dans le cadre européen, un achat par un agent dépassant les conditions fixées par le client serait en principe considéré comme une opération non autorisée ; Ant International, Visa et Mastercard n'ont commencé que le 2026-09-10 à explorer un cadre interopérable de Know-Your-Agent. La PSD3/le PSR de l'UE n'en sont qu'à la position du Conseil en première lecture adoptée le 2026-10-29 et ne sont pas encore publiés au Journal officiel (Official Journal) ; une recherche par mots-clés dans l'exposé des motifs du Conseil sur le PSR ne trouve aucune disposition sur l'IA ou les agents autonomes. Le CFPB américain n'a pas non plus publié de lignes directrices sur les paiements par agents.

La recherche académique met en évidence un autre angle mort. Debi et al. (IEEE IMNS 2026) ont soumis un agent d'achat AP2 à un red teaming et montré que l'injection de prompt indirecte et directe peut manipuler le classement des produits et extraire des données sensibles de l'utilisateur : un mandat signé ne protège pas le raisonnement qui précède la signature. Jiang et al. (arXiv:2609.00060) ont analysé formellement x402, MPP, ACP et AP2 avec Tamarin, en mettant en évidence les dépendances de sécurité qui naissent quand l'intention, les pouvoirs délégués et le règlement sont répartis entre plusieurs parties. Dans la logistique, l'« agentification » passe aujourd'hui par MCP : le serveur MCP de Flexport permet aux assistants IA des clients de réserver du fret aux tarifs négociés et d'obtenir un booking ID. Les notes de recherche n'ont trouvé aucun exemple de frais de transport réglés via AP2 ou x402.

Le communiqué du premier anniversaire de la Linux Foundation, daté du 2026-04-09, affirme qu'A2A compte plus de 150 organisations soutiens et des déploiements en production dans la chaîne d'approvisionnement, la finance, l'assurance et l'exploitation informatique ; il s'agit d'une affirmation du fournisseur : le communiqué ne nomme aucun utilisateur et ne fournit ni processus ni indicateurs de résultat. Les exemples les plus souvent cités, un article sur Microsoft Agent Framework pour .NET et le codelab Google de purchasing concierge, sont des exemples de code et non des comptes rendus de déploiement. Tyson Foods est souvent présenté comme un cas A2A de chaîne d'approvisionnement, mais apis.io attribue à son Agent Card A2A un score de 0/8, et ce que l'entreprise propose à ses partenaires commerciaux reste de l'EDI et des API.

La contre-preuve la plus directe vient des tests. En avril 2026, un auteur a prélevé dans un registre public 50 agents se déclarant compatibles A2A : seuls 0 à 2 environ servaient une carte valide au chemin well-known, et 0 ont répondu correctement à une tâche. Le même auteur a envoyé 24 requêtes à 12 organisations le 2026-09-09 et 36 requêtes à 18 organisations le 2026-10-27, et a obtenu 0 carte les deux fois. Les échantillons ont été choisis par l'auteur et ne constituent pas un recensement, mais ils vont dans le même sens. Ce qui fonctionne réellement, c'est l'interopérabilité au sein d'une même plateforme cloud : AWS AgentCore, Microsoft Foundry et Google Agent Registry.

Les données sur les architectures multi-agents elles-mêmes jouent aussi contre l'A2A inter-organisations. MAST (NeurIPS 2025 Datasets & Benchmarks Track) a analysé 1 642 traces d'exécution et identifié 14 modes d'échec répartis en trois catégories : conception du système, désalignement entre agents et vérification des tâches ; les 7 systèmes multi-agents open source de pointe étudiés affichaient des taux d'échec entre 41 % et 86,7 % (les auteurs rappellent que des benchmarks différents ne sont pas directement comparables). « Towards a Science of Scaling Agent Systems », d'auteurs issus notamment de Google Research et du MIT, a testé 180 configurations dans les versions v1/v2 et la version du blog Google : les configurations multi-agents indépendantes amplifiaient les erreurs 17,2 fois, les configurations à coordination centralisée 4,4 fois, et sur les tâches de raisonnement séquentiel, toutes les variantes multi-agents se dégradaient de 39 à 70 % ; la v3 du 2026-04-08, étendue à 260 configurations et 6 benchmarks, maintient les conclusions de 17,2 et 4,4 fois. Le blog d'ingénierie d'Anthropic (qui n'est pas un article évalué par les pairs) indique que son système de recherche multi-agents surpassait de 90,2 % l'agent unique Claude Opus 4, mais consommait environ 15 fois plus de jetons qu'une conversation ordinaire, et désigne comme peu adaptés les domaines « où tous les agents doivent partager le même contexte ou où les dépendances entre agents sont nombreuses ». L'A2A inter-organisations réunit justement toutes ces conditions défavorables : les deux parties ne partagent pas de contexte, il n'y a pas de vérificateur commun, et les processus commerciaux (devis→commande→paiement→expédition) sont séquentiels ; il s'agit d'une déduction.

Les lacunes d'ingénierie sont plus nombreuses que celles de la spécification. Les traces se rompent quand A2A délègue à l'agent suivant : le SDK Python ne crée que des spans locaux, et il n'existe aucun moyen standard de propager le W3C Trace Context entre agents (ticket #2103). Le SDK Rust communautaire a signalé 7 échecs au TCK, attribués après comparaison à des défauts de la suite de tests elle-même ; le même rapport indique que les SDK JS, Go et Java passent 21/21 sur les deux liaisons. Le trafic d'agents côté consommateurs reste lui aussi faible : HUMAN Security a mesuré en 2025 une hausse annuelle de 7 851 % du trafic d'agents, mais seuls 2,3 % concernaient des pages de paiement ; une source secondaire citant des données Cloudflare Radar d'août 2026 évalue les bots IA à environ 7 % des requêtes HTML, dont « agir en temps réel pour le compte d'utilisateurs » ne représente que 5,8 % ; multipliés, cela donne environ 0,4 %, un calcul qui est une déduction et n'a pas encore été confirmé sur les données brutes. Akamai avertit que les sites d'e-commerce se contentent de surveiller plus de 90 % des bots IA, alors que l'activité d'agents frauduleux augmente. Les notes de recherche n'ont trouvé aucune preuve que des agents personnels comme ChatGPT, Gemini ou Claude appellent via A2A des agents d'entreprises ordinaires ; il s'agit toutefois d'une simple absence de preuve, pas d'une confirmation officielle.

Les entretiens menés par des gouvernements et des organisations internationales montrent que le besoin est réel. Les OECD Artificial Intelligence Papers No. 65 rapportent en page 16 que les praticiens interrogés préfèrent les protocoles ouverts et voient dans les protocoles de communication d'agent à agent comme A2A un moteur important de la coordination multi-agents, tout en craignant l'enfermement dans l'écosystème d'un seul fournisseur.

Taïwan : la loi fondamentale sur l'intelligence artificielle compte 20 articles. L'article 3 définit l'intelligence artificielle comme un « système doté d'une capacité de fonctionnement autonome », ce qui peut englober les agents IA, mais le mot « agent » n'apparaît pas dans la loi ; l'article 4 énonce sept principes, dont l'autonomie et la supervision humaines, la transparence et l'explicabilité, et la redevabilité ; en vertu de l'article 16, le ministère des Affaires numériques promeut un cadre de classification des risques articulé avec les cadres internationaux ; l'article 17 impose au gouvernement de définir l'attribution de la responsabilité et ses conditions pour l'IA à haut risque, et de mettre en place des mécanismes de recours, d'indemnisation ou d'assurance ; l'article 18 impose aux administrations d'achever l'adaptation des réglementations concernées dans les deux ans suivant l'entrée en vigueur. Sur le fondement de l'article 16, le ministère des Affaires numériques a publié le 115-07-07 (calendrier Minguo) le Cadre de classification des risques de l'IA v1.0 (lettre Stratégie numérique n° 1150015933, d'effet immédiat), dans lequel le type de risque B6, « actions hors autorisation des agents IA autonomes », indique : « Les systèmes multi-agents sont plus susceptibles, du fait du déclenchement mutuel des agents, de provoquer des réactions en chaîne imprévues tant par les développeurs que par les utilisateurs, rendant difficile une intervention humaine corrective à temps. » Les lignes directrices du ministère de la Santé et du Bien-être sur l'IA générative dans les établissements de santé, diffusées par lettre le 115-05-29, précisent explicitement que les systèmes d'agents IA « ne relèvent pas encore du champ d'application des présentes lignes directrices ».

Le droit taïwanais existant s'applique aussi aux situations impliquant des agents. L'article 4 de la loi sur la protection des données personnelles dispose que quiconque collecte, traite ou utilise des données personnelles sur mandat est, dans le champ de la loi, assimilé à l'organisme mandant ; confier des données personnelles à un agent n'exonère donc pas de responsabilité au motif que « c'est une IA qui agit ». L'article 21 encadre les restrictions aux transferts internationaux. À noter : plusieurs articles modifiés le 114-11-11 (dont la nouvelle version de l'article 21 et le nouvel article 20-1) ont été promulgués mais ne sont pas encore en vigueur, la date d'entrée en vigueur devant être fixée par le Yuan exécutif. La loi sur les signatures électroniques ne mentionne ni l'IA ni les agents ; la question de savoir si une signature apposée par un agent pour le compte d'une personne peut être présumée être la signature de cette personne n'est pas tranchée par la loi et ne peut être confirmée par cet article.

Chine : par l'avis de normes nationales n° 22 de 2026, l'Administration d'État pour la régulation du marché (SAMR) et l'Administration de normalisation de Chine (SAC) ont approuvé et publié le 2026-05-22 la série GB/Z 185.1–185.7-2026 « Intelligence artificielle – Interconnexion des agents intelligents », soit 7 documents techniques d'orientation (architecture générale, code d'identité, gestion de l'identité, description des agents, découverte des agents, interaction des agents et appel d'outils par les agents). La National Public Service Platform for Standards Information indique leur statut « en vigueur », les textes intégraux ont été rendus publics le 2026-06-18, et la SAMR a tenu une conférence de presse dédiée le 2026-06-26. Le nom de protocole utilisé dans les documents officiels est AIP (Agent Interconnection Protocol) ; aucune des pages officielles trouvées ne mentionne A2A ou MCP, et la compatibilité entre les deux n'est pas établie. Les Avis de mise en œuvre sur l'application normalisée et le développement innovant des agents intelligents, publiés conjointement le 2026-05-08 par l'Administration du cyberespace de Chine (CAC), la Commission nationale du développement et de la réforme (NDRC) et le ministère de l'Industrie et des Technologies de l'information (MIIT), associent en un seul ensemble la promotion d'AIP, une plateforme d'enregistrement des agents et l'identité numérique des agents, et exigent que « les opérations exécutées par les agents ne dépassent pas le périmètre autorisé par l'utilisateur ». Cette approche diffère de celle de la communauté A2A, qui ne prévoit « pas de registre officiel ».

UE : l'AI Act (règlement (UE) 2024/1689) est entré en vigueur le 2024-08-01 ; les obligations relatives aux modèles d'IA à usage général s'appliquent depuis le 2025-08-02, l'application générale et les obligations de transparence à partir du 2026-08-02. Les obligations relatives au haut risque ont été reportées par le règlement (UE) 2026/1744 (publié au Journal officiel le 2026-07-24) : l'annexe III au 2027-12-02 et l'annexe I au 2028-08-02. Pour la PSD3 et le PSR, le Conseil a adopté sa position en première lecture le 2026-10-29 ; la deuxième lecture au Parlement européen reste à venir, et aucune publication au Journal officiel n'a eu lieu.

États-Unis, Singapour, Royaume-Uni : la CISA, la NSA et d'autres agences des Five Eyes ont publié le 2026-04-30/05-01 « Careful Adoption of Agentic AI Services », qui recommande de restreindre les droits d'accès et de commencer par des cas d'usage à faible risque et non sensibles. Le CFPB américain n'a pas de lignes directrices sur les paiements par agents, et sa proposition de règle interprétative de 2025 sur le sujet a été retirée le 2025-05-15. Le Model AI Governance Framework for Agentic AI v1.5 de l'IMDA de Singapour (publié le 2026-05-20, mis à jour le 06-05) cite directement, à la section 1.1.1, A2A pour la communication entre agents et MCP pour la communication entre agents et outils, et désigne la délégation récursive et l'identité inter-organisations comme des lacunes actuelles. Les lignes directrices de la CMA britannique publiées le 2026-03-09 (mises à jour le 10-30) indiquent « if an AI agent you use does something illegal, you are responsible » : les entreprises répondent des actes illicites des agents qu'elles utilisent. L'appel à contributions de l'ICO britannique sur l'IA agentique se clôt le 2026-11-20.

Le ticket #1942 a regroupé 41 sujets en huit thèmes pour la v1.1 ; la mémoire des agents d'une tâche à l'autre (#893) est hors du périmètre suivi. Les tickets les plus commentés en disent plus sur l'orientation que la liste des thèmes : #1672, vérification de l'identité des agents dans l'Agent Card (environ 658 commentaires) ; #1829, signature des messages avec Ed25519 et la RFC 9421 ; #2028, délégation par actor-chain ; #2121, transmission des coûts et du budget ; et #1815, utilisation du code HTTP 402 pour signaler « paiement requis ». Ce sont tous des problèmes de confiance et de commerce ; compte tenu du nouveau processus de gouvernance des extensions, les notes de recherche estiment qu'ils arriveront plus probablement sous forme d'extensions que de modifications de la spécification de base. Il s'agit d'une déduction.

La question « comment un agent personnel trouve-t-il l'agent d'une entreprise ? » n'a aujourd'hui aucune réponse ouverte déployée. La documentation officielle d'A2A précise explicitement que les registres curatés sont hors du périmètre d'A2A ; la proposition d'Agent Registry de la Discussion #741 traîne depuis longtemps, les relecteurs contestant son postulat selon lequel « les fournisseurs gèrent eux-mêmes leurs entrées ». Pour trouver un agent à partir d'un domaine, l'IETF compte quatre projets individuels concurrents : DNS-AID (un enregistrement SVCB pointant vers /.well-known/agent-card.json), AID (consultation d'un enregistrement TXT _agent), ADP et DAN, dont aucun n'a encore été adopté par un groupe de travail ; un projet de panorama (landscape) de juillet 2026 souligne en outre que l'espace de noms doit être coordonné. Côté MCP, le MCP Registry est en préversion depuis septembre 2025 et l'est toujours.

L'audit et la responsabilité inter-organisations n'ont pas davantage de cadre. La spécification A2A ne comporte que des exigences de niveau SHOULD sur la journalisation des échecs d'authentification et la limitation de débit, et les sources se contredisent sur le statut de stabilité des conventions sémantiques GenAI d'OpenTelemetry. Avec les outils actuels, l'unité d'audit minimale que l'on peut conserver est à peu près : le taskId et le contextId de son propre côté, l'empreinte de la signature de l'Agent Card de l'autre partie et la chaîne de délégation act du jeton présenté par l'autre partie, chaque partie les conservant pour un rapprochement ultérieur ; il s'agit d'une déduction. Les notes de recherche n'ont pas non plus trouvé de recherche empirique sur les attaques de type denial-of-wallet visant à « épuiser le budget LLM de l'autre partie ».

A2A ressemble aujourd'hui beaucoup aux débuts du HTTP : le format est standardisé, la couche de confiance reste à ajouter par chacun ; la différence, c'est que cette fois la partie appelée raisonne elle-même et peut même être persuadée par l'autre partie. Le goulet d'étranglement n'est donc pas technique mais tient à la question « qui répond des actes de l'agent ? », aujourd'hui éclatée entre l'IETF (identité), la FIDO Alliance (intention de paiement), les réseaux de cartes (litiges) et les régulateurs nationaux, hors de portée du TSC d'A2A. Nous en déduisons que la forme la plus probable de l'interopérabilité d'agents inter-entreprises dans les prochaines années sera « une enveloppe A2A autour d'appels d'outils déterministes » : la partie appelée ressemble en surface à un agent mais est en réalité une API, et le vrai raisonnement n'a lieu qu'à l'intérieur de la frontière de confiance de chaque entreprise.

Les lignes directrices gouvernementales vont dans le même sens. La CISA, la NSA et d'autres agences des Five Eyes recommandent de commencer par des cas d'usage à faible risque et non sensibles et de restreindre les droits d'accès ; le cadre de l'IMDA de Singapour fait de « la responsabilité effective des humains » et des contrôles techniques des axes centraux ; le ministère taïwanais des Affaires numériques classe comme risque B6 les réactions en chaîne nées du déclenchement mutuel des agents ; et la CMA britannique affirme clairement que les entreprises répondent des actes illicites des agents qu'elles utilisent.

Le tableau ci-dessous classe les options d'adoption pour une entreprise ordinaire selon la solidité des preuves. « À faire » signifie un risque faible et un bénéfice clair au vu des preuves actuelles ; « Possible » signifie un coût faible mais aucun cas mesuré ; « À reporter » et « À éviter » sont chacun motivés, et seront réévalués lorsque des conditions de déclenchement apparaîtront.

Les requêtes centrales de l'e-commerce transfrontalier et de la logistique – combien coûte l'envoi, à combien s'élèvent les taxes, quels sont le code tarifaire et les règles d'importation de ce produit – sont par nature des calculs déterministes : c'est précisément le type de service dont les agents externes ont le plus besoin et sur lequel ils se trompent le moins. Selon le blog d'ingénierie d'Anthropic, la seule réécriture des descriptions d'outils a réduit de 40 % le temps d'exécution des tâches pour les agents suivants ; le retour d'Instant Checkout vers les Apps marchandes chez OpenAI montre que les transactions finissent par revenir dans le parcours propre du marchand. L'ordre de préparation devrait donc être : d'abord rendre les pages web et les données structurées lisibles, puis transformer les outils déterministes en MCP, ajouter dans les réponses des outils des URL de reprise qui ramènent les transactions vers son propre parcours, et seulement ensuite envisager un emplacement A2A.

Une carte A2A de réservation (placeholder) consiste à publier à /.well-known/agent-card.json une carte dont les compétences correspondent à des outils déterministes existants, comme les devis, les taxes ou les informations de processus, avec derrière des appels directs à des programmes, sans LLM. Cette démarche est peu coûteuse et relève de la « valeur d'option », mais il n'existe à ce jour aucun cas mesuré d'une PME ayant gagné du trafic ou du chiffre d'affaires grâce à elle ; il s'agit d'une déduction. Si l'on ouvre réellement un point de terminaison A2A, il faut au minimum : n'exposer que des compétences en lecture seule, ne se fier à aucun champ de la carte de l'autre partie, refuser les IP privées dans les URL de push, et journaliser taskId, contextId, identité de l'appelant et traceparent.

Ce que fait HowBridge aujourd'hui (tout est vérifiable sur la page développeurs de HowBridge) : HowBridge propose un MCP public sans clé API ni OAuth (https://0523.tw/mcp/public), qui comprend 8 outils en lecture seule et idempotents : présentation de la marque et des services HowBridge, estimation des frais de groupage de la Chine vers Taïwan (express maritime/fret aérien), estimation des taxes à l'importation à Taïwan, codes tarifaires CCC candidats à partir du nom du produit, taux tarifaires CCC et règles d'importation, frais de hors-gabarit pour la livraison à Taïwan, et processus de groupage et règles de déclaration simplifiée ; la limite est de 120 requêtes par minute et par IP, et le MCP est inscrit au MCP Registry officiel (nom tw.0523/lucky-public). Les réponses d'estimation des frais d'envoi contiennent une URL de reprise (continue_url) qui permet à l'utilisateur de poursuivre sur le site. Le MCP membres (https://0523.tw/mcp) utilise une autorisation OAuth 2.1 et propose 6 outils en lecture seule qui ne peuvent lire que les factures, colis, préavis, avis d'imposition et déclarations d'importation du membre autorisé lui-même, avec par défaut 60 requêtes par minute et 5 000 par jour. Les points d'accès actuellement listés sur la page développeurs de HowBridge sont l'API de données membres, le MCP membres et le MCP public ; il n'y a pas de point de terminaison A2A, et cet article ne signifie pas que HowBridge prend en charge A2A.

Si vous souhaitez qu'un assistant IA vous aide à estimer le coût d'un envoi de la Chine vers Taïwan, vous pouvez utiliser directement les versions web du calculateur de frais de groupage, du calculateur de droits d'importation et de la recherche de codes tarifaires ; ces outils et le MCP public partagent la même logique de calcul. Les estimations sont fournies à titre indicatif : les frais d'envoi définitifs sont ceux de la facture établie après mesure à l'entrée en entrepôt, et les taxes sont celles fixées par la douane.