La règle 3-2-1-0 : pourquoi « avoir des sauvegardes » ne protège pas

Presque toute entreprise vous dira, l'air tranquille, qu'elle « a des sauvegardes ». Le problème, c'est que les attaquants le savent mieux que vous — et ils comptent dessus. Selon les rapports Veeam de 2025, les sauvegardes sont visées directement dans 96 % des attaques ransomware, et dans environ 76 % des cas les attaquants parviennent à les compromettre. Autrement dit, la première cible n'est pas vos données de production, mais précisément le filet de sécurité sur lequel vous comptez pour vous relever.

« Avoir des sauvegardes » et « pouvoir se rétablir dans un délai acceptable » sont deux affirmations totalement différentes. La première concerne le stockage. La seconde concerne une capacité de restauration que vous avez testée et en laquelle vous avez confiance. Entre les deux se trouvent les entreprises qui, le jour d'un incident, découvrent que leurs fichiers copiés étaient chiffrés eux aussi, ou qu'une restauration complète prend trois jours au lieu de trois heures.

Une sauvegarde que vous n'avez jamais testée n'est qu'un espoir

Les données sur la restauration réelle sont impitoyables. Parmi les organisations frappées par un ransomware, seules 10 % environ ont réussi à récupérer plus de 90 % de leurs données, tandis que 57 % en ont récupéré moins de la moitié (Veeam, 2025). Un rapport de 2026 confirme la tendance : seuls 28 % des victimes ont entièrement récupéré leurs données affectées, et 44 % sont restées sous la barre des 75 %. Ce ne sont pas des entreprises sans aucune sauvegarde — ce sont des entreprises qui « avaient des sauvegardes ».

Et même quand les données sont récupérables, le temps vous tue. Une étude de 2026 montre que 60 % des responsables IT ont besoin de six heures ou plus pour une restauration complète, et que seuls 5 % y parviennent en moins d'une heure. Pour une entreprise qui facture, produit ou livre chaque jour, la différence entre trois heures et trois jours d'arrêt n'est pas un détail technique — c'est la différence entre un incident et une crise existentielle.

Pourquoi les sauvegardes échouent-elles exactement quand vous en avez le plus besoin ? Généralement pour quelques raisons récurrentes :

• La sauvegarde est connectée en permanence au même réseau — elle est donc chiffrée avec tout le reste, dans la même attaque.
• Elle n'a jamais été testée par une restauration réelle — personne ne sait si l'archive s'ouvre avant le jour où cela compte.
• La restauration « fonctionne », mais les applications ne démarrent pas : permissions manquantes, dépendances, ordre de démarrage des services.
• Personne n'a décidé, en chiffres, combien de données l'entreprise peut se permettre de perdre et combien de temps elle peut rester à l'arrêt — il n'y a donc aucun objectif pour mesurer le succès.

La synchronisation cloud n'est pas une sauvegarde

Il existe une confusion coûteuse, très répandue dans les petites entreprises : la synchronisation n'est pas une sauvegarde. OneDrive, Google Drive ou Dropbox maintiennent les fichiers à jour sur tous les appareils — mais c'est exactement pour cela qu'ils propagent aussi le chiffrement. Quand le ransomware chiffre vos fichiers en local, la version « sûre » du cloud est écrasée par la version chiffrée en quelques secondes. Un service de synchronisation sans versionnage et sans copie immuable séparée ne vous sauve pas d'une attaque, il ne fait que la répliquer plus vite sur chaque appareil connecté.

La raison pour laquelle l'effort en vaut la peine est simple : le coût de l'arrêt. Pour une entreprise qui dépend de ses systèmes pour facturer, produire ou livrer, chaque heure d'immobilisation signifie des commandes retardées, du personnel payé pour rien et de la confiance perdue. Une sauvegarde bon marché qui ne fonctionne pas ne fait pas économiser d'argent — elle ne fait que reporter et amplifier la facture.

De 3-2-1 à 3-2-1-0 : ce que change le dernier zéro

La règle classique 3-2-1 reste la bonne fondation : 3 copies des données, sur 2 types de supports différents, avec 1 copie hors site. Pendant des années, cela a suffi. À l'ère du ransomware, ce n'est plus le cas — car elle suppose qu'une copie « hors site » est automatiquement en sécurité, ce qui n'est plus vrai quand les attaquants traquent activement les sauvegardes.

D'où l'extension 3-2-1-0 (et la variante 3-2-1-1-0). Les chiffres ajoutés ne sont pas du marketing, ce sont exactement la brèche par laquelle la plupart des entreprises tombent aujourd'hui :

1. 1Un « 1 » supplémentaire — une copie immuable ou air-gapped : une copie qui ne peut être ni modifiée ni supprimée, même avec des identifiants administrateur compromis. C'est la seule qui survit à une attaque ayant pris le contrôle du réseau.
2. 2Un « 0 » — zéro erreur de restauration : chaque sauvegarde est vérifiée, et la restauration est testée périodiquement jusqu'à ce que le nombre d'erreurs soit nul. Une sauvegarde non testée n'est pas une protection, c'est une hypothèse.

Le chiffre qui devrait vous inquiéter : bien que 89 % des organisations rapportent que des attaquants ont visé leurs sauvegardes, seules 32 % utilisent réellement un dépôt immuable (Veeam, 2025). Les autres ont compris la menace mais n'ont pas fermé la porte. C'est là que la restauration se gagne ou se perd — pas dans le logiciel de sauvegarde, mais dans l'architecture qui l'entoure.

