L'UCP de Google ajoute quatre en-têtes à chaque paiement. Trois existent pour la dispute qui suivra

Le 11 janvier 2026, Google a publié le Universal Commerce Protocol — un standard open source permettant aux agents IA d'acheter — co-développé avec Shopify et soutenu par plus de 20 partenaires, dont Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa et Zalando.

La couverture qui a suivi parlait de shopping. Des agents qui parcourent les catalogues pour vous, des agents qui paient pour vous, la fin du panier d'achat, etc.

Puis on lit la spécification, et le shopping s'avère être la chose la moins intéressante qu'elle contient. Ce que l'UCP normalise avec un soin inhabituel, ce n'est pas l'achat. C'est la preuve que l'achat s'est déroulé comme les deux parties le prétendent.

L'essentiel :

• Chaque requête UCP modifiant un état transporte quatre en-têtes, et trois d'entre eux — request-signature, idempotency-key, request-id — ne servent à rien pour la transaction elle-même. Ils existent pour que plus tard, quelqu'un puisse prouver ce qui a été demandé, que cela n'a été demandé qu'une fois, et le retrouver.
• La non-répudiation est une fonctionnalité nommée. Dans l'extension optionnelle de mandats AP2 (dev.ucp.shopping.ap2_mandate), le commerçant signe cryptographiquement les conditions de paiement pendant que la plateforme fournit des mandats cryptographiques prouvant que l'utilisateur les a autorisées. Objectif déclaré par la spécification : « réduire considérablement les risques d'altération et de litige ».
• Le nombre de soutiens n'est pas un nombre d'intégrations. « Plus de 20 partenaires mondiaux » est la formule publiée par Google, et elle décrit un soutien. À l'heure où nous écrivons, nous n'avons trouvé aucune source primaire donnant un décompte de marchands UCP en production.

Jeu d'en-têtes issu du tutoriel publié par Google le jour du lancement. Sources en fin d'article.

Ce qu'est l'UCP, en aussi peu de mots que possible sans mentir

Avant l'argument, les faits vérifiables. Ils proviennent de la spécification publiée sur ucp.dev et du blog développeurs de Google, tous deux consultés le 5 septembre 2026.

Deux lignes de ce tableau méritent qu'on s'y arrête, car la plupart des articles les sautent toutes les deux.

La première est la ligne des transports. L'UCP n'est pas une affaire de MCP, ni une affaire de REST. Les mêmes données déclarées sont proposées sur REST, MCP, A2A et un binding embarqué, et c'est le commerçant qui choisit. C'est un refus délibéré de parier sur la tuyauterie d'agent qui l'emportera.

La seconde est le versionnage par date. 2026-04-08 n'est pas une version sémantique, c'est un jour. La raison invoquée est l'ordre chronologique et la comparaison sans ambiguïté — mais l'effet pratique, c'est que chaque session négociée enregistre la date des règles sous lesquelles elle s'est déroulée. C'est une décision d'archivage déguisée en décision de versionnage, et elle donne le ton du reste du document.

Le goulot d'étranglement qu'il vise à supprimer

Le cadrage de Google est un problème en N×N. Toute entreprise voulant apparaître dans une surface conversationnelle doit construire une connexion sur mesure pour chacune ; chaque surface doit intégrer chaque entreprise séparément ; au final, personne ne livre.

Le billet d'ingénierie de Shopify, publié le même jour par l'ingénieur distingué Ilya Grigorik, aborde le même problème par en dessous. Après plus de 20 ans, des milliards de transactions et des millions de marchands, la leçon est que le commerce refuse de se normaliser : « les options et règles de paiement diffèrent selon les propriétés du panier, de l'acheteur et du marché ; les remises ont des règles de cumul et de combinaison qui rivalisent avec le code des impôts ; les options de livraison explosent en permutations incontrôlables ». Puis vient la phrase à retenir : « Cette complexité n'est pas un bug, c'est une propriété émergente de la diversité des détaillants. »

Cette seule ligne explique toute l'architecture. Si l'on accepte que les marchands sont irréductiblement différents, on ne peut pas normaliser le comportement. On ne peut normaliser que la manière dont un marchand déclare son comportement, et la manière dont un agent découvre à quoi il vient de consentir.

La structure qu'une entreprise publie sur /.well-known/ucp. Source : spécification UCP 2026-04-08, Overview.

La découverte a lieu avant que la conversation commence

Voici le déroulé, tel que le décrivent la spécification et le tutoriel de Google. Il vaut la peine de le suivre à la lettre, car l'ordre est l'argument.

