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, au final, 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, invoquer 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 AI × 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 nouvelle répartition des rôles.

Le ministre des Finances de Hong Kong, Paul Chan, lors de son discours au Web3 Festival 2026, a aussi évoqué que les agents IA analyseront à la vitesse machine l’information et agiront, tout en exploitant pleinement l’infrastructure blockchain en arrière-plan, pour améliorer l’efficacité des transactions et remodeler 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 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’IA agent ne peut-elle pas utiliser une carte bancaire ? une carte de 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 invoquer le système de paiement existant. Une seule autorisation 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 entreprise ou un portefeuille tiers, cela paraît tout à fait 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 répondent-elles dans le cadre de l’Agentic Payment, et lesquelles ne peuvent pas couvrir ? L’agent IA utilisera-t-il vraiment une carte bancaire ? Et pourquoi, une fois qu’on atteint un certain stade d’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 exécuter à l’agent IA 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 n’a pas de problème fondamental. La carte peut être utilisée, la carte de crédit aussi.

L’utilisateur donne une autorisation préalable, l’agent exécute le paiement dans la limite des quotas et règles. Ce n’est pas difficile à comprendre, c’est un peu comme un prélèvement automatique plus intelligent, une carte virtuelle d’entreprise, une carte de voyage ou 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 de 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 d’agents, en supportant à la fois stablecoins et moyens fiat comme cartes, BNPL, etc. Autrement dit, dans la phase initiale de l’Agentic Payment, paiement traditionnel et stablecoins coexisteront plutôt qu’ils ne se remplaceront immédiatement. Mais cela ne couvre qu’une partie du commerce agentique : le checkout.

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

Le vrai enjeu apparaît dans un autre scénario : l’agent ne se contente pas d’entrer dans un panier préétabli, mais il appelle en continu des ressources, assemble des services, accomplit des tâches.

Par exemple, un agent de recherche IA pour un rapport sectoriel pourrait devoir invoquer 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 à un autre agent une analyse spécifique. Il n’y a pas forcément de “boutique” traditionnelle, ni de page de checkout complète. Il s’agit plutôt d’interfaces API, de flux de données, de services de modèles, de nœuds de calcul, de ressources de contenu, d’outils automatisés, voire d’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, je me suis rendu compte que le problème n’était pas “l’IA peut analyser”, mais “comment elle accède aux données”. Beaucoup de sources commerciales ne sont pas conçues pour des appels uniques, payés à l’usage, avec réponse immédiate. Par exemple, Semrush fonctionne avec un système d’API basé sur des comptes, des forfaits et des unités API. Chaque requête consomme un certain nombre d’unités, et il faut avoir un accès API ou acheter un pack d’unités. Même leur API Trends, qui peut être achetée séparément, repose sur ce même modèle.

Mais 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, je paie, et je reçois la réponse 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 facturent pour “l’achat de logiciels par des humains”, pas pour “ressources à la demande pour des machines”.

Le problème de l’Agentic Payment n’est pas la dernière étape de paiement, mais tout le processus : comment la machine continue d’obtenir l’autorisation, initie le paiement, vérifie la livraison, règle 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, le processeur de paiement et le service de règlement s’occupent de l’autorisation, du règlement, du contrôle des risques et des litiges.

Mais l’économie agentique pose un autre problème : pourquoi cet agent a-t-il le droit de dépenser cet argent ? Comment le service peut-il confirmer 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, 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 agentiques. La spécification AP2 définit un cadre “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant et au fournisseur 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é, simple, pour obtenir des permissions limitées, pour agir au nom de l’utilisateur ; la sécurité du protocole repose sur la signature cryptographique par l’utilisateur et le commerçant.

Donc, la première question de l’Agentic Payment 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, les cartes virtuelles, les identifiants tokenisés, la gestion des quotas, le contrôle des dépenses d’entreprise, les règles de gestion des risques, tout cela permet à l’agent d’effectuer des transactions dans le cadre des systèmes existants.

Visa travaille aussi dans cette direction. Son protocole Trusted Agent et ses solutions d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser des agents IA à représenter des consommateurs ou des entreprises dans le réseau marchand actuel. La description officielle de Visa Developer pour Trusted Agent indique que : les agents IA aideront à naviguer sur les sites, découvrir des produits, comparer des prix et faire des choix, avant même le checkout ; ces interactions automatisées sont souvent bloquées par les systèmes anti-bot ou 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 final. 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 et continuer à faire de petits paiements pour API, données, modèles, calculs, contenus ou autres agents.

