Les paiements par agents IA ont produit en un an environ quatre spécifications concurrentes, deux fondations sectorielles et une quantité considérable d’articles. Ce qu’ils n’ont pas encore produit, pour l’immense majorité des marchands, c’est du chiffre d’affaires. L’écart entre le bruit et les chiffres est la partie utile à comprendre, car la couverture enthousiaste et la couverture dédaigneuse se trompent toutes deux d’une manière qui coûte de l’argent.

Quelque chose de réel se construit. Google, OpenAI, Stripe, Coinbase, Shopify, Visa et Mastercard ont tous publié des spécifications ou des produits sur ce terrain, et deux de ces spécifications relèvent désormais de fondations neutres plutôt que d’un éditeur unique. Une partie est en production. Mais l’essentiel du trafic en production, ce sont des machines qui achètent des appels d’API à d’autres machines, pas un assistant d’achat qui vous commande un canapé.

Cet article sépare ce qui est livré de ce qui n’est qu’une spécification accompagnée de logos, explique ce qui change pour votre paiement en ligne et votre dispositif antifraude, et propose un plan sur douze mois classé par coût.

Un marchand britannique doit-il agir sur les paiements par agents IA en 2026 ? Seulement à petite échelle. Les protocoles sont réels mais jeunes, le volume grand public se concentre sur une poignée de surfaces majoritairement américaines, et la quasi-totalité de l’activité de paiement machine mesurable correspond à des agents qui paient pour des données et du calcul, pas pour des marchandises. Le travail utile aujourd’hui consiste à rendre vos données produit lisibles par une machine, à vérifier que vos règles antibots ne bloquent pas les agents acheteurs, et à publier vos conditions de stock et de retour dans un format qu’une machine peut analyser.

Pourquoi les rails carte cassent quand l’acheteur est un logiciel

Le système de paiement que vous utilisez tous les jours repose sur une hypothèse valable depuis l’invention de la carte. Au moment de l’achat, une personne est présente et consent. Presque tout ce qui est bâti par-dessus hérite de cette hypothèse : l’authentification, le score de fraude, les règles de litige et la répartition de la responsabilité entre vous, votre acquéreur et l’émetteur.

Un agent qui achète pour le compte de quelqu’un ne casse pas cette hypothèse bruyamment. Il la casse discrètement, à quatre endroits distincts, et chaque rupture atterrit sur une partie différente de votre activité.

Le porteur présent est un état technique, pas une politesse

Chaque transaction par carte transporte des données décrivant par quel chemin les informations de carte vous sont parvenues et quelle confiance l’émetteur doit accorder à ce chemin. Un agent qui colle un numéro de carte enregistré dans votre tunnel ressemble à du commerce en ligne sans présentation de carte, c’est-à-dire déjà la catégorie la plus chère et la plus contestée que vous traitez.

C’est le résultat par défaut si le trafic agentique vous atteint par un tunnel web inchangé, et c’est pire que le statu quo, pas mieux. Tout l’intérêt des dispositifs de jetons propres aux agents construits par les réseaux de cartes, dont Visa Intelligent Commerce et Mastercard Agent Pay, est de donner à l’émetteur un meilleur signal que « quelqu’un a tapé un numéro de carte dans un formulaire ».

L’authentification n’a personne à interroger

L’authentification forte du client suppose que le payeur peut répondre à une demande sur le moment : une notification dans l’application bancaire, une biométrie, un code. Un agent autonome n’a ni pouce ni téléphone. Il ne peut pas passer une vérification supplémentaire.

La réponse du secteur consiste à déplacer le moment humain plus tôt. L’utilisateur s’authentifie une fois, lorsqu’il délègue son autorité et fixe les limites, et l’achat qui suit s’appuie sur cette autorisation enregistrée plutôt que sur une vérification en direct. C’est exactement ce que code le modèle de mandat du protocole de Google, et c’est pourquoi la couche d’autorisation et la couche de paiement sont deux problèmes distincts.

