Payer par agent IA : ce que les protocoles garantissent

OUTILS IA — L'AGENT QUI AGIT · PAYER PAR AGENT

Sources relevées au 25 juillet 2026, sur les spécifications publiques des protocoles cités, leurs dépôts officiels et la documentation d'éditeur. Aucun paiement n'a été exécuté pour cet article.

Un paiement en ligne repose depuis trente ans sur une hypothèse discrète : au bout de la chaîne, quelqu'un regarde l'écran. Le titulaire de la carte voit le montant, voit le marchand, et clique. Toute la sécurité s'est construite autour de ce geste — le code reçu par message, le mot de passe bancaire, la case à cocher. Retirez la personne devant l'écran, et l'édifice ne s'écroule pas : il devient muet. Il ne sait plus à qui il parle.

C'est le trou que quatre protocoles concurrents tentent de combler depuis dix-huit mois. Ils ne cherchent pas à rendre le paiement plus rapide. Ils cherchent à répondre à une question que le rail bancaire n'a jamais eu à poser : ce logiciel qui présente une carte agit-il pour le compte de quelqu'un, et jusqu'où ?

Cet article compare ce que ces protocoles écrivent noir sur blanc, et ce qu'ils laissent délibérément hors de leur périmètre. Il prolonge notre article sur la gouvernance d'un agent autonome : payer est le premier acte irréversible qu'un agent puisse commettre.

Quatre protocoles, quatre points d'entrée dans la même chaîne

La confusion vient de ce que ces spécifications sont souvent présentées comme rivales alors qu'elles n'interviennent pas au même endroit. Deux décrivent l'autorisation, une décrit la reconnaissance de l'agent à la porte du marchand, une décrit un paiement de machine à machine sans être humain dans la boucle.

Une remarque de méthode avant d'entrer dans le détail. Les quatre textes sont jeunes : le plus ancien date de septembre 2025, l'un porte un numéro de version inférieur à 1, un autre s'appuie sur des brouillons de normalisation non finalisés. À ce stade d'un chantier, ce qui compte n'est pas de désigner un vainqueur — l'histoire des rails de paiement montre qu'il en subsiste rarement un seul — mais de repérer ce que chacun prend en charge, afin de ne pas payer deux fois pour la même fonction ni découvrir tardivement un trou dans sa chaîne.

Le protocole AP2, conduit par Google, se présente comme « un protocole ouvert pour l'économie des agents qui émerge », conçu comme une extension du protocole d'agent à agent. Il a été annoncé le 16 septembre 2025, et sa spécification a depuis été versée à la FIDO Alliance pour être normalisée en groupes de travail dédiés. Sa version 0.2 est publique, sous licence Apache 2.0. Son mécanisme central tient en deux objets : un Checkout Mandate, qui « capture la référence aux articles précis et aux détails de l'achat », et un Payment Mandate, qui « autorise un paiement contre un instrument de paiement déterminé ». Chacun existe en deux états, ouvert puis clos, c'est-à-dire avant et après autorisation.

Le protocole de commerce agentique — ACP —, développé conjointement par Stripe et OpenAI et publié sous licence Apache 2.0, aborde la même chaîne par l'autre bout : la mise en place du paiement chez le marchand. Sa documentation insiste sur un point qui vaut d'être lu tel quel : les entreprises « conservent leurs relations clients en tant que marchand de référence, gardant le contrôle des produits qui peuvent être vendus, de la façon dont ils sont présentés, et de la façon dont les commandes sont honorées ». Autrement dit, le protocole normalise le dialogue, pas la propriété de la vente.

Le Trusted Agent Protocol de Visa, développé en collaboration avec Cloudflare, traite un troisième problème : comment un marchand distingue un agent légitime d'un robot ordinaire. Sa spécification repose sur des signatures cryptographiques propres à l'agent et transporte trois familles d'informations — une intention d'agent signalant que l'agent souhaite consulter ou acheter un produit précis, une reconnaissance du consommateur indiquant si celui-ci possède déjà un compte chez le marchand, et, en option, les données de paiement. Les programmes pilotes sont annoncés pour l'Europe et l'Asie-Pacifique au début de 2026.