Ce n’est pas que la carte ne peut pas faire, c’est qu’elle ne répond pas à cette problématique. Plus précisément : la carte résout le checkout dans un réseau marchand 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 encore un autre agent, comment faire pour initier et compléter un paiement entre machines ? C’est aussi la raison pour laquelle des protocoles comme x402, L402, 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 de crédit, débit, virtuelle ou portefeuille, pour payer. Mais si la cible est une API, un modèle, une ressource de contenu, ou encore un autre agent, le problème change.

Il faut alors une procédure de paiement compréhensible par machine : l’agent demande une ressource. Le service répond : cette ressource nécessite paiement, quel est le prix, quelle est l’adresse de paiement, quels moyens sont supportés. L’agent vérifie si la dépense est dans l’autorisation utilisateur. Si oui, il paie. Le service vérifie le paiement, 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 “paiement” n’est pas une partie intégrée du protocole Internet, c’est une extension à un autre système : 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 tolérable. On peut s’inscrire, se connecter, lier sa carte, faire des achats, se faire rembourser. Mais pour une machine, c’est lourd.

L’agent ne doit pas devoir créer un compte à chaque appel API, ni acheter un gros pack d’unités, ni suivre tout un processus d’achat et de gestion. Il faut une solution plus légère, comme un simple appel HTTP, pour demander : combien ça coûte ? Ai-je l’autorisation ? Je paie si c’est dans le budget, et je reçois la réponse.

C’est là que la fracture entre l’Agentic Payment et le modèle API traditionnel apparaît. Aujourd’hui, la majorité des API facturent pour “l’achat de logiciels par des humains”, pas pour “ressources à la demande pour des machines”.

Le problème n’est pas la dernière étape de paiement, mais tout le processus : comment la machine continue d’obtenir l’autorisation, initie le paiement, vérifie la livraison, règle 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 la consommation humaine : entrer dans un commerce, choisir un produit, confirmer, payer, et la banque, l’organisme de cartes, le processeur de paiement et le service de règlement s’occupent de l’autorisation, du règlement, du contrôle des risques et des litiges.

Mais l’économie agentique pose une autre question : pourquoi cet agent a-t-il le droit de dépenser cet argent ? Comment le service peut-il confirmer 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 faire 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, 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 agentiques. La spécification AP2 définit un cadre “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant et au fournisseur 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é, simple, pour obtenir des permissions limitées, pour agir au nom de l’utilisateur ; la sécurité du protocole repose sur la signature cryptographique par l’utilisateur et le commerçant.

Donc, la première question de l’Agentic Payment 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, les cartes virtuelles, les identifiants tokenisés, la gestion des quotas, le contrôle des dépenses d’entreprise, les règles de gestion des risques, tout cela permet à l’agent d’effectuer des transactions dans le cadre des systèmes existants.

Visa travaille aussi dans cette direction. Son protocole Trusted Agent et ses solutions d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser des agents IA à représenter des consommateurs ou des entreprises dans le réseau marchand actuel. La description officielle de Visa Developer pour Trusted Agent indique que : les agents IA aideront à naviguer sur les sites, découvrir des produits, comparer des prix et faire des choix, avant même le checkout ; ces interactions automatisées sont souvent bloquées par les systèmes anti-bot ou 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 final. 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 et continuer à faire de petits paiements pour API, données, modèles, calculs, contenus ou autres agents.

Ce n’est pas que la carte ne peut pas faire, c’est qu’elle ne répond pas à cette problématique. Plus précisément : la carte résout le checkout dans un réseau marchand 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 ressource de données, ou encore un autre agent, comment faire pour initier et compléter un paiement entre machines ? C’est aussi la raison pour laquelle des protocoles comme x402, L402, T402 commencent à émerger.

3. 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 de crédit, débit, virtuelle ou portefeuille, pour payer. Mais si la cible est une API, un modèle, une ressource de contenu, ou encore un autre agent, le problème change.

Il faut alors une procédure de paiement compréhensible par machine : l’agent demande une ressource. Le service répond : cette ressource nécessite paiement, quel est le prix, quelle est l’adresse de paiement, quels moyens sont supportés. L’agent vérifie si la dépense est dans l’autorisation utilisateur. Si oui, il paie. Le service vérifie le paiement, 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 “paiement” n’est pas une partie intégrée du protocole Internet, c’est une extension à un autre système : 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 tolérable. On peut s’inscrire, se connecter, lier sa carte, faire des achats, se faire rembourser. Mais pour une machine, c’est lourd.

