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

Rôles pendant un incident

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

• Incident Commander (IC) - gère l'incident, prend les décisions et 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, informe les clients et le management. Dans une petite équipe, cela peut être la même personne que l'IC.
• Scribe - tient la timeline : qui fait quoi, et quand. Un support crucial pour le post-mortem.

Dans une équipe jusqu'à 5 personnes, on sépare généralement l'IC et le Technical lead, et l'IC prend les autres rôles.

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 (une partie des features, certains utilisateurs). Réaction dans les 30 min pendant les heures de travail, dans l'heure en dehors.
• SEV3 (Minor) - petit impact, un workaround existe. Réaction d'ici le prochain jour ouvré.
• SEV4 (Cosmetic) - sans impact user-facing, part 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) et l'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 être au courant.
4. 00:10 - Initial diagnostics. Vérifiez les deploys récents, les graphes de monitoring et les error logs. Qu'est-ce qui a changé dans les 30-60 dernières min ?
5. 00:15 - Décision : rollback, hotfix ou workaround ? Si ce n'est pas immédiatement clair, l'IC escalade ou appelle d'autres ingénieurs.

Communication : la règle "5 + 30"

Mettez à jour la status page au moins toutes les 30 minutes pendant un SEV1, même si vous n'avez pas de nouvelles infos. "Investigation toujours en cours, ETA encore 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 intervenir dans les 5 minutes suivant la détection, que vous connaissiez déjà la cause ou non.

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. Un hotfix écrit la nuit sous pression est une source de nouveaux bugs. Le rollback restaure un état connu et fonctionnel, et vous laisse le temps de diagnostiquer calmement le matin.

Le rollback suppose de disposer de :

• Versioning du déploiement (tags Docker, tags Git, artefact de déploiement)
• Database migrations backwards compatible (si la nouvelle version supprime une colonne, l'ancienne ne la restaure pas)
• Procédure de rollback documentée (commandes, durée, qui peut la lancer)

Post-mortem sous 48 heures

Après chaque incident SEV1/SEV2, rédigez un document avec la structure suivante :

1. Summary - 2-3 phrases sur ce qui s'est passé, combien de temps cela a duré et qui cela a affecté
2. Timeline - les temps exacts de détection, des actions clés et de la résolution
3. Root cause - pourquoi c'est arrivé (raison technique et raison procédurale)
4. Impact - nombre de clients affectés et 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", mais plutôt "ajouter un test d'intégration pour le payment flow dans les 14 jours, owner : X")

Règle blameless post-mortem : Vous ne cherchez pas un coupable, mais 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 un produit 24/7 :

• Les rotations hebdomadaires sont le bon compromis - les plus courtes provoquent l'épuisement, les plus longues surchargent le on-caller primaire
• Prévoyez toujours un on-call primaire + secondaire. Le secondaire prend le relais quand le primaire ne répond pas dans les 5 min.
• Compensez le paging nocturne et de week-end (prime ou repos compensatoire)
• Mettez en place un "on-call review" mensuel - qui a été réveillé le plus souvent et 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, un MTTR plus court, une 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 →