Anatomie d'un bug détecté à 3h du matin : le récit complet d'un incident chez un client Prod Watch

Histoire vraie, anonymisée. Un mardi de février, un site e-commerce français spécialisé dans la mode démarre une promotion à minuit. À 3h12 du matin, son checkout se met à casser silencieusement. Voici comment Prod Watch a détecté, alerté et permis le fix avant que les premiers acheteurs du matin ne soient bloqués.

1. Le contexte

Notre client, qu'on appellera "Atelier Lou", est une marque française de mode indépendante. CA en ligne : ~1,5 M€/an. Site Shopify customisé avec apps et workflows custom. Trafic moyen : 8 000 sessions/jour, pic à 25 000 lors des soldes.

Atelier Lou est client Prod Watch depuis 6 mois. On monitore 8 parcours critiques toutes les 15 minutes :

• Page d'accueil et catégorie principale.
• Recherche produit.
• Ajout au panier (avec sélection de variantes).
• Checkout invité avec carte Stripe de test.
• Création de compte + email de bienvenue.
• Application d'un code promo.
• Login + accès à l'historique.
• Mise à jour d'adresse de livraison.

Ce mardi soir, l'équipe avait préparé une vente flash avec un code promo FLASH-30 donnant 30% de réduction. Démarrage prévu : minuit pile. Communication : email à la base + Stories Instagram.

2. La timeline minute par minute

00h00 - Le lancement

La promotion démarre. Le code FLASH-30 devient actif. Le trafic commence à monter (300 sessions concurrentes vers 00h30, surtout depuis mobile).

02h47 - Premier signal faible

Un run de monitoring échoue sur le parcours checkout. Le test note : "Timeout 5000ms en attendant l'apparition du bouton de confirmation après application du code promo".

Notre système ne déclenche pas immédiatement d'alerte humaine : on a une politique de 2 échecs consécutifs minimum pour éviter les faux positifs (un timeout réseau ponctuel, par exemple).

03h02 - Deuxième échec

Run suivant, 15 minutes plus tard, même test, même erreur. Cette fois, c'est confirmé : il y a un problème répétable sur le checkout avec code promo.

03h03 - Alerte Slack

Une alerte est postée sur le canal #qa-alerts du client avec :

• Le screenshot de l'étape qui échoue (capture du moment exact où le timeout survient).
• La trace réseau : un appel à /api/checkout/discount qui retourne HTTP 502.
• La vidéo de toute la session de test (45 secondes).
• Un lien direct vers le rapport complet sur le dashboard Prod Watch.

03h08 - Le on-call regarde son téléphone

Antoine, dev senior et de garde cette semaine, a une notification Slack. Il consulte le rapport directement sur son mobile depuis son lit.

La trace réseau est limpide : l'API qui valide le code promo répond 502 systématiquement. Pas un timeout, pas une lenteur : un vrai 502 immédiat. Quelque chose de cassé côté backend.

03h11 - Investigation côté serveur

Antoine ouvre les logs Heroku du worker qui gère les codes promos. Il voit immédiatement :

2026-02-XX 03:14:22 ERROR [discount-worker] connect ECONNREFUSED 10.0.X.Y:6379
2026-02-XX 03:14:22 ERROR [discount-worker] redis client error
... (repete 240 fois en 10 minutes)

Diagnostic : le service Redis externe utilisé pour cacher les codes promos a redémarré (maintenance planifiée du fournisseur), et le worker n'a pas réussi à se reconnecter automatiquement. L'API renvoie 502 par défaut quand Redis est down, et le code promo ne peut pas être validé.

03h22 - Le fix

Antoine redémarre simplement le dyno du worker via Heroku CLI. La connexion Redis se rétablit immédiatement. Pour vérifier, il déclenche un run manuel sur Prod Watch via l'UI.

03h27 - Validation

Le run manuel passe au vert. Le checkout fonctionne à nouveau de bout en bout, code promo inclus. Antoine reçoit la notification "OK" sur Slack et reçoit donc l'autorisation mentale de retourner se coucher.

03h34 - Note pour l'équipe

Avant de dormir, Antoine poste un message dans #dev :

"Incident Redis cette nuit (3h-3h22), worker discount cassé.
Fix : restart dyno. Patch durable demain matin :
brancher un retry exponential + alerting Datadog
sur ECONNREFUSED Redis."

Total temps mobilisé : 25 minutes. Total temps d'incident : 47 minutes (premier échec à 02h47, retour vert à 03h27, mais aucun client réel impacté avant 06h30, heure du premier vrai utilisateur du matin).

3. Pourquoi le diagnostic a été aussi rapide

Sans Prod Watch, voici ce qui se serait probablement passé :

• Vers 7h du matin, premier client matinal essaie de finaliser sa commande avec le code promo, ça plante. Il abandonne.
• Vers 8h30, premiers tickets support entrants (5 à 10 clients en 30 minutes).
• Vers 9h, l'équipe support alerte le CTO qui alerte les devs.
• Vers 9h30, l'équipe commence à investiguer sans avoir accès aux traces réseau du moment de l'incident.
• Vers 10h, premier diagnostic possible (avec 6h de retard).
• Vers 10h30, fix déployé.

Soit 3 à 4 heures de checkout cassé sur les meilleures heures de la matinée, dont la première heure de pic post-promo. Comparé aux 47 minutes en pleine nuit avec Prod Watch.

4. Le suivi du fix durable

Le lendemain matin, l'équipe a :

1. Mis en place un retry exponential avec jitter sur la connexion Redis du worker.
2. Configuré une alerte Datadog sur le pattern ECONNREFUSED Redis.
3. Ajouté un fallback graceful dans l'API : si Redis est down, on revalide le code promo en base SQL (plus lent mais fonctionnel).
4. Demandé à Prod Watch d'ajouter un test ciblé qui valide spécifiquement le flow code promo, indépendamment du reste du checkout.

Trois mois plus tard, le pattern s'est reproduit (autre maintenance Redis), et cette fois aucun impact : le retry a fait son travail, le fallback aussi.

5. Combien on a évité, en chiffres

Estimation par l'équipe d'Atelier Lou, basée sur le trafic moyen et le panier moyen :

Total CA + temps équipe sauvés sur ce seul incident : environ 4 000 €. Soit largement plus que le coût annuel de Prod Watch sur leur forfait.

6. Enseignements

1. Les pannes infrastructure n'attendent pas les heures ouvrées. Au contraire, les fenêtres de maintenance des fournisseurs tombent souvent la nuit, exactement quand votre équipe dort.
2. Le screenshot et la trace réseau valent mille mots. Antoine a diagnostiqué en 3 minutes parce qu'il avait directement accès à l'erreur HTTP 502 sur l'endpoint exact. Sans ces traces, il aurait perdu 30 minutes en exploration.
3. Les codes promo méritent un test dédié. Ce flow est souvent la combinaison la plus complexe (frontend + API + Redis + DB), donc le plus susceptible de casser.
4. Une politique de "2 échecs consécutifs avant alerte" est essentielle. Sinon, vous réveillez votre on-call pour rien et vous générez de l'alert fatigue.
5. Le ROI d'un service de monitoring se mesure sur l'année, pas sur un incident. Mais quand un incident comme celui-ci paye à lui seul l'abonnement annuel, la conversation devient plus simple.