Sauvegardes : le test de restauration que personne ne fait
Publié le · mis à jour le
Fin mai 2021, l’administration communale de Rolle, au bord du lac Léman, subissait une attaque par rançongiciel du groupe Vice Society. En août, un spécialiste découvrait sur le darknet un simple fichier Excel : les identités, les numéros AVS, les données fiscales et les coordonnées de 5 393 habitants, que n’importe qui pouvait télécharger. Une ville de 6 000 habitants, c’est-à-dire exactement l’échelle d’une PME, avec les mêmes moyens informatiques et les mêmes attaquants en face.
Cinq ans plus tard, la menace n’a pas faibli. Dans son rapport annuel 2025, le Centre national pour la cybersécurité recense 64 733 signalements volontaires et 222 signalements obligatoires. Depuis le 1er avril 2025, les autorités publiques, communes comprises, ainsi que les exploitants d’infrastructures critiques visés par la loi, doivent déclarer certains cyberincidents sous 24 heures.
Une PME hors de ce champ n’a pas cette obligation. À titre indicatif, une enquête gfs-zürich publiée en 2021 estimait qu’environ une petite entreprise sur trois avait déjà été touchée. C’est une mesure d’exposition datée de 2021, pas un taux actuel.
Le paradoxe suisse : la sauvegarde tourne, le test n’a jamais lieu
Ces mêmes études montrent un paradoxe. Les mesures techniques existent : la plupart des PME lancent des sauvegardes régulières. Les mesures organisationnelles restent négligées : les plans d’urgence, les exercices, la formation. La bande existe, et personne ne l’a jamais relue.
C’est exactement là que frappent les attaques actuelles. Le rançongiciel ne chiffre plus seulement les serveurs de production : il cherche d’abord les sauvegardes joignables sur le réseau, et il les détruit. Un NAS resté connecté, avec le même mot de passe administrateur que le serveur, garde bien une copie juste à côté de l’original ; cette copie n’est pas une stratégie pour autant. Une erreur, un vol, un incendie ou un chiffrement atteignent l’original et la copie du même coup.
La règle, puis le test
Dans mes mandats, je fixe la date de la première restauration avant d’accepter quoi que ce soit d’autre. Dans l’ordre inverse, vous obtenez des sauvegardes que personne ne vérifie.
La règle 3-2-1-1-0 tient en une phrase : trois copies des données, sur deux types de supports, une hors site, une hors ligne ou immuable, et zéro erreur non résolue après vérification. La copie immuable doit résister aux comptes administrateurs de production, pas seulement aux utilisateurs ordinaires.
La règle ne vaut rien sans test. Un test trimestriel est un bon point de départ pour beaucoup de petites entreprises ; vous en fixez la fréquence et l’étendue d’après l’objectif de temps de restauration (RTO), l’objectif de point de restauration (RPO), l’impact sur l’activité et le taux de changement des données. Chronomètre en main :
- Un fichier au hasard : demandé par quelqu’un d’autre que la personne qui gère les sauvegardes
- Un dossier complet : avec ses droits d’accès
- Un service complet : restauré dans un environnement isolé, avec l’application, la base de données, les permissions, les clés, le DNS, le réseau et les dépendances qui le font tourner
Trois questions à la fin. Tout est revenu intact ? Combien de temps a duré la restauration, et ce délai tient-il pour la paie, la facturation, les fichiers clients ? Et surtout, qui savait faire ? Si la réponse est « une seule personne », vous n’avez pas de plan. Vous avez une dépendance.
Le coût du test, et les pertes qu’il évite
Sur un service simple, le test prend une demi-journée par trimestre. Un ERP, une plateforme d’identité, plusieurs sites ou des objectifs stricts demandent davantage. Regardez ce que Rolle a payé : des mois de gestion de crise et une commission d’enquête. La confiance des habitants a mis longtemps à revenir. Les données, elles, restent sur le darknet. Personne ne « restaure » une fuite. La LPD révisée, en vigueur depuis 2023, impose par ailleurs à toute entreprise une sécurité « adaptée au risque ». Un test de restauration documenté vous aide donc à montrer, avant comme après un incident, que vous avez traité ce risque. Il ne remplace pas les autres contrôles.
La fiche qui rend le test utile
Notez l’actif restauré et le point de restauration retenu. Inscrivez le RTO et le RPO visés à côté du temps réellement mesuré. Précisez le résultat du contrôle d’intégrité, les permissions, les clés et les dépendances. Indiquez qui a mené le test, l’écart constaté, la correction décidée et la date du prochain test. Ajoutez-y les exports SaaS et le retour vers votre fournisseur d’identité : sans identité, un serveur restauré reste inutilisable.
Le test coûte du temps, et il produit une mesure. C’est cette mesure qui sépare une restauration testée d’une promesse de sauvegarde.
Les sources de l’affaire de Rolle
Fixez la fréquence du test, son étendue et les objectifs de restauration service par service, d’après leur impact, plutôt que d’appliquer un calendrier unique à tout.
Rapports fédéraux consultés le 14 août 2026.