1. L'entreprise publie un profil sur /.well-known/ucp. Elle y déclare une version de protocole, un ou plusieurs services (dev.ucp.shopping), les capacités qu'ils contiennent, les transports et points d'accès, les gestionnaires de paiement disponibles et — cela comptera plus loin — ses signing_keys publiques.
2. L'agent annonce son propre profil à chaque requête, via un en-tête UCP-Agent en syntaxe dictionnaire RFC 8941 : UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Sur transport MCP, la même information voyage dans un objet meta.
3. L'entreprise calcule l'intersection. Parmi ses capacités, elle garde celles que la plateforme déclare aussi ; pour chaque survivante, elle retient la version la plus élevée présente dans les deux tableaux ; s'il n'existe aucune version commune, la capacité disparaît entièrement.
4. Les extensions orphelines sont élaguées. Une extension déclarant extends: "dev.ucp.shopping.checkout" disparaît si checkout n'a pas survécu. L'élagage se répète jusqu'à ce que plus rien ne tombe, ce qui gère les chaînes transitives.
5. C'est l'entreprise qui choisit. L'UCP utilise une architecture où le serveur sélectionne : c'est le marchand, pas l'agent, qui décide de ce qui est actif pour la session, et il renvoie le registre des capacités actives dans la réponse.

Le nommage n'est pas une convention mais une gouvernance. Chaque capacité s'écrit {domaine-inversé}.{service}.{capacité} — dev.ucp.shopping.checkout pour la version standard, com.example.payments.installments pour celle d'un marchand. Un détaillant peut inventer une capacité que personne d'autre n'a, sans demander la permission et sans entrer en collision avec quiconque, parce que le domaine inversé fait autorité.

L'échec a lui aussi sa taxonomie, et la distinction est instructive. La spécification sépare les échecs de découverte (erreurs de transport : invalid_profile_url renvoie 400, profile_unreachable renvoie 424, profile_malformed renvoie 422) des échecs de négociation, qui sont des résultats métier et reviennent en 200 normal avec capabilities_incompatible dans le corps. « Je n'ai pas pu vous joindre » et « nous n'avons rien en commun » sont deux événements différents, et l'UCP refuse de les confondre en un seul 400.

Quatre en-têtes voyagent sur chaque requête modifiante

Regardons un appel réel. C'est l'exemple publié par Google le jour du lancement : la création d'une session de paiement auprès d'un fleuriste fictif.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Quatre en-têtes. Demandez à quoi sert chacun, et un motif se dégage.

Trois des quatre ne servent pas la transaction. Ils servent le désaccord au sujet de la transaction.

Ce n'est pas un accident d'hygiène d'API. Les clés d'idempotence et les identifiants de requête sont des bonnes pratiques ordinaires dans le paiement, certes — mais la spécification va nettement plus loin, et plus elle va loin, plus l'intention devient claire.

La non-répudiation est un objectif de conception, pas un ajout de conformité

L'UCP énumère quatre mécanismes d'authentification qu'une entreprise peut accepter : clés d'API, OAuth 2.0, mTLS, et signatures de messages HTTP selon RFC 9421. Les trois premiers sont ordinaires. Le quatrième fait quelque chose de précis.

Avec les signatures de messages, les deux parties publient leurs clés publiques dans le tableau signing_keys du document de profil qui déclare aussi leurs capacités. Le vérificateur extrait le keyid de l'en-tête Signature-Input, le rapproche d'un kid du jeu de clés publié par le signataire, et vérifie la signature. Pas de secret partagé, pas d'inscription, pas de compte. La spécification appelle ce résultat l'onboarding sans permission : « toute plateforme dotée d'un profil découvrable peut interagir avec n'importe quelle entreprise sans inscription préalable ».

La faille évidente est refermée par la liaison d'identité. Quel que soit le mécanisme, les vérificateurs doivent confirmer que le principal authentifié est bien autorisé à agir pour le profil désigné dans UCP-Agent, et rejeter la requête en cas de conflit. On ne peut pas s'authentifier en tant que soi-même puis prétendre être l'agent d'un autre.

Et les webhooks allant de l'entreprise vers la plateforme doivent être signés. Pas « devraient » — doivent. Les mises à jour du cycle de vie de commande — expédition, livraison, retours — sont le seul endroit du protocole où l'exigence est absolue, parce que ce sont les messages qui arrivent après le mouvement d'argent et que personne ne surveille en temps réel.

Source : spécification UCP 2026-04-08, sections Identity & Authentication et Transaction Integrity.

Puis vient le sommet de l'échelle. Pour les agents autonomes et les transactions à forte valeur, l'UCP définit une extension optionnelle, dev.ucp.shopping.ap2_mandate. Lorsque les deux parties la négocient :

• l'entreprise fournit une signature cryptographique sur les conditions de paiement, et
• la plateforme fournit des mandats cryptographiques prouvant que l'utilisateur les a autorisées.

