Sauvegarde 3-2-1 : le plan anti-ransomware de votre site web

La sauvegarde 3-2-1 signifie 3 copies de vos données sur 2 supports différents, dont 1 hors site : c'est le minimum pour survivre à un ransomware ou à une panne grave de votre hébergeur.

En 2025, 48 % des attaques par ransomware ont ciblé des PME et TPE. La majorité de ces victimes n'avait pas de sauvegarde testée et exploitable au moment de l'incident. Résultat : des semaines de travail perdues, un site hors ligne, des clients définitivement partis.

Chez ConsilioWEB, nous intégrons systématiquement un plan de sauvegarde dans chaque contrat de maintenance géré pour nos clients. Nous l'avons appris rapidement : la question n'est jamais « sera-t-on attaqués ? » mais « serons-nous prêts quand ça arrivera ? ».

Cet article vous explique comment appliquer la règle sauvegarde 3-2-1 à un site web réel — base de données, fichiers médias, code, configuration. Vous y trouverez les outils, les fréquences recommandées, les bonnes questions à poser à votre prestataire et, surtout, comment tester vos restaurations.

Ransomware et pannes : les scénarios qui tuent un site

Le chiffrement de fichiers par un ransomware est le scénario le plus médiatisé. Ce n'est pourtant pas le seul danger. Quatre types d'incidents reviennent régulièrement dans nos retours terrain.

Scénario 1 : l'attaque par ransomware

Un ransomware s'infiltre via un plugin vulnérable, un accès SSH compromis ou une injection de code. Il chiffre la base de données, les fichiers médias, parfois les sauvegardes locales. Une demande de rançon s'affiche.

En 2025, la rançon médiane pour une PME européenne dépassait 30 000 €. Payer ne garantit rien. Environ 30 % des victimes ne récupèrent pas leurs données après paiement. Sans sauvegarde hors site, le choix se résume à payer ou reconstruire de zéro.

Scénario 2 : la défaillance d'hébergeur

Un hébergeur peut perdre des données. Cela arrive. Panne matérielle, erreur humaine interne, incendie dans un datacenter — ces événements sont rares mais réels. Certains hébergeurs proposent des snapshots automatiques, mais ils restent sur la même infrastructure. Un sinistre majeur emporte tout.

Sans copie externe indépendante, vous dépendez entièrement de la politique de backup de votre hébergeur. Ce n'est pas une position tenable.

Scénario 3 : la fausse manœuvre

Un développeur supprime la mauvaise table. Un administrateur écrase un fichier de configuration critique. Ces accidents sont beaucoup plus fréquents que les attaques. Une sauvegarde quotidienne versionnée permet de remonter 24 heures en arrière en quelques minutes. Sans elle, l'incident anodin devient un désastre.

Scénario 4 : l'injection malveillante silencieuse

Un attaquant injecte du code dans votre base de données via un plugin non mis à jour. Le site reste fonctionnel en apparence, mais sert du phishing. Google vous déréférence dans les 24 heures suivantes. Les avis négatifs s'accumulent.

Réparer votre e-réputation après une compromission prend des mois. Une sauvegarde antérieure à l'injection évite la catastrophe. Corriger la faille applicative initiale est tout aussi urgent — nos recommandations sur la sécurité des Server Actions Next.js couvrent ce sujet en profondeur.

La règle sauvegarde 3-2-1 expliquée simplement

La sauvegarde 3-2-1 est une règle formulée dans les années 2000 par le photographe Peter Krogh. Elle s'est ensuite imposée comme standard de référence en sécurité informatique. Son principe est volontairement simple pour être applicable partout, quelle que soit la taille de l'organisation.

Voici ce que chaque chiffre signifie concrètement :

• 3 copies de vos données — l'originale plus 2 sauvegardes distinctes.
• 2 supports différents — par exemple, un disque NAS local et un stockage cloud.
• 1 copie hors site — physiquement séparée de votre bureau ou datacenter principal.

