“C’est chiffré, donc je suis tranquille.” C’est probablement l’un des raccourcis les plus coûteux en cybersécurité domestique et pro. Le chiffrement est essentiel — mais il ne protège pas contre tout, et surtout pas contre les scénarios qui font le plus mal : ransomware, compte cloud piraté, synchronisation qui réplique une catastrophe, suppression accidentelle, ou sauvegarde “en miroir” qui écrase l’historique.
Le sujet est décortiqué en profondeur dans Sauvegardes chiffrées : pourquoi beaucoup pensent être protégés… alors qu’ils ne le sont pas. Ici, l’objectif est plus opérationnel : vous donner une grille de lecture claire pour savoir si votre “sauvegarde chiffrée” vous permettra vraiment de restaurer des données propres, même quand tout part en vrille.
Sur Glooton.com, ce thème mérite d’être traité sans langage marketing, parce que le piège est précisément là : le chiffrement donne une sensation de sécurité “absolue”, alors que la vraie protection vient d’une stratégie (versions, isolation, séparation des accès) — pas d’une case cochée.
1) Le chiffrement protège la confidentialité… pas l’intégrité
Le chiffrement, dans sa fonction la plus simple, répond à une question : si quelqu’un obtient le support, peut-il lire mes données ? Si la clé n’est pas accessible, la réponse est non. Très bien.
Mais une sauvegarde échoue rarement parce qu’un voleur a “lu” un disque. Elle échoue surtout parce que :
- les fichiers ont été chiffrés par un ransomware puis sauvegardés comme si de rien n’était ;
- le compte cloud a été compromis et l’attaquant a supprimé/modifié les backups ;
- une synchronisation a répliqué une erreur humaine (suppression, écrasement, corruption) ;
- l’historique n’existe pas, ou trop peu longtemps ;
- la restauration n’a jamais été testée (et le jour J, ça ne marche pas).
Conclusion : le chiffrement, seul, est une réponse à un sous-problème (lecture non autorisée). Or la plupart des désastres sont des problèmes d’intégrité et de restauration.
2) Le malentendu n°1 : “cloud” et “sauvegarde” ne veulent pas dire la même chose
Beaucoup de services cloud sont des services de synchronisation, pas de sauvegarde au sens strict. La synchronisation est un miroir rapide : si vous supprimez ou modifiez, le cloud suit. C’est utile pour travailler. C’est dangereux comme seule “sauvegarde”.
Une sauvegarde, la vraie, doit pouvoir dire : “je peux revenir en arrière” — pas juste “j’ai la dernière version”. Sans historique, une “sauvegarde” devient un duplicateur de catastrophes.
3) Le malentendu n°2 : “chiffré” peut vouloir dire “chiffré côté serveur”
Quand un fournisseur annonce “chiffrement”, il parle souvent d’un chiffrement au repos (les disques du prestataire). C’est une protection pour l’infrastructure. Mais si votre compte est piraté, l’attaquant entre par la porte d’entrée légitime : il voit, télécharge, supprime, parce qu’il est “vous”. Dans ce scénario, le chiffrement ne change rien.
Le vrai saut de confidentialité, c’est le chiffrement où vous contrôlez réellement la clé (bout en bout, ou chiffrement côté client avant envoi). Mais même là : confidentialité ≠ restauration. Vous pouvez avoir un coffre-fort parfaitement chiffré… rempli de fichiers déjà détruits.
4) Mini-audit : 5 critères qui font une sauvegarde réellement protectrice
1) Versions / points de restauration (le cœur)
Vous devez pouvoir restaurer :
- un fichier précis, à une date précise ;
- un dossier complet avant une erreur ;
- un état “sain” avant une corruption ou un chiffrement.
Sans versions, vous n’avez pas une sauvegarde : vous avez une copie.
2) Isolation / immutabilité (anti-ransomware)
Le ransomware gagne quand la sauvegarde est accessible en écriture depuis la machine compromise. Les bons patterns :
- copie déconnectée (disque branché seulement le temps de la sauvegarde) ;
- stockage immuable / “verrouillé” (WORM ou équivalent) ;
- mécanisme empêchant suppression/altération avant un délai défini.
Règle froide : le chiffrement protège la confidentialité ; l’isolation protège l’intégrité.
3) Séparation des accès (compartimenter)
Si votre session quotidienne peut modifier/supprimer les sauvegardes, un malware le peut aussi. Vous voulez :
- un compte dédié aux sauvegardes ;
- des droits minimaux (écriture uniquement là où nécessaire, lecture/restauration séparée si possible) ;
- 2FA activé, mots de passe uniques, gestionnaire de mots de passe.
4) Gestion des clés (confidentialité réelle, sans auto-sabotage)
Si vous contrôlez la clé (chiffrement côté client / bout en bout), c’est mieux pour la confidentialité. Mais :
- une clé perdue = sauvegarde perdue ;
- une clé stockée “à côté” (sur la même machine, dans les notes, dans un navigateur compromis) = confidentialité perdue.
La bonne pratique : documenter la récupération (où est la clé, qui y a accès, comment la restaurer) et éviter la dépendance à un seul point fragile.
5) Test de restauration (le seul test qui compte)
Une sauvegarde non testée est une croyance. Faites un test périodique :
- restaurer un fichier au hasard ;
- restaurer un dossier ;
- vérifier lisibilité + intégrité (pas juste “ça se copie”).
Le jour où ça brûle, il est trop tard pour découvrir que la restauration échoue.
5) La check-list “sans blabla”
- J’ai des versions (au moins 2–4 semaines selon mon risque) : oui/non
- J’ai au moins une copie isolée/immuable : oui/non
- Mes accès sont séparés (compte dédié + 2FA) : oui/non
- Je sais qui contrôle la clé (prestataire vs moi) : oui/non
- J’ai déjà restauré pour tester : oui/non
Si vous avez 2 ou 3 “non”, vous n’êtes pas “mauvais” : vous avez juste identifié pourquoi le mot “chiffré” ne suffit pas. Et ça, c’est déjà un gain énorme.
Conclusion
Le chiffrement est indispensable, mais il ne protège pas contre la plupart des scénarios de perte de données. La vraie protection, c’est : historique + isolation + séparation des accès + restauration testée. Si votre stratégie répond à ces quatre points, alors le chiffrement devient ce qu’il doit être : une couche solide, pas un placebo rassurant.
