Chiffrement local vs cloud classique : ce qui change vraiment en cas de fuite de données

Une fuite de données n'est plus un événement rare. C'est une hypothèse de travail. La vraie question, pour un professionnel qui manipule des documents sensibles (dossiers clients, contrats, données de santé, comptabilité), n'est pas « est-ce que mon prestataire peut se faire pirater ? » mais « le jour où ça arrive, qu'est-ce qui fuit exactement ? ». Et la réponse dépend presque entièrement d'un choix technique que peu de gens regardent : où sont chiffrées vos données, et qui détient la clé.

Quick Answer

En cas de fuite chez votre hébergeur, la différence tient à qui possède la clé de déchiffrement. Avec un cloud classique (Notion, Google Drive, la plupart des SaaS), le fournisseur chiffre vos données « au repos » mais garde lui-même les clés : si ses serveurs sont compromis ou si un accès admin fuite, vos fichiers sont lisibles en clair. Avec un chiffrement local ou zero-knowledge, les données sont chiffrées sur votre appareil avant tout envoi, et le serveur ne stocke que des blobs illisibles : une fuite côté serveur n'expose alors que du bruit chiffré, inexploitable sans votre mot de passe. Le chiffrement « au repos » protège contre le vol de disques physiques, pas contre une compromission logique du service. C'est la distinction qui change tout le jour de l'incident.

Pourquoi cette question devrait vous inquiéter

Si vous êtes freelance, consultant, ou que vous dirigez une petite structure, vous êtes responsable des données que vos clients vous confient. Un cabinet comptable stocke des bilans et des RIB, un avocat des pièces couvertes par le secret professionnel, un thérapeute des notes de séance, un consultant des documents stratégiques sous NDA. Dans tous ces cas, la fuite ne vous coûte pas seulement des données : elle coûte la confiance, parfois un contrat, et potentiellement une exposition réglementaire.

Le piège, c'est que la plupart des outils grand public affichent « chiffrement AES-256 » sur leur page sécurité, ce qui rassure sans rien garantir sur le scénario qui compte vraiment. Chiffrer, oui, mais contre qui ? Un service qui chiffre vos données mais détient les clés vous protège du cambrioleur qui vole un disque dur dans un datacenter. Il ne vous protège pas d'un employé indélicat, d'un accès administrateur compromis, d'une faille applicative, ni d'une réquisition légale. Or ce sont précisément ces scénarios-là qui composent l'écrasante majorité des fuites réelles.

La vraie ligne de fracture : qui détient la clé

Il existe trois grands modèles, et ils ne se valent pas du tout face à une fuite.

Chiffrement côté serveur (au repos). C'est le modèle par défaut du cloud classique. Vos données arrivent sur le serveur, qui les chiffre avec des clés qu'il gère. Techniquement le disque est chiffré, mais le service peut déchiffrer à volonté puisque la clé est chez lui. C'est le cas de Notion, par exemple : il chiffre au repos et en transit, mais pas de bout en bout, comme on l'a détaillé dans notre analyse de ce que le chiffrement de Notion protège vraiment. Si le serveur fuit, la clé fuit avec, ou l'attaquant qui a l'accès a aussi la capacité de déchiffrer.

Chiffrement de bout en bout / zero-knowledge. Les données sont chiffrées sur votre appareil, avec une clé dérivée de votre mot de passe que le serveur ne voit jamais. Le service ne stocke que du contenu chiffré opaque. Même piraté, même réquisitionné, il ne peut techniquement rien lire. La nuance entre ces deux termes souvent confondus est réelle, et nous l'avons décortiquée dans notre comparatif end-to-end vs zero-knowledge : pour résumer, zero-knowledge décrit ce que le serveur ignore, end-to-end décrit le trajet des données. Ce qu'il faut retenir : dans les deux cas, la clé reste chez vous.

Chiffrement local-first. Les données vivent chiffrées sur votre disque, et le cloud n'est qu'une option de synchronisation. Vous pouvez travailler 100 % hors ligne. La surface d'attaque côté serveur se réduit à sa plus simple expression, puisque le serveur ne détient parfois même rien du tout.

Voici comment ces modèles se comportent concrètement le jour de l'incident.

