ÉvaluerChecklist≈ 9 min d’utilisation

Checklist — Votre sauvegarde est-elle réellement restaurable ?

Douze vérifications à faire une fois par an. Une seule case non cochée suffit à rendre la sauvegarde théorique.

Mis à jour le 5 juillet 2026Protect

Comment l’utiliser — Cet outil s’utilise directement sur cette page : parcourez-le à l’écran ou imprimez-la pour la réunion. Aucun fichier à télécharger.

Une sauvegarde qui tourne toutes les nuits ne garantit rien : seule une sauvegarde restaurée avec succès, dans un délai connu, prouve que l’entreprise peut repartir. Cette checklist regroupe les vérifications à faire, phase par phase, pour passer d’une sauvegarde « qui existe » à une sauvegarde « qui fonctionne ». Elle se lit et se coche avec la personne — interne ou prestataire — qui gère réellement les sauvegardes.

Vocabulaire

RPO (Recovery Point Objective): Quantité de données que l’entreprise accepte de perdre, exprimée en temps (ex. 4 heures de données au maximum).
RTO (Recovery Time Objective): Délai maximal acceptable pour remettre un service en marche après un incident.
Rétention: Durée pendant laquelle des copies de sauvegarde successives sont conservées avant d’être écrasées.
Sauvegarde immuable: Copie qui ne peut être ni modifiée ni supprimée pendant une période définie, même par un compte administrateur compromis.
Copie hors ligne / hors site: Copie déconnectée du réseau ou stockée dans un lieu physique distinct, protégée si le site principal ou le réseau est compromis.
Restauration granulaire: Capacité à restaurer un élément précis (un fichier, une boîte mail, un enregistrement) sans devoir tout restaurer.
Cohérence applicative: Garantie que les données restaurées forment un état exploitable pour l’application (ex. une base de données non corrompue), pas seulement des fichiers présents.
Journal de test: Document qui trace chaque test de restauration effectué : date, périmètre, résultat, durée, actions correctives.

Périmètre

La cause la plus fréquente d’échec de restauration n’est pas technique : c’est un oubli de périmètre. Un service en ligne, un poste nomade ou une base applicative absente de la liste n’est tout simplement jamais sauvegardé.

La liste des données et systèmes sauvegardés est écrite et validée par les métiers, pas seulement par l’IT.
Chaque application critique identifiée dans l’entreprise figure nommément dans cette liste.
Les postes de travail et les boîtes mail sont couverts, pas seulement les serveurs.
Les services en ligne (messagerie, stockage cloud, outils métier SaaS) sont couverts par une sauvegarde distincte du fournisseur du service.
Les bases de données et les configurations systèmes critiques sont incluses, pas seulement les fichiers.

Fréquence, rétention et RPO/RTO

Sans objectif chiffré, « sauvegarder régulièrement » ne veut rien dire. Le RPO fixe la perte de données tolérable, le RTO fixe le délai de retour en service — ce sont des décisions métier, pas des paramètres techniques.

Un RPO cible est défini pour chaque application critique, en accord avec les métiers concernés.
Un RTO cible est défini pour chaque application critique et est réaliste par rapport aux capacités réelles.
La fréquence des sauvegardes est cohérente avec le RPO fixé (une sauvegarde quotidienne ne tient pas un RPO de 2 heures).
La durée de rétention couvre au moins un incident détecté tardivement (ex. un chiffrement découvert plusieurs semaines après coup).
Les objectifs RPO/RTO sont revus au moins une fois par an, ou après un changement significatif d’activité.

Isolement et protection des sauvegardes

Une sauvegarde accessible depuis le même réseau que les données qu’elle protège n’est pas une protection contre un rançongiciel : elle peut être chiffrée ou supprimée en même temps que le reste.

Au moins une copie de sauvegarde est immuable ou hors ligne, inaccessible en écriture depuis le réseau de production.
Au moins une copie est conservée hors site (site distinct ou hébergement cloud séparé).
L’accès administrateur au système de sauvegarde est distinct de l’accès administrateur au système de production.
Les sauvegardes sont chiffrées, au repos et pendant le transfert.
Le système de sauvegarde lui-même est mis à jour et supervisé, pas seulement les serveurs qu’il protège.

Comptes et accès

Les sauvegardes sont une cible privilégiée lors d’une attaque : un attaquant qui les détruit prive l’entreprise de son filet de sécurité avant même de déclencher l’incident visible.

Le nombre de comptes ayant un droit de suppression ou de modification des sauvegardes est connu et limité.
L’authentification multifacteur est activée sur ces comptes.
Un compte de sauvegarde compromis ne peut pas, à lui seul, supprimer toutes les copies (séparation des rôles ou double validation).
La liste des personnes ayant accès au système de sauvegarde est revue au moins une fois par an.
Le départ d’un collaborateur ou d’un prestataire déclenche la révocation de ses accès aux sauvegardes.

