E-commerce
28 juin 2026
« Ça ne marche pas. » Trois mots, dix causes possibles : batterie déchargée, mauvais mode, pièce mal montée, attente irréaliste, ou défaut réel. Le client veut une réponse maintenant ; votre expert produit n'est pas disponible à 23 h un dimanche.
VSight cite Accenture : environ 68 % des retours électronique sont No Trouble Found, souvent après un échec de diagnostic (VSight, visual support 2026). Un chatbot générique qui recrache la notice PDF n'aide pas : il faut un diagnostic conversationnel qui accumule des indices tour après tour.
Ce guide #229 traite le chatbot IA diagnostic produit post-achat : intents, arbres, handoff expert. Distinct de support installation (#228) (workflow humain + macros INS), onboarding bot (#179) (setup proactif) et limites bot (#124) : ici, troubleshooting guidé qui sait s'arrêter avant de remplacer le jugement technique.
Sommaire
Pourquoi le diagnostic conversationnel change-t-il le support produit ?
Le chatbot diagnostic produit ne répond pas à une question : il mène une enquête structurée jusqu'à une cause probable ou une escalade.
Limite du RAG multi-tours naïf
Le framework DQA (ACL Industry 2026) montre qu'un RAG standard sans état diagnostic atteint 41,3 % de résolution sur scénarios support IT, contre 78,7 % avec état persistant et hypothèses concurrentes (ACL Anthology, DQA 2026). Même logique en e-commerce : « ça ne marche pas » exige des questions ciblées, pas un paragraphe notice.
Trois gains mesurables
Retours NTF évités : reset, pairing, réglage avant demande remboursement
Tickets expert filtrés : l'humain reçoit dossier pré-diagnostiqué
Disponibilité 24 h : diagnostic niveau 1 sans file d'attente
Exemple DTC petit électroménager
Robot cuisine, 34 % tickets post-livraison « ne fonctionne pas ». Bot diagnostic 5 branches (alimentation, sécurité, mode, blocage, défaut). Après 8 semaines : autonomie bot 62 %, retours NTF −31 %, temps expert par ticket −40 %.
En quoi diffère-t-il de l'installation, de l'onboarding et des limites bot ?
Cinq contenus voisins, un angle : diagnostic IA post-achat avec handoff expert.
Support installation (#228)
Support installation (#228) : macros INS-*, escalade humaine, tutoriels. Le #229 couvre comment le bot mène l'arbre diagnostic avant handoff.
Onboarding bot (#179)
Onboarding bot : flows setup proactifs J+0. Le #229 : réactif quand le client signale un dysfonctionnement, y compris semaines après livraison.
Guide usage statique
Guide usage : assets PDF/vidéo. Le bot orchestre et adapte selon réponses client.
Limites et handoff (#124, #12)
Limites bot (#124) : zones interdites. Handoff (#12) : règles générales. Le #229 précise seuils diagnostic : quand le bot s'arrête face à un expert.
Promesse #229
Intents troubleshoot, état diagnostic, branches TRB-*, corpus, escalade, tests, KPI, playbooks.
Quels intents diagnostic cartographier pour le chatbot ?
Cartographiez les intents troubleshoot chatbot avant branchement des arbres.
Douze intents post-achat (top volume)
ts_power_on : ne démarre pas, voyant absent
ts_power_cycle : s'éteint seul, surchauffe
ts_connectivity : Wi-Fi, Bluetooth, app pairing
ts_assembly_incomplete : structure instable, bruit anormal
ts_missing_part : pièce absente colis
ts_usage_wrong : mauvais mode, mauvaise dose
ts_expectation_gap : « pas l'effet promis » sans défaut
ts_error_code : code affiché écran
ts_noise_leak : fuite, odeur, bruit suspect (escalade rapide)
ts_damage_transit : casse visible à réception
ts_warranty_defect : défaut confirmé post-diagnostic
ts_compare_working : « chez le voisin ça marche » (usage/comparaison)
Mining tickets 90 jours
Export verbatims « ne marche pas », « defectueux », « code », « pairing », « bruit ». Croiser SKU : top 5 intents par catégorie = ordre de construction arbres.
Priorisation bot vs humain
Bot autonome : ts_power_on, ts_connectivity, ts_usage_wrong, ts_error_code (si table codes). Handoff immédiat : ts_noise_leak, ts_damage_transit, client menace chargeback.
Comment construire un arbre diagnostic conversationnel TRB-* ?
L'arbre diagnostic bot TRB-* suit des branches déterministes ; le LLM reformule, il ne invente pas les étapes.
Structure en 4 couches
Triage : SKU confirmé, date livraison, symptôme en une phrase
Hypothèses : 2-4 causes probables classées (usage > config > défaut)
Tests séquentiels : une action, confirmation Oui/Non/Photo
Conclusion : résolu, pièce à envoyer, ou escalade expert
État diagnostic persistant
Stocker en session : hypotheses[], tests_done[], confidence_score. Zoom Contact Center recommande des flows guidés qui escaladent quand la confiance tombe sous seuil, avec contexte complet transféré (Zoom, agents service 2026). Viewpoint Analysis cite Stonly et Zingtree pour guides interactifs adaptatifs en troubleshooting complexe (Viewpoint Analysis, AI support 2026).
Exemple TRB-POWER (extrait)
1) Câble branché secteur ? 2) Voyant charge ? 3) Reset 10 s bouton power. 4) Autre prise testée ? Si 4× Non → confidence_defect 0,75 → handoff SAV avec log tests.
Schéma JSON minimal (metafield Shopify)
{"sku":"HUM-200","intent":"ts_power_on","steps":[{"id":1,"action":"Brancher câble secteur","next_yes":2,"next_no":"photo_cable"}, {"id":2,"action":"Voyant charge visible ?","next_yes":3,"next_no":"charge_2h"}], "escalate_after_steps":4}. Versionner à chaque révision produit.
Codes erreur
Table error_codes[SKU] : E77 → procédure reset + vérif bobine (pattern Onsite AI (Onsite AI, troubleshooting 2026)). Pas de lookup = TRB-UNKNOWN, pas d'invention.
Quelles sources de données connecter au bot diagnostic ?
Le stack données troubleshoot bot combine commande, corpus technique et règles escalade.
Sources obligatoires
Commande Shopify : SKU, variante, date livraison, garantie
Arbres TRB : JSON par SKU ou famille produit
Codes erreur : table structurée, pas PDF seul
Tutoriels chunkés : étapes setup/troubleshoot (#228)
Policy SAV : remplacement, retour, pièce détachée
Chunking corpus
Un chunk = une étape diagnostic : action, image, condition suivante si Oui/Non. SharkNinja a restructuré manuels image-heavy avant agents unboxing (PYMNTS, SharkNinja 2026).
Sync hebdomadaire
Nouveau SKU → arbre minimum avant mise en vente. Révision BOM → update TRB. Voir base connaissances catalogue et entraîner bot Shopify.
Quelles branches bot pour alimentation, pairing et usage incorrect ?
Trois branches troubleshoot bot couvrent ~60 % du volume post-livraison sur électronique et connecté.
Branche alimentation (ts_power_on)
Séquence : branchement → voyant → charge initiale 2 h → reset → autre câble/prises. Boutons : « Fait / Pas fait / Je ne sais pas ». « Je ne sais pas » → photo demandée ou handoff.
Branche pairing (ts_connectivity)
OS version → app installée → Bluetooth/Wi-Fi ON → mode pairing (durée 30 s) → distance < 2 m. Lien vidéo 45 s si échec étape 3. Voir conseil électronique pour compatibilité pré-achat.
Branche usage (ts_usage_wrong)
Cosmétique : dose, fréquence, SPF associé. Fitness : tension courroie, surface plane. Cuisine : mode vs recette. Message clé : « Ce comportement est normal les 3 premiers jours » si documenté.
Six macros TRB-* pour le bot
TRB-TRIAGE-01 : « Je vois votre [SKU] livré le [date]. Décrivez en une phrase ce qui ne va pas. Je vais vous guider étape par étape. »
TRB-STEP-01 : « Étape [N]/[total] : [action documentée]. Appuyez sur Fait quand c'est terminé. »
TRB-CODE-01 : « Code [X] sur [SKU] : [procédure table error_codes]. Si le code persiste après ces étapes, je vous mets en relation avec notre expert. »
TRB-NTF-01 : « Bonne nouvelle : le produit répond normalement. Voici comment obtenir [résultat attendu]. Pas besoin de retour pour l'instant. »
TRB-ESCALATE-01 : « J'ai noté : [symptôme], tests [liste], photos reçues. Notre expert produit reprend sous [délai]. Vous n'avez rien à répéter. »
TRB-UNKNOWN-01 : « Je n'ai pas de procédure validée pour ce cas sur [SKU]. Je transmets à un expert sans vous faire attendre une réponse inventée. »
Templates réponse bot
Étape : « Essayons ceci : [action]. Dites-moi quand c'est fait. »
Confirmation : « Parfait, le voyant est vert ? Prochaine étape : … »
Blocage : « Merci pour la photo. Je vois [observation grounded]. Essayons … »
Quand le bot doit-il escalader vers l'expert sans improviser ?
Le principe #229 : aider sans remplacer l'expert. L'escalade est une fonctionnalité, pas un échec.
Déclencheurs escalade immédiate
Sécurité : odeur brûlé, fuite, étincelle, surchauffe anormale
Confiance < 0,55 après 3 tests sans résolution
Demande explicite : « je veux un technicien »
Produit réglementé : réaction cutanée, ingestion (produits réglementés)
Garantie litige : client exige remplacement sans diagnostic (garantie SAV)
Handoff structuré
Transmettre : SKU, symptôme initial, hypothèses écartées, tests effectués, photos, score confiance. Gorgias recommande handover avec contexte complet pour éviter que le client répète (Gorgias, handover AI 2026).
Ce que le bot ne décide jamais seul
Remboursement, envoi produit neuf sans inspection, ouverture dossier garantie légale, diagnostic sécurité alimentaire. Voir limites bot (#124).
Comment éviter hallucinations et surpromesses en troubleshooting ?
Le troubleshoot bot grounded ne devine jamais une procédure absente du corpus.
Règles strictes
Whitelist étapes : seules les actions TRB documentées
Pas de démontage si non dans arbre (risque sécurité)
TRB-UNKNOWN si code erreur ou SKU sans arbre
Pas de « c'est normal » sans claim substantiation produit
Garde-fous techniques
Temperature basse sur génération étapes. Validation JSON schema avant envoi client. Log every step pour audit qualité. Voir anti-hallucination (#123) et gouvernance bot (#142).
Programme « attack the bot »
Inspiré SharkNinja : agents SAV tentent de casser le bot 30 min/jour (codes rares, photos floues, contradictions). Remontée hebdo vers équipe conversation design.
Comment tester et itérer le bot diagnostic avant mise en prod ?
Le QA bot troubleshoot combine scénarios replay et métriques trajectoire, pas seulement réponse unique.
Protocole test (20 scénarios / SKU prioritaire)
5 cas résolvables bot seul (power, pairing, usage)
5 cas NTF réels (mauvais mode, câble)
5 cas escalade obligatoire (sécurité, défaut)
5 edge cases (photo absente, SKU similaire, multilingue)
Critère succès trajectoire
Inspiré DQA : résolution = client confirme OK OU handoff expert avec dossier complet en < 6 tours. Cible pilote : ≥ 55 % autonomie, ≥ 85 % handoffs avec log tests.
Shadow mode 2 semaines
Bot propose réponse, agent valide avant envoi. Mesurer écarts agent vs bot → enrichir arbre.
Quels KPI pour piloter le diagnostic chatbot ?
Mesurez le diagnostic bot par trajectoire, pas par message isolé.
KPI résolution
Taux résolution bot troubleshoot : OK client sans humain
Tours moyens : cible 3-5 (DQA baseline 3,9)
Retours NTF post-chat par SKU
TRB-UNKNOWN rate : signal gap corpus
KPI escalade
Handoff quality score : expert confirme dossier exploitable
Repeat contact 7 j même SKU
CSAT segment troubleshoot
Boucle mensuelle
Top intents non résolus → nouvelle branche TRB. SKU TRB-UNKNOWN > 10 % → arbre prioritaire. Croiser TPU tickets et KPI chatbot (#11).
Comment Qstomy mène-t-il le diagnostic produit en conversation ?
Qstomy combine lookup commande, arbres TRB grounded et handoff expert structuré.
Fonctionnalités diagnostic
État diagnostic session : hypothèses et tests persistants
Lookup SKU + error_codes : procédures whitelistées
Intents ts_* : routing automatique post-livraison
Demande photo guidée : angles documentés par arbre
Handoff dossier : log complet pour expert
TRB-UNKNOWN + blocage sécurité : pas d'improvisation
Scénario DTC chiffré
Marque purificateur air + humidificateur, 29 % tickets « ne fonctionne pas », CSAT troubleshoot 68 %. Déploiement : 12 arbres TRB, table 18 codes erreur, handoff Gorgias enrichi. Après 10 semaines : résolution bot 58 %, retours NTF −27 %, tours moyens 4,1, satisfaction handoff expert 91 % (dossier complet).
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels lancer cette semaine ?
Playbook 1 : cartographie intents (½ journée)
Export tickets 90 j, classer 12 intents section 3 par SKU top CA.
Playbook 2 : arbre TRB pilote (2 j / SKU)
Triage + 3 branches + conclusion. Validation expert produit avant prod.
Playbook 3 : corpus + codes erreur (1 j)
Chunker notices, table error_codes JSON, sync metafields Shopify.
Playbook 4 : QA + shadow mode (2 semaines)
20 scénarios section 9, attack the bot, shadow puis bascule 25 % trafic.
Playbook 5 : revue KPI mensuelle (1 h)
Résolution, NTF, TRB-UNKNOWN, enrichir arbres ou handoff.
Maillage utile
Un bon bot diagnostic ne prétend pas être ingénieur : il pose les bonnes questions, exécute les tests sûrs documentés, et passe la main avec un dossier que l'expert peut exploiter en trente secondes. C'est ainsi que vous réduisez les retours injustifiés sans sacrifier la confiance du client.
Enzo
28 juin 2026