Certains experts recommandent désormais la règle 3-2-1-1-0 : une copie immuable (non modifiable après écriture) et zéro erreur vérifiée lors des tests de restauration. C'est l'approche que nous conseillons pour les sites e-commerce et les applications métier traitant des données sensibles.

L'immuabilité signifie qu'un accès root compromis ne peut toujours pas supprimer ni modifier vos sauvegardes. C'est la seule protection fiable contre un ransomware qui aurait obtenu vos credentials cloud. Nous y revenons dans la section suivante sur les outils.

La règle 3-2-1 s'applique-t-elle à toutes les tailles de site ?

Oui, sans exception. Un site vitrine de PME peut sembler peu critique — jusqu'au jour où votre commercial perd le numéro client d'une commande en cours, ou jusqu'à ce que votre référencement local, construit sur trois ans, s'effondre parce que le site a affiché du phishing pendant 48 heures. La règle s'adapte à votre budget, pas à votre taille.

Que sauvegarder sur un site web (et à quelle fréquence)

Un site web n'est pas un monobloc. Plusieurs composantes doivent être sauvegardées séparément, avec des fréquences adaptées à leur criticité et à leur rythme de modification.

La base de données : priorité absolue

C'est l'élément le plus critique. Elle contient vos contenus, vos commandes, vos utilisateurs et vos configurations. Une sauvegarde quotidienne est le minimum absolu. Pour un site e-commerce ou un SaaS, visez une sauvegarde toutes les 4 à 6 heures. Pour les applications à forte valeur — facturation, CRM, prise de rendez-vous — envisagez la réplication continue vers une base secondaire.

Les fichiers médias

Images, PDF, vidéos uploadées par vos équipes ou vos utilisateurs — leur volume peut dépasser plusieurs gigaoctets sur un site actif. Ils changent moins souvent que la base de données. En conséquence, une sauvegarde quotidienne suffit dans la plupart des cas. Intégrez-les néanmoins à chaque snapshot complet.

Le code source

Votre code vit normalement dans un dépôt Git hébergé sur GitHub ou GitLab. C'est déjà une sauvegarde versionnée. Assurez-vous cependant que ce dépôt est hébergé chez un fournisseur distinct de votre serveur de production. Si les deux tombent simultanément, vous perdez les deux.

Les fichiers de configuration

Fichiers .env, configuration serveur (nginx, Apache), certificats SSL. Ces fichiers sont souvent exclus du dépôt Git pour des raisons de sécurité. Prévoyez une sauvegarde séparée, chiffrée et stockée hors site. Sans eux, une restauration complète peut prendre plusieurs heures supplémentaires en situation de crise.

Les logs et données transactionnelles

Pour les sites utilisant un headless CMS ou une solution e-commerce, les logs d'activité s'avèrent précieux après un incident. L'architecture de votre CMS influence directement cette stratégie. Notre comparatif Headless CMS 2026 — Sanity, Payload ou Strapi détaille comment chaque solution gère le stockage des données et les implications pour votre plan de backup.

Tableau des fréquences recommandées

Combien de temps conserver les sauvegardes ?

• 30 jours pour les sauvegardes quotidiennes — couvre les incidents récents et les erreurs humaines immédiates.
• 3 mois pour les sauvegardes hebdomadaires — couvre les infections dormantes et les malwares à délai.
• 1 an pour les sauvegardes mensuelles — répond aux obligations légales de traçabilité.

Le RGPD impose en effet de retracer ce qu'il est advenu des données personnelles. Une rétention structurée est donc aussi une obligation de conformité, au même titre que la facturation électronique qui s'applique désormais à toutes les PME françaises.

Automatiser : outils et stratégies 2026

Une sauvegarde manuelle est une sauvegarde oubliée. L'automatisation n'est pas une option, c'est la condition sine qua non d'un plan de sauvegarde crédible.

Les outils de référence

