La production est en feu dans le développement — ce que c'est, causes et plan d'action

Ce que signifie « la production est en feu » et les types de pannes

L'expression « la production est en feu » (tout est tombé) décrit une situation où l'environnement de production fonctionne incorrectement et les utilisateurs sont affectés. La panne peut se manifester par une indisponibilité totale de l'application (écran blanc, erreur 502), une indisponibilité partielle (le module de paiement ne fonctionne pas mais les autres fonctions sont disponibles) ou une dégradation des performances (chargement extrêmement lent). La gravité de l'incident est déterminée par le pourcentage d'utilisateurs affectés et la durée de la panne.

Selon Atlassian Statuspage (2025), le temps d'arrêt moyen pour les applications mobiles en 2024 était de 27 minutes par incident. Les causes les plus fréquentes : régression de code après déploiement (34 %), panne du fournisseur cloud (22 %), problèmes de base de données (18 %), erreurs de configuration (15 %) et attaques DDoS (11 %). Principal enseignement : la plupart des pannes sont causées par des changements que l'équipe a elle-même introduits, et non par des facteurs externes.

Il est important de distinguer un crash (plantage de l'application côté client) d'une panne backend (indisponibilité du serveur). Un crash est généralement corrigé par un hotfix du code client, tandis qu'une panne backend nécessite des changements d'infrastructure ou un redéploiement du service. Métriques de surveillance : pour le client — taux sans crash, pour le serveur — taux d'erreur 5xx et latence p95. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — aide à déterminer rapidement le type de panne.

Gravité des incidents : P0, P1, P2 et critères de classification

Une classification unifiée de la gravité est la base d'une réponse rapide. Sans elle, l'équipe perd du temps à discuter « à quel point c'est urgent » au lieu d'agir. L'échelle classique : P0 (critique) — l'application est totalement indisponible ou des données utilisateur fuient, temps de réponse — immédiat ; P1 (élevé) — une fonctionnalité critique ne fonctionne pas pour 50 %+ des utilisateurs, temps de réponse — 15 minutes ; P2 (moyen) — une fonctionnalité non critique est indisponible pour certains utilisateurs, temps de réponse — 1 heure.

P0 nécessite une escalade immédiate : l'ingénieur de garde interrompt tout travail en cours et se concentre sur l'incident. Si le problème n'est pas résolu en 10 minutes — le tech lead est impliqué. Si après 30 minutes — escalade vers le responsable engineering. Pour les incidents P0, il est permis de contourner tous les processus : faire un hotfix sans révision complète du code, déployer directement en production, ignorer les règles de protection de branche. L'override d'urgence doit être préalablement convenu au niveau de l'équipe.

Tableau de gravité

Il est extrêmement important de ne pas sous-estimer la gravité. Les incidents P0 et P1 classifiés comme P2 entraînent une réponse tardive et une augmentation du temps d'arrêt. Règle : en cas de doute — définissez P0. La surclassification vaut mieux que la sous-classification : il vaut mieux organiser une réunion supplémentaire que de perdre une heure de récupération.

Les 10 premières minutes : algorithme d'action en cas de panne

Le chronomètre démarre : à partir du moment où une alerte ou un message d'un utilisateur arrive. Les 10 premières minutes sont les plus importantes. Algorithme : 1) confirmer le problème — s'assurer que le problème est réel (pas une fausse alerte) ; 2) arrêter l'hémorragie — réduire immédiatement l'impact (rollback, feature toggle, blocage d'endpoint) ; 3) communiquer — écrire dans le canal général #incident le statut : ce qui s'est passé, la gravité, ce qui est fait. Les 10 premières minutes ne sont pas consacrées à l'analyse de la cause racine.

En parallèle de l'arrêt de l'hémorragie, un ingénieur commence le diagnostic tandis qu'un autre gère la communication. Canaux de communication : canal Slack #incident (pour l'équipe), page de statut (pour les utilisateurs), e-mail/SMS d'escalade (pour la direction). Toutes les 15 minutes — une mise à jour de statut avec les informations : ce qui est connu, ce qui est fait, le temps de récupération estimé. Page de statut (StatusPage, Statuspal) affiche le temps de disponibilité et l'historique des incidents pour les utilisateurs externes.

Comment arrêter l'hémorragie : rollback, feature toggle et hotfix

La première règle et la plus importante : n'essayez pas de résoudre le problème en production. Si une nouvelle version a causé la panne — effectuez un rollback vers la version stable précédente. Si la panne est causée par une fonctionnalité spécifique qui se trouve derrière un feature toggle — désactivez simplement le toggle. Si ni le rollback ni le toggle ne sont disponibles — appliquez un hotfix avec un diff minimal. Le rollback est l'option la plus sûre car il revient à un état qui fonctionnait déjà.

