ACP (Protocole de Commerce Agentique)

Ce que la spécification nomme réellement

L'ACP est le plus spécifique au commerce des protocoles dans cet espace, et la manière la plus simple de le concevoir est comme une liste d'objets plutôt que comme une philosophie. La révision d'avril 2026 couvre un flux de produits, une session de paiement, la délégation de paiement, le panier et l'authentification, ainsi qu'un point d'intégration qui permet à un agent compatible ACP de faire connaître sa capacité de paiement via la découverte d'outils MCP.

Chaque objet existe parce qu'une étape qu'une personne effectue dans un navigateur n'a pas d'équivalent machine. Une personne navigue dans un catalogue ; un agent a besoin d'un flux. Une personne voit un total s'assembler en tapant une adresse ; un agent a besoin d'une session qui renvoie un montant définitif. Une personne saisit une carte dans un formulaire sur votre domaine ; un agent a besoin d'un moyen défini de transmettre le paiement à votre processeur sans détenir lui-même les informations d'identification.

Les éditeurs sont OpenAI et Stripe, et cet appariement est visible dans la forme du document. Il est rédigé par une partie qui possède une interface d'assistant et une partie qui possède le traitement des paiements, et la majeure partie de ce qu'il spécifie est la frontière entre les deux.

Position de l'ACP par rapport à UCP, AP2 et MCP

Les quatre noms sont généralement présentés comme une guerre des standards, ce qui conduit les marchands à la mauvaise conclusion — que la démarche sensée est d'attendre un vainqueur. Ils répondent à des questions différentes et se complètent largement.

Le MCP, publié par Anthropic, est le mécanisme général par lequel un agent apprend qu'une capacité existe et comment l'appeler ; il ne dit rien sur les paniers ou l'argent. L'UCP, de Google et Shopify, couvre la lecture de catalogues et la construction de paniers. L'ACP couvre l'exécution du paiement et la délégation de paiement. L'AP2, initié par Google et donné à la FIDO Alliance en avril 2026, couvre la preuve qu'un humain spécifique a autorisé un paiement spécifique.

Le parrainage explique la couverture dans chaque cas. Google et Shopify ont besoin que les agents puissent lire les catalogues du monde, donc leur standard spécifie la découverte. OpenAI et Stripe ont besoin qu'un achat soit finalisé quelque part, donc le leur spécifie le paiement et le règlement. Personne n'a écrit de spécification pour une couche qu'il ne possédait pas déjà.

Le seul chevauchement à connaître est la limite du panier, où l'UCP et l'ACP ont tous deux quelque chose à dire. L'exigence côté marchand sous-jacente est identique dans les deux cas — un catalogue présentant un prix réel et une disponibilité réelle — c'est pourquoi ce travail est la seule partie de la pile qui ne dépend pas du standard qui prévaudra.

La délégation de paiement est la partie véritablement nouvelle

Les flux de produits ne sont pas nouveaux et les points d'accès de paiement ne sont pas nouveaux. L'élément de l'ACP sans équivalent antérieur est la délégation de paiement : l'environnement de l'agent transmet le traitement au processeur du marchand plutôt que de détenir les informations d'identification de la carte ou de devenir lui-même le marchand officiel.

Cet arrangement est ce qui rend le protocole acceptable pour les marchands. Vous conservez la relation avec le processeur, le règlement et le dossier client. Vous conservez également la responsabilité, et c'est la partie qui mérite d'être lue deux fois — un achat initié par un agent et un achat initié par un humain atteignent votre processeur par les mêmes canaux, tandis que les formats de preuves de litige qui existent aujourd'hui supposent tous qu'une personne était présente lors de la transaction.

Cette lacune est précisément ce que l'AP2 a été conçu pour combler, et elle n'est pas traitée au niveau de l'ACP. Un marchand acceptant des paiements initiés par un agent les accepte désormais sans un artefact standard établissant ce que le titulaire de la carte a autorisé ou dans quelles limites.

Ce que l'ACP ne spécifie pas

Lire une spécification pour ce qu'elle omet est généralement plus instructif que de la lire pour ce qu'elle contient, et les omissions ici sont suffisamment importantes pour changer ce que l'expression « support ACP » peut honnêtement signifier.

Ils tracent également la ligne entre la livraison des prérequis et l'implémentation du protocole. Un catalogue lisible par machine, une passerelle d'agent délimitée et un ensemble d'outils MCP sont des éléments que l'ACP suppose qu'un marchand possède déjà. Les avoir est un travail préparatoire plutôt qu'une conformité, et une plateforme présentant les deux comme la même affirmation exagère ce qu'elle fait.

Ce que la spécification vous laisse entièrement :

• Confiance. Rien dans celle-ci ne décide quels agents vous devez servir, ni à quelles conditions. C'est une politique que vous rédigez et appliquez vous-même.
• Autorisation et audit. Il ne définit aucune portée de permission, aucune exigence d'idempotence et aucun enregistrement d'audit. Un agent qui réessaie une requête ambiguë est un événement ordinaire, et rien dans le protocole n'empêche que cela ne devienne deux commandes.
• La partie post-achat. Les retours, remboursements, annulations, changements d'abonnement et le support sont en dehors de son champ d'application, et c'est là que se trouve la majeure partie du coût d'exploitation d'une commande.
• Adoption. Une implémentation conforme n'oblige aucun assistant à l'utiliser. Quelles interfaces lisent quoi, dans quelles catégories, est une question commerciale qu'aucune spécification ne règle.