E-commerce13 minutes de lecture

Commerce agentique : préparer son e-commerce sans parier sur un protocole

Préparez votre e-commerce aux agents IA avec une grille concrète : catalogue, prix, stock, règles, permissions, preuves et solution de repli.

Catalogue e-commerce structuré en modules vérifiés avant le passage contrôlé d’un agent d’achat

Le commerce agentique désigne un parcours dans lequel un agent d’intelligence artificielle recherche, compare et peut, à terme, exécuter tout ou partie d’un achat pour une personne. En France, l’achat entièrement agentique n’était pas encore disponible lors de l’avis publié par l’Autorité de la concurrence le 17 juillet 2026. Des agents peuvent déjà recommander des produits, mais recommander n’est pas commander.

La bonne préparation ne consiste donc pas à greffer immédiatement un chatbot ou à choisir le protocole qui gagnera. Elle consiste à rendre le catalogue, les prix, les stocks, la livraison, les retours et les preuves assez cohérents pour être compris par une machine sans dégrader le contrôle humain. Ce travail améliore déjà le SEO du catalogue, l’expérience d’achat et l’exploitation de la boutique. Le reste doit attendre un usage démontré.

Ce que le commerce agentique change — et ce qu’il ne change pas

Un parcours e-commerce classique place l’interface du marchand au centre : une personne parcourt une catégorie, ouvre une fiche, compare, ajoute au panier puis paie. Un agent peut déplacer une partie de ces décisions hors du site. Il reçoit une contrainte, consulte plusieurs sources, sélectionne des options et présente une recommandation. Dans un scénario plus avancé, il pourrait aussi préparer ou confirmer la transaction selon les permissions reçues.

Ce déplacement ne rend pas le site inutile. Il augmente au contraire l’exigence de cohérence entre ce que voient la personne, le moteur de recherche, le flux marchand, l’agent et le système de commande. Un prix différent entre la page et la caisse n’est plus seulement une friction d’interface : c’est une donnée impossible à utiliser sans risque.

L’Autorité de la concurrence distingue le commerce conversationnel déjà observable — découvrir et obtenir des recommandations — de l’automatisation complète de l’achat, encore indisponible en France au moment de son avis. Elle alerte aussi sur l’opacité du choix, le verrouillage et la gouvernance des standards.

La première décision est donc simple : préparer les fondations réversibles, différer l’intégration spéculative.

Distinguer découverte, recommandation et transaction

Ces trois niveaux sont souvent présentés comme une même révolution. Ils n’exigent pourtant ni les mêmes données, ni les mêmes garanties.

Niveau Question posée au système Preuve minimale du marchand Risque si elle manque
Découverte « Quels produits correspondent à cette catégorie ou à ce besoin ? » identité stable, catégorie, attributs, disponibilité et URL cohérente produit absent, mal classé ou confondu avec une variante
Recommandation « Quelle option convient à ces contraintes ? » compatibilités, limites, prix total, délai, livraison, retours et sources à jour comparaison trompeuse ou recommandation impossible à justifier
Transaction « Puis-je acheter cette option selon les règles autorisées ? » identité, permission, montant final, stock réservé, confirmation, journal et annulation action non voulue, double commande, prix erroné ou reprise impossible

Une boutique peut être prête pour la découverte sans l’être pour la recommandation. Elle peut permettre une recommandation fiable sans devoir ouvrir la transaction à un agent. Cette progression protège l’investissement : chaque niveau doit payer son loyer avant d’ajouter le suivant.

La matrice de préparation en six preuves

Pour chaque famille de produits prioritaire, documentez la chaîne offre → vérité → règle → action → preuve → repli. Elle constitue le cœur de l’audit Zence pour le commerce agentique.

