AP2 face à x402 : comment les agents d’IA gèrent l’autorisation des paiements et le règlement automatisé

AP2 (Agent Payments Protocol) et x402 sont deux protocoles de paiement conçus pour le commerce des agents IA. Ils fournissent une infrastructure pour les transactions autonomes, respectivement du point de vue de l’autorisation de paiement et du règlement programmatique. AP2 vise à prouver qu’un achat effectué par un agent IA a été autorisé par l’utilisateur, tandis que x402 utilise des interactions de paiement HTTP standardisées pour permettre aux systèmes logiciels d’acheter à la demande des API, des données et d’autres services numériques.

À mesure que le commerce d’agent à agent se développe, les agents IA évoluent d’outils de recherche d’informations vers des systèmes automatisés capables d’effectuer des achats, de gérer des abonnements et d’appeler des services. Lorsqu’un agent utilise des fonds pour le compte d’un utilisateur ou d’une entreprise, les processus de paiement traditionnels reposant sur des clics et des confirmations manuels rencontrent de nouveaux défis : comment le système peut-il déterminer si l’agent est autorisé à effectuer un paiement ? Comment limiter le montant du paiement ? Comment différents systèmes peuvent-ils effectuer le règlement automatiquement ?

AP2 et x402 proposent deux approches complémentaires. Cet article présente les mécanismes fondamentaux, les différences techniques et les flux de travail collaboratifs des deux protocoles, analyse le rôle des stablecoins dans les paiements des agents IA et examine les risques de sécurité et de conformité que peuvent impliquer les transactions automatisées.

À retenir

• AP2 (Agent Payments Protocol) est un protocole ouvert d’autorisation de paiement pour les agents IA. Il s’intéresse à la possibilité pour un agent d’effectuer des paiements au nom d’un utilisateur et à la manière de vérifier qu’une transaction reflète l’intention de l’utilisateur.
• x402 est un protocole de paiement programmatique basé sur le code d’état HTTP 402 Payment Required. Il permet aux agents IA de payer automatiquement des API et des services numériques selon les exigences de paiement renvoyées par le serveur.
• AP2 et x402 répondent à des niveaux différents : AP2 se concentre sur l’autorisation et la vérification de la responsabilité, tandis que x402 se concentre sur les demandes de paiement, la vérification des justificatifs et le règlement. Les deux protocoles peuvent être utilisés conjointement.
• Les stablecoins fournissent aux agents IA une forme de paiement numérique programmable. Ils sont adaptés aux API facturées à l’usage, aux services de données et aux transactions de machine à machine, mais ne sont pas nécessaires dans tous les scénarios de paiement par agent.
• Les paiements automatiques par des agents IA nécessitent toujours des limites budgétaires, des contrôles d’autorisation du wallet, une vérification des contreparties et la gestion des transactions anormales. L’exécution automatisée ne doit pas être considérée comme une autorisation illimitée d’utiliser des fonds.

Que sont AP2 et x402 ? Pourquoi les agents IA ont-ils besoin de protocoles de paiement dédiés ?

AP2 et x402 prennent tous deux en charge le commerce automatisé des agents IA, mais ils résolvent des problèmes différents. AP2 a été lancé en septembre 2025 par Google avec des participants issus des secteurs des paiements et des technologies. Il vise à établir un cadre multiplateforme et indépendant du moyen de paiement pour l’autorisation de paiement des agents. Il se concentre sur la preuve qu’un utilisateur a autorisé un agent à effectuer un achat spécifique et sur la possibilité pour les institutions de paiement de vérifier cette autorisation.

x402, quant à lui, a été développé par Coinbase et repose sur le code d’état 402 Payment Required du protocole HTTP. Il permet aux sites web, aux API et à d’autres services numériques d’envoyer directement des exigences de paiement aux clients. Après avoir reçu les informations de paiement, un agent IA peut utiliser un wallet contrôlé pour générer des justificatifs de paiement et accéder à la ressource concernée une fois la vérification et le règlement effectués.

L’émergence de ces deux protocoles reflète deux défis distincts du commerce des agents IA. Premièrement, un agent peut découvrir de manière autonome des produits et services, mais il doit prouver qu’il a reçu l’autorisation de l’utilisateur. Deuxièmement, même si un agent dispose d’une autorisation de paiement, il lui faut encore un moyen d’interagir avec des services externes et d’effectuer des paiements automatiquement.

