Lors d'une panne, le problème technique est rarement le plus dur. La coordination l'est. Voici la séquence qui empêche une petite équipe d'aggraver les choses.
La plupart des petites équipes gèrent mal leur première panne sérieuse — non par incompétence, mais parce que tout le monde débogue en même temps, personne ne parle aux clients, et deux personnes déploient des correctifs contradictoires. Le playbook ci-dessous existe pour éviter cela.
Les dix premières minutes
- Déclarez-la. Dites le mot « incident » à voix haute dans le canal de l'équipe. L'ambiguïté sur la gravité coûte plus de temps que n'importe quelle étape technique.
- Nommez un responsable d'incident. Une personne, explicitement. Elle ne débogue pas — elle coordonne, décide et tient la chronologie.
- Évaluez le rayon d'impact : qui est affecté, de l'argent circule-t-il de travers, des données sont-elles en danger. Cela détermine tout le reste.
- Arrêtez l'hémorragie avant de chercher la cause. Rollback, désactivation de la fonctionnalité, page de maintenance. Comprendre peut attendre ; l'impact client, non.
- Publiez un message de statut. Même « nous investiguons » vaut mieux que le silence — c'est le silence qui transforme une panne en problème de confiance.
Des rôles, même à quatre
| Rôle | Fait | Ne fait PAS |
|---|---|---|
| Responsable d'incident | Décide, coordonne, tient la chronologie | Déboguer — dès qu'il le fait, la coordination s'arrête |
| Investigateur | Trouve et corrige la cause | Parler aux clients |
| Communication | Met à jour la page de statut, les clients, l'équipe interne | Spéculer publiquement sur la cause |
Dans une petite équipe, une personne peut porter deux rôles — mais responsable d'incident et investigateur ne doivent jamais être la même personne lors d'un incident sérieux.
Quoi dire aux clients
- Accuser réception vite, même sans réponses — « nous sommes au courant et investiguons » en quelques minutes
- Énoncer l'impact dans leurs termes : ce qu'ils ne peuvent pas faire maintenant, pas quel service est dégradé
- Donner une heure de prochaine mise à jour, et la tenir même si rien n'a changé
- Ne jamais spéculer sur une cause non confirmée — les rétractations coûtent plus de confiance que le silence n'en aurait coûté
- Dire clairement quand c'est résolu, puis fournir une explication écrite si l'impact a été matériel
Après : la partie que tout le monde saute
Un postmortem sous 48 heures, tant que la mémoire est fidèle. Sans blâme — non par politesse, mais parce que le blâme pousse les gens à cacher de l'information, et l'incident suivant devient plus difficile à prévenir.
- Chronologie : ce qui s'est passé, quand, qui a fait quoi — des faits uniquement
- Impact : durée, utilisateurs affectés, conséquences monétaires ou sur les données
- Facteurs contributifs, au pluriel — une cause racine unique est presque toujours une simplification
- Actions avec responsables et dates ; les éléments sans les deux sont décoratifs
- Ce qui a bien marché — la détection ou la réponse qui a fonctionné mérite d'être renforcée
Vous ne vous élevez pas au niveau de votre plan de réponse aux incidents. Vous tombez au niveau de celui que vous avez réellement répété.
Se préparer avant que cela arrive
- Des alertes sur les symptômes que les clients ressentent (le paiement échoue), pas seulement sur les métriques d'infrastructure (CPU élevé)
- Un rollback qui tient en une commande et a été répété au calme
- Une page de statut qui existe avant d'en avoir besoin
- Une escalade écrite : qui on appelle à 3h du matin, et qui si cette personne ne répond pas
- Un exercice — cassez délibérément quelque chose en staging et suivez le playbook
Confirmer le rétablissement par les parcours réels
Un taux d'erreur en baisse peut masquer des données incohérentes. Définir les preuves de rétablissement avant la clôture.
- Noter impact, dernier état fonctionnel et changements récents.
- Choisir une action réversible avec responsable et condition d'arrêt.
- Vérifier parcours essentiels, tâches retardées et rapprochement des données.
Questions fréquentes
Que faire en premier quand la production tombe ?
Déclarer un incident et nommer une personne responsable, puis atténuer avant de diagnostiquer — rollback, désactivation de la fonctionnalité cassée ou mode maintenance. Rétablir le service passe d'abord ; comprendre la cause est une tâche pour après, quand les clients travaillent à nouveau.
Faut-il prévenir les clients immédiatement ?
Oui. Accusez réception en quelques minutes, décrivez l'impact en termes de ce qu'ils ne peuvent pas faire, et engagez-vous sur une heure de prochaine mise à jour. Le silence pendant une panne abîme davantage la confiance que la panne elle-même, et une spéculation que vous rétractez ensuite est pire que les deux.
Faut-il un postmortem pour chaque incident ?
Pour tout ce qui a un impact client, oui — et il doit être écrit sous 48 heures, tant que le souvenir est exact. Restez sans blâme : les équipes qui distribuent les torts obtiennent moins d'informations honnêtes, ce qui rend l'incident suivant plus probable, pas moins.
Faut-il annuler chaque déploiement lié à une panne ?
Non. Examiner d'abord modifications de données et effets externes. Un retour de code ne peut pas toujours annuler ces effets et peut aggraver l'incident.
En plein incident ?
Nous faisons de la réponse technique d'urgence — triage, atténuation, cause racine et le postmortem qui suit.
Pour aller plus loin
Postmortems : les bonnes pratiques pour en écrire un qu'on lit vraiment
La plupart des postmortems sont de l'archéologie : un compte rendu exact de quelque chose que personne ne changera. Un postmortem utile produit un petit nombre de choses qui se font réellement.
Audit technique de MVP : ce que nous vérifions dans les 48 premières heures
La plupart des audits de MVP produisent un document. Un audit utile produit des décisions : ce qui brûle, ce qui peut attendre, et ce que coûte la correction.