E-commerce
7 juillet 2026
Un rappel produit déclenche en quelques heures des centaines de messages identiques : « Mon lot est-il concerné ? » « Que faire ? » « Puis-je me faire rembourser ? » Un bot générique cite la politique retour 30 jours. Un bot rappel mal calibré rassure à tort ou alarme inutilement.
Shopappy recommande une notice en quatre temps : consigne immédiate, identification lot, remède concret, explication en dernier (Shopappy, recall trust 2026). Total Retail estime que les agents multimodaux structurent vérification lot, remède et traçabilité à grande échelle (Total Retail, AI recalls 2026).
Ce guide #328 traite le chatbot IA pour rappels produit : informer sans paniquer, vérifier lot, exécuter remède. Il automatise BATCH-RECALL (#327), distinct du plan crise (#329) et de trace_recall_check (#312).
Sommaire
Pourquoi un bot rappel doit-il être configuré avant la crise ?
Un rappel n'attend pas votre roadmap Q3. Dès publication RappelConso, le trafic support peut multiplier par dix. Sans template bot pré-validé legal, chaque message est rédigé sous stress et chaque erreur devient preuve juridique.
Trois risques bot rappel improvisé
Fausse réassurance : « à priori pas concerné » sans check registre
Alarmisme : vocabulaire catastrophiste hors consignes DGCCRF
Incohérence canal : email dit X, bot dit Y
Opportunité si préparé
Conferbot estime 85 à 93 % de résolution self-service en crise rappel quand l'infrastructure bot est pré-déployée (Conferbot, recall bot 2026). Market IA rappelle : en 2026, le rappel est un moment définissant pour la marque, pas un sujet purement legal (Market IA, recall 2026).
Principe #328
Pipeline RECALL-BOT-LOOP : activer mode crise → intent → RECALL-BOT-GUARD → flow 4 temps → remède (refund/reship) → log audit → handoff si santé/presse.
En quoi diffère-t-il du SAV lots #327, du plan crise #329 et de la traçabilité #312 ?
Cinq contenus rappel, cinq niveaux d'intervention.
Support lots (#327)
Lots SAV (#327) : BATCH-RECALL humain, macros, lookup. Le #328 : exécution bot à volume avec mode crise.
Plan crise (#329)
Plan crise (#329) : email/SMS massif, page hub, war room. Le #328 : conversation unitaire client qui arrive en panique ou via lien rappel.
Traçabilité bot (#312)
Traçabilité (#312) : trace_recall_check en fonctionnement normal. Le #328 : mode crise actif, corpus rappel versionné, remède automatisé.
Incident technique (#278)
Incident tech (#278) : panne site ou API. Le #328 : risque sanitaire produit, ton et garde-fous distincts.
Bot fallback (#279)
Fallback (#279) : API down. Le #328 : registre rappel indisponible = mode prudence maximal, pas hallucination.
Promesse #328
RECALL-BOT-INTENT, RECALL-BOT-GUARD, flow 4 temps, RECALL-BOT-MODE, proactive outreach, remède bot, KPI crise, playbooks.
Quelle taxonomie RECALL-BOT-INTENT pour router le bot rappel ?
La taxonomie RECALL-BOT-INTENT mappe les verbatims crise vers flows bot exécutables.
10 intents bot rappel
recall_check_lot: lot cité, concerné ou nonrecall_check_order: lookup lot depuis commande authrecall_read_lot_help: où trouver le numéro emballagerecall_instructions: que faire maintenant (ne pas consommer, détruire)recall_remedy_refund: demande remboursement sans retourrecall_remedy_replace: demande remplacement lot sainrecall_return_process: retour physique si policy l'exigerecall_claim_status: où en est ma demanderecall_symptoms_health: malaise, ingestion, urgencerecall_panic_media: peur extrême, tweet, avocat
Routing priorité crise
P0 immédiat : recall_symptoms_health → handoff humain + numéro urgence si alimentaire. P1 : recall_check_lot, recall_check_order. P2 : remède et statut. Mode crise : bot bypass file générale, bandeau site « Rappel actif {réf} ».
Quels garde-fous RECALL-BOT-GUARD avant tout message bot rappel ?
Le document RECALL-BOT-GUARD verrouille ce que le bot peut dire pendant une crise sanitaire ou qualité.
14 règles non négociables
Jamais confirmer non-concerné sans match registre lot/GTIN
Jamais minimiser risque : pas de « probablement sans danger »
Consignes depuis legal : texte validé qualité + juridique, pas LLM libre
Ordre 4 temps : action → identification → remède → explication
Auth avant remède : email + commande ou preuve achat
Refund plafonné policy RECALL-REMEDY, log audit
Pas de conseil médical : orienter SAMU/15 si symptômes
Registre versionné : lots listés datés, refresh horaire crise
Mode prudence si registre API down : handoff humain
Ton calme : empathie, pas jargon corporate ni alarmiste
Cohérence RappelConso : mêmes lots que fiche officielle
Log interaction : lot, décision, remède, timestamp
Review humaine : templates bot validés pré-crise
Escalade presse/santé : immédiate, bot s'arrête sur remède
Message interdit vs autorisé
Interdit : « Ne vous inquiétez pas, c'est sans gravité. » Autorisé : « Voici la consigne officielle : ne consommez pas le produit. Nous vérifions votre lot {lot} dans notre registre. » Conferbot insiste : instructions identiques à chaque client, validées avant déploiement (Conferbot 2026).
Comment structurer le flow bot en quatre temps RECALL-BOT-4T ?
Le flow RECALL-BOT-4T suit l'ordre cognitif du client anxieux (Shopappy).
Temps 1 : consigne immédiate
Dès ouverture chat mode crise : « Rappel {réf} en cours sur {produit}. Si vous possédez ce produit : {consigne officielle}. Nous allons vérifier si votre lot est concerné. » Pas d'excuse avant l'action.
Temps 2 : identification
Proposer : saisir lot OU n° commande OU photo emballage (OCR)
Lookup registre RECALL-REGISTRY : lots[], GTIN[], dates achat
Résultat binaire : concerné / non concerné avec liste lots rappelés citée
Temps 3 : remède
Si concerné : choix refund sans retour (denrées) ou étiquette retour (non-alimentaire) ou reship. Exécution Shopify refund tool plafonné. Confirmation : « Remboursement {montant} lancé, délai {j} j ouvrés. »
Temps 4 : explication
Seulement après remède initié ou si client demande : nature du risque (texte legal validé), date décision, mesures correctives. Lien fiche RappelConso. Market IA : page centrale indexable mise à jour en temps réel (Market IA 2026).
Comment activer le mode crise RECALL-BOT-MODE ?
Le protocole RECALL-BOT-MODE bascule le bot du fonctionnement normal vers crise rappel en moins de 2 h.
8 étapes activation
Qualité valide fiche RappelConso publiée + registre lots interne
Legal valide textes consigne et explication (Temps 1 et 4)
Ops exporte clients concernés par lot (traçabilité aval)
Injecter RECALL-REGISTRY v1.0 dans corpus bot (lots, SKU, GTIN)
Activer bandeau site + chip chat « Vérifier mon lot rappel »
Lancer flow email/SMS lien chat pré-rempli (#329)
Désactiver intents vente proactive bot sur SKU concernés
Brief support : bot gère tier 1, humains tier santé/presse
Proactive outreach bot
Message type : « Bonjour {first_name}, rappel {réf} sur {produit} que vous avez commandé le {date}. Cliquez pour vérifier votre lot et obtenir remboursement : {link}. » Total Retail : lien sécurisé ouvre assistant avec contexte commande (Total Retail 2026).
Désactivation mode crise
Quand claim rate < 5 % actifs et volume < seuil : repasser mode normal. Archiver RECALL-REGISTRY et logs pour audit DGCCRF.
Comment exécuter les flows vérification lot et remède ?
Les flows RECALL-BOT-CHECK et RECALL-BOT-REMEDY opérationnalisent #327 en bot.
Flow recall_check_lot
Collecter lot (texte ou OCR photo)
Normaliser format (trim, uppercase, prefix)
Match RECALL-REGISTRY.lots[]
Si match : Temps 1 consigne + proposer remède
Si no match : « Lot {lot} non listé dans rappel {réf}. Lots concernés : {liste}. Vérifiez l'emballage ou saisissez n° commande. »
Flow recall_check_order
Auth email + order → lire batch_id fulfillment (#327 BATCH-LOOKUP) → auto-match registre. Si commande contient SKU rappelé et lot concerné : skip saisie manuelle, proposer remède direct.
Flow recall_remedy_refund
Vérifier concerné + auth + pas déjà refund claim
Montant = line item TTC policy RECALL-REMEDY
Trigger refund Shopify API ou ticket finance auto
Tag order
recall_remediedEmail confirmation + recall_claim_status disponible
Intent recall_symptoms_health
Script fixe : « Si symptômes graves, contactez le 15 ou le SAMU. Notre équipe vous rappelle sous 30 min. Ne consommez plus le produit. » Handoff P0 qualité + legal. Bot ne diagnostique pas.
Quels outils RECALL-BOT-TOOLS connecter au bot Shopify ?
La couche RECALL-BOT-TOOLS alimente vérification et remède sans inventer.
Lecture obligatoire
RECALL-REGISTRY : JSON versionné lots, SKU, GTIN, date début/fin
Order API : line items, batch metafield, email
Customer export crise : liste proactive outreach
Link RappelConso : URL fiche officielle par recall_id
Écriture bot plafonnée
Refund API si montant < seuil RECALL-REMEDY.auto_refund_max. Au-delà : ticket finance structuré. Reship : draft order lot neuf si stock disponible. Tag helpdesk recall_bot.
OCR lot optionnel
Photo emballage → extraction lot → match registre. Total Retail décrit lecture packaging multimodale (Total Retail 2026). Fallback saisie manuelle si OCR < confidence 0,85.
Sync RappelConso
Webhook ou refresh horaire : lots listés fiche DGCCRF = source vérité. Écart interne vs public = alerte ops avant réponse client (RappelConso 2026).
Quels segments et scénarios prioriser selon le type de rappel ?
La matrice segment RECALL-BOT adapte remède et ton au produit rappelé.
Alimentaire contamination
Refund sans retour systématique. Consigne ne pas consommer. OCR lot fréquent. SLA bot < 30 s. Lien périssables (#313).
Cosmétique/allergène
Stop usage immédiat. Symptômes cutanés → handoff. Remède refund ou reship selon policy.
Électronique sécurité
Consigne débrancher/stopper. Retour physique parfois requis CPSC-style. Flow recall_return_process actif. Numéro série vs lot (#327).
Textile défaut non sanitaire
Ton moins urgent, 4 temps identiques. Refund ou échange taille. Pas de consigne SAMU.
Clients B2B revendeurs
Bot collecte lot + volume, handoff commercial. Pas auto-refund panier 500 unités.
Quels KPI mesurer pendant et après un rappel bot ?
Mesurez couverture remède et erreurs bot, pas seulement le volume conversations.
KPI crise RECALL-BOT
recall_bot_resolution_rate : clos sans humain / total intents crise
recall_false_reassurance : erreurs non-concerné (cible 0)
recall_time_to_remedy : minutes check lot → refund initié
recall_proactive_open_rate : % outreach cliqués
recall_claim_completion : % clients concernés ayant obtenu remède
recall_csat_crisis : satisfaction post-rappel (benchmark Conferbot ~3,8/5)
recall_handoff_health_rate : escalades santé, délai réponse humain
Benchmarks
Objectif : recall_bot_resolution_rate 80-90 % en crise, recall_false_reassurance = 0, recall_time_to_remedy < 5 min médian. Shopappy : trust se construit par suivi jusqu'à taux claim qui décroît (Shopappy 2026).
Post-mortem J+30
Revue logs bot + tickets humains. Ajuster RECALL-REGISTRY format et templates 4 temps pour prochain incident.
Comment Qstomy gère un rappel produit sans paniquer ni rassurer à tort ?
Qstomy active RECALL-BOT-MODE : flow 4 temps, check lot registre, remède refund, logs audit, handoff santé immédiat.
Capacités
Injection RECALL-REGISTRY versionné en un clic crise
Intents recall_check_lot et recall_check_order automatisés
OCR photo lot + fallback saisie
Refund plafonné RECALL-REMEDY via Shopify
RECALL-BOT-GUARD : zéro message hors corpus legal
Proactive link chat depuis export clients lot
Escalade P0 recall_symptoms_health
Scénario DTC chiffré
Marque snacks, rappel lot L2406-B (2 400 clients touchés). Sans #328 : 890 appels J+1, attente 38 min, 2 fausses réassurances agent stressé. Avec RECALL-BOT-MODE Qstomy : 71 % résolution bot, attente humaine 4 min, recall_false_reassurance 0, recall_time_to_remedy 3,2 min médian, recall_claim_completion 84 % à J+14, recall_csat_crisis 3,9/5.
Intégration
Template crise pré-chargé, sync BATCH-POLICY (#327). Voir support client IA, démo. Suite : plan crise (#329).
Quels playbooks déployer pour préparer le bot rappel ?
Playbook 1 : template RECALL-BOT-4T (1 j)
Rédiger 4 temps section 5. Validation legal + qualité. Stocker corpus versionné Qstomy.
Playbook 2 : RECALL-REGISTRY fictif (2 h)
Lot L-TEST-RECALL, 10 commandes test. Simuler check + refund. Mesurer recall_time_to_remedy.
Playbook 3 : RECALL-BOT-GUARD tests (3 h)
20 scénarios : lot inconnu, lot limite, symptômes, registre down. recall_false_reassurance doit rester 0.
Playbook 4 : runbook activation crise (1 j)
8 étapes section 6. Owners nommés. Lien export ERP → outreach.
Playbook 5 : simulation trimestrielle (2 h)
Tabletop qualité + support + bot. Chronométrer activation < 2 h. Lier plan crise (#329).
Maillage utile
Enzo
7 juillet 2026