Les systèmes de paiement en ligne traditionnels supposent généralement que les consommateurs examineront eux-mêmes les produits, cliqueront pour confirmer et effectueront une vérification d’identité. Un agent IA peut toutefois exécuter des tâches sans la participation en temps réel de l’utilisateur. Les systèmes de paiement doivent donc déterminer non seulement si une transaction est valide, mais aussi si le comportement de l’agent respecte les autorisations prédéfinies.

AP2 et x402 apportent respectivement un soutien technique à ces deux étapes, mais tous les paiements effectués par des agents IA ne nécessitent pas les deux protocoles.

Comment AP2 vérifie-t-il l’autorisation de paiement d’un agent IA ?

Le cœur d’AP2 est le Mandate, un justificatif d’autorisation vérifiable cryptographiquement. Il consigne les actions qu’un utilisateur a autorisé un agent à effectuer ainsi que les restrictions applicables, ce qui permet aux commerçants et aux prestataires de services de paiement de déterminer si une transaction reflète l’intention de l’utilisateur.

Selon la spécification technique AP2 v0.2, le protocole définit deux principaux types de justificatifs : le Checkout Mandate et le Payment Mandate. Un Checkout Mandate prouve qu’un agent a été autorisé à acheter un produit ou un service spécifique. Un Payment Mandate prouve que l’agent peut initier le paiement de la commande correspondante. Les deux sont liés par les informations de commande, ce qui réduit le risque qu’un justificatif de paiement soit utilisé pour une autre transaction.

Par exemple, supposons qu’un utilisateur souhaite qu’un agent IA achète un service de données dont le prix ne dépasse pas 50 $. Le système peut enregistrer la catégorie de produit, le budget et les conditions d’autorisation dans les justificatifs concernés. Après que l’agent a trouvé un service répondant aux exigences, le commerçant vérifie l’autorisation d’achat, puis le prestataire de services de paiement vérifie l’autorisation de paiement. La transaction ne doit passer à l’étape de paiement suivante qu’une fois les conditions pertinentes remplies.

AP2 distingue également les modes de transaction Human Present et Human Not Present. Dans le premier cas, l’utilisateur peut confirmer la commande spécifique lors du paiement. Dans le second, l’agent peut exécuter la transaction dans les limites autorisées à l’avance. Dans les deux cas, les vérifications d’autorisation essentielles doivent être effectuées par des processus déterministes plutôt qu’en s’appuyant uniquement sur le jugement d’un grand modèle de langage.

Par conséquent, AP2 n’a pas vocation à remplacer les cartes bancaires, les comptes bancaires ou les stablecoins. Sa valeur réside dans l’établissement d’une base d’autorisation vérifiable pour différents moyens de paiement et dans la fourniture d’enregistrements pour les audits ultérieurs et la résolution des litiges.

Comment x402 permet-il les paiements automatisés via HTTP 402 ?

L’idée centrale de x402 consiste à intégrer directement le processus de paiement aux requêtes HTTP. Les services d’API traditionnels exigent généralement que les utilisateurs créent un compte, associent un moyen de paiement ou achètent des crédits d’abonnement à l’avance. x402 permet à un serveur de renvoyer des exigences de paiement standardisées lorsqu’il reçoit une requête, après quoi le client effectue le paiement et récupère à nouveau la ressource.

Selon le protocole officiel x402, le processus typique commence lorsqu’un client envoie une requête HTTP à un serveur de ressources. Si la ressource nécessite un paiement, le serveur renvoie 402 Payment Required et fournit le prix, les réseaux pris en charge, les actifs de paiement et les autres informations requises. Le client sélectionne un moyen de paiement pris en charge, génère des justificatifs de paiement et les soumet au moyen d’une requête HTTP.

Le serveur de ressources vérifie ensuite les justificatifs de paiement et effectue le règlement via une transaction on-chain ou un Facilitator, c’est-à-dire un service de vérification et de règlement des paiements. Un Facilitator peut effectuer la vérification des signatures et le règlement on-chain au nom du serveur, réduisant ainsi la complexité liée à la maintenance d’une infrastructure de paiement sur blockchain. Une fois la vérification et le règlement réussis, le serveur renvoie les données demandées ou le résultat du service.