Les litiges supposent un humain capable de dire ce qu’il voulait

Les règles de rétrofacturation sont bâties autour d’une personne qui se souvient de son intention. Quand l’acheteur était un logiciel, la question intéressante n’est pas de savoir si la transaction a eu lieu mais si elle correspondait à l’instruction, et les parties capables de répondre sont l’utilisateur, l’opérateur de l’agent, le fournisseur du modèle et vous.

Aucun des motifs de litige existants ne décrit « l’agent a mal lu le guide des tailles ». Tant que les réseaux ne publient pas un traitement des litiges propre aux agents, le risque pratique est que les achats agentiques ambigus se règlent comme se règlent aujourd’hui les achats ambigus sans présentation de carte, c’est-à-dire rarement en faveur du marchand.

Vous ne savez pas encore distinguer un acheteur d’un aspirateur de pages

La quatrième rupture est celle que les marchands sous-estiment. Un agent acheteur et un robot de veille tarifaire arrivent par le même protocole, depuis une infrastructure semblable, avec des en-têtes semblables. Votre gestion des bots voit du trafic, pas une intention.

Ce que font vraiment les standards de paiement par agents IA

Quatre spécifications comptent, et elles résolvent des couches différentes. Les traiter comme des rivales est l’erreur d’analyse la plus fréquente dans ce domaine ; trois des quatre se citent explicitement.

AP2 : la couche d’autorisation et de mandat

Google a annoncé l’Agent Payments Protocol le 16 septembre 2025 avec, selon l’annonce de Google Cloud, plus de soixante organisations au lancement, dont Adyen, American Express, Coinbase, Mastercard, PayPal et Worldpay. Son contenu est un jeu de mandats signés cryptographiquement : un Intent Mandate qui enregistre ce que l’utilisateur a demandé, et un Cart Mandate qui enregistre les articles exacts et le prix exact qu’il a approuvés.

Le but est une chaîne auditable, de l’instruction humaine jusqu’au débit. La version 0.2.0 est arrivée le 28 avril 2026 en ajoutant les flux sans humain présent, et l’historique des versions sur GitHub ne montre que ces deux publications. La gouvernance est passée à la FIDO Alliance. C’est une spécification précoce au parrainage lourd, pas un rail achevé.

ACP : le protocole de paiement

L’Agentic Commerce Protocol a été publié par Stripe et OpenAI le 29 septembre 2025 sous licence Apache 2.0. Plutôt que de pousser un agent dans votre tunnel web ordinaire, il transmet au marchand les identifiants de paiement sous forme de jeton dont l’usage est autorisé et journalisé, ce qui constitue un signal nettement meilleur qu’un numéro de carte collé.

C’est aussi le plus concret des quatre pour un marchand, car il définit des points d’accès que vous construiriez réellement. La documentation de Stripe cite désormais Meta aux côtés de Stripe et d’OpenAI comme auteur, et nomme les briques : paiement agentique, panier et flux produit, paiement délégué, authentification déléguée avec OAuth 2.0, et webhooks de commande. Le répertoire de spécification publié porte la date du 17 avril 2026, ce qui vous dit à la fois qu’il est entretenu et qu’il est jeune.

UCP : la couche commerce de Google

Google a lancé l’Universal Commerce Protocol le 11 janvier 2026 lors de la conférence de la National Retail Federation. D’après l’annonce de Google, il a été construit avec Shopify, Etsy, Wayfair, Target et Walmart, et soutenu par plus de vingt autres acteurs, dont Adyen, Mastercard, Stripe et Visa.

UCP couvre tout le parcours plutôt que le seul paiement : découverte, panier, commande et suivi après achat, à travers Google Search, AI Mode et l’application Gemini. Il s’appuie sur les flux Merchant Center que vous entretenez peut-être déjà, et il utilise AP2 en dessous pour l’étape de paiement. Si vous vendez des biens physiques et que vous gérez déjà Google Shopping, c’est la spécification qui a le plus de chances de vous atteindre en premier.

