AP2: Le Protocole de Paiements par Agents

Ceci est une plongée technique approfondie dans AP2 v0.2, le système de mandat cryptographique derrière les paiements d’agents autonomes. Je l’ai écrit après avoir construit une démo réelle sur Camunda 8, et j’ai vérifié chaque affirmation par rapport à la spécification sur ap2-protocol.org, et non à la couverture médiatique. La plupart des articles de la semaine de lancement utilisent une terminologie que la spécification actuelle a déjà remplacée. Je le signalerai là où c’est pertinent.

Le problème qu’il résout

« Donneriez-vous votre carte de crédit à une IA ? » C’est la question à laquelle j’ai cherché à répondre pour l’EP 03 de Agents, Orchestrated. Le protocole qui y répond correctement est AP2.

Un agent capable de dépenser de l’argent est fondamentalement différent d’un agent capable de répondre à des questions. Lorsqu’un agent appelle une API de recherche et se trompe, vous obtenez un mauvais résultat. Lorsqu’il appelle une API de paiement et se trompe, vous perdez de l’argent.

La réponse traditionnelle est : exiger une présence humaine au moment du paiement. Cliquer sur Approuver. Saisir un OTP. Ce qui est bien, jusqu’à ce que l’agent soit censé acheter au moment où les prix des billets de la FIFA chutent à 2h du matin pendant que vous dormez.

AP2 résout un problème spécifique : comment un humain délègue-t-il une autorité de dépense à un agent d’une manière qui soit cryptographiquement limitée, vérifiable par chaque partie de la chaîne, et exécutoire sans faire appel à une autorité centrale ?

La réponse, ce sont les mandats. C’est tout le protocole.

Ce qu’est AP2 : faits clés

AP2 = Agent Payments Protocol. Le standard ouvert de Google pour les paiements initiés par des agents, annoncé le 16 septembre 2025, avec plus de 60 partenaires de lancement, dont Mastercard, PayPal, American Express, Coinbase et Salesforce.

Fait	Détail
Version actuelle	v0.2, publiée en avril 2026 (GitHub : google-agentic-commerce/AP2)
Partenaires de lancement	60+ (Mastercard, PayPal, AmEx, Coinbase, Salesforce)
Standardisation	FIDO Alliance (Google a fait don d’AP2 au groupe de travail technique Agentic Auth + Payments)
Implémentations de référence	5 langages : Python, Go, TypeScript, Kotlin, Android

Points clés à savoir d’emblée :

• AP2 est une extension du protocole A2A (Agent-to-Agent, le standard de messagerie pair-à-pair de Google pour les agents). Il ajoute la sémantique des mandats de paiement au-dessus du transport d’A2A.
• Il s’intègre au Universal Commerce Protocol (UCP) en tant que couche de commerce/paiement.
• Il prend en charge x402 / stablecoins (USDC) comme rail de paiement de première classe, et non comme une solution de dernier recours. Cela est important pour les micro-transactions où l’interchange de carte (0,50 $ à 0,80 $) dépasse la valeur de la transaction.
• La source de vérité de la spécification est ap2-protocol.org, et non la couverture médiatique. La plupart des articles de septembre 2025 utilisent une terminologie obsolète. Je le signalerai là où c’est pertinent.

Où AP2 se situe dans la pile

C’est la chose que j’aurais aimé que quelqu’un me dessine clairement dès le premier jour. La pile du commerce agentique comporte cinq couches distinctes : différents protocoles, différentes organisations, différents problèmes résolus.

Couche	Protocole	Ce qu’il fait	Responsable
1	MCP	Model Context Protocol. Découverte et outillage : comment les LLM découvrent et invoquent des capacités externes	Anthropic
2	A2A	Agent-to-Agent Protocol. Transport : messagerie HTTP pair-à-pair entre les rôles d’agent via la découverte AgentCard	Google
3	AP2 (vous êtes ici)	Autorisation de paiement : chaîne de mandats signés cryptographiquement, SD-JWT, ECDSA P-256, W3C Verifiable Credentials	Google / FIDO
4	ACP / UCP	Endpoints HTTP de paiement, assemblage du panier, sémantique d’exécution des commandes	Spécification ouverte
5	Cartes, FedNow, x402	Rails de règlement : Mastercard, Visa, UPI, Pix, stablecoins USDC	Réseaux

