Pourquoi préparer la reprise avant l’incident ?
Une organisation découvre souvent son vrai niveau de préparation au pire moment : quand un incident impose des arbitrages rapides entre remise en ligne, intégrité des données, communication client et pression interne. Sans cadre préalable, l’équipe consomme un temps précieux à décider qui fait quoi au lieu de restaurer.
Préparer la reprise ne consiste pas à écrire un document théorique. Il s’agit de construire un runbook utilisable sous stress, avec des responsabilités nommées, des seuils d’escalade, une logique de restauration et des messages de communication déjà cadrés.
À quoi ressemble un runbook crédible ?
Le runbook doit suivre la chronologie réelle d’un incident : détection, qualification, escalade, décision, restauration, communication interne et externe, puis retour d’expérience. Chaque étape doit dire qui agit, sur quel signal, avec quel niveau d’autonomie et quel critère de sortie.
Détection : repérer le symptôme utile et ouvrir le bon canal d’incident.
Escalade : mobiliser les bonnes personnes sans attendre que tout le contexte soit parfait.
Décision : arbitrer entre rollback, restauration, mode dégradé ou coupure préventive.
Restauration : remettre un état exploitable, pas seulement “faire repartir” un composant.
Communication : informer selon les engagements, sans promettre ce qui n’est pas encore confirmé.
Retour d’expérience : corriger les causes et les angles morts pendant que le contexte est encore frais.
Qui décide quoi pendant l’incident ?
C’est souvent le point le moins documenté et le plus coûteux. Il faut distinguer qui qualifie l’incident, qui décide d’un rollback ou d’une coupure, qui valide une communication client, et qui arbitre si la restauration technique dégrade temporairement une fonction métier.
Une bonne organisation accepte qu’en incident certaines décisions soient prises avec une information incomplète. L’important est que le niveau d’autorité soit défini avant, pas au milieu de la crise.
Quelle perte de données ou quelle interruption est acceptable ?
La continuité de service n’a de sens qu’adossée à un niveau de perte acceptable. Il faut décider à froid ce que l’entreprise peut tolérer : quelques minutes de dégradation, une reprise en mode dégradé, une perte limitée de données, ou au contraire une exigence de restauration stricte sur certains périmètres.
Cette discussion change directement l’architecture, les sauvegardes, la supervision et le budget. Sans elle, le plan de continuité reste abstrait et impossible à arbitrer sérieusement.
Quels exercices, indicateurs et livrables faut-il prévoir ?
La préparation se juge par l’entraînement. Les indicateurs les plus utiles sont le MTTR, le temps pour qualifier l’incident, le taux de restauration réussie, la fréquence des exercices et la capacité à mettre à jour le runbook après un changement majeur.
Les livrables attendus sont pragmatiques : runbook d’incident, matrice de décision, annuaire d’escalade, scénarios de restauration, messages de communication types et journal des exercices ou incidents réellement passés.
