L'état des standards du commerce agentique, mi-2026

Le commerce agentique a cessé d'être une expérience de pensée quelque part fin 2025. À la mi-2026, la question n'est plus de savoir si les agents IA achèteront pour le compte des consommateurs, mais quels standards ils parleront en le faisant. La réponse honnête aujourd'hui : plusieurs, en même temps. Voici un instantané de l'état des principaux protocoles, de ce qui a été livré récemment, et d'une lacune de spécification concrète que nous avons contribué à combler.

Trois protocoles qui coexistent

Le fait le plus important du paysage des standards, c'est qu'il n'y a pas de vainqueur unique, et que les marchands qui misent sur un seul seront pris de court. Trois protocoles occupent des couches distinctes mais qui se recouvrent.

MCP — Model Context Protocol. Issu d'Anthropic et entièrement ouvert, MCP est la couche qui expose les outils et données d'un système à un agent LLM. C'est l'adoption la plus rapide des trois : les téléchargements de SDK sont passés d'environ 100K par mois au lancement à des dizaines de millions par mois début 2026, avec des milliers de serveurs MCP publics aujourd'hui en ligne. WooCommerce a livré un MCP natif dans la version 10.3, et WordPress 7.0 a standardisé l'Abilities API sous-jacente pour tout l'écosystème.

ACP — Agentic Commerce Protocol. Porté par Stripe et OpenAI et publié sous Apache 2.0, ACP se concentre sur la transaction d'achat elle-même — le handshake de checkout et de paiement entre un agent et un marchand.

UCP — Universal Commerce Protocol. Porté par Google et Shopify, également sous Apache 2.0, UCP définit le flux de commerce de bout en bout, y compris une machine à états formelle du checkout. C'est le protocole où une grande partie du travail difficile sur les cas limites transactionnels se fait actuellement, à ciel ouvert.

Ces trois protocoles ne sont ni interchangeables ni mutuellement exclusifs. Un marchand multicanal à la mi-2026 doit penser MCP, ACP et UCP simultanément, car différents agents et plateformes l'atteindront par des portes différentes.

AP2 : la couche de mandat en dessous

Sous les protocoles de transaction se trouve AP2, le modèle de mandat pour les paiements par agent. AP2 introduit des mandats d'intention et des mandats de panier signés : une preuve cryptographique qu'un acheteur a autorisé un achat précis, portant une durée de vie (TTL). Le mandat de panier est la preuve d'autorisation non répudiable du marchand — l'artefact qui rend défendable une transaction par agent contestée. Comme nous le verrons, c'est précisément autour du cycle de vie de ce mandat que se concentre une grande partie du travail de spécification actuel.

Ce qui a été livré récemment

WordPress 7.0 (mai 2026) a standardisé l'Abilities API sur toute la plateforme, donnant à chaque boutique WordPress et WooCommerce une manière commune d'exposer ses capacités aux agents.

WooCommerce 10.7 (avril 2026) a ajouté le support natif d'ACP via un flag agentic_commerce sur les passerelles de paiement, après le MCP WooCommerce arrivé en 10.3.

3DS2 dans UCP est en passe de devenir un scénario de premier rang (suivi dans les issues UCP #420 et #421). Cela compte plus qu'il n'y paraît : un challenge 3-D Secure peut prendre plusieurs minutes quand l'acheteur est interrompu, ce qui transforme les complétions longues d'un cas limite en cas normal.

Une lacune que nous avons aidé à combler : l'expiration de mandat en plein checkout

En implémentant un serveur marchand UCP pour des marchands de longue traîne (hors Shopify), nous avons buté sur une question que la spécification ne tranchait pas, et nous l'avons ouverte sous la forme de l'issue UCP #512 : que se passe-t-il lorsqu'un mandat AP2 atteint sa TTL après l'acceptation de Complete Checkout mais avant la fin du paiement — pendant que le checkout est en complete_in_progress ?

Ce n'est pas théorique. Les rails de paiement asynchrones européens (prélèvement SEPA, iDEAL, Bancontact), les challenges 3DS interrompus et les relances PSP sur refus temporaires poussent régulièrement le traitement au-delà de la durée de vie restante d'un mandat. Sans réponse normative, des checkouts identiques réussiraient sur une stack marchande et échoueraient sur une autre, et un paiement autorisé contre un mandat expiré affaiblirait précisément la piste d'audit qu'AP2 existe pour fournir.

La discussion a convergé vers un modèle propre :

• Évaluer une fois, puis figer. La TTL du mandat est vérifiée une seule fois, à la réception de Complete Checkout. Une fois acceptée, le traitement va jusqu'à un état terminal quelle que soit l'expiration ultérieure. Cela suit une distinction autorisation/liveness : l'acceptation règle l'autorisation ; la TTL ne contrôle que la possibilité d'entrer dans le grant, jamais le maintien de l'autorisation du travail en cours.
• Ancré dans AP2 et la DSP2. AP2 n'offre à l'acheteur aucun canal intra-protocole pour révoquer un mandat avant sa TTL ; la TTL est donc une borne convenue d'avance, pas un signal de retrait en direct. Cela reflète la DSP2, où le retrait du consentement (art. 64) est borné par l'irrévocabilité (art. 80) — l'acceptation de Complete Checkout est le point d'irrévocabilité naturel.
• Un artefact terminal signé pour la péremption. Si un mandat est déjà expiré à l'acceptation, le checkout n'entre jamais en complete_in_progress ; à la place, un reçu d'annulation signé EXPIRED devient l'état terminal, tiré d'un enum fermé (USER_REQUESTED / MERCHANT_REQUESTED / COMPLIANCE_TERMINATED / EXPIRED).
• Un seul chemin de vérification, deux issues. L'évaluation positive enregistrée (autorisé-et-exécuté) et le reçu EXPIRED sont des frères : la même forme probante signée, vérifiée par un chemin unique — canonicalisation JCS (RFC 8785) plus Ed25519 — plutôt que par deux vérificateurs spécifiques.
• Politique déclarée par le marchand. Le profil de capacités annonce la politique, un min_remaining_ttl optionnel et le profil de signature, pour qu'une plateforme connaisse les règles avant d'appeler Complete Checkout.

L'étape suivante est le texte normatif : une enveloppe de reçu partagée et versionnée avec un discriminant receipt_type, un champ de liaison commun rattachant les deux reçus au même checkout, et des horodatages distincts et normativement séparés pour que le timing de révocation reste auditable. C'est un petit changement à l'impact démesuré : c'est la différence entre une piste d'audit déterministe et défendable et un amas de comportements PSP divergents. Nous documentons le modèle de cycle de vie complet — la règle évaluer-une-fois-puis-figer, le chemin de vérification unique derrière les deux issues et le profil de capacité marchand — sur notre page de référence UCP mandate-evaluation.

Ce que cela signifie pour les marchands

Vous n'avez pas à désigner un protocole vainqueur, car il n'y en aura pas de sitôt. Vous devez être lisible et transactable sur tous, et votre plateforme — ou votre couche d'audit — doit traiter correctement les cas limites ingrats comme l'expiration de mandat. Les standards mûrissent vite, à ciel ouvert, et les marchands qui suivent les discussions de spécification sont ceux que le prochain changement normatif ne surprendra pas.

Les audits MerchantStamp évaluent la préparation du catalogue et de la boutique face à MCP, ACP et UCP côte à côte, pour que vous voyiez où vous en êtes à chaque porte qu'un agent pourrait emprunter. Lancez un scan gratuit pour vérifier votre état actuel.