Se rendre au contenu

Ransomware : deux victimes sur trois récupèrent grâce à leurs sauvegardes. Et la troisième ?

Une sauvegarde ne vous sauve d'un ransomware que si elle est hors de portée de l'attaquant et si vous l'avez déjà restaurée.
10 novembre 2026 par
Ransomware : deux victimes sur trois récupèrent grâce à leurs sauvegardes. Et la troisième ?

Le 15 juillet 2026, Sophos a publié son rapport annuel sur les ransomwares : parmi les organisations dont les données ont été chiffrées, 66 % les ont récupérées grâce à leurs sauvegardes, contre 54 % un an plus tôt. Deux victimes sur trois s'en sortent donc grâce à leur sauvegarde contre le ransomware. Pour une PME, la question utile n'est pas « ai-je des sauvegardes ? » mais « ma sauvegarde survivrait-elle à un ransomware, et saurais-je la restaurer ? ».

L'essentiel

  • Selon Sophos, 56 % des attaques par ransomware ont réussi à chiffrer les données de la victime sur les douze mois étudiés.
  • Quand les données sont chiffrées, 66 % des organisations les récupèrent par leurs sauvegardes et 48 % paient la rançon, les deux réponses pouvant se cumuler.
  • Payer ne garantit rien : selon Hiscox, seules 60 % des entreprises qui ont payé ont récupéré tout ou partie de leurs données, et 31 % se sont vu réclamer davantage.
  • Une sauvegarde ne protège d'un ransomware que si elle est hors de portée de l'attaquant et si sa restauration a été testée.

Ce qui se passe

Le rapport The State of Ransomware 2026 repose sur une enquête menée de janvier à mars 2026 par l'institut Vanson Bourne pour Sophos, auprès de 2 158 responsables informatiques et cybersécurité dans 17 pays. Toutes leurs organisations, de 100 à 5 000 employés, avaient subi un ransomware au cours des douze mois précédents. C'est donc une photographie des victimes, pas de l'ensemble des entreprises.

Trois chiffres méritent l'attention. D'abord, 56 % des attaques ont abouti au chiffrement des données, contre 50 % dans l'édition précédente : les attaquants regagnent du terrain. Ensuite, parmi les organisations chiffrées, 66 % ont récupéré leurs données par leurs sauvegardes, soit 12 points de plus qu'un an plus tôt. Enfin, 48 % ont payé la rançon. Le questionnaire autorisait plusieurs réponses : une même entreprise a pu restaurer une partie de ses données et payer pour le reste. Seules 2 % n'ont rien récupéré du tout.

Le rapport note aussi que les plus petites organisations interrogées, de 100 à 250 employés, n'ont arrêté l'attaque avant le chiffrement que dans 34 % des cas, contre 46 % pour les plus grandes, de 3 001 à 5 000 employés. Et le coût moyen de la remise en état, rançon non comprise, atteint 1,7 million de dollars par incident.

Sa recommandation sur ce point est sans ambiguïté : des sauvegardes testées régulièrement, conservées hors ligne ou sous une forme non modifiable, et intégrées à un plan de réponse documenté, applicable sous pression.

L'assureur Hiscox apporte l'autre moitié du tableau. Dans son rapport 2025 sur la cyber-préparation, publié le 29 septembre 2025 et portant sur 5 750 entreprises de sept pays, 27 % des entreprises disaient avoir subi un ransomware dans l'année. Parmi elles, 80 % ont payé. Mais seules 60 % de celles qui ont payé ont récupéré tout ou partie de leurs données, et 31 % ont reçu une nouvelle demande d'argent.

Ce que ça change pour la sauvegarde de votre PME face au ransomware

La bonne nouvelle est réelle : une sauvegarde bien faite reste le moyen le plus sûr de sortir d'un ransomware sans négocier avec ceux qui vous ont attaqué. Mais l'écart entre « avoir des sauvegardes » et « récupérer grâce à ses sauvegardes » est précisément là où se trouve la troisième victime. Le rapport ne dit pas combien d'entre elles pensaient être couvertes. Sur le terrain, j'en vois trois causes principales.

La sauvegarde est à portée de l'attaquant. Un disque externe branché en permanence, un partage réseau accessible depuis le serveur, un dossier synchronisé dans le cloud : si votre serveur peut écrire dans la sauvegarde, celui qui prend la main sur votre serveur peut l'effacer ou la chiffrer aussi.

La sauvegarde est incomplète ou inutilisable. Une base de données copiée fichier par fichier pendant qu'elle tourne peut ressembler à une sauvegarde sans pouvoir être restaurée. Un oubli de périmètre (la messagerie, la configuration, les pièces jointes) ne se voit que le jour où il manque.

Personne n'a jamais restauré. On découvre alors, sous pression, qu'il manque un mot de passe, que la procédure n'est écrite nulle part, ou que la restauration prend trois jours au lieu de trois heures. Une sauvegarde jamais restaurée n'est qu'une hypothèse.

Ce que j'en ai appris