MCP définit ce qu’un agent peut lire et appeler. ACP définit comment un agent achète. AP2 définit comment l’intention de l’utilisateur et la facturation du commerçant sont cryptographiquement attestées.

Ces couches se composent. Vous utilisez MCP pour donner des outils à un agent. Ces outils invoquent des endpoints A2A pour envoyer des messages à d’autres agents. AP2 fournit les identifiants d’autorisation signés qui accompagnent ces messages. ACP/UCP définit l’API de paiement que le commerçant expose. Les rails règlent l’argent.

Figure 1 : La pile du commerce agentique à cinq couches. AP2 se situe à la couche 3, entre le transport et le règlement, fournissant la chaîne d’autorisation cryptographique.

Les quatre parties

AP2 définit quatre rôles nommés. Chaque transaction implique certains ou tous ces rôles :

Rôle	Ce qu’ils font	Exemples concrets
Shopping Agent	Surveille les prix, prend des décisions, agit au nom de l’utilisateur dans les limites des mandats	Claude Sonnet, agents d’achat Gemini, tout agent LLM
Merchant Agent	Expose un endpoint de panier compatible AP2, vérifie les Checkout Mandates, exécute les commandes	TicketVault, tout backend de commerçant conforme à l’ACP
Credentials Provider	Vérifie les deux mandats, émet des titres de paiement à l’Agent d’achat	Mastercard Agent Pay, PayPal, Visa
Processeur de paiement	Règle la transaction par rapport à l’instrument de financement	Réseaux de cartes, FedNow, Coinbase (x402)

La Surface de Confiance est un concept spécial : le client compatible AP2 (portefeuille ou application) où l’utilisateur signe les mandats. Considérez-la comme l’autorité de signature numérique de l’utilisateur. Elle détient la clé privée ECDSA de l’utilisateur et produit les mandats ouverts avant que l’Agent d’achat n’agisse de manière autonome.

Le système de mandats : le mécanisme central

Note terminologique : de nombreux articles utilisent encore le cadre à trois mandats de la semaine de lancement (Intent Mandate, Cart Mandate, Payment Mandate). La spécification v0.2 restructure cela en deux types de mandats avec deux étapes chacun. L’ancien cadre est obsolète ; utilisez la terminologie v0.2.

Deux types de mandats

Mandat	Partagé avec	Ce qu’il capture
Checkout Mandate	Agent commerçant	Autorité d’achat, portée des articles, plafond de prix, liste blanche des commerçants, TTL
Payment Mandate	Fournisseur de titres / Réseau	Autorité de facturation, token d’instrument de financement, plafond de montant, restrictions de catégorie

Étapes ouvertes vs fermées

La distinction entre ouvert et fermé est le mécanisme entier pour les paiements sans présence humaine.

	Étape ouverte	Étape fermée
Quand créé	Lors de la configuration du mandat, humain présent	Au moment de l’achat, humain non présent
Signé par	Clé du portefeuille de l’utilisateur (ECDSA)	Clé de l’agent (ECDSA)
Contenu	Contraintes, portée, TTL, listes blanches	Panier spécifique / montant exact, hachage de paiement
Objectif	Autorité permanente	Preuve spécifique à la transaction

Exemple concret : scénario de billets FIFA

Checkout Mandate, ouvert : « J’autorise mon agent à acheter jusqu’à 2 billets FIFA Cat 3 chez TicketVault, max 1 500 $ chacun, expire dans 24h. »

Checkout Mandate, fermé : « J’achète 2 × Cat 3 à 1 350 $ chacun, total 2 700 $, checkout_hash: 0xABC... »

Le Payment Mandate fermé ne peut être créé qu’après la fermeture du Checkout Mandate. Il doit inclure le checkout_hash du Checkout fermé. La spécification impose cette dépendance séquentielle.

Figure 2 : Cycle de vie des mandats. Les mandats ouverts sont signés par l’utilisateur lors de la configuration. Les mandats fermés sont signés par l’agent au moment de l’achat. Le Payment Mandate nécessite le hachage du Checkout Mandate fermé.

À quoi ressemble un mandat

