Playbook de réponse aux incidents pour petites et moyennes équipes

En bref : Quand vendredi à 23:30 le serveur de production tombe, ce n'est pas le moment d'inventer la procédure à partir de zéro. Un playbook de réponse aux incidents est un document qui définit les rôles, communication et procédures avant d'en avoir besoin. Voici un playbook minimal adapté à une équipe de 5-20 personnes.

Rôles pendant un incident

Des rôles clairs éliminent le chaos. Même une petite équipe a besoin au minimum :

• Incident Commander (IC) - gère l'incident, prend les décisions, escalade. N'écrit pas de code.
• Technical lead - la personne qui connaît la zone à problème. Écrit le fix.
• Communications lead - met à jour la status page, les clients, le management. Pour une petite équipe peut être la même que IC.
• Scribe - écrit la timeline, qui fait quoi, quand. Crucial pour le post-mortem.

Dans une équipe jusqu'à 5 personnes typiquement IC + Technical lead = 2 rôles divisés, autres pris par IC.

Niveaux de severity

Définissez 3-4 niveaux de gravité à l'avance :

• SEV1 (Critical) - service principal complètement indisponible. Réaction immédiate, paging même la nuit.
• SEV2 (Major) - dégradation significative (partie des features, certains utilisateurs). Réaction dans 30 min pendant heures de travail, dans 1 h hors.
• SEV3 (Minor) - petit impact, workaround existe. Réaction d'ici prochain jour ouvré.
• SEV4 (Cosmetic) - sans impact user-facing, va dans la queue normale.

Procédure SEV1 : les 15 premières minutes

1. 00:00 - Détection. L'alerte vient du monitoring ou d'un client. Quelqu'un en rotation on-call confirme que le problème est réel.
2. 00:02 - Activation IC. Un canal de communication dédié s'ouvre (Slack #incident-N ou Discord). On appelle le Technical lead.
3. 00:05 - Premier status update. Sur la status page publique : "Investigating reports of [problème]." Email aux personnes internes qui devraient savoir.
4. 00:10 - Initial diagnostics. Vérifiez les deploys récents, graphes monitoring, error logs. Qu'a changé dans les 30-60 dernières min ?
5. 00:15 - Décision : rollback, hotfix ou workaround ? Si pas immédiatement clair, IC escalade ou appelle d'autres ingénieurs.

Communication : la règle "5 + 30"

Mise à jour de la status page au moins toutes les 30 minutes pendant SEV1, même si vous n'avez pas de nouvelles infos. "Investigons toujours, ETA toujours inconnu" est une meilleure mise à jour que le silence - les clients savent au moins que quelqu'un travaille sur le problème.

La première mise à jour doit être dans les 5 minutes après la détection. Indépendamment de si vous connaissez la cause.

Rollback par défaut

Lors d'un SEV1 qui a commencé peu après un deploy, le rollback est le premier choix, pas le hotfix. Hotfix sous pression la nuit est source d'autres bugs. Le rollback restaure un état connu bon et donne du temps pour diagnostic calme le matin.

Pour le rollback il faut avoir :

• Versioning du déploiement (tags Docker, tags Git, artefact de déploiement)
• Database migrations backwards compatible (si nouvelle version drop une colonne, l'ancienne ne récupère pas)
• Procédure de rollback documentée (commandes, combien de temps, qui peut le lancer)

Post-mortem sous 48 heures

Après chaque incident SEV1/SEV2 écrivez un document avec structure :

1. Summary - 2-3 phrases ce qui s'est passé, combien de temps a duré, qui a affecté
2. Timeline - temps exacts de détection, actions clés, résolution
3. Root cause - pourquoi c'est arrivé (raison technique + raison procédurale)
4. Impact - nombre de clients affectés, impact business
5. What went well - ce qu'on a bien fait (apprécier l'équipe)
6. What went wrong - où on a perdu du temps
7. Action items - tâches concrètes avec owner et deadline (pas "mieux tester" - plutôt "ajouter test d'intégration pour payment flow dans les 14 jours, owner : X")

Règle blameless post-mortem : Vous ne cherchez pas de coupable, vous cherchez une faiblesse systémique. "John a déployé une mauvaise version" est la mauvaise conclusion - la bonne est "le processus de deploy ne contenait pas de phase canary qui aurait attrapé le bug avant le rollout complet".

Rotation on-call

Pour une équipe avec produit 24/7 :

• Rotations hebdomadaires - plus court fait burnout, plus long signifie continuité du contexte
• Toujours primaire + secondaire on-call. Secondaire prend le relais quand primaire ne répond pas dans 5 min.
• Compensation (paiement extra, time-off) pour paging nocturne et week-end
• "On-call review" mensuel - qui a été souvent réveillé, ce qui peut être automatisé

Outils

• Monitoring (ePulz.io, Datadog, New Relic) - détection + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - escalation, rotation, SMS/voix
• Status page (propre, ePulz.io, StatusPage.io) - communication externe
• Hosting runbook (Notion, GitHub Wiki, internal docs) - playbooks et runbooks
• Template postmortem (Confluence, Notion template) - standardisation

Conclusion

La réponse aux incidents ne peut pas être improvisée sous pression. 30 minutes investies dans l'écriture d'un playbook se rentabilisent lors de la première panne majeure - moins de chaos, MTTR plus court, meilleure communication avec les clients et une équipe qui sait quoi faire.

Commencez par la détection automatique

ePulz.io résout les premières minutes de la réponse à un incident : détection + alerting par e-mail, Telegram et webhook vers Slack / Discord / PagerDuty.

Lancer le monitoring →