L’agent ne doit pas devoir créer un compte à chaque appel API, ni acheter un gros pack d’unités, ni suivre tout un processus d’achat et de gestion. Il faut une solution plus légère, comme un simple appel HTTP, pour demander : combien ça coûte ? Ai-je l’autorisation ? Je paie si c’est dans le budget, et je reçois la réponse.

C’est là que la fracture entre l’Agentic Payment et le modèle API traditionnel apparaît. Aujourd’hui, la majorité des API facturent pour “l’achat de logiciels par des humains”, pas pour “ressources à la demande pour des machines”.

Le problème n’est pas la dernière étape de paiement, mais tout le processus : comment la machine continue d’obtenir l’autorisation, initie le paiement, vérifie la livraison, règle 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 la consommation humaine : entrer dans un commerce, choisir un produit, confirmer, payer, et la banque, l’organisme de cartes, le processeur de paiement et le service de règlement s’occupent de l’autorisation, du règlement, du contrôle des risques et des litiges.

Mais l’économie agentique pose une autre question : pourquoi cet agent a-t-il le droit de dépenser cet argent ? Comment le service peut-il confirmer 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 faire 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, 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 agentiques. La spécification AP2 définit un cadre “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant et au fournisseur 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é, simple, pour obtenir des permissions limitées, pour agir au nom de l’utilisateur ; la sécurité du protocole repose sur la signature cryptographique par l’utilisateur et le commerçant.

Donc, la première question de l’Agentic Payment 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, les cartes virtuelles, les identifiants tokenisés, la gestion des quotas, le contrôle des dépenses d’entreprise, les règles de gestion des risques, tout cela permet à l’agent d’effectuer des transactions dans le cadre des systèmes existants.

Visa travaille aussi dans cette direction. Son protocole Trusted Agent et ses solutions d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser des agents IA à représenter des consommateurs ou des entreprises dans le réseau marchand actuel. La description officielle de Visa Developer pour Trusted Agent indique que : les agents IA aideront à naviguer sur les sites, découvrir des produits, comparer des prix et faire des choix, avant même le checkout ; ces interactions automatisées sont souvent bloquées par les systèmes anti-bot ou 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 final. 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 et continuer à faire de petits paiements pour API, données, modèles, calculs, contenus ou autres agents.

Ce n’est pas que la carte ne peut pas faire, c’est qu’elle ne répond pas à cette problématique. Plus précisément : la carte résout le checkout dans un réseau marchand 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 ressource de données, ou encore un autre agent, comment faire pour initier et compléter un paiement entre machines ? C’est aussi la raison pour laquelle des protocoles comme x402, L402, T402 commencent à émerger.

4. 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 de crédit, débit, virtuelle ou portefeuille, pour payer. Mais si la cible est une API, un modèle, une ressource de contenu, ou encore un autre agent, le problème change.

Il faut alors une procédure de paiement compréhensible par machine : l’agent demande une ressource. Le service répond : cette ressource nécessite paiement, quel est le prix, quelle est l’adresse de paiement, quels moyens sont supportés. L’agent vérifie si la dépense est dans l’autorisation utilisateur. Si oui, il paie. Le service vérifie le paiement, 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 “paiement” n’est pas une partie intégrée du protocole Internet, c’est une extension à un autre système : 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 tolérable. On peut s’inscrire, se connecter, lier sa carte, faire des achats, se faire rembourser. Mais pour une machine, c’est lourd.

L’agent ne doit pas devoir créer un compte à chaque appel API, ni acheter un gros pack d’unités, ni suivre tout un processus d’achat et de gestion. Il faut une solution plus légère, comme un simple appel HTTP, pour demander : combien ça coûte ? Ai-je l’autorisation ? Je paie si c’est dans le budget, et je reçois la réponse.

C’est là que la fracture entre l’Agentic Payment et le modèle API traditionnel apparaît. Aujourd’hui, la majorité des API facturent pour “l’achat de logiciels par des humains”, pas pour “ressources à la demande pour des machines”.