x402 : les paiements machine natifs de HTTP

x402 ranime le code de statut HTTP 402 Payment Required, inutilisé depuis les premières spécifications HTTP. Un serveur répond 402 avec une description du paiement attendu, le client attache une charge de paiement signée à la nouvelle tentative, et la requête aboutit. Aucun compte, aucune page de paiement, aucun humain.

Coinbase a confié le protocole à une fondation désormais hébergée par la Linux Foundation, dont le communiqué du 14 juillet 2026 recense 40 membres, avec AWS, American Express, Cloudflare, Fiserv, Google, Mastercard, Shopify, Stripe et Visa parmi les membres premier. Il est conçu aussi bien pour les stablecoins que pour les cartes, et c’est le seul des quatre à publier des chiffres de volume.

Comment les quatre s’articulent

Une façon utile de retenir tout cela : x402 permet à une machine de payer une requête, AP2 permet de prouver qu’un humain a autorisé un achat, ACP permet à un agent de finaliser un paiement chez un marchand, et UCP permet à un détaillant d’exposer une boutique entière à un agent.

Ils se composent au lieu de se concurrencer. La documentation de Google positionne AP2 comme la couche de paiement sous l’orchestration commerciale d’UCP, et renvoie à une implémentation de référence qui associe son protocole d’agents à x402 pour le règlement en crypto. ACP s’intègre au Model Context Protocol que les agents parlent déjà.

Commercialement, cela signifie que miser sur le mauvais protocole est un risque plus faible qu’il n’y paraît. Les couches sont séparables, et la plomberie que votre plateforme construit pour l’une reste largement réutilisable. Le risque plus grand consiste à dépenser sur l’un ou l’autre avant que la demande existe.

Où se trouve réellement le volume

C’est la section qui devrait calibrer tout le reste, et c’est là que la plupart des articles décrochent du réel.

Le machine à machine est réel et minuscule en valeur

Le tableau de bord x402 publie des chiffres glissants sur trente jours. Lu le 2 septembre 2026, il indiquait 75,41 millions de transactions, 24,24 millions de dollars de volume, 94 060 acheteurs et 22 000 vendeurs. Ce sont les chiffres de la fondation elle-même, pas un audit indépendant.

Divisez-les. Cela donne une transaction moyenne d’environ 32 cents américains. 75 millions de paiements, c’est un nombre de transactions vraiment grand et une somme d’argent vraiment petite, et cette forme vous dit de quoi il s’agit : des agents qui paient à l’appel un accès à des API, à des données et à du calcul. Ce ne sont pas des gens qui achètent des meubles.

Le paiement agentique grand public est concentré et surtout américain

Le versant grand public passe par un petit nombre de surfaces. Shopify, dans son annonce du 24 mars 2026, indique que des marchands sont actifs sur ChatGPT, Microsoft Copilot, AI Mode dans Google Search et l’application Gemini, avec des produits visibles par défaut et sans frais de transaction au-delà des taux de traitement habituels. Les marchands restent le vendeur officiel.

Shopify est la partie qui a le plus à gagner à cette présentation, alors traitez cet enthousiasme en conséquence. Mais la direction est claire, et il importe pour les vendeurs britanniques que la disponibilité la plus précoce du paiement ait été à plusieurs reprises limitée aux acheteurs américains, même quand le marchand se trouve ailleurs. Vérifiez la disponibilité sur votre marché avant de planifier autour.

Ce que cela change pour votre boutique

Vos données produit deviennent l’interface

Un agent ne sait pas interpréter votre carrousel, votre image de guide des tailles ou votre promesse de livraison dans un visuel de pied de page. Il lit des flux et des données structurées. Tout ce qui n’existe que visuellement est invisible.

C’est la même discipline que rendre un catalogue lisible pour la recherche par IA, que nous avons traitée dans GEO pour l’e-commerce et dans notre guide sur la façon dont l’IA lit le balisage Schema. Le recouvrement est presque total, et c’est ce qui rend le travail peu coûteux : vous en avez probablement déjà fait la moitié.

