Source originale : Waterdrop Capital

Résumé

Les grands modèles évoluent de simples outils de réponse à des questions vers des agents intelligents capables de planifier, d'invoquer des outils et de produire des résultats. Parallèlement, le règlement en stablecoins, les protocoles de paiement natifs HTTP (HTTP 402) et les portefeuilles intelligents commencent à converger vers une infrastructure de paiement conçue pour les machines. Un programme peut recevoir un devis à l'exécution, signer une autorisation et effectuer un micropaiement — une idée purement théorique il y a quelques années, désormais une voie technologique viable.

Toutefois, « les machines peuvent payer » ne signifie pas « les machines peuvent mener à bien des transactions ». Lorsqu’un agent intelligent doit acheter des services tels que la recherche, des données, de la puissance de calcul, la génération de contenus ou des analyses professionnelles, il se heurte encore à des défis comme la découverte de points de terminaison, la comparaison de devis, les paiements inter-protocoles, le contrôle budgétaire, la vérification de livraison et la consolidation comptable. Les rails de paiement régissent le transfert de valeur, mais ne résolvent pas automatiquement comment la demande trouve l’offre, ni si le service adéquat a bien été fourni après paiement.

Cela signifie que, lors de la prochaine phase des paiements pour agents, la concurrence pourrait ne plus porter uniquement sur le débit du protocole, la vitesse de règlement ou le nombre de blockchains prises en charge, mais plutôt sur la capacité à construire une véritable infrastructure d’acheteurs machines. Cet article examine pourquoi les paiements pour agents deviendront une filière autonome — en partant de la structure de la demande, de l’évolution des protocoles, des goulots d’étranglement réels et de la division du travail sur le marché — et quels maillons essentiels font encore défaut avant une adoption à grande échelle.

Introduction : Les agents intelligents bénéficient d’un « budget discrétionnaire » limité

Au cours des deux dernières années, les capacités des agents intelligents ont évolué très rapidement. Initialement, les grands modèles se limitaient à la génération d’informations : les utilisateurs posaient des questions, et les modèles produisaient du texte. Ensuite, l’appel d’outils a permis aux modèles d’explorer des pages web, d’interroger des bases de données, d’exécuter du code ou d’interagir avec des logiciels. Plus loin encore, les agents intelligents ont commencé à décomposer des objectifs, à élaborer des plans et à ajuster leurs actions en fonction des résultats externes sur plusieurs cycles d’exécution.

Lorsque les cibles d’exécution étaient limitées à des outils gratuits ou à des systèmes internes d’entreprise, les autorisations d’appel pouvaient être préconfigurées par les développeurs. Toutefois, les capacités de haute qualité disponibles sur les marchés ouverts nécessitent généralement un paiement : les données financières en temps réel sont facturées à l’appel, le web scraping consomme des crédits, la puissance de calcul et les GPU sont facturés à l’usage, et la génération vidéo ou les bases de données professionnelles comportent des tarifs clairs. Pour qu’un agent intelligent accomplisse une tâche de façon autonome, il doit inévitablement devenir acheteur au moment de l’exécution.

Le modèle commercial traditionnel des API n’a pas été conçu pour ce type d’acheteur. Il exige qu’une personne visite d’abord un site web, crée un compte, lie une carte bancaire, choisisse un forfait, protège une clé API, puis insère cette clé dans l’environnement logiciel. La décision d’achat et l’appel effectif sont séparés dans le temps : l’humain achète avant la tâche, tandis que le logiciel se contente de consommer le quota déjà acquis.

Un agent ne sait souvent pas ce dont il a besoin avant d’atteindre une étape donnée de la tâche. Il ne peut pas prédire à l’avance quelle source de données il appellera finalement, ni exiger que l’utilisateur crée un compte pour chaque service potentiel. Son processus d’approvisionnement est caractérisé par son caractère instantané, de faible valeur, multi-marchand, fréquent et orienté résultats. Pour lui, l’expérience la plus naturelle n’est pas « s’abonner puis appeler », mais « découvrir le service, obtenir un devis, autoriser le paiement, recevoir le résultat ».

Les paiements pour agents ne consistent donc pas simplement à ajouter un bouton de paiement à un chatbot. Cela signifie que les logiciels acquièrent une autorité limitée de dépense et mettent en place un processus d’approvisionnement propre aux machines. Les humains définissent les objectifs, les budgets et les seuils de risque ; les agents allouent les fonds dans ces limites. Le paiement passe ainsi d’une simple action de règlement à un élément intégré du système décisionnel de l’agent.

1. Pourquoi les paiements pour agents deviendront une filière autonome

1.1 De l’appel d’outils à l’action économique

La différence entre les agents et les scripts d’automatisation classiques ne réside pas uniquement dans leur capacité de raisonnement. Les scripts exécutent des processus prédéfinis, et les ressources et fournisseurs requis sont généralement codés en dur ; les agents choisissent leur parcours en fonction de l’environnement. Dans une même tâche de recherche, ils peuvent d’abord acheter des résultats de recherche, puis, selon ces résultats, décider s’ils ont besoin d’une base de données sectorielle, et enfin faire appel à un autre modèle pour une validation croisée. Chaque étape d’approvisionnement influe sur les décisions suivantes.

