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 ```jsonc // 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 ```text // 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](https://ap2-protocol.org/ap2/specification/) (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](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) (contexte de lancement, plus de 60 partenaires, annonce du don à la FIDO Alliance) - [AP2 GitHub : google-agentic-commerce/AP2](https://github.com/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](https://cloudsecurityalliance.org/blog/2025/10/06/secure-use-of-the-agent-payments-protocol-ap2-a-framework-for-trustworthy-ai-driven-transactions) (modèle de menace STRIDE, formule ECDSA P-256, framework MAESTRO, AES-GCM-256) - [ACP vs AP2 vs MCP : Comparaison des piles de protocoles](https://www.leadgen-economy.com/blog/acp-ap2-mcp-agentic-commerce-protocol-stack-comparison/) (analyse couche par couche de la pile du commerce agentique) - [Eco : AP2 v0.2 expliqué](https://eco.com/support/en/articles/15192002-ap2-protocol-explained-google-s-agentic-commerce-standard-2026) (restructuration des mandats v0.2, flux sans présence humaine, DIDs pour la découverte de clés) - [Cobo Agentic Wallet : Guide complet AP2](https://www.cobo.com/post/ap2-protocol-complete-guide-to-agent-payments-for-web3-developers-2026) (détails x402, rails stablecoin, intégration de portefeuille multi-parties) - [UCP : Extension des mandats AP2](http://ucp.dev/2026-01-23/specification/ap2-mandates/) (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](https://codelabs.developers.google.com/next26/adk-agent-commerce) (implémentation pratique avec l'ADK officiel de Google) - [arXiv : Vérification d'exécution Zero-Trust pour AP2](https://arxiv.org/pdf/2602.06345) (traitement académique des attaques par rejeu et des échecs de liaison de contexte dans AP2) - [AP2 : Perspective européenne](https://agentpaymentsprotocol.eu/) (contexte réglementaire et de standardisation européen pour les paiements agentiques) - [Guide technique AP2 : Medium / Vishal Mysore](https://medium.com/@visrow/google-agent-payments-protocol-ap2-technical-guide-implementation-73ee772fe349) (présentation de l'implémentation avec des exemples de code)