J'applique ces règles à mon propre système de gestion, celui qui porte la comptabilité, les sites web et les rendez-vous de mes sociétés. Chaque nuit, la base de données est exportée, puis relue automatiquement : un export illisible fait échouer la tâche au lieu de passer inaperçu. Une copie part ensuite hors site, vers un stockage où le serveur de production peut ajouter des sauvegardes mais pas les effacer. Si ce serveur était compromis, l'attaquant ne pourrait pas détruire l'historique. Je suis prévenu à chaque passage, en cas de succès comme en cas d'échec : un silence n'est jamais une bonne nouvelle.

En septembre 2026, j'ai relu toute cette chaîne et trouvé un piège : la copie des fichiers bruts de la base, prise moteur en marche, ressemblait à une sauvegarde sans aucune garantie d'être restaurable. Je l'ai retirée pour ne garder que l'export vérifié, plutôt que de laisser croire un jour à quelqu'un qu'il pouvait s'en servir. Puis j'ai fait le seul test qui compte : restaurer l'export de la nuit dans un environnement jetable, coupé de tout réseau, et comparer le résultat à la production. Restauration terminée en moins de deux minutes, sans erreur, et les sept comptages de contrôle identiques. Je refais ce test au moins une fois par trimestre et après chaque mise à jour importante. Autre règle : je fais une sauvegarde avant toute intervention qui modifie des données.

J'ai aussi appris qu'un filet qu'on n'a jamais éprouvé peut lâcher. Après une mise à jour automatique du système, mon application ne s'est pas relancée : 8 h 30 d'arrêt des sites, alors que je croyais ce cas couvert. J'ai corrigé le réglage, puis provoqué volontairement la même panne pour le vérifier : le service est revenu seul en moins d'une demi-minute. C'est la même logique que pour une sauvegarde : tant qu'on n'a pas joué le scénario, on ne sait pas.

Ce n'est pas nouveau dans mon métier. En concevant l'infrastructure informatique d'AtonRa Partners, une société de gestion financière, les sauvegardes faisaient partie du socle, au même titre que les serveurs, le réseau et la sécurité des accès, avec une documentation technique remise à l'équipe. Les outils ont changé depuis ; le principe non.

Que faire concrètement

1. Faites la liste de ce qui doit revenir

Bases de données, fichiers partagés, messagerie, documents comptables, configuration des serveurs et des applications. Pour chacun : combien de jours de données pouvez-vous perdre, et combien de temps pouvez-vous rester à l'arrêt ? Ces deux réponses dictent la fréquence des sauvegardes et le type de solution.

2. Mettez une copie hors de portée

Au moins une copie hors de vos locaux, que vos serveurs ne peuvent ni modifier ni effacer : stockage en ajout seul, non modifiable pendant une durée donnée, ou support déconnecté. Gardez plusieurs générations, sur plusieurs semaines et plusieurs mois, pour pouvoir remonter avant le début d'une infection discrète.

3. Faites vérifier chaque sauvegarde automatiquement

Une tâche de sauvegarde doit contrôler ce qu'elle produit et vous prévenir en cas d'échec comme en cas de succès. Si vous ne recevez rien, c'est un signal, pas un répit.

4. Testez une restauration complète

Dans un environnement isolé, restaurez réellement vos données et comparez-les à la production. Chronométrez l'opération : c'est votre véritable délai de reprise. Recommencez au moins une fois par trimestre et après chaque changement important.

5. Écrivez la procédure avant d'en avoir besoin

Qui décide, qui appelle qui, où sont les accès nécessaires à la restauration, dans quel ordre on remonte les services, et quelle est votre position sur le paiement d'une rançon. Une décision prise à froid vaut mieux qu'une décision prise en pleine crise.

Questions fréquentes

Une synchronisation dans le cloud suffit-elle comme sauvegarde contre un ransomware ?

Non. Une synchronisation recopie fidèlement les fichiers chiffrés par le ransomware. Il faut des versions conservées dans le temps et une copie que vos postes et vos serveurs ne peuvent pas modifier.

À quelle fréquence faut-il tester une restauration ?

Au moins une fois par trimestre, et systématiquement après une mise à jour majeure d'une application ou d'une base de données. Un test qui n'a jamais été fait ne vous dit rien de votre délai réel de reprise.

Faut-il payer la rançon si les sauvegardes manquent ?

C'est une décision qui vous appartient, mais les chiffres de Hiscox sont clairs : payer ne garantit ni le retour des données ni la fin des demandes. La meilleure position est de ne pas avoir à faire ce choix.

Pour aller plus loin

Je conçois et j'exploite des infrastructures pour des PME, sauvegardes et tests de restauration compris : voir la page Systèmes et infrastructure. Si vous voulez savoir si vos sauvegardes tiendraient face à un ransomware, parlons-en lors d'un appel de 20 minutes.

Sources

Photo : Domaintechnik / Unsplash (unsplash.com/photos/VHmBX7FnXw0).

Tags : ransomware, sauvegarde, restauration, PME, cybersécurité, continuité d'activité, infrastructure

Data Act : dès le 12 janvier 2027, plus de frais de sortie pour changer de cloud
La loi supprime le frais, pas le travail : préparez votre plan de sortie maintenant.