E-commerce
30 juin 2026
9 h27, mardi 3 juin 2026 : checkout, admin et POS Shopify tombent. Vos clients voient « Cette boutique n'existe pas » au lieu d'un message de panne. Votre équipe support n'a plus accès à Gorgias. Les DMs Instagram s'empilent : « Arnaque ? », « Ma carte a été débitée ? »
PYMNTS rapporte une coupure d'environ deux heures touchant vitrines, paiements et accès au support marchand (PYMNTS, panne Shopify juin 2026). Digital Applied rappelle qu'une status page tenue à jour pendant l'incident peut réduire les contacts support de 60 à 80 % (Digital Applied, outage playbook 2026).
Ce guide #278 traite la communication client pendant incident technique checkout ou paiement : messages, canaux, macros, bot et recovery. Aucun contenu voisin ne couvrait ce moment précis. Distinct de paiement refusé (#payment) (refus carte individuel) : ici, panne système touchant tous les clients.
Sommaire
Pourquoi la communication incident compte-t-elle autant que la résolution ?
Pendant une panne checkout e-commerce, le support devient le canal de vérité quand la boutique ne peut plus parler d'elle-même. Le client ne distingue pas Shopify, Stripe et votre marque : il voit une marque qui « ne marche pas ».
Trois risques si vous restez silencieux
Charge support ×10 : même question « le site est down ? » sans macro
Abandon définitif : client part chez un concurrent pendant la panne
Chargebacks : débit pré-autorisé perçu comme fraude
Ce que la transparence apporte
SmartSMS Solutions illustre une panne checkout 23 min Cyber Monday : « investigating issues » a généré 347 appels et 892 e-mails. Un message précis (« checkout indisponible, panier sauvegardé, retour sous 30 min ») aurait évité 90 % de ces contacts (SmartSMS, status page). AWS Well-Architected recommande pages d'erreur amicales, bannières statut et notifications push sur surfaces que vous contrôlez (AWS, plan communication outage).
Exemple DTC mode
Marque 180 k€ CA/mois, panne PSP 47 min un jeudi promo. Sans runbook : 214 tickets, 31 avis négatifs. Avec status page + macro INC-CHECKOUT + post Instagram sous 8 min : 41 tickets, 0 chargeback, 62 % clients reviennent dans les 24 h selon lien recovery e-mail.
En quoi diffère-t-il du paiement refusé et des guides ops voisins ?
Six contenus voisins, six situations.
Paiement refusé (#payment)
Paiement refusé : échec carte individuel, 3DS, plafond. Le #278 : checkout indisponible pour tous, pas diagnostic bancaire.
Plan BFCM (#251)
Staffing BFCM (#251) : headcount pic. Le #278 : communication crise quand le pic devient panne.
Erreurs prix (#247)
Erreurs prix (#247) : bug affichage tarif. Le #278 : indisponibilité technique, pas litige prix.
Triage bot (#236)
Triage (#236) : routing intent. Le #278 ajoute intent platform_outage priorité P0.
Gestes commerciaux (#238)
Gestes (#238) : recovery post-incident avec plafonds encadrés.
Messages proactifs (#proactive)
Messages proactifs : widget promo. Le #278 : bannière incident et mode bot dégradé. Détail technique fallback API : mode dégradé bot (#279).
Promesse #278
Grille SEV, war room, templates 4 phases, macros INC-*, bot, paniers bloqués, post-mortem client, playbooks pré-staging.
Comment classifier la sévérité d'un incident checkout ?
La grille sévérité incident SAV fixe délais communication et canaux avant que l'ingénieur confirme la cause.
SEV1 : checkout ou paiement down total
Symptômes : 0 commande confirmée, erreur checkout 100 %, vitrine down
Premier message : sous 5 min sur surfaces owned
Fréquence updates : toutes les 15-20 min
Canaux : status page + Instagram/Stories + bannière site si possible
SEV2 : perte partielle
Shop Pay OK, CB KO. Apple Pay down, reste up. PayPal seulement. Update sous 15 min, toutes les 30 min. Status page + social si > 45 min.
SEV3 : dégradation performance
Checkout lent, timeouts sporadiques. Update sous 30 min. Status page seule sauf escalade SEV2.
Matrice décision rapide
Monitoring checkout (Better Stack, Pingdom body assertion) + alerte Slack #incident. Si 3 échecs checkout test consécutifs depuis 2 pays → SEV1 par défaut. AlertSleep : poster « Investigating » même sans cause identifiée (AlertSleep, outage comms 2026).
Qui fait quoi pendant les deux premières heures ?
Le war room incident support sépare résolution technique et voix client dès T+0.
RACI minimal PME DTC
Incident commander (fondateur ou ops) : décision SEV, liaison Shopify/PSP
Customer comms owner : status page, social, macros (1 personne dédiée)
Support lead : file tickets, agents, bot mode incident
Tech : diagnostic, pause ads Meta/Google si checkout down
Timeline T+0 à T+120 min
T+0-5 : ack Slack #incident, SEV assigné, comms owner nommé
T+5 : post status « Investigating » + bannière si CDN accessible
T+10 : macro INC-* activée Gorgias, bot mode outage
T+15 : pause campagnes acquisition checkout (manual ou règle)
T+20 à résolution : update status toutes les 15-20 min SEV1
T+ résolution +15 : post « Resolved » + e-mail paniers actifs si applicable
Règle Digital Applied juin 2026
Sur plateforme hébergée, vous ne contrôlez pas toujours la page d'erreur Shopify. Pré-stagez donc e-mail, social, domaine secours et status page hors plateforme (Digital Applied, surfaces owned).
Quels messages publier à chaque phase de l'incident ?
Quatre templates communication incident couvrent le cycle complet. Adapter [SERVICE], [TIME], [TZ].
Phase 1 : Investigating (T+5 min)
« Nous constatons des difficultés sur le paiement / checkout. Notre équipe enquête. Vous pouvez parcourir le site et remplir votre panier. Nous publions une mise à jour avant [heure + 20 min]. Statut : [URL status]. » Préciser ce qui marche vs ce qui est down.
Phase 2 : Identified (cause connue)
« La cause est identifiée ([prestataire paiement / plateforme]). Correction en cours. Checkout de retour estimé vers [heure]. Si vous avez vu une erreur dans les 15 dernières minutes, votre panier est sauvegardé, pas besoin de tout ressaisir. »
Phase 3 : Monitoring (fix déployé)
« Le checkout est rétabli. Nous surveillons la stabilité. Si un problème persiste, contactez-nous avec une capture d'écran. Merci de votre patience. »
Phase 4 : Resolved (clôture)
« Incident résolu à [heure]. Durée : [X min]. Impact : paiement temporairement indisponible. Aucune donnée bancaire compromise. Commandes passées pendant la fenêtre : voir section paniers bloqués. Désolés pour la gêne. » AlertSleep recommande post-mortem public si > 30 min (AlertSleep, post-mortem).
Interdits rédactionnels
« Problème chez notre hébergeur » sans info utile. « Revenez plus tard » sans heure. Jargon technique « Error 502 » seul. Promettre remboursement automatique non validé finance.
Quelles macros support activer immédiatement ?
Six macros incident technique SAV standardisent les réponses pendant que comms owner met à jour la status page.
INC-SITE-DOWN
« Bonjour, nous avons une interruption technique affectant [checkout / le site]. Ce n'est pas un problème avec votre compte. Suivez les mises à jour : [URL status]. Dernière info : [copier phrase status]. Je reste disponible pour votre commande en cours #[num] si applicable. »
INC-CHECKOUT-FAIL
« Le paiement ne aboutit pas chez nous en ce moment à cause d'un incident en cours. Aucun débit final n'est effectué tant que vous n'avez pas reçu la confirmation commande. Votre panier est conservé. Réessayez après [heure estimée] ou activez l'alerte sur [status URL]. »
INC-CHARGED-UNSURE
« Je comprends l'inquiétude. Vérifions : avez-vous reçu un e-mail « Commande confirmée » avec numéro #[format] ? Si non, il s'agit souvent d'une pré-autorisation temporaire libérée sous 3-7 j ouvrés. Je consulte notre système dès rétablissement : [e-mail client]. »
INC-ORDER-LIMBO
« Votre tentative pendant l'incident est enregistrée. Nous reconcilions les commandes sous 24 h. Si payée et confirmée : expédition normale. Si payée sans confirmation : nous vous recontactons avec remboursement ou validation. Référence : INC-[date]-[ticket]. »
INC-VIP-PRIORITY
Même fond INC-SITE-DOWN + « Je traite votre dossier en priorité et vous écris sous 2 h après rétablissement. » Aligner policy VIP (#207).
INC-SOCIAL-PUBLIC
Réponse courte DM/commentaire : « Incident technique en cours, pas lié à votre compte. Mises à jour : [lien]. MP ouvert si commande urgente. » Ne jamais débattre en thread public.
Comment configurer le bot pendant une panne ?
Le mode bot incident checkout remplace les intents produit par réponses statut et handoff rapide.
Activation
Toggle « incident_mode » Notion ou Gorgias tag global incident_active. Bot lit flag au début session. Si true : skip recommandations produit, skip promos, intent checkout_error → macro INC-CHECKOUT-FAIL.
Intents prioritaires P0
site_down,checkout_error,payment_failed_masscharged_no_confirmationwhen_back_online
Réponse bot type
« Incident technique en cours sur le paiement. Ce n'est pas votre carte. Statut live : [lien]. Panier sauvegardé. Mise à jour prévue à [heure]. Un agent peut reprendre si commande urgente (> 200 € ou date événement). » Handoff si 2e message même sujet ou sentiment angry.
Guardrails
Bot ne promet pas délai fixe non validé comms owner. Bot ne confirme pas commande sans lookup Shopify OK. Voir gouvernance bot (#142). Triage P0 #236.
Bannière widget
Remplacer message promo par : « Checkout temporairement indisponible. [Lien status]. » Messages proactifs en mode alerte.
Comment traiter paniers bloqués et prélèvements douteux ?
Le protocole paniers incident évite double commande et chargebacks post-résolution.
Pendant l'incident
Ne pas demander au client de « réessayer 10 fois »
Collecter e-mail + SKU panier via formulaire Typeform secours si checkout down
Tag ticket
incident_stranded_cart
Après rétablissement (sous 24 h)
Export Shopify orders créées pendant fenêtre incident
Croiser logs PSP : captured vs authorized only
Liste B : payé sans order Shopify → contact client choix refund ou push order manuelle
Liste C : abandoned carts haute valeur → e-mail recovery avec lien panier + code INC-RETRY5 (-5 % max, aligné gestes #238)
Script charged_no_order
« Notre système confirme une autorisation bancaire sans commande finalisée le [date] à [heure]. Nous lançons remboursement sous 48 h ou validons votre commande manuellement selon votre préférence. Référence PSP : [id]. » Documenter dans registre décisions.
BNPL et wallets
Si Shop Pay / Klarna / Alma : même logique, vérifier dashboard financeur post-incident. Voir paiement fractionné (#194) pour sync refund.
Quels pièges communication éviter pendant une panne ?
Sept anti-patterns communication incident amplifient la crise.
Erreurs fréquentes
Silence 30+ min : client assume arnaque ou faillite
Agents contradictoires : l'un dit « c'est réglé », l'autre « on ne sait pas »
Blâmer Shopify en public : vous restez la marque visible
Promettre -20 % à tous : budget gestes explosé, attente future
Continuer ads checkout : CPA brûlé pendant panne
Ignorer social : 80 % verbatins publics pendant SEV1
Fermer tickets en masse sans vérifier paniers limbo
Réponse type tweet négatif juin 2026
« Nous avons vécu la même interruption que des milliers de boutiques aujourd'hui. Checkout rétabli à [heure]. Si votre commande pose question : [support email]. Transparence : [lien status/post-mortem]. »
Single source of truth
Comms owner seul modifie le paragraphe canonique copié par agents, bot et social. Slack épinglé #incident avec dernière formulation.
Quels KPI suivre pendant et après l'incident ?
La mesure incident support prouve ROI communication et alimente post-mortem interne.
KPI pendant (live)
Time to first public update : cible < 5 min SEV1
Tickets / 15 min vs baseline même tranche horaire
First response time incident-tagged
Social mentions négatifs volume
KPI post (J+1 à J+7)
Stranded carts recovered %
Chargebacks incident window
CSAT tickets tag incident_*
Repeat purchase 7 j clients contactés INC-*
Reduction tickets vs incident sans comms (benchmark interne)
Post-mortem interne 48 h
Timeline, root cause, ce qui a marché comms, actions préventives. Partager version client allégée sur blog ou status page si SEV1 > 30 min.
Comment Qstomy gère-t-il les incidents checkout côté support ?
Qstomy bascule en mode incident : intents checkout priorisés, lien status injecté, handoff enrichi pour paniers limbo.
Capacités
Toggle incident_mode : 1 clic, sync widget + réponses
Status URL dynamique dans chaque réponse bot
Intent checkout_error P0 : bypass promo flows
Collecte e-mail panier si checkout inaccessible
Export tickets incident_* pour reconciliation J+1
Scénario DTC chiffré
Marque cosmétiques, panne PSP 38 min, trafic ads actif. Avant runbook : 127 tickets, FRT 18 min, 4 chargebacks. Après Qstomy incident_mode + 6 macros INC + status page : 29 tickets qualifiés, FRT 4 min, 0 chargeback, recovery paniers e-mail J+1 34 %, CSAT post-incident 3,8/5.
Explorez support client IA, Shopify, demander une démo.
Quels playbooks préparer avant la prochaine panne ?
Playbook 1 : status page (2 h)
Créer page status domaine owned (Better Stack, Instatus). Embed lien footer + bio Instagram. Tester post manuel.
Playbook 2 : macros INC-* (1 h)
Importer 6 templates section 6 dans Gorgias. Tag auto incident_active sur règle mot-clé « site down », « checkout », « paiement impossible ».
Playbook 3 : war room doc (1 h)
Notion 1 page : RACI section 4, liens Shopify status, PSP, templates section 5, contact Meta ads pause.
Playbook 4 : drill trimestriel (45 min)
Simulation tabletop : « checkout down 10 h00 ». Chronométrer first update. Corriger gaps.
Playbook 5 : bot incident_mode (2 h)
Configurer section 7. Pack test 10 messages. Lier triage (#236).
Playbook 6 : reconciliation template
Sheet colonnes section 8 prête. Owner finance + support. Maillage : paiement refusé, plan BFCM (#251), escalade (#193).
La panne de juin 2026 a rappelé une règle simple : vous ne contrôlez pas toujours la page d'erreur, mais vous contrôlez toujours ce que votre équipe support répond.
Enzo
30 juin 2026
