Les agents d'IA commencent à rechercher, comparer, recommander, négocier et, dans certains cas, effectuer des transactions pour le compte de personnes ou d'entreprises. Cela crée une nouvelle opportunité pour le web.
Le web est très efficace pour gérer le commerce piloté par des humains. Une personne parcourt une boutique en ligne, se connecte, ajoute un article à son panier, saisit ses informations de paiement et valide sa commande. Ce flux met en jeu un navigateur, une session utilisateur, une page de paiement et un humain prenant la décision finale.
Le commerce agentique change cela : l'acheteur peut être un agent d'IA, le vendeur peut être une API, une marketplace, un site marchand ou un autre service automatisé. La transaction, elle, peut être un passage en caisse classique, un achat délégué, un abonnement ou un micro-paiement machine à machine pour une seule requête.
Ce processus exerce une nouvelle pression sur la couche protocolaire.
Le commerce agentique a besoin de moyens communs pour exprimer l'intention, l'identité, l'autorisation, les exigences de paiement, la preuve de paiement et la réponse du commerçant. Sans cela, chaque agent, commerçant, fournisseur de paiement et plateforme finit par créer une intégration ponctuelle. Même si cela peut fonctionner pour des démos, à l'échelle, dans un véritable écosystème commercial, cela s'avère plus complexe.
C'est ce qui marque le début d'une série technique sur le commerce agentique et la manière dont la périphérie s'y intègre. Dans cet article, nous examinerons le paysage actuel du commerce agentique et découvrirons pourquoi la périphérie devient un point d'application important pour les transactions gérées par des agents.
Paiements M2M et commerce agentique
Les paiements de machine à machine consistent en un système qui paie un autre système. Une imprimante qui commande elle-même son encre en est un bon exemple. Le flux peut être restreint : le stock d'encre est bas, un paiement est requis, l'imprimante fournit une preuve de paiement et l'API de commande renvoie une confirmation.
Le commerce agentique, lui, est plus vaste. Un chatbot qui vous aide à acheter une nouvelle garde-robe doit comprendre vos intentions, vos préférences, votre budget, votre taille, votre style, les options des commerçants, les modifications du panier, le passage en caisse, les retours et l'assistance. Le paiement n'est qu'une étape du parcours.
Ces deux principes comportent des similitudes, mais ils ne sont pas identiques. Les paiements M2M peuvent alimenter le commerce agentique, en particulier lorsque les agents paient directement des API, des outils ou des services. A contrario, le commerce agentique inclut les cas où un agent d'IA aide une personne à acheter via une expérience marchande classique, comme un site web, une marketplace ou un parcours d'achat.
Cette distinction est importante en périphérie.
Un flux de paiement M2M peut ressembler à un contrôle d'accès :
Cette requête nécessite-t-elle un paiement ?
Une preuve de paiement a-t-elle été fournie ?
A-t-elle été vérifiée ?
La requête doit-elle atteindre le serveur d'origine ?
Un flux de commerce agentique présente une surface plus étendue :
S'agit-il d'un agent de confiance ?
La requête est-elle conforme au mandat de l'utilisateur ?
L'agent devrait-il voir ces données produit ?
La requête est-elle suspecte ?
Que faut-il consigner dans des journées à des fins de conformité, de débogage ou de résolution de litiges ?
Les deux modèles tirent avantage d'un traitement au plus près de la requête. C'est là que les politiques de paiement, l'identité, le routage, les signaux de fraude et la protection du serveur d'origine commencent à se rejoindre.
Ce qui change pour le e-commerce
Il existe un parallèle pratique avec l'édition. La recherche, les réseaux sociaux et les résumés d'IA modifient la façon dont les lecteurs trouvent du contenu. Les éditeurs créent toujours le contenu, mais une plus grande partie de la relation avec le public s'est déplacée vers les plateformes qui l'agrègent et le classent.
Le commerce agentique pourrait agir de la même manière pour le e-commerce. En effet, si un acheteur demande à un agent « Achète-moi les meilleures chaussures de course à moins de 150 $ », l'agent peut comparer les options chez différents vendeurs, choisir un modèle et finaliser l'achat sans que l'acheteur n'ait jamais à consulter le site du marchand.
C'est pratique pour l'acheteur, mais cela soulève de vraies questions pour les marchands : qu'advient-il de la boutique en ligne, de la page produit, de l'offre de fidélité, du pack, de la vente incitative et de l'expérience de marque ? Si l'agent contrôle la découverte et la comparaison, les marchands auront peut-être moins d'occasions de fidéliser les clients ou d'influencer la décision finale.
Nous avons déjà vu des éléments de ce schéma avec Google Shopping, Amazon et les marketplaces. Le commerce agentique pourrait aller encore plus loin en déplaçant une plus grande partie du parcours d'achat dans la couche automatisée.
Cela signifie que les équipes e-commerce auront besoin de plus que d'un simple support de paiement : elles auront besoin de moyens pour contrôler l'accès des agents, protéger les API de produits et de paiement, vérifier les agents de confiance, comprendre le trafic automatisé et appliquer des politiques avant que ces requêtes n'atteignent le serveur d'origine.
Gestion du trafic agentique en périphérie
La périphérie peut devenir le point de contrôle programmable où la politique de commerce agentique rencontre le trafic réel. La plateforme Edge Cloud de Fastly se trouve déjà sur le chemin de la requête et peut inspecter le trafic, appliquer des politiques, vérifier les signaux, router les requêtes, protéger les serveurs d'origine et rendre les flux commerciaux observables.
La périphérie est un point d'application naturel pour le commerce agentique, car elle se situe déjà entre les clients et les applications. Une requête arrive : Fastly peut l'inspecter, appliquer des politiques, évaluer les signaux d'identité et d'autorisation, vérifier les métadonnées liées au paiement et décider de traiter, bloquer, soumettre à un défi ou acheminer la requête. Pour les API et le trafic machine, cela peut signifier exiger le paiement avant d'atteindre un serveur d'origine. Pour les flux commerciaux, il s'agit plutôt d'aider les commerçants à contrôler quels agents peuvent accéder à quelles routes, quels produits ou quelles actions de paiement.
Il ne s'agit pas de remplacer les fournisseurs de paiement. Les paiements s'effectueront toujours via Stripe, Visa, Mastercard, Coinbase, des portefeuilles, des facilitateurs, des banques ou le réseau choisi par l'application.
Le rôle de Fastly, c'est la couche programmable en périphérie qui entoure la transaction.
Cette couche est importante car le commerce agentique créera de nouveaux modèles de trafic :
Découverte de produits plus automatisée
Plus de flux de paiement de type API
Plus d'actions déléguées
Plus de requêtes qui ressemblent à des bots mais peuvent représenter de vrais acheteurs
Besoin accru de politiques claires, de vérification, de routage et d'observabilité avant que le trafic n'atteigne le serveur d'origine
L'écosystème du commerce agentique prend encore forme. De nouveaux protocoles, frameworks et moyens de paiement émergent rapidement. Les initiatives actuelles évoluent à vitesse grand V, et il est trop tôt pour savoir quels standards connaîtront une adoption durable.
Cette incertitude n'est pas nouvelle pour Fastly. Nous avons aidé les clients à s'adapter aux évolutions majeures de nombreux protocoles, de l'IPv6 et du TLS 1.3 à HTTP/2 et HTTP/3. Plus récemment, nous avons aidé les clients à répondre au trafic des bots d'IA en périphérie, notamment à comprendre quels bots d'IA explorent, à décider lesquels autoriser ou bloquer et à appliquer une politique avant que l'automatisation indésirable n'atteigne l'application.
Le commerce agentique suit un schéma similaire. Certains agents d'IA représenteront de vrais clients et une intention d'achat légitime, quand d'autres peuvent extraire des données produit, abuser des flux de paiement ou générer de nouvelles fraudes et une charge supplémentaire sur le serveur d'origine.
Fastly vous donne l'assurance que votre infrastructure en périphérie est conçue pour s'adapter à l'écosystème, afin que vos équipes puissent rester concentrées sur la création d'excellentes expériences client.
Protocoles d'agents adjacents
Avant d'aborder les protocoles spécifiques au commerce et aux paiements, il convient de les séparer de l'infrastructure d'agents plus large comme MCP et A2A. MCP aide les applications d'IA à se connecter aux outils, aux données et aux flux de travail. A2A se concentre sur la communication et la coordination d'agent à agent. Tous deux peuvent apparaître dans les flux de commerce agentique, mais ils ne résolvent pas le problème du commerce à eux seuls : ils aident les agents à agir et à collaborer. Les protocoles ci-dessous sont davantage axés sur les achats, l'autorisation, le paiement et la confiance.
Protocoles commerciaux
En ce moment, le secteur se rassemble autour de deux frameworks commerciaux majeurs pour aider les agents d'IA à naviguer dans l'expérience d'achat actuelle :
UCP, ou Universal Commerce Protocol
Cette initiative est soutenue par Google et Shopify. Elle simplifie la façon dont les agents d'IA interagissent avec les systèmes commerciaux, notamment les catalogues des marchands, la disponibilité des produits, la tarification, les paniers, le paiement, le traitement des commandes, le contexte client et l'état des commandes. L'idée principale est que les marchands ne devraient pas avoir besoin d'une intégration personnalisée pour chaque surface d'IA. Si les données et les actions commerciales peuvent être exprimées dans un format partagé, les agents peuvent découvrir des produits, créer des paniers et progresser vers le paiement de manière plus cohérente.
En savoir plus sur le protocole UCP sur cette page
ACP, ou Agentic Commerce Protocol
Il s'agit d'une norme ouverte soutenue par OpenAI et Stripe. ACP se concentre sur les flux commerciaux programmatiques entre acheteurs, agents et entreprises. Il s'agit du protocole qui sous-tend les travaux d'Instant Checkout d'OpenAI avec Stripe, et il donne aux commerçants un moyen d'exposer des produits et des flux de paiement à des expériences pilotées par des agents. ACP concerne moins le règlement brut des paiements que le fait de rendre l'interaction commerciale elle-même adaptée aux agents.
En savoir plus sur le protocole ACP sur cette page
Bien que les protocoles UCP et ACP permettent tous deux aux agents d'IA de faire des achats de manière autonome pour les utilisateurs, leurs approches diffèrent. Le protocole UCP est une norme ouverte et décentralisée conçue pour une découverte plus importante et un catalogage de produits sur le web ouvert. À l'inverse, le protocole ACP est un canal de paiement centralisé et hautement optimisé pour des paiements rapides et tokenisés au sein de plateformes d'IA spécifiques. Ces deux protocoles sont complémentaires : les commerçants peuvent tirer parti de l'UCP pour bénéficier d'une visibilité sur le web ouvert tout en utilisant l'ACP pour exécuter un paiement final sécurisé et sans friction.
Protocoles d'autorisation et de paiement
Trouver un produit et l'ajouter dans son panier n'est pas un défi d'infrastructure très difficile à résoudre. La complexité commence lorsqu'un agent d'IA doit autoriser une transaction et transférer de l'argent réel.
Contrairement à un être humain, un bot ne peut pas saisir un numéro de carte bancaire ni résoudre un CAPTCHA.
Faire fonctionner ces transactions autonomes nécessite une infrastructure back-end capable de gérer deux étapes distinctes :
L'autorisation (prouver qu'un agent dispose du mandat explicite de l'utilisateur pour dépenser de l'argent)
Le paiement (router par programmation des fonds, des réseaux de crédit traditionnels aux pings API bruts de machine à machine)
Quelques protocoles concurrents émergent pour répondre à ces défis d'autorisation et de paiement :
AP2 (ou Agent Payments Protocol) a été introduit par Google comme un protocole ouvert pour les paiements sécurisés par agent. L'idée importante du protocole AP2, c'est l'autorisation. Lorsqu'un agent dépense pour le compte d'un utilisateur, les commerçants et les fournisseurs de paiement ont besoin de la preuve que l'utilisateur lui a effectivement délégué ce pouvoir. Le protocole AP2 introduit des mandats signés qui peuvent représenter l'intention, les contraintes et l'approbation de l'utilisateur. https://ap2-protocol.org/
Visa TAP, ou Trusted Agent Protocol, est l'approche adoptée par Visa pour établir la confiance entre les agents et les marchands. Le protocole TAP vise à aider les marchands à distinguer l'activité légitime des agents délégués des automatisations inconnues ou des bots abusifs. C'est important, car le trafic d'agents peut ressembler à du trafic de bots, à moins de disposer d'un moyen fiable pour identifier qui est l'agent, qui il représente et ce qu'il est autorisé à faire. https://developer.visa.com/capabilities/trusted-agent-protocol
Mastercard Agent Pay est le framework de paiement agentique de Mastercard. Il se concentre sur les agents d'IA de confiance participant aux flux de paiement en utilisant le réseau, la tokenisation, les contrôles et les capacités d'authentification de Mastercard. Mastercard a également introduit Agent Pay for Machines, qui vise les paiements machine à haute fréquence et de faible valeur qui s'effectuent en continu en arrière-plan. https://www.mastercard.com/us/en/business/artificial-intelligence/mastercard-agent-pay.html
x402 emprunte un chemin différent. Il réactive le code d'état HTTP 402 Payment Required et l'utilise comme un défi de paiement natif du web. Un client demande une ressource protégée. Le serveur renvoie un code 402 avec les exigences de paiement. Le client paie et réessaie avec une preuve de paiement. Ce protocole est particulièrement intéressant pour la monétisation des API, l'accès des agents et les paiements de machine à machine, car le paiement fait partie du flux de la requête HTTP. https://www.x402.org/
MPP, ou Machine Payments Protocol est un protocole ouvert de Stripe et Tempo destiné aux paiements programmatiques entre des agents et des services. Il est conçu pour les paiements entre machines, tels que les microtransactions, les paiements récurrents et les achats automatisés de service à service. À l'instar de x402, il se situe plus près de la couche des moyens de paiement que de la couche du flux d'achat complet. https://stripe.com/blog/machine-payments-protocol
Outre ces initiatives protocolaires de premier plan, des tiers développent également les couches d'identité, de portefeuille, de paiement et de vérification autour du commerce agentique.
Protocole | Couche | Fonction principale | Exemple d'action |
A2A | Communications | Permet la délégation directe de tâches et la communication entre différents agents d'IA. | L'agent personnel d'un acheteur négocie une remise sur volume directement avec l'agent commercial d'un commerçant. |
MCP | Fondation des données | Accède en toute sécurité aux données externes. | L'agent lit les stocks en temps réel et la tarification d'une boutique. |
UCP | Orchestration | Gère l'intégralité du cycle de vie d'achat. | L'agent parcourt les articles, compare les prix et gère le panier. |
ACP | Exécution | Gère le passage en caisse rapide et en surface. | L'agent exécute le flux de paiement final modéré par la plateforme. |
Visa TAP | Identité et confiance | Vérifie de manière cryptographique la légitimité de l'agent. | Le marchand confirme que la requête HTTP entrante provient d'un agent d'IA connu et de confiance, et non d'un bot de scraping. |
Mastercard Agent Pay | Accréditation | Émet des cartes tokenisées dont la portée est limitée à des agents spécifiques. | L'agent effectue le paiement en utilisant un jeton de réseau Mastercard lié directement à son identité avec une limite stricte de 100 $. |
AP2 | Autorisation | Prouve le consentement humain de manière cryptographique. | La banque vérifie que l'utilisateur a réellement approuvé la dépense de 50 $. |
x402 | Paiements machine | Gère les micropaiements crypto instantanés. | L'agent paie 0,02 $ à une API logistique pour router une distribution. |
MPP | Paiements machine | Permet les paiements HTTP 402 avec du streaming basé sur les sessions pour les devises fiduciaires et les cryptomonnaies. | L'agent transmet 0,003 $ par appel d'API via les rails fiat Stripe sans avoir besoin de créer un compte. |
À suivre…
Dans la suite de cette série, nous approfondirons les protocoles commerciaux ainsi que les protocoles d'autorisation et de paiement qui façonnent le commerce agentique.
Nous commencerons par le protocole x402, car il correspond parfaitement au chemin de la requête et montre comment le paiement peut s'intégrer au contrôle d'accès HTTP. Nous continuerons ensuite avec des articles et des démonstrations associés concernant Stripe MPP, ACP et d'autres travaux sur les protocoles émergents.
L'objectif est de rester au plus près de la mise en œuvre pratique : comment ces protocoles se comportent dans les flux de requêtes réels, là où la périphérie peut aider à relier politiques et routage, et ce que Fastly pourrait apporter au vaste écosystème du commerce agentique à mesure qu'il mûrit.
Lisez l'article How Fastly and Skyfire Enable Trusted Agentic Commerce at the Edge (Comment Fastly et Skyfire appuient le commerce agentique de confiance en périphérie) pour découvrir une implémentation concrète utilisant les identifiants KYA (Know Your Agent) de Skyfire et Fastly Compute pour vérifier les agents d'IA, valider les signaux de paiement et contrôler l'accès aux expériences de commerce et de contenu.