// Simplified mandate JSON (encoded as SD-JWT in practice)
{
  "id": "mandate_7A3F2026",
  "type": "checkout.open",
  "vct": "mandate.checkout.1",       // schema version, must match exactly
  "user_did": "did:key:z6Mk...",     // DID of user's wallet key
  "agent_did": "did:key:z6Mk...",    // DID of shopping agent
  "constraints": {
    "item_scope": "event-tickets",
    "max_unit_price": 1500,
    "max_quantity": 2,
    "currency": "USD",
    "merchant_allowlist": ["ticketvault.com"],
    "ttl": "2026-07-12T00:00:00Z"
  },
  "signature": "ECDSA_P256_sig_by_user_key..."  // MUST be ECDSA, NOT Ed25519
}

La cryptographie : pourquoi c’est un protocole, et pas seulement un enregistrement de base de données

Beaucoup de solutions de « paiements agentiques » ne sont que des enregistrements de base de données : l’utilisateur coche une case, l’application écrit authorized=true, l’agent le lit. Cela se brise dès que vous avez plusieurs parties qui ne se font pas confiance intrinsèquement.

Les mandats AP2 sont des SD-JWT (Selective Disclosure JSON Web Tokens) signés avec ECDSA P-256. La spécification est explicite : le JWT de Checkout DOIT être signé en utilisant ECDSA et NE DOIT PAS utiliser Ed25519.

Pourquoi ECDSA, et non Ed25519 ?

C’est subtil et cela mérite d’être compris. Ed25519 est déterministe : étant donné le même message et la même clé privée, il produit toujours la même signature. Cela signifie que deux mandats identiques produisent le même hachage de signature. Un attaquant qui collecte des signatures au fil du temps peut construire une table arc-en-ciel contre la revendication checkout_hash intégrée dans le mandat. ECDSA inclut un nonce aléatoire par opération de signature, de sorte que chaque signature est unique même pour des contenus de mandat identiques. Aucune attaque par table arc-en-ciel n’est possible.

La formule cryptographique

// From the CSA security framework for AP2
Sig_U(M) = ECDSA.Sign(K_U, Hash(M))

// Verification: any party can run this independently
Verify(M, Sig, PubKey_U) → boolean

// No API call to any central server required
// The credential is self-contained proof

Les cinq garanties cryptographiques

1. Preuve d’altération : toute modification du mandat après signature rompt la signature ECDSA. Le commerçant ou le fournisseur de titres la rejettera.
2. Non-répudiation : l’utilisateur ne peut pas nier avoir signé le mandat ouvert. Sa clé privée est l’autorité de signature.
3. Portabilité : chaque partie de la chaîne vérifie indépendamment en utilisant la clé publique de l’utilisateur (via DID). Aucune autorité centrale. Pas de rappel à la maison.
4. Application de la portée : le mandat fermé doit satisfaire toutes les contraintes du mandat ouvert, sinon la vérification échoue. L’agent ne peut pas dépasser la portée pré-autorisée par l’utilisateur.
5. Divulgation sélective : SD-JWT permet à un commerçant vérifiant un Checkout Mandate de voir les champs d’article et de prix sans voir le token de l’instrument de financement. Les champs sont révélés sélectivement par partie.

Les champs de charge utile sensibles (comme les tokens d’instrument de financement) sont chiffrés avec AES-GCM-256 avant d’être intégrés dans le JWT. Pour les transactions de grande valeur, la spécification recommande la signature de clé assistée par matériel (TPM/HSM).

AP2 utilise des Identifiants Décentralisés (DIDs) pour la découverte des clés d’émetteur : pas d’autorité de certification, pas de hiérarchie PKI à laquelle faire confiance. La vérification est purement cryptographique.

Modèle de menace

AP2 utilise STRIDE pour son modèle de menace, étendu par le framework MAESTRO pour les écosystèmes multi-agents. Il est important de le savoir car cela montre exactement ce qu’AP2 a été conçu pour contrer.

