Sauvegardes : pourquoi tester la restauration est vital pour une PME

Un matin, tout fonctionne. Le lendemain, une panne, un ransomware ou une erreur humaine bloque l’accès aux données. On se tourne alors vers la sauvegarde, confiant. Mais la surprise n’est pas rare : le fichier est corrompu, la restauration échoue, ou l’application ne redémarre pas. Ce scénario n’est pas une fiction – il arrive chaque semaine à des PME françaises.

Pourquoi une sauvegarde n’est jamais une assurance sans test

Beaucoup d’organisations vérifient que leur sauvegarde s’exécute chaque nuit. Mais trop peu testent ce qui compte : la capacité à restaurer, dans le délai attendu, les données et applications qui font tourner l’entreprise. L’ANSSI et la CNIL insistent : une sauvegarde qui n’a jamais été testée est une sauvegarde dont on ne connaît pas la valeur réelle.

Les incidents récents l’ont prouvé : une sauvegarde peut sembler réussie, mais être inutilisable le jour où elle devient critique. Un fichier manquant, une base incohérente, un compte administrateur oublié… et la reprise d’activité s’enlise. Ce paradoxe touche aussi bien les serveurs locaux que les services cloud ou SaaS : il ne suffit pas de payer un abonnement pour être à l’abri.

Définir ce qu’il faut restaurer, et en combien de temps

Avant de parler technique, il faut décider ce qui compte. Quelles applications ou données sont vitales pour l’activité ? Un ERP, un logiciel de facturation, la messagerie, un CRM : chaque entreprise a ses priorités. Pour chacune, il faut lister :

• les données à restaurer ;
• les serveurs ou services nécessaires ;
• les comptes et droits indispensables ;
• les configurations et licences ;
• qui vérifiera que tout fonctionne à nouveau.

Deux indicateurs structurent la réflexion :

• RPO (Recovery Point Objective) : la quantité de données qu’on accepte de perdre (par exemple : pas plus de deux heures de saisie).
• RTO (Recovery Time Objective) : le délai maximal pour tout remettre en service (par exemple : 8 heures).

Ces seuils ne sortent pas d’un manuel, mais des conséquences réelles pour l’activité. Le NIST et la CNIL rappellent que ces objectifs doivent guider la fréquence des sauvegardes et les moyens de restauration, pas l’inverse.

Premier réflexe : tester la restauration, pas seulement la sauvegarde

Un test complet n’exige pas de bloquer l’entreprise. Il s’agit d’abord de choisir une donnée ou une application critique, puis de tenter une restauration dans un environnement isolé ou de recette. L’objectif : vérifier que le fichier s’ouvre, que l’application redémarre, que les utilisateurs peuvent travailler.

Pour une base de données, il faut contrôler l’intégrité et la cohérence. Pour une application métier, il s’agit de s’assurer que les données restaurées sont exploitables et que les connexions avec les autres services fonctionnent.

La CNIL conseille de documenter ces tests et de les refaire régulièrement. Une sauvegarde jamais vérifiée est un pari risqué.

La règle du 3-2-1 : une sécurité simple, rarement appliquée

L’ANSSI recommande la « règle du 3-2-1 » : trois copies de chaque donnée, sur deux supports différents, dont une hors ligne. Cette approche protège contre la plupart des scénarios : panne matérielle, ransomware, erreur de manipulation ou suppression malveillante.

En pratique, cela veut dire : une sauvegarde locale (disque externe ou NAS), une copie sur un cloud ou un autre site, et une version déconnectée (clé USB stockée hors site, bande magnétique, etc.). Ce dispositif doit lui aussi être testé : une sauvegarde hors ligne qui n’a jamais été relue ne sert à rien.

Que faire concrètement cette semaine ?

Pour une PME, il n’est pas nécessaire de construire un plan de reprise d’activité complet dès le départ. Mais il est essentiel de :

• Identifier les applications et données critiques.
• Définir le RPO et le RTO pour chacune.
• Vérifier que les sauvegardes couvrent bien ces besoins.
• Réaliser un test de restauration sur un périmètre limité : récupérer un fichier, une base, une application, et vérifier son bon fonctionnement.
• Documenter le résultat : temps de restauration réel, difficultés rencontrées, éléments manquants.

Si le test échoue ou révèle une faiblesse, il est temps de revoir le dispositif. Cela peut passer par une vérification complète de la continuité et de la reprise d'activité, ou par la mise en place de sauvegardes mieux isolées.

En cas de doute, ou si la restauration s’avère impossible, il est préférable de préparer la gestion des incidents et de crise : comment détecter, documenter et notifier un incident, qui appeler, quelles étapes suivre (préparer la gestion des incidents et de crise).

Enfin, face à une attaque ou une perte de données, il existe des dispositifs d’urgence cyber pour être rappelé et guidé dans les premiers gestes.

Le réflexe DYCAST

Cette semaine, demandez à votre responsable informatique ou à votre prestataire d’effectuer un test de restauration sur une application critique. Notez le temps nécessaire et vérifiez que tout fonctionne. C’est le meilleur moyen de découvrir un problème… avant qu’il ne devienne une crise.