Sauvegardes en PME : les 7 questions à poser avant un incident

La première question paraît simple, mais elle est souvent mal maîtrisée. Il ne suffit pas de savoir qu’une sauvegarde existe. Il faut savoir précisément ce qui est sauvegardé : fichiers, bases de données, messagerie, logiciels métier, paramètres serveurs, machines virtuelles, documents partagés ou postes critiques.

Le risque fréquent est de sauvegarder une partie visible du système, mais d’oublier une dépendance essentielle : une base SQL, un dossier de configuration, un export comptable, un connecteur métier ou une application ancienne.

La fréquence de sauvegarde doit être cohérente avec le niveau de perte acceptable pour l’entreprise. Perdre une journée de données peut être acceptable dans certains contextes, mais catastrophique dans d’autres.

Le bon raisonnement consiste à se demander combien d’heures ou de jours de travail l’entreprise peut réellement se permettre de perdre.

Une sauvegarde stockée au même endroit que le système de production protège contre certaines erreurs, mais pas contre tous les scénarios. Si le serveur principal tombe, si le site est indisponible ou si un ransomware chiffre aussi les sauvegardes accessibles, l’entreprise peut se retrouver bloquée.

Il faut donc comprendre où sont stockées les copies, sur quels supports, avec quelles protections et dans quelle logique de séparation.

C’est probablement la question la plus importante. Une sauvegarde n’a de valeur que si elle peut être restaurée. Pourtant, beaucoup d’entreprises n’ont jamais réalisé de test réel de restauration.

Un test de restauration permet de vérifier que les fichiers sont exploitables, que les bases redémarrent, que les versions sont cohérentes et que les procédures sont comprises.

En cas d’incident, toutes les applications ne se valent pas. Certaines sont vitales pour produire, facturer, livrer, soigner, vendre ou communiquer. D’autres peuvent attendre.

La sauvegarde doit donc être reliée à une priorisation métier. Sans ordre de reprise, l’entreprise risque de restaurer ce qui est techniquement simple plutôt que ce qui est réellement critique.

Une sauvegarde peut être techniquement correcte, mais inutile si personne ne sait qui doit agir. En situation de crise, la confusion entre direction, prestataire, hébergeur, éditeur logiciel et utilisateurs peut faire perdre un temps précieux.

Il faut donc clarifier les responsabilités avant l’incident : qui décide, qui restaure, qui communique, qui vérifie, qui valide le retour en production.

La sauvegarde est une brique essentielle, mais elle ne constitue pas à elle seule un plan de continuité ou de reprise. Un PRA/PCA doit relier les données, les outils, les personnes, les délais, les priorités métier et les scénarios d’incident.

Sans cette vision globale, l’entreprise peut disposer de sauvegardes correctes mais rester incapable d’organiser une reprise efficace.

C’est une confusion fréquente : une entreprise peut avoir une sauvegarde quotidienne, une copie externalisée, un NAS ou une solution cloud, sans disposer pour autant d’un vrai plan de reprise d’activité.

La sauvegarde répond à une question technique : peut-on récupérer des données ? Le PRA répond à une question d’entreprise : peut-on redémarrer l’activité dans des conditions acceptables ?

La différence se voit le jour de l’incident. Il ne suffit plus de retrouver des fichiers. Il faut savoir quels systèmes redémarrer en premier, qui décide des priorités, comment les équipes travaillent en mode dégradé et comment vérifier que l’activité peut repartir correctement.

La bonne question n’est pas seulement : avons-nous des sauvegardes ? La vraie question est : savons-nous redémarrer correctement ?

Une PME n’a pas forcément besoin d’un dispositif lourd ou complexe, mais elle doit connaître ses priorités, ses dépendances, ses responsabilités et ses délais réalistes de reprise.

Un diagnostic PRA/PCA permet justement de passer d’une logique de sauvegarde technique à une logique de continuité d’activité compréhensible par la direction.