Vendredi 28 novembre, 08h47. L’alerte tombe.
Le Slack du canal #incidents-prod vibre. Un message automatique, rouge, urgent : “P95 latency API checkout > 3s. Threshold: 500ms. Duration: 2 min.”
On est le Black Friday. Le trafic est 8 fois supérieur à un jour normal. Le retailer que nous accompagnons fait 15% de son CA annuel aujourd’hui. Chaque minute de dégradation, c’est des dizaines de milliers d’euros qui s’évaporent.
Voici comment l’observabilité — pas la chance, pas l’héroïsme, l’observabilité — nous a permis de résoudre l’incident en 4 minutes et de sauver une journée à 2 millions d’euros de CA.
Les 3 mois de préparation qu’on ne voit pas
Le Black Friday ne se gagne pas le jour J. Il se gagne 3 mois avant, quand personne n’y pense encore.
Septembre : l’audit de la stack de monitoring
En septembre, nous avons réalisé un audit complet de la couverture d’observabilité. Le constat était brutal :
- Logs : présents mais non structurés. Chercher une information revenait à chercher une aiguille dans une botte de foin.
- Métriques : monitoring basique (CPU, RAM). Aucune métrique business (taux de conversion, panier moyen, taux d’erreur checkout).
- Traces : inexistantes. Impossible de suivre une requête de bout en bout dans l’architecture microservices.
- Alertes : configurées sur des seuils arbitraires. L’équipe recevait 50 alertes par jour, dont 45 fausses.
Octobre : la mise en place
En 4 semaines, nous avons déployé une stack d’observabilité complète :
Les 3 piliers :
- Logs structurés (JSON) avec corrélation par request ID. Chaque log contient le tenant, l’utilisateur, l’action, et le contexte.
- Métriques : techniques (latence, error rate, saturation) ET business (conversions/minute, CA/minute, abandon panier).
- Traces distribuées : OpenTelemetry sur chaque service. On peut suivre une requête du navigateur client jusqu’à la base de données, en passant par tous les services intermédiaires.
L’intelligence des alertes :
Nous avons remplacé les seuils statiques par des alertes basées sur les anomalies. Au lieu de “alerte si latence > 500ms”, c’est “alerte si la latence dévie de plus de 3 écarts-types par rapport à la normale pour ce jour et cette heure”.
Résultat : de 50 alertes/jour, nous sommes passés à 3-5 alertes pertinentes par semaine.
Novembre : les war games
Deux semaines avant le Black Friday, nous avons organisé des game days : des simulations d’incidents en production.
Les scénarios testés :
- Base de données primaire qui tombe : le failover automatique fonctionne-t-il ?
- Service de paiement qui ralentit : le circuit breaker s’active-t-il ?
- Pic de trafic x10 : l’autoscaling suit-il ?
- CDN qui dysfonctionne : le fallback est-il en place ?
Chaque scénario a révélé des failles. Le failover DB prenait 45 secondes au lieu de 5. Le circuit breaker était mal configuré. L’autoscaling avait un délai de 8 minutes. Tout a été corrigé avant le jour J.
Le jour J : anatomie d’un incident résolu en 4 minutes
08h47 — L’alerte
Le système détecte une anomalie : la latence du service checkout explose. Le dashboard dédié Black Friday s’affiche automatiquement dans le canal Slack.
En un coup d’oeil, l’astreinte voit :
- Quoi : latence P95 à 3.2s sur l’API checkout (normal : 200ms)
- Depuis quand : 2 minutes
- Impact : taux de conversion en chute de 40% sur les 2 dernières minutes
- Où : localisé sur le service checkout, pas sur les autres services
08h48 — Le diagnostic
L’astreinte ouvre la trace d’une requête lente. En 30 secondes, la cause apparaît : le service checkout fait un appel au service d’inventaire qui timeout systématiquement.
Pourquoi ? Le service d’inventaire est saturé. Ses métriques montrent : CPU à 98%, connexions DB au maximum, queue de requêtes en attente qui s’allonge.
Le pourquoi du pourquoi : une requête de synchronisation d’inventaire, programmée la veille par erreur à 08h45, verrouille des tables critiques pendant son exécution. Le jour normal, ça passe inaperçu. Le Black Friday avec 8x le trafic, c’est catastrophique.
08h49 — La décision
Deux options :
- Tuer la requête de synchronisation (risque : données d’inventaire légèrement décalées)
- Scaler le service d’inventaire (temps : 3-4 minutes, trop long)
L’astreinte choisit l’option 1. La requête est identifiée et tuée via le dashboard de monitoring DB.
08h51 — La résolution
La requête est tuée. En 30 secondes, les connexions DB se libèrent. La latence du service d’inventaire retombe à la normale. Le service checkout récupère. Le taux de conversion remonte.
Temps total d’incident : 4 minutes. Impact estimé sur le CA : inférieur à 15K euros, au lieu des 200K+ euros qu’aurait coûté une heure de dégradation.
Ce qui aurait pu se passer sans observabilité
Imaginons le même scénario sans la stack d’observabilité :
- Détection : au lieu de 2 minutes, l’incident est détecté quand les clients appellent le service client. Délai : 15 à 30 minutes.
- Diagnostic : sans traces distribuées, l’équipe passe 30 minutes à chercher la cause. “C’est le réseau ? Le CDN ? La base ?”
- Résolution : sans identification précise, on essaie des solutions au hasard. On relance des services, on scale des pods. Rien ne marche parce que le vrai problème est une requête SQL.
- Durée totale : 1h30 à 2h.
- Impact CA : 200K à 400K euros.
La différence entre 4 minutes et 2 heures, c’est la différence entre un Black Friday réussi et un Black Friday catastrophique.
Les 7 leçons tirées
1. Monitorez le business, pas juste la technique
Le CPU et la RAM ne racontent pas l’histoire complète. Le taux de conversion par minute, le CA par minute, le taux d’abandon panier en temps réel — ce sont ces métriques qui vous disent si votre business fonctionne.
2. Les traces distribuées sont non négociables
Dans une architecture microservices, sans traces, vous êtes aveugle. OpenTelemetry est gratuit, open-source, et s’intègre en quelques heures. Il n’y a aucune excuse pour ne pas l’avoir.
3. Les alertes intelligentes sauvent des nuits
Les seuils statiques génèrent du bruit. Les alertes basées sur les anomalies génèrent du signal. La différence entre “alerte fatigue” et “réactivité”, c’est l’intelligence de vos alertes.
4. Les game days révèlent la vérité
Votre plan de reprise n’a jamais été testé ? Alors vous n’avez pas de plan de reprise. Testez en conditions réelles, régulièrement.
5. Le runbook doit être automatisé
Chaque type d’incident connu doit avoir un runbook. Et chaque runbook doit être partiellement automatisé. L’humain décide, la machine exécute.
6. L’astreinte doit s’entraîner
L’astreinte du Black Friday, ce n’est pas le moment de découvrir les dashboards. L’équipe doit s’entraîner sur les outils, les procédures, les escalades.
7. Le post-mortem est obligatoire
Chaque incident, même résolu rapidement, mérite un post-mortem. Pas pour blâmer, mais pour apprendre. La requête de synchronisation mal programmée ? Elle a été déplacée à 3h du matin et plafonnée en ressources.
Le coût de l’observabilité vs le coût de l’aveuglement
La stack d’observabilité complète pour ce client coûte environ 3K euros par mois. L’incident du Black Friday aurait pu coûter 200K euros ou plus sans cette stack.
Le ROI de l’observabilité ne se calcule pas sur les jours normaux. Il se calcule sur le pire jour de l’année. Et ce jour-là, 3K euros par mois, c’est le meilleur investissement que vous puissiez faire.
FAQ
Quel outil d’observabilité choisir en 2026 ?
Pour les PME, Grafana Cloud offre le meilleur rapport qualité-prix. Pour les entreprises avec plus de budget, Datadog est la référence en termes de facilité d’utilisation et d’intégrations. L’important est d’avoir les 3 piliers (logs, métriques, traces) dans un outil unifié.
Combien de temps faut-il pour mettre en place une stack d’observabilité complète ?
Comptez 4 à 6 semaines pour une mise en place complète avec instrumentation du code, dashboards, alertes et runbooks. L’instrumentation OpenTelemetry prend 2-3 jours par service. Le reste du temps est consacré aux dashboards et à l’intelligence des alertes.
Faut-il monitorer les environnements de staging aussi ?
Oui, mais avec moins de rétention et d’alertes. Le staging doit avoir la même instrumentation que la production pour que les développeurs prennent l’habitude d’utiliser les outils d’observabilité au quotidien, pas uniquement en cas de crise.
Comment convaincre le management d’investir dans l’observabilité ?
Chiffrez le coût d’un incident. Prenez votre CA par heure, multipliez par le temps moyen de résolution actuel, et multipliez par le nombre d’incidents par an. Le résultat sera toujours supérieur au coût d’une stack d’observabilité. C’est une assurance, et comme toute assurance, elle paraît chère jusqu’au jour où on en a besoin.