Tests de restauration

Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Le test de restauration est le seul moyen de vérifier que les fichiers de sauvegarde sont exploitables et que le délai annoncé est tenable.

Un test de restauration complet a été réalisé au cours des douze derniers mois pour chaque application critique.
Le test a été effectué sur un environnement distinct de la production, pas en écrasant les données vivantes.
La durée réelle de restauration observée a été comparée au RTO cible.
Un test de restauration granulaire (un fichier, une boîte mail) a été réalisé récemment, en plus du test complet.
Les écarts constatés lors du dernier test ont donné lieu à une action corrective documentée.

Cohérence applicative

Un fichier de sauvegarde peut exister et être pourtant inutilisable, si l’application n’a pas été arrêtée ou mise en cohérence au moment de la copie. C’est particulièrement vrai pour les bases de données.

Les sauvegardes de bases de données utilisent un mécanisme garantissant la cohérence (arrêt, snapshot cohérent, ou export applicatif dédié).
Les applications critiques ont été vérifiées comme redémarrant correctement après une restauration, pas seulement leurs fichiers.
Les dépendances entre systèmes (ex. base de données et serveur d’application) sont restaurées dans le bon ordre lors des tests.
Les intégrations externes (API, interfaçages) sont revérifiées après une restauration test, pas seulement l’application elle-même.

Responsabilités et documentation

Une procédure connue d’une seule personne n’est pas une procédure : elle disparaît si cette personne est absente ou indisponible au moment où on en a besoin.

Une personne nommée est responsable de la sauvegarde pour chaque système critique, avec un remplaçant identifié.
La procédure de restauration est écrite, à jour, et accessible même si les systèmes habituels sont indisponibles.
Le rôle du prestataire externe, s’il y en a un, est précisé par écrit (qui sauvegarde, qui teste, qui restaure en cas d’incident).
Le coût et le délai d’une restauration d’urgence facturée par le prestataire sont connus à l’avance.

Preuves et suivi

Sans traçabilité, une sauvegarde qui échoue silencieusement peut passer inaperçue pendant des mois. Le suivi transforme la sauvegarde d’une tâche automatique en un dispositif piloté.

Les échecs de sauvegarde déclenchent une alerte suivie d’une action, pas seulement un journal consulté a posteriori.
Un journal de test de restauration existe, avec date, périmètre, résultat et durée pour chaque test réalisé.
Un indicateur simple (taux de succès des sauvegardes, dernière restauration réussie) est présenté à la direction au moins une fois par an.

Lire votre résultat

Cette checklist ne donne pas un score global : chaque groupe pointe un risque différent. Une majorité de cases non cochées dans « Périmètre » signifie qu’une partie de l’activité n’est probablement pas sauvegardée du tout. Dans « Fréquence, rétention et RPO/RTO », cela signifie que même une restauration réussie pourrait arriver trop tard ou avec trop de pertes. Dans « Isolement et protection », l’entreprise reste exposée à la perte simultanée des données et de leur sauvegarde lors d’une attaque. Dans « Comptes et accès », un compte compromis suffit à effacer le filet de sécurité. Dans « Tests de restauration » et « Cohérence applicative », la sauvegarde existe mais sa capacité réelle à remettre l’activité en marche n’a jamais été prouvée. Dans « Responsabilités et documentation », la continuité dépend d’une seule personne. Dans « Preuves et suivi », les défaillances peuvent passer inaperçues jusqu’au jour où elles comptent le plus.

Actions correctives prioritaires

Combler d’abord les trous de périmètre : identifier ce qui n’est pas sauvegardé du tout avant d’améliorer ce qui l’est déjà.
Vérifier qu’au moins une copie est immuable ou hors ligne, isolée d’un compte administrateur unique.
Planifier un test de restauration complet sur l’application la plus critique, si aucun n’a eu lieu depuis plus d’un an.
Fixer par écrit un RPO et un RTO pour chaque application critique, avec les métiers concernés.
Nommer une personne responsable par système critique et documenter un remplaçant.
Mettre en place une alerte active sur les échecs de sauvegarde, et un journal de test partagé.

À retenir

Une sauvegarde n’a de valeur que si elle a été restaurée avec succès au moins une fois, dans un délai connu.
L’isolement des sauvegardes (immuabilité, hors ligne, comptes distincts) les protège d’une attaque qui viserait la production.
Sans test régulier, cohérence applicative vérifiée et responsable nommé, la sauvegarde reste une hypothèse non prouvée.

OAKTEAM Score