Comment sauvegarder ses notes chiffrées sans casser le zero-knowledge

Tu as fini par ranger toute ta vie numérique au même endroit : tes notes de réunion, tes idées de projet, les PDF importants, le graph qui relie le tout. Et là, une question désagréable surgit. Que se passe-t-il si ton disque lâche demain matin ? Si ton laptop est volé dans le train ? Si tu effaces un dossier par erreur un vendredi soir de fatigue ? Une sauvegarde, tu en as besoin, c'est évident. Le vrai problème est ailleurs : la plupart des méthodes de backup te font payer ta sécurité pour récupérer ta tranquillité. Tu chiffres tes notes localement, puis tu les balances en clair sur un Google Drive ou une clé USB, et tout le bénéfice s'évapore.

Ce guide règle exactement ça. On va voir comment garder une vraie copie de secours de tes notes et de tes fichiers, sans jamais donner à un serveur, à un cloud grand public ou à un voleur la possibilité de les lire. Autrement dit : sauvegarder sans casser le zero-knowledge. Les exemples utilisent Filarr, parce que ses trois mécanismes de sauvegarde couvrent bien les cas de figure, mais les principes valent pour n'importe quel outil de notes chiffré.

Quick Answer. Pour sauvegarder des notes chiffrées sans casser le zero-knowledge, garde tes données chiffrées de bout en bout à chaque étape. Trois options avec Filarr : (1) l'export de coffre en mode chiffré, qui produit un ZIP protégé en AES-256-GCM avec un mot de passe que toi seul connais ; (2) la sync cloud zero-knowledge, où seuls des blobs chiffrés opaques quittent ta machine vers Cloudflare R2 ou ton propre bucket S3 ; (3) la copie brute du dossier de coffre local, dont les fichiers sont déjà chiffrés par fichier sur le disque. La règle unique : ne jamais laisser tes notes toucher un support tiers en clair, et garder ta phrase de récupération de 24 mots hors ligne.

Le piège des sauvegardes "classiques"

Définissons d'abord ce qu'on essaie de protéger. Une sauvegarde utile doit survivre à trois scénarios : la panne matérielle (ton disque meurt), l'erreur humaine (tu supprimes ou écrases quelque chose), et le sinistre (vol, incendie, ordinateur noyé). La règle 3-2-1 résume le tout : trois copies de tes données, sur deux supports différents, dont une hors site.

Là où ça se gâte, c'est le mot "hors site". Copie hors site rime presque toujours avec cloud, et cloud grand public rime avec données lisibles par le prestataire. Quand tu déposes un fichier sur Google Drive, Dropbox ou iCloud, il est chiffré au repos sur leurs serveurs, oui, mais eux détiennent les clés. Ils peuvent techniquement lire ton contenu, le scanner, le remettre à une autorité qui le demande, ou le laisser fuiter le jour où ils se font pirater. Si tu utilises Filarr précisément pour éviter ça, envoyer ton backup en clair chez eux revient à fermer la porte d'entrée à double tour et à laisser la fenêtre grande ouverte.

La question n'est donc pas "est-ce chiffré ?" mais "qui tient la clé ?". C'est toute la différence entre un chiffrement de façade et un vrai modèle zero-knowledge, où le service qui héberge tes octets ne peut structurellement pas les déchiffrer. Si tu veux creuser cette distinction, j'ai détaillé ce que veut dire exactement le chiffrement zero-knowledge et en quoi il diffère du end-to-end. Pour un backup, retiens juste ceci : à chaque copie que tu fais, tes données doivent rester chiffrées avec une clé que toi seul possèdes.

Méthode 1 : l'export de coffre chiffré (le backup portable)

C'est la méthode que je recommande en premier, parce qu'elle est simple, autonome et sans dépendance à un serveur. Filarr propose un export de coffre complet sous forme de fichier ZIP, avec deux modes : "plain" (ZIP standard, lisible partout) et "encrypted" (le ZIP est construit puis chiffré en AES-256-GCM avec un mot de passe que tu choisis).

Pour un backup qui respecte le zero-knowledge, tu choisis toujours le mode chiffré. Le mode plain a son utilité, on y revient plus bas, mais il produit un ZIP dont les fichiers et les notes sont en clair. Pratique pour migrer vers un autre outil, catastrophique pour dormir sur un cloud tiers.

Ce que contient l'export

Un export Filarr n'est pas juste un tas de fichiers. Le ZIP embarque, d'après le code du service d'export :