L’exactitude du stock cesse d’être un agrément. Un agent qui finalise un achat sur un flux périmé engendre une annulation, et les taux d’annulation seront la métrique qui décidera qui ces surfaces continuent d’afficher.

Les jetons de paiement arrivent avec des conditions

Sous les dispositifs de jetons pour agents, ce qui vous parvient n’est pas un numéro de carte brut mais un identifiant limité à un agent, à un plafond de dépense et souvent à une catégorie de marchand. C’est mieux pour vous : l’émetteur dispose de plus de contexte, et la transaction porte une traçabilité qu’un numéro tapé n’a pas.

Le coût, c’est l’intégration. Prendre correctement en charge des identifiants d’agent limités suppose que votre prestataire de paiement les gère, que vos règles antifraude les comprennent et que votre flux de commande enregistre quel agent a agi pour quel client. Rien de tout cela n’est gratuit, et rien n’est urgent pour une activité qui ne voit aucun trafic d’agents.

Vos règles antibots vont bloquer votre meilleur client

L’infrastructure qui éloigne les aspirateurs de pages de votre site est celle-là même qu’un agent acheteur doit franchir. Les marchands qui ont durci leurs règles antibots pendant la vague d’aspiration par les IA, une décision que nous avons examinée dans bloquer ou autoriser les crawlers IA, bloquent peut-être aujourd’hui un logiciel que leur client a chargé de faire ses courses.

L’identité signée est réglée, l’intention non

L’identité cryptographique est la partie qui fonctionne. L’approche des agents signés de Cloudflare fait signer les requêtes HTTP par les agents avec Web Bot Auth, si bien qu’un site peut vérifier qui appelle sans entretenir de listes d’adresses IP. Le Trusted Agent Protocol de Visa utilise le même mécanisme de signature des messages HTTP et y ajoute un champ d’intention explicite. Les signatures prouvent l’identité et déjouent l’usurpation.

Elles ne prouvent pas le dessein. L’agent d’un même opérateur peut parcourir le site pour un acheteur le lundi et aspirer tout votre catalogue le mardi, signé à l’identique les deux fois. L’intention doit être déduite du comportement, ou affirmée par l’agent puis crue, et aucune de ces voies n’est encore solide.

Le geste pratique n’est pas d’ouvrir les vannes. C’est de vérifier que vos règles actuelles relèvent d’une décision et non d’un accident, et de savoir quelles catégories vous bloquez.

Retours et litiges quand l’acheteur n’était pas une personne

Le droit de la consommation se moque de savoir qu’une machine a cliqué. Pour une vente à distance au Royaume-Uni, l’acheteur conserve son droit légal d’annulation, et GOV.UK en expose la mécanique : quatorze jours à compter de la réception pour vous annoncer l’annulation, quatorze de plus pour renvoyer la marchandise, et quatorze pour votre remboursement, livraison standard comprise.

Ce qui change, c’est le taux d’échec. Un humain qui lit mal une fiche produit s’en aperçoit généralement au moment de payer. Un agent qui travaille à partir d’un flux pauvre ne s’en apercevra pas, et les retours qui en découlent sont à votre charge, pas à celle de l’opérateur de l’agent.

L’autre question non tranchée est de savoir qui répond d’un achat agentique non autorisé. L’utilisateur a délégué, la plateforme a hébergé, le modèle a raisonné et vous avez accepté, et aucune règle de réseau n’attribue encore cela proprement. Conservez les preuves de mandat que les protocoles produisent. C’est le seul enregistrement qui montre ce que l’humain a réellement approuvé.

La position réglementaire du Royaume-Uni

L’authentification forte est en réexamen, pas tranchée