Scénario de fuite	Cloud classique (clé chez le fournisseur)	Zero-knowledge / local-first (clé chez vous)
Vol de disque physique en datacenter	Protégé (chiffré au repos)	Protégé
Compromission d'un accès admin du service	Données lisibles en clair	Blobs chiffrés inexploitables
Faille applicative côté serveur	Exposition possible en clair	Rien d'exploitable sans votre mot de passe
Employé malveillant du fournisseur	Accès possible aux données	Aucun accès au contenu
Réquisition légale visant l'hébergeur	Données communicables	Le fournisseur n'a rien à communiquer de lisible
Perte / vol de votre propre appareil	Dépend de votre poste	Protégé si le coffre est verrouillé

Ce tableau montre l'essentiel : le chiffrement au repos ne coche qu'une seule case, celle qui arrive le moins souvent. Les modèles où vous gardez la clé couvrent la colonne entière, à une exception près, votre propre appareil, sur laquelle nous revenons plus bas.

Ce que « chiffrement AES-256 » veut vraiment dire (et ne dit pas)

AES-256 est un excellent algorithme, mais c'est juste le cadenas. La question qui compte est : qui a la clé du cadenas ? Une app peut utiliser exactement le même algorithme que votre banque et rester complètement transparente pour son éditeur, simplement parce que c'est lui qui gère les clés. Pour lire une page sécurité correctement, cherchez trois choses au-delà du nom de l'algorithme : est-ce que le chiffrement se fait sur mon appareil ou sur leur serveur ; est-ce que ma clé dérive de mon mot de passe et reste chez moi ; est-ce qu'il existe un mécanisme pour eux de récupérer mes données sans moi (si oui, ils peuvent aussi les lire).