• Tes fichiers, déchiffrés puis re-rangés dans leur arborescence de dossiers d'origine, sous files/.
• Tes notes en deux formats : une version Markdown lisible par un humain (avec un frontmatter YAML : titre, dates de création et de modification, tags) sous _notes/, et une version JSON complète et fidèle sous _data/notes.json, qui conserve le contenu TipTap intégral, les liens entre notes, fichiers et dossiers, les icônes, les couleurs, l'état épinglé, tout ce qu'il faut pour une vraie restauration.
• Tes données annexes : modèles, jeux de flashcards, automatisations, profils, réglages, chacun dans son propre fichier JSON sous _data/.
• Un _manifest.json qui décrit l'ensemble : version de l'app, date d'export, nom du profil, statistiques (nombre de fichiers, dossiers, notes, tags, liens du graph, taille totale), la liste complète des dossiers avec leurs chemins, les tags, et surtout les graph_links, c'est-à-dire toutes les connexions de ton graph. Ton réseau de notes reliées n'est pas perdu à la restauration.

En mode chiffré, ce manifest note aussi explicitement encryption_algorithm: AES-256-GCM. Le nom de fichier par défaut devient filarr-export-encrypted-AAAA-MM-JJ.zip, ce qui te permet de repérer d'un coup d'oeil, dans ton dossier de backups, lesquels sont protégés et lesquels ne le sont pas.

Le geste concret, étape par étape

La manipulation est courte, mais chaque étape compte. D'abord, ouvre les réglages de ton coffre et lance l'export de vault. Ensuite, sélectionne le mode chiffré. À ce moment, l'app te demande un mot de passe d'export : c'est lui, et lui seul, qui protégera l'archive. Ce n'est pas forcément le même que ton mot de passe de coffre, et je conseille d'ailleurs qu'il soit distinct et costaud, parce que ce ZIP va potentiellement voyager sur des supports que tu ne contrôles pas.

Une fois le mot de passe saisi, l'app collecte tes fichiers et tes notes, empaquette tout dans le ZIP, puis chiffre l'archive entière avant de te proposer où l'enregistrer via la boîte de dialogue système. Tu obtiens un unique fichier .zip chiffré. À partir de là, ce fichier est opaque : sans le mot de passe, personne ne peut en tirer quoi que ce soit, ni le contenu de tes notes, ni même la liste de leurs titres.

C'est ce qui rend cette méthode si adaptée à la règle 3-2-1. Ce ZIP chiffré, tu peux le déposer sans crainte sur un Google Drive, l'envoyer sur un NAS familial, le graver, le mettre sur deux clés USB rangées à des endroits différents. Le support devient indifférent, puisque la protection voyage avec le fichier. C'est exactement le principe du chiffrement local que je détaille dans mon comparatif chiffrement local contre cloud classique face à une fuite : le jour d'un incident, tout dépend de qui tient la clé, et là, c'est toi.

Le point de vigilance : le mot de passe d'export

Un ZIP chiffré en AES-256-GCM est aussi solide que le mot de passe qui le protège. C'est le maillon humain. Si tu choisis filarr2026, tu as un coffre-fort blindé avec un post-it collé dessus. Prends une phrase de passe longue, unique, et stocke-la dans ton gestionnaire de mots de passe. Et surtout : si tu perds ce mot de passe, l'archive est irrécupérable. C'est le prix du zero-knowledge, il n'y a pas de bouton "mot de passe oublié" qui te renverrait le contenu, sinon ce ne serait pas du zero-knowledge. Pour bien poser ces bases, mon guide sur comment chiffrer ses notes correctement revient sur le choix d'un bon mot de passe et la gestion de la récupération.

Méthode 2 : la sync cloud zero-knowledge (le backup automatique et hors site)

L'export manuel est excellent, mais il a un défaut : il faut y penser. Un backup qu'on oublie de faire ne protège de rien. C'est là qu'intervient la sync cloud de Filarr, qui joue à la fois le rôle de synchronisation entre appareils et de sauvegarde hors site continue, sans effort de ta part.

La différence cruciale avec un Dropbox, c'est ce qui quitte réellement ta machine. D'après le code du client de sync et du worker Cloudflare, tout ce qui part vers le cloud est constitué de blobs chiffrés opaques, avec la mention explicite "zero knowledge" dans les commentaires du code. Même le manifest de sync n'expose que des UUID opaques : les identifiants de fichiers sont dérivés de façon à ne jamais révéler les vrais noms de tes fichiers. Le serveur ne voit ni le contenu, ni les titres, ni l'arborescence lisible. Il stocke des paquets d'octets qu'il est incapable d'ouvrir.

Le stockage par défaut est Cloudflare R2. Si tu veux garder le contrôle jusqu'au bout, Filarr supporte aussi le BYOS ("bring your own storage") : tu branches ton propre bucket compatible S3, et tes blobs chiffrés atterrissent chez l'hébergeur de ton choix, sans que ça change quoi que ce soit à la garantie zero-knowledge, puisque le chiffrement se fait sur ta machine avant l'envoi. J'ai décortiqué toute cette mécanique, FEK, blobs, manifest chiffré et transfert de clé, dans l'article sur la sync zero-knowledge de Filarr.