Menace (STRIDE)	Attaque	Atténuation AP2
Usurpation d’identité	Signatures de mandat forgées revendiquant une fausse autorisation	Vérification PKI basée sur DID, clés assistées par HSM
Altération	Contenu du mandat altéré en transit (changer le prix, la portée)	La signature ECDSA se rompt à toute modification, TLS 1.3
Répudiation	« Je n’ai jamais autorisé cet achat »	Signature ECDSA non-répudiable sur mandat ouvert plus piste d’audit
Divulgation d’informations	Instrument de paiement exposé au commerçant	AES-GCM-256 sur les champs sensibles, divulgation sélective SD-JWT
Élévation	L’agent dépasse la portée du mandat (achète quelque chose non autorisé)	Contraintes du mandat ouvert vérifiées cryptographiquement dans le mandat fermé
Fraude par hallucination	Le LLM achète la mauvaise chose en raison d’une erreur de modèle	Tous les achats ancrés à l’intention signée de l’utilisateur, et non à la sortie probabiliste du modèle
Coercition d’agent	Le commerçant trompe l’agent pour qu’il achète en dehors du mandat	Vérification du commerçant basée sur DID plus merchant_allowlist dans le mandat ouvert

MAESTRO étend cela aux menaces multi-agents émergentes : empoisonnement de modèle, détournement de workflow, collusion d’écosystème. Pour les transactions de grande valeur, la spécification recommande des exigences de consensus multi-agents avant la clôture du mandat.

Les flux : avec présence humaine et sans présence humaine

Flux avec présence humaine

Le cas le plus simple. L’utilisateur est devant son clavier au moment du paiement. La Surface de Confiance présente le panier spécifique à l’utilisateur pour signature avant de clôturer les mandats.

1. L’Agent d’achat assemble le panier chez le Commerçant via l’endpoint ACP
2. L’agent présente le panier et les mandats ouverts à la Surface de Confiance (portefeuille ou application de l’utilisateur)
3. L’utilisateur examine et signe, produisant le Checkout Mandate fermé (signé par l’utilisateur, panier spécifique)
4. L’utilisateur signe le Payment Mandate fermé (référence le hachage du Checkout)
5. L’agent présente les deux mandats fermés au Fournisseur de titres
6. Le Fournisseur de titres vérifie et émet un titre de paiement
7. L’agent finalise le paiement chez le Commerçant avec le titre. Le règlement suit.

Flux sans présence humaine (la fonctionnalité phare de la v0.2)

C’est celui qui compte pour le commerce agentique. L’utilisateur a défini des contraintes à l’avance ; l’agent agit de manière autonome lorsque le déclencheur se manifeste, potentiellement des heures ou des jours plus tard.

L’étape 0 est primordiale. La phase de configuration est celle où l’humain est présent. Après cela, l’agent agit de manière entièrement autonome. La cryptographie applique la limite, et non un humain approuvant chaque transaction.

Configuration (humain présent, une fois) : l’utilisateur signe un Checkout Mandate ouvert (contraintes, TTL, portée du commerçant) ainsi qu’un Payment Mandate ouvert (instrument, plafond de montant). Les deux sont stockés par l’Agent d’achat / la Surface de Confiance.

… le temps passe. L’utilisateur s’endort. Le prix baisse à 2h du matin. Le déclencheur se manifeste …

1. L’Agent d’achat détecte la condition de déclenchement (prix égal ou inférieur à la cible)
2. L’agent interroge le Commerçant et reçoit un Cart Mandate (signé par le commerçant, SKU et prix spécifiques)
3. L’agent vérifie que le panier satisfait toutes les contraintes du Checkout Mandate ouvert (prix égal ou inférieur au plafond, commerçant dans la liste blanche, TTL non expiré)
4. L’agent signe le Checkout Mandate fermé (clé de l’agent, panier spécifique, checkout_hash)
5. L’agent présente le Checkout Mandate fermé au Commerçant, qui vérifie les signatures ouverte (utilisateur) et fermée (agent)
6. L’agent signe le Payment Mandate fermé (référence le checkout_hash de l’étape 4)
7. L’agent présente les deux mandats au Fournisseur de titres, qui vérifie la chaîne complète
8. Le Fournisseur de titres émet le titre de paiement
9. L’agent finalise le paiement chez le Commerçant avec le titre. Le règlement a lieu ; la piste d’audit est complète.

Figure 3 : Flux sans présence humaine. Quatre parties, deux types de mandats, neuf étapes numérotées. La chaîne entière est liée cryptographiquement.

Comment cela se connecte au commerçant : ce n’est pas MCP

La question que je me posais sans cesse au début : comment le mandat passe-t-il réellement de mon agent à TicketVault ?