Ce modèle « exécuter tout en approvisionnant » intègre le choix économique au cœur du cycle d’exécution logiciel. Un agent doit non seulement évaluer la disponibilité d’un outil, mais aussi sa pertinence économique : le prix respecte-t-il le budget ? La rapidité de réponse convient-elle à la tâche ? La fiabilité historique de livraison est-elle avérée ? Un service alternatif serait-il plus adapté ? Le routage traditionnel d’outils se concentre sur la correspondance des capacités, tandis que l’approvisionnement machine doit simultanément gérer prix et risques liés au contrepartie. Dans ces transactions, c’est l’agent lui-même qui assume le risque : le paiement peut aboutir, mais le service ne pas être fourni.

Ainsi, le besoin fondamental des paiements pour agents n’est pas un paiement automatique sans condition, mais une délégation contrôlée du pouvoir d’achat aux logiciels. Les utilisateurs ne confieront pas facilement leur portefeuille entier à un agent, mais accepteront volontiers d’allouer quelques dollars à une tâche précise, autorisant ainsi plusieurs achats de quelques centimes. Des autorisations importantes nécessiteront encore une construction progressive de la confiance, mais des autorisations mineures peuvent déjà générer une valeur réelle.

1.2 Micropaiements, haute fréquence et multiples marchands : une mutation de l’économie des paiements

L’infrastructure de paiement d’internet humain est conçue pour traiter des transactions relativement peu fréquentes et de valeur élevée. Les réseaux de cartes bancaires, les passerelles de paiement et les systèmes d’abonnement comportent tous des coûts fixes, incitant les marchands à regrouper de nombreuses demandes dans des forfaits mensuels. Pour des requêtes API valant seulement quelques centimes, les frais, les risques de rétrofacturation et les coûts de gestion de compte liés aux paiements traditionnels peuvent dépasser la valeur même des biens.

La consommation par machines est exactement l’inverse. Un agent peut initier plusieurs achats auprès de multiples marchands en quelques minutes pour produire un seul résultat. Le montant par transaction est très faible, mais la fréquence des appels est élevée, et le volume total des transactions peut largement dépasser celui des consommateurs humains. Les monnaies stables et le règlement programmable sur chaîne offrent une nouvelle base économique pour ces scénarios : les fonds circulent 24h/24, les autorisations de paiement sont signées par logiciel, et les services sont tarifés directement à l’appel.

Plus important encore, l’approvisionnement multi-marchand transformera la nature de la concurrence sur le marché des API. Les modèles d’abonnement incitent les utilisateurs à rester longtemps fidèles à un seul fournisseur, tandis que le paiement à l’usage permet aux agents de choisir dynamiquement le prestataire adapté à chaque tâche. Les fournisseurs de services ne se font plus concurrence uniquement pour des contrats annuels, mais aussi pour répondre à un besoin ponctuel. Prix, performances et historique d’exécution peuvent influencer en temps réel les décisions de routage.

1.3 Les monnaies stables évoluent d’un moyen d’échange vers une infrastructure de règlement

Sur le marché crypto précoce, la demande de monnaies stables provenait principalement des opérations de trading et de la fuite vers des actifs sûrs. À mesure que l’émission, la garde, la conformité et l’infrastructure interchaînes mûrissent progressivement, les monnaies stables pénètrent désormais les règlements transfrontaliers, la gestion des trésoreries d’entreprise et les paiements natifs du web. Pour les paiements automatisés, elles offrent un avantage supplémentaire : elles sont à la fois une monnaie et un actif numérique directement manipulable par programme.

Les paiements par carte bancaire reposent sur l’identité du titulaire, les comptes bancaires et les réseaux géographiques. Les agents n’ont pas d’identité de personne physique et ne peuvent pas ouvrir indépendamment un compte selon les procédures traditionnelles. Un portefeuille soumis à des politiques peut toutefois servir d’interface de financement pour l’agent : l’opérateur y injecte un solde limité, définit des plafonds par transaction et par session, et conserve le droit de geler ou de révoquer ; l’agent ne signe que des paiements dans la limite de son autorisation.

Cela ne signifie pas que les paiements sur chaîne soient intrinsèquement supérieurs à tous les paiements traditionnels. La protection des consommateurs, les mécanismes de remboursement, la confidentialité, la gestion des clés et la responsabilité réglementaire restent à résoudre. Mais pour les paiements machine-à-machine, les micro-paiements à l’usage et l’approvisionnement mondial de services, les monnaies stables programmables offrent une compatibilité évidente. Pour la première fois, « appeler une interface » et « payer une interface » peuvent être compressés dans une seule interaction réseau.

2. Des rails de paiement sont déjà apparus : x402, MPP et transactions natives HTTP

2.1 Transformer le code d’état 402 en interface commerciale

HTTP a réservé il y a longtemps le code d’état 402 « Paiement requis », sans qu’il n’ait jamais généré de flux généralisé pendant près de 30 ans. Les protocoles de paiement automatisés ont réactivé cette sémantique : le client sollicite une ressource payante, le serveur renvoie 402 avec des conditions de paiement lisibles par machine ; le client choisit une option acceptable, effectue la signature ou le paiement, puis réessaie la requête avec les justificatifs adéquats.

L’importance de ce processus réside dans l’élimination de la page d’inscription humaine. La découverte des prix, les exigences de paiement et la livraison du contenu se produisent toutes au niveau du protocole, compréhensible par les programmes. Pour les développeurs, les API payantes n’ont plus besoin de construire un portail SaaS complet autour de comptes, d’offres et de clés ; pour les agents, les services peuvent être découverts comme des pages web ordinaires et achetés au moment précis où ils sont nécessaires.