Il convient de noter que les différentes versions de x402 utilisent des noms d’en-tête HTTP et des structures de données différents. Par exemple, les versions antérieures utilisaient X-PAYMENT, tandis que les spécifications plus récentes utilisent des champs tels que PAYMENT-SIGNATURE. Les développeurs doivent donc implémenter la version spécifique qu’ils utilisent et ne doivent pas mélanger directement les interfaces de différentes versions.

Pour les agents IA, l’avantage de x402 est que le paiement peut devenir une partie intégrante d’une requête web ordinaire. Si un agent doit acheter des données payantes ou appeler un modèle d’IA, il peut effectuer le paiement dans la limite de son budget autorisé sans être redirigé à chaque fois vers une page de paiement manuelle distincte.

Quelles sont les différences entre AP2 et x402 ?

La différence la plus fondamentale entre AP2 et x402 réside dans leurs responsabilités. AP2 répond principalement à la question : « Cette transaction est-elle autorisée ? » x402 répond principalement à la question : « Comment le paiement peut-il être effectué par programmation conformément aux exigences du serveur ? »

AP2 ne dépend pas d’une devise de paiement ou d’un réseau de règlement spécifique. Par exemple, un agent IA peut utiliser AP2 pour prouver qu’un achat a été autorisé, puis effectuer la transaction avec une carte bancaire ou un autre moyen de paiement pris en charge. x402 se concentre davantage sur l’exécution technique des paiements de services numériques et est particulièrement adapté à la combinaison des paiements en stablecoins avec les requêtes API.

Les deux protocoles présentent également un certain chevauchement fonctionnel. x402 peut vérifier les justificatifs de paiement soumis par un client, mais cette vérification concerne principalement le respect des exigences du serveur par le paiement. Elle n’équivaut pas intrinsèquement à une autorisation complète de l’intention commerciale de l’utilisateur. AP2 peut enregistrer des informations plus étendues sur l’intention de l’utilisateur, le produit et les conditions de paiement.

Par conséquent, AP2 ne doit pas être simplement considéré comme une version améliorée de x402, et x402 ne doit pas non plus être considéré comme un remplacement de tous les mécanismes d’autorisation de paiement. Ils peuvent être déployés indépendamment ou utilisés ensemble.

Comment AP2 et x402 peuvent-ils fonctionner ensemble pour effectuer une transaction d’agent à agent ?

La collaboration entre AP2 et x402 peut être comprise à travers un exemple impliquant un service payant d’analyse de données.

Supposons qu’un utilisateur autorise un agent de recherche à acheter jusqu’à 20 $ de données de marché au cours d’une même journée. L’agent découvre qu’un autre prestataire de services propose une API répondant à ses besoins et reçoit un tarif de 0,10 $ par appel. Le système doit d’abord confirmer que le service entre dans le champ de l’achat autorisé, puis vérifier que les dépenses cumulées ne dépassent pas le budget.

Au stade de l’autorisation, AP2 peut fournir un Mandate vérifiable prouvant que l’agent dispose des autorisations d’achat et de paiement correspondantes. Au stade du paiement, x402 peut transmettre les exigences de paiement du serveur à l’agent et effectuer le transfert de fonds au moyen d’un wallet contrôlé, de justificatifs de paiement et d’un service de règlement. Une fois le paiement effectué, le serveur renvoie les données et l’agent poursuit sa tâche de recherche.

Cette combinaison ne se limite pas à un modèle conceptuel. Des projets open source liés à Google ont publié l’A2A x402 Payments Extension, qui permet aux agents d’acheter des services fournis par d’autres agents au moyen de paiements on-chain. Sa spécification v0.2 définit également des flux de paiement indépendants et intégrés. Ces derniers peuvent intégrer des structures de paiement dans des protocoles de niveau supérieur tels qu’AP2.

Toutefois, le processus ci-dessus est un exemple destiné à expliquer comment les protocoles peuvent être combinés. Cela ne signifie pas que toutes les implémentations d’AP2 ou de x402 prennent déjà en charge exactement les mêmes fonctions. Les systèmes réels doivent encore gérer des éléments tels que la vérification des justificatifs d’autorisation, les autorisations du wallet, les paiements échoués, les requêtes en double et les reçus de transaction.