La réponse : via des appels HTTP A2A, et non MCP.

MCP est la couche d’outils et de contexte. C’est ainsi que Claude (ou tout LLM) accède à search_inventory ou create_mandate en tant qu’outils appelables. Ce que le LLM fait avec ces outils (les messages entre l’Agent d’achat et l’Agent commerçant) est A2A. Les titres de mandat sont la charge utile, et non les résultats des outils MCP.

MCP définit ce qu’un agent peut lire et appeler. Les mandats sont transportés avec les appels A2A en tant qu’artefacts de preuve, et non générés par MCP lui-même.

Dans un déploiement AP2 réel, le flux vers TicketVault serait :

1. L’Agent d’achat envoie un Checkout Mandate signé (SD-JWT) à l’endpoint A2A du commerçant AP2 de TicketVault via une requête POST
2. L’agent commerçant de TicketVault valide : vérification de la signature, puis vérification des contraintes, puis correspondance du hachage de paiement
3. TicketVault renvoie un reçu de paiement (signé par le commerçant)
4. L’Agent d’achat transmet ce reçu et le Payment Mandate à l’endpoint A2A du Fournisseur de titres

Dans notre démo, nous simulons cela au sein d’un seul BFF Node.js : les workers Camunda jouent les rôles d’agents distribués, et les événements SSE remplacent les appels A2A entre eux. Les mécanismes sont réels ; la distribution est simulée. Une simplification honnête pour une démo.

Rails de paiement : délibérément multi-rails

AP2 ne choisit pas de vainqueur entre les rails de carte et la crypto. Il définit des points d’extension pour tous :

Rail	Comment cela fonctionne dans AP2	Idéal pour
Réseaux de cartes	Mastercard Agent Pay, Visa : titres de carte tokenisés émis par le Fournisseur de titres	Achats de grande valeur par les consommateurs, relations bancaires existantes
Paiements en temps réel	FedNow, UPI, Pix : titres de virement bancaire	B2B de grande valeur, marchés où le virement bancaire en temps réel domine
x402 / USDC	L’agent détient un portefeuille intelligent directement, USDC sur Base/Ethereum, règlement instantané	Micro-transactions, paiements API-à-API, pas de seuil d’interchange

x402 est particulièrement intéressant pour les micro-transactions. Les coûts d’interchange de carte traditionnels s’élèvent à 0,50 $ à 0,80 $ par transaction, quel que soit le montant. Un agent payant 0,01 $ pour un appel API ne peut pas utiliser les rails de carte de manière économique. x402 et les stablecoins résolvent ce problème : l’agent détient des USDC, paie directement on-chain, et peut utiliser un séquestre programmable pour des engagements en plusieurs étapes.

Trois déploiements publics AP2 nommés en avril 2026 : le portefeuille de PayPal et l’Agent de commerce conversationnel de Google Cloud, le pilote Mastercard Agent Pay au sein de PayPal, et l’extension A2A x402 pour les paiements crypto.

Comment notre démo correspond à un AP2 réel

J’ai construit une démo Camunda 8 + AP2 pour l’EP 03 de Agents, Orchestrated. Voici la correspondance honnête :

Notre démo (BFF Camunda 8)	AP2 réel
mandateService.js crée et signe le JSON du mandat (ES256)	La Surface de Confiance et l’Agent d’achat détiennent des mandats ouverts signés par l’utilisateur avec une gestion de clés DID réelle
Politique de dépense Camunda DMN (humain dans la boucle, plafond, vélocité)	Intégrée dans les contraintes du mandat ouvert et le moteur de politique du fournisseur de titres
Les événements SSE pilotent le site marchand TicketVault	L’Agent d’achat envoie le Checkout Mandate à l’endpoint A2A de l’Agent commerçant (HTTP standard) via une requête POST
Worker Camunda merchant.completeCheckout	Binaire d’Agent commerçant distinct vérifiant les mandats et exécutant le paiement ACP
Worker Camunda credentials.issueToken	Agent Fournisseur de titres vérifiant la paire de mandats et émettant le titre de paiement
Tâche utilisateur Zeebe task_desk_approval (humain dans la boucle)	AP2 ne prescrit pas d’escalade humain dans la boucle ; Camunda ajoute cela comme gouvernance au-dessus du protocole

