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 la conformité et l’infrastructure, à la fin, tout 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’engouement pour l’IA ? Je pense que non. Bien sûr, certains projets surfent sur la tendance. Mais si on limite la compréhension de AI × Web3 à un simple collage de narratifs, on risque de manquer une transformation plus profonde : l’IA responsable de la compréhension, de la prise de décision et de l’action, 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 nouvelle répartition des rôles.

Le ministre des Finances de Hong Kong, Paul Chan, a également é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, afin d’accroître l’efficacité des transactions et de 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 manière 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 au départ : pourquoi, dès qu’on parle d’Agentic Payment ou d’Agentic Commerce, on a l’impression que c’est forcément lié à la crypto, aux stablecoins ou à la blockchain ?

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

Si un agent ne fait que m’aider à 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. Une seule autorisation de l’utilisateur, et l’agent exécute le paiement dans la limite des quotas et règles, en utilisant une carte bancaire, une carte virtuelle, un compte entreprise ou un portefeuille de paiement tiers. Rien d’irrationnel à cela.

Le problème n’est donc pas “est-ce qu’on peut utiliser une carte bancaire”. Bien sûr que oui. La vraie question est : la carte bancaire et la carte de crédit, à quel segment répondent-elles dans le cadre de l’Agentic Payment, et lesquelles ne peuvent pas couvrir ? L’agent IA utilisera-t-il une carte bancaire ? Et pourquoi, une fois qu’on atteint un certain stade de développement de l’Agentic Payment, on ne peut pas presque inévitablement recourir aux stablecoins et à la blockchain ?

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

Si l’Agentic Payment se limite à faire en sorte que l’IA aide à finaliser le paiement, par exemple pour acheter un billet ou 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 bancaire peut tout à fait être utilisée, tout comme la carte de crédit.

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

Ainsi, les acteurs traditionnels comme Visa, Mastercard ou Stripe ne disparaîtront pas. Ils pourraient même devenir 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 simplement de miser sur un stablecoin, mais de permettre aux commerçants d’accepter directement des paiements venant d’agents, en supportant à la fois stablecoins et moyens de paiement fiat comme les cartes, BNPL, etc. Autrement dit, dans la phase initiale de l’Agentic Payment, la coexistence entre paiement traditionnel et stablecoins est plus probable que leur remplacement immédiat. Mais cela ne couvre qu’une partie du checkout dans le commerce agentique.

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

Le vrai défi apparaît dans un autre contexte : l’agent ne se contente pas 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, des interfaces de données, des services de modèles, des nœuds de calcul, des ressources de contenu, des outils d’automatisation, voire un autre agent.

J’ai récemment rencontré un exemple concret : je voulais créer un assistant d’analyse de trafic, capable d’appeler automatiquement des sources comme Semrush pour analyser un site web, ses mots-clés, ses concurrents et ses tendances. Mais en préparant le projet, j’ai réalisé que le problème n’était pas “l’IA peut analyser”, mais “comment elle obtient les données”. Beaucoup de sources commerciales ne sont pas conçues pour des appels ponctuels payants et instantanés. Par exemple, Semrush fonctionne avec un système d’abonnement, de forfaits et d’unités API. Chaque requête consomme un certain nombre d’unités, et l’utilisateur doit avoir un accès API ou acheter un pack d’unités. Même si l’API Trends peut être achetée séparément, elle reste basée sur un système d’unités.

Pour un agent, ce modèle n’est pas naturel. Si l’agent doit faire une seule requête de temps en temps, il ne veut pas forcément créer un compte SaaS ou acheter un gros pack d’unités. Il veut simplement faire une requête 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 l’Agentic Payment et le modèle traditionnel d’API. La majorité des API aujourd’hui facturent pour “l’achat par l’humain”, pas pour “l’achat machine à la demande”.

Le problème n’est donc pas “est-ce qu’on peut débiter une carte”. La réponse est oui. La vraie question est : la carte bancaire ou la carte de crédit, à quel segment répondent-elles dans le cadre de l’Agentic Payment, et lesquelles ne peuvent pas couvrir ? L’agent IA utilisera-t-il une carte bancaire ? Et pourquoi, une fois qu’on atteint un certain stade, on ne peut pas presque inévitablement recourir aux stablecoins et à la blockchain ?

2. La carte bancaire ne résout pas l’économie agentique

