L'agent IA peut-il utiliser une carte bancaire ?
Pourquoi le paiement agentique ne peut-il pas éviter les stablecoins et la blockchain ?

Auteur : Yokiiiya

La semaine dernière, lors du Web3 Festival à Hong Kong, une impression très claire était : aujourd’hui, presque chaque forum, chaque panel tourne autour de l’IA.

Peu importe si le sujet initial était le paiement, la stabilité des monnaies, RWA, portefeuilles, échanges, ou encore conformité et infrastructure, à la fin, cela revient presque toujours à la même question : lorsque l’IA ne se limite plus à générer du contenu, mais commence à exécuter des tâches, appeler des services, prendre des décisions, voire gérer des flux financiers, nos systèmes financiers et de paiement actuels sont-ils encore suffisants ?

Dans un panel auquel j’ai assisté, quelqu’un a même posé directement la question : le Web3 est-il en train de profiter de l’IA ? Je pense que non. Bien sûr, certains projets surfent sur la tendance. Mais si on limite l’IA × Web3 à une simple narration ou collage de récits, on risque de manquer une transformation plus profonde : l’IA qui comprend, décide et agit, tandis que Web3 fournit les actifs, comptes, règlements et environnements d’exécution vérifiables. Les deux ne sont pas simplement des concepts empilés, mais une redéfinition de la répartition des rôles.

Le secrétaire au Trésor de Hong Kong, Paul Chan, a aussi évoqué lors du Web3 Festival 2026 que, à l’avenir, les agents IA analyseront l’information à la vitesse de la machine et agiront en conséquence, tout en exploitant pleinement l’infrastructure blockchain en arrière-plan, pour améliorer l’efficacité des transactions et remodeler des secteurs comme la finance, le commerce, la gestion de patrimoine, la chaîne d’approvisionnement et la logistique. Quand l’IA commence à agir, la question ne se limite plus à “l’intelligence” elle-même, mais à la façon dont ces actions sont autorisées, réglées, enregistrées et responsables.

Parmi ces sujets, Agentic Payment devient un thème de plus en plus incontournable. Mais j’avais aussi une question simple : pourquoi, dès qu’on parle de Agentic Payment ou Agentic Commerce, on a l’impression que c’est forcément lié à la crypto, aux stablecoins ou à la blockchain ?

L’IA agent ne peut-elle pas utiliser une carte bancaire ? un crédit ? Apple Pay, Visa, Mastercard, Stripe, PayPal ?

Si un agent se contente d’acheter un billet d’avion, réserver un hôtel, ou renouveler un SaaS, en théorie, il peut tout à fait utiliser le système de paiement existant. Autorisation unique de l’utilisateur, l’agent exécute le paiement dans la limite des quotas et règles, en utilisant une carte bancaire, une carte virtuelle, un compte d’entreprise ou un portefeuille tiers, cela ne paraît pas déraisonnable.

Le problème n’est donc pas “la carte bancaire peut-elle être utilisée”. Bien sûr que oui. La vraie question est : la carte bancaire et la carte de crédit, à quel segment d’Agentic Payment sont-elles adaptées, et lesquelles ne le sont pas ? L’agent IA utilisera-t-il une carte bancaire ? Et pourquoi, à un certain stade, le développement de Agentic Payment semble presque inévitablement lié aux stablecoins et à la blockchain ?

1. La carte bancaire résout le checkout, pas l’économie agentique

Si Agentic Payment se limite à faire en sorte que l’IA exécute la dernière étape du paiement, comme acheter un billet, réserver un hôtel ou renouveler un SaaS, alors utiliser une carte bancaire, une carte virtuelle, Apple Pay, Stripe ou PayPal ne pose pas de problème fondamental. La carte peut être utilisée, la carte de crédit aussi.

L’utilisateur autorise une fois, l’agent paie dans la limite des quotas et règles. Ce n’est pas difficile à comprendre, c’est un peu comme une version plus intelligente du prélèvement automatique, d’une carte virtuelle d’entreprise, d’une carte de voyage ou d’un système d’achat automatisé.

Ainsi, les acteurs traditionnels comme Visa, Mastercard ou Stripe ne disparaîtront pas. Ils seront même probablement des portes d’entrée importantes pour le commerce agentique naissant.