La couche Camunda est l’endroit où nous ajoutons une gouvernance qu’AP2 lui-même n’impose pas : la politique de dépense DMN, l’escalade humain dans la boucle à 95 % du plafond, la piste d’audit complète du processus. AP2 est le protocole d’autorisation. Camunda est l’orchestrateur de gouvernance au-dessus.

Ce que la v0.2 a ajouté (avril 2026)

La fonctionnalité phare est le paiement sans présence humaine : les agents peuvent exécuter des transactions pré-autorisées sans invite de consentement interactive, en utilisant la paire de mandats ouverts/fermés.

• Restructuration de trois types de mandats (Intent/Cart/Payment) en deux (Checkout/Payment) avec des étapes ouvertes et fermées
• Formalisation de SD-JWT comme standard d’encodage des mandats
• Ajout explicite de la distinction ECDSA DOIT / Ed25519 NE DOIT PAS dans la spécification
• Introduction du support officiel pour les rails x402 / stablecoin en tant que type de paiement de première classe
• Implémentations de référence en Python, Go, TypeScript, Kotlin et Android
• Standardisation par la FIDO Alliance via le groupe de travail technique Agentic Authentication and Payments

La version en un paragraphe

AP2 est le protocole ouvert de Google pour les paiements initiés par des agents. Il résout bien un problème : comment un humain délègue-t-il une autorité de dépense limitée à un agent d’une manière que chaque partie de la chaîne de transaction peut vérifier indépendamment, sans se faire confiance mutuellement ni faire appel à une autorité centrale ? Il le fait via un système à deux mandats, un Checkout Mandate (agent vers commerçant) et un Payment Mandate (agent vers fournisseur de titres), où chaque mandat a une étape ouverte (l’utilisateur pré-signe les contraintes) et une étape fermée (l’agent signe la transaction spécifique). Les titres sont des SD-JWT signés avec ECDSA P-256, ce qui les rend infalsifiables et portables. AP2 se situe à la couche d’autorisation entre le protocole de transport A2A et la couche de paiement ACP/UCP. Ce n’est pas MCP, et ce n’est pas une passerelle de paiement. Il fonctionne sur les rails de carte, les paiements en temps réel et les stablecoins. Le scénario phare de la v0.2 est le paiement sans présence humaine : l’agent agit de manière autonome pendant que l’utilisateur dort, limité par les contraintes cryptographiques qu’il a définies à l’avance.

L’autonomie est un prérequis. Le fossé, c’est tout ce qui entoure l’agent.

Références

• Spécification AP2 : ap2-protocol.org (source de vérité pour les types de mandats, l’encodage SD-JWT, les exigences ECDSA, les rôles des parties)
• Google Cloud : Annonce d’AP2 (contexte de lancement, plus de 60 partenaires, annonce du don à la FIDO Alliance)
• AP2 GitHub : google-agentic-commerce/AP2 (implémentations de référence en Python, Go, TypeScript, Kotlin, Android, plus des scénarios exécutables)
• Cloud Security Alliance : Utilisation sécurisée d’AP2 (modèle de menace STRIDE, formule ECDSA P-256, framework MAESTRO, AES-GCM-256)
• ACP vs AP2 vs MCP : Comparaison des piles de protocoles (analyse couche par couche de la pile du commerce agentique)
• Eco : AP2 v0.2 expliqué (restructuration des mandats v0.2, flux sans présence humaine, DIDs pour la découverte de clés)
• Cobo Agentic Wallet : Guide complet AP2 (détails x402, rails stablecoin, intégration de portefeuille multi-parties)
• UCP : Extension des mandats AP2 (comment AP2 s’intègre au Universal Commerce Protocol au niveau de la couche de paiement)
• Google Codelabs : Commerce d’agents sécurisé avec AP2 et UCP (implémentation pratique avec l’ADK officiel de Google)
• arXiv : Vérification d’exécution Zero-Trust pour AP2 (traitement académique des attaques par rejeu et des échecs de liaison de contexte dans AP2)
• AP2 : Perspective européenne (contexte réglementaire et de standardisation européen pour les paiements agentiques)
• Guide technique AP2 : Medium / Vishal Mysore (présentation de l’implémentation avec des exemples de code)