Si l’agent ne fait que finaliser un paiement dans un checkout classique, alors utiliser une carte bancaire, une carte virtuelle ou Apple Pay suffit. Mais si l’objet de la transaction n’est pas un commerçant, mais une API, un modèle, une ressource de données, ou encore un autre agent, le problème change.

Dans ce cas, ce dont les machines ont besoin, ce n’est pas un simple bouton “payer”, mais un protocole de paiement compréhensible par une machine : l’agent demande une ressource, le service lui indique : “il faut payer, le prix est X, l’adresse de paiement est Y, les moyens supportés sont Z”. L’agent vérifie si la dépense est dans le cadre de l’autorisation utilisateur. Si oui, il paie. Le service vérifie le paiement, et libère la ressource.

Ce processus, simple en apparence, comble une lacune historique d’Internet : la couche native de paiement. Internet a toujours supporté le flux d’informations, mais pas le paiement. La transaction financière est souvent une couche supplémentaire : création de compte, liaison de carte, intégration à une passerelle, achat de forfait, 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 approuve, on achète, on rembourse. Mais pour un agent, c’est lourd.

L’agent ne doit pas devoir créer un compte à chaque appel API, ni acheter un forfait complet, ni passer par tout le processus de paiement et d’achat pour quelques centimes. C’est pour cela que des protocoles comme x402 ont été imaginés.

x402 réactive le code HTTP 402 Payment Required, longtemps peu utilisé. Il permet au service de dire directement au client : “il faut payer pour accéder à cette ressource”. Le client peut être humain ou machine. Une fois le paiement effectué, le service vérifie, puis renvoie la ressource.

Coinbase définit très simplement 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 services sans avoir besoin de comptes, sessions ou authentifications complexes.

Ce qui compte, ce n’est pas “utiliser Coinbase” ou “USDC”, mais que x402 intègre le paiement dans le cycle requête-réponse d’Internet.

Autrefois :

• inscription
• achat de forfait
• obtention de clé API
• appel de service
• réconciliation

Avec x402 :

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

Ce processus est crucial pour l’Agentic Payment, car il ne s’agit pas de quelques gros achats, mais de nombreux petits paiements en temps réel pour des appels de service.

Par exemple :

• un agent de rédaction achète une requête de données pour un article
• 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 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

Si chaque service exigeait un compte, un abonnement, une clé API, une validation manuelle, l’agent serait bloqué. L’intérêt de x402, ce n’est pas de rendre le paiement “plus crypto”, mais de le rendre aussi simple et automatique que le protocole HTTP : une requête, une réponse, une validation.

L402, une autre voie, s’appuie aussi sur HTTP 402, mais intègre des mécanismes comme Lightning Network ou macaroons pour la preuve d’accès et le paiement de petites sommes. L’objectif est de faciliter l’authentification et la facturation pour des API, des ressources de calcul, etc., permettant aux agents IA de participer plus facilement.

Ce n’est pas une invention récente : des tentatives ont toujours existé pour combiner contrôle d’accès, micropaiements et droits 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, si. Les agents ne vont pas appeler des centaines de sources chaque jour, mais ils le feront. Ils ne vont pas faire des appels, des comparaisons, des paiements en temps réel entre services, mais ils le feront.

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

Dans l’écosystème Tether, on voit aussi apparaître des initiatives similaires. La documentation x402 de Tether WDK souligne l’importance pour les agents IA de pouvoir payer programmatique pour des ressources, en intégrant le paiement dans la pile web, permettant à un agent de découvrir le prix, signer le paiement, et obtenir la ressource dans un seul cycle requête-réponse. T402 se veut une norme ouverte pour des paiements natifs internet, supportant crypto, fiat, stablecoins, tokens, et compatible avec Tether WDK. Ce n’est pas encore une norme officielle, mais une exploration en cours autour de l’écosystème USDT/Tether.

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

• AP2 répond à : “Pourquoi un agent est-il autorisé à payer ?”
• x402, L402, T402 répondent à : “Comment un service peut-il demander un paiement lorsqu’un agent demande une ressource ?”
• La blockchain répond à : “Avec quel actif la transaction est-elle réglée, où est-elle vérifiée, et comment assurer un paiement rapide, programmable et transfrontalier ?”