Le Payments Forward Plan du Trésor britannique, publié le 26 février 2026, place clairement le sujet sur la feuille de route. La modernisation de la réglementation des services de paiement comprend des mises à jour du régime d’authentification forte du client et, selon les termes mêmes du plan, l’examen de la question de savoir si une évolution de la réglementation est nécessaire pour accompagner les paiements par IA agentique.

Le calendrier est lent : une consultation du Trésor au deuxième trimestre 2026, un document de discussion de la FCA du deuxième au quatrième trimestre, une réponse à la consultation au quatrième trimestre, et des déclarations de politique de la FCA en 2027 et 2028. Quiconque vous affirme que les règles britanniques du paiement agentique sont fixées avance une supposition.

La FCA applique les règles existantes, elle n’en écrit pas de nouvelles

La position publiée de la FCA sur l’intelligence artificielle, mise à jour le 13 février 2026, est explicite : elle ne prévoit pas d’introduire de réglementation supplémentaire pour l’IA et s’appuiera sur les cadres existants, qui atténuent selon elle beaucoup des risques associés à l’IA.

Pour un marchand, c’est rassurant et un peu inutile. Rassurant parce que rien de neuf ne vous tombe dessus. Inutile parce que les cadres existants n’ont pas été rédigés en pensant à l’achat machine délégué, et que les vides se comblent au cas par cas plutôt que par une règle.

L’angle du règlement européen sur l’IA si vous vendez en Europe

Si vous déployez vous-même un agent, un assistant d’achat ou un agent de support capable de transiger, les obligations de transparence de l’article 50 du règlement européen sur l’IA s’appliquent à partir du 2 août 2026. Les orientations de la Commission européenne sur l’article 50 exigent que les personnes soient informées qu’elles interagissent avec un système d’IA, dès le début de la première interaction et de manière claire et distinguable, sauf si cela est évident.

Cette obligation pèse sur les fournisseurs et les déployeurs du système, pas sur un marchand dont le site est visité par un agent extérieur. Si vous construisez l’agent, il est à vous. Si l’agent d’un tiers achète chez vous, il est à ce tiers.

La Commission a publié à côté un code de bonnes pratiques sur le marquage des contenus générés par IA. Si vous produisez des descriptions produit à grande échelle pour une consommation par des machines, cela vaut la lecture avant d’étendre encore la pratique.

Un plan sur douze mois, classé par coût

Quasi gratuit : corriger les données produit

Des données produit complètes, exactes et structurées, avec des niveaux de stock réels, des dimensions, des matières, des délais de livraison et des conditions de retour. Cela se rentabilise par la visibilité dans la recherche par IA, qu’un agent vous achète quelque chose un jour ou non, et c’est ce qui en fait le seul investissement vraiment sûr de cette liste.

Un jour : auditer vos règles antibots

Listez ce que vous bloquez et pourquoi. Décidez délibérément si un trafic d’agents identifié doit atteindre les fiches produit et le tunnel de paiement. Écrivez la décision pour que la personne suivante ne l’inverse pas par accident. Si votre trafic bascule déjà vers les surfaces IA, l’analyse de Google AI Mode et le trafic de votre site est le complément utile.

Une semaine : rendre vos politiques lisibles par une machine

Retours, livraison, garantie et conditions d’éligibilité exprimés comme des données plutôt que comme de la prose sur une page. Cela réduit le risque de retours décrit plus haut et c’est le préalable à toute intégration ultérieure d’un paiement agentique.

En continu et gratuit : une veille

Programmez un rappel trimestriel pour vérifier l’état des quatre spécifications et voir si votre plateforme e-commerce ou votre prestataire de paiement a livré une prise en charge. Sur une plateforme hébergée, l’essentiel du travail arrivera comme une fonction à activer, comme cela a été le cas chez Shopify. Sur un développement sur mesure, les arbitrages de Shopify face à une solution e-commerce sur mesure prennent ici plus de poids.

Ce qu’il ne faut pas encore faire

Ne construisez pas un paiement agentique sur mesure. Des spécifications qui ont changé deux fois en douze mois et qui comptent deux publications changeront encore, et vous intégreriez en avance sur votre plateforme, pour un trafic que vous ne pouvez pas encore mesurer.

