Commerce agentique et UCP : préparer son catalogue et son checkout aux achats pilotés par l’IA

Les assistants peuvent déjà rechercher, comparer et recommander des produits. L’étape suivante consiste à leur permettre de préparer ou d’exécuter certaines étapes de l’achat. En 2026, le terme commerce agentique désigne ces parcours dans lesquels un agent agit à partir de l’intention d’un utilisateur, dialogue avec des systèmes marchands et maintient le contexte jusqu’à la commande.

Google a présenté Universal Commerce Protocol, ou UCP, comme un standard ouvert destiné à décrire des capacités de commerce de façon cohérente entre surfaces et marchands. Des intégrations de référence visent notamment des expériences conversationnelles. Au 17 août 2026, certaines fonctions restent toutefois en pilote ou soumises à éligibilité : la préparation technique doit être distinguée de la disponibilité commerciale.

Les versions, schémas, pilotes et conditions d’accès évoluent ; ils doivent être confirmés dans la documentation officielle avant toute intégration.

Ce que change un acheteur logiciel

Un visiteur humain peut interpréter une page imparfaite, ouvrir plusieurs onglets, comprendre une promotion ambiguë ou appeler le support. Un agent a besoin de contrats plus explicites :

• identifiants stables ;
• attributs structurés ;
• prix et disponibilité datés ;
• politiques lisibles ;
• étapes transactionnelles documentées ;
• erreurs typées ;
• actions réversibles ;
• preuve du consentement.

Le commerce agentique pousse donc l’e-commerce vers une architecture plus API-first. Il ne remplace pas le site : il crée une surface supplémentaire qui doit partager la même vérité produit et transactionnelle.

UCP en quelques mots

UCP décrit des capacités du cycle d’achat et permet à un marchand de publier un profil indiquant les versions et fonctions prises en charge. Dans l’intégration documentée par Google, ce profil est exposé à une adresse bien connue, puis des API peuvent gérer découverte, checkout et autres étapes selon le mode choisi.

Le principe important n’est pas seulement le format. Il s’agit de séparer :

• la surface où l’utilisateur exprime son besoin ;
• l’agent qui orchestre ;
• le serveur marchand qui reste maître de ses règles ;
• les prestataires d’identité et de paiement ;
• les systèmes de commande et d’exécution.

Le marchand conserve la responsabilité de ses prix, politiques, commandes et relation client selon le modèle d’intégration.

Commencer par la vérité produit

Un agent ne peut pas recommander correctement un article dont les données sont pauvres. Le socle est le PIM, le catalogue ou la base produit :

• identifiant global et SKU ;
• variantes ;
• attributs normalisés ;
• compatibilités ;
• images ;
• disponibilité ;
• prix ;
• promotions ;
• restrictions ;
• délais ;
• vendeurs si marketplace ;
• conditions de retour.

Les descriptions marketing ne suffisent pas. Les critères discriminants doivent être structurés : dimensions, matière, usage, consommation, taille, normes, pièces compatibles ou zone de livraison.

La fraîcheur est essentielle. Une donnée extraite la veille peut être fausse au moment du checkout.

Les neuf capacités à rendre explicites

1. Découverte

Rechercher et filtrer avec des critères métier, pas seulement des mots-clés. Le résultat précise la correspondance, les variantes et les limites.

2. Prix

Calculer un prix déterministe selon devise, client, quantité, promotion, taxe et date. L’agent doit connaître la durée de validité.

3. Stock

Distinguer information de disponibilité et réservation. Les conflits concurrents doivent produire une erreur exploitable.

4. Livraison

Calculer options, délais, coûts, points relais, restrictions et empreinte si disponible, à partir d’une adresse validée.

5. Identité

Gérer invité, compte existant, consentements, fidélité et préférences sans exposer plus de données que nécessaire.

6. Checkout

Créer une session versionnée contenant lignes, prix, taxes, livraison, politiques et expiration. Toute modification doit être visible.

7. Paiement

Utiliser tokenisation, authentification et confirmation adaptées. L’agent ne reçoit pas des données de carte brutes.

8. Commande

Confirmer une seule fois, fournir un identifiant, exposer le statut et gérer annulation ou modification selon les règles.

9. Après-vente

Rendre accessibles support, retours, remboursement, garantie, litige et preuve d’achat.

Concevoir un checkout idempotent

Les agents et réseaux peuvent réessayer. Une requête répétée ne doit pas créer deux commandes. Chaque opération d’écriture utilise une clé d’idempotence, une version de session et un état explicite.

Exemple de cycle :

1. création de session ;
2. ajout ou validation des lignes ;
3. calcul du prix ;
4. sélection de livraison ;
5. confirmation des politiques ;
6. autorisation de paiement ;
7. validation finale ;
8. création de commande ;
9. émission de la confirmation.

