UCP 2026-08-25 : authentification 3DS2, paiement en plusieurs fois et une série de ruptures

Le Universal Commerce Protocol (UCP) est un standard ouvert qui décrit comment un assistant IA dialogue avec une boutique : chercher un produit, remplir un panier, payer, suivre la commande. Son site le présente comme co-développé par Google, Shopify, Walmart, Amazon, Microsoft, Meta ou Stripe, entre autres. Parmi les soutiens affichés figurent Carrefour, Zalando, Adyen, Klarna, Visa, Mastercard et PayPal.

La version publiée le 25 août 2026 succède à celle du 8 avril. Elle est dense. Voici ce qui compte pour un commerçant.

Le paiement se rapproche des usages européens

• Authentification 3DS2. Le protocole sait désormais porter la collecte de données de l'appareil et le parcours de vérification, quel que soit le prestataire. C'est la brique qui manquait pour l'authentification forte exigée en Europe sur les paiements par carte.
• Échéanciers. Paiement différé, acompte et paiement en plusieurs fois deviennent exprimables à la commande.
• Paiement fractionné. Plusieurs moyens de paiement peuvent régler une même commande.
• Carte ou jeton. Le numéro de carte et le jeton réseau deviennent deux types d'identifiants distincts.

La mécanique commune s'appelle « Actions » : la boutique peut demander à l'agent une étape hors du flux normal, par exemple une authentification ou un formulaire à faire remplir.

Retrait en magasin, produits au poids, fidélité

La version prépare l'alimentaire et le commerce de proximité :

• recherche de points de vente, avec adresse et horaires, y compris les horaires exceptionnels et le fuseau ;
• distinction obligatoire entre livraison et retrait ;
• quantités non entières, pour vendre au kilo ;
• programme de fidélité décrit en propre, sans passer par une fausse remise ;
• conditions de retour, de remboursement et de garantie attachées au panier et à la commande ;
• lien permanent qui reconstitue un panier, utile dans un courriel ou sur un code QR.

Ce qui casse

Les notes de version énumèrent des changements incompatibles avec la version d'avril. Les principaux :

• le schéma de livraison est restructuré : indicateurs renommés, description devenue un objet, un fichier de configuration supprimé et fusionné dans un autre ;
• le consentement de l'acheteur change de forme ;
• le champ des clés de signature du profil est remplacé : seul keys[] subsiste ;
• les schémas sont réorganisés en trois familles (achat, paiement, commun), ce qui modifie leurs adresses ;
• les extensions de paiement changent d'espace de noms ;
• la quantité d'un article peut être un entier ou une mesure ;
• les exigences sur les moyens de paiement ne sont plus statiques : la boutique les renvoie dans ses réponses.

Les notes ne comportent ni section de dépréciation ni guide de migration. Il faut lire les demandes de modification liées, une par une.

Les limites

Le protocole avance vite : quatre versions publiées sur GitHub depuis janvier 2026, dont au moins deux avec ruptures. Une intégration faite au printemps est déjà à reprendre. Par ailleurs, qu'une fonction existe dans la spécification ne dit rien de sa prise en charge par les assistants ni par les prestataires de paiement. Le 3DS2 dans UCP ne vaut que si votre prestataire l'a implémenté.

Enfin, un protocole technique ne dit pas qui est responsable quand un agent commande le mauvais produit ou qu'un paiement est contesté.

Notre lecture

Un petit commerçant français n'a pas à implémenter UCP lui-même. Il doit en revanche poser trois questions à l'éditeur de sa boutique et à son prestataire de paiement : quelle version du protocole est prise en charge, qui assume les migrations quand elle change, et comment l'authentification forte est gérée pour un achat lancé par un agent. Tant que ces réponses restent floues, mieux vaut soigner ses données produits, ses stocks et ses conditions de retour : elles serviront quel que soit le protocole retenu.