x402 est l’un des protocoles ouverts les plus suivis sur cette voie. Il structure les défis de paiement et les justificatifs autour du code HTTP 402, permettant aux prestataires de collecter un paiement à chaque requête. MPP, en revanche, part d’un écosystème différent et explore des méthodes de paiement orientées machines telles que le débit immédiat (charge) et la facturation par session. Leurs conceptions diffèrent, mais ensemble elles valident une direction claire : les paiements automatisés peuvent intégrer le protocole applicatif, sans exiger un processus manuel externe de règlement.

2.2 La diversification durable des rails de paiement

Le secteur attend souvent qu’un jour ne subsiste qu’un seul protocole standard, un seul réseau de règlement et un seul schéma de paiement. Or, du point de vue du marchand, la diversification repose sur une logique pérenne. Les requêtes ponctuelles conviennent au paiement à l’appel, tandis que les services d’inférence continue ou de diffusion en continu privilégient la facturation par session ; les services haut de gamme exigent des garanties et des mécanismes de litige renforcés, alors que les appels de faible valeur privilégient vitesse et coût ; différentes régions et entreprises opteront aussi pour des réseaux de conformité et de règlement distincts.

La couche protocole continuera d’innover. Les marchands pourront adopter le prélèvement direct, l’autorisation préalable, l’escrow, les paiements en continu ou le règlement groupé ; les réseaux feront des arbitrages différents entre coût, caractère définitif, liquidité et outils écosystémiques. Pour les vendeurs, c’est une liberté de choix. Pour les acheteurs, chaque nouvelle combinaison ajoute une surface d’intégration supplémentaire.

La matrice de configuration ci-dessous illustre une coupe de cette diversification : les protocoles/schémas de paiement forment les colonnes, les blockchains les lignes, et chaque case correspond à une configuration de paiement nécessitant une intégration séparée — une matrice qui s’élargit encore.

Figure 1 : Matrice de configuration des rails de paiement dans un contexte de fragmentation

Ainsi, la fragmentation ne disparaîtra pas nécessairement naturellement avec la maturité du marché. Le marché des cartes bancaires n’a pas abouti à une seule organisation après des décennies de développement, et le cloud computing n’a pas convergé vers un unique fournisseur. Les marchés matures n’éliminent généralement pas les différences, mais construisent plutôt des couches d’agrégation, de routage et de compensation par-dessus celles-ci. Les paiements automatisés suivront très probablement cette même trajectoire évolutionnaire. Cette scission est déjà mesurable. Les données de deux explorateurs publics (x402scan et mppscan) sur les 30 derniers jours (au 3 septembre 2026) montrent : le protocole MPP compte 65 591 portefeuilles acheteurs actifs sur la chaîne Tempo, x402 en compte 19 472 sur Base, et seulement 365 portefeuilles figurent sur les deux rails — moins de 0,6 % des acheteurs MPP et 2 % des acheteurs Base x402 ; parmi eux, seuls 112 ont effectué plus de dix transactions sur chaque rail, et une part notable correspond à des agrégateurs biorails payant pour des utilisateurs avec la même clé, plutôt qu’à des acheteurs adoptant un second rail. Les acheteurs ne migrent pas d’un rail à l’autre : chaque rail constitue sa propre base d’acheteurs indépendante.

2.3 L’intégration des vendeurs ne représente que la moitié de la transaction

Les protocoles de paiement abaissent d’abord le seuil d’accès pour les marchands souhaitant accepter des paiements. Dès qu’un point de terminaison peut publier des devis, vérifier des identifiants et fournir des services, il remplit les conditions minimales du commerce orienté machines. Un nombre croissant d’outils pour développeurs, de services de données et d’interfaces de contenu devient ainsi achetable par des machines.

Toutefois, une offre payante ne signifie pas que la demande suivra automatiquement. Les marchands résolvent la question « Comment percevoir des paiements de machines ? », mais les agents doivent encore répondre à « De qui acheter ? Avec quelle méthode de paiement ? Comment confirmer la livraison après paiement ? ». Si chaque acheteur doit intégrer séparément chaque protocole, provisionner des fonds sur différents réseaux et tenir des registres indépendants, les paiements automatisés reproduiront la complexité des premières intégrations API — en remplaçant simplement les clés API par des portefeuilles et des adaptateurs de protocole.

L’adoption réelle dépend de la friction totale de la transaction, pas seulement de celle liée à l’étape de règlement.

3. Le véritable goulot d’étranglement du secteur : l’absence de boucle fermée dans les transactions

Figure 2 : Processus complet d’un achat automatisé

3.1 Premier obstacle : découvrir les services achetables

Les agents ont besoin d’annuaires de services lisibles par machine. Un annuaire efficace ne peut pas se limiter à des noms et des URL ; il doit aussi décrire les capacités du point de terminaison, ses entrées et sorties, ses unités de tarification, les protocoles disponibles, sa latence, ses restrictions géographiques et son statut de mise à jour. Une correspondance entre l’intention exprimée en langage naturel et les paramètres d’API est également nécessaire ; sinon, un agent sait qu’il « a besoin de données macroéconomiques », mais ne peut pas identifier quel point de terminaison remplit cette tâche.

Les annuaires des marchés ouverts font aussi face à la duplication, à l’obsolescence et aux affirmations trompeuses. Tout marchand peut prétendre fournir des données de haute qualité, mais les agents ne peuvent pas consacrer des jours entiers à des vérifications comme le ferait un service humain d’achat. La couche de découverte doit donc vérifier en continu si les points de terminaison sont appelables, si les devis sont réels et si les descriptions correspondent au contenu fourni.

