Votre question de départ : si l’activité s’arrête ce soir, qu’est-ce qui doit revenir en premier ?

La bonne question n’est pas « avons-nous une sauvegarde ? », mais « pouvons-nous remettre en service, vite et sans surprise, les données qui font tourner l’entreprise ? ». La CNIL rappelle qu’il faut tester régulièrement l’intégrité des sauvegardes et la capacité à les restaurer, et l’ANSSI recommande de considérer sauvegarde et restauration comme des opérations à part entière, avec procédures et tests.

Pour une PME, « données essentielles » ne veut pas dire « tout l’historique ». Cela désigne le minimum utile pour redémarrer : fichiers clients actifs, commandes en cours, facturation récente, référentiels produits, droits d’accès, et parfois une base applicative ou un export clé. Le piège classique est de restaurer un volume immense… et de découvrir que le dernier export exploitable manque ou que l’application ne sait plus relire les données.

  • Objectif : prouver la restauration, pas seulement la sauvegarde.
  • Périmètre : le strict nécessaire pour reprendre l’activité.
  • Risque principal : découvrir l’échec le jour du sinistre, quand il est trop tard.

Méthode pratique en 5 étapes pour un test réaliste

Étape 1 : choisissez un scénario. Restez concret : panne serveur, suppression accidentelle, rançongiciel, ou corruption d’une base. NIST insiste sur l’intérêt d’un playbook de reprise adapté à chaque type d’incident et d’exercices de test pour améliorer la reprise.

Étape 2 : définissez l’« état cible ». Pour chaque donnée critique, notez la date de reprise acceptable, l’emplacement de la sauvegarde, et le système de restitution attendu : fichier, base, machine virtuelle, ou export importable. La CNIL recommande notamment d’isoler au moins une sauvegarde hors ligne et d’en garder une sur un site distinct.

Étape 3 : testez en environnement séparé. Restaurez une copie dans un bac à sable, jamais directement sur la production. Vérifiez d’abord que le support se lit, puis que les fichiers s’ouvrent, puis que l’application redémarre et retrouve ses relations de données. L’ANSSI et la CNIL insistent sur l’intégrité et la capacité de restauration, pas seulement sur l’existence d’un backup.

  • 1. Choisir un incident plausible.
  • 2. Définir les données minimales et leur date cible.
  • 3. Restaurer en environnement isolé.
  • 4. Vérifier lisibilité, cohérence et démarrage applicatif.
  • 5. Consigner les écarts et corriger.
  • ]} ,{"heading":"Exemple chiffré fictif : une remise en route en 4 heures, pas en 4 jours","paragraphs":["Supposons une PME de négoce qui doit retrouver ses commandes, son fichier clients actif et ses factures de la semaine. Elle teste une restauration sur une machine isolée, avec une sauvegarde hors ligne de la veille et une réplication secondaire plus ancienne. Résultat : les fichiers s’ouvrent, mais deux tables de liaison sont corrompues et un export comptable ne passe pas l’import. Le test révèle donc un vrai problème avant la panne, pas pendant.","Dans ce scénario fictif, l’entreprise décide une règle simple : données critiques restaurées en moins de 4 heures, reste de l’historique en différé. Ce n’est pas une promesse universelle. C’est un objectif opérationnel à calibrer selon votre activité, vos contrats et vos contraintes techniques. La CNIL rappelle d’ailleurs que si les exigences de disponibilité sont élevées, une réplication vers un site secondaire peut être pertinente, ce,

Les limites à connaître avant de se féliciter trop vite

Un test réussi sur un petit échantillon ne prouve pas qu’une restauration complète fonctionnera. De même, une restauration de fichiers ne valide pas forcément les permissions, les automatisations, les intégrations avec l’ERP, ou la conformité des données personnelles après reprise. La CNIL rappelle aussi que sauvegardes et systèmes de sauvegarde doivent être protégés au niveau adéquat, et que la journalisation peut aider à comprendre l’origine d’un incident.

Autre limite fréquente : la fraîcheur des données. Une sauvegarde exploitable peut être trop ancienne pour votre besoin réel. C’est pourquoi il faut distinguer la restauration technique du besoin métier : « les données reviennent » n’est pas la même chose que « l’activité repart sans casser la relation client, la paie ou la facturation ».

  • Tester un échantillon ne suffit pas toujours.
  • La restauration doit couvrir les droits, dépendances et imports.
  • Une sauvegarde utilisable peut rester trop vieille pour le métier.

Checklist de 7 jours : ce qu’il faut faire, qui le fait, et ce qu’on observe

Jour 1 — Dirigeant ou DG : valider la liste des 5 à 10 données essentielles. Résultat observable : une liste courte, datée, approuvée.

Jour 2 — Responsable informatique ou prestataire : identifier la sauvegarde source et la cible de test. Résultat : chemin de restauration documenté.

Jour 3 — Référent métier : définir le critère d’acceptation. Résultat : on sait ce qui doit s’ouvrir, s’importer et se recalculer.

  • Jour 4 — IT : restaurer en environnement isolé. Résultat : une copie exploitable hors production.
  • Jour 5 — Métier : contrôler 10 cas réels. Résultat : erreurs listées, pas supposées.
  • Jour 6 — IT + métier : corriger au moins un écart prioritaire. Résultat : une reprise de test améliorée.
  • Jour 7 — Direction : décider la fréquence du prochain test. Résultat : une date de revalidation inscrite au calendrier.