La robustesse dépend aussi de détails d'implémentation : le mode de chiffrement (GCM authentifie les données et détecte toute altération, ce que nous expliquons dans ce qu'est l'AES-256-GCM), et la façon dont le mot de passe est transformé en clé. Une dérivation faible rend le meilleur algorithme vulnérable au bruteforce. Une dérivation sérieuse utilise un grand nombre d'itérations (l'OWASP recommandait 600 000 itérations PBKDF2-SHA512 en 2024) ou un algorithme à coût mémoire comme Argon2id.

Autre point souvent négligé : une clé unique pour tout votre coffre est un risque. Si elle fuit, tout fuit. Une architecture sérieuse dérive une clé par fichier, protégée par une clé maîtresse, ce que nous détaillons dans KEK et FEK, pourquoi le chiffrement par fichier compte. C'est le même principe de compartimentage qu'utilisent Signal ou BitLocker.

Là où le chiffrement local ne suffit pas (soyons honnêtes)

Aucun modèle n'est magique, et prétendre le contraire serait malhonnête.

Le chiffrement local déplace la responsabilité de la clé vers vous. Si vous perdez votre mot de passe et votre phrase de récupération, personne ne peut vous sauver, c'est le prix du zero-knowledge. Il faut donc une vraie discipline de sauvegarde de la phrase de récupération.

Ensuite, le chiffrement au repos protège les données stockées, pas votre poste de travail en cours d'utilisation. Si votre ordinateur est compromis par un malware pendant que votre coffre est déverrouillé, le contenu est lisible en mémoire. Le chiffrement local sécurise le stockage, pas un poste déjà infecté. L'hygiène du terminal (mises à jour, antivirus, verrouillage de session) reste indispensable.

Enfin, le cloud classique garde des avantages réels : collaboration temps réel fluide, récupération de compte simple, partage granulaire, zéro gestion de clé pour l'utilisateur. Pour des données non sensibles et un travail d'équipe intensif, ces bénéfices peuvent légitimement peser plus lourd que le modèle de menace. Le bon choix dépend de la sensibilité réelle de vos données, pas d'un dogme.

Ce que ça implique concrètement

Quelques pratiques actionnables, quel que soit l'outil que vous choisissez :

• Classez vos données par sensibilité. Tout ne mérite pas le même niveau. Les documents clients confidentiels, les pièces sous secret professionnel, les données de santé justifient un modèle où vous gardez la clé. Un brouillon de blog, non.
• Lisez la page sécurité au-delà du logo AES. Cherchez « end-to-end », « zero-knowledge », « client-side encryption ». Si vous trouvez « nous pouvons réinitialiser votre mot de passe et récupérer vos données », c'est qu'ils peuvent les lire.
• Sauvegardez votre phrase de récupération hors ligne. Sur papier, dans un coffre, pas dans le même outil. C'est le maillon qui remplace le service de récupération que vous perdez volontairement.
• Ne confondez pas chiffrement et conformité. Le chiffrement est une mesure technique de sécurité. La conformité RGPD dépend de l'ensemble de votre traitement (base légale, minimisation, information des personnes, sous-traitants). Un bon chiffrement y contribue, il ne la remplace pas.
• Vérifiez où sont hébergés les serveurs si vous utilisez la sync. Un hébergement dans l'UE simplifie certaines obligations, même si en zero-knowledge le fournisseur ne voit de toute façon que des blobs.

Où Filarr peut aider

Filarr adopte le modèle local-first chiffré de bout en bout. Concrètement, vos notes et vos fichiers vivent chiffrés sur votre disque en AES-256-GCM, avec une clé par fichier isolée, protégée par une clé dérivée de votre mot de passe via PBKDF2-SHA512 à 600 000 itérations (Argon2id disponible en option). Vous travaillez 100 % hors ligne si vous voulez, et la synchronisation cloud est optionnelle : quand elle est activée, le serveur (Cloudflare R2, ou votre propre bucket S3-compatible en BYOS) ne reçoit que des blobs chiffrés opaques. Face à une fuite côté serveur, c'est exactement la colonne « rien d'exploitable » du tableau plus haut. Si vous partez de Notion, notre guide de migration sans perte détaille le chemin.

Ce que Filarr ne fait pas, et il faut le dire clairement : ce n'est pas une certification RGPD ni un conseil juridique, votre conformité dépend de tout votre traitement, pas d'un outil. Il ne protège pas un poste déjà infecté par un malware. Son écosystème de plugins est plus jeune que celui d'Obsidian, et l'app mobile est encore en cours. Filarr résout un problème précis, garder la clé chez vous, pas tous les problèmes. Si vous voulez comparer les options du marché sans parti pris, notre panorama des alternatives à Notion respectueuses de la vie privée les met côte à côte honnêtement.

Filarr est gratuit pour toujours en local, la sync cloud commence à 4 €/mois. Le client desktop est open source (BSL 1.1), ce qui vous permet, ou permet à un expert, de vérifier que le chiffrement fait ce qu'il annonce.

Cet article est une explication technique, pas un conseil juridique. Pour vos obligations réglementaires précises, référez-vous aux recommandations de la CNIL et, si besoin, à un juriste.

FAQ

Le chiffrement au repos de mon cloud actuel me protège-t-il en cas de piratage du service ? Pas vraiment. Le chiffrement au repos protège surtout contre le vol physique de disques. Si le service est piraté logiquement, ou si un accès admin est compromis, les clés étant détenues par le fournisseur, vos données peuvent être lues. Seul un modèle où vous gardez la clé (end-to-end ou local-first) rend une fuite serveur inexploitable.

Quelle différence entre chiffrement de bout en bout et zero-knowledge ? Ce sont deux angles de la même idée. End-to-end décrit le fait que les données sont chiffrées d'un appareil à l'autre sans être lisibles au milieu. Zero-knowledge décrit le fait que le service qui héberge ne peut techniquement rien apprendre du contenu. Une bonne app de notes chiffrée combine les deux.

Si je perds mon mot de passe, est-ce que je perds tout ? Dans un vrai modèle zero-knowledge, oui, si vous n'avez pas votre phrase de récupération. C'est la contrepartie du fait que personne d'autre ne peut lire vos données : personne ne peut non plus les débloquer à votre place. D'où l'importance de conserver votre phrase de récupération hors ligne, en lieu sûr.

Le chiffrement local me met-il en conformité RGPD ? Non, pas à lui seul. Le chiffrement est une mesure de sécurité qui contribue à la conformité, mais le RGPD couvre l'ensemble du traitement : base légale, information des personnes, durées de conservation, gestion des sous-traitants. Un outil chiffré est un bon socle, pas une certification.

Le cloud classique a-t-il encore des avantages ? Oui, pour la collaboration temps réel, la simplicité de récupération de compte et le partage granulaire sans gestion de clé. Pour des données peu sensibles et un travail d'équipe intensif, c'est souvent un compromis raisonnable. Le choix dépend de la sensibilité réelle de vos données.