Enfin x402 sort du cadre de la carte bancaire. Le protocole se décrit comme « une norme ouverte et neutre pour les paiements natifs d'internet » et réactive un code de statut resté inutilisé pendant vingt-cinq ans : le 402 Payment Required. Le serveur répond 402 à une requête non payée, le client construit une charge de paiement en jeton adossé à une monnaie et rejoue la requête. Le règlement est effectué en chaîne, la spécification se revendiquant agnostique et compatible avec les chaînes de type EVM ainsi qu'avec Solana. Le projet est opéré sous l'égide des projets de la Linux Foundation. Le site public affiche, pour les trente derniers jours, 75,41 millions de transactions et 24,24 millions de dollars de volume, pour 94 060 acheteurs et 22 000 vendeurs actifs.

Fig. 1 — Les quatre protocoles ne se disputent pas la même case. AP2 et ACP décrivent l'autorisation et la mise en paiement, le Trusted Agent Protocol décrit la reconnaissance de l'agent à l'entrée du marchand, x402 court-circuite entièrement le rail carte pour un paiement de machine à machine. Un marchand peut en implémenter plusieurs ; il n'en implémente jamais un « à la place » d'un autre.

Ce qu'un mandat garantit réellement

La formulation d'AP2 mérite qu'on s'y arrête, parce qu'elle est plus modeste que la promesse commerciale qui l'accompagne souvent. La documentation décrit des identifiants numériques vérifiables — des objets « inviolables, signés cryptographiquement » — qui produisent une « trace d'audit cryptographique non répudiable ».

Non répudiable signifie : personne ne pourra soutenir plus tard que l'autorisation n'a pas été donnée. C'est considérable, et c'est tout. Une signature établit qu'une intention a été exprimée par un porteur de clé à un instant donné. Elle n'établit pas que cette intention était la bonne, ni que l'agent l'a correctement traduite en achat, ni que le produit livré correspond au produit voulu.

La distinction est celle que nous avons déjà rencontrée à propos de la confiance que l'on peut placer dans un agent : la cryptographie déplace la charge de la preuve, elle ne fabrique pas de discernement. Un mandat signé sur un panier erroné est un mandat parfaitement valide sur un panier erroné.

Le découpage en deux états — ouvert puis clos — mérite lui aussi d'être compris pour ce qu'il est. Il matérialise le moment où l'engagement devient ferme, et il ne le fait pas au hasard : c'est là que se joue la différence entre un utilisateur présent au moment de l'achat et un utilisateur qui a délégué par avance. Le dépôt public d'AP2 nomme d'ailleurs explicitement un scénario de paiement par carte « avec humain présent » parmi les flux qu'il fournit en exemple. Le cas symétrique — l'agent qui achète pendant que personne ne regarde — est celui qui intéresse tout le monde, et c'est celui où la qualité du mandat écrit à l'avance devient l'unique protection.

Deuxième conséquence, moins commentée : la trace non répudiable protège aussi le marchand. Un vendeur qui conserve un mandat signé dispose d'un élément qu'il n'avait jamais eu auparavant face à une contestation. Le rapport de forces habituel du commerce à distance, où la charge de la preuve pèse par défaut sur le vendeur, s'en trouve modifié. Ce déplacement est probablement la raison la plus solide pour laquelle ces protocoles seront adoptés — bien avant le confort de l'acheteur.

Reconnaître l'agent avant de discuter d'argent

Avant qu'un mandat soit présenté, le marchand doit savoir qui frappe à la porte. C'est un problème antérieur au paiement, et il est en train d'être résolu séparément, par des moyens qui n'ont rien de bancaire.

La méthode d'authentification des robots par signature documentée par Cloudflare — dont la page a été mise à jour le 1^er juillet 2026 — décrit un mécanisme volontairement simple. L'agent génère une paire de clés Ed25519. Il publie ses clés publiques sur son propre domaine, à un emplacement conventionnel accessible uniquement en HTTPS, au format de jeu de clés JSON. Il signe ensuite ses requêtes et joint trois en-têtes : Signature, Signature-Input et Signature-Agent. Le destinataire vérifie.

Le point notable est ce que cette méthode remplace : la détection par adresse IP et par résolution de nom inversée, qui a servi vingt ans à distinguer les robots légitimes des autres. Le mécanisme s'appuie sur la RFC 9421 pour les signatures de messages HTTP, mais repose lui-même sur deux propositions de l'IETF encore à l'état de brouillon, dans leurs versions 03 et 02 respectivement. Ce n'est donc pas une norme établie ; c'est une convention en cours d'adoption, déjà déployée en production par au moins un acteur d'infrastructure majeur.

