Quand la production tombe, les 60 premières minutes suivent un protocole précis : constater et qualifier l'incident (T+0), désigner un pilote unique et ouvrir la communication (T+5), dérouler les hypothèses par ordre de probabilité (T+10), choisir entre mitigation et correction (T+30), puis rétablir le service ou escalader (T+60). Ce cadre évite les deux pièges qui coûtent le plus cher : l'agitation désordonnée et le redémarrage à l'aveugle qui détruit les indices.
T+0 : constater et qualifier, sans toucher à rien
Avant d'agir, il faut savoir ce qui est réellement cassé. Trois questions en moins de cinq minutes :
- Quel est le périmètre ? Tout est en panne, ou seulement une fonctionnalité, une région, un type d'utilisateur ? Un test depuis un réseau externe évite de confondre panne du service et panne de son propre accès.
- Depuis quand ? L'heure de début, croisée avec les courbes de supervision, délimite immédiatement les causes possibles.
- Quel est l'impact métier ? Vente bloquée, données à risque, ou simple lenteur : la réponse conditionne le niveau d'urgence et qui prévenir.
Règle absolue à ce stade : ne rien redémarrer, ne rien modifier. Un service relancé efface sa mémoire, ses processus en cours et souvent l'explication de la panne.
T+5 : un pilote unique et une communication cadencée
Le facteur qui distingue les incidents bien gérés n'est pas technique, c'est le pilote d'incident : une seule personne qui coordonne, décide et parle. Sans lui, trois ingénieurs modifient la même configuration en parallèle et la direction interrompt les experts toutes les cinq minutes pour demander où on en est.
- Le pilote ouvre un canal dédié à l'incident où tout se consigne : actions, heures, constats. Ce fil devient la mémoire de l'incident et la matière du post-mortem.
- Il publie un premier message de statut, même minimal : « incident en cours sur X, impact Y, investigation en cours, prochain point dans 20 minutes ». Une communication cadencée supprime 80 % des sollicitations.
- Il protège les intervenants techniques : les questions passent par lui, pas par ceux qui investiguent.
T+10 : les hypothèses par ordre de probabilité
On ne cherche pas au hasard : on déroule les causes dans l'ordre statistique où elles se produisent réellement.
- Le dernier changement. Déploiement, migration, modification de configuration ou de DNS dans les dernières heures : c'est la cause la plus fréquente. Question réflexe : « qu'est-ce qui a changé ? »
- Les certificats expirés. Panne brutale à une heure ronde, erreurs TLS dans les logs : vérification en trente secondes, oubli récurrent même dans les équipes matures.
- Le disque plein. Logs, sauvegardes locales ou fichiers temporaires qui saturent un volume : la base de données ou le service s'arrête net.
- La base de données. Connexions épuisées, requête qui verrouille une table, réplication rompue : les symptômes sont des timeouts partout alors que les serveurs applicatifs semblent sains.
- Une dépendance externe. Passerelle de paiement, API tierce, CDN, fournisseur cloud : consultez leurs pages de statut avant de chercher chez vous pendant une heure.
- La charge. Pic de trafic légitime, campagne marketing oubliée, ou attaque par déni de service.
T+30 : mitiger d'abord, corriger ensuite
À la demi-heure, une décision s'impose : privilégier le rétablissement du service, pas l'élégance de la solution. Rétablir par un contournement — rollback du dernier déploiement, bascule sur un serveur sain, désactivation de la fonctionnalité fautive, page dégradée — puis corriger la cause racine à froid, est presque toujours le bon choix.
Le rollback mérite ses règles : vérifier que les migrations de base de données sont réversibles avant de revenir en arrière, et consigner l'état actuel (logs, métriques, dump si possible) avant toute manipulation. Un rollback précipité sur un schéma de données modifié peut transformer une panne en perte de données.
T+60 : rétabli, ou escalade assumée
À l'heure, deux issues. Si le service est rétabli : on surveille les métriques de près, on garde le canal ouvert et on programme le post-mortem. Si l'incident persiste : on escalade sans ego — expert de l'éditeur, support du cloud, renfort externe spécialisé. L'erreur classique est d'attendre la troisième heure pour appeler à l'aide, quand la fatigue a déjà dégradé les décisions et brouillé les pistes.
Les erreurs qui aggravent une panne
- Redémarrer à l'aveugle : le symptôme disparaît parfois, la cause reste, et les indices sont détruits. La panne revient, sans explication disponible.
- Toucher à tout en parallèle : plusieurs changements simultanés rendent impossible de savoir ce qui a aidé ou aggravé.
- Ne pas préserver les logs : rotation, redémarrage ou réinstallation qui effacent la seule matière de l'analyse.
- Communiquer trop tard : le silence génère la panique, les sollicitations, et parfois des décisions commerciales prises sur de fausses informations.
- Chercher un coupable à chaud : la peur pousse à cacher des informations, exactement ce dont l'incident n'a pas besoin.
Le post-mortem sans blâme, et la préparation d'avant
Dans les jours qui suivent, un post-mortem sans blâme reconstitue la chronologie, identifie les causes — elles sont presque toujours multiples — et produit des actions concrètes datées : supervision manquante, alerte à créer, procédure à écrire. Le principe fondateur : on corrige les systèmes, pas les personnes ; quelqu'un qui a fait une erreur dans un système qui la permettait n'est pas le problème, le système l'est.
Enfin, les 60 minutes se gagnent avant l'incident : supervision avec alertes sur les signaux vitaux, runbook écrit et accessible hors du système en panne, contacts d'urgence à jour, rollback testé, et exercices réguliers. Les équipes qui s'en sortent en 40 minutes ne sont pas plus brillantes : elles s'étaient préparées. Pour une PME sans astreinte interne 24/7, l'équivalent de cette préparation, c'est de savoir précisément qui appeler à la première minute — un partenaire qui a déjà ce protocole en mémoire musculaire.