Les points clés à garder en tête
- Une vraie sauvegarde conserve des versions récupérables, même si les fichiers d’origine sont supprimés ou chiffrés.
- La règle 3-2-1 reste une base solide : 3 copies, sur 2 supports, dont 1 hors ligne ou hors site.
- La synchronisation n’est pas une sauvegarde à elle seule, car elle réplique aussi les erreurs et les suppressions.
- L’immutabilité, le chiffrement et la séparation des accès font une vraie différence contre les attaques.
- Un test de restauration régulier vaut mieux qu’une politique de sauvegarde jamais vérifiée.
- En France, il faut aussi regarder la conformité, la localisation des données et les conditions de sous-traitance.
Pourquoi une copie distante change vraiment la donne
Je vois souvent la même erreur de départ : on pense avoir sécurisé ses données parce qu’elles “sont dans le cloud”. En réalité, ce qui protège vraiment, c’est la présence d’une copie indépendante, séparée du poste de travail, du serveur ou du NAS principal. Une panne matérielle, un vol d’ordinateur portable, un incendie ou un rançongiciel peuvent frapper toute l’infrastructure locale en une seule fois.
La CNIL recommande d’ailleurs une logique simple et robuste : 3 copies, 2 supports différents, dont 1 hors ligne. Cette approche garde tout son intérêt en 2026, parce qu’elle répond à un problème très concret : si une seule source de vérité est compromise, il ne reste plus rien à restaurer. Le cloud devient alors intéressant non pas parce qu’il est “moderne”, mais parce qu’il introduit une vraie séparation géographique et technique.
Pour un indépendant, cela peut vouloir dire des documents bureautiques, des devis ou une base de contacts. Pour une PME, la logique s’étend vite aux boîtes mail, aux partages de fichiers, aux machines virtuelles, aux bases de données et aux applications métiers. Plus les données sont critiques, plus il faut penser en termes de reprise et non de simple conservation. C’est justement ce qui distingue une vraie sauvegarde d’une simple synchronisation, et c’est là que beaucoup d’équipes se trompent.
Ce qu’une vraie sauvegarde fait mieux qu’une simple synchronisation
Le piège le plus courant consiste à confondre un espace de synchronisation avec une sauvegarde. Je le dis franchement : si un ransomware chiffre un dossier synchronisé, il peut propager ce chiffrement vers le cloud avant même que quelqu’un ne réagisse. Même logique pour une suppression accidentelle, qui se répercute parfois partout en quelques secondes.
| Critère | Synchronisation simple | Sauvegarde en ligne |
|---|---|---|
| Suppression d’un fichier | Souvent répliquée partout | Peut être récupérée depuis une version antérieure |
| Historique des versions | Souvent limité ou court | Prévu pour restaurer un état daté |
| Protection contre un ransomware | Faible si la synchronisation est immédiate | Meilleure si les versions sont immuables ou isolées |
| Restauration d’un poste complet | Peu adaptée | Conçue pour remettre des données en service |
| Usage principal | Travail collaboratif et accès multi-appareils | Reprise après incident et continuité d’activité |
La différence est simple : la synchronisation sert à garder les fichiers identiques sur plusieurs appareils, alors que la sauvegarde sert à revenir à un point de confiance. Une solution sérieuse garde donc de l’historique, limite l’impact des suppressions, et permet une restauration granulaire, fichier par fichier ou système par système. C’est sur ce terrain que le choix technique commence vraiment, et il mérite d’être regardé de près.