rclone est l'outil le plus polyvalent pour synchroniser vos données vers n'importe quel stockage cloud : AWS S3, Backblaze B2, OVH Object Storage, Scaleway, Google Cloud Storage. Il supporte le chiffrement côté client et s'intègre facilement dans un cron Linux. La configuration prend moins d'une heure pour un cas d'usage standard.

BorgBackup excelle pour les sauvegardes déduplicées et compressées. Il réduit significativement la taille stockée sur des sauvegardes quotidiennes de bases volumineuses. Sa déduplication est particulièrement efficace sur les fichiers médias qui changent peu d'un jour à l'autre.

mysqldump et pg_dump restent les références pour les bases SQL. Un script cron exporte la base, la compresse en .gz et la pousse vers un bucket objet — vingt lignes de Bash, 2 à 5 euros par mois de stockage.

Les destinations de stockage recommandées

Diversifiez les fournisseurs. Ne stockez pas vos trois copies chez le même opérateur.

L'immuabilité : la vraie protection contre les ransomwares

Un ransomware sophistiqué peut, s'il obtient vos credentials cloud, supprimer ou chiffrer vos sauvegardes distantes. La parade s'appelle l'Object Lock (verrouillage d'objet), disponible sur AWS S3 et les stockages compatibles S3.

Une sauvegarde sous Object Lock ne peut pas être modifiée ni supprimée avant une date fixée — même par un compte root compromis. Activez le mode COMPLIANCE (non révocable) pour vos sauvegardes critiques, avec une rétention minimale de 30 jours.

Pensez également à séparer les credentials d'écriture (utilisés par vos scripts cron) des credentials d'administration (utilisés pour gérer les buckets). Un ransomware qui vole vos credentials d'écriture ne peut donc pas supprimer les fichiers déjà verrouillés.

La question de la souveraineté des données dépasse d'ailleurs la seule sauvegarde. Notre article sur les LLM locaux et la souveraineté des données explore les enjeux plus larges du contrôle de votre infrastructure, notamment pour les entreprises sensibles aux localisations géographiques des données.

Organiser ses crons et surveiller les échecs

Ne lancez pas tous vos jobs de sauvegarde simultanément. Un pic de charge nocturne peut ralentir votre site le lendemain matin si les tâches débordent. Échelonnez vos crons par priorité :

• 02h00 : export base de données + push cloud chiffré.
• 03h00 : synchronisation des médias (delta quotidien via rclone).
• 04h00 : vérification d'intégrité des archives créées.

Ajoutez une alerte email ou Slack dès qu'une tâche échoue. Sans monitoring actif, un échec silencieux peut passer inaperçu plusieurs semaines. Le jour où vous en avez besoin, votre « sauvegarde » date de six semaines.

Chiffrement et accès aux sauvegardes

Chiffrez systématiquement vos sauvegardes avant l'envoi — en particulier si elles contiennent des données personnelles. rclone intègre un chiffrement AES-256 transparent, activable en quelques lignes de configuration. Stockez les clés de déchiffrement dans un gestionnaire de secrets (Bitwarden, Vaultwarden, Infisical) distinct de votre infrastructure principale. Une sauvegarde dont vous ne pouvez pas déchiffrer les données est inutile.

Tester ses restaurations : le vrai test de survie

Une sauvegarde qu'on n'a jamais testée n'est pas une sauvegarde. C'est un espoir. Il y a une différence considérable entre les deux.

Pourquoi les tests sont si souvent négligés ?

La restauration est mentalement associée à la catastrophe. On la reporte indéfiniment. En pratique, un fichier de sauvegarde peut être corrompu, incomplet ou dans un format que votre outil ne supporte plus après une mise à jour majeure.

Des organisations ont perdu toutes leurs données précisément parce qu'elles ne testaient pas leurs restaurations. Elles pensaient être protégées. Elles ne l'étaient pas.

Comment tester concrètement