Objet Offre visible Vérité responsable Règle explicite Action autorisée Preuve conservée Repli prévu
Produit nom, variante, image, description PIM, ERP ou catalogue maître identifiant et attributs obligatoires consulter et comparer version et date de synchronisation fiche humaine accessible
Prix montant, devise, remise moteur de prix ou ERP taxes, durée, segment et quantité calculer un total détail du prix appliqué validation dans la caisse
Stock état et délai ERP ou gestion d’entrepôt réservation, rupture, précommande vérifier ou réserver réponse horodatée alternative ou attente explicite
Compatibilité usages, dimensions, dépendances référentiel produit validé conditions et exclusions filtrer ou proposer critères utilisés transfert vers une personne compétente
Livraison et retours zones, coût, délai, conditions OMS, transporteurs et politique commerciale règles par destination et produit simuler puis sélectionner option choisie et conditions rendues parcours classique modifiable
Commande panier, identité, paiement, confirmation plateforme e-commerce seuils, permissions et contrôle final préparer ou exécuter selon mandat journal, reçu et identifiant annulation, support et reprise manuelle

Le tableau n’oblige pas à centraliser toutes les données dans un nouvel outil. Il oblige à nommer la source de vérité, la règle et le responsable. Si deux systèmes revendiquent le même prix ou le même stock, l’agent n’est pas le premier chantier. L’arbitrage des données l’est.

Commencer par une famille représentative

N’auditez pas dix mille références à plat. Choisissez une famille qui réunit des variantes, une règle de compatibilité, une promotion, plusieurs modes de livraison et au moins un retour récent. Cette famille doit traverser tout le système, de la source produit à la confirmation de commande.

Le test est assez petit pour être corrigé, mais assez complet pour révéler les ruptures de synchronisation, les règles implicites et les décisions impossibles à expliquer. C’est plus instructif qu’un démonstrateur branché sur cinq produits parfaitement préparés.

Attribuer chaque décision avant de l’automatiser

Une source de vérité ne devient fiable que si une personne ou une équipe peut répondre de sa qualité. Le PIM peut contenir les attributs produit sans décider du prix. L’ERP peut connaître le stock comptable sans refléter une réservation en cours. La plateforme e-commerce peut calculer le total sans être autorisée à modifier une règle commerciale. Documentez donc la responsabilité au niveau de la décision, pas seulement du logiciel.

Le responsable du catalogue valide l’identité, les variantes et les compatibilités. Les opérations répondent du stock réellement vendable et des délais. Le commerce arbitre le prix, les remises et les conditions de compte. Le service client rend les règles de livraison, de retour et d’annulation compréhensibles. L’équipe technique protège les interfaces, les permissions, les journaux et la reprise. Une compétence juridique appropriée intervient lorsque le mandat, le paiement, les données personnelles ou l’information du consommateur exigent une validation spécifique.

Cette répartition n’ajoute pas une réunion à chaque commande. Elle définit qui tranche lorsqu’un système rencontre une contradiction. L’agent peut alors s’arrêter avec un motif exploitable au lieu d’inventer une réponse ou de choisir silencieusement la donnée la plus récente.

Conservez pour chaque règle : son propriétaire, sa date d’effet, ses systèmes consommateurs, sa méthode de test et son comportement par défaut. Lorsqu’une remise expire ou qu’un transporteur devient indisponible, l’équipe sait ce qui doit changer, où vérifier la propagation et quand réautoriser l’action. Cette discipline améliore la boutique même si aucun agent ne passe jamais commande.

Quelles données produit fiabiliser en premier ?

Les besoins ne commencent pas avec les agents IA. Google demande déjà une cohérence entre la page produit, les données structurées, le flux Merchant Center et la caisse. Sa spécification des données produit insiste notamment sur le prix, la devise et la disponibilité exacts. Sa documentation sur les données structurées de marchand couvre aussi les informations de livraison et de retour.

