E-commerce
28 juin 2026
Le client ouvre le chat : « Où est ma commande ? » Le bot interroge l'API Shopify, trouve le statut, répond en 8 secondes. Parfait. Mais 40 % de ces questions auraient pu disparaître si le bot avait su, dès l'expédition, que le colis partait et avait pré-rempli le contexte conversationnel.
Les webhooks Shopify poussent un événement (commande créée, colis expédié, remboursement) vers votre endpoint dès qu'il se produit (Shopify, webhooks apps). ShippyPro estime que les notifications proactives liées aux événements logistiques réduisent les tickets WISMO de 50 à 65 % (ShippyPro, WISMO 2026).
Ce guide #217 montre comment brancher un chatbot IA sur les webhooks Shopify pour déclencher la bonne réponse au bon moment. Distinct du glossaire webhook (définition) et de suivi commande (#184) (réponse réactive WISMO) : ici, automation événementielle push, pas seulement lookup pull.
Sommaire
Pourquoi un chatbot événementiel bat-il un bot purement réactif ?
Un chatbot événementiel Shopify écoute les changements boutique et met à jour le contexte conversationnel avant que le client ne pose la question.
Push vs pull
Pull : le client demande, le bot appelle l'API commande
Push : Shopify envoie un webhook, le bot enrichit profil + message proactif
Trois gains mesurables
Moins de WISMO : contexte expédition déjà connu au moment du chat
Réponses plus courtes : pas de lookup API à chaque message
Proactivité widget : bulle « Votre colis est en route » si session ouverte
Exemple DTC accessoires
Boutique 800 commandes/mois, bot WISMO pull seul : 310 tickets/mois intent tracking. Ajout webhooks fulfillments/create + fulfillment_events/create → cache contexte client + message proactif page compte. Tickets WISMO −44 % en 6 semaines, temps réponse bot −60 % (plus de lookup à froid).
En quoi diffère-t-il du glossaire webhook et du suivi commande #184 ?
Cinq contenus voisins, cinq rôles. Le #217 connecte événements Shopify au moteur bot.
Glossaire webhook
Glossaire webhook : définition technique HTTP POST. Le #217 : quels topics souscrire et quelle action bot déclencher.
Suivi commande (#184)
Suivi commande (#184) : branches WISMO quand le client écrit. Le #217 alimente ces branches avant la question.
Support par statut
Personnaliser par statut : macros et scripts par phase. Le #217 automatise la détection de phase via webhook.
Alertes internes (#172)
Alertes internes (#172) : Slack ops depuis conversations. Le #217 cible le client, pas l'équipe interne.
Entraînement données Shopify
Entraîner bot Shopify : catalogue et policies. Le #217 ajoute le flux temps réel commandes.
Promesse #217
Topics prioritaires, architecture receiver, mapping événement → message, sécurité, KPI, playbooks.
Quels webhooks Shopify souscrire en priorité pour le bot ?
Ne souscrivez pas aux 200 topics Shopify. Priorisez les webhooks chatbot e-commerce par impact tickets.
Tier 1 : post-achat (ROI immédiat)
orders/create: commande payée, contexte achat fraisfulfillments/create: expédition, numéro trackingfulfillment_events/create: in transit, out for delivery, deliveredorders/updated: changement statut, adresse, annulation
Tier 2 : SAV et exceptions
refunds/create: remboursement lancé, rassurer clientreturns/request: retour initié, guider étapesorders/cancelled: annulation, expliquer suite
Tier 3 : pré-achat et catalogue
checkouts/update: panier abandonné identifié (voir bot avant e-mail abandon)inventory_levels/update: rupture sur SKU consulté récemmentproducts/update: changement prix ou dispo sur fiche en session
Scopes API requis
Shopify exige read_orders, read_fulfillments, read_customers selon topics (Shopify, topics webhook). Demandez le minimum : read-only, pas de write depuis le receiver webhook.
Comment architecturer le flux webhook vers le moteur bot ?
L'architecture webhook chatbot standard tient en 5 composants.
1. Endpoint HTTPS
URL publique POST (ex. /webhooks/shopify). Répond 200 en moins de 5 s. Traitement lourd en file async (Redis, SQS, ou worker Qstomy).
2. Vérification HMAC
Comparez header X-Shopify-Hmac-SHA256 avec HMAC du body brut + secret app. Rejetez tout payload non signé. Shopify documente la vérification constant-time obligatoire.
3. Déduplication
Header X-Shopify-Webhook-Id : stockez les IDs traités 48 h. Shopify ne garantit pas l'ordre des webhooks sur un même resource : le dernier payload = vérité.
4. Normaliseur événement
Transforme payload Shopify en objet interne : {customer_id, order_id, event_type, status, tracking, sku[]}. Découple le bot du format Shopify brut.
5. Moteur bot / context store
Met à jour le profil conversationnel client. Si widget ouvert ou session récente (< 30 min), déclenche message proactif. Sinon, enrichit la prochaine interaction pull.
Schéma flux
Shopify event → POST endpoint → HMAC OK → queue → normalizer → context store → bot rule engine → (proactif widget OU cache pour pull). E-mail Klaviyo reste parallèle, pas remplacé.
Quel mapping événement → action bot → message appliquer ?
Table de mapping webhook → action bot prête à implémenter.
orders/create
Action : lier order_id au profil client chat. Message proactif (si widget compte client) : « Commande #[X] confirmée. Préparation sous [délai policy]. Posez vos questions ici. » Enrichissement pull : bot connaît dernière commande sans demander e-mail.
fulfillments/create
Action : injecter tracking + carrier. Proactif : « Bonne nouvelle : commande #[X] expédiée via [carrier]. Suivi : [lien]. Livraison estimée [date]. » Aligné branches #184.
fulfillment_events/create (out_for_delivery)
Proactif SMS ou widget : « Votre colis arrive aujourd'hui. Tracking : [lien]. » ShippyPro : notification out for delivery réduit livraisons ratées jusqu'à 35 %.
fulfillment_events/create (delivered)
Action : basculer intent par défaut vers retour/SAV produit. Proactif : « Colis livré. Un souci ? Décrivez-le ici. » Pas de relance agressive avis.
refunds/create
Action : contexte remboursement montant + délai banque. Pull : si client écrit « où est mon remboursement », réponse immédiate sans escalade.
checkouts/update (abandoned)
Action : si checkout idle 10 min + e-mail connu + SKU panier, trigger widget : « Question sur [produit] ou frais de port ? » Voir relance panier (#47).
inventory_levels/update (stock 0)
Action : si client a consulté ce SKU en session 24 h, proactif : « [Produit] vient de passer en rupture. Alternatives : [liens]. »
Quand utiliser webhook push vs API pull ?
Le webhook ne remplace pas l'API. Règles push vs pull chatbot claires.
Utiliser le webhook (push)
Notification proactive au client
Mise à jour cache contexte entre deux messages
Déclenchement règle bot sans polling
Utiliser l'API pull (get order)
Client pose WISMO sans webhook récent reçu
Reconciliation après panne endpoint (webhook manqué)
Lookup commande ancienne (> 30 j) hors cache
Anti-pattern polling
Ne planifiez pas de cron « interroger Shopify toutes les 5 min par client actif ». Coût API, latence, rate limits. Webhooks + pull à la demande suffisent.
Délai propagation
Après checkout, attendez 10 s avant premier lookup si webhook orders/create pas encore arrivé. Message fallback : « Je finalise la récupération de votre commande… »
Quelles règles de production avant le go-live ?
Six règles production webhook chatbot avant go-live.
Règle 1 : réponse 2xx immédiate
Shopify retente jusqu'à 8 fois sur 4 h si échec. Traitez en async, pas dans le handler HTTP.
Règle 2 : body brut pour HMAC
Ne parsez pas JSON avant vérification signature. Erreur classique : middleware Express parse trop tôt.
Règle 3 : idempotence
Même webhook reçu 2× = 1 action bot. Clé : webhook_id + order_id + event_type.
Règle 4 : dernier état gagne
orders/updated peut arriver avant fulfillments/create. Stockez timestamp Shopify, ignorez événements plus anciens.
Règle 5 : filtrer par shop
Header X-Shopify-Shop-Domain : routez multi-boutiques si applicable.
Règle 6 : logs sans PII complète
Loggez order_id, event_type, latency. Masquez adresse et e-mail dans logs production.
Test sandbox
Shopify CLI shopify app dev ou bouton « Send test webhook » Partner Dashboard. 15 scénarios : create, fulfill, deliver, refund, cancel, duplicate delivery.
Quels scénarios lifecycle concrétiser en premier ?
Trois scénarios lifecycle où webhooks + bot battent e-mail seul.
Scénario A : expédition J+1
Webhook fulfillments/create 9 h. Client ouvre site 9 h 15, widget affiche statut expédié. Il ne ouvre pas de ticket. E-mail Klaviyo part en parallèle à 9 h 05.
Scénario B : retard transporteur
App tracking (AfterShip) détecte retard → webhook custom ou orders/updated + tag delay. Bot proactif : « Retard 1 jour, nouvelle livraison vendredi. Aucune action requise. » Claimlane : alerte retard proactive évite ticket 5 €+ par contact.
Scénario C : remboursement en cours
Client écrit « remboursement ? » 2 h après refunds/create. Bot lit cache : « Remboursement 49,90 € lancé le [date], visible sous 5-10 j ouvrés banque. » FCR 100 %.
Orchestration multicanal
Webhook alimente bot + helpdesk sidebar Gorgias + segment Klaviyo. Le bot ne duplique pas l'e-mail transactionnel : il répond en chat et enrichit le contexte agent si escalade. Voir transfert contexte humain.
Quels KPI mesurer l'impact des webhooks sur le bot ?
Mesurez l'impact webhooks chatbot vs bot pull seul.
KPI comparatif
Tickets WISMO / 1000 commandes : baseline vs post-webhooks
Latence réponse bot WISMO : ms avec cache vs sans
Taux message proactif ouvert : clic widget post-webhook
FCR intent tracking : résolu sans recontact
Webhooks failed / retried : santé endpoint
Test A/B 4 semaines
Semaines 1-2 : bot pull only. Semaines 3-4 : webhooks Tier 1 actifs. Même trafic, même e-mails transactionnels. Attendu DTC mid-size : WISMO −30 à 45 %, latence bot −50 % sur intents post-achat.
Dashboard
Tuile « events processed / h », « cache hit rate pull », « proactifs envoyés ». Voir dashboard support Shopify (#216).
Quelles erreurs éviter avec les webhooks chatbot ?
Cinq erreurs webhook chatbot fréquentes en production.
Erreur 1 : traiter synchronously
Timeout Shopify, retries en boucle, doublons. Fix : queue async section 4.
Erreur 2 : proactif spam
5 messages widget par commande. Fix : max 1 proactif / phase (ship, deliver), cap 2/jour.
Erreur 3 : ignorer consentement
Proactif checkout sans opt-in marketing. Fix : proactif support ≠ promo, pas de vente forcée.
Erreur 4 : webhook sans branche pull fallback
Endpoint down 2 h, bot aveugle. Fix : pull API si cache stale > 15 min.
Erreur 5 : confondre webhook et e-mail
Désactiver e-mails Shopify pensant que le bot suffit. Fix : canaux complémentaires, bot pour instantanéité chat, e-mail pour trace asynchrone.
Comment Qstomy consomme-t-il les webhooks Shopify ?
Qstomy consomme les webhooks Shopify natifs sans endpoint custom côté marchand.
Événements Qstomy branchés
orders/create, orders/updated : contexte commande sidebar + bot
fulfillments/create + events : branches WISMO pré-chargées
refunds/create : intent remboursement instantané
checkouts/update : trigger abandon panier configurable
Scénario DTC chiffré
Marque bien-être, 1 200 commandes/mois, bot pull WISMO seul, 38 % tickets intent tracking. Activation webhooks Qstomy Tier 1 + messages proactifs widget compte. Après 7 semaines : tickets WISMO −41 %, latence réponse tracking 1,2 s → 0,3 s, FCR intent tracking +18 pts, taux ouverture message proactif expédition 34 %.
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels lancer en 30 jours ?
Playbook 1 : audit topics (2 h)
Export tickets 90 j par intent. Classer Tier 1/2/3 section 3. Livrable : liste 8 topics + scopes API requis.
Playbook 2 : mapping événement → message (3 h)
Remplir table section 5 pour chaque topic Tier 1. Rédiger 6 templates proactifs + 6 enrichissements pull. Revue tone of voice.
Playbook 3 : sécurité endpoint (2 h)
HMAC, dedup webhook_id, logs, réponse 200 < 5 s. 15 tests sandbox section 7. Monitoring alertes failed webhooks.
Playbook 4 : go-live Tier 1 (1 j)
Activer orders/create, fulfillments/create, fulfillment_events/create. Cap proactif 2/jour/client. Observer 50 commandes réelles avant Tier 2.
Playbook 5 : mesure S+30
KPI section 9. Comparer WISMO, latence, FCR vs baseline. Activer Tier 2 si endpoint stable (< 0,1 % failed).
Maillage utile
Le webhook est la sonnette : le chatbot ouvre la porte avec la bonne réponse avant que le client ne frappe.
Enzo
28 juin 2026