Le problème n’est pas la dernière étape de paiement, mais tout le processus : comment la machine continue d’obtenir l’autorisation, initie le paiement, vérifie la livraison, règle 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 la consommation humaine : entrer dans un commerce, choisir un produit, confirmer, payer, et la banque, l’organisme de cartes, le processeur de paiement et le service de règlement s’occupent de l’autorisation, du règlement, du contrôle des risques et des litiges.

Mais l’économie agentique pose une autre question : pourquoi cet agent a-t-il le droit de dépenser cet argent ? Comment le service peut-il confirmer 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 faire 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, 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 agentiques. La spécification AP2 définit un cadre “indépendant du mode de paiement”, permettant à l’utilisateur, au commerçant et au fournisseur 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é, simple, pour obtenir des permissions limitées, pour agir au nom de l’utilisateur ; la sécurité du protocole repose sur la signature cryptographique par l’utilisateur et le commerçant.

Donc, la première question de l’Agentic Payment 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, les cartes virtuelles, les identifiants tokenisés, la gestion des quotas, le contrôle des dépenses d’entreprise, les règles de gestion des risques, tout cela permet à l’agent d’effectuer des transactions dans le cadre des systèmes existants.

Visa travaille aussi dans cette direction. Son protocole Trusted Agent et ses solutions d’Intelligent Commerce visent à faire reconnaître, faire confiance et autoriser des agents IA à représenter des consommateurs ou des entreprises dans le réseau marchand actuel. La description officielle de Visa Developer pour Trusted Agent indique que : les agents IA aideront à naviguer sur les sites, découvrir des produits, comparer des prix et faire des choix, avant même le checkout ; ces interactions automatisées sont souvent bloquées par les systèmes anti-bot ou 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 final. 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 et continuer à faire de petits paiements pour API, données, modèles, calculs, contenus ou autres agents.

Ce n’est pas que la carte ne peut pas faire, c’est qu’elle ne répond pas à cette problématique. Plus précisément : la carte résout le checkout dans un réseau marchand 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 ressource de données, ou encore un autre agent, comment faire pour initier et compléter un paiement entre machines ? C’est aussi la raison pour laquelle des protocoles comme x402, L402, T402 commencent à émerger.

5. La stabilité, la nécessité d’une unité de valeur stable pour l’agent

Si l’agent a vraiment besoin d’un protocole de paiement lisible par machine, capable d’automatiser le paiement, pourquoi parle-t-on surtout de stablecoin ? Pourquoi pas BTC ? ETH ? Ou simplement une carte bancaire ?

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

Par exemple, un agent de recherche qui invoque 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 respecter un budget précis.

Dans ces scénarios, l’agent ne fait pas de trading ni de spéculation. Il accomplit une tâche. Il doit donc connaître le prix : combien coûte cette ressource ? La dépense 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é avec précision.

Si la valeur de l’actif de paiement fluctue fortement chaque jour, la gestion du budget devient compliquée. Aujourd’hui, une API coûte 0,1 dollar, demain 0,12 ou 0,08 selon la fluctuation. Pour un marché d’échange, cela n’a pas beaucoup d’impact. Mais pour une machine achetant des ressources à la demande, cela complique tout.

C’est pourquoi, dans l’Agentic Payment, une monnaie stable est plus naturelle qu’un actif crypto volatil. La première valeur d’une stablecoin est d’offrir une unité de compte plus proche du monde réel. La majorité des API, SaaS, services de données, modèles, cloud sont déjà libellés en dollars. Si l’agent paie en stablecoin, il peut directement gérer son budget, ses prix, ses autorisations, ses factures dans une même unité.

Cela paraît simple, mais c’est crucial pour l’agent. Car il ne se limite pas à payer. Il doit aussi juger si la dépense est justifiée, si le budget est suffisant, si l’autorisation est valable, si la livraison est conforme, si le coût est bien enregistré, et pouvoir expliquer en cas de problème : pourquoi cette dépense ?

L’Agentic Payment a donc besoin d’un actif de paiement peu volatile, lisible par machine, pouvant être invoqué par programme. La stablecoin répond mieux à ce besoin que BTC ou ETH.

La deuxième valeur, c’est que la stablecoin est plus adaptée aux paiements petits, fréquents, instantanés. Comme on l’a vu avec x402, cette tendance est claire. Coinbase définit x402 comme un protocole permettant des paiements instantanés et automatisés en stablecoin, pour que API, contenus numériques et services puissent recevoir des paiements programmatiques, sans comptes, sessions ou authentifications complexes. En pratique, cela veut dire que le paiement peut se faire dans une requête API, sans passer par un checkout complet.