Pourquoi la sync compte comme une vraie sauvegarde ? Parce qu'elle coche les cases difficiles. Elle est hors site par nature. Elle est continue, donc pas d'oubli. Et comme elle réplique tes données chiffrées sur les serveurs, une panne de ton disque local ne t'efface pas : tu réinstalles Filarr, tu te reconnectes, tu resynchronises. La sync locale reste gratuite pour toujours, et la partie cloud démarre à 4 euros par mois.

Une nuance honnête, parce que ce guide n'est pas une brochure : une sync n'est pas un historique de versions illimité. Si tu supprimes une note et que la suppression se propage, tu ne veux pas dépendre uniquement de la sync pour la retrouver. C'est pour ça que sync et export ne s'opposent pas, ils se complètent, on y arrive dans la section stratégie.

Méthode 3 : copier le dossier de coffre local (le backup brut)

Il existe une troisième voie, plus artisanale mais parfaitement valide : copier directement le dossier où Filarr stocke ton coffre sur le disque. L'intérêt, c'est que ces fichiers sont déjà chiffrés au repos, fichier par fichier. Filarr chiffre chaque fichier avec sa propre clé (une FEK), elle-même protégée par une clé dérivée de ton mot de passe. Cette architecture à deux niveaux, je l'explique en détail dans KEK et FEK, pourquoi le chiffrement par fichier compte : concrètement, ça veut dire que même une copie brute du dossier reste illisible sans ton mot de passe.

Donc si tu fais un rsync de ton dossier de coffre vers un disque externe, ou que tu le laisses embarquer dans un backup système type Time Machine, tu ne casses pas le zero-knowledge : ce qui est copié est du chiffré. Contrairement à un export en mode plain, ici rien n'est déchiffré au passage.

La contrepartie, c'est que cette méthode est la plus fragile en pratique. Tu sauvegardes un état interne de l'application, pas une archive pensée pour être restaurée. Une copie faite pendant que l'app écrit peut attraper un fichier à moitié modifié. Et pour restaurer, tu remets le dossier en place, ce qui suppose que la structure interne n'a pas changé entre-temps. C'est un bon filet de sécurité complémentaire, surtout couplé à un backup système chiffré, mais je ne le prendrais pas comme unique stratégie. Pour une restauration propre et prévisible, l'export chiffré de la méthode 1 reste le format de référence.

Le maillon vital : ta phrase de récupération de 24 mots

Aucun backup de contenu ne te sauve si tu perds l'accès à tes clés. C'est le point que les gens négligent le plus. Filarr génère à l'installation une phrase de récupération de 24 mots au standard BIP-39. Techniquement, cette phrase sert à envelopper ta clé de fichier : elle est utilisée comme mot de passe pour une dérivation PBKDF2-SHA512 à 600 000 itérations (le seuil recommandé par l'OWASP en 2024), produisant une clé qui "emballe" ta FEK. En clair : si tu oublies ton mot de passe de coffre, cette phrase de 24 mots est le seul moyen de reprendre la main sur tes données.

Cette phrase mérite son propre plan de sauvegarde, distinct de tes fichiers. Écris-la sur papier, range-la dans un endroit sûr, éventuellement en deux exemplaires à deux endroits. Ne la mets pas dans une note à l'intérieur de Filarr (tu ne pourrais plus y accéder si tu es verrouillé dehors), ni dans un fichier texte en clair sur ton bureau. Le meilleur backup de coffre du monde ne vaut rien si la clé pour l'ouvrir a disparu avec le disque.

Pièges courants et bonnes pratiques

Le piège numéro un : exporter en mode plain "juste pour tester". Le mode plain produit un ZIP en clair. Il est fait pour migrer vers un autre outil ou consulter tes notes hors de l'app, pas pour dormir sur un cloud. Si tu en fais un, traite-le comme un document sensible : utilise-le, puis efface-le. Ne le laisse jamais traîner dans un dossier synchronisé automatiquement.

Le piège numéro deux : un seul backup au même endroit que l'original. Un ZIP chiffré posé sur le même disque que ton coffre ne te protège pas d'une panne de ce disque. Applique la règle 3-2-1 : l'original, plus au moins une copie sur un autre support, plus une hors site.

Le piège numéro trois : le mot de passe d'export faible ou perdu. Un AES-256-GCM ne compense pas un mot de passe devinable, et il n'y a aucune récupération si tu l'oublies. Gestionnaire de mots de passe, phrase de passe longue, point.

Le piège numéro quatre : oublier la fréquence. Un backup datant de six mois te fait perdre six mois de travail. Si tu comptes sur l'export manuel, mets-toi un rappel mensuel, ou mieux, active la sync pour la continuité et garde l'export chiffré comme instantané périodique.