Une sauvegarde que vous n'avez jamais restaurée n'est pas une copie de sécurité — c'est une promesse que vous n'avez jamais vérifiée. Le ransomware la vérifie à votre place, exactement le jour où vous ne pouvez pas vous permettre de le découvrir.

RPO et RTO : les deux chiffres à décider avant tout outil

L'erreur de mise en œuvre la plus fréquente est de commencer par « quel logiciel de sauvegarde acheter ? ». L'ordre correct est inverse. Avant tout outil, l'entreprise doit répondre à deux questions métier, en chiffres concrets :

• RPO (Recovery Point Objective) — combien de données pouvez-vous vous permettre de perdre, mesuré en temps ? Une heure de travail ? Une journée entière ? La réponse fixe la fréquence de la sauvegarde.
• RTO (Recovery Time Objective) — combien de temps l'entreprise peut-elle rester à l'arrêt avant que la restauration ne devienne inacceptablement coûteuse ? La réponse fixe le type d'infrastructure de restauration nécessaire.

Un objectif de restauration que vous n'avez jamais testé n'est qu'une supposition. Ces deux chiffres, décidés avec la direction et pas seulement avec « l'informaticien », transforment la sauvegarde d'une vague dépense technique en une décision de continuité d'activité. Sans eux, toute mise en œuvre est sur- ou sous-dimensionnée — vous payez trop pour des données sans importance, ou trop peu pour celles dont l'entreprise dépend.

Un exemple rend tout concret. Si le RPO convenu est d'une heure, une sauvegarde quotidienne n'est pas une solution : un incident à 17 h vous coûterait toute la journée de travail. Si le RTO est de quatre heures, une restauration qui tire des téraoctets par internet depuis un cloud lointain ne convient pas — il vous faut aussi une copie locale rapide, en plus de la copie hors site. Ces deux chiffres ne sont pas de la bureaucratie ; ils dictent directement l'architecture, la fréquence et le budget de toute la solution.

À quoi ressemble une mise en œuvre qui vous protège vraiment

Une mise en œuvre sérieuse, ce n'est pas « installer un programme et cocher la case sauvegarde ». C'est un petit projet aux étapes claires, où chaque phase comble l'une des brèches ci-dessus. Voici comment nous structurons une mise en œuvre de stratégie de sauvegarde 3-2-1-0 :

1. 1Atelier RPO/RTO avec la direction : pour chaque système critique, nous fixons combien de données peuvent être perdues et combien d'arrêt est acceptable. C'est là que naissent les vrais objectifs.
2. 2Conception 3-2-1-0 : nous concevons les 3 copies sur 2 supports, avec une copie hors site et, surtout, une copie immuable que le ransomware ne peut atteindre.
3. 3Configuration (Veeam Backup & Replication + stockage QNAP) : nous déployons réellement la solution, avec rétention, chiffrement et immuabilité activés — pas seulement « en marche », mais configurée pour le scénario d'attaque.
4. 4Test de restauration réel : nous restaurons effectivement données et applications dans un environnement contrôlé, pour prouver qu'elles s'ouvrent, démarrent et fonctionnent — et que nous respectons le RTO promis.
5. 5Runbooks + formation de l'administrateur local : nous documentons, étape par étape, qui fait quoi le jour d'un incident, afin que la restauration ne dépende ni d'une seule personne ni de la chance.

La dernière étape est celle que la plupart des entreprises sautent — et précisément celle qui fait la différence. Une sauvegarde se teste selon un rythme, pas une seule fois à l'installation. La cadence pratique que nous recommandons :

• Mensuel : une restauration de fichiers, comme vérification de routine que les archives s'ouvrent.
• Trimestriel : une restauration au niveau applicatif, dépendances et permissions incluses.
• Annuel : un exercice complet de bascule (failover) de l'environnement critique, chronométré face au RTO.

Quelques pièges que nous voyons souvent et qu'une bonne mise en œuvre ferme d'emblée : une rétention trop courte (vous découvrez l'infection seulement après l'expiration de l'unique copie saine), une immuabilité « sur le papier » mais non réellement activée sur le stockage, une seule personne qui sait lancer la restauration, et l'absence d'une copie totalement déconnectée pour les systèmes les plus critiques. Chacun transforme une sauvegarde qui « existe » en une sauvegarde qui ne vous aide pas précisément le jour J.

La bonne nouvelle, c'est que la maturité paie : les entreprises qui testent et conservent des copies immuables se rétablissent nettement plus vite — la part de celles qui se rétablissent entièrement en une semaine est passée de 35 % à 53 % en une seule année. Ce n'est pas de la magie, c'est de la méthode. Si vous voulez voir ce que cela donne pour votre configuration, nous partons de votre architecture d'infrastructure IT et des systèmes qui n'ont pas le droit de tomber.

Conclusion

La sauvegarde n'est pas une case que l'on coche, c'est une capacité de restauration que l'on prouve. La différence entre « j'ai une sauvegarde » et « j'ai remis mon entreprise en marche en deux heures » se fait précisément par ces deux zéros : une copie immuable et un test de restauration réel, face à des objectifs RPO/RTO choisis consciemment. Si vous n'êtes pas sûr que votre sauvegarde passerait un test réel aujourd'hui, parlons-en 30 minutes — je vous dirai concrètement où vous êtes exposé et par où commencer.