UCP (Protocole de Commerce Universel)

UCP est un acronyme polysémique

Trois lettres, plusieurs significations. Dans les télécommunications et l'informatique d'entreprise, la même abréviation est le plus souvent interprétée comme une plateforme de communications unifiées, et elle apparaît dans des noms de produits et de plans de contrôle sans rapport dans toute l'industrie. Quiconque recherche l'acronyme seul rencontre un mélange de ces significations.

Dans le commerce, cela signifie le Protocole de Commerce Universel, le standard ouvert de Google et Shopify qui permet aux agents IA de lire les catalogues marchands, de récupérer les prix et les stocks en temps réel, de gérer les paniers et de finaliser les achats. C'est celui décrit ici.

Le problème qu'il vise à résoudre est de nature combinatoire

Sans un standard partagé, chaque assistant qui souhaite effectuer des transactions doit s'intégrer avec chaque détaillant avec lequel il souhaite effectuer des transactions. C'est une multiplication, et les multiplications deviennent rapidement inabordables.

Prenons un marché illustratif de 6 interfaces d'assistant et 500 détaillants avec lesquels il vaut la peine de s'intégrer. L'intégration bilatérale signifie 6 × 500 = 3,000 accords et implémentations distincts, chacun étant construit puis maintenu par quelqu'un. Selon un standard partagé, chaque partie l'implémente une seule fois : 6 + 500 = 506. L'écart se creuse à mesure que le marché se développe — à 10 interfaces et 2,000 détaillants, c'est 20,000 contre 2,010.

La conséquence pour une marque de taille moyenne est la partie qui compte. Les intégrations bilatérales ne sont négociées qu'avec les plus grands catalogues, car c'est là que le retour sur investissement justifie le développement. Un standard est ce qui rend le travail qu'un marchand effectue une fois lisible par tout agent conforme, ce qui est la différence entre participer à la demande générée par les agents et en être structurellement exclu.

Ce qu'un catalogue conforme doit contenir

L'obligation est moins exotique que ne le suggère la formulation, et elle se divise en trois éléments dont un agent a besoin avant de pouvoir agir sur vos produits.

Seul le premier est un exercice de modélisation de données. Le second est une question d'architecture concernant l'emplacement des stocks et le nombre de systèmes qui doivent s'accorder avant qu'un chiffre de stock ne soit exact, et c'est là que les implémentations échouent réellement plutôt que là où elles sont difficiles à démarrer.

• Identité. Identifiants de produit et de variante stables, idéalement incluant un GTIN, afin que l'article qu'un agent a trouvé à un endroit puisse être mis en correspondance avec l'article qu'il achète à un autre. Sans cela, la comparaison compare silencieusement les mauvaises choses.
• Vérité au moment de la lecture. Prix et disponibilité corrects au moment où ils sont lus, pas au moment où un flux nocturne a été généré. Un flux périmé de quelques heures annoncera avec confiance des stocks vendus ce matin, et un agent agissant sur celui-ci produira une annulation plutôt qu'une commande.
• Un panier qu'un agent peut piloter. Construction programmatique du panier retournant un total sur lequel l'agent peut compter, incluant les frais de port et les taxes pour la destination, car un agent qui ne peut pas obtenir un chiffre contraignant n'a rien à comparer.

Ce que la conformité ne vous apporte pas

Deux affirmations sont associées au support de protocole qui ne sont pas garanties par celui-ci, et il est préférable de refuser les deux avant de définir la portée d'un projet autour d'elles.

La première est la visibilité. Implémenter un standard vous rend lisible ; cela ne vous rend pas recommandé. Les produits qu'un assistant met en avant sont une décision de classement basée sur la pertinence, des informations de marque cohérentes et l'autorité de tiers tels que les avis et la couverture médiatique. Un catalogue conforme est la condition préalable pour être pris en compte, pas une raison d'être choisi.

La seconde est la sécurité. UCP décrit la lecture d'un catalogue et la construction d'un panier. Il n'inclut pas de modèle de permissions, pas d'exigence d'idempotence et pas de piste d'audit, et il ne dit rien sur l'autorisation de paiement — c'est le domaine d'AP2, et c'est la couche qui est encore en évolution. Toute interface par laquelle un agent peut agir sur des systèmes en direct nécessite des portées, une protection contre la relecture et un journal, quel que soit le protocole qui l'y a amené.

Comment UCP et ACP sont liés

Ils sont généralement présentés comme des rivaux et sont mieux compris comme des voisins qui se rencontrent à une frontière. UCP se concentre sur la découverte de catalogues et la construction de paniers ; ACP, d'OpenAI et Stripe, se concentre sur l'exécution du paiement et la délégation de paiement au sein d'un assistant. Les deux nécessitent la même chose de la part d'un marchand en amont.

Cette exigence partagée est la réponse pratique à la question de savoir lequel soutenir. Un catalogue lisible par machine avec des prix et des disponibilités réels est requis par les deux, utile aux assistants n'implémentant aucun des deux, et améliore la recherche classique en même temps. C'est la seule partie de cette pile qui n'est pas un pari.

Les couches au-dessus sont des paris, et les preuves jusqu'à présent plaident pour la patience. Les plus grands détaillants s'intégrant dans cet espace se sont concentrés sur la capacité à être trouvés plutôt que sur la capacité à effectuer des transactions au sein d'un assistant, et la partie la mieux placée pour le savoir a fermé sa propre fonction de paiement en chat en 2026.