Le protocole Machine Payments lancé par Stripe et Tempo illustre bien cela. Il ne s’agit pas uniquement de stablecoins, mais de permettre aux commerçants d’accepter directement les paiements des agents, en supportant à la fois stablecoins et cartes, BNPL ou autres moyens fiat. En résumé, dans les premières phases de l’Agentic Payment, la coexistence entre paiement traditionnel et stablecoins est plus probable que la substitution immédiate. Mais cela ne couvre qu’une partie du commerce agentique : le checkout.

Le checkout suppose que produits, commerçants, commandes, boutons de paiement, remboursements et gestion des litiges existent déjà. L’agent n’est qu’un accompagnant, automatisant une étape d’achat.

Le vrai défi apparaît dans un autre contexte : l’agent ne se contente plus d’entrer dans un panier préétabli, mais doit enchaîner des appels à des ressources, combiner des services, réaliser des tâches dans un réseau ouvert.

Par exemple, un agent de recherche IA pour un rapport sectoriel pourrait devoir appeler plusieurs bases de données, acheter des documents payants, accéder à différents API de modèles, lancer un crawler, payer un générateur de graphiques, voire acheter une analyse à un autre agent. Il n’y a pas forcément de “boutique” traditionnelle, ni de page de checkout. L’agent interagit avec des API, interfaces de données, services de modèles, nœuds de calcul, ressources de contenu, outils automatisés, voire un autre agent.

J’ai récemment rencontré un exemple précis : je voulais créer un assistant d’analyse de trafic, capable d’appeler automatiquement des sources comme Semrush pour analyser un site, ses mots-clés, ses concurrents et ses tendances. Mais en organisant la solution, j’ai compris que le problème n’était pas “l’IA peut-elle analyser”, mais “comment elle accède aux données”. Beaucoup de sources commerciales ne sont pas conçues pour un appel unique, paiement immédiat. Par exemple, l’API Semrush fonctionne selon un modèle d’abonnement, de forfait et d’unités API. Chaque requête consomme un certain nombre d’unités, et l’accès nécessite un abonnement ou l’achat d’un pack d’unités. Même si l’API Trends peut être achetée séparément, elle reste basée sur ce modèle d’unités.

Pour un agent, ce modèle n’est pas naturel. Si l’agent doit faire une seule requête, il ne veut pas forcément créer un compte SaaS ou acheter un gros pack d’unités. Il veut simplement faire une demande comme un navigateur : combien ça coûte ? Ai-je l’autorisation d’acheter ? Si c’est dans le budget, il paie, et il reçoit la donnée immédiatement.

C’est là que se situe la fracture entre Agentic Payment et le modèle traditionnel d’API. Aujourd’hui, la majorité des API sont facturées pour “l’achat de logiciels par des humains”, pas pour “l’achat à la demande par des machines”.

Le problème d’Agentic Payment n’est pas la dernière étape de paiement, mais tout le processus : comment la machine continue d’obtenir l’autorisation, initier le paiement, vérifier la livraison, régler la transaction.

C’est là que la limite du système de cartes apparaît.

Ce n’est pas parce que la carte est dépassée, mais parce qu’elle a été conçue pour des scénarios de consommation humaine : un individu entre dans un commerce, choisit un produit, confirme la commande, paie, et la banque, l’organisme de cartes, l’acquéreur et le prestataire de paiement gèrent l’autorisation, la compensation, la gestion des risques et les litiges.

Mais l’économie agentique pose d’autres questions : pourquoi cet agent a-t-il le droit de dépenser cet argent ? comment le service peut-il vérifier qu’il ne s’agit pas d’un bot malveillant, mais d’une extension de la volonté réelle de l’utilisateur ? L’agent peut-il effectuer des paiements petits, fréquents, transversaux, sans intervention humaine ? Le service peut-il libérer immédiatement la ressource après paiement ? Si l’agent achète à tort, dépasse ses droits ou est attaqué, qui en porte la responsabilité ?

C’est aussi pour cela que Google, en développant AP2, n’a pas mis l’accent sur “quelle méthode de paiement utiliser”, mais sur un cadre de confiance plus général pour les paiements par agent. La spécification AP2 définit un cadre “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant et au prestataire de paiement d’effectuer des paiements pilotés par l’agent, en toute confiance. Elle précise aussi que l’agent doit disposer d’un moyen sécurisé et simple d’obtenir des permissions limitées, pour agir au nom de l’utilisateur, et que la sécurité repose sur la signature cryptographique des parties.

Le premier enjeu de l’Agentic Payment n’est donc pas : d’où vient l’argent ? mais : par quel droit l’agent peut-il dépenser cet argent ?