Le feature toggle (également appelé feature flag) est un outil puissant pour arrêter l'hémorragie sans déploiement. Si le module de paiement tombe mais est désactivé via un toggle — les utilisateurs ne voient tout simplement pas le bouton de paiement au lieu de recevoir un écran d'erreur. Un toggle ne nécessite pas de build, ne nécessite pas de révision de store et prend effet en quelques secondes. Chaque fonctionnalité critique doit être derrière un feature toggle avec possibilité de désactivation au niveau du serveur (configuration à distance). Le feature flag — la première ligne de défense.

Si le rollback est impossible (par exemple, en raison d'une migration de base de données irréversible) et qu'aucun toggle n'est en place — le dernier recours est un hotfix avec des modifications minimales. Le hotfix est créé à partir du dernier tag de version, contient uniquement les lignes nécessaires pour corriger la panne et passe par un déploiement accéléré (voir l'article « Hotfix — corrections urgentes »). Règle d'or : après la stabilisation, effectuez toujours une analyse de cause racine, même si la cause semble évidente.

Diagnostic des causes : logs, métriques et alertes

Après avoir arrêté l'hémorragie (ou en parallèle, si le nombre d'ingénieurs le permet), le diagnostic commence. La première source est les logs. La journalisation centralisée (ELK, Grafana Loki, Datadog Logs) permet de trouver les erreurs par horodatage, ID utilisateur ou ID de requête. Important : les logs doivent être structurés (JSON) pour que grep fonctionne rapidement. La journalisation structurée est une exigence obligatoire pour tous les services.

La deuxième source est les métriques. Grafana, Datadog, New Relic montrent quand le pic d'erreurs s'est produit, sur quels endpoints et avec quels codes de statut. La comparaison des métriques avant et après le déploiement aide à localiser le problème sur un service ou un endpoint spécifique. Les métriques RED (Rate, Errors, Duration) — la norme de surveillance des microservices.

La troisième source est le tracing distribué (distributed tracing). Jaeger, Zipkin, Datadog APM montrent le chemin de la requête à travers les microservices et identifient où exactement le retard ou l'erreur s'est produit. Le tracing est particulièrement utile pour les défaillances en cascade, lorsqu'une panne dans un service provoque des erreurs dans tous les services dépendants. L'ID de trace doit être transmis du client à tous les services backend.

# Exemple de diagnostic rapide avec kubectl et les logs
# Lister les pods en erreur
kubectl get pods --field-selector=status.phase!=Running

# Vérifier les logs du pod planté
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Rechercher les erreurs dans le service des 30 dernières minutes
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Important : n'essayez pas de diagnostiquer la cause avant d'arrêter l'hémorragie. Si 50 % des utilisateurs voient un crash — effectuez d'abord le rollback, puis enquêtez. Exception : si un rollback prendrait plus de temps qu'un hotfix direct (par exemple, en raison d'une incompatibilité de données). Dans ce cas, appliquez le hotfix immédiatement et effectuez le post-mortem après la stabilisation. Diagnostiquer avant de corriger est un modèle dangereux qui augmente le temps d'arrêt.

Post-mortem : comment analyser les incidents sans chercher de coupables

Le post-mortem (également appelé révision d'incident) est une analyse structurée de l'incident réalisée 24 à 72 heures après sa résolution. Son objectif : comprendre pourquoi la panne s'est produite, pourquoi la surveillance et les tests ne l'ont pas détectée avant la production, et quoi modifier dans les processus pour prévenir la récurrence. La culture sans reproche est un principe fondamental : le post-mortem discute des processus, des outils et de la communication, et non des erreurs de personnes spécifiques.

Structure du document post-mortem : chronologie (séquence d'événements avec horodatages), impact (utilisateurs affectés, durée, pertes financières), cause racine (cause technique principale), détection (comment cela a été découvert, pourquoi cela n'a pas été détecté plus tôt), réponse (ce qui a été fait, ce qui aurait pu être fait plus rapidement), actions (tâches spécifiques avec responsables et délais). Les actions doivent être S.M.A.R.T. : spécifiques, mesurables, assignables, réalistes et limitées dans le temps.

Actions typiques après une panne de production : ajouter une surveillance et des alertes pour la métrique qui était silencieuse ; étendre la couverture de test pour le cas manqué ; ajouter une page au runbook avec un algorithme étape par étape pour une situation similaire ; organiser une formation de l'équipe sur l'outil qui a été utilisé incorrectement. Chaque action est un changement concret qui réduit la probabilité de récurrence de l'incident.