Les critères techniques à vérifier avant de signer
Quand je compare des solutions, je ne commence jamais par l’interface ou le volume de stockage annoncé. Je regarde d’abord les mécanismes qui font la différence en cas d’incident réel. Deux notions sont essentielles ici : RPO, le volume de données que vous acceptez de perdre, et RTO, le temps maximum acceptable pour remettre le service en route.
| Critère | Ce que je recommande | Pourquoi c’est important |
|---|---|---|
| Rétention | 30 à 90 jours pour une PME, davantage si la contrainte métier l’exige | Permet de revenir en arrière après une erreur détectée tardivement |
| Fréquence de sauvegarde | Au minimum quotidienne, plus souvent pour les données très actives | Réduit la perte de données entre deux points de restauration |
| Immutabilité | Au moins une copie inviolable ou protégée contre la suppression | Complique fortement la tâche des attaquants et des suppressions accidentelles |
| Chiffrement | En transit et au repos, avec gestion claire des clés | Protège la confidentialité pendant le transport et dans le stockage |
| Gestion des clés | Clés contrôlées par le client ou au minimum bien cloisonnées | Évite de dépendre entièrement du fournisseur pour l’accès aux données sensibles |
| Restauration granulaire | Fichier, dossier, boîte mail, base de données ou machine complète | Permet de restaurer seulement ce qui manque, au lieu de tout remettre à plat |
| Journalisation | Logs d’accès, d’administration et de restauration | Facilite l’audit et la détection d’un comportement anormal |
| Tests de reprise | Trimestriels pour les systèmes critiques, au minimum annuels sinon | Une sauvegarde non testée reste une promesse, pas une garantie |
Je trouve utile de raisonner aussi en termes de couches de protection. Une sauvegarde protégée par chiffrement, mais sans immutabilité, reste vulnérable à certains scénarios d’attaque. À l’inverse, une copie immuable mais impossible à restaurer rapidement n’aide pas beaucoup dans une crise opérationnelle. Le bon équilibre, c’est celui qui vous permet de restaurer vite, sans ouvrir trop de portes.
Mettre en place une stratégie fiable sans alourdir l’infrastructure
Dans la pratique, une stratégie solide tient rarement dans une pile d’outils compliqués. Elle repose plutôt sur quelques décisions bien posées et appliquées sans déviation. Je construis généralement le plan en cinq étapes.
- Classer les données en trois niveaux : critiques, importantes et archivables.
- Définir les objectifs de RPO et de RTO pour chaque niveau, au lieu d’avoir un seul réglage pour tout.
- Choisir la cadence de sauvegarde selon l’activité réelle : quotidienne pour les fichiers de bureau, plus fréquente pour les bases ou les applications métiers.
- Isoler les accès avec MFA, comptes dédiés et droits minimums, afin qu’un compte compromis ne puisse pas effacer tous les points de restauration.
- Planifier des tests de restauration dans un environnement séparé, avec un vrai temps mesuré de remise en service.
Pour une PME, la bonne combinaison ressemble souvent à ceci : une sauvegarde locale rapide pour les restaurations simples, une copie distante pour la continuité, et une version immuable pour le scénario de crise. Ce montage évite de dépendre d’un seul support et réduit le risque de point de défaillance unique. Une fois cette base en place, la question suivante n’est plus “est-ce que ça sauvegarde ?”, mais “est-ce que c’est conforme et exploitable dans mon contexte ?”.
Sécurité, conformité et limites à connaître en France
En France, le sujet ne se limite pas à la technique. Il faut aussi regarder la conformité, la localisation des données, les sous-traitants, les droits d’accès et la manière dont le fournisseur traite les clés de chiffrement. La CNIL insiste depuis longtemps sur ces points : évaluer la sécurité proposée, vérifier la redondance, le chiffrement, la sécurité physique et les lieux de sauvegarde géographiquement éloignés des datacenters principaux.Je recommande de vérifier systématiquement trois choses avant de confier des données sensibles :
- Où vont les données et dans quels pays transitent-elles réellement.
- Qui peut y accéder, y compris côté support, administration et sous-traitance.
- Comment les clés sont gérées, car un chiffrement qui dépend entièrement du fournisseur ne protège pas de la même façon qu’un chiffrement maîtrisé côté client.
Il faut aussi garder une limite en tête : une sauvegarde n’est pas un archivage. Pour des obligations légales de conservation, d’e-discovery ou de preuve, on peut avoir besoin d’un dispositif distinct, plus rigide sur la durée et l’intégrité. Autre point souvent sous-estimé : une restauration volumineuse dépend du réseau, du temps de copie et du volume à rapatrier. Pour des téraoctets de données, la vitesse de reprise peut devenir le vrai sujet, pas la capacité de stockage elle-même.
Enfin, je me méfie des solutions qui promettent tout sans préciser leur mécanique de restauration. Si un fournisseur ne documente pas clairement l’immuabilité, la rétention, les logs et les tests de reprise, il y a de fortes chances que la protection soit plus théorique que réelle. C’est précisément pour cela qu’il faut relier la sécurité technique à la réalité métier, et c’est ce qui permet de finir avec une stratégie vraiment exploitable.
Ce que je retiendrais pour un indépendant ou une PME
Si je devais résumer la bonne approche en trois décisions simples, je choisirais d’abord une copie séparée du poste principal, ensuite une version protégée contre la suppression, et enfin un test de restauration documenté. Ce trio vaut souvent mieux qu’une solution plus chère jamais vérifiée.
- Pour un indépendant, la priorité absolue est de pouvoir restaurer rapidement les documents, la messagerie et les fichiers clients.
- Pour une PME, l’enjeu principal est de couvrir les partages, les bases de données et les applications métiers sans dépendre d’un seul support.
- Pour tous, le meilleur indicateur n’est pas la taille du stockage, mais le temps réel de reprise après incident.
Une stratégie simple, testée et bien isolée protège mieux qu’un empilement d’options mal maîtrisées. Si je devais garder une seule idée, ce serait celle-ci : une copie distante n’a de valeur que si elle est restaurable, intacte et vraiment indépendante du reste de l’infrastructure.