Le système de cartes peut répondre à une partie de cette question. Par exemple, via des cartes virtuelles, des tokens, la gestion de quotas, le contrôle des dépenses d’entreprise, des règles de gestion des risques, etc., l’agent peut réaliser des transactions dans le cadre du système existant.

Visa avance aussi dans cette voie. Son protocole Trusted Agent et ses initiatives d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser les agents IA à représenter les consommateurs ou entreprises dans le réseau commercial existant. La description officielle de Visa Developer précise que l’agent IA aidera à naviguer sur les sites, découvrir des produits, comparer des prix, faire des choix, avant même le checkout ; ces interactions automatiques étant souvent bloquées par des systèmes anti-bot ou des CDN.

Cela montre que les réseaux de paiement traditionnels ont aussi conscience que le commerce agentique ne se limite pas au bouton de paiement, mais couvre toute la chaîne : recherche, comparaison, sélection, autorisation, paiement. Mais leur force réside dans la capacité à faire entrer un agent dans le flux existant, pour réaliser une transaction autorisée. Ils ne résolvent pas naturellement la question : comment un agent peut, dans un réseau ouvert, initier en continu de petits paiements pour API, données, modèles, calculs, contenus, outils ou un autre agent.

Ce n’est pas que la carte ne puisse pas faire cela. C’est que, plus précisément, la carte résout le problème du checkout dans le commerce traditionnel, mais l’économie agentique a besoin d’un protocole de paiement plus fondamental.

Ce qui amène à la question suivante : si la cible de la transaction n’est pas un commerçant traditionnel, mais une API, un modèle, une interface de données, ou un autre agent, comment faire pour qu’une machine initie et réalise un paiement ?

C’est aussi la raison pour laquelle des protocoles comme x402, L402 ou T402 commencent à émerger.

2. Ce dont l’agent a vraiment besoin, c’est d’un protocole de paiement lisible par machine

Si la cible est un commerçant classique, l’agent peut utiliser le flux de checkout existant, avec carte, virtual card ou portefeuille. Mais si la cible est une API, un modèle, une interface de données, ou un autre agent, le problème change.

Ce qu’il faut, c’est une procédure de paiement compréhensible par machine : l’agent demande une ressource. Le service répond : cette ressource coûte X, voici l’adresse de paiement, quels moyens sont supportés. L’agent vérifie si la dépense est dans le cadre de l’autorisation. Si oui, il paie. Le service vérifie le paiement, puis libère la ressource.

Ce processus paraît simple, mais il comble une lacune historique d’Internet : la couche native de paiement. Jusqu’ici, Internet supporte naturellement le flux d’informations : requêtes web, emails, API, téléchargement. Mais le paiement n’a pas été intégré dans le protocole Internet, il est souvent externalisé : création de comptes, liaison de cartes, intégration de passerelles, achat de forfaits, gestion de clés API, réconciliation mensuelle.

Pour l’humain, c’est acceptable. On s’inscrit, on se connecte, on lie sa carte, on achète, on rembourse. Mais pour une machine, c’est lourd.

Une machine ne devrait pas devoir créer un compte à chaque appel API, ni acheter un forfait complet pour une seule requête, ni suivre tout un processus de paiement humain pour quelques centimes. C’est la raison d’être de protocoles comme x402.

x402 réactive le code HTTP 402 Payment Required, longtemps existant mais peu utilisé. Il permet au serveur d’indiquer directement au client : pour accéder à cette ressource, il faut payer. Le client peut être humain ou machine. Une fois payé, le serveur vérifie, puis fournit la ressource.

Coinbase définit x402 comme un protocole ouvert permettant des paiements instantanés en stablecoin via HTTP, pour que clients humains ou machines puissent payer et accéder à des contenus ou services sans compte, session ou authentification complexe.

L’enjeu n’est pas “utiliser Coinbase” ou “USDC uniquement”. L’essentiel, c’est que x402 intègre le paiement dans le cycle requête-réponse d’Internet.

Avant, c’était :

• création de compte
• achat de forfait
• obtention de clé API
• appel de service
• réconciliation

Avec x402, cela devient :

• requête de ressource
• réponse 402 Payment Required
• paiement
• accès à la ressource

Ce qui est crucial pour l’Agentic Payment, c’est que ce processus ne concerne pas seulement quelques gros paiements, mais une multitude de petits paiements en temps réel, à la demande.

Par exemple :