Pourquoi les stablecoins sont-ils adaptés aux paiements automatisés des agents IA ?

Les stablecoins figurent parmi les principaux candidats pour les paiements programmatiques des agents IA. Par rapport aux crypto-actifs présentant une volatilité des prix plus élevée, les stablecoins indexés sur le dollar américain sont généralement libellés par rapport au dollar américain, ce qui aide les prestataires de services à fixer des prix relativement stables pour les appels API, l’accès aux données et les ressources informatiques.

Par exemple, un agent IA peut avoir besoin d’appeler une interface de données payante des centaines de fois par jour. Si chaque appel exige la confirmation manuelle d’un paiement par carte bancaire, le processus de transaction sera difficile à automatiser. Avec x402 et un réseau de stablecoins pris en charge, les exigences de paiement, les signatures et les opérations de règlement peuvent être intégrées aux requêtes programmatiques, ce qui permet à l’agent de payer automatiquement des services dans la limite de son budget.

Les stablecoins sont également nativement numériques et programmables. Les développeurs peuvent combiner la logique de paiement avec les autorisations d’API, les limites d’utilisation et les restrictions de wallet, ce qui permet aux systèmes logiciels de transférer des fonds entre différentes plateformes. Lors de l’introduction de x402, Coinbase a identifié les paiements automatisés entre API, services logiciels et agents IA comme un domaine d’application clé.

Cependant, les paiements en stablecoins présentent également des limites. Les transferts on-chain peuvent entraîner des frais de réseau, certaines transactions peuvent nécessiter du temps pour atteindre leur finalité, et des adresses incorrectes ou des transferts irréversibles peuvent entraîner une perte de fonds. Les stablecoins impliquent également des risques liés à l’émetteur, aux réserves, au remboursement et à la réglementation. Les stablecoins doivent donc être compris comme une option de règlement pour le commerce des agents, et non comme une solution universelle à tous les problèmes de paiement.

Quels risques de sécurité et quelles limites techniques AP2 et x402 rencontrent-ils ?

Le premier risque est l’abus d’autorisation. Un agent IA peut mal interpréter la demande d’un utilisateur ou être influencé par des pages web malveillantes, des réponses d’outils ou une injection de prompt, ce qui l’amène à initier des achats au-delà de l’intention réelle de l’utilisateur. Si le système s’appuie uniquement sur le modèle pour déterminer si un paiement est raisonnable et ne dispose pas de contrôles indépendants du budget et des autorisations, des dépenses non intentionnelles peuvent survenir.

AP2 réduit ce risque grâce aux Mandates et à des mécanismes de vérification déterministes, mais sa sécurité dépend toujours de la manière dont les justificatifs d’autorisation sont émis, stockés et vérifiés. Les systèmes doivent également éviter d’accorder des autorisations trop étendues et devraient introduire une confirmation supplémentaire pour les transactions à haut risque.

Le deuxième risque concerne l’exécution du paiement. x402 implique le client, le serveur, le wallet et le service de règlement, et une erreur d’implémentation à n’importe quelle étape peut affecter le résultat de la transaction. Par exemple, des soumissions répétées de requêtes peuvent entraîner des paiements en double, un paiement réussi suivi d’un échec de fourniture du service peut conduire à un litige, et une défaillance d’un Facilitator peut retarder le règlement. Les développeurs doivent donc concevoir un traitement idempotent, des tentatives de paiement après échec, un rapprochement des reçus et des procédures de remboursement en cas d’exception.

Le troisième risque concerne la vérification de la contrepartie et de l’identité. Même si un agent soumet correctement des justificatifs de paiement, le destinataire n’est pas nécessairement digne de confiance. Un serveur malveillant peut présenter les prix de manière trompeuse, fournir un service non valide ou falsifier les informations sur le produit. A2A et x402 peuvent améliorer la communication entre agents et les flux de paiement, mais ils ne peuvent pas garantir automatiquement l’authenticité de l’identité d’un commerçant ni que la qualité du service répondra aux attentes.

Les derniers risques concernent la confidentialité et la réglementation. Le commerce des agents peut impliquer les préférences de consommation des utilisateurs, les informations d’approvisionnement des entreprises et les données de paiement. Bien que les paiements on-chain fournissent des enregistrements de transaction vérifiables publiquement, ils peuvent également exposer des adresses et des flux de fonds. Les paiements transfrontaliers nécessitent également de prendre en compte les exigences applicables en matière de lutte contre le blanchiment d’argent, de sanctions et de protection des consommateurs.