Cela distingue la découverte de services de la recherche traditionnelle. Les moteurs de recherche optimisent la pertinence de l’information, tandis que les annuaires destinés aux achats automatisés doivent aussi optimiser la négociabilité : adéquation des capacités, acceptabilité des prix, compatibilité des paiements et capacité des marchands à livrer.

3.2 Deuxième obstacle : comprendre et comparer les devis

En apparence, des API similaires peuvent toutes être tarifées à l’appel, mais en réalité leurs devis sont peu comparables. L’une facture par requête, une autre par élément retourné ; l’une inclut l’inférence de modèle dans le prix, l’autre exige un paiement supplémentaire ; d’autres services facturent dynamiquement selon la longueur de l’entrée, le temps d’exécution ou le succès des résultats.

Un agent ne peut pas simplement choisir le point de terminaison au prix nominal le plus bas. Il doit évaluer le coût total, la probabilité de livraison, la latence et la qualité du résultat. Si une interface bon marché échoue fréquemment, les coûts de nouvelles tentatives et les retards de tâche peuvent rendre son prix effectif plus élevé. Les devis doivent donc être évalués conjointement avec le niveau de service, les performances historiques et le contexte de la tâche.

Les devis lisibles par machine doivent aussi préciser leur période de validité et leur montant définitif. Dans un environnement de tarification dynamique, ce que l’agent signe doit être un engagement ferme, non une fourchette de prix approximative. Les opérateurs doivent aussi connaître la composition des frais — frais de service, coûts réseau et frais de routage — afin d’établir des budgets crédibles.

3.3 Troisième obstacle : répartition des fonds et liquidité inter-réseaux

Si un agent doit acheter des services simultanément sur plusieurs chaînes et plusieurs protocoles, l’approche la plus directe consiste à préalimenter des soldes sur chaque réseau. Mais cela fragmente un montant modeste de capital en de nombreux petits morceaux. Les fonds restent inactifs sur les réseaux non utilisés, tandis que les réseaux populaires peuvent manquer de liquidités ; recharger les soldes implique des ponts, des conversions, des frais de gaz et des opérations de sécurité.

Pour un seul utilisateur, cela est déjà fastidieux. Pour une entreprise gérant un grand nombre d’agents, le problème s’aggrave : quel solde chaque agent doit-il détenir ? Qui est chargé de recharger ? Comment éviter les dépenses abusives ? Comment agréger actifs et frais sur différents réseaux ? Sans couche de financement unifiée, plus il y a de voies de paiement, plus la complexité financière augmente.

Idéalement, l’agent ne voit qu’un budget unique utilisable, pas plusieurs soldes réseau. Le système sous-jacent gère alors le choix des itinéraires de règlement, la gestion de la liquidité et la fourniture de devis transparents. Le principe est similaire à celui d’un voyageur utilisant une seule carte pour payer dans différents pays : l’utilisateur s’intéresse à la limite de crédit globale et au taux de change, sans avoir à ouvrir un compte local dans chaque destination.

3.4 Quatrième obstacle : autorisation fondée sur des politiques

La préoccupation la plus immédiate liée aux paiements autonomes est de savoir si un agent dépensera sans contrôle. La solution ne consiste pas simplement à choisir entre « interdiction totale » et « autorisation totale », mais à mettre en place des politiques multicouches.

Des plafonds par transaction limitent la perte due à une erreur isolée, des budgets par session encadrent la dépense totale d’une tâche, des listes blanches ou noires de marchands contrôlent les contreparties, des règles par catégorie restreignent les achats autorisés, et des limites de fréquence empêchent les appels anormaux sur une courte période. Les transactions à haut risque ou à forte valeur peuvent aussi nécessiter une validation manuelle. Les politiques doivent être définies par les opérateurs ; les agents ne peuvent agir qu’à l’intérieur de ces limites — ils ne peuvent pas augmenter eux-mêmes les seuils.

Un portefeuille ne doit pas seulement gérer les signatures. Il doit être intégré à des tâches, à des identités et à des registres d’audit afin de répondre à la question suivante : « Quel agent a approuvé ce paiement, pour quelle tâche et dans quel cadre réglementaire ? » Sinon, l’entreprise ne dispose que d’une suite de hachages de transactions en chaîne, incapables de satisfaire les exigences de contrôle interne et d’imputation des coûts.

3.5 Étape cinq : Une régulation réussie ne signifie pas une livraison de service

La blockchain excelle pour prouver qu’un montant a été transféré d’une adresse à une autre, mais ne peut pas intrinsèquement prouver qu’une API a renvoyé un contenu correct. Une transaction peut aboutir à une régulation complète, tandis que le serveur expire, renvoie un code d’erreur ou fournit des données ne correspondant pas à celles annoncées. Pour les agents, ce n’est pas un cas marginal : c’est au cœur du risque d’achat.

Le commerce électronique traditionnel relie paiement et livraison via la logistique, les avis et les remboursements ; les services automatisés n’ont pas de logistique physique — la livraison peut se résumer à une simple réponse HTTP éphémère. Si les systèmes de paiement ne consignent que le parcours des fonds, et les marchands uniquement leurs propres réponses, le marché manque d’une vision unifiée de l’exécution couvrant marchands et protocoles.