1. Restauration partielle (base seule) : importez votre dernière sauvegarde de base de données sur un serveur de test. Vérifiez la cohérence des données — comptes utilisateurs, commandes récentes, contenus créés dans les 24 dernières heures.
2. Restauration complète en staging : montez une copie intégrale du site sur un environnement distinct. Vérifiez que le site démarre, que les formulaires fonctionnent, que les assets s'affichent correctement.
3. Restauration d'une sauvegarde ancienne : testez une sauvegarde vieille de 30 jours. Le format est-il toujours lisible ? Les données sont-elles cohérentes ? Cette étape révèle les problèmes de rétention à long terme.
4. Chronométrage du RTO : mesurez le temps total de remise en service complète. Ce délai s'appelle le Recovery Time Objective (RTO). Pour un site e-commerce, un RTO de 2 heures maximum est une cible raisonnable. Connaissez le vôtre avant d'en avoir besoin.

Fréquences recommandées pour les tests de restauration

Documenter la procédure : le runbook

Notez chaque étape de restauration dans un document appelé runbook. Ce document doit rester accessible même si votre serveur principal est hors ligne — stockez-le sur un Google Drive ou un Notion séparé, accessible depuis n'importe quel appareil.

En situation de crise, vous n'avez pas à réfléchir. Vous suivez les étapes dans l'ordre. Une heure de documentation en amont économise une journée entière de stress en situation réelle.

Le GameDay : simuler l'incident pour de vrai

Les équipes SRE des grands groupes pratiquent le GameDay : une simulation d'incident complet où l'on coupe volontairement le service de production et où l'on mesure le temps de remise en service réelle. Rien n'empêche une PME de l'adapter à son échelle. Deux heures, une fois par an, suffisent à révéler les angles morts de votre plan — l'accès manquant, le script cassé, la documentation obsolète.

Sauvegarde et contrat de maintenance : les bonnes questions

Votre prestataire web gère vos sauvegardes ? Posez ces questions avant de signer, et exigez des réponses précises et documentées.

Les 7 questions à poser à votre prestataire

1. Quelles données sont sauvegardées exactement — base de données, médias, configuration ?
2. Quelle est la fréquence des sauvegardes ?
3. Où sont stockées les sauvegardes — sur l'hébergeur principal ou sur une infrastructure externe distincte ?
4. Quelle est la durée de rétention des sauvegardes ?
5. Les sauvegardes sont-elles chiffrées avant envoi ?
6. Des tests de restauration sont-ils réalisés régulièrement, et à quelle fréquence ?
7. Quel est le RTO garanti contractuellement en cas d'incident ?

Un prestataire qui ne peut pas répondre précisément à ces sept questions n'a probablement pas de plan de sauvegarde structuré. C'est un signal d'alarme, non une formalité.

Ce qu'un bon contrat de maintenance inclut

Un contrat de maintenance web sérieux prévoit au minimum :

• Des sauvegardes automatisées quotidiennes (base de données + médias).
• Un stockage hors site sur une infrastructure distincte de l'hébergeur principal.
• Un test de restauration documenté au moins une fois par trimestre.
• Un rapport périodique incluant l'état des sauvegardes et les éventuels échecs.
• Un runbook de restauration accessible 24h/24, même en cas de panne totale du site.
• Une clause de RTO précisant le délai de remise en service garanti.

Ce que ConsilioWEB intègre dans chaque contrat

Chez nous, chaque site maintenu bénéficie de ce dispositif complet. Nous stockons les sauvegardes sur un service objet distinct de l'hébergeur principal, avec rétention de 30 jours minimum sur les quotidiennes et 3 mois sur les hebdomadaires. Un test de restauration partielle est réalisé chaque mois. Nous documentons la procédure dans un runbook mis à jour à chaque changement d'infrastructure.

En cas d'incident, nos clients savent exactement ce qui est sauvegardé, où, sous quel chiffrement et en combien de temps on peut restaurer. Ce niveau de clarté évite les mauvaises surprises les jours où le stress est déjà maximal.

Questions fréquentes sur la sauvegarde 3-2-1