Bonne pratique : teste ta restauration au moins une fois. Un backup jamais restauré est une hypothèse, pas une garantie. Fais l'exercice une fois : prends un export chiffré, restaure-le dans un profil de test, vérifie que tes notes, tes liens de graph et tes fichiers reviennent bien. Tu dormiras mieux.

Bonne pratique : combine les trois méthodes selon leur force. La sync pour le continu et le multi-appareils, l'export chiffré pour l'instantané restaurable et archivable, la copie de dossier comme filet système. Ce trio couvre les trois scénarios (panne, erreur, sinistre) sans jamais exposer une seule note en clair à un tiers.

Une stratégie simple qui tient la route

Si tu ne devais retenir qu'un plan, prends celui-ci. Active la sync cloud zero-knowledge (R2 ou ton propre bucket S3) pour avoir une copie hors site continue et le multi-appareils. Une fois par mois, fais un export de coffre en mode chiffré et range le ZIP à deux endroits distincts, dont un support déconnecté comme une clé USB au tiroir. Sauvegarde ta phrase de récupération de 24 mots sur papier, séparément de tout le reste. Et une fois, teste une restauration pour de vrai.

Ce plan respecte le zero-knowledge à chaque maillon : la sync n'envoie que des blobs opaques, l'export chiffré protège l'archive en AES-256-GCM avec ta clé, la phrase de récupération reste hors ligne. Si demain ton laptop tombe dans un lac, tu rachètes une machine, tu réinstalles, tu resynchronises ou tu restaures ton dernier ZIP, et ta vie numérique repart, sans qu'un serveur ait jamais pu lire une ligne de tes notes. Pour comprendre l'ensemble du modèle de sécurité qui rend tout ça possible, l'architecture défensive de Filarr est documentée couche par couche.

FAQ

Un backup chiffré en AES-256-GCM est-il vraiment sûr sur un cloud grand public ? Oui, à condition que le mot de passe soit fort. Le contenu du ZIP est chiffré avant de quitter ta machine, donc le fournisseur de cloud ne stocke qu'un fichier opaque. Il ne peut ni lire tes notes, ni voir leurs titres. La seule chose qui compte alors, c'est la robustesse de ton mot de passe d'export.

Quelle différence entre l'export chiffré et la sync cloud ? L'export chiffré est un instantané manuel, un fichier ZIP autonome que tu ranges où tu veux et qui sert de point de restauration à une date donnée. La sync est un flux continu et automatique vers un stockage cloud, idéal pour le multi-appareils et le hors site sans y penser. Les deux sont complémentaires : la sync pour la continuité, l'export pour l'archivage restaurable.

Que se passe-t-il si je perds mon mot de passe d'export ? L'archive est définitivement illisible. C'est la conséquence directe du zero-knowledge : personne, pas même Filarr, ne détient de copie de ta clé. Stocke ce mot de passe dans un gestionnaire de mots de passe et ne compte sur aucune récupération côté serveur.

La copie brute de mon dossier de coffre expose-t-elle mes notes ? Non. Les fichiers du coffre sont chiffrés au repos, chacun avec sa propre clé (FEK), elle-même protégée par une clé dérivée de ton mot de passe. Une copie brute reste illisible sans ce mot de passe. C'est un backup valide, mais moins fiable à restaurer qu'un export chiffré, car tu copies un état interne de l'app.

Ai-je besoin d'un compte ou de payer pour sauvegarder ? Non pour l'export chiffré et la copie de dossier : ils sont 100% locaux et gratuits, sans compte. La sync cloud, elle, est optionnelle et démarre à 4 euros par mois, avec la possibilité d'utiliser ton propre bucket S3 si tu préfères héberger toi-même tes blobs chiffrés.

Mon graph de notes et mes liens survivent-ils à une restauration ? Oui avec l'export. Le fichier _manifest.json de l'archive conserve tous les graph_links (liens note-note, note-fichier, note-dossier), et le _data/notes.json garde le contenu intégral et les relations. Ton réseau de connaissances se reconstitue à la restauration, pas seulement le texte brut.

Conclusion

Sauvegarder sans casser le zero-knowledge n'a rien de compliqué une fois qu'on a compris la règle unique : à chaque copie, tes données doivent rester chiffrées avec une clé que toi seul détiens. Concrètement, ça tient en un plan de dix minutes à mettre en place. Active la sync zero-knowledge pour le hors site continu, prends l'habitude d'un export de coffre chiffré mensuel rangé à deux endroits, et mets ta phrase de 24 mots à l'abri sur papier. Fais le test de restauration une fois, pour transformer ton hypothèse en certitude. À partir de là, tu as les trois filets, panne, erreur, sinistre, sans jamais avoir tendu une seule de tes notes en clair à un serveur qui n'aurait rien à en faire.