Ce qui exige prudence, c’est que consigner une réponse ne prouve pas sa qualité. Toutefois, corréler paiement et réponse permet tout au moins de distinguer des états fondamentaux tels que « payé et résultat reçu », « payé mais service en échec » et « non réglé ». C’est la première couche de faits pour établir la crédibilité des transactions automatisées.

3.6 Étape six : Rapprochement unifié et définition des responsabilités

Une seule tâche peut impliquer une dizaine d’achats microscopiques. Si chaque transaction est éparpillée entre différents portefeuilles, protocoles et backends marchands, il devient difficile pour les utilisateurs de comprendre pourquoi le livrable final coûte ce qu’il coûte. Les entreprises doivent aussi imputer les dépenses aux projets, équipes, clients et centres de coûts, tout en conservant des preuves vérifiables.

Un grand livre unifié doit consigner simultanément l’intention d’achat, les marchands, les devis, les politiques d’autorisation, les résultats de régulation, l’état des réponses et les motifs d’échec. Il sert non seulement la finance, mais aussi l’optimisation des agents. Le système peut analyser les sources de données fréquemment défaillantes, les itinéraires les plus coûteux et le mix d’achats typique pour un type donné de tâche.

Lorsque le paiement est intégré à la chaîne de raisonnement, le coût devient un signal de rétroaction pour les décisions du modèle. Sans rapprochement unifié, les agents ne peuvent optimiser que les réponses, pas le processus économique pour les obtenir. Une grande partie de la valeur à long terme du « Paiement pour agents » provient précisément de cette observabilité.

4. Du protocole de paiement à la couche d’achat automatisé

4.1 L’abstraction centrale de l’avenir n’est pas « payer », mais « acheter »

Le paiement est une action effectuée une fois l’objet et le prix définis, tandis que l’achat couvre l’ensemble du processus, de la demande à l’acceptation. Exposer une fonction pay() à un agent lui permet uniquement de transférer des fonds vers une adresse connue ; exposer une capacité buy() signifie que le système peut recevoir la demande, découvrir les services, comparer les options, exécuter le paiement et renvoyer des résultats vérifiables.

Cette distinction détermine la répartition des rôles dans le secteur. Les protocoles fournissent des messages de paiement standardisés, les portefeuilles gèrent les signatures et les actifs, les réseaux de régulation déplacent la valeur, les annuaires regroupent l’offre, et la couche d’achat organise ces composants autour d’une tâche unique. Chaque composant est important, mais aucun ne représente à lui seul une transaction complète.

La couche d’achat automatisé doit rester ouverte. Elle ne doit pas exiger que tous les marchands migrent vers le même protocole, ni déterminer qui peut être acheté via un annuaire fermé. Un modèle plus durable consiste à assurer la compatibilité avec plusieurs rails de paiement, à divulguer explicitement les coûts de routage dans les devis, et à permettre aux agents de choisir librement selon leur politique.

4.2 L’agrégation des acheteurs pourrait être plus importante que celle des vendeurs

Les plateformes internet agrègent généralement d’abord l’offre, puis attirent les consommateurs. Sur les marchés automatisés, l’offre existe déjà largement sous forme d’API ; ce qui manque, c’est un acheteur standardisé capable d’achats continus. Un agent équipé peut transformer une demande fragmentée et occasionnelle en un flux de transactions stable.

L’agrégation des acheteurs améliore aussi la visibilité des services de niche. Les développeurs humains privilégient souvent les grandes marques familières, car le coût temporel d’évaluer de nouveaux fournisseurs est élevé ; si les agents peuvent lire des signaux normalisés de capacité, de prix et d’exécution, ils peuvent sélectionner pour chaque tâche le service le plus adapté. Cela pourrait réduire les coûts d’acquisition client pour les nouveaux marchands et contraindre les marchands établis à rivaliser sur leurs performances réelles.

Toutefois, les points d’entrée des acheteurs peuvent aussi créer un nouveau pouvoir de plateforme. Celui qui contrôle l’annuaire par défaut, le classement et les chemins de paiement peut influencer l’allocation du trafic. Le secteur a donc besoin de règles de classement transparentes, de frais explicables et d’enregistrements de transactions transférables. L’agrégation peut réduire les frictions, mais ne doit pas transformer des protocoles ouverts en canaux fermés.

4.3 Construire une réputation fondée sur des données réelles de transaction

Les acheteurs automatisés prennent des décisions très rapidement et ne peuvent pas s’appuyer sur des vérifications approfondies. Ils ont besoin de signaux sur les contreparties dès l’affichage du devis. Les notes et avis classiques peuvent servir de référence, mais sont facilement manipulés par des volumes factices, des comptes sybil ou des parties liées. Si les avis ne nécessitent pas un paiement réel, le coût de l’attaque est particulièrement bas. Des recherches empiriques récentes sur ERC-8004 — la première couche de confiance permissionless sur chaîne pour agents — confirment ce point [6]. La spécification du protocole indique textuellement que « Les paiements sont orthogonaux à ce protocole » : les avis, par défaut, ne sont pas liés à une transaction payée réelle, et la preuve de paiement n’est qu’un champ facultatif. Résultat : sur Ethereum, BSC et Base (au 13 mai 2026), respectivement 73,5 %, 59,2 % et 90,6 % des rédacteurs d’avis ont présenté un comportement sybil coordonné.

