Il est 3h du matin. Votre pager explose. Le site est down. Vous vous connectez en urgence, plusieurs collègues font de même. Chacun commence à investiguer de son côté, à faire des modifications. Personne ne sait exactement ce que font les autres. Les managers appellent pour demander des comptes. Au bout de deux heures de chaos, quelqu’un trouve le problème par hasard. Le lendemain, tout le monde reprend son travail comme si de rien n’était — jusqu’au prochain incident.

Ce scénario, Google l’a vécu des milliers de fois avant de développer une approche structurée. Leur constat : la façon dont vous gérez un incident compte autant que sa résolution technique. Un incident bien géré dure moins longtemps, stresse moins les équipes, et génère des apprentissages durables. Un incident mal géré peut transformer un problème mineur en catastrophe.

Qu’est-ce qu’un incident ?

Définition et distinction

Un incident est un événement qui dégrade ou interrompt un service de manière visible pour les utilisateurs. Il se distingue d’un simple bug ou d’une anomalie par son impact immédiat et sa nécessité d’intervention.

La frontière n’est pas toujours évidente. Une règle simple : si l’événement nécessite une action humaine urgente pour restaurer le service, c’est un incident.

Classification par sévérité

La plupart des organisations classifient les incidents par niveau de sévérité. Cette classification détermine qui est mobilisé et quelle urgence est accordée.

Niveau	Nom courant	Définition	Exemple	Réponse attendue
SEV1	Critique	Service totalement indisponible ou données corrompues	Site inaccessible, perte de données	Mobilisation immédiate, communication externe
SEV2	Majeur	Fonctionnalité critique dégradée pour tous les utilisateurs	Paiements échouent, authentification lente	Mobilisation rapide, communication aux stakeholders
SEV3	Modéré	Fonctionnalité secondaire impactée ou critique pour un sous-ensemble	Export PDF cassé, lenteurs régionales	Traitement dans les heures qui suivent
SEV4	Mineur	Impact limité, workaround disponible	Bug d’affichage, fonctionnalité dégradée avec alternative	Traitement normal, pas d’urgence

Quand déclarer un incident ?

Google recommande de déclarer un incident tôt plutôt que tard. Il est plus facile de désescalader un incident mineur que de rattraper un retard dans la gestion d’un incident majeur.

Critères de déclenchement suggérés :

Le problème nécessite l’intervention de plusieurs équipes
Le problème est visible par les utilisateurs
Le problème n’est pas résolu après une heure d’investigation
Le problème pourrait s’aggraver si non traité

Le cycle de vie d’un incident

Un incident bien géré suit un cycle prévisible. Chaque phase a ses objectifs et ses responsables.

Cycle de vie d'un incident : de la détection au postmortem

Détection

L’incident est découvert, soit par une alerte automatique (monitoring), soit par un signalement utilisateur, soit par observation directe. Plus la détection est rapide, moins l’impact est important.
Triage

Évaluation rapide de la sévérité et de l’impact. Qui doit être mobilisé ? Quelle est l’urgence ? Cette phase ne doit pas durer plus de quelques minutes.
Mobilisation

Les bonnes personnes sont contactées et un incident commander est désigné. Un canal de communication est établi (chat, call, war room).
Mitigation

L’objectif est de restaurer le service, pas de comprendre le problème. Rollback, restart, failover, redirection de trafic — tout ce qui permet de limiter l’impact utilisateur.
Résolution

Une fois le service restauré, on peut prendre le temps de comprendre et corriger la cause racine. Cette phase peut prendre des heures ou des jours.
Clôture et Postmortem

L’incident est officiellement clos. Un postmortem est programmé pour analyser ce qui s’est passé et identifier les améliorations.

Gestion structurée des incidents

Le problème des incidents non structurés

Voici ce qui se passe typiquement lors d’un incident sans structure :

Plusieurs personnes investiguent en parallèle sans coordination
Des modifications sont faites sur le système sans que tout le monde soit au courant
Les managers bombardent l’équipe de questions, interrompant le travail
Personne ne sait qui décide quoi
Les communications externes sont incohérentes ou absentes
Le stress monte, les erreurs s’accumulent

Google a observé que ces incidents “non managés” durent en moyenne beaucoup plus longtemps et causent plus de dégâts que les incidents structurés.

Les rôles dans la gestion d’incident

L’approche SRE définit des rôles clairs, inspirés du système de gestion d’incidents d’urgence (ICS) utilisé par les pompiers et les secours.

Les rôles dans la gestion d'incident : Incident Commander, Ops, Communications, Planning

Responsabilité : Coordination globale de la réponse à l’incident.

Ce qu’il fait :

Maintient une vue d’ensemble de la situation
Assigne les rôles et délègue les tâches
Prend les décisions stratégiques (escalade, communication externe)
Ne fait PAS le travail technique lui-même

