UCP : qu'est-ce que le Universal Commerce Protocol ?

Un agent qui achète à votre place doit parler à des milliers de marchands qui n'ont ni la même API, ni le même tunnel, ni les mêmes règles. UCP est la tentative de répondre à ça par un vocabulaire commun.

Pourquoi il existe

Aujourd'hui, un agent qui veut acheter a deux options, mauvaises toutes les deux.

Il peut piloter un navigateur comme le ferait une personne : cliquer, remplir, valider. Cela fonctionne jusqu'au premier bouton renommé, jusqu'au premier test A/B, jusqu'au premier captcha. C'est fragile par construction.

Il peut intégrer chaque API marchande, une par une. Cela fonctionne, et ne monte pas à l'échelle : l'éditeur de l'agent devient responsable d'autant d'intégrations qu'il y a de sites.

UCP propose la troisième voie : que le marchand expose un parcours décrit de la même façon partout, que l'agent sache consommer sans rien connaître de particulier.

Ce qu'il standardise

Discovery   -> quelles capacités ce marchand expose-t-il ?
Catalog     -> chercher, filtrer, lire un produit et son prix
Cart        -> composer, modifier, connaitre le total
Checkout    -> ouvrir un paiement, passer la main si besoin
Order       -> etat de la commande, apres l'achat

Chacune de ces étapes a un vocabulaire : des ressources, des champs, des erreurs. Le protocole décrit aussi des capabilities : un marchand annonce ce qu'il sait faire, et l'agent s'y adapte plutôt que de supposer.

Deux points méritent l'attention.

Le handoff

Tout ne peut pas se faire sans humain. Un paiement fort, une vérification d'identité, une acceptation de conditions : à un moment, l'agent doit passer la main, et y revenir ensuite. UCP prévoit ce relais, et c'est l'une des parties les plus sensibles du standard : mal faite, elle donne un parcours qui s'interrompt sans que personne ne sache pourquoi.

Les liaisons

UCP n'est pas qu'un format : il se transporte. Une liaison REST le rend consommable comme une API ordinaire, une liaison MCP le rend consommable par un agent déjà outillé. Ce sont deux portes sur le même vocabulaire, et un marchand peut n'en ouvrir qu'une.

Ce qu'il ne résout pas

Il ne règle pas non plus la question de la confiance : un agent qui commande pour un utilisateur engage son argent. Consentement, plafonds, révocation, traçabilité : ces sujets vivent autour du protocole, pas dedans.

Où en est Ts-Shop

Soyons précis, parce que c'est exactement le genre de sujet où le flou se vend bien.

Autrement dit : les fondations sont là, l'adaptateur ne l'est pas. Nous préférons le dire ainsi plutôt que d'écrire « UCP ready », qui ne veut rien dire de vérifiable.

Ce qu'il faut vérifier avant de croire un « nous supportons UCP »

1. Quelle version ? Un standard en évolution sans numéro de version annoncé est une promesse sans objet.
2. Quelles capabilities ? Supporter le catalogue n'est pas supporter le checkout.
3. Quelle liaison ? REST, MCP, les deux ?
4. Que se passe-t-il au handoff ? C'est là que les implémentations incomplètes se voient.
5. Est-ce testable ? Un bac à sable et un exemple d'échange valent mieux qu'une page produit.

Questions courantes

UCP remplace-t-il MCP ? Non. Voir MCP vs UCP : l'un sert à comprendre et intégrer, l'autre à commercer.

Faut-il attendre UCP pour vendre ? Non, et c'est même l'inverse : un catalogue et un checkout qui marchent sont le prérequis de toute exposition future.

Un marchand doit-il tout implémenter ? Le protocole prévoit qu'on annonce ce qu'on sait faire. Un marchand qui n'expose que la découverte et le catalogue reste conforme, et utile.

Sources et pour aller plus loin

• La spécification UCP, dans sa version en vigueur : c'est elle qui fait foi, et elle bouge.
• MCP vs UCP : deux protocoles IA, deux rôles différents
• Agentic Commerce chez Ts-Shop