Ces couches ne sont pas identiques, mais leur assemblage constitue une infrastructure d’Agentic Payment cohérente. Sinon, on se retrouve avec un paradoxe : un agent intelligent, capable de rechercher, décider, agir, mais qui doit revenir à des processus classiques pour payer, avec création de comptes, validation manuelle, etc. Ce n’est pas une véritable “Agentic Payment”, mais un simple assistant de navigation.

Il ne faut pas non plus être naïf : faire entrer un agent dans la chaîne de paiement blockchain comporte des risques, notamment la perte de contrôle, la fraude, la non-fourniture du service, ou des attaques. Une transaction sur la blockchain, une fois envoyée, est difficile à annuler. Si l’agent est compromis, si l’autorisation est trop large, si le service ne livre pas, ou si un site malveillant induit en erreur, cela pose problème.

C’est pourquoi l’Agentic Payment ne consiste pas à donner à l’agent un portefeuille pour dépenser à tout va. Mais à mettre en place un cadre de contrôle : quotas, listes blanches, listes noires, limites d’usage, niveaux de risque, approbation humaine, mécanismes d’arrêt, audit. Pour des petits paiements, automatisés, à faible risque, cela peut fonctionner. Pour des transactions importantes ou sensibles, il faut revenir à une validation humaine.

L’intérêt de la blockchain dans ce contexte, ce n’est pas de rendre le paiement “plus crypto”, mais d’offrir une couche de responsabilité et de vérification pour l’action économique de l’agent. Elle permet de prouver que l’argent dépensé a été autorisé, que la ressource achetée est enregistrée, que l’action est traçable, et que la responsabilité peut être engagée.

C’est cela, la véritable place de la blockchain dans l’Agentic Payment. Pas une foi aveugle, ni une narration, ni une simple addition “IA + Web3”, mais une infrastructure pour que, lorsque la machine participe à l’économie, l’état de ses actions soit vérifiable et responsable.

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 doit payer en stablecoin, pourquoi la blockchain ? Ne pourrait-on pas utiliser un registre centralisé ? Stripe, Visa, une banque, ou une plateforme qui fait la comptabilité ?

C’est possible. Si l’agent évolue dans un environnement fermé, comme faire ses achats sur Amazon, utiliser un SaaS, ou dans un système interne d’entreprise, un registre centralisé suffit. La plateforme connaît l’utilisateur, l’agent, les permissions, le montant dépensé, la livraison du service.

Mais l’intérêt de l’Agentic Payment, c’est qu’il peut s’étendre à des scénarios multi-plateformes, multi-services, multi-wallets, multi-nations, voire multi-agents. À ce stade, la question n’est plus “l’argent peut-il sortir”, mais “pourquoi, qui l’a autorisé, qui est responsable, la livraison a-t-elle été faite, et comment tracer tout cela ?”

Ce sont ces questions qui justifient la valeur de la blockchain dans ce contexte. Pas parce que toutes les transactions doivent y être, mais parce que, dans un environnement où l’agent agit pour le compte d’un utilisateur, chaque action économique doit laisser une trace vérifiable.

L’humain peut tolérer un certain manque de transparence : si un service n’est pas livré, il peut contacter le support ; si une erreur de paiement survient, il peut faire une contestation ; si une transaction est frauduleuse, il peut faire opposition. Mais pour un agent, qui agit à grande vitesse, avec de nombreux petits paiements, ces mécanismes sont trop lourds.

L’agent a besoin d’une responsabilité claire, d’un registre de ses actions, d’un moyen de prouver qu’il a été autorisé, qu’il a payé, qu’il a reçu la ressource. La blockchain fournit cette infrastructure.

C’est pourquoi AP2, x402, T402, et la stabilité des stablecoins, sont liés. Ce n’est pas pour faire du “Web3” pour le plaisir, mais pour que l’action économique de l’agent soit traçable, vérifiable, responsable.

5. La fin du “carte vs stablecoin” : une stratification du système de paiement

En conclusion, je ne pense pas que l’Agentic Payment se résumera à une simple substitution : stablecoin pour remplacer la carte, blockchain pour remplacer le réseau de paiement traditionnel.

Ce jugement est trop simpliste, et la réalité le contredira probablement longtemps. La majorité des paiements dans le monde physique continueront d’être assurés par la carte, Visa, Mastercard, Stripe, PayPal, et les systèmes existants. Les scénarios de consommation humaine, de réservation, d’achat en ligne ou hors ligne, ne disparaîtront pas du jour au lendemain.