N’acceptez pas les paiements en stablecoins parce que x402 les prend en charge. C’est une décision de trésorerie, de fiscalité et de comptabilité avec de vraies frictions, et la transaction moyenne à 32 cents indique que la demande porte sur l’accès aux API, pas sur la vente au détail.

N’achetez pas une mission de conseil en commerce agentique tarifée sur un marché qui n’existe pas encore pour vous. Mesurez d’abord votre propre trafic d’agents. S’il est nul, la réponse honnête est d’attendre.

Ne construisez pas d’agents d’achat autonomes pour vos propres approvisionnements sans avoir lu d’abord les modes de défaillance, que nous exposons dans agents IA en entreprise. Les mêmes problèmes de délégation s’appliquent quand c’est vous l’acheteur.

Ce qu’il reste à faire pour un marchand britannique

La course aux standards est réelle, le parrainage est sérieux, et le volume grand public n’est pas encore là pour la plupart d’entre vous. Cette combinaison plaide pour une préparation peu coûteuse et contre un engagement onéreux.

Mecanik construit les briques sous-jacentes comme un travail ordinaire : données produit structurées, exactitude des flux, politique antibots et intégration de paiement via notre service de développement web, et systèmes tournés vers les agents via nos services d’intégration d’IA. Notre jugement est que les trois premiers points de la liste ci-dessus méritent d’être traités ce trimestre, et le quatrième quand vos journaux montreront quelqu’un qui demande.

Questions fréquentes

Les agents IA achètent-ils déjà chez des marchands ordinaires ? Rarement. Le tableau de bord x402 indiquait 75,41 millions de transactions pour 24,24 millions de dollars sur trente jours, lu le 2 septembre 2026, soit environ 32 cents américains en moyenne, ce qui est la signature d’agents qui paient un accès à des API plutôt que d’agents qui achètent des marchandises. Le paiement agentique grand public existe, mais il se concentre sur quelques surfaces et a souvent été limité d’abord aux acheteurs américains.

Quelle est la différence entre AP2, ACP, UCP et x402 ? Ils occupent des couches différentes. AP2 enregistre la preuve cryptographique qu’un humain a autorisé un achat, ACP définit les points d’accès de paiement qu’un agent appelle pour acheter chez un marchand, UCP expose un détaillant entier aux surfaces IA de Google, et x402 permet à une machine de payer une seule requête HTTP. Ils sont conçus pour se composer, pas pour se remplacer.

Bloquer les robots IA empêche-t-il les agents d’acheter chez moi ? C’est possible. Les agents acheteurs et les aspirateurs de pages arrivent par le même protocole depuis une infrastructure semblable, et la gestion des bots voit du trafic plutôt qu’un dessein. Les schémas de signature cryptographique comme Web Bot Auth prouvent quel opérateur appelle, mais pas son intention, alors examinez délibérément ce que vous bloquez au lieu de supposer qu’une règle par défaut reste correcte.

L’authentification forte s’applique-t-elle quand un agent IA paie ? La position n’est pas tranchée au Royaume-Uni. Le Payments Forward Plan du Trésor du 26 février 2026 s’engage à mettre à jour le régime d’authentification forte du client et à examiner si la réglementation doit changer pour accompagner les paiements par IA agentique, les déclarations de politique de la FCA n’étant pas attendues avant 2027 ou 2028. Le contournement du secteur consiste à authentifier l’humain une fois, au moment de la délégation.

Que doit faire un marchand britannique dans l’année qui vient ? Trois choses peu coûteuses. Rendez vos données produit complètes, exactes et structurées, stock en direct et conditions de retour compris. Auditez vos règles antibots pour que le blocage soit une décision et non un accident. Publiez vos politiques de livraison et de retour comme des données lisibles par une machine. Maintenez ensuite une veille trimestrielle sur les spécifications et attendez que vos propres journaux montrent la demande.