Profil : Quelqu’un qui garde son calme sous pression, capable de synthétiser et décider rapidement. Pas nécessairement le plus expert techniquement.

Phrase typique : “OK, Mary tu continues l’investigation sur les logs, Robin tu prépares un rollback au cas où. Je fais un point aux stakeholders dans 15 minutes.”

Le document d’incident vivant

Pendant un incident, un document partagé (Google Docs, Notion, wiki) doit capturer l’état en temps réel :

En haut : Sévérité actuelle, incident commander, statut (en cours/résolu)
Résumé : 2-3 phrases sur ce qui se passe
Impact : Utilisateurs affectés, métriques dégradées
Timeline : Chronologie des événements et actions (avec timestamps)
Actions en cours : Qui fait quoi
Décisions prises : Pour référence et postmortem

Ce document sert de “source de vérité” pendant l’incident et de base pour le postmortem ensuite.

Le handoff : passer le relais proprement

Si l’incident dure plus d’un shift (généralement 8-12h), il faut organiser un handoff — un transfert de responsabilité vers une nouvelle équipe.

Le handoff doit être explicite :

Briefing complet de la situation actuelle
Transfert formel du rôle d’incident commander
Confirmation verbale : “Tu es maintenant l’incident commander, OK ?” → “Compris, j’ai le lead.”
Communication à toute l’équipe du changement

Un handoff bâclé peut annuler des heures de travail si le nouveau responsable n’a pas le contexte.

Le postmortem : apprendre sans blâmer

Pourquoi les postmortems sont essentiels

Un incident résolu n’est pas un incident terminé. Sans analyse, les mêmes causes produiront les mêmes effets. Le postmortem est le mécanisme par lequel une organisation apprend de ses échecs.

Les objectifs d’un postmortem :

Documenter ce qui s’est passé (mémoire organisationnelle)
Comprendre les causes profondes (pas juste les symptômes)
Identifier les améliorations concrètes (prévention)
Renforcer ce qui a bien fonctionné (bonnes pratiques)

La culture blameless : condition sine qua non

Le concept de postmortem sans blâme (blameless postmortem) est fondamental. L’idée : les humains font des erreurs. C’est inévitable. Ce qui compte, c’est de concevoir des systèmes qui tolèrent ces erreurs ou les rendent impossibles.

Ce que “blameless” signifie :

On analyse les actions, pas les personnes
On assume que chacun a fait de son mieux avec l’information disponible
On cherche les failles systémiques, pas les coupables
On se demande “pourquoi le système a permis cette erreur ?” plutôt que “qui a fait cette erreur ?”

Ce que “blameless” ne signifie pas :

Ignorer les comportements problématiques répétés
Ne pas identifier qui a fait quoi (la timeline doit être factuelle)
Éviter les discussions difficiles

Quand déclencher un postmortem ?

Définissez vos critères avant qu’un incident ne survienne. Critères courants :

Incident SEV1 ou SEV2
Perte de données, même mineure
Intervention manuelle nécessaire (rollback, failover)
Temps de résolution supérieur à un seuil (ex: 1h)
Échec du monitoring (incident découvert manuellement)
Demande d’un stakeholder

Structure d’un postmortem

Un bon postmortem suit une structure prévisible :

Section	Contenu	Exemple
Résumé	2-3 phrases décrivant l’incident	”Le 15 janvier, le service de paiement a été indisponible pendant 45 minutes suite à un déploiement défectueux.”
Impact	Métriques d’impact chiffrées	”1200 utilisateurs impactés, 340 transactions échouées, 32% de l’error budget mensuel consommé.”
Timeline	Chronologie factuelle avec timestamps	”14:23 - Déploiement v2.3.1 en production. 14:31 - Première alerte latence. 14:35 - Incident déclaré…”
Causes racines	Analyse des facteurs contributifs	”Le déploiement contenait une régression sur la gestion des connexions DB. Les tests d’intégration ne couvraient pas ce scénario.”
Ce qui a fonctionné	Éléments positifs à renforcer	”Le monitoring a détecté le problème en 8 minutes. Le rollback a été effectué en moins de 5 minutes.”
Ce qui peut être amélioré	Faiblesses identifiées	”Pas de test de charge avant déploiement. Pas de canary deployment.”
Actions	Items concrets avec owner et deadline	”Ajouter test de régression DB (Alice, 22 janvier). Implémenter canary deployment (Bob, 15 février).”

La réunion de postmortem

Le postmortem n’est pas juste un document — c’est aussi une réunion où les participants discutent de l’incident.

Timing : Dans les 48-72h suivant l’incident. Assez tôt pour que les souvenirs soient frais, assez tard pour avoir du recul.