Pour une première famille, vérifiez au minimum :

  1. Une identité stable. SKU, GTIN ou référence fabricant lorsque ces identifiants existent, groupe de variantes et URL ne changent pas au gré des exports.
  2. Des attributs comparables. Dimensions, matière, capacité, compatibilité et condition sont structurées plutôt qu’enfouies dans un texte libre.
  3. Un prix explicable. Devise, taxes, remise, quantité minimale et éventuelles conditions client conduisent au même total sur tous les canaux concernés.
  4. Un stock frais. La disponibilité affichée, le flux et la caisse ne se contredisent pas ; le délai de mise à jour est connu.
  5. Des conditions opérationnelles. Livraison, retour, garantie, installation ou restriction géographique sont accessibles et reliés au produit.
  6. Une limite lisible. Le produit indique aussi quand il ne convient pas, ce qui réduit les recommandations séduisantes mais erronées.

Cette base sert déjà à une boutique humaine. Elle évite donc le principal piège du sujet : financer un chantier « IA-ready » qui ne produit aucune amélioration tant que les agents transactionnels ne sont pas disponibles.

Un exemple fictif : la pièce compatible mais non commandable

Prenons un distributeur fictif de pièces techniques. Son catalogue indique qu’un filtre convient à trois machines. Le PIM connaît la compatibilité, l’ERP détient le stock, le site affiche le prix public et le CRM conserve un tarif négocié pour certains comptes.

Un agent peut découvrir le filtre et le recommander. Il ne devrait pas encore l’acheter si le système ne sait pas :

  • identifier le compte autorisé ;
  • appliquer le bon prix contractuel ;
  • vérifier la machine exacte et sa version ;
  • respecter un plafond de commande ;
  • montrer les frais et le délai avant confirmation ;
  • produire un reçu et permettre une annulation.

La solution proportionnée n’est pas nécessairement une API de commande ouverte. Le premier périmètre peut générer une sélection argumentée et un panier préparé, puis laisser une personne vérifier et confirmer. L’agent réduit la recherche sans recevoir prématurément le droit d’engager la dépense.

Notre guide sur le cadrage des agents IA en entreprise détaille cette séparation entre lire, proposer, préparer et agir. Dans un e-commerce, ces verbes doivent devenir des permissions distinctes.

Ne pas choisir un protocole avant d’avoir défini le service

Les protocoles, connecteurs et plateformes évolueront. L’Autorité de la concurrence recommande des standards ouverts, transparents et interopérables afin d’éviter qu’un acteur dominant impose seul les conditions d’accès au commerce agentique. Pour un marchand, cette recommandation devient une règle d’architecture : garder les données et les décisions séparables de l’intégration choisie.

Avant tout raccordement, demandez :

  • quelles données le service lit et à quelle fréquence ;
  • quelles actions il peut déclencher ;
  • comment son identité et ses permissions sont contrôlées ;
  • qui peut modifier une règle de prix ou de livraison ;
  • quel journal permet de reconstruire une décision ;
  • comment couper le service sans arrêter la boutique ;
  • comment changer de fournisseur sans réécrire le catalogue.

La réversibilité cloud et SaaS s’applique ici : exporter les données ne suffit pas si les règles, les historiques et les procédures de reprise restent captifs.

Conserver un parcours humain complet

Une interface conversationnelle ne doit pas devenir une obligation. Une personne doit pouvoir consulter les informations importantes, modifier le panier, comprendre le total, choisir la livraison, confirmer l’achat et exercer ses droits sans dépendre d’un agent.

Cette continuité protège plusieurs situations : technologie d’assistance, connexion instable, produit sensible, compte partagé, erreur de recommandation ou indisponibilité du service tiers. Elle fournit aussi une référence de recette. Si l’équipe ne sait pas terminer et reprendre le parcours elle-même, elle ne saura pas contrôler ce que l’agent exécute.

La matrice d’accessibilité du parcours e-commerce et le guide sur la performance et la conversion restent donc valables. Le commerce agentique ajoute un canal et des permissions ; il n’efface ni l’acheteur, ni le service après-vente.

Tester douze scénarios avant toute transaction