• un agent de rédaction achète une requête de données
• un agent de recherche financière appelle un service d’analyse on-chain
• un agent de voyage demande plusieurs devis
• un agent de développement achète des inférences de modèles, des tests ou des environnements
• un agent d’analyse de trafic achète une seule fois des données Semrush pour un site, sans devoir souscrire à un SaaS complet

Si chaque service exige un compte, un abonnement, une clé API, un forfait ou une validation manuelle, l’exécution de l’agent sera bloquée par ces processus. La force de x402, ce n’est pas de rendre le paiement “plus crypto”, mais de le faire ressembler à un protocole Internet : une requête, une réponse, une vérification, une exécution automatique.

L402 suit une voie similaire, en combinant HTTP 402 avec des mécanismes comme Lightning Network ou macaroons pour l’authentification et le paiement de petits montants. Lightning Labs voit dans L402 un moyen de faire payer des API, des ressources de calcul, en facilitant la participation des agents IA.

Ce n’est pas une invention récente : des tentatives ont toujours existé pour combiner contrôle d’accès HTTP, micropaiements et droits sur services numériques. Mais jusqu’ici, le besoin n’était pas assez fort.

Les humains ne paient pas quelques centimes pour accéder à une API. Mais les agents oui. Les humains ne font pas des centaines d’appels par jour. Mais les agents oui. Les humains ne combinent pas en temps réel des appels, des prix, des paiements et des vérifications entre plusieurs services. Mais les agents, si.

L’émergence des IA agents donne tout son sens à cette voie HTTP-native.

Dans l’écosystème USDT / Tether, des initiatives similaires apparaissent. La documentation x402 de Tether WDK souligne l’importance pour les agents IA, car ils doivent pouvoir payer programmatique­ment pour des ressources ; x402 permet de faire du paiement dans la pile web, en découvrant le prix, en signant la transaction, en obtenant la ressource, tout dans un cycle de requête-réponse. T402 se présente aussi comme une norme ouverte pour des paiements natifs Internet, supportant crypto, fiat, stablecoins, tokens, et compatible avec Tether WDK. Attention, je ne dis pas que c’est “déjà la norme officielle de Tether”, mais que, dans l’écosystème USDT, des protocoles comme x402 sont en train d’émerger.

Ce phénomène traduit une tendance forte : l’Agentic Payment ne se limite pas à une compétition entre entreprises ou protocoles, mais construit une nouvelle couche de protocole.

• AP2 répond à la question : pourquoi un agent peut-il payer ?
• x402, L402, T402 répondent à la question : comment un agent demande-t-il un paiement, et comment le service le réalise-t-il ?
• La stabilité et la blockchain répondent à la question : avec quel actif, où, et comment faire la compensation, en temps réel, à faible coût, de façon programmable et transfrontalière ?

Ainsi, Agentic Payment et crypto ne sont pas simplement liés parce que Web3 veut “profiter” de l’IA. C’est plutôt parce que cette approche remet en question la “paiement natif” que l’Internet n’a pas encore résolue.

3. Pourquoi la stabilité : l’agent a besoin d’une unité de valeur stable, pas d’un actif volatil

Si un agent a vraiment besoin d’un protocole de paiement lisible par machine, automatisable, alors pourquoi parle-t-on surtout de stablecoins ? Pourquoi pas BTC ? ETH ? ou une carte bancaire classique ?

La clé n’est pas “l’actif crypto” en soi, mais le type d’actif dont l’agent a besoin. Si l’agent ne fait que détenir à long terme, il s’intéressera aux fluctuations, aux rendements, aux risques. Mais si l’agent paie pour réaliser une tâche, ce qu’il lui faut, c’est une unité de valeur stable.

Par exemple, un agent de recherche qui appelle une API de données peut payer 0,1 dollar. Un agent de codage qui invoque un modèle peut payer 0,03 dollar. Un agent marketing qui achète des données de trafic peut payer 1 dollar. Un agent d’approvisionnement qui compare, commande et paie doit maîtriser ses coûts dans le cadre du budget.

Dans ces scénarios, l’agent ne fait pas de trading ni de spéculation. Il réalise une tâche. Il doit donc connaître le prix : combien ça coûte ? La requête dépasse-t-elle le budget ? La dépense est-elle autorisée par l’utilisateur ? Après livraison, le coût doit être enregistré précisément.

Si l’actif de paiement est très volatile, la gestion du budget devient compliquée. Si aujourd’hui une API coûte 0,1 dollar, demain, à cause de la fluctuation, ça peut devenir 0,12 ou 0,08 dollar. Pour un marché, ce n’est pas un problème. Mais pour une machine achetant à la demande, c’est une complication inutile.

