Rançongiciel en mairie ou en PME : la sauvegarde existe, mais la reprise peut quand même échouer

Après un chiffrement, beaucoup de dirigeants découvrent une vérité un peu rude : la sauvegarde restaurable n'existe pas parce qu'un logiciel l'affiche en vert. Sans test de restauration de sauvegarde, sans ordre de reprise et sans vision de la continuité d'activité informatique, l'entreprise reste à l'arrêt.

Le jour où la sauvegarde ne suffit plus

Dans une PME touchée par un rançongiciel ou dans une mairie dont les fichiers sont chiffrés, le premier réflexe est presque toujours le même : vérifier que les sauvegardes ont bien tourné. C'est nécessaire, mais insuffisant. Une sauvegarde peut exister, être récente, même supervisée, et pourtant rester inutilisable au moment critique.

Pourquoi ? Parce que restaurer un fichier n'a rien à voir avec relancer une activité. Il faut remettre en route des machines virtuelles, des droits d'accès, des applications métier, parfois la messagerie, souvent l'accès à Internet, et de plus en plus la téléphonie IP. Le disque dur, lui, ne raconte pas ces dépendances. Il garde les données, pas l'ordre dans lequel le système doit respirer à nouveau.

Les causes les plus fréquentes d'un échec de reprise

Des sauvegardes présentes, mais jamais rejouées

Le problème le plus courant reste l'absence de test de restauration. Beaucoup d'organisations savent qu'elles sauvegardent, peu savent combien de temps prendrait une remise en service réelle. Une restauration testée une fois il y a deux ans ne vaut pas garantie : l'infrastructure change, les versions bougent, les usages aussi.

Nous le voyons souvent lors d'un audit de sauvegarde ou d'une reprise d'infogérance : la copie est saine, mais le point de restauration pertinent n'est pas identifié, ou bien les accès au support de sauvegarde dépendent d'un compte administrateur oublié.

Un PRA absent, ou trop théorique

Le plan de reprise d'activité n'est pas un document réservé aux grandes structures. À partir du moment où une équipe dépend d'un serveur de fichiers, d'une comptabilité Sage, d'une messagerie Microsoft 365 ou d'un standard téléphonique, il faut définir ce qui redémarre d'abord, dans quel délai, et avec quelles ressources minimales.

Sans cela, tout paraît urgent. En pratique, rien n'est arbitré. On restaure parfois un serveur secondaire avant le partage documentaire principal, ou l'on attend le retour d'un prestataire télécom alors que l'équipe ne peut déjà plus travailler.

Ce que changent vraiment sauvegarde, restauration et PRA

La sauvegarde répond à une question simple : les données ont-elles été copiées correctement ? La restauration répond à une autre : peut-on récupérer ces données dans un format exploitable, sur une plateforme fonctionnelle, dans un délai acceptable ? Le PRA, lui, va plus loin : il organise la reprise priorisée de l'activité.

Cette distinction paraît scolaire. Le jour d'un incident, elle devient très concrète. Une entreprise peut récupérer ses données en 24 heures et rester bloquée trois jours, faute de postes préparés, de licences valides ou de procédure pour reconnecter les utilisateurs distants. C'est précisément là que la méthode de reprise et la visibilité sur les dépendances changent la donne.

Les dépendances qu'on oublie jusqu'au mauvais matin

Dans les environnements de 10 à 100 postes, les angles morts sont rarement spectaculaires. Ils sont discrets, et donc dangereux. Un logiciel métier qui n'accepte qu'un partage réseau nommé d'une certaine façon. Une VM restaurable, mais sans le bon VLAN. Une messagerie opérationnelle, sauf pour l'authentification multifacteur. Un accès fibre rétabli, mais pas la téléphonie 3CX.

Il faut aussi penser aux droits. Restaurer des données sans restaurer les autorisations, c'est parfois rouvrir l'activité dans le désordre. Dans les secteurs juridiques, financiers ou soumis à de fortes contraintes de confidentialité, ce détail n'en est pas un. Le système revient, mais il revient de travers.

Quand l'arrêt d'un export Sage révèle un problème plus large

À Melun, une PME de services avait bien ses sauvegardes. Le chiffrement n'avait pas tout emporté, et l'équipe pensait redémarrer vite. Pourtant, le blocage venait d'ailleurs : l'export comptable dépendait d'un poste précis, d'un lecteur réseau mappé à la main et d'un droit local que personne n'avait documenté. Le serveur a été restauré, pas l'habitude technique qui faisait tenir l'ensemble.

Dans ce type de situation, notre travail ne consiste pas seulement à récupérer. Il faut remettre en ordre les dépendances, vérifier les comptes, puis reconnecter les usages métier, y compris ceux liés à Sage. Le redémarrage a été obtenu, mais la vraie leçon était ailleurs : la reprise échoue souvent sur ce qui semblait anodin la veille.

Comment tester sans bloquer l'entreprise

Un test de restauration de sauvegarde utile n'impose pas de couper toute la production. On peut définir un périmètre limité : une VM critique, un partage de fichiers, une base applicative, une boîte Microsoft 365, puis mesurer trois éléments concrets. Le temps de récupération, l'intégrité des données et la capacité réelle des utilisateurs à reprendre.

Le bon test ne cherche pas à rassurer. Il cherche à faire apparaître les frottements. Il doit produire un ordre de reprise, une liste de dépendances et des écarts à corriger. Les recommandations de l'ANSSI et les ressources de Cybermalveillance.gouv.fr vont d'ailleurs dans ce sens : documenter, tester, rejouer.

Les indicateurs qu'un dirigeant devrait demander

Pour savoir si une sauvegarde restaurable est vraiment prête, demandez peu d'indicateurs, mais les bons. Quel est le taux de succès des sauvegardes ? Quelle a été la date du dernier test de restauration complet ? Combien de temps faut-il pour relancer le fichier partagé principal, puis l'application métier critique ? Qui valide que la reprise est utilisable côté métier, pas seulement côté technique ?

Ajoutez une question très simple, souvent décisive : si le prestataire habituel est indisponible, la documentation permet-elle à un autre intervenant de reprendre proprement ? En Île-de-France comme ailleurs, c'est souvent ce niveau de clarté qui sépare un incident grave d'une semaine perdue.

Mettre la reprise au niveau réel de votre activité

Compter sur une sauvegarde seule, c'est souvent confondre stock de données et capacité de redémarrage. Si votre structure dépend de plusieurs briques - fichiers, messagerie, logiciel métier, téléphonie, accès distant - il devient raisonnable de formaliser un PRA proportionné, puis de le tester. Nous détaillons cette logique dans nos articles d'expertise et nous pouvons l'évaluer dans le cadre d'un accompagnement d'infogérance en Île-de-France ou à distance. Le bon objectif n'est pas d'avoir beaucoup de sauvegardes. C'est de savoir, calmement, dans quel ordre votre activité revient.