Une base plus fiable repose sur des enregistrements de résultats liés à de véritables appels payants : nombre de règlements effectués par un point de terminaison de service, taux de réussite des réponses, latence moyenne courante et proportion élevée d’absence de réponse après paiement. Ces indicateurs ne reflètent pas encore pleinement la qualité du contenu, mais ils se rapprochent davantage de faits vérifiables que les déclarations unilatérales.

À mesure que les données s’accumulent, le marché pourrait développer une réputation hiérarchisée. Le premier niveau concerne le statut objectif des transactions, le deuxième les indicateurs de service reproductibles, et le troisième l’évaluation de qualité pour des tâches spécifiques. Les agents peuvent choisir la robustesse requise des preuves selon le montant et le risque : quelques centimes pour une requête de données peuvent reposer sur des signaux statistiques, tandis qu’un achat à forte valeur nécessite des garanties, des audits ou un mécanisme de règlement des litiges.

4.4 La stratégie budgétaire deviendra une capacité clé pour les agents

Aujourd’hui, les agents sont principalement évalués sur la qualité des réponses, le taux d’achèvement des tâches et la précision des appels d’outils. Une fois intégrés dans des environnements payants, des indicateurs économiques doivent être ajoutés : coût engagé pour atteindre une qualité donnée, respect ou non du budget alloué, moment opportun pour acheter des données plus coûteuses, et équilibre entre rapidité, coût et fiabilité.

Cela ouvrira de nouvelles pistes pour l’entraînement et l’évaluation. Les agents apprendront non seulement « quel outil permet de répondre à la question », mais aussi « si l’achat de cet outil est justifié au regard de la valeur de la tâche en cours ». Ils pourraient d’abord utiliser des services peu coûteux pour filtrer, puis acquérir une vérification haute qualité pour les conclusions clés ; ils pourraient aussi réduire la fréquence des appels à l’approche de l’épuisement du budget ou demander une autorisation supplémentaire à l’utilisateur.

En ce sens, le paiement par agent n’est pas un module financier externe aux capacités du modèle, mais fait partie intégrante de l’intelligence décisionnelle. Un agent véritablement mature doit non seulement mobiliser des ressources, mais aussi en évaluer le prix.

5. Évolutions possibles du paiement par agent

5.1 Phase 1 : les outils pour développeurs et les services numériques en tête

Les premiers scénarios à grande échelle seront très probablement purement numériques : recherche, données, scraping par proxy, inférence de modèles, exécution de code, stockage et génération de contenus. Ces services, fournis via API, ont un coût marginal faible, permettent paiement et réponse dans la même session réseau, et n’impliquent pas de logistique complexe.

Les montants typiques à ce stade sont très faibles ; les utilisateurs privilégient la facilité de développement et le taux d’achèvement des tâches. Le marché validera rapidement les protocoles, mais le volume de transactions restera fortement fragmenté. De nombreux appels continueront d’être gérés via des clés API classiques ou des abonnements, les paiements automatisés étant surtout utilisés pour des besoins ponctuels, des achats inter-marchands ou des services de niche non préconfigurables en comptes.

5.2 Phase 2 : budgets d’entreprise et collaboration multi-agents

Lorsque les entreprises déploieront plusieurs agents, la gestion des fonds évoluera des portefeuilles individuels vers des systèmes de comptes organisationnels. Elles devront allouer des budgets à différents rôles, contrôler les catégories d’achats autorisés, définir des seuils d’approbation et comptabiliser les dépenses dans leurs systèmes financiers. Des règlements internes pourraient aussi émerger entre agents : agents de recherche achetant des données, agents d’analyse souscrivant à de la puissance de calcul, agents d’exécution sollicitant des services externes.

À ce stade, la sécurité et la conformité priment sur la nouveauté des paiements. Les entreprises exigent la gestion sécurisée des clés, l’isolement des permissions, la surveillance des transactions, l’évaluation des fournisseurs et des traces auditables. Seules les infrastructures capables de s’intégrer aux processus financiers existants passeront de l’expérimentation à la production.

5.3 Phase 3 : extension des services numériques à l’économie réelle

Billets d’avion, hôtels, logistique, publicité et services professionnels pourraient tous devenir des cibles d’achat pour les agents, mais les transactions du monde réel exigent une gestion plus complexe de l’identité, des remboursements, de la fiscalité et des litiges. Les monnaies stables ne résolvent qu’une partie du problème de règlement ; elles ne remplacent pas les droits des consommateurs ni les contrats commerciaux.

L’industrie ne doit donc pas interpréter à tort le « paiement autonome » comme l’élimination de tous les intermédiaires. Au contraire, à mesure que la valeur des transactions augmente, garanties, assurances, crédit et arbitrage réapparaissent — simplement transformés en services appelables par machine. La pile future du paiement par agent pourrait intégrer simultanément des protocoles de paiement ouverts et des connecteurs financiers traditionnels, plutôt qu’un seul chemin remplaçant l’autre.

5.4 Phase 4 : du routage inter-protocole à l’exécution inter-marchés

À long terme, ce que les agents achètent n’est pas seulement une réponse API, mais un résultat concret. Un utilisateur pourrait demander « générer un rapport sectoriel crédible », et le système combinerait alors de façon autonome recherche, bases de données, traduction, modèles et services de vérification. Plusieurs transactions se produisent en couche profonde, tandis que l’utilisateur ne voit que le budget total, les sources de preuve et la livraison finale.

Cela élèvera le routage des paiements au rang d’exécution marchande. Le système devra décomposer des objectifs complexes en portefeuilles d’achats, remplacer dynamiquement les fournisseurs défaillants et optimiser coût global et qualité. La compatibilité protocole n’est que la base ; la vraie barrière à l’entrée vient de la compréhension des besoins, des données transactionnelles et des retours d’exécution.

