« Nos sauvegardes sont testées » figure dans presque tous les questionnaires. Dans la majorité des cas, le test consiste à restaurer un fichier isolé, ce qui ne prouve à peu près rien.
Un test de restauration crédible répond à une seule question : combien de temps pour redevenir opérationnel, et avec quelles pertes ?
Les trois niveaux de test
Niveau 1 — Restauration unitaire. Un fichier, une boîte aux lettres. Vérifie que la sauvegarde est lisible. Utile, insuffisant.
Niveau 2 — Restauration système. Un serveur complet sur une infrastructure de remplacement, avec vérification que l’application démarre et fonctionne. C’est le minimum crédible.
Niveau 3 — Restauration de service. Une chaîne applicative entière, avec ses dépendances, jusqu’à ce qu’un utilisateur métier confirme que le service rend le service. C’est le seul niveau qui valide vraiment un RTO.
Beaucoup d’organisations déclarent un niveau 3 en ayant pratiqué un niveau 1.
Ce qu’il faut mesurer
- Le temps réel de restauration, chronométré, de la décision à la remise en service. Pas le temps de copie des données.
- Le point de reprise effectif : quelle est la date des données restaurées, et quel écart avec le RPO annoncé.
- Les dépendances découvertes : services annexes, certificats, comptes de service, résolution de noms. C’est là que se trouvent les mauvaises surprises.
- Les compétences requises : combien de personnes savent faire, et sont-elles disponibles un dimanche ?
Ces mesures alimentent directement le bilan d’impact et le dimensionnement du plan de reprise.
Le scénario qu’il faut oser tester
La plupart des tests supposent que l’infrastructure existe encore et que les comptes d’administration fonctionnent.
Le scénario réaliste aujourd’hui est différent : l’annuaire est compromis, les comptes d’administration ne sont plus fiables, une partie des serveurs doit être reconstruite depuis zéro.
Questions à se poser dans ce cadre :
- Où sont les identifiants nécessaires à la restauration, si l’annuaire est indisponible ?
- La documentation de reconstruction est-elle accessible hors ligne ?
- La sauvegarde elle-même est-elle atteignable sans les comptes compromis — voir la copie hors de portée ?
- Comment vérifie-t-on que la sauvegarde restaurée n’est pas déjà compromise ?
Ce dernier point est le plus délicat, et découle directement de la durée de présence d’un attaquant.
Organiser le test
Annoncé ou surprise ? Les deux ont leur usage. Un test annoncé valide la procédure. Un test surprise valide la capacité réelle — disponibilité des personnes, accessibilité de la documentation. Alterner est une bonne pratique.
Sur une infrastructure de remplacement, jamais en écrasant la production.
Avec un observateur qui note les blocages sans intervenir. C’est lui qui produira la valeur du test.
Avec un métier pour valider que le service restauré est réellement utilisable.
Ce qu’il faut consigner
Un compte rendu daté indiquant le périmètre testé, le scénario, les temps mesurés, les écarts constatés et les actions correctives avec échéances.
C’est ce document que demanderont l’auditeur ISO, l’assureur — voir ce que l’assureur vérifie — et l’autorité de contrôle. Un test réussi non documenté n’existe pas.
À quelle fréquence
Niveau 1 : mensuel, automatisable. Niveau 2 : trimestriel sur un système tournant. Niveau 3 : annuel au minimum, et systématiquement après un changement majeur d’architecture.
La règle qui compte : tout système ajouté au périmètre critique doit avoir été restauré au moins une fois avant d’être considéré comme couvert.
Sources
- ISO/IEC 27002:2022, mesure 8.13 — sauvegarde des informations
- ISO 22301:2019 — exercices et tests
- Règlement (UE) 2016/679 (RGPD), article 32 — capacité de rétablir la disponibilité
Aller plus loin
Ces tests s’inscrivent dans une démarche de continuité que nous accompagnons en gouvernance, risques et conformité, et dans notre maintien en condition de sécurité.