Depuis un an, le paiement dit agentique se construit surtout du côté des réseaux de cartes, qui ajoutent des mandats et des identifiants d’agent à leurs rails existants. Fin juillet 2026, Coinbase a pris le problème par l’autre bout avec son offre commerçants, Coinbase Business : plutôt que d’adapter la carte à la machine, elle a branché l’encaissement sur un protocole conçu pour des machines, x402, et règle en stablecoin. Le 11 août, une mise à jour de l’offre y a ajouté de nouvelles fonctions.
Ce que contient l’offre
- Acceptation des agents, ouverte fin juillet : les pages d’encaissement déjà utilisées par le commerçant peuvent recevoir des paiements émis par des agents logiciels via x402, avec règlement en USDC sur le compte du commerçant.
- Kit de développement, annoncé le 23 juillet : un SDK x402 publié par la plateforme développeur de Coinbase permet d’ajouter l’acceptation à une API, à un serveur MCP ou à un service web en trois lignes de code, selon l’éditeur.
- Acceptation de l’USDT, ajoutée le 11 août : les liens de paiement, pages d’encaissement et factures acceptent ce second stablecoin, converti automatiquement en USDC au règlement.
- Outils marchands, ajoutés le 11 août : liens de paiement réutilisables avec limites d’usage, montants flexibles (minimum, maximum ou au choix du payeur), catalogue de produits réutilisable et collecte des données nécessaires à l’exécution de la commande.
402 Payment Required, un code réservé depuis trente ans
Le protocole s’appuie sur un code de statut HTTP resté lettre morte pendant des décennies. Le 402 Payment Required figure dans la spécification du web depuis ses premières versions, avec la mention explicite qu’il est réservé à un usage futur. x402 lui donne enfin ce contenu : une négociation de paiement lisible par une machine, insérée dans le dialogue normal entre un client et un serveur.
- L’agent appelle une ressource payante (une API, un article, un calcul, un jeu de données).
- Le serveur répond
402et joint les modalités : montant, actif accepté, adresse de règlement. - L’agent règle en stablecoin, sans intervention humaine, à partir du budget que son mandant lui a alloué.
- L’agent rejoue la requête en présentant la preuve de paiement dans un en-tête ; le serveur délivre la ressource.
Deux familles de protocoles, deux paris
L’écosystème agentique s’organise aujourd’hui autour de deux logiques qui ne s’excluent pas. La première conserve les instruments existants et ajoute une couche de mandats vérifiables, pour qu’un émetteur sache qu’un agent agit au nom d’un porteur identifié et dans les limites qu’il a fixées. La seconde, celle de x402, suppose que le payeur n’a pas besoin d’être un porteur au sens de la carte : il lui suffit d’un solde et d’un protocole.
| Rails carte adaptés aux agents | x402 et règlement stablecoin | |
|---|---|---|
| Instrument | Carte tokenisée, mandat rattaché au porteur | Solde en stablecoin détenu par l’agent ou son mandant |
| Autorisation | Émetteur, avec authentification du porteur en amont | Vérification du paiement par le serveur du commerçant |
| Montant minimal viable | Contraint par les frais fixes par transaction | Micro-montants revendiqués comme viables |
| Révocation | Chargeback et procédure de litige du réseau | Aucune : le règlement est définitif |
| Cadre juridique | Régime des services de paiement, responsabilités connues | Régime des crypto-actifs, responsabilités moins balisées |
Ce que l’absence de chargeback veut vraiment dire
Coinbase présente comme un argument commercial l’absence de risque d’impayé : un règlement stablecoin ne se rétracte pas. Du point de vue du commerçant, la promesse est réelle et ancienne, c’est celle du virement. Du point de vue du payeur, elle a un revers exact : il n’existe pas d’équivalent du droit au remboursement organisé par le réseau carte lorsque le bien n’est pas livré ou que l’ordre n’a pas été autorisé.
Un second point mérite attention : la conformité. Accepter un paiement d’un agent revient à accepter un paiement dont le donneur d’ordre humain n’est pas dans la transaction. La chaîne d’obligations en matière de connaissance du client, de sanctions et de lutte contre le blanchiment suppose un client identifiable. Les protocoles agentiques déportent cette identification vers l’amont, au moment où le mandat est délivré, et non vers le point d’acceptation. C’est une architecture cohérente, mais elle ne sera opposable que lorsque les régulateurs l’auront reconnue comme telle.
Reste la portée de l’offre elle-même. Cinq mille entreprises et cent mille paiements cumulés situent l’offre à l’échelle d’une expérimentation avancée, pas d’un rail de masse. Son intérêt tient moins aux volumes qu’à la nature du geste : l’acceptation d’un paiement machine n’est plus un projet de laboratoire, c’est une case à cocher dans une interface commerçant.