C’est pourquoi, dans l’Agentic Payment, la stabilité prime. La première valeur d’un stablecoin, c’est d’offrir une unité de valeur plus proche du monde réel. La majorité des API, SaaS, données, modèles, cloud sont déjà en dollars. Si l’agent paie en stablecoin, il peut tout gérer dans la même unité : budget, prix, autorisation, facturation.

Ce n’est pas une idée révolutionnaire, mais c’est crucial pour l’agent. Car il ne paie pas seulement, il doit aussi juger : cette requête vaut-elle le coût ? Le budget est-il suffisant ? Faut-il revenir à l’utilisateur ? Le coût doit être enregistré, et en cas d’erreur, expliqué : pourquoi cette dépense ?

L’Agentic Payment a donc besoin d’un actif de paiement peu volatile, lisible par machine, directement utilisable par programme. Le stablecoin répond mieux à ce besoin que BTC ou ETH.

La seconde valeur, c’est que le stablecoin est plus adapté aux paiements petits, fréquents, instantanés. La tendance x402 le montre déjà : permettre un paiement instantané, automatique, stablecoin via HTTP, pour que API, contenus et services puissent facturer à la fois humains et machines, sans compte ni authentification complexe. La requête API devient un point de paiement.

L’agent demande une ressource. Le service répond : paiement 402. L’agent vérifie le prix, signe la transaction, paie en stablecoin. Le service vérifie, libère la ressource.

Ce processus est idéal pour des paiements petits, fréquents, à la demande : requête de données, appel de modèle, déblocage de contenu, analyse on-chain, génération de graphique. La documentation x402 de Tether WDK le dit clairement : les agents IA doivent pouvoir payer programmatique­ment pour des ressources, et x402 leur permet de découvrir le prix, signer la transaction, obtenir la ressource dans un cycle requête-réponse.

Ce n’est pas une utilisation du tout différente de la carte bancaire. La carte est adaptée à la consommation humaine, le stablecoin à la consommation machine. La carte permet de payer dans un commerce, le stablecoin dans un réseau ouvert, pour des paiements instantanés, à faible coût. La carte ne disparaîtra pas, mais le stablecoin devient une unité de paiement native pour la machine, dans des scénarios à faible montant, haute fréquence, transfrontaliers.

La troisième valeur, c’est que le stablecoin, par sa nature, est plus adapté à l’interopérabilité et à la décentralisation. Un agent ne travaille pas forcément sur une seule plateforme. Il peut appeler des API américaines, des services européens, des interfaces asiatiques, des outils on-chain, et échanger avec d’autres agents. Si chaque étape dépend d’un compte bancaire local, d’un acquéreur, d’un mode de paiement, d’un cycle de règlement, le processus devient fragmenté. Le stablecoin, en tant qu’actif natif de l’Internet, circule 24/7, peut traverser plateformes, portefeuilles, applications, et être traité par contrats intelligents ou protocoles de paiement. Pour l’humain, c’est une transaction plus rapide. Pour l’agent, c’est une exécution continue, sans interruption liée aux horaires bancaires, aux frontières ou aux cycles de règlement.

Il doit disposer d’un actif de règlement disponible à tout moment, automatisable, vérifiable.

C’est aussi pour cela que x402, Tether WDK, et les explorations autour de Tether, avancent dans cette direction : faire du paiement stablecoin une composante native du web, accessible par machine, plutôt que de faire entrer l’agent dans une page de paiement conçue pour l’humain.

Mais attention, le stablecoin n’est pas sans problème.

Les réserves, la transparence, l’émetteur, la régulation, la liquidité sur la chaîne varient. Le BIS, dans son rapport annuel 2025, a critiqué les stablecoins, soulignant qu’ils présentent des insuffisances en termes de “singleness”, “elasticity” et “integrity”, et ne doivent pas être considérés comme une alternative complète au système monétaire moderne.

Plus précisément, le stablecoin n’est pas une monnaie parfaite, mais c’est aujourd’hui l’un des actifs de règlement natifs de l’Internet qui se rapproche le plus des besoins de l’Agentic Payment.

Sa valeur ne réside pas dans la “décentralisation narrative”, mais dans sa capacité à répondre à plusieurs conditions : stabilité de prix, programmabilité, circulation transplateforme, disponibilité 24/7, compatibilité avec HTTP-native payment, wallets, smart contracts, et audit on-chain.