Par conséquent, les applications pratiques d’AP2 et de x402 doivent être construites sur une architecture de sécurité multicouche incluant l’autorisation de l’utilisateur, les contrôles des autorisations de l’agent, la vérification des justificatifs de paiement, la surveillance des transactions et la gestion des exceptions. Ce n’est qu’en combinant ces mécanismes que les systèmes peuvent contrôler les risques liés aux fonds tout en augmentant le niveau d’automatisation.

Conclusion

AP2 et x402 fournissent une infrastructure pour le commerce des agents IA, respectivement du point de vue de l’autorisation de paiement et du règlement programmatique. Grâce aux Mandates et aux justificatifs vérifiables, AP2 aide les commerçants et les prestataires de services de paiement à confirmer si la transaction d’un agent respecte l’autorisation de l’utilisateur. Grâce à HTTP 402 et aux processus de vérification des paiements, x402 permet aux agents IA d’acheter automatiquement des API, des données et d’autres services numériques.

Les deux protocoles ne se substituent pas l’un à l’autre. AP2 peut fonctionner avec différents moyens de paiement, tandis que x402 peut servir de mécanisme d’exécution pour les paiements on-chain. À mesure que des technologies telles que l’A2A x402 Payments Extension se développent, la vérification des autorisations et le règlement automatisé nouent une relation de collaboration plus étroite.

Pour le commerce d’agent à agent, l’enjeu principal ne consiste pas seulement à permettre aux agents IA d’effectuer des paiements. Chaque transaction doit disposer de limites d’autorisation clairement définies, de résultats de paiement vérifiables et de mécanismes fiables de gestion des exceptions. Les stablecoins et le Web3 apportent de nouveaux outils de règlement dans cette direction, mais l’adoption généralisée du commerce des agents dépendra en définitive de la sécurité, de l’interopérabilité et des besoins réels des entreprises.

FAQ

Quelle est la différence fondamentale entre AP2 et x402 ?

AP2 vérifie principalement l’autorisation d’achat et de paiement d’un agent IA, tandis que x402 permet principalement les paiements programmatiques via des requêtes HTTP. Le premier se concentre sur l’autorisation, tandis que le second se concentre sur l’exécution du paiement.

AP2 est-il un protocole de paiement sur blockchain ?

Non. AP2 est un cadre d’autorisation indépendant du moyen de paiement qui peut prendre en charge différents systèmes de paiement, notamment les cartes bancaires et les stablecoins. Il n’exige pas que les transactions soient réglées sur une blockchain.

x402 peut-il uniquement utiliser l’USDC ?

Non. Les capacités de paiement de x402 dépendent du système de paiement spécifique, du réseau et de la prise en charge fournie par le serveur. L’USDC est un actif de paiement courant dans les implémentations, mais il ne doit pas être compris comme le seul actif pris en charge par le protocole.

AP2 et x402 peuvent-ils être utilisés ensemble ?

Oui. AP2 peut être utilisé pour vérifier l’autorisation de transaction d’un agent, tandis que x402 peut être utilisé pour exécuter le paiement on-chain programmatique correspondant. L’A2A x402 Extension a déjà exploré des moyens de combiner x402 avec des protocoles de niveau supérieur tels qu’AP2.

Un agent IA a-t-il besoin d’une confirmation manuelle pour effectuer un paiement avec x402 ?

Pas nécessairement. Si l’utilisateur a fourni une autorisation valide et que la transaction respecte le budget, le destinataire et les autres restrictions applicables, le système peut autoriser l’agent à effectuer le paiement automatiquement. Les transactions en dehors du champ autorisé doivent nécessiter une nouvelle confirmation.

La fourniture du service est-elle garantie après la réussite d’un paiement x402 ?

Non. La réussite du paiement et l’exécution du service sont des étapes distinctes. Des défaillances d’API, des services indisponibles ou des litiges concernant la fourniture peuvent toujours survenir. Les risques doivent donc être gérés au moyen de reçus de transaction, de la gestion des exceptions et, lorsque nécessaire, de mécanismes de remboursement.