Participants : Tous ceux qui ont participé à la gestion de l’incident, plus les personnes qui pourraient apporter un éclairage (équipe produit, experts techniques).

Déroulement :

Lecture de la timeline (rappel des faits)
Discussion des causes (pas de blâme !)
Brainstorm sur les améliorations
Priorisation et assignation des actions
Validation du document final

Règles :

Pas d’interruption pendant la lecture de la timeline
Questions de clarification bienvenues
Pas de “tu aurais dû…” — reformuler en “le système aurait pu…”

Les actions : le vrai livrable

Un postmortem sans actions est un exercice futile. Les actions sont le vrai livrable du processus.

Chaque action doit avoir :

Une description claire de ce qui doit être fait
Un owner responsable de sa réalisation
Une deadline réaliste
Un suivi jusqu’à complétion

Partager les apprentissages

Un postmortem qui reste dans un tiroir ne sert à rien. Google encourage activement le partage :

Repository centralisé : Tous les postmortems accessibles à l’organisation
Newsletter mensuelle : “Postmortem du mois” mettant en avant un cas intéressant
Reading clubs : Sessions où une équipe analyse un postmortem d’une autre équipe
Onboarding : Les nouveaux arrivent lisent les postmortems récents pour comprendre les systèmes

Cultiver la culture postmortem

Les obstacles courants

Introduire une culture de postmortem blameless n’est pas facile. Obstacles fréquents :

Obstacle	Manifestation	Solution
Peur du blâme	Les gens minimisent leurs erreurs	Leadership exemplaire, récompenser la transparence
Manque de temps	”On n’a pas le temps pour des réunions”	Intégrer dans le processus standard, limiter la durée
Actions non suivies	Les mêmes problèmes reviennent	Tracker les actions, revue régulière
Postmortems superficiels	”C’était un bug, on l’a fixé”	Former aux techniques d’analyse (5 Whys, etc.)
Pas de valeur perçue	”Ça ne sert à rien”	Montrer les incidents évités grâce aux actions passées

Le rôle du leadership

La culture blameless doit venir du haut. Si un manager punit quelqu’un après un postmortem, tout l’effort est ruiné.

Le leadership doit :

Participer aux postmortems (montrer que c’est important)
Récompenser la transparence, pas la perfection
Protéger les équipes des demandes de “trouver un coupable”
Célébrer les apprentissages, pas cacher les échecs

Chez Google, les fondateurs eux-mêmes ont participé à des sessions sur les postmortems, envoyant un message clair sur l’importance de cette pratique.

Récompenser les bonnes pratiques

Contrairement à l’intuition, il faut récompenser ceux qui déclarent des incidents et rédigent des postmortems :

Peer recognition pour les postmortems bien rédigés
Valorisation dans les évaluations de performance
Partage public des bons exemples
Jamais de sanction pour avoir causé un incident (sauf négligence répétée)

Pièges courants

Piège	Pourquoi c’est un problème	Comment l’éviter
Chercher un coupable	Tue la transparence, les problèmes sont cachés	Former à la culture blameless, exemplarité du leadership
Postmortem trop tard	Mémoire altérée, détails perdus	Programmer dans les 48-72h systématiquement
Actions sans owner	Rien n’est fait, mêmes incidents	Chaque action a un owner et une deadline
Pas de suivi des actions	Actions oubliées, problèmes récurrents	Revue hebdomadaire des actions ouvertes
Document jamais partagé	Apprentissages perdus	Repository centralisé, newsletter
Timeline incomplète	Analyse impossible	Documenter en temps réel pendant l’incident

À retenir

Structurez la gestion des incidents

Des rôles clairs (incident commander, ops lead, communications) réduisent le chaos et accélèrent la résolution.
Mitigation d’abord, résolution ensuite

Restaurez le service rapidement, même avec une solution temporaire. La compréhension du problème peut attendre.
Postmortem sans blâme, toujours

On analyse les systèmes, pas les personnes. Les humains font des erreurs — les systèmes doivent les tolérer.
Les actions sont le vrai livrable

Un postmortem sans actions concrètes (owner + deadline) est un exercice futile.
Partagez les apprentissages

Un postmortem dans un tiroir ne sert à rien. Rendez-les accessibles, discutez-en, apprenez collectivement.

Pour aller plus loin

Rédiger des postmortems efficaces Templates, anti-patterns et bonnes pratiques pour des postmortems actionnables.

Créer des runbooks Documenter les procédures de réponse aux incidents.

Documentation opérationnelle Les 5 types de documentation pour les équipes ops.

Ressources externes

Managing Incidents (Google SRE Book) — Gestion structurée des incidents
Postmortem Culture (Google SRE Book) — Construire une culture d’apprentissage
Example Postmortem (Google SRE Book) — Template de postmortem Google

La Suite

Vous avez terminé ce module.

Incidents et Postmortems