C’est pourquoi, dès qu’on parle de ressources dans le web ouvert, le stablecoin apparaît naturellement. L’agent ne veut pas une “main qui swipe”, mais un langage de paiement que le logiciel peut comprendre et utiliser.

Si la carte est conçue pour la consommation humaine, le stablecoin est une langue de règlement pour l’économie machine.

Ce langage n’est pas encore mature. Il nécessite de meilleures régulations, des mécanismes d’émission plus stables, une gestion des risques plus claire, des portefeuilles mieux contrôlés, et une intégration avec AP2, x402, MPP pour devenir une composante viable de l’Agentic Payment à grande échelle.

Mais la direction est claire : l’agent a besoin d’une unité de valeur stable, d’un actif de règlement instantané, d’un moyen de paiement programmable, et d’une capacité à opérer à travers plateformes, frontières et services.

C’est pour cela que le stablecoin est incontournable dans l’Agentic Payment. Pas parce que tous les paiements doivent devenir crypto, mais parce qu’en passant d’un “consommateur humain” à un “agent logiciel”, l’argent devient pour la première fois une partie intégrante du protocole Internet.

Mais le stablecoin ne répond qu’à une question : avec quoi l’agent paie-t-il ? Il n’a pas encore répondu à l’autre : après avoir dépensé dans le réseau ouvert, qui a autorisé cette dépense, où est-elle allée, y a-t-il eu dépassement, la livraison a-t-elle été effectuée ? C’est là que la blockchain entre en jeu.

4. Pourquoi la blockchain : pas pour “mettre sur la chaîne”, mais pour rendre vérifiable le comportement de l’agent

Même si l’agent a besoin de payer en stablecoin, pourquoi la blockchain ? Un registre centralisé ne suffirait-il pas ? Stripe, Visa, une banque, ou une plateforme qui tient ses comptes ?

Bien sûr. Si l’agent évolue dans un environnement fermé, comme faire ses achats sur Amazon, utiliser un SaaS, ou gérer un achat interne à une entreprise, un registre centralisé suffit. La plateforme connaît l’utilisateur, l’agent, les droits, le montant dépensé, la livraison.

Mais l’intérêt de l’Agentic Payment, c’est qu’il ne se limite pas à un environnement fermé. Il peut traverser plateformes, services, portefeuilles, frontières, et impliquer plusieurs agents. À ce stade, la question n’est plus “l’argent peut-il sortir ?”, mais “qui l’a autorisé ?”, “qui est responsable en cas de dépassement ou d’erreur ?”, “le service a-t-il livré ?”.

Ce sont ces questions qui donnent tout leur sens à la blockchain dans l’Agentic Payment. Pas parce que tout doit être sur la chaîne, mais parce que, dès que l’agent commence à exécuter des tâches, appeler des services, gérer des flux financiers dans un réseau ouvert, chaque action doit laisser une trace vérifiable.

L’humain peut tolérer un certain manque de transparence : si un service n’a pas été livré, on peut contacter le support ; si une erreur de facturation survient, on peut consulter le contrat, la comptabilité, les emails, faire une réunion. La dispute peut être réglée à posteriori.

Mais pour un agent, c’est différent. La fréquence des transactions est plus élevée, les montants plus faibles, les services plus nombreux, la chaîne d’exécution plus longue. Si chaque paiement doit faire l’objet d’une vérification manuelle, d’une capture d’écran, d’un email, d’un appel au support, alors l’intérêt de l’agentic payment s’évanouit. Il faut une responsabilité claire, une traçabilité fiable.

Par exemple, un utilisateur donne à un agent une consigne : “Ce mois-ci, je ne veux pas dépenser plus de 100 dollars. Fais une analyse de marché. Tu peux acheter des données, invoquer des modèles, générer des graphiques, mais pas plus.” L’agent demande une API. Le service répond : cette requête coûte 0,2 dollar. L’agent vérifie si c’est dans le budget, paie, et le service livre la donnée. La question essentielle n’est pas “quelle blockchain ?”, mais “pouvons-nous, après coup, répondre : qui a autorisé cette dépense ?”, “qu’a-t-il acheté ?”, “le montant est-il conforme au budget ?”, “le service a-t-il livré ?”, “si l’agent a été manipulé, peut-on remonter à la source ?”

C’est aussi pour cela que, en relisant le white paper de Bitcoin, je ne le fais pas pour faire du “nostalgie”. Satoshi Nakamoto ne voulait pas inventer une “monnaie échangeable”, mais comment, sans tiers de confiance, faire en sorte qu’un transfert d’argent électronique soit vérifié, ordonné et enregistré par le réseau. La réponse est claire : le réseau inscrit la transaction dans une chaîne de hachages, sécurisée par preuve de travail, inaltérable sans refaire tout le travail.