Même dans le commerce agentique naissant, il est probable que l’agent commence par s’intégrer dans ces systèmes existants. La majorité des commerçants, des consommateurs, des banques, des réseaux de cartes sont déjà en place, avec des processus de gestion des risques, des litiges, des remboursements, et de conformité bien rodés. La voie la plus simple pour un agent qui doit faire un achat unique ou une tâche simple, c’est d’utiliser ces rails.

Le vrai enjeu, c’est que l’Agentic Payment ne se limite pas à ce niveau. Si l’agent doit simplement cliquer sur “checkout”, alors oui, il peut continuer à utiliser la carte bancaire. Mais si l’agent doit accéder à des réseaux plus ouverts, appeler des API, acheter des données, payer des modèles, régler des calculs, ou faire des transactions entre agents, alors il lui faut une nouvelle couche de protocole de paiement.

Ce qui me semble probable, c’est que le futur ne sera pas une opposition “carte vs stablecoin”, mais une stratification du système de paiement.

Dans le monde de la consommation humaine et des commerçants traditionnels, la carte, la banque, le portefeuille, le compte bancaire resteront principaux. L’agent, dans ses tâches classiques, utilisera ces rails.

Mais dans les scénarios plus machine, plus décentralisés, plus ouverts, comme l’appel à des API, la gestion de ressources numériques, la coordination entre agents, la blockchain et les stablecoins seront plus adaptés. La raison : ici, l’objet de paiement n’est pas un commerçant, mais une ressource numérique, un service, un calcul, une donnée, ou un autre agent. La fréquence est plus élevée, le montant plus petit, la diversité plus grande, la nécessité d’automatiser plus forte.

En résumé : la carte répond à la problématique du paiement dans l’ère humaine, la blockchain et les stablecoins répondent à celle de l’échange et du règlement dans l’économie machine.

Ce n’est pas que la blockchain ou les stablecoins soient déjà prêts. La complexité de leur utilisation, la gestion des portefeuilles, la régulation, la liquidité, la sécurité, tout cela doit encore évoluer. Mais leur intérêt, c’est qu’ils offrent une couche de paiement native, programmable, vérifiable, et transfrontalière, adaptée à l’agent IA.

Ce n’est pas parce que tous les paiements deviendraient crypto, mais parce que, lorsque la transaction concerne un logiciel ou un agent, la monnaie stable devient la première “langue” de règlement native à l’Internet.

Mais cela ne répond pas à une autre question : après que l’agent ait dépensé, qui a autorisé ? Où est la preuve ? La livraison ? La responsabilité ? La traçabilité ? La responsabilité ?

C’est là que la blockchain joue un rôle essentiel : pas pour remplacer le paiement traditionnel, mais pour fournir une infrastructure vérifiable, responsable, transparente.

6. La nécessité d’une nouvelle stratification du système de paiement

En résumé, je ne pense pas que l’avenir soit une simple substitution : stablecoin pour la carte, blockchain pour le réseau. La réalité sera une stratification, avec des couches différentes pour différents usages.

Dans la sphère humaine et commerciale classique, la carte, la banque, le portefeuille, le système de paiement traditionnel continueront de dominer. Mais dans les scénarios d’automatisation, d’interopérabilité, de ressources numériques, de coordination entre agents, la blockchain et les stablecoins seront de plus en plus indispensables.

Ce n’est pas une question de “remplacer” la carte, mais d’ajouter une couche supplémentaire, adaptée à l’économie des logiciels et des agents.

Ce qui est certain, c’est que la blockchain ne remplacera pas tout, mais qu’elle devient une couche essentielle pour rendre l’économie des agents vérifiable, responsable, et ouverte.

En conclusion :
L’Agentic Payment ne se résumera pas à une simple substitution de moyens de paiement. Il s’agit d’une évolution vers une infrastructure multi-couches, où la stabilité, la vérifiabilité, la programmabilité et l’interopérabilité seront clés. La blockchain, avec ses stablecoins, ses protocoles comme x402, et ses mécanismes de vérification, joue un rôle central dans cette nouvelle architecture. Ce n’est pas une question de “Web3 contre le reste”, mais de construire un système de paiement qui accompagne la nouvelle économie des logiciels et des agents intelligents.