Un parcours nominal ne suffit pas. Préparez des scénarios qui obligent le système à expliquer, arrêter ou reprendre l’action :

  1. produit disponible au prix public attendu ;
  2. variante incompatible avec la contrainte ;
  3. prix du flux différent du prix en caisse ;
  4. stock épuisé entre recommandation et confirmation ;
  5. promotion expirée ;
  6. adresse hors zone de livraison ;
  7. compte non autorisé à commander ;
  8. montant supérieur au plafond reçu ;
  9. agent indisponible après préparation du panier ;
  10. double demande de confirmation ;
  11. annulation ou retour après commande ;
  12. demande d’explication sur les critères de sélection.

Pour chaque scénario, conservez l’entrée, la règle appliquée, l’action, le résultat visible, le journal et la procédure de reprise. Une capture isolée n’est pas une preuve suffisante si le stock, le prix ou la permission ne peuvent pas être reconstruits.

Mesurer sans confondre nouveauté et valeur

La Fevad observe en 2026 une utilisation de l’IA surtout en amont de l’achat et une confiance plus faible au moment de payer. Cette étude décrit des usages déclarés ; elle ne prouve ni la disponibilité d’un achat entièrement automatisé en France, ni la rentabilité d’une intégration pour une boutique donnée.

Mesurez donc séparément :

  • découverte : produits trouvés, sources consultées et requêtes comprises ;
  • qualité de recommandation : compatibilité, disponibilité, correction et motifs de refus ;
  • progression : panier préparé, validation humaine et abandon ;
  • transaction : commande confirmée, erreur, annulation et double action ;
  • économie : marge, coût d’intégration, support, retours et temps de contrôle ;
  • confiance : explications demandées, corrections et usage du parcours humain.

Une hausse des recommandations ne justifie pas l’ouverture du paiement. Elle justifie l’étape suivante seulement si les recommandations sont exactes, utiles et assez traçables pour être contestées.

Le plan de préparation sur 90 jours

Jours 1 à 15 — Définir le niveau utile

Choisissez découverte, recommandation ou transaction. Listez une famille de produits, les personnes concernées, les systèmes, les responsabilités et une règle d’arrêt. Si la demande réelle concerne seulement la recherche interne, traitez ce problème sans rebaptiser le projet.

Jours 16 à 35 — Établir la vérité du catalogue

Remplissez la matrice en six preuves. Corrigez les identifiants, attributs, prix, stocks, conditions et responsabilités sur la famille choisie. Utilisez l’auto-audit du site pour vérifier aussi les fondations visibles avant d’élargir le diagnostic.

Jours 36 à 60 — Tester sans droit d’achat

Évaluez la découverte et la recommandation sur des demandes réelles anonymisées. Comparez les résultats à une décision humaine, notez les erreurs et empêchez toute écriture. Le but est d’apprendre où les données et les règles échouent.

Jours 61 à 90 — Préparer une action réversible

Si les preuves sont suffisantes, testez un panier préparé ou une réservation limitée. Ajoutez identité dédiée, permissions minimales, confirmation, journal, plafond et repli manuel. N’ouvrez le paiement que si cette étape répond à un usage, à une responsabilité et à une mesure explicites.

Faut-il préparer son e-commerce maintenant ?

Oui, si « préparer » signifie fiabiliser les données, rendre les règles explicites, préserver l’interopérabilité et tester le contrôle. Ces travaux améliorent déjà le SEO, la conversion, les flux marchands et les opérations.

Non, si « préparer » signifie acheter dans l’urgence une couche agentique, exposer une API générique ou reconstruire la boutique autour d’un protocole encore mouvant. L’adoption de l’IA dans le commerce reste progressive : la Direction générale des Entreprises recommande de partir d’un besoin concret et rappelle que la qualité comme la structuration des données sont des prérequis.

Zence conçoit et fait évoluer des systèmes e-commerce reliés au catalogue, au paiement, aux opérations et à la maintenance. La première livraison utile peut être un audit de vérité du catalogue, une règle de synchronisation ou un pilote en lecture seule. Elle n’a pas besoin de simuler un futur déjà certain.

Sources principales

Écrit et relu par

Équipe ZenceThomas et Bastien croisent architecture logicielle, stratégie produit, design et opérations pour transformer des sujets complexes en produits numériques clairs et durables.