L’Agentic Payment n’est pas tout à fait la même problématique. Il ne s’agit pas seulement de double dépense, mais d’autorisation, de dépassement, de livraison, de responsabilité. Mais ils partagent un point commun : dans un réseau ouvert, chaque action économique doit laisser une trace vérifiable.

C’est là que réside la véritable valeur de la blockchain. Elle ne sert pas à rendre le paiement “plus ésotérique”, mais à faire en sorte qu’un certain nombre d’états, qui étaient autrefois dans des bases de données privées, soient désormais vérifiables par tous. La preuve de paiement, l’autorisation, l’accès à un service, la condition de remboursement, la consommation du budget, tout cela peut être enregistré et vérifié selon des standards ouverts. Pour l’humain, cela signifie une comptabilité plus claire ; pour l’agent, cela devient la base de sa confiance.

Car l’agent n’est pas un humain. Il ne peut pas se contenter de “je me souviens que c’était comme ça”. Il a besoin d’une chaîne de preuves vérifiables, extérieures, indépendantes.

C’est aussi pour cela que AP2, x402, stablecoins et blockchain sont souvent évoqués ensemble, mais ne sont pas la même chose. AP2 n’est pas un protocole décentralisé, ni une blockchain. Google voit AP2 comme un cadre ouvert “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant, au prestataire de paiement d’effectuer des paiements pilotés par l’agent, en toute confiance. La spécification AP2 précise que l’agent doit disposer d’un moyen sécurisé et simple d’obtenir des permissions limitées, pour agir au nom de l’utilisateur, et que la sécurité repose sur la signature cryptographique.

Le premier enjeu de l’Agentic Payment, ce n’est pas : d’où vient l’argent ? mais : par quel droit l’agent peut-il dépenser cet argent ?

Le système de cartes peut répondre à une partie de cette question. Par exemple, via des cartes virtuelles, des tokens, la gestion de quotas, le contrôle des dépenses d’entreprise, des règles de gestion des risques, etc., l’agent peut réaliser des transactions dans le cadre du système existant.

Visa avance aussi dans cette voie. Son protocole Trusted Agent et ses initiatives d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser les agents IA à représenter les consommateurs ou entreprises dans le réseau commercial existant. La description officielle de Visa Developer précise que l’agent IA aidera à naviguer sur les sites, découvrir des produits, comparer des prix, faire des choix, avant même le checkout ; ces interactions automatiques étant souvent bloquées par des systèmes anti-bot ou des CDN.

Cela montre que les réseaux de paiement traditionnels ont aussi conscience que le commerce agentique ne se limite pas au bouton de paiement, mais couvre toute la chaîne : recherche, comparaison, sélection, autorisation, paiement. Mais leur force réside dans la capacité à faire entrer un agent dans le flux existant, pour réaliser une transaction autorisée. Ils ne résolvent pas naturellement la question : comment un agent peut, dans un réseau ouvert, initier en continu de petits paiements pour API, données, modèles, calculs, contenus, outils ou un autre agent.

Ce n’est pas que la carte ne puisse pas faire cela. C’est que, plus précisément, la carte résout le problème du checkout dans le commerce traditionnel, mais l’économie agentique a besoin d’un protocole de paiement plus fondamental.

Ce qui amène à la question suivante : si la cible de la transaction n’est pas un commerçant traditionnel, mais une API, un modèle, une interface de données, ou un autre agent, comment faire pour qu’une machine initie et réalise un paiement ?

C’est aussi la raison pour laquelle des protocoles comme x402, L402 ou T402 commencent à émerger.

5. Ce dont l’agent a vraiment besoin, c’est d’un protocole de paiement lisible par machine

Si la cible est un commerçant classique, l’agent peut utiliser le flux de checkout existant, avec carte, virtual card ou portefeuille. Mais si la cible est une API, un modèle, une interface de données, ou un autre agent, le problème change.

Ce qu’il faut, c’est une procédure de paiement compréhensible par machine : l’agent demande une ressource. Le service répond : cette ressource coûte X, voici l’adresse de paiement, quels moyens sont supportés. L’agent vérifie si la dépense est dans le cadre de l’autorisation. Si oui, il paie. Le service vérifie le paiement, puis libère la ressource.