L'agent signe les objets de mandat avec la clé privée de l'utilisateur sur une surface non agentique — c'est-à-dire que l'humain autorise depuis un écran qu'il contrôle, et non à l'intérieur de la boucle d'agent qui s'apprête à dépenser son argent. La formulation de l'objectif par la spécification mérite d'être citée exactement, car ce n'est pas une phrase de sécurité passe-partout : le mécanisme « fournit des garanties cryptographiques fortes et de bout en bout sur les détails de la transaction et le consentement des participants, réduisant considérablement les risques d'altération et de litige ».

Voici le point. Un protocole conçu uniquement pour laisser des agents acheter n'aurait besoin de rien de tout cela. Des conditions signées côté marchand et des mandats signés côté utilisateur ne sont pas des fonctionnalités de l'achat. Ce sont des fonctionnalités de la dispute au sujet de l'achat, six semaines plus tard, devant quelqu'un qui doit trancher.

Là où le récit dépasse les preuves

Trois choses reviennent au sujet de l'UCP que les sources primaires n'étayent pas telles quelles.

« 20+ partenaires » est un décompte de soutiens. La formule de Google est que l'UCP a été « co-développé et soutenu par plus de 20 partenaires ». Un soutien est une déclaration publique d'appui. Ce n'est pas une intégration livrée, et encore moins un marchand en production. Nous avons cherché une source primaire donnant le nombre de marchands transactant via UCP, sans succès.

« Standard ouvert » et « standard de Google » sont vrais tous les deux, et la tension est réelle. La spécification est open source, le dépôt GitHub accepte les pull requests, et la convention de nommage laisse délibérément chacun revendiquer son espace de noms. Par ailleurs, Google a construit la première implémentation de référence, et pour participer à celle-là, une entreprise doit disposer d'un compte Google Merchant Center actif avec des produits éligibles au paiement. Protocole neutre, première scène à guichet.

L'UCP ne supprime pas le marchand. C'est assez souvent déformé pour mériter d'être dit clairement : sous l'UCP, l'entreprise conserve sa propre logique métier et reste Merchant of Record. L'Embedded Checkout Protocol de Shopify prend le même engagement dans l'autre sens — quand un flux requiert un humain, l'agent charge une continue_url et le vrai paiement du marchand s'affiche à l'intérieur de la surface de l'agent via un canal JSON-RPC 2.0, le marchand finalisant la transaction. L'agent est une surface, pas un substitut.

Quatre choses que nous n'avons pas pu vérifier, signalées comme telles

La spécification publiée sur ucp.dev au moment de la consultation porte la version 2026-04-08, et sa liste de capacités standard — Cart, Checkout, Identity Linking, Order — diffère du tutoriel du 11 janvier, dont les exemples tournent en version 2026-01-11 et montrent checkout, discount et fulfillment. Quelque chose a été ajouté entre ces deux dates. Nous n'avons trouvé ni journal de modifications primaire identifiant le moment, ni note de version datée pour les versions intermédiaires ; nous rapportons donc la différence, pas un événement de publication.

Nous n'avons trouvé aucun décompte publié de marchands en production sur l'UCP, ni chez Google, ni chez Shopify, ni chez aucun partenaire soutien. L'absence de chiffre n'est pas la preuve d'un petit chiffre, mais c'est la raison pour laquelle nous n'en imprimons aucun.

Google déclare avoir construit la première implémentation de référence alimentant les achats dans l'AI Mode de la recherche et l'application Gemini. Nous n'avons pas vérifié indépendamment la disponibilité, la géographie ou l'ampleur de ce déploiement.

Savoir si l'UCP deviendra le standard du commerce agentique est, à l'heure où nous écrivons, impossible à établir, et tout article affirmant le contraire devine. La lecture honnête est plus étroite : une spécification existe, elle est publique, elle est exceptionnellement soigneuse sur la question de la preuve, et plusieurs très grandes entreprises ont signé l'annonce.

La moitié non signée

Prenons du recul par rapport au commerce, car la partie intéressante se généralise.

L'UCP décrit un monde où une machine agit en votre nom et où chaque étape de cette action laisse quelque chose derrière elle : qui a demandé, signé ; quelles conditions, signées ; combien de fois, clé d'idempotence ; dans quel ordre, corrélé. Six semaines plus tard, quand le débit est contesté, il existe un artefact. Personne n'a besoin de se souvenir.

Maintenant, demandez-vous d'où vient réellement l'autorité de ces actions. Un agent achète 400 unités parce qu'une décision d'achat a été prise. Un contrat se renouvelle parce que quelqu'un a accepté une clause. Un périmètre change parce que deux personnes en ont discuté un jeudi et que l'une d'elles a dit oui.