La sauvegarde 3-2-1 est-elle obligatoire pour les PME françaises ?

Elle n'est pas imposée par un texte précis, mais le RGPD exige de garantir l'intégrité et la disponibilité des données personnelles. En pratique, un dispositif conforme à la règle sauvegarde 3-2-1 est le moyen le plus fiable de satisfaire cette exigence légale. En cas de perte de données, l'absence de sauvegarde documentée peut constituer un manquement sanctionnable par la CNIL — avec des amendes pouvant atteindre 2 % du chiffre d'affaires mondial.

Combien coûte une solution de sauvegarde 3-2-1 pour un site PME ?

Pour un site standard, une solution de base — export DB quotidien plus médias sur Backblaze B2 — revient à 5 à 15 € par mois de stockage. Un dispositif complet avec Object Lock, tests automatisés et runbook représente 30 à 80 € par mois. Ce montant est souvent inclus dans un contrat de maintenance global, ce qui le rend difficilement comparable au coût d'un site hors ligne pendant 48 heures.

Le stockage cloud suffit-il comme unique sauvegarde hors site ?

Non. Le cloud est un excellent support hors site, mais il ne remplace pas les 3 copies distinctes. Si vous conservez une copie locale et une copie cloud chez le même hébergeur que votre site de production, vous ne respectez pas la règle 3-2-1. Les fournisseurs doivent être véritablement distincts. De plus, une seule copie cloud sans Object Lock reste vulnérable à un ransomware qui obtient vos credentials.

Quelle différence entre un snapshot et une sauvegarde ?

Un snapshot est une image instantanée d'un serveur ou d'un disque, généralement conservée sur la même infrastructure. Une sauvegarde est une copie exportée vers un support ou service externe indépendant. Les deux sont complémentaires : le snapshot offre une restauration rapide après une fausse manœuvre, la sauvegarde externe protège contre un sinistre global. Un snapshot seul ne constitue pas une sauvegarde 3-2-1.

La sauvegarde protège-t-elle contre tous les ransomwares ?

Pas automatiquement. Un ransomware dormant peut rester inactif plusieurs semaines avant d'activer le chiffrement. Si toutes vos sauvegardes datent de moins d'un mois, elles peuvent toutes contenir le malware. C'est pourquoi une rétention longue — 3 mois minimum sur les sauvegardes hebdomadaires — et l'immuabilité via Object Lock sont indispensables. Bien appliquée, la règle sauvegarde 3-2-1 limite très fortement l'impact d'une attaque, sans l'éliminer complètement si les délais de rétention sont trop courts.

Ne laissez pas le hasard décider

La sauvegarde 3-2-1 n'est pas réservée aux grandes entreprises. C'est le filet de sécurité de base pour tout site web qui joue un rôle dans votre activité — vitrine, e-commerce ou application métier.

La règle est simple à énoncer : 3 copies, 2 supports, 1 hors site. Son application exige cependant de la rigueur : automatisation, chiffrement, immuabilité et tests réguliers. Un backup non testé n'a jamais sauvé personne.

La maintenance web va bien au-delà des mises à jour de plugins. Elle englobe la résilience de l'ensemble de votre infrastructure numérique, et la sauvegarde en est le pilier central.

Si vous n'êtes pas certain que votre site est correctement protégé, ou si vous souhaitez faire auditer votre stratégie de sauvegarde actuelle, notre équipe à Ussel peut analyser votre infrastructure et vous proposer un plan concret adapté à votre budget. Contactez-nous via le formulaire de devis — un premier échange suffit souvent à identifier les failles avant qu'elles ne coûtent cher.

Pour aller plus loin

• Guide CNIL : la sécurité des données personnelles — cnil.fr
• BorgBackup : documentation officielle — borgbackup.readthedocs.io
• rclone : synchronisation et chiffrement vers le cloud — rclone.org
• AWS S3 Object Lock : guide officiel — docs.aws.amazon.com