Chiffrer ses données avant de les envoyer dans le cloud : tour d’horizon des solutions
Pour protéger vos données, ne mettez pas tous vos œufs (vos clés) dans le même panier
Il faut prendre soin de ses données, en tant que lecteurs de Next vous en êtes convaincus depuis longtemps. Que ce soit pour faire des sauvegardes dans le cloud, c’est-à-dire sur l’ordinateur de quelqu’un d’autre, ou pour les protéger des regards indiscrets, on doit souvent faire confiance à un tiers pour le chiffrement. Next vous aide à trouver un successeur à feu Boxcryptor.
Depuis le 24 décembre, Next propose à ses abonnés Premium du stockage S3 : 1 To par défaut, avec 100 Go de plus par ancienneté du compte. Nous avons publié dans la foulée un tuto pour vous expliquer comment en profiter. Disponible sous forme de bêta, l’offre s’est ouverte à tous début février.
Il est maintenant temps de passer au second gros morceau de notre dossier : comment chiffrer vos données avant de les envoyer dans le cloud.
Deux méthodes de protection
Pour cela, nous avons grosso modo deux méthodes : la gestion des droits d’accès et le chiffrement. Pour la gestion des droits, c’est-à-dire la mise en place d’un mécanisme empêchant les consultations non souhaitées, il faut s’en remettre entièrement à un fournisseur : il doit mettre en place les outils nécessaires, mais il est impossible de les vérifier nous-mêmes, sauf par un audit hors de portée des utilisateurs lambda.
Le chiffrement, en revanche, offre lui la possibilité d’être maîtrisé (sous certaines conditions) par l’utilisateur, notamment quand il reste le seul maître des clés de chiffrement. Encore faut-il choisir le bon outil, si tant est qu’il existe, et les bonnes options.
Il est impossible de lister tous les produits du marché, on va en regarder quelques-uns pour vous montrer leurs principales caractéristiques, afin que vous compreniez bien leurs usages et que vous trouviez ce qui vous convient le mieux. Mais on vous le réexpliquera très prochainement dans un dossier, il vaut vraiment mieux rester maître de ses clés, donc l’exigence pour notre recherche d’outil se résumera ainsi :
Chiffrer un dossier (pouvant être local ou distant), tout en restant bien sûr maître de la clé de chiffrement, et en y accédant localement de façon transparente.
La référence disparue : Boxcryptor
Cet outil non open source et payant cochait néanmoins de très nombreuses cases : chiffrement de bout en bout (E2EE comme on dit dans les milieux autorisés) fichier par fichier, maîtrise des clés de chiffrement grâce au zero knowledge (les informations principales pour le processus de chiffrement étant déduites d’un secret qui n’est stocké nulle part et n’est utilisé que localement), gestion multi-utilisateurs et intégration possible dans des Active Directories ou LDAP pour une utilisation professionnelle.
Le chiffrement E2EE fichier par fichier avec maîtrise des secrets convenait parfaitement à ceux qui veulent protéger leurs fichiers où qu’ils soient, localement ou dans le cloud, la contrepartie étant que dans un cas d’usage avec Office (Microsoft 365), les fichiers devraient forcément être déchiffrés localement avant d’être utilisés : on perd l’usage des Word et Excel en ligne, mais en gagnant sur la sécurité, chacun mettant le curseur d’usage là où il le souhaite.
Disparu suite à son rachat par Dropbox, il n’a guère laissé que Cryptomator comme alternative pour les mêmes cas d’usage. Nous y reviendrons un peu plus tard.
Quelques exemples pour voir de quoi on parle
Nous allons regarder quelques outils, et voir à quels cas d’usage ils correspondent vraiment. On en profitera pour faire un petit test de qualité, en les comparant chaque fois avec notre référence disparue (promis, on ne versera aucune larme même si l’émotion nous gagne).
Vous trouverez en fin d’article un tableau récapitulatif des fonctionnalités, forces et faiblesses, ainsi que des tarifs.
TrueCrypt et ses forks tels que VeraCrypt
Commentaires (66)
Modifié le 10/02/2026 à 18h36
Certains avaient suggéré Kopia et Plakar, un test est également envisagé ?
Le 10/02/2026 à 19h04
Moi j'ai une solution simple et rustique pour mes sauvegardes en ligne. J'ai un petit script shell qui :
dargpgswiften ligne de commande.Et c'est tout.
Revers de la médaille : il faut que je l'adapte pour faire du S3 pour passer chez
AWSNXI.Le 10/02/2026 à 21h46
Le 10/02/2026 à 22h32
Le 11/02/2026 à 00h27
Le 10/02/2026 à 22h31
Surtout que ce dernier est vraiment très simple d'usage.
Le 10/02/2026 à 22h37
Le 10/02/2026 à 22h43
Mais il reste simple et open source, dur de le mettre dans la case machine a gaz d'un éditeur.
Le 11/02/2026 à 09h09
Ainsi : exit les grosses dépendances (sauf quelques packages de base genre rclone et fuse-t) !!
Le 11/02/2026 à 14h11
Ça tourne un peu partout et depuis que je l'utilise, j'en suis enchanté.
Le 11/02/2026 à 15h33
Modifié le 10/02/2026 à 19h18
Et CyberDuck (https://cyberduck.io/cryptomator/) avec un intégration un peu différente. Il y a un tableau comparatif sur la page de l'éditeur.
Le 10/02/2026 à 19h18
Il ya aussi Rclone qui propose du chiffrement.
Le 10/02/2026 à 19h27
Le 10/02/2026 à 19h59
Le 10/02/2026 à 21h41
J'ai éliminé mes tests avec plakar : dépendance via un compte en ligne pour tout se qui est gestion S3 ou rclone.
J'ai pas besoin d'avoir mes backups connectés à je ne sais quoi.
Du coup, je teste zerobyte, une GUI qui utilise Restic en backend avec du montage externe
Par exemple, j'ai mon serveur "backup" ou ça tourne cron, lieu backup and co,etc.
Et les serveurs que je veux backup, j'expose leurs données via webdav depuis rclone server.
Mon serveur de mail se fait backup dans un dossier, le dit dossier est exposé localement à zerobyte via webdav et de là, ça push sur le S3 de Next via cron + motif...
Le 11/02/2026 à 00h19
Le 10/02/2026 à 21h45
Le 11/02/2026 à 05h35
Que pensez-vous de se plan de sauvegarde.
Quel logiciel conseiller vous pour cette architecture de sauvegarde?
Le 11/02/2026 à 09h51
Si c'est incrémental quotidien, quel intérêt d'une complète par semaine en plus ?
Le 11/02/2026 à 10h49
Modifié le 11/02/2026 à 10h57
Modifié le 11/02/2026 à 11h35
[edit] Et histoire de compliquer encore plus les choses : il faut également faire la distinction entre incrémentale et différentielle :
La différence, c'est qu'en cas de restauration :
Le 11/02/2026 à 11h35
Je garde juste ce qui n'a pas été modifié par rapport à la sauvegarde précédente au même endroit…
Le 11/02/2026 à 11h42
Si tu décrivais ton processus, ce serait plus simple ;)
Le 11/02/2026 à 11h17
Si tu as ton disque qui est mort et que tu veux restaurer sur un nouveau disque, il faudra bien que tu partes de la dernière sauvegarde complète puis que tu appliques les différentes sauvegardes incrémentales y compris les suppressions. Et plus la sauvegarde complète est lointaine, plus c'est long.
Par contre, si tu veux juste récupérer un fichier effacé par erreur dans sa dernière version, tu peux parcourir les sauvegardes incrémentales en partant de la plus récente et en remontant jusqu'à la dernière complète si besoin.
Le 11/02/2026 à 11h37
Seules celles qui sont modifiées ou créées sont transférées, les autres (sauf celles qui sont supprimées) sont en lien dur avec celles de la sauvegarde précédente.
Modifié le 11/02/2026 à 11h50
Sinon, le terme recommandé pour dossier est répertoire.
Le 11/02/2026 à 12h24
Le 11/02/2026 à 11h00
1) moins de risque à la restauration : il y a peu de risque d'avoir un fichier de backup corrompu sur 7 (pour 7j) que si tu as 3 ans (plus de 1000 fichiers) à restaurer d'un coup
2) beaucoup plus facile de mettre en place un roulement des backups (comment fais-tu, si tu n'as que des incrémentales, pour bazarder tout ce qui a plus de 1 mois par exemple ? Il faut tout "recalculer" à chaque fois (avec le risque d'erreur que cela implique)
3) cela limite les erreurs dans le cas où la sauvegarde incrémentale aurait zappé un fichier (par ex. à cause d'une date de modification invalide)
4) c'est également plus facile pour tester régulièrement ses backups, tout en diminuant le temps de restauration.
C'est comme pour les bases de données : un backup complet est long (et autosuffisant). Un backup différentiel est rapide (mais il faut un backup complet avant).
Sinon, après, il faut partir sur des solutions plus poussées de backup, comme Borg, qui font de la déduplication côté serveur par exemple, mais toujours un backup complet du point de vue client (ce qui peut prendre énormément de temps côté client, car il faut alors passer en revue l'intégralité des fichiers sauvegardés et de leurs métadonnées à chaque sauvegarde, ce qui peut prendre du temps dès qu'on commence à avoir quelques dizaines de Go).
Le 11/02/2026 à 11h42
rsync -aLe 11/02/2026 à 12h18
J'ai l'impression que tu confonds tout : transfert, backup, synchronisation... pas évident d'avoir une discussion avec tant d'amalgame...
Le 11/02/2026 à 12h28
Le 11/02/2026 à 12h44
Une stratégie de backup, ce n'est pas juste avoir une copie de ses données (ce que fait rsync) mais avoir aussi la possibilité de revenir en arrière dans un temps compatible avec la stratégie de backup (ce que ne fait pas rsync).
rsync ne fait pas autant que ce que tu crois. Il faut utiliser d'autres outils comme rdiff-backup pour avoir de l'historisation.
Le 11/02/2026 à 13h43
Je peux très facilement récupérer mes sauvegardes faites avec rsync, partiellement ou totalement depuis n'importe quel point de sauvegarde.
Le 11/02/2026 à 13h49
Le 11/02/2026 à 13h54
Le 11/02/2026 à 14h08
Le 11/02/2026 à 17h20
Mes sauvegardes incrémentales journalières avec rsync me permettent de récupérer n'importe quel fichier/dossier ou l'ensemble de fichiers de n'importe quel point de sauvegarde, et tu dis que ce ne sont pas des sauvegardes ?
Le 12/02/2026 à 08h11
Ce que tu ne sembles pas comprendre c'est comment fonctionne un backup complet d'un backup différentiel.
Un.backup complet, tu prends chaque fichiers sources un à un et tu l'envoies. Un système intelligent va pouvoir vérifier si le fichier a déjà été sauvegarder précédemment ou pas pour limiter les transferts mais cela ne concerne QUE le transfert et reste un backup complet.
Avec un backup différentiel, pour simplifier tu regardes les méta-données des fichiers, tu prends uniquement ceux créés/modifiés depuis la dernière sauvegarde, et tu transferts ces fichiers.
Un backup complet est lent car si tu as 300Go à sauvegarder tu as 300Go à lire.
Un backup différentiel sera beaucoup plus rapide en général car beaucoup moins de fichiers à lire. Mais il pourra passer à côté de fichiers si les méta-données sont incorrectes (par exemple, en entrayant les fichiers en conservant les dates présentes dans une archive)
Tu peux faire tout ce que tu veux au niveau de ta sauvegarde, faire de la déduplication et/ou ne stocker que les fichiers modifiés, ta sauvegarde telle que tu l'as implémentée reste une sauvegarde complète.
Et en ne faisant que des sauvegardes complètes, la gestion de la rotation des sauvegardes et de la restauration s'en trouve simplifié, mais c'est au prix d'un temps de backup qui est, grosse modo, proportionnelle à la taille de tes données à sauvegarder (hors temps de transfert). Et tu ne gères pas de la même manière 10Go à sauvegarder que 2To.
Le 12/02/2026 à 15h58
Toutes les docs que je trouve sur la méthode indiquent bien "sauvegarde incrémentale/incrémentielle" :
Sauvegardes incrémentielles
incremental backups with rsync -link-dest
How to Create Incremental Backups Using rsync on Linux
rsync script for incremental backup which continues unfinished jobs
How to create incremental backups using rsync on Linux
Mais bon, si c'est moi qui ai tort…
Mon backup de mes 280 Go de données prend un peu plus de 2 minutes, dont plus de la moitié sont dues au transfert des données modifiées. Et le temps d’exécution prend aussi en compte le temps du reste de mon script (gestion des logs et création/suppressions de dossiers). C'est 1,231 secondes pour avoir la liste des données à envoyer :
Le 12/02/2026 à 19h15
La définition de backup complet/différentiel/incrémentiel n'a pas été définie par moi, et on la retrouve partout. On la retrouve tellement partout qu'elle en est même dans les liens que tu as donné ! Cf. le 3e
Tu peux dire ce que tu veux, mais le fait que rsync fasse les choses de manière intelligente (il faut le reconnaitre), cela n'en change pas pour autant la nature des backups : de base, il fait des synchronisation complète, et il est possible de faire des synchronisation incrémentale avec la bonne option, mais avec des contraintes (cf. fin du commentaire) et qui apparaitront comme des backups complets (car il va combiner le précédent backup avec le backup incrémental).
280Go en 2 min 20s, soit environ 2 Go/s. Ca va dépendre de ce que tu as comme disque. C'est possible avec des SSD nvme par exemple (et dans ce cas, TOUTES tes données sont lues, et c'est bien un backup COMPLET), soit c'est un SSD "classique" ou un disque dur à plateau, et là, clairement, c'est de l'incrémental car utilise les métadonnées des fichiers pour détecter les modifications (et donc, n'est pas fiable à 100%).
Mais c'est difficile à savoir, car tu ne donnes toujours pas la commande que tu utilises. J'espère juste pour toi que tu utilises l'option --checksum de rsync. Sinon, ton backup n'est pas fiable.
Qui plus est, tu parles de ton script. Donc je parie que c'est ton script qui gère le backup, pas rsync qui n'est qu'un outil utilisé pour mettre en place un backup. Relis mes commentaires, tu verras que j'ai bien précisé que Rsync pouvait être utilisé pour mettre en place des stratégies de backup, mais qu'il n'est pas en lui-même un logiciel de backup, mais uniquement de synchronisation.
Qui plus est, je trouve dommage qu'il faille attendre tant de commentaire de ta part pour qu'on sache un peu comment tu utilises rsync. C'est si efficace que :
Modifié le 12/02/2026 à 23h41
Et mon 3e lien dit bien : « rsync excels at incremental backups »
La quantité et la vitesse de données envoyées sont indiquées. J'ai envoyé seulement "7,51M byte" de données (créées ou modifiées depuis la dernière sauvegarde) à "95,65K bytes/sec".
Le reste n'a pas été modifié et n'a donc pas été envoyé…
J'ai fait une « sauvegarde complète qui prend du temps » (d'après toi) ou bien une sauvegarde incrémentale (sachant que toutes mes données, les 280 Go, sont dans mon dernier répertoire de sauvegarde), selon toi ?
rsync -a --link-dest="/backup/$(date -d "yesterday" +%Y-%m-%d)/" "/home/user/data/" "/backup/$(date +%Y-%m-%d)/"
C'est ça mon "script", pour une sauvegarde en local (mon vrai script est plus complexe, car j'ai rajouté d'autres choses).
Je fais mes sauvegardes via SSH sur un serveur distant, et j'ai des fichiers de plusieurs Go.
Aucun souci depuis environ 10 ans de sauvegardes journalières, mes fichiers de sauvegarde sont sains (je vérifie parfois, et rsync vérifie toujours le checksum des données qu'il transfère).
Le 13/02/2026 à 14h45
Mais je vais m'arrêter là, la discussion tourne en rond, et on s'est beaucoup éloigné de la question initiale. Le principe, c'est que tu sois content de ta solution à base de rsync et qu'elle te convienne, même si elle présente des lacunes et que je ne la conseillerais pas à un utilisateur non averti..
Modifié le 13/02/2026 à 18h10
Sauvegarde complète : Une copie complète de tous les fichiers de données qu'une organisation souhaite protéger, peu importe si des modifications ont été apportées aux données.
Une sauvegarde complète consiste à copier la totalité des données d’un disque
si des sauvegardes complètes sont effectuées quotidiennement, une copie du même ensemble de données sera répliquée et sauvegardée, que des modifications aient été apportées ou non à cet ensemble de données depuis la dernière sauvegarde
la sauvegarde complète. Elle consiste à copier l’intégralité des fichiers et des données sélectionnées vers un emplacement sécurisé
Je ne vois pas lesquelles.
Autant je trouve d'habitude tes interventions pertinentes et intéressantes, autant là je suis très déçu que tu restes bloqué sur tes idées préconçues (ça arrive) et n'admette pas que tu as tort…
Le 13/02/2026 à 20h34
Une dernière fois : un backup complet, c'est quand toutes les données de A se retrouvent à un emplacement B. Qu'importe si tu ne transferts que les données utiles, tant que les données de B sont complètes et autosuffisantes.
Ton rsync ne fait pas un backup complet. Non pas parce qu'il ne transfert que les fichiers modifiés, mais parce qu'il se base sur une heuristique pour déterminer si un fichier a été modifié ou non. En cela, il ne fait pas un backup complet.
Ma manière de travailler fait d'ailleurs que ton système sera incomplet pour moi. Il m'arrive fréquemment de travailler avec des archives dont les fichiers où les dates de modifications sont toutes à la même date (1 janviers 1970, pour des raisons de reproductibilité de build). Et ça, ça fausse complètement l'heuristique utilisée par rsync.
Il est donc TRES important de connaitre les outils que l'on utilise, et c'est d'ailleurs bien pour ça que je t'ai conseillé l'option --checksum, pour se baser sur le contenu des fichiers plutôt que leur taille et date de modification (mais attends-toi à avoir un processus de sauvegarde beaucoup plus long et une forte activité disque).
Considères ma position comme une méconnaissance de l'outil et basé sur des préjugés si cela te chante, c'est tout à fait ton droit et cela m'est égal. Je ne dis pas ça pour te convaincre, mais pour donner des éléments qui me semblent pertinent à celles et ceux qui nous lisent.
Modifié le 14/02/2026 à 09h50
Vu le nombre de liens que je donne qui montrent que tu as tort et que tu n'en donnes aucun pour justifier ton point de vue, il faudrait se remettre en cause à un moment…
Et c'est ce que je dis depuis le début, enfin, merci !
Le 14/02/2026 à 20h02
Autant de mauvaise foi, c'est dingue... Tu dis que rsync fait de l'incrémental car il ne transfert que les données modifiées, mais que tu as quand même des backups complet. Je te dis que rsync fait de l'incrémental car il utilise une heuristique (qui n'est pas fiable à 100%) pour déterminer les fichiers à sauvegarder, et que du fait du risque d'erreur, tu n'as pas un backup complet.
Mais comme je n'arrête pas de le dire, tu confonds depuis le début le processus de transfert des données du processus qui visent à déterminer les données qui doivent être sauvegarder... Et c'est justement à cause de cet amalgame que tu es persuadé que les liens que tu donnes me donne tort...
Nous sommes donc deux
Le 14/02/2026 à 20h09
Si tu en as d'autres, donne-les avec des liens pour appuyer tes dires, stp !
Le 11/02/2026 à 14h51
S tu veux faire du versionning, il faut jouer avec les dates et les snapshot dans rsync
Le 11/02/2026 à 17h22
Le 11/02/2026 à 17h38
"Non, toutes mes données sont dans le même dossier à chaque sauvegarde incrémentale."
Modifié le 11/02/2026 à 18h45
Mais seules les données modifiées ou créées depuis la dernière sauvegarde sont transférées (dans le nouveau dossier de la sauvegarde en cours).
Edit :
Un exemple pour plus de clarté :
- Hier, sauvegarde dans le dossier "2026-02-10/" des fichiers "a.txt", "b.txt" et "c.txt".
- Aujourd'hui, sauvegarde dans le dossier "2026-02-11/" des fichiers "b.txt" (modifié) et "d.txt" (nouveau).
Le dossier "2026-02-11/" va alors contenir "a.txt", "b.txt" (le nouveau) et "d.txt", mais pas "c.txt" parce que je l'avais effacé. Donc toutes mes données d'aujourd'hui dans le même dossier.
J'espère que c'est plus clair.
Le 11/02/2026 à 11h08
Ca me permet d'avoir un NAS avec un CPU avec peu de puissance de calcul.
Mes données sont chiffrées côté client.
J'ai un historique, la deduplication et un temps de sauvegarde contenu.
Pour la politique de rétention, elle dépend des données et des besoins.
Le 11/02/2026 à 07h38
Perso je met le container sur mon kDrive et le reupload régulièrement, mais c'est juste pour l'avoir "ailleurs".
Pour chiffrer des données sur un compatible S3 ou un Claude, j'aurais plus tendance à utiliser rclone qui permet de monter le filesystem distant et chiffre à la volée, ce que je faisais à un moment avec des object storage OVH. Par contre, je doute que ça marche sur smartphone.
Dans tous les cas, la conclusion est bien l'info principale à avoir en tête : l'utilisateur doit être maître de la clé de chiffrement. Le CSP ne doit pas la posséder.
Le 11/02/2026 à 12h34
Le 11/02/2026 à 12h58
Ça n’enlève rien à la qualité de l’article, qui est un super comparatif détaillé (même si un peu trop centré sur windows à mon goût). Mais c’est moi qui suis passé à côté d’un truc ?
Le 11/02/2026 à 13h22
Il n'y a pas que des solutions locales mais aussi pour le Cloud, mais comme tu le dis pour des documents de travail.
Le fait que tout soit "à plat" en terme de titre de paragraphe alors qu'il y a des sous paragraphes pour chacun des sujets n'aide pas à comprendre l'articulation de ce long article et donc sa logique de progression.
Pour finir, moi aussi, Windows et des "lecteurs" (B:, Z:) d'un autre siècle, ça ne m'intéresse pas.
Le 11/02/2026 à 16h09
Pour vous consoler : il y aura une suite, à base de rclone, et des scripts qui tourneront sur Windows 11, Linux et MacOS !!
Le 11/02/2026 à 16h23
Je me doutais bien que tu ne pouvais pas mieux faire avec l'outil, mais ça n'aide vraiment pas.
J'ai aussi pensé aux lecteurs de disquettes sur B:
Le 11/02/2026 à 16h38
Le 12/02/2026 à 15h36
Le 11/02/2026 à 13h23
Je n'avais pas envisagé les cas d'usages proposés dans cet article. Ca m'a permis de re-découvrir certains solutions et d'en découvrir d'autres.
Le 11/02/2026 à 14h07
Le 12/02/2026 à 16h47
Le 13/02/2026 à 09h33
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?