6. Risques et questions ouvertes

Les paiements automatisés offrent un potentiel créatif considérable, mais les contraintes du monde réel ne peuvent être ignorées. La première est la sécurité : une injection de prompt pourrait inciter des agents à acheter des services malveillants, des attaques contre la chaîne d’approvisionnement pourraient remplacer les adresses de réception, et des politiques défaillantes pourraient entraîner des paiements en double massifs. Les actions de paiement doivent être isolées du contenu non fiable et dotées de limites, de simulation, de révocation et de détection d’anomalies.

La seconde est la confidentialité. Les registres d’achats révèlent les tâches exécutées par un agent, et les données publiques sur chaîne pourraient relier l’identité d’un utilisateur à ses intentions commerciales. Les systèmes doivent minimiser les fuites de métadonnées sensibles et trouver un équilibre entre exigences d’audit et protection de la vie privée.

La troisième est la responsabilité. En cas d’achat erroné par un agent, de défaillance de livraison d’un marchand ou d’échec de conversion de protocole, qui supporte la perte ? Les transactions de faible valeur peuvent accepter un risque automatisé, mais celles de haute valeur exigent des frontières claires de responsabilité. Un réseau de paiement sans mécanisme de litige peinera à s’imposer directement dans le commerce haut de gamme.

La quatrième est la réglementation. L’émission de stablecoins, les contrôles des portefeuilles, les transferts transfrontaliers et les paiements aux marchands sont soumis à des règles variées selon les juridictions. Les machines sont des exécutants, non des sujets de responsabilité juridique. L’infrastructure doit permettre de retracer chaque transaction autonome jusqu’à un opérateur clair, une politique d’autorisation et une source de fonds identifiées.

La cinquième est la viabilité commerciale. Les revenus issus des micropaiements sont facilement érodés par les coûts réseau, la liquidité et les frais de gestion des risques. Si les plateformes subventionnent l’expérience via des majorations cachées, elles sapent la confiance des acheteurs. Les frais doivent être transparents, et un modèle économique solide doit reposer sur l’échelle, l’efficacité du routage et des services à valeur ajoutée.

Ces enjeux ne remettent pas en cause le secteur ; ils montrent plutôt que les paiements automatisés ne se réaliseront pas via un seul protocole. Ils deviendront finalement une infrastructure composite couvrant les paiements, l’identité, les autorisations, la découverte, la réputation et le rapprochement.

7. SELAT : Équiper le côté achat pour le commerce natif-machine

« SELAT » provient du mot malais désignant un « détroit », comme le détroit de Malacca (Selat Melaka). Depuis des siècles, quelle que soit l’origine des marchandises ou leur destination, le courant principal du commerce Est-Ouest empruntait ce passage maritime. SELAT vise à devenir ce détroit dans le commerce natif-machine : quel que soit le réseau utilisé par un marchand, la demande des agents peut y circuler.

SELAT est une entreprise native IA qui choisit d’entrer dans les paiements automatisés par le côté achat. SELAT constitue la couche côté achat pour le commerce natif-machine. Son objectif n’est pas de créer un nouveau réseau de paiement exigeant la migration des marchands, mais d’habiliter les agents à effectuer des achats via les réseaux existants. Elle cible deux problèmes centraux : premièrement, la fragmentation des configurations de paiement — rails, protocoles, chaînes et identifiants diffèrent tous, nécessitant une nouvelle intégration pour chaque marchand ; deuxièmement, l’absence de mesure du risque contrepartie, car un règlement réussi ne garantit pas la livraison effective du service.

Figure 3 : Schéma de la couche côté achat SELAT

Pour résoudre la fragmentation, l’interface en ligne de commande (CLI) SELAT maintient les différences de protocoles, de schémas de paiement et de réseaux de règlement au niveau de l’infrastructure, permettant aux agents d’effectuer des achats inter-rails via une seule commande. Découverte, obtention de devis, autorisation, paiement, enregistrement de l’état de livraison et rapprochement sont intégrés dans un même processus d’achat, et chaque appel est également enregistré dans le même registre.

• Une trésorerie unique, utilisant N réseaux de paiement

Les agents détiennent un solde USDC en auto-custodie, sans besoin de pré-financement par chaîne ni de clients distincts selon les protocoles.

• Catalogue agrégé de points de terminaison

La CLI SELAT intègre quatre registres tiers de services — Circle, MPP, Apify et pay.sh — ainsi que son propre catalogue, permettant aux agents de découvrir et comparer plus de 4 000 points de terminaison selon leurs intentions en temps réel.

• Plafonds de dépense stricts

Les opérateurs peuvent définir des limites par transaction et des budgets de session, et suspendre à tout moment les autorisations de dépense ; les agents ne peuvent pas augmenter ces limites eux-mêmes.

• Aucune migration requise pour les marchands

Les marchands conservent leurs réseaux de paiement préférés et peuvent être découverts et achetés par les agents sans avoir à s’enregistrer à nouveau auprès de SELAT.

Du côté du financement, SELAT fonctionne avec tout portefeuille d’agent, y compris les portefeuilles Circle et MetaMask. SELAT achemine chaque achat via des réseaux de paiement tels que x402 et MPP, selon les devis en temps réel.

7.1 ERC-8004 : Primitives correctes, signaux discutables