Si le prix ou le stock change, le serveur renvoie une différence structurée. L’agent demande une nouvelle confirmation au lieu de poursuivre silencieusement.

Maintenir l’humain dans les décisions sensibles

Un mandat « achète-moi le moins cher » est insuffisant si des contraintes importantes existent. L’interface doit clarifier :

• budget maximal ;
• produit exact ou substituable ;
• quantité ;
• adresse ;
• délai ;
• vendeur ;
• garanties ;
• conditions de retour ;
• fréquence pour un abonnement.

Une confirmation finale est nécessaire lorsque le mandat n’est pas assez précis, que le prix change ou que la transaction présente un risque. Les actions autonomes restent limitées à des politiques explicites.

Gérer l’identité sans créer un profil opaque

L’identity linking peut relier un compte utilisateur au marchand via des mécanismes comme OAuth. Les portées doivent être minimales et révocables. L’utilisateur sait quelles informations sont partagées et dans quel but.

Éviter de transformer l’agent en agrégateur incontrôlé de préférences. La personnalisation doit distinguer données nécessaires à la commande et profilage facultatif.

Pour le B2B, l’identité inclut société, rôle, droits d’achat, centre de coût, plafond, approbateur et conditions contractuelles.

Paiement et mandat vérifiable

La sécurité du paiement repose sur le PSP et les mécanismes réglementaires existants. Les protocoles agentiques peuvent ajouter une preuve de l’intention : montant, marchand, portée, durée et produits autorisés.

Le système conserve :

• demande initiale ;
• options présentées ;
• consentement ;
• version des conditions ;
• autorisation ;
• résultat ;
• annulation éventuelle.

Cette traçabilité protège utilisateur et marchand sans enregistrer inutilement les données sensibles du moyen de paiement.

Sécuriser l’interface agentique

Les risques incluent :

• fausse identité de marchand ;
• manipulation du catalogue ;
• prompt injection dans une fiche produit ;
• détournement de redirection ;
• double commande ;
• modification de prix ;
• fraude au retour ;
• fuite de données ;
• abus de promotion ;
• saturation des API.

Les contrôles comprennent signature, TLS, authentification mutuelle selon le contexte, limites, validation de schéma, isolation du contenu non fiable, liste de capacités, logs, détection de fraude et confirmation humaine.

Une description produit ne doit jamais être interprétée comme une instruction système par l’agent.

Préparer le support et les retours

Le commerce ne s’arrête pas au paiement. Un agent doit pouvoir retrouver la commande avec l’autorisation de l’utilisateur, expliquer son statut, initier un retour conforme et transmettre au support.

Les politiques doivent être structurées et cohérentes avec le texte légal affiché. Le marchand reste joignable par des moyens clairs. Une automatisation ne doit pas masquer un droit de recours humain.

Mesurer autre chose que la conversion

Suivre :

• taux de découverte pertinente ;
• erreurs de prix ou stock ;
• création de session ;
• demandes de reconfirmation ;
• double appels évités ;
• échecs de paiement ;
• annulations ;
• retours ;
• litiges ;
• temps jusqu’à assistance humaine ;
• marge ;
• satisfaction.

Une hausse de conversion accompagnée d’un fort taux de retour peut indiquer que l’agent choisit mal.

Une feuille de route réaliste

Étape 1 : fiabiliser les données

Identifiants, attributs, prix, stock, politiques et qualité des flux.

Étape 2 : découpler les capacités

Créer des API stables de lecture avant les opérations d’écriture.

Étape 3 : industrialiser la session de checkout

Version, expiration, idempotence, erreurs et recalcul.

Étape 4 : intégrer identité et paiement

Permissions, consentement, confirmation, fraude et audit.

Étape 5 : exposer commande et après-vente

Statuts, support, retours et réversibilité.

Étape 6 : ajouter un protocole

Implémenter UCP ou une autre interface lorsque le canal et les conditions le justifient, sans coupler le cœur métier à une seule surface.

Une préparation utile même sans canal immédiat

La mise à niveau requise pour le commerce agentique améliore déjà le site, les applications, les marketplaces et les partenaires : catalogue propre, prix déterministe, checkout robuste, APIs idempotentes et service client connecté.

Partitech peut auditer le catalogue et le tunnel, concevoir les APIs, intégrer les systèmes de paiement et de commande, puis ajouter les interfaces agentiques. L’objectif est de rendre le commerce interprétable et sûr pour de nouveaux canaux sans perdre le contrôle de la transaction ni de la relation client.

Parlons de votre projet

Évaluer la préparation de votre plateforme e-commerce au commerce agentique avec Partitech. Contactez Partitech.