L’agent demande une ressource. Le service répond : paiement requis. L’agent vérifie le prix, l’autorisation. Il paie en stablecoin. Le service vérifie le paiement, libère la ressource.

Ce processus est idéal pour des scénarios de petits paiements, haute fréquence, appels à 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 souligne : les agents IA doivent pouvoir payer de façon programmée pour des ressources, et x402 leur permet de découvrir le prix, signer le paiement, obtenir la ressource dans une seule cycle request-response.

Ce n’est pas une utilisation du tout différente de la carte bancaire, mais dans un contexte où la transaction ne se limite pas à un checkout marchand. La stablecoin est une unité de règlement instantanée, adaptée à ces usages machine-to-machine. La carte bancaire reste utile pour la consommation humaine, mais la stablecoin est plus adaptée pour des paiements automatiques, à la demande, en petits montants, à travers des réseaux ouverts.

Ce qui nous amène à la troisième valeur : la stabilité intrinsèque, la compatibilité avec l’échelle mondiale et la décentralisation. Un agent peut opérer dans plusieurs régions, avec différentes banques, différents systèmes de paiement locaux. La stablecoin, en tant qu’actif natif de l’internet, peut circuler 24/7, être transférée entre wallets, intégrée dans des contrats intelligents ou protocoles de paiement. Pour l’humain, c’est plus rapide. Pour l’agent, c’est une continuité d’exécution, sans interruption liée aux horaires bancaires ou aux frontières.

C’est pourquoi, dans le cadre de x402, Tether WDK, et des explorations autour de l’écosystème USDT, on voit émerger cette tendance : faire de la stablecoin un composant natif du web stack, accessible par machine, pour des paiements programmatiques, plutôt que de faire passer l’agent par une page de paiement humaine.

Mais attention, la stabilité n’est pas sans problème.

Les réserves, la transparence, la régulation, la liquidité sur la chaîne varient selon les stablecoins. Le rapport annuel de BIS 2025 critique aussi leur “ségrégation”, leur “élasticité” et leur “intégrité”, soulignant qu’ils ne remplacent pas encore complètement la monnaie moderne.

Plus précisément, la stablecoin n’est pas une monnaie parfaite, mais c’est l’un des actifs natifs d’internet qui répond le mieux aux besoins de l’Agentic Payment. Elle ne doit pas être vue comme une simple “narrative décentralisée”, mais comme une unité de compte stable, programmable, transférable 24/7, compatible avec HTTP-native payment, wallets, smart contracts, et audit blockchain.

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

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

Ce langage n’est pas encore mature. Il nécessite une meilleure régulation, 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 à grande échelle de l’Agentic Payment.

Mais la direction est claire : l’agent a besoin d’une unité de valeur stable, d’un actif de règlement instantané, d’une monnaie programmable, d’un système de paiement interopérable, global et décentralisé.

C’est pour cela que la stablecoin est incontournable dans l’Agentic Payment. Pas parce que tout doit devenir crypto, mais parce que, lorsque la cible devient un “logiciel”, la monnaie doit ressembler à un protocole internet.

Mais la stablecoin ne répond qu’à une seule question : “avec quoi l’agent paie-t-il ?”. Elle ne répond pas encore à l’autre : “après avoir dépensé dans un 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 intervient.

6. Pourquoi la blockchain : pas pour “mettre sur la chaîne”, mais pour rendre les actions de l’agent vérifiables

Même si l’agent doit payer en stablecoin, pourquoi utiliser la blockchain ? Un registre centralisé ne suffirait-il pas ? Stripe, Visa, une banque, ou une plateforme pourrait-elle faire l’affaire ?

Bien sûr. Si l’agent évolue dans un environnement fermé, comme faire ses achats sur Amazon, utiliser un SaaS, ou gérer un système interne, 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 peut traverser plusieurs plateformes, services, portefeuilles, pays, voire agents. À ce stade, la question n’est plus “l’argent peut-il sortir ?”, mais “qui l’a autorisé ?”, “qui est responsable ?”, “l’agent a-t-il dépassé ses droits ?”, “le service a-t-il livré ?”, “en cas de problème, qui porte la responsabilité ?”.

Ce sont ces questions qui donnent tout leur sens à la blockchain dans l’Agentic Payment. Pas parce