Le commerce agentique rassemble des technologies qui permettent à un agent IA de rechercher un produit, comparer des offres, préparer une transaction et parfois agir au nom d’un acheteur. Plusieurs protocoles sont apparus pour couvrir ces étapes. Ils sont souvent présentés comme concurrents, alors qu’ils traitent des problèmes différents : découverte, contexte, autorisation, paiement ou transport.
Pour une équipe e-commerce, la bonne question n’est pas de choisir immédiatement un vainqueur. Il faut comprendre la fonction de chaque standard, identifier les dépendances de la plateforme et préparer une architecture capable d’évoluer.
Décomposer le parcours avant de comparer
Un achat par agent comporte plusieurs couches. L’agent doit comprendre l’intention, trouver des produits, vérifier les offres, respecter les politiques, obtenir un consentement, payer puis suivre la commande. Aucun protocole unique ne résout nécessairement l’ensemble de ces étapes.
La comparaison devient plus claire lorsque chaque standard est placé sur cette chaîne. Un protocole de contexte ne remplace pas une autorisation de paiement. Un standard de checkout ne garantit pas la qualité du catalogue. Cette décomposition évite les oppositions artificielles.
ACP et UCP : deux approches du commerce agentique
ACP, pour Agentic Commerce Protocol, est associé à OpenAI et Stripe. Il vise les interactions de commerce dans un environnement d’agents, notamment autour de la découverte et du checkout. UCP, pour Universal Commerce Protocol, est porté par Google et Shopify avec d’autres acteurs du commerce et couvre un parcours plus large.
Les deux approches doivent être évaluées selon les canaux ciblés, la disponibilité des intégrations et la maturité réelle des fonctionnalités. Les annonces évoluent rapidement. Une équipe doit donc s’appuyer sur la documentation et les versions en production plutôt que sur un schéma figé.
AP2 : encadrer l’autorisation de paiement
Un agent ne devrait pas payer simplement parce qu’il a trouvé une offre. Il faut prouver l’intention de l’utilisateur, définir des limites et conserver une trace. AP2, Agent Payments Protocol, traite ce besoin d’autorisation dans un cadre indépendant d’un moyen de paiement particulier.
Cette couche est essentielle pour la gouvernance. Elle aide à distinguer la recommandation, la préparation et l’exécution. Les entreprises doivent préciser quels montants, marchands ou catégories sont autorisés et dans quelles situations une nouvelle confirmation est nécessaire.
MCP : relier l’agent aux outils et aux données
MCP, Model Context Protocol, sert à connecter un agent à des ressources et à des outils. Dans le commerce, il peut donner accès à un catalogue, un service de stock ou une fonction de création de panier. Il ne constitue pas à lui seul un système de paiement.
La sécurité dépend des outils exposés, des permissions et de la validation des entrées. Une fonction de lecture n’a pas le même risque qu’une action modifiant une commande. Chaque outil doit avoir un périmètre clair et des journaux exploitables.
x402 : payer nativement sur HTTP
x402 réutilise le principe du code HTTP 402 pour permettre des paiements, notamment en stablecoins, entre agents et services. Cette approche intéresse les API et les microtransactions où un paiement peut débloquer une ressource.
Elle soulève toutefois des questions de conformité, de volatilité opérationnelle, de remboursement et de rapprochement comptable. Sa pertinence dépend du cas d’usage et de la juridiction, pas seulement de la simplicité technique.
- ACP : expérience de commerce dans l’écosystème des agents OpenAI ;
- UCP : parcours de commerce agentique porté par Google, Shopify et des partenaires ;
- AP2 : autorisation et preuve d’intention pour le paiement ;
- MCP : connexion de l’agent aux données et aux outils ;
- x402 : paiement natif sur HTTP pour services et API.
Utiliser une source datée et neutre
Les spécifications et partenariats évoluent vite. ACP Info propose un comparatif des standards, un suivi d’adoption et des sources primaires datées. Cette méthode est utile pour vérifier si une fonctionnalité est annoncée, disponible en bêta ou réellement déployée.
Une comparaison sérieuse doit indiquer l’auteur, la licence, le périmètre, le statut et la date de vérification. Sans ces éléments, une fiche peut mélanger une vision prospective avec un produit utilisable aujourd’hui.
Construire une stratégie sans verrouillage prématuré
Le marchand doit d’abord stabiliser ses données produit, ses politiques et ses identifiants. Ensuite, il peut exposer des capacités par interfaces contrôlées et tester les canaux pertinents. Les permissions, le consentement et la traçabilité doivent rester communs, même si plusieurs protocoles coexistent.
Une architecture modulaire permet de changer un connecteur sans réécrire toute la gouvernance. Les standards de commerce agentique sont complémentaires lorsqu’ils sont placés sur les bonnes couches. La meilleure préparation consiste donc à rendre les données fiables, les actions explicites et les décisions auditables, puis à connecter progressivement les protocoles réellement utilisés par les clients.
Avant toute expérimentation, l’équipe doit enfin définir un responsable, un environnement de test et des critères d’arrêt. Une transaction agentique touche plusieurs métiers : produit, paiement, sécurité, juridique et service client. Un pilote limité, documenté et réversible apporte davantage d’enseignements qu’une intégration générale lancée sur la base d’une annonce.