E-commerce
29 juin 2026
Le client se connecte, ouvre le widget : « Où en est ma commande ? » Le bot répond sans demander l'e-mail. Parfait. Puis il enchaîne : « Vous avez aussi acheté le sérum anti-âge en mars, voulez-vous le réassort ? » Le client ferme l'onglet. L'historique d'achat a résolu le WISMO et détruit la confiance en une phrase.
Shopify estime que 80 % des consommateurs achètent davantage chez une marque qui personnalise l'expérience, notamment via l'historique pour les clients connectés (Shopify, AI personal shopper 2026). ButtonBlock : l'historique d'achat reste l'une des données les plus acceptées (45 %), si elle sert la demande en cours (ButtonBlock, creep factor 2026).
Ce guide #258 traite le chatbot IA et historique d'achat : recommander, assister, respecter la confiance. Complète policy support (#257) avec l'automation bot : flows, whitelist, messages et handoff.
Sommaire
Pourquoi le bot IA doit-il lire l'historique d'achat ?
Un chatbot historique achat sans données client repose les mêmes questions qu'un bot générique. Avec historique, il résout, route et recommande dans le bon contexte.
Gains mesurables
WISMO : lookup commande sans re-saisie e-mail
Replenishment : même SKU, bon intervalle
Repeat SAV : continuité ticket précédent
Reco contextuelle : complément à achat passé
Routing VIP : tag silencieux, escalade rapide
Risque confiance
Heeya rappelle que la personnalisation 2026 repose sur les données first-party (historique, chat, préférences déclarées), plus robustes que les cookies tiers (Heeya, parcours 2026). Même base légale, perception différente : utile vs surveillance.
Exemple DTC compléments alimentaires
Bot sans règles : cite 4 commandes passées en intro WISMO. Taux abandon conversation 38 %. Bot need-to-know (#257 appliqué au bot) : une commande citée, reco refill seulement si demandée. Abandon 11 %, conversion reco refill +19 %.
En quoi diffère-t-il des guides personnalisation voisins ?
Six contenus, six rôles dans l'écosystème historique.
Policy support (#257)
Historique SAV (#257) : test creepy, macros HISTORY agents. Le #258 automatise ces règles côté bot.
Données Shopify (#20)
Bot Shopify (#20) : quels champs API lire. Le #258 : flows et whitelist par intent historique.
Cross-sell (#152)
Cross-sell (#152) : complément panier session. Le #258 : reco depuis achats passés, pas seulement panier courant.
Routine / refill
Reco routine : intervalles consommables. Le #258 : cadre global auth + limites confiance. Le timing proactif reorder : bot réachat (#310).
Clients récurrents (#206)
Récurrents (#206) : ton fidèle humain. Le #258 : segments bot repeat_loyal sans verbaliser LTV.
Audit conversations (#259)
Audit mensuel (#259) : rituel qualitatif voix client. Le #258 fournit les tags bot à auditer (history_exposed, history_reco_declined).
Quelles données historique le bot lit-il vs expose-t-il ?
La matrice bot historique duplique la logique #257 en trois colonnes : lire, utiliser en interne, citer au client.
Lire (API Shopify / Gorgias)
orders_count, last_order_date, tags VIP/subscriber
5 dernières commandes : #, statut, line items, tracking
Tickets support 90 j, metafields taille_habituelle
Return rate interne, notes fraude (jamais exposées)
Utiliser en interne (routing, handoff)
Route VIP si tag + intent urgent
Skip questions déjà répondues ticket open
Package handoff : 3 commandes + tickets récents
Filtrer reco : exclure SKU retourné 2×
Citer au client (whitelist)
Commande liée au ticket : #, statut, tracking
SKU pertinent au problème ou à la demande refill
Continuité : « votre demande du [date] concernant [sujet] »
Insider One : les bots contextualisés s'appuient sur historique et panier pour reconnaître un VIP et référencer la dernière commande (Insider One, CDP chatbot 2026).
Comment authentifier le client avant lookup historique ?
L'auth bot historique est non négociable. Sans identité vérifiée, le bot ne cite aucune commande.
Trois niveaux auth
Session Shopify logged-in : customer_id token, lookup direct
E-mail + code OTP : widget chat, lien magique ou 6 chiffres
N° commande + e-mail : lookup ponctuel, scope limité à cette commande
Visiteur anonyme
Bot répond depuis KB catalogue et politiques. Pas de « nous voyons que vous avez commandé... ». Proposer auth : « Pour consulter votre commande, indiquez votre e-mail. » Aligner auth support (#122).
Macro bot PRIVACY-HIST-01
Si question « comment me connaissez-vous ? » : « Je consulte votre historique commandes sur [marque] pour traiter votre demande. Ces données ne sont pas utilisées à des fins publicitaires via ce chat. Politique : [lien]. » Reprend HISTORY-PRIVACY-01 du #257.
Edge case cadeau
Commande expédiée à adresse différente : ne pas inférer taille ou préférences depuis un achat cadeau. Demander « est-ce pour vous ? » avant reco historique.
Quels flows bot par intent historique ?
Cinq flows bot historique achat couvrent 90 % des cas DTC.
Flow WISMO-HIST-01
Auth → lookup dernière commande unfulfilled ou commande citée par client
Réponse : #, statut, tracking (1 commande max)
Si plusieurs open : « Laquelle concerne votre message ? » liste 3 max
Escalade si statut bloqué > SLA
Flow REPEAT-SAV-01
Ticket open détecté → « Je reprends votre demande #[ref] du [date]. Statut actuel : [1 ligne]. » Pas de dump historique complet.
Flow REFILL-01
Intent « je veux recommander » ou « même produit » → lookup dernier SKU consommable → proposer même variant + lien PDP. Uniquement si client demande. Voir reco routine.
Flow RECO-COMPLEMENT-01
Post-achat J+7 ou question usage → complément à SKU acheté (metafield cross_sell_primary). Règles timing #152. Max 1 reco par session.
Flow VIP-ROUTE-01
Tag VIP + intent litige ou panier > seuil → escalade silencieuse, message client : « Je vous mets en relation avec un conseiller prioritaire. » Sans mentionner montant dépensé.
Comment configurer la whitelist need-to-know ?
Le need-to-know filter bot est la barrière technique entre données lues et phrases envoyées.
Config type (JSON policy)
exposed_fields : order_number, fulfillment_status, tracking_url, line_item_title (ticket scope), last_contact_date. forbidden_fields : total_spent, orders_count verbalisé, return_rate, browsing_events, cart_abandoned, internal_notes.
Règles par intent
wismo : exposed = statut + tracking uniquement
return : + SKU + taille commande concernée
refill : + dernier SKU consommable si demandé
reco : + 1 SKU complément, jamais liste achats
litige : handoff riche, message client minimal
Test regression (10 scénarios)
Pour chaque intent : simuler client repeat avec 5 commandes. Vérifier que la réponse bot ne contient jamais LTV, count orders, ou produits non liés. Logger history_fields_exposed pour audit #259.
Sync Shopify metafields
Bot lit skin_type, size_usual seulement si intent sizing ou refill. Ignorer si metafield vide. Voir #20 pour mapping champs.
Quelles recommandations depuis historique sans effet creepy ?
Les reco bot historique suivent des règles de timing aussi strictes que le cross-sell session (#152).
Moments autorisés
Client demande refill ou « même produit »
Question usage post-achat (« comment entretenir ? »)
Complément fonctionnel lié au SKU acheté (cross_sell_primary)
Fin résolution SAV positive (1 reco max, soft)
Moments interdits
Premier message WISMO (résoudre d'abord)
Ticket litige colis abîmé, remboursement en cours
Visiteur anonyme sans auth
« Clients comme vous ont aussi acheté... » sans contexte
Formulation reco acceptable
« Vous aviez commandé [SKU] il y a [X] semaines. Souhaitez-vous le même ? » vs interdit : « Nous savons que vous aimez le bleu et achetez le soir. »
Limite session
1 reco proactive depuis historique par conversation. Refus = « Très bien, je reste disponible. » Sans relance. AnswerLab : reconnaissance = résolution rapide, pas liste d'achats (AnswerLab, recognition gap).
Quels messages bot prêts à coller par scénario ?
Huit templates bot historique à importer dans votre base instructions.
WISMO authentifié
« Bonjour [Prénom], commande #[X] du [date] : [statut]. Suivi : [lien]. Autre question sur cette commande ? »
Multi-commandes
« J'ai trouvé 3 commandes récentes. Laquelle concerne votre message ? 1) #[A] [date] 2) #[B] [date] 3) #[C] [date] »
Continuité ticket
« Je reprends votre demande ouverte depuis le [date] concernant [sujet]. Voici l'avancement : [1 ligne]. »
Refill demandé
« Votre dernière commande de [SKU] date du [date]. Voici le lien pour recommander : [PDP]. Même format ? »
Complément post-usage
« Pour [produit acheté], beaucoup de clients ajoutent [complément] pour [bénéfice 8 mots]. Souhaitez-vous voir le compatible ? »
Refus gracieux reco
« Pas de souci. Je reste disponible pour votre commande ou d'autres questions. »
Auth requise
« Pour accéder à votre historique commande en toute sécurité, indiquez l'e-mail utilisé à la caisse. Je vous envoie un code de vérification. »
Escalade VIP
« Je vous mets en relation avec un conseiller qui reprendra votre dossier complet. Délai estimé : [X] min. »
Comment structurer le handoff agent avec historique ?
Le handoff historique bot transmet tout à l'agent, presque rien au client dans le message de transition.
Package handoff (interne)
3 dernières commandes : #, statut, SKU, montant (agent only)
Tickets 90 j : sujet, statut, agent assigné
Tags : VIP, subscriber, high_return_internal
Transcript bot : intents, champs exposés, reco refusées
Metafields : taille, profil peau si pertinent
Message client handoff
« Un conseiller reprend votre dossier. Référence : #[ticket]. Vous serez contacté sous [SLA]. » Pas de récapitulatif achats dans le message client.
Engaige benchmark
Les agents e-commerce 2026 résolvent en agissant dans les systèmes (refund, exchange, edit abo), pas en relisant l'historique au client (Engaige, agents e-commerce 2026). Handoff = contexte agent, pas script client.
Détails workflow : transfert contexte (#155). Doublons : #256.
Quels anti-patterns bot historique éviter ?
Sept erreurs bot historique génèrent plaintes et churn.
Dump historique au hello
« Bonjour, vous avez 12 commandes... » Fix : auth puis intent.
Reco en plein litige
Colis perdu + suggestion nouveauté. Fix : résoudre, reco seulement si CSAT OK.
Citation sans auth
Cookie session expirée, bot cite quand même. Fix : re-auth obligatoire.
Cross-sell agressif repeat
« Vous achetez souvent, voici 5 produits. » Fix : 1 reco, need-to-know.
Mélange browsing + achats
« Vous avez consulté X puis acheté Y. » Fix : achats only, pas navigation.
LTV ou count orders verbalisé
Fix : VIP routing silencieux (#257 HISTORY-VIP-01).
Ignorer refus reco
Relancer même SKU. Fix : tag history_reco_declined, bloquer session.
Comment Qstomy gère-t-il historique achat et confiance ?
Qstomy applique la policy #257 en automation : lookup riche, exposition minimale, handoff complet.
Fonctionnalités historique bot
Auth gate Shopify : session + OTP e-mail
Need-to-know engine : whitelist par intent
5 flows HIST : WISMO, repeat SAV, refill, complement, VIP
Reco throttle : 1 proactive / session, respect refus
Handoff package : timeline agent, message client court
Privacy template : PRIVACY-HIST-01 auto si question
Audit tags : history_exposed, history_reco_declined
Scénario DTC chiffré
Marque skincare, 800 conv bot/semaine, 58 % clients repeat. Bot legacy « full history » : plaintes creepy 3,8 %, CSAT bot 3,7, conversion reco 8 %. Qstomy need-to-know + flows section 5 : plaintes 0,5 %, CSAT 4,5, FCR WISMO +22 pts, conversion refill 21 %, escalades inutiles −28 %.
Déploiement 10 jours
J1-2 : connect Shopify, définir whitelist. J3-5 : activer flows WISMO + refill. J6-8 : test 50 convos repeat. J9-10 : reco complement post-SAV, mesure KPI.
Explorez intégration Shopify, support client IA, agent vente, demander une démo.
Quels playbooks déployer en 3 semaines ?
Playbook 1 : matrice données (3 h, semaine 1)
Remplir section 3 avec votre stack. Valider avec legal : champs exposables. Exporter JSON policy need-to-know section 6.
Playbook 2 : auth + flows WISMO (4 h)
Configurer auth #122. Activer WISMO-HIST-01 et REPEAT-SAV-01. Test 20 scénarios : logged-in, OTP, anonyme.
Playbook 3 : templates section 8 (2 h)
Importer 8 messages. Revue tone of voice. Interdire formulations section 7.
Playbook 4 : reco refill + complement (1 semaine)
Activer REFILL-01 et RECO-COMPLEMENT-01 sur 10 SKU pilotes. Metafields cross_sell_primary. Cap 1 reco/session.
Playbook 5 : handoff riche (2 h)
Package section 9. Brief agents : « le client n'a pas vu ce que vous voyez ». Test 10 escalades bot → humain.
Playbook 6 : mesure S+30 (2 h)
KPI : plaintes creepy, FCR WISMO, conversion refill, abandon post-reco. Préparer audit #259 sur tags history_*. Ajuster whitelist si plainte > 1 %.
Maillage utile
Un chatbot qui lit l'historique d'achat sans filtre est un vendeur bavard avec accès à votre dossier client. Avec auth, whitelist et flows par intent, il devient un assistant qui sait quand parler et quand se taire. La confiance se gagne en résolvant vite, pas en prouvant que vous savez tout.
Enzo
29 juin 2026
