Économie des agents et protocoles d'interopérabilité

Autorise les achats initiés par un agent au moyen d'une chaîne de mandats signés cryptographiquement sous forme de justificatifs vérifiables, plutôt qu'en confiant à l'agent les données brutes d'une carte bancaire. Un Intent Mandate capture les contraintes définies à l'avance par l'utilisateur (prix maximal, marchands autorisés, durée de validité), permettant à l'agent d'acheter en l'absence de l'utilisateur ; un Cart Mandate, signé par le marchand et co-signé par l'utilisateur, porte sur les articles et le prix exacts, garantissant que ce que vous voyez est ce que vous payez ; et un Payment Mandate est partagé avec le réseau de paiement. La chaîne signée constitue une piste d'audit non répudiable qui règle les questions d'autorisation, d'authenticité et de responsabilité pour les dépenses autonomes, et elle est indépendante du rail de paiement, avec un profil A2A-x402 pour les rails crypto. À distinguer de authenticated-delegation : ce modèle confère à un agent une autorité délimitée pour agir, tandis qu'AP2 lie chaque achat spécifique à une chaîne de mandats signés qu'un réseau de paiement peut vérifier de manière indépendante.

Standard ouvert co-développé par Stripe et OpenAI (Apache-2.0, septembre 2025) pour finaliser un achat auprès d'un marchand qui demeure le marchand de référence (merchant of record). Le marchand expose des points de terminaison REST ou MCP destinés aux agents (créer, mettre à jour, finaliser et annuler un paiement) au-dessus d'un flux de produits ; l'agent paie au moyen d'un Shared Payment Token émis par Stripe et limité à un seul marchand et au montant total du panier, de sorte que l'agent ne voit jamais les identifiants de carte de l'acheteur. Il a été lancé comme le standard qui sous-tend ChatGPT Instant Checkout avec les vendeurs Etsy et les marchands Shopify. À distinguer de `model-context-protocol` : MCP est un transport générique d'appel d'outils, tandis qu'ACP est un contrat de paiement spécifique qui peut s'appuyer sur MCP ou sur du REST simple.

Standard de paiement ouvert créé par Coinbase en 2025 et désormais géré par la x402 Foundation sous l'égide de la Linux Foundation, qui ranime le code d'état HTTP 402 Payment Required jusque-là inutilisé pour en faire un rail de paiement à la requête. Un serveur répond 402 avec des exigences de paiement lisibles par machine ; le client (humain ou agent) renvoie un paiement en stablecoin signé dans un en-tête HTTP ; un facilitateur vérifie la charge utile et règle le transfert on-chain (chaînes EVM, Solana, et d'autres), le tout au sein d'une seule requête, sans comptes, sessions ni clés API. C'est un rail natif pour des micropaiements d'agent à service sans clé et inférieurs au centime, ainsi que pour un accès mesuré aux outils ou aux données ; c'est également le profil crypto référencé par l'extension A2A-x402 d'AP2. À distinguer de `agentic-commerce-protocol` : ACP est un paiement de détail par carte via un marchand de référence, tandis que x402 est un paiement machine par appel réglé on-chain.

La couche de découverte qui permet aux agents et aux serveurs d'outils de se trouver mutuellement à l'exécution plutôt que via une configuration codée en dur. Trois mécanismes convergents rendent cela possible : les A2A Agent Cards, un manifeste JSON auto-descriptif servi à /.well-known/agent-card.json (RFC 8615) qui annonce les compétences, les points de terminaison, les schémas d'authentification et les capacités de streaming d'un agent ; le MCP Registry officiel (préversion en septembre 2025), un catalogue public fédéré et une API pour publier et trouver des serveurs MCP, extensible par des sous-registres privés d'entreprise ; et des propositions de nommage décentralisé telles que MIT Project NANDA, dont le NANDA Index résout des enregistrements AgentFacts cryptographiquement vérifiables vers des points de terminaison, positionné comme un DNS pour les agents. Le schéma courant consiste à publier un enregistrement de capacité signé, puis à le résoudre par une URI bien connue ou une requête au registre, à valider les schémas d'authentification annoncés et à lier l'agent dynamiquement. À distinguer de `a2a-protocol` : celui-ci couvre le transport des messages une fois qu'un pair est connu, tandis qu'il s'agit ici de trouver et de valider ce pair au préalable.

Des contrats côté offre qui exposent le contenu d'un site directement aux agents, au lieu de les contraindre à extraire le HTML rendu. llms.txt (Jeremy Howard, 2024) est un index Markdown curé, situé à /llms.txt, complété par des pages « fantômes » .md qui fournissent à un LLM un contenu à haute densité et sans navigation au moment de l'inférence. Microsoft NLWeb (2025, sous la direction de R.V. Guha, co-créateur de Schema.org) va plus loin avec un point de terminaison en langage naturel /ask qui renvoie du JSON structuré ancré dans les données Schema.org du site lui-même, chaque instance NLWeb faisant également office de serveur MCP. Ensemble, ils définissent le site lisible par les agents, le pendant côté lecture de robots.txt pour le web agentique.

Un standard émergent, à l'état de brouillon IETF (Cloudflare et Google), qui permet à un agent de prouver cryptographiquement son identité à un site web à l'aide des HTTP Message Signatures de la RFC 9421. L'agent signe chaque requête sortante avec une clé Ed25519, publie ses clés publiques sous forme d'un répertoire de clés JWKS à /.well-known/http-message-signatures-directory, et le désigne via un en-tête Signature-Agent ; l'origine récupère le répertoire, vérifie la signature et décide d'autoriser, de refuser, de limiter le débit ou de tarifer le trafic. Il remplace les listes d'autorisation fragiles fondées sur des plages IP et l'User-Agent, et les Signed Agents de Cloudflare le transforment en produit à la périphérie (edge). À distinguer de authenticated-delegation : celui-ci prouve l'autorité de l'utilisateur envers l'agent, tandis que Web Bot Auth fait l'inverse, un agent prouvant son origine à un site web.

Des standards émergents, pour la plupart à l'état de brouillon, définissant la manière dont un agent évalue le risque de contrepartie face à un agent inconnu, sans intermédiaire central. Le brouillon d'EIP ERC-8004 « Trustless Agents » définit trois registres on-chain : Identity (un identifiant ERC-721 pointant vers des métadonnées d'agent off-chain), Reputation (signaux de retour signés) et Validation (attestations de contrats validateurs, comme la ré-exécution sécurisée par mise en jeu de fonds ou les oracles TEE), en gardant délibérément les paiements et la logique applicative hors chaîne. Une taxonomie complémentaire des modèles de confiance classe les mécanismes en six catégories (brief, claim, proof, stake, reputation et constraint), en soutenant qu'aucun mécanisme isolé ne suffit et que des combinaisons à plusieurs niveaux sont nécessaires. Le domaine est précoce et encore instable : ERC-8004 est un brouillon d'EIP et une grande partie de l'outillage n'en est qu'à ses débuts. À distinguer de authenticated-delegation : ce dernier relève de l'autorité déléguée et de l'identité, tandis qu'il s'agit ici d'une confiance de réputation évaluée entre pairs économiques.