Ce chantier est le pendant exact de celui décrit dans notre article sur le contrôle de ce que les robots d'IA prennent sur votre site. Hier, la question était : que laissez-vous lire ? Aujourd'hui elle devient : que laissez-vous acheter, et par qui ?

La voie qui contourne entièrement la carte

x402 mérite une lecture à part, parce qu'il ne cherche pas à adapter l'existant. Il part du constat qu'un agent qui doit payer trois centimes pour consulter une ressource ne peut pas passer par un rail conçu pour des paniers de plusieurs dizaines d'euros, avec ses frais fixes, ses délais de compensation et son obligation d'un titulaire identifié.

Le mécanisme est d'une sobriété désarmante : le serveur refuse et annonce son tarif, le client paie et rejoue, le serveur vérifie — directement ou par un intermédiaire de facilitation — puis délivre la ressource. Aucun compte à ouvrir, aucun abonnement, aucune relation commerciale préalable.

Les volumes affichés indiquent un usage réel et non un prototype. Ils indiquent aussi la nature de cet usage : rapportés au nombre de transactions, ils situent le paiement moyen bien en dessous du seuil où une carte bancaire aurait un sens économique. C'est un marché de micro-règlements entre machines, pas un canal de vente au détail — et il faut le lire comme tel avant d'en tirer une tendance sur le commerce grand public. La contrepartie est explicite : le règlement s'opère en chaîne, avec les conséquences que cela emporte en matière de volatilité, de conservation des avoirs et de traitement comptable, sujets qui débordent largement le cadre de cet article.

Ce qu'aucun de ces protocoles ne règle

Le silence des spécifications est aussi instructif que leur contenu. Quatre questions traversent la chaîne sans qu'aucun texte examiné ici ne prétende y répondre.

Qui supporte l'achat erroné. Aucune des spécifications lues n'attribue la charge d'un achat conforme au mandat mais contraire à l'intention réelle. La question relève du contrat entre l'utilisateur, l'éditeur de l'agent et l'émetteur du moyen de paiement — c'est-à-dire de documents que personne ne lit, et qui ne sont pas harmonisés.

Le droit de rétractation et le remboursement. Les mécanismes de contestation existants supposent un porteur qui déclare ne pas reconnaître une opération. Une opération portant un mandat signé par ce même porteur entre mal dans cette catégorie. Le régime applicable n'est établi par aucune des sources relevées.

L'interopérabilité. Un marchand qui implémente le protocole d'un acteur n'est pas joignable par un agent qui parle celui d'un autre. En l'état, la promesse d'universalité coexiste avec quatre piles incompatibles — configuration classique d'un marché avant consolidation, et raison suffisante pour ne pas s'enfermer, comme nous l'écrivions à propos du risque de dépendance à un fournisseur unique.

Le budget. Un agent qui peut payer peut payer souvent. Les protocoles décrivent l'autorisation d'une opération, pas la maîtrise d'un flux. C'est une dimension distincte de celle traitée dans notre article sur le coût réel d'un agent IA : il ne s'agit plus de la facture d'inférence, mais de dépenses engagées auprès de tiers.

🔬 Comment le vérifier vous-même

Aucun de ces protocoles n'a été implémenté ni éprouvé pour cet article, et aucun montant n'a été engagé. En revanche, tout ce qui précède se contrôle sur pièces, sans compte marchand et sans budget.

Il reste une décision, et elle ne se prend pas dans une équipe technique. Autoriser un agent à engager de l'argent, c'est transformer une erreur logicielle en perte financière directe, sans le délai de réflexion qu'introduisait le clic humain. Les protocoles rendent cette perte traçable et opposable ; aucun ne la rend improbable. Le premier travail utile n'est donc pas de choisir une pile, mais d'écrire ce que l'agent n'a pas le droit de faire — et de vérifier que le mandat sait le transporter.

Cet article ouvre la série Outils IA — l'agent qui agit. Le suivant regarde la même scène depuis l'autre côté du comptoir : ce qu'un site doit mettre en place pour reconnaître un agent, et décider de ce qu'il lui ouvre. Pour le socle conceptuel, notre article sur les agents, du chat statique à l'IA qui exécute reste le point de départ.

Une question, un projet IA ?

Vous envisagez de laisser un agent engager des dépenses, ou d'ouvrir votre boutique aux agents de vos clients ? Échangeons sur votre contexte.

Prendre contact →