Ce processus paraît simple, mais il comble une lacune historique d’Internet : la couche native de paiement. Jusqu’ici, Internet supporte naturellement le flux d’informations : requêtes web, emails, API, téléchargement. Mais le paiement n’a pas été intégré dans le protocole Internet, il est souvent externalisé : création de comptes, liaison de cartes, intégration de passerelles, achat de forfaits, gestion de clés API, réconciliation mensuelle.

Pour l’humain, c’est acceptable. On s’inscrit, on se connecte, on lie sa carte, on achète, on rembourse. Mais pour une machine, c’est lourd.

Une machine ne devrait pas devoir créer un compte à chaque appel API, ni acheter un forfait complet pour une seule requête, ni suivre tout un processus de paiement humain pour quelques centimes. C’est la raison d’être de protocoles comme x402.

x402 réactive le code HTTP 402 Payment Required, longtemps existant mais peu utilisé. Il permet au serveur d’indiquer directement au client : pour accéder à cette ressource, il faut payer. Le client peut être humain ou machine. Une fois payé, le serveur vérifie, puis fournit la ressource.

Coinbase définit x402 comme un protocole ouvert permettant des paiements instantanés en stablecoin via HTTP, pour que clients humains ou machines puissent payer et accéder à des contenus ou services sans compte, session ou authentification complexe.

L’enjeu n’est pas “utiliser Coinbase” ou “USDC uniquement”. L’essentiel, c’est que x402 intègre le paiement dans le cycle requête-réponse d’Internet.

Avant, c’était :

• création de compte
• achat de forfait
• obtention de clé API
• appel de service
• réconciliation

Avec x402, cela devient :

• requête de ressource
• réponse 402 Payment Required
• paiement
• accès à la ressource

Ce qui est crucial pour l’Agentic Payment, c’est que ce processus ne concerne pas seulement quelques gros paiements, mais une multitude de petits paiements en temps réel, à la demande.

Par exemple :

• un agent de rédaction achète une requête de données
• un agent de recherche financière appelle un service d’analyse on-chain
• un agent de voyage demande plusieurs devis
• un agent de développement achète des inférences de modèles, des tests ou des environnements
• un agent d’analyse de trafic achète une seule fois des données Semrush pour un site, sans devoir souscrire à un SaaS complet

Si chaque service exige un compte, un abonnement, une clé API, un forfait ou une validation manuelle, l’exécution de l’agent sera bloquée par ces processus. La force de x402, ce n’est pas de rendre le paiement “plus crypto”, mais de le faire ressembler à un protocole Internet : une requête, une réponse, une vérification, une exécution automatique.

L402 suit une voie similaire, en combinant HTTP 402 avec des mécanismes comme Lightning Network ou macaroons pour l’authentification et le paiement de petits montants. Lightning Labs voit dans L402 un moyen de faire payer des API, des ressources de calcul, en facilitant la participation des agents IA.

Ce n’est pas une invention récente : des tentatives ont toujours existé pour combiner contrôle d’accès HTTP, micropaiements et droits sur services numériques. Mais jusqu’ici, le besoin n’était pas assez fort.

Les humains ne paient pas quelques centimes pour accéder à une API. Mais les agents oui. Les humains ne font pas des centaines d’appels par jour. Mais les agents oui. Les humains ne combinent pas en temps réel des appels, des prix, des paiements et des vérifications entre plusieurs services. Mais les agents, si.

L’émergence des IA agents donne tout son sens à cette voie HTTP-native.

Dans l’écosystème USDT / Tether, des initiatives similaires apparaissent. La documentation x402 de Tether WDK souligne l’importance pour les agents IA, car ils doivent pouvoir payer programmatique­ment pour des ressources ; x402 permet de faire du paiement dans la pile web, en découvrant le prix, en signant la transaction, en obtenant la ressource, tout dans un cycle de requête-réponse. T402 se présente aussi comme une norme ouverte pour des paiements natifs Internet, supportant crypto, fiat, stablecoins, tokens, et compatible avec Tether WDK. Attention, je ne dis pas que c’est “déjà la norme officielle de Tether”, mais que, dans l’écosystème USDT, des protocoles comme x402 sont en train d’émerger.

Ce phénomène traduit une tendance forte : l’Agentic Payment ne se limite pas à une compétition entre entreprises ou protocoles, mais construit une nouvelle couche de protocole.

• AP2 répond à la question : pourquoi un agent peut-il payer ?
• x402, L402, T402 répondent à la question : comment un agent demande-t-il