Ces conversations sont la moitié non signée du même flux de travail. Le côté machine se construit avec des reçus cryptographiques et une spécification qui traite les litiges comme un scénario de premier ordre. Le côté humain, dans la plupart des organisations, c'est la mémoire de l'un, la mémoire différente de l'autre, et un résumé écrit à partir des deux.

L'asymétrie va empirer avant de s'améliorer, parce que la moitié machine progresse au rythme d'une spécification et que la moitié humaine ne progresse pas du tout. Et le mode de défaillance est précis : ce n'est pas que les gens mentent. C'est qu'un artefact dérivé — un résumé, un compte rendu, une liste d'actions — devient le document lui-même dès que ce dont il est dérivé a disparu. Les résumés sont par construction avec perte. C'est ce qui les rend utiles. C'est aussi ce qui en fait de mauvaises sources primaires, et une fois l'original écarté, rien ne permet de distinguer un résumé lacunaire d'un résumé exact.

Les concepteurs de l'UCP l'ont compris au niveau du protocole et l'ont écrit : conservez l'original signé, dérivez-en ce que vous voulez, et faites en sorte que la dérivation puisse toujours être confrontée à quelque chose qui n'a pas bougé. C'est une discipline, pas une technologie, et elle s'applique exactement aussi bien à une heure de conversation humaine qu'à un POST /checkout-sessions.

Le fond de l'affaire : le commerce agentique est une norme de justificatifs déguisée en shopping

Le Universal Commerce Protocol est généralement décrit comme un moyen pour les agents IA d'acheter des choses. Lu de bout en bout, il est mieux décrit comme une tentative de répondre à une question que tout ce qui est agentique va rencontrer sans arrêt : quand une machine a agi pour moi, que peut-on exactement prouver de ce à quoi j'ai consenti ?

La réponse de l'UCP est bonne : déclarez vos capacités en public, signez les conditions, signez le consentement, clefez la reprise, corrélez l'appel, et signez le webhook qui rapporte ensuite ce qui s'est passé. Que le protocole l'emporte reste franchement ouvert. La question autour de laquelle il est bâti, elle, ne disparaîtra pas, quel que soit le vainqueur.

Reste une question avec laquelle il faut s'asseoir. Vos agents vont bientôt disposer de meilleures traces de ce à quoi ils ont consenti que vous n'en avez de ce à quoi vous avez consenti. Où cela mène-t-il ?

---

Où Telli.sh intervient : nous construisons la moitié non signée. Telli.sh enregistre la conversation, sépare les intervenants, traduit en direct dans 15 langues, et conserve l'enregistrement original et la transcription intégrale à côté de chaque résumé produit — pour que l'artefact dérivé ne devienne jamais le seul artefact. Telli.sh n'implémente pas l'UCP et ne le prétend pas ; nous traitons l'autre bout du même problème : les décisions qui autorisent le comportement des agents se prennent le plus souvent à l'oral et ne sont conservées nulle part.

Enregistrer votre prochaine réunion de décision

Sources

• Spécification Universal Commerce Protocol, Overview, version 2026-04-08 — modèle services, capacités et extensions, convention de nommage, versionnage par date, algorithme d'intersection des capacités, codes d'erreur de négociation et de signature, capacités standard (Cart, Checkout, Identity Linking, Order), transports, en-tête UCP-Agent et syntaxe RFC 8941, mécanismes d'authentification et onboarding sans permission, découverte de clés via signing_keys, liaison d'identité, signature obligatoire des webhooks, et section Transaction Integrity and Non-Repudiation ; consulté le 5 septembre 2026
• Google Developers Blog, « Under the Hood: Universal Commerce Protocol (UCP) », 11 janvier 2026 — liste des partenaires et chiffre de plus de 20 soutiens, compatibilité AP2/A2A/MCP, cadrage N×N, manifeste /.well-known/ucp, tutoriel en cinq étapes et jeu d'en-têtes de POST /checkout-sessions, Merchant of Record et option embarquée, implémentation de référence de Google dans AI Mode et Gemini, et exigence Merchant Center ; consulté le 5 septembre 2026
• Shopify Engineering, Ilya Grigorik, « Building the Universal Commerce Protocol », 11 janvier 2026 — le cadrage 20+ ans / milliards de transactions / millions de marchands, l'argument « pas un bug, une propriété émergente », les quatre principes de conception, et la passation Embedded Checkout Protocol en JSON-RPC 2.0 via continue_url ; consulté le 5 septembre 2026
• Agent Payments Protocol (AP2) — le protocole de paiement avec lequel l'UCP déclare sa compatibilité
• Universal Commerce Protocol sur GitHub — le dépôt open source nommé dans les deux annonces
• Notre lecture de GPT-6 Astra et de ce que la couche de capture décide encore — le même argument côté modèle : la qualité du raisonnement est plafonnée par ce qui a produit la trace sur laquelle il raisonne