ACP vs UCP vs AP2 vs MCP : quel protocole de commerce agentique est le plus pertinent ?

Ce sont des couches, pas des rivaux

Presque toute la couverture de ces protocoles les présente comme une guerre des standards avec un gagnant à choisir. Cette approche est erronée et conduit les commerçants à prendre la mauvaise décision, qui est d'attendre.

Ils répondent à des questions différentes. MCP répond « à quoi cet agent peut-il accéder et qu'est-ce qu'il peut appeler ? » UCP répond « comment un agent lit-il un catalogue et construit-il un panier ? » ACP répond « comment un achat s'exécute-t-il au sein d'une interface d'IA, et qui le traite ? » AP2 répond « comment prouver qu'un humain a autorisé cela, d'une manière qui résiste à une contestation ? » Une seule transaction peut toucher les quatre.

Ce qui a changé en 2026, et pourquoi cela plaide en faveur de la couche de découverte

Deux développements ont remis les choses à plat cette année, et tous deux vont dans la même direction.

Premièrement, OpenAI a fermé Instant Checkout et a repositionné ACP vers la découverte de produits et les expériences contrôlées par le commerçant plutôt que l'achèvement d'achats en chat. De grands détaillants — Target, Sephora, Nordstrom, Lowe's, Best Buy, Home Depot, Wayfair — ont intégré ACP pour la découverte. La révision d'avril 2026 couvre le paiement, la délégation de paiement, le panier, le flux et l'authentification, plus un crochet qui permet aux agents compatibles ACP de faire de la publicité pour la capacité de paiement via la découverte d'outils MCP.

Deuxièmement, Google a fait don d'AP2 v0.2 à la FIDO Alliance le 28 avril 2026, déplaçant l'autorisation de paiement du contrôle d'un seul fournisseur vers un organisme de normalisation ayant une longue expérience en matière d'authentification.

Ce qu'il faut retenir pour un commerçant : la couche de paiement est encore en mouvement, la couche de découverte s'est déjà consolidée, et tous ceux qui ont essayé de sauter la découverte pour passer directement à l'achat en chat ont au moins en partie fait marche arrière. Construisez le catalogue lisible par machine maintenant. Il est requis par chacun de ces protocoles et n'est obsolète par aucun d'entre eux.

La séquence qui ne laisse pas de travail en suspens

Étant donné que le haut de la pile est incertain, l'ordre de travail sensé est celui où chaque étape est utile en soi et rien n'est gaspillé si un protocole échoue.

• 1. Catalogue lisible par machine. Données produit rendues par le serveur avec schema.org Product, prix réel, disponibilité réelle, identifiants réels. Requis par UCP et ACP, utile à chaque assistant aujourd'hui, et cela améliore le SEO classique en même temps.
• 2. Une surface de découverte qu'un agent peut indexer. Un robots.txt qui autorise les crawlers d'assistants que vous souhaitez, un sitemap, et un llms.txt qui indique ce que vous vendez sans obliger un modèle à parcourir 80 pages pour le comprendre.
• 3. Panier et devis programmatiques. Une API qui renvoie un prix ferme incluant les frais de port et les taxes, afin qu'un agent n'ait jamais à naviguer sur un navigateur pour savoir ce que coûte quelque chose.
• 4. Accès agentique délimité et audité. Avant de laisser quoi que ce soit d'externe agir, vous avez besoin de portées par clé, d'idempotence et d'un journal d'audit. C'est là que la plupart des plateformes n'ont rien, et c'est ce qui transforme l'accès agentique d'une responsabilité en quelque chose qu'une équipe financière approuvera.
• 5. Autorisation de paiement. Mandats vérifiables de type AP2, une fois que votre processeur les prend en charge. En dernier car c'est la couche encore en mouvement et celle que vous voulez le moins construire deux fois.

Où se situe PlatformDTC

PlatformDTC livre les étapes un et deux comme des valeurs par défaut de la plateforme plutôt que comme des plugins — les vitrines rendent les données produit structurées côté serveur, et la couche de découverte est générée à partir de l'arborescence des routes afin qu'elle ne puisse pas dériver.

Les étapes trois et quatre sont l'Agent Gateway : une API délimitée où chaque opération appelable par un agent porte une clé d'idempotence, un enregistrement d'audit et une portée de permission liée à la clé d'appel, et où toute action qui dépense de l'argent s'arrête à une porte d'approbation humaine avant de s'exécuter. Les mêmes opérations sont exposées comme des outils MCP, de sorte qu'un assistant peut les découvrir et les appeler directement.