Résilience
Beaucoup d'équipes ont des sauvegardes, mais pas une reprise fiable. La différence est très concrète. Une sauvegarde est un artefact. La reprise est un processus avec rôles, dépendances, ordre d'exécution et pression temporelle.
Pourquoi commencer par les runbooks
Si un incident débute par une discussion sur le premier système à restaurer, sur la personne qui valide un failover ou sur l'emplacement du dernier test de restauration, la sauvegarde n'est qu'un morceau du problème. Un bon runbook réduit l'incertitude avant même le stress technique.
- Quels systèmes sont critiques et dans quel ordre doivent-ils revenir ?
- Qui décide entre failover, restauration ou mode dégradé assumé ?
- Où se trouvent les identifiants, copies hors ligne et contacts d'urgence ?
- Comment suit-on ce qui est déjà revenu et ce qui bloque encore le service ?
RPO/RTO ne valent que s'ils sont exercés
Des chiffres RPO/RTO n'ont de sens que s'ils sont confrontés à des exercices. Pour beaucoup de PME, un test mensuel structuré sur un système représentatif apporte déjà énormément, s'il est documenté et répétable.
Lacunes fréquentes
- Les sauvegardes tournent, mais les chemins de restauration ne sont jamais validés.
- Les dépendances entre services ne sont pas documentées.
- On teste des composants isolés, pas une reprise complète de service.
- Le savoir reste dans quelques têtes au lieu d'être rattaché à des rôles.
Checklist en 5 minutes
- Définir l'ordre de restauration des cinq systèmes les plus critiques.
- Documenter un runbook de restauration avec rôles, contacts et validations.
- Planifier au moins un test de restauration chaque mois.
- Comparer les RPO/RTO affichés aux résultats réels des exercices.
- Retenir trois améliorations concrètes après chaque test.