E-commerce
30 juin 2026
« Où est ma commande #4821 ? » Le bot répond : « Livraison demain à Paris. » Sauf que l'API Shopify a timeout depuis 40 secondes. Le client attend un colis qui n'a pas quitté l'entrepôt. Pire qu'un silence : une fausse certitude.
AeroChat rappelle qu'un fallback efficace suit quatre niveaux : clarifier, interroger les données live, escalader, différer avec prochaine étape claire (AeroChat, fallback ecommerce 2026). Aidify note que la majorité des échecs bot viennent d'intégrations Shopify cassées ou lentes, pas du modèle seul (Aidify, chatbot fails).
Ce guide #279 traite le mode dégradé chatbot IA quand les données Shopify ne répondent plus : continuité, fallback data, messages honnêtes. Complète communication incident (#278) côté bot, pas seulement macros humaines.
Sommaire
Pourquoi le bot doit-il basculer en mode dégradé ?
Sans fallback chatbot Shopify, l'API down devient hallucination : le LLM invente un statut commande ou un stock pour combler le vide.
Trois scénarios fréquents
Panne plateforme : Admin API 503, juin 2026 Shopify (#278)
Timeout isolé : lookup order > 5 s, rate limit 429
Token expiré : apps publiques Shopify, tokens offline expirants depuis avril 2026 (Shopify, offline tokens)
Coût d'un bot qui improvise
Mauvais ETA → recontact WISMO. Faux stock → commande annulée. Promesse remboursement sans lookup → chargeback. AI Solutions Wiki : le fallback doit être testé en staging, pas improvisé en prod (AI Solutions, circuit breaker).
Exemple DTC
Cosmétiques, 420 conv bot/jour. Spike 429 Shopify 22 min. Bot sans fallback : 67 réponses WISMO inventées. Après mode dégradé + circuit breaker : 0 statut inventé, handoff 89 % intents data-dependent, CSAT incident 3,6/5 vs 2,1 avant.
En quoi diffère-t-il de l'incident support et des guides bot voisins ?
Six contenus, six couches.
Communication incident (#278)
Incident (#278) : macros humaines, status page, social. Le #279 : comportement automatique bot quand lookup échoue.
Hallucinations (#123)
Hallucinations (#123) : RAG et confiance corpus. Le #279 : échec API temps réel, pas chunk KB manquant.
Données Shopify (#20)
Personnalisation (#20) : quelles données lire en nominal. Le #279 : que faire sans ces données.
Gouvernance (#142)
Gouvernance (#142) : kill switch global. Le #279 : dégradation graduée, pas coupure totale.
Handoff (#12)
Handoff (#12) : quand céder. Le #279 définit handoff automatique si API down.
Limites bot (#124)
Limites (#124) : intents humain-only. Le #279 ajoute règle : intent data-live → fallback si API KO.
Promesse #279
Matrice échecs, 4 tiers fallback, 4 modes dégradés, circuit breaker, templates BOT-FALLBACK, token refresh, KPI, playbooks.
Quels types d'échec API Shopify le bot doit-il détecter ?
Le monitoring API bot Shopify classe l'échec avant de choisir le fallback.
Cinq signaux techniques
Timeout : pas de réponse > 3-5 s (lookup order)
5xx : 502/503 plateforme ou proxy
429 : rate limit Admin API
401/403 : token expiré ou scope manquant
Partial response : customer OK, orders vide anormal
Health check synthétique
Ping GraphQL toutes les 60 s : query shop { name } + 1 order test. 3 échecs consécutifs → mode DEGRADED global. AI/TLDR : compter timeout et 429 comme failures, pas les 400 requête mal formée (AI/TLDR, circuit breaker LLM).
Distinction panne vs client inconnu
E-mail non matché ≠ API down. Ne pas confondre : log api_error vs customer_not_found. Réponses différentes.
Quelle cascade fallback en quatre tiers appliquer ?
La cascade fallback bot ecommerce suit AeroChat : ne jamais sauter direct au « je ne sais pas ».
Tier 1 : Clarifier
Intent ambigu + API OK partiel : « Parlez-vous de la commande #[dernière connue] ou d'un autre numéro ? » Si API down : passer tier 2 sans clarifier sur data live.
Tier 2 : Données live
WISMO, stock, statut fulfillment : appel Order API. Succès → réponse normale. Échec → tier 3. Confiance requise 90 %+ sur données commande (AeroChat).
Tier 3 : Escalade humaine
Handoff avec payload : intent, e-mail client, numéro commande verbatim, flag shopify_api_down, transcript. SLA humain prioritaire si panier > seuil ou sentiment angry.
Tier 4 : Différer structuré
Pas d'agent dispo : collecter e-mail + numéro commande + callback window. « Nous ne pouvons pas consulter Shopify en direct maintenant. Un agent vous écrit sous [X] h avec le statut exact. Référence : FB-[ticket]. » Jamais inventer statut en tier 4.
Taux fallback sain
AeroChat : 15-25 % conversations touchent un fallback, dont escalade ou différé. > 40 % = problème intégration ou corpus trop dépendant API.
Matrice intent × tier (extrait)
wismo : tier 2 → 3 si fail → jamais tier 4 sans collecte
return_start : tier 2 KB si API down, lien portail statique
refund_dispute : tier 3 immédiat si API fail
pre_sale_stock : tier 4 + « stock confirmé par agent »
policy_general : tier 2 corpus seul, pas API
AeroChat : 15-25 % conversations touchent un fallback, dont escalade ou différé. > 40 % = problème intégration ou corpus trop dépendant API.
Quels modes dégradés activer selon la gravité ?
Quatre modes dégradés chatbot remplacent le binaire on/off.
MODE FULL (nominal)
Toutes APIs OK. Lookup order, inventory, customer tags, RFM.
MODE KB_ONLY
Shopify down, corpus KB accessible. Bot répond policy retour, délais génériques, liens centre d'aide. Interdit : statut commande, stock variant, prix live. Bannière widget : « Consultation commande temporairement indisponible. »
MODE STALE_CACHE
API flaky : servir cache Redis order/customer < 15 min avec mention interne stale=true. Message client : « Information basée sur notre dernière sync à [heure]. Pour confirmation exacte, un agent reprend sous [X] h. » Brandon Hendricks : accepter data stale plutôt qu'échec total (Hendricks, agent reliability).
MODE HANDOFF_ONLY
Panne SEV1 plateforme (#278). Bot accueille, explique incident, lien status, collecte contact, handoff ou callback. Zero intent produit, zero promo. Toggle manuel + auto si health check 503.
Matrice mode × intent
WISMO + KB_ONLY → tier 3/4. Pre-sale policy + KB_ONLY → tier 2 corpus OK. Refund dispute → HANDOFF_ONLY immédiat. Voir triage (#236).
Comment configurer le circuit breaker Shopify ?
Le circuit breaker API Shopify protège latence bot et évite cascade timeout.
Paramètres production DTC
Timeout request : 3 s order lookup, 5 s inventory
Seuil ouverture : 50 % échecs sur 20 requêtes ou 60 s
Half-open : 2 probes après 30 s cooldown
Retry : 1 retry idempotent sur timeout, pas sur 401
États et actions
Closed : normal. Open : skip API, mode KB_ONLY ou HANDOFF. Half-open : 1 lookup test, si OK → closed + log recovery.
Token refresh avril 2026
Apps publiques : expiring=1 à l'OAuth, stocker refresh_token, refresh avant expiration. Sinon 401 silencieux → bot croit client absent (Shopify dev, tokens expirants). Alerte si refresh échoue 2× : MODE HANDOFF_ONLY préventif.
Logging obligatoire
Chaque fallback : api_endpoint, error_code, mode_active, tier_triggered. Alimenter revue QA #277.
Arbre décision runtime
lookup_order(email) → timeout 3 s → retry 1× → fail → circuit.record_failure() → if circuit.open → mode=KB_ONLY → template BOT-FALLBACK-API-DOWN → handoff si angry OR cart>200€. Si partial customer sans orders → tier 3 direct, pas tier 2.
Quels messages BOT-FALLBACK utiliser ?
Six templates fallback bot remplacent l'hallucination par transparence calibrée.
BOT-FALLBACK-API-DOWN
« Je ne peux pas accéder à votre commande en direct pour le moment (incident technique côté boutique). Votre numéro #[X] est bien noté. Un agent vous répond sous [SLA] h avec le statut exact, ou consultez [status URL]. »
BOT-FALLBACK-STALE
« D'après notre dernière synchronisation à [heure], la commande #[X] était [statut]. Pour une confirmation à l'instant T, je vous mets en relation avec l'équipe. »
BOT-FALLBACK-KB-POLICY
« Nos délais de retour standard sont [X j] selon [lien policy]. Je ne peux pas vérifier votre commande maintenant ; indiquez votre e-mail et un agent confirmera l'éligibilité. »
BOT-FALLBACK-COLLECT
« Pour reprendre dès que le système revient : e-mail, numéro commande si connu, téléphone optionnel. Référence FB-[id]. »
BOT-FALLBACK-HANDOFF
« Je vous transfère avec le contexte de notre échange. L'équipe a accès prioritaire aux outils internes. Délai estimé : [X] min. »
BOT-FALLBACK-NO-GUESS
Prompt system : « Si shopify_lookup_failed=true, interdiction d'inventer statut commande, stock, tracking, remboursement. Utiliser template BOT-FALLBACK-*. »
Payload handoff minimal
{"shopify_api_down":true,"mode":"KB_ONLY","intent":"wismo","order_id_verbatim":"#4821","customer_email":"x@mail.com","circuit_state":"open","stale_cache_used":false}. Agent Gorgias voit le flag sans relire 20 messages.
Quelles capacités bot désactiver en mode dégradé ?
La liste interdits mode dégradé évite les réponses dangereuses quand Shopify est muet.
Désactiver immédiatement
Confirmation statut fulfillment ou tracking
Vérification stock variant temps réel
Promesse remboursement, cancel, edit adresse
Recommandation produit basée inventory API
Personnalisation RFM lookup (#276)
Codes promo dynamiques checkout
Conserver si KB local OK
Policy retour texte statique, guide taille PDF, horaires support, lien portail retour générique, transparence IA art. 50.
Sync avec incident_mode #278
Flag incident_active Gorgias force HANDOFF_ONLY. Flag shopify_api_degraded seul → KB_ONLY ou STALE_CACHE. Deux flags indépendants : panne comms ≠ API lente.
Recovery automatique
Health check OK 5 min → repasser FULL. Annoncer en widget : « Consultation commande rétablie. » Pas de rattrapage inventé sur tickets ouverts : agent vérifie manuellement.
Quels pièges fallback éviter absolument ?
Sept anti-patterns fallback bot coûtent plus cher que le silence.
Erreurs fréquentes
Fallback appelle la même API en boucle : circuit jamais open
Cache stale sans label : client agit sur vieux tracking
Message technique : « Error 503 GraphQL » au client
Handoff sans payload : agent redemande tout
Bot continue promos pendant HANDOFF_ONLY
Pas de test fallback : découvert en panne réelle juin 2026
401 non géré : token mort depuis 3 j, bot aveugle
Test staging mensuel
Simuler timeout API (mock 503), vérifier 0 hallucination WISMO sur pack 10 conversations. Documenter dans registre gouvernance (#142).
Quels KPI suivre sur les fallbacks ?
La performance fallback bot se mesure au-delà du uptime API.
KPI hebdomadaires
Fallback rate : % conv avec tier ≥ 3 (cible 15-25 %)
api_error rate : timeouts + 5xx / lookups
Hallucination post-fallback : audits #123, cible 0
Handoff latency quand shopify_api_down
CSAT mode dégradé vs nominal
Time in DEGRADED : minutes/semaine
Alertes
Slack si fallback rate > 35 % sur 1 h. Pager si circuit open > 10 min en heures commerce. Corréler avec Shopify status page.
Dashboard Notion minimal
Colonnes : date | minutes DEGRADED | fallback_rate | handoff_count | hallucination_audit | action fix. Revue 15 min vendredi avec owner bot.
Comment Qstomy gère-t-il le mode dégradé Shopify ?
Qstomy intègre circuit breaker, modes dégradés et templates BOT-FALLBACK sans exposer l'erreur technique au client.
Capacités
Health check Shopify : bascule auto KB_ONLY / HANDOFF
Stale cache order avec flag et message STALE
Guardrail NO-GUESS : block LLM si lookup failed
Payload handoff enrichi : api_error + mode + verbatim
Sync incident_mode #278 : toggle unifié widget
Scénario DTC chiffré
Marque mode, 380 conv bot/jour, lookup Shopify 98,5 % OK nominal. Incident 429 spike 35 min Black Friday preview. Avant fallback : 41 statuts commande inventés, 8 chargebacks WISMO. Après Qstomy circuit breaker + 6 templates : 0 statut inventé, fallback rate 22 %, handoff 94 % intents WISMO en panne, CSAT dégradé 3,7/5, recovery paniers post-incident +28 % vs silence bot.
Explorez support client IA, Shopify, demander une démo.
Quels playbooks déployer avant la prochaine panne API ?
Playbook 1 : cartographie intents data-live (2 h)
Lister intents nécessitant Order/Inventory API. Marquer tier fallback par intent. Aligner limites (#124).
Playbook 2 : circuit breaker (3 h)
Implémenter section 6. Timeout 3 s. Test mock 503 en staging.
Playbook 3 : templates BOT-FALLBACK (1 h)
Importer 6 messages section 7. Prompt system NO-GUESS. Revue legal ton transparence.
Playbook 4 : token audit (1 h)
Vérifier expiring tokens avril 2026. Refresh job documenté. Alerte 401 Slack.
Playbook 5 : drill trimestriel (30 min)
Simuler API down + incident_mode. Chronométrer first fallback message. Corriger gaps.
Playbook 6 : lien war room
Intégrer toggle bot dans runbook #278. Maillage : hallucinations (#123), contexte handoff, données Shopify (#20).
Quand Shopify ne répond plus, le bot n'a pas le droit de deviner : il a le devoir de basculer proprement.
Enzo
30 juin 2026
