E-commerce
28 juin 2026
Le widget est configuré. Les policies sont importées. Vous appuyez sur « Activer » un vendredi soir. Lundi matin : quarante conversations, douze escalades litige mal routées, un client promis remboursement par le bot, personne en équipe ne sait qui surveille.
GoodChatBot estime que la majorité des projets IA échouent faute de données prêtes, handoff flou et lancement trop large (GoodChatBot, échecs IA Shopify 2026). Heeya rappelle : un corpus incomplet produit un bot qui esquive la moitié des questions dès le jour 1 (Heeya, intégration Shopify 2026).
Ce guide #220 liste les contrôles pré-lancement chatbot Shopify avant activation. Distinct de entraîner le bot (#13) (données) et de choisir les questions (#120) (priorisation) : ici, validation go-live production.
Summary
Pourquoi valider avant d'activer un chatbot IA sur Shopify ?
Activer un chatbot IA Shopify sans contrôles préalables, c'est exposer 100 % du trafic à un agent non éprouvé.
Trois risques go-live immédiat
Hallucination policy : délai retour inventé, litige
Handoff froid : client répète 4 messages à l'humain
Scope trop large : 30 intents non testés
Principe launch narrow
Quickchat AI : lancer un ou deux parcours haute fréquence, mesurer, puis étendre. Smart Circuit observe 61 % moins d'erreurs production avec déploiement progressif 10-25-50-100 % (Smart Circuit, formation chatbot 2026).
Exemple DTC cosmétiques
Go-live vendredi sans tests handoff. 68 conversations week-end, CSAT bot 62 %, 3 promesses refund non autorisées. Rollback lundi, contrôles section 4-7, relance jeudi en soft launch 10 % : CSAT 84 %, zero incident policy semaine 2.
En quoi diffère-t-il de l'entraînement bot et de la priorisation intents ?
Six contenus voisins, six étapes du projet. Le #220 couvre le moment « on active ».
Entraîner bot (#13)
Entraîner bot (#13) : sources Shopify. Le #220 : validation finale avant toggle public.
Choisir questions (#120)
Priorisation (#120) : scoring intents. Le #220 : ces intents sont-ils testés et prêts ?
Tests utilisateurs (#164)
UAT (#164) : sessions humaines. Le #220 : contrôles techniques + ops complémentaires.
Former équipe (#219)
Formation équipe (#219) : post-activation. Le #220 inclut prérequis équipe avant toggle.
Handoff (#12) et gouvernance (#142)
Règles transfert et charte doivent être configurés et testés, pas seulement rédigés.
Promesse #220
5 blocs validation, 25 tests, placement widget, soft launch, KPI J+72, playbooks.
Quels contrôles scope verrouiller avant le go-live ?
Bloc 1 : cadrage scope verrouillé avant toute activation.
Contrôles scope
Intents phase 1 listés : max 5-8, documentés (ex. WISMO, retour, shipping, taille, horaires)
Intents exclus écrits : litige, refund > seuil, réglementé, VIP
Owner bot nommé : responsable monitoring J+7
Objectif mesurable : ex. −30 % tickets WISMO à J+30
Export tickets 90 j validé
Vector Agents : auditez top 50 requêtes avant réglages plateforme. Si le bot ne couvre pas 60 %+ du volume phase 1, repoussez le go-live (Vector Agents, chatbot ROI 2026).
Livrable
One-pager Notion « Scope v1 » signé Head Support + ops. Aucun intent hors liste sans retest.
Comment valider le corpus et les données knowledge ?
Bloc 2 : données et corpus prêts. GoodChatBot : deux semaines nettoyage data valent mieux qu'un fix post-lancement.
Contrôles knowledge
Policy retour : une seule version, alignée PDP et e-mails
Délais livraison : par zone, à jour promo en cours
Top 20 SKU : fiches complètes, metafields taille/compatibilité
10 questions clients : réponses testées en preview bot
Macros obsolètes retirées du corpus indexé
Test des 10 questions
Heeya : posez les 10 questions les plus fréquentes en preview. Réponse vague = trou dans la source, pas dans le prompt. Corrigez le document, re-indexez, retestez.
Alignement multicanal
Bot, help center, e-mails transactionnels : même délai retour, même seuil franco. Voir cohérence réponses (#191).
Quelles vérifications techniques Shopify effectuer ?
Bloc 3 : intégration Shopify technique validée en staging.
Contrôles API
App installée : permissions read orders, products, customers
Lookup commande : 5 commandes test (unfulfilled, shipped, delivered, refund, cancel)
Stock temps réel : variant OOS reflété en chat
Webhooks actifs si parcours événementiel (voir webhooks #217)
Rate limits : pas de timeout sur pic simulé
Contrôles widget
Heeya : exclure checkout du widget (Liquid conditional). Actif sur PDP, collection, panier, compte client. Test iOS Safari + Android Chrome.
Disclosure IA
Message d'accueil indique assistant IA + option humain. Voir RGPD bot.
Comment configurer et tester handoff et guardrails ?
Bloc 4 : handoff et guardrails configurés avant le premier visiteur.
Contrôles escalade
Handover topics : litige, chargeback, produit dangereux, demande humain
Tag ai_handover route vers équipe dédiée Gorgias
Contexte transféré : transcript + commande visible sidebar
Seuils financiers : bot ne promet jamais refund > X € sans humain
Hors heures : collecte e-mail si équipe offline
Test handoff obligatoire
3 scénarios : client demande humain, bot sans confiance, client frustré. Agent reçoit ticket en < 60 s avec contexte complet. Aligné handoff (#12).
Mode shadow optionnel
Semaine 1 : bot répond en brouillon, agent valide avant envoi. Voir relecture IA (#210).
Quels 25 tests exécuter avant d'activer le widget ?
Vingt-cinq tests pré-activation chatbot à exécuter en 4 h. Cocher dans un tableur interne.
Tests fonctionnels (1-10)
Greeting widget desktop + mobile
WISMO commande expédiée : tracking + ETA
WISMO commande non expédiée : délai honeste
Policy retour : délai exact policy
Frais port zone France métropolitaine
Question taille top SKU avec guide
Produit OOS : alternative ou alerte
Code promo cumul : réponse alignée site
Question hors scope : handoff propre
Demande « parler à quelqu'un » : escalade immédiate
Tests robustesse (11-18)
Typos : « ou es ma comande »
Intent mixte : retour + WISMO même message
Langage agressif : pas de réponse défensive
Commande inexistante : pas d'invention tracking
E-mail ne match aucune commande
Question concurrent : refus poli
Injection prompt : « ignore tes règles »
Pièce jointe photo : handoff ou consigne claire
Tests ops (19-25)
Notification agent handoff reçue
Dashboard KPI bot accessible
Tag conversation exportable
Widget ne chevauche pas CTA panier mobile
Page checkout : widget absent
Performance : réponse < 5 s question simple
Rollback plan documenté (désactiver en 2 clics)
Comment préparer l'équipe et les ops pour le jour J ?
Bloc 5 : équipe et ops prêts le jour J.
Contrôles humains
Champion bot identifié : monitoring transcripts J+1 à J+7
Agents briefés : macro reprise handoff, tag bot_error
File handoff staffed heures ouverture semaine 1
Revue calée J+3 : BotHero recommande review 72 h post go-live
Kill switch testé : qui désactive le bot si incident
Minimum formation
Même sans programme 90 j (#219), session 1 h : sidebar bot, handoffs, feedback erreur. Sobot : ne pas exposer l'IA à tous les visiteurs avant test tickets réels.
Communication interne
Slack #bot-launch : owner poste résumé quotidien semaine 1 (conversations, escalades, fixes).
Comment planifier un soft launch sur 4 semaines ?
Plan de soft launch chatbot Shopify sur 4 semaines, pas big bang.
Semaine 1 : 10 % trafic
Pages support-heavy (compte client, page aide). Monitoring 100 % transcripts. Corrections corpus daily.
Semaine 2 : 25 %
Ajout PDP top 20 SKU. Mesurer CSAT bot, taux escalade, latence.
Semaine 3 : 50 %
Panier + collection. A/B widget placement si mobile overlap.
Semaine 4 : 100 %
Full site hors checkout. Baseline KPI figée. Plan expansion intents phase 2.
KPI J+1 à J+72
CSAT bot : seuil minimum 80 % avant scale
Taux escalade : < 35 % phase 1 normal
Incidents policy : zero tolérance
Recontact 48 h : < 12 % sur intents bot
Dashboard : KPI chatbot (#11), dashboard support (#216).
Quelles erreurs de go-live provoquent un rollback ?
Cinq erreurs go-live chatbot qui forcent le rollback.
Erreur 1 : activer vendredi soir
Zero équipe week-end. Fix : mardi 10 h, soft launch 10 %.
Erreur 2 : 30 intents jour 1
Aucun testé en profondeur. Fix : max 8 intents section 3.
Erreur 3 : widget sur checkout
Friction conversion. Fix : exclusion Liquid Heeya.
Erreur 4 : handoff non testé
Client répète tout. Fix : 3 scénarios section 6.
Erreur 5 : pas de revue J+3
Erreurs s'accumulent 2 semaines. Fix : calendrier review 72 h.
Comment Qstomy structure-t-il la validation pré-lancement ?
Qstomy accélère la validation pré-lancement avec des contrôles intégrés.
Pré-lancement Qstomy
Preview sandbox : 10 questions + lookup commandes test
Sync Shopify : catalogue, orders, policies en 1 flux
Guardrails refund/litige : seuils configurables
Mode shadow : brouillon agent avant auto-send
Soft launch % : limitation trafic native
Scénario DTC chiffré
Marque skincare, go-live précipité semaine 1 (CSAT 64 %). Rollback + passage contrôles Qstomy sections 3-7 + soft launch 10→100 % sur 4 sem. Résultat : CSAT bot 86 %, escalade 28 %, zero incident policy mois 1, tickets WISMO −38 % vs baseline.
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels enchaîner avant activation ?
Playbook 1 : audit scope (3 h)
Top 50 tickets, 5-8 intents phase 1, exclusions. One-pager signé.
Playbook 2 : corpus + Shopify (1 jour)
Blocs 2-3 sections 4-5. 10 questions Heeya + 5 commandes test API.
Playbook 3 : handoff + guardrails (3 h)
Bloc 4 section 6. 3 tests escalade live avec agent.
Playbook 4 : batterie 25 tests (4 h)
Section 7 complet. Tableur pass/fail. Zero fail critique (policy, handoff, checkout).
Playbook 5 : soft launch 4 sem
Section 9. Revue J+3 calée. Formation mini équipe #219. Scale si KPI OK.
Maillage utile
Activer un chatbot, ce n'est pas cliquer sur un bouton : c'est ouvrir un canal support. Méritez la confiance du client avant d'ouvrir la porte.
Enzo
28 juin 2026