ERC-8004 définit trois types de registres — identité, réputation et validation — et permet aux acheteurs de soumettre des avis aux vendeurs. La direction est bonne, mais elle sépare explicitement paiement et réputation : les retours ne doivent pas provenir de transactions réelles, et la preuve de paiement est facultative.

Des recherches empiriques sur l’écosystème déployé montrent que, sur Base, 93,8 % des rédacteurs d’avis n’avaient jamais effectué de paiement x402, pourtant ils ont fourni 94,9 % des retours ; une grande partie de ces retours présente aussi un comportement sybil coordonné [6]. Les registres consignent des affirmations, mais ce dont les acheteurs ont vraiment besoin, ce sont les résultats.

7.2 Une réputation liée aux données réelles de transaction est ce dont les acheteurs ont besoin

Les infrastructures de paiement peuvent confirmer si un transfert a abouti, mais ne voient pas le service fourni ; les marchands voient leurs propres réponses, mais pas le marché dans son ensemble ; les registres listent des points de terminaison, mais ne prouvent pas que les avis proviennent d’achats réels.

La couche acheteur exécutant les achats est la mieux placée pour relier les deux extrémités d’une transaction : chaque achat réalisé via SELAT enregistre quel point de terminaison a été payé, quel montant a été réglé et les métadonnées relatives à l’état de livraison post-paiement (2xx, 4xx, 5xx). Ces enregistrements s’accumulent continuellement par marchand et par infrastructure de paiement, constituant la base de données du « graphe Règlement–Livraison ».

Une distinction précise est nécessaire : les enregistrements liant paiement et état de livraison ne constituent pas une preuve indépendante de la qualité de livraison ou de l’exactitude des devis. Toutefois, ils fournissent la base que la réputation fondée sur les registres ne possède pas — des données de résultat liées à des invocations réellement payées.

7.3 Évaluer la crédibilité des contreparties avant les transactions

Alors que certains débattaient sur X de la conception d’un mécanisme de confiance inspiré de Google PageRank pour le quatrième Internet, SELAT avait déjà lancé l’« Indice de transactabilité » au-dessus de son graphe Règlement–Livraison, afin d’offrir aux agents un accès en temps réel à des données de crédibilité des contreparties fondées sur des résultats réels de transactions.

Cet indice est renvoyé avec les devis, sans obliger les agents à interrompre leurs tâches pour enquêter séparément sur les marchands. Il signale les risques sans verrouiller le marché : les points de terminaison restent découvrables et achetables, et les agents décident en fonction de leur budget, de l’importance de la tâche et de leur tolérance au risque.

Les agents n’ont pas le temps de lire des récits de marque. Avant de payer, ils doivent savoir : comment ce point de terminaison se comporte-t-il dans des transactions réelles ? Dans le commerce machine-native, la crédibilité ne doit pas reposer sur des affirmations, mais sur des résultats.

Figure 3 : Signaux de transactabilité au stade du devis

Actuellement, l’interface en ligne de commande (CLI) SELAT a été adaptée aux environnements d’exécution d’agents incluant Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes et Grok Bot.

8. Synthèse : L’économie machine nécessite plus que de simples rails de paiement accélérés

Le paiement par agent en est à un stade où il est facilement surestimé ou sous-estimé. Il est facilement surestimé car réaliser techniquement un paiement en stablecoin ne signifie pas qu’un agent possède une autonomie commerciale mature ; il est facilement sous-estimé car, dès lors que les logiciels peuvent acheter des capacités externes dans des contraintes claires, les méthodes organisationnelles, les modèles de tarification et les frontières concurrentielles de l’économie machine changeront toutes.

Les protocoles de paiement ont déjà démontré que les machines peuvent recevoir des devis et finaliser des règlements. La prochaine étape clé consiste à élargir un paiement isolé en un processus d’approvisionnement complet : permettre aux agents de trouver des services adaptés, d’en comprendre les coûts réels, de payer via divers rails dans leur budget, de confirmer la livraison et de transformer chaque transaction en un enregistrement vérifiable et exploitable.

L’économie machine future n’aura pas une seule chaîne, un seul protocole ni un seul portefeuille. L’approvisionnement multiforme perdurera à long terme, et les infrastructures véritablement utiles aideront les acheteurs à naviguer dans cette complexité. Le paiement par agent doit intégrer rails, approvisionnement, paiements par défaut et mécanismes de confiance pour transformer une capacité technique en demande réelle.

Lorsque les logiciels commencent à agir en tant qu’acheteurs, le paiement n’est que la première étape qu’ils franchissent. La question la plus importante demeure toujours : peuvent-ils mener à bien une transaction réellement utile, de façon contrôlable, transparente et vérifiable ?

Références

[1] Circle, « Construire l’économie agente ouverte », 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, « Le risque de contrepartie dans les paiements agents : la moitié non mesurée », 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, « Accélérer le commerce IA avec le nouveau protocole de paiements agents (AP2) », 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] Fondation x402, « x402 : une norme ouverte de paiement native pour Internet ». https://github.com/x402-foundation/x402

[5] Protocole de paiements machines (MPP), « MPP : un protocole de paiement machine basé sur HTTP 402 ». https://mpp.dev/

[6] Xiong et al., « Peut-on faire confiance à des agents sans confiance ? Une étude empirique de l’écosystème décentralisé d’agents IA ERC-8004 », arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] Site officiel de SELAT : https://www.selat.ai

Cet article est une contribution externe et ne reflète pas les vues de BlockBeats.