Votre plan de reprise tiendrait-il ?

Avez-vous restauré une sauvegarde complète en conditions réelles au cours des douze derniers mois ?

Restauration effective sur un environnement séparé, pas une vérification d'intégrité ni un test de lecture.

Connaissez-vous la durée réelle d'une restauration complète, mesurée et non estimée ?

Le temps chronométré lors du dernier test, du déclenchement jusqu'au service rendu aux utilisateurs.

Après une restauration, vérifiez-vous le contenu restitué et pas seulement le statut de l'opération ?

Données réellement présentes, schéma complet, application qui démarre — au-delà d'un « terminé » affiché par l'outil.

Plusieurs personnes savent-elles conduire une restauration complète ?

Au moins deux personnes capables de le faire seules, sans assistance de celle qui a construit le dispositif.

Les secrets nécessaires à la restauration sont-ils accessibles si la production est indisponible ?

Clés de déchiffrement, identifiants du stockage, certificats — conservés ailleurs que dans le système à restaurer.

Existe-t-il un inventaire à jour de ce qui est sauvegardé, et surtout de ce qui ne l'est pas ?

La seconde partie est la plus importante : les exclusions assumées doivent être écrites.

Les états applicatifs sont-ils sauvegardés de façon cohérente ?

Bases de données, files de messages, volumes persistants : capturés à un instant cohérent, pas fichier par fichier pendant que l'application écrit.

Votre infrastructure se reconstruit-elle à l'identique depuis du code ?

Terraform, Ansible, manifestes GitOps : la plateforme elle-même, pas seulement les données qu'elle porte.

Un nouveau type de stockage mis en service entre-t-il automatiquement dans le périmètre de sauvegarde ?

Nouvelle classe de stockage, nouveau pilote, migration de volumes d'une technologie vers une autre.

Vos sauvegardes sont-elles immuables ou verrouillées pendant leur durée de rétention ?

Object lock, rétention en mode gouvernance ou conformité, support hors ligne.

Une copie est-elle stockée hors du domaine d'authentification de production ?

Compte séparé, fournisseur distinct, identifiants qui ne sont pas ceux de l'annuaire principal.

Savez-vous restaurer sans réintroduire la compromission ?

Point de restauration antérieur à l'intrusion identifiable, et procédure pour repartir sur une infrastructure saine.

Êtes-vous alerté quand une sauvegarde échoue, et l'alerte est-elle traitée ?

Une alerte qui part dans une boîte que personne ne lit ne compte pas.

Une sauvegarde partiellement échouée déclenche-t-elle la même réaction qu'un échec complet ?

Le statut intermédiaire — « partiellement terminé », « avec erreurs » — traité comme un incident, pas comme un succès dégradé.

Surveillez-vous la disponibilité de la destination de sauvegarde elle-même, et l'expiration de ses certificats et identifiants ?

Le stockage distant, ses accès, sa chaîne de confiance — pas seulement le déroulement des travaux de sauvegarde.

Êtes-vous certain que la configuration de sauvegarde réellement appliquée est celle de votre dépôt ?

Écart entre le code et l'état effectif, y compris quand l'outil de déploiement se déclare synchronisé.

Le RTO et le RPO sont-ils définis avec les métiers, et non par l'équipe technique seule ?

Combien de temps l'activité peut s'arrêter, et combien de données elle accepte de perdre.

La procédure de reprise est-elle écrite et accessible pendant une panne ?

Y compris si le wiki, l'intranet ou la messagerie sont eux-mêmes indisponibles.