Zero-knowledge, chiffré de bout en bout, chiffré au repos : quelles différences concrètes

Vous comparez deux applications. Les deux affichent "chiffré" sur leur page d'accueil. L'une dit "chiffré au repos", l'autre "zero-knowledge", et une troisième que vous avez croisée hier parlait de "chiffrement de bout en bout". Ces trois expressions ressemblent à des synonymes marketing. Elles décrivent en réalité des niveaux de protection très différents, et la différence devient brutalement concrète le jour où le fournisseur se fait pirater, reçoit une réquisition judiciaire, ou décide de lire vos données pour entraîner un modèle.

Ce guide décode les trois termes en langage clair, montre contre quoi chacun protège réellement, et vous donne la seule question à poser pour savoir ce que vaut vraiment le "chiffré" d'une app.

Quick Answer

Les trois expressions décrivent des protections différentes, pas la même chose sous trois noms. "Chiffré au repos" signifie que vos données sont chiffrées quand elles dorment sur le disque du serveur, mais le fournisseur détient la clé et peut les lire à tout moment : cela protège contre le vol physique d'un disque, pas contre le fournisseur lui-même. "Chiffré de bout en bout" (E2EE) signifie que les données sont chiffrées sur votre appareil et ne sont déchiffrables que par les destinataires prévus : le serveur ne voit que du contenu illisible qu'il transporte sans pouvoir l'ouvrir. "Zero-knowledge" décrit une propriété du service : il ne connait jamais ni votre clé ni vos données en clair, même s'il le voulait, même piraté, même réquisitionné. En pratique, la question qui tranche tout est simple : qui détient la clé de déchiffrement ? Si c'est le fournisseur, vous n'avez que du chiffrement au repos. Si c'est vous seul, vous êtes en zero-knowledge.

Pourquoi ces trois termes se ressemblent (et pourquoi ça vous piège)

Le problème vient du fait que les trois expressions parlent bien de chiffrement, mais répondent à trois questions différentes.

"Chiffré au repos" répond à : les données sont-elles chiffrées quand elles sont stockées ?
"Chiffré de bout en bout" répond à : le chiffrement couvre-t-il tout le trajet, de votre appareil jusqu'au destinataire, sans point intermédiaire en clair ?
"Zero-knowledge" répond à : le service qui héberge les données peut-il, techniquement, les lire ?

Un service peut cocher la première case sans les deux autres. C'est même le cas le plus fréquent. Presque tous les grands SaaS chiffrent au repos et en transit, parce que c'est la base et parce que c'est peu coûteux. Très peu vont jusqu'au zero-knowledge, parce que cela leur retire la capacité de lire vos données, donc de proposer de la recherche côté serveur, des aperçus, de l'IA sur votre contenu, ou simplement de réinitialiser votre mot de passe à votre place.

Le piège marketing, c'est qu'une page d'accueil qui affiche "chiffrement AES-256" en gros vous laisse croire à une protection maximale, alors qu'il s'agit souvent du plus faible des trois modèles. C'est exactement le cas de plusieurs outils grand public : nous avons détaillé ailleurs ce que veut dire concrètement le chiffrement de Notion, qui chiffre bien au repos et en transit mais détient les clés.

Les trois modèles, ligne par ligne

1. Chiffré au repos

Vos données arrivent en clair sur le serveur du fournisseur. Le serveur les chiffre avec une clé qu'il gère lui-même, puis les écrit sur son disque. Quand vous les demandez, le serveur les déchiffre, puis vous les renvoie.

Ce que ça protège : si quelqu'un vole physiquement un disque dur du datacenter, ou accède à un backup brut mal protégé, il ne lit rien d'exploitable. C'est une vraie protection, mais étroite.

Ce que ça ne protège pas : le fournisseur détient la clé. Donc un employé mal intentionné, un pirate qui compromet le serveur applicatif (pas juste le disque), une réquisition judiciaire, ou une décision commerciale de lire votre contenu, tout cela reste possible. Vos données existent en clair à chaque fois que le serveur les traite.

Exemple typique : la plupart des SaaS de notes, de docs et de stockage cloud classiques.

2. Chiffré de bout en bout (E2EE)

Les données sont chiffrées sur votre appareil, avant de partir. Elles ne redeviennent lisibles que sur l'appareil du destinataire prévu, qui possède la clé. Entre les deux, le serveur ne voit passer que du contenu chiffré qu'il stocke ou relaie sans pouvoir l'ouvrir.

Ce que ça protège : le fournisseur ne peut pas lire le contenu, même s'il le voulait. C'est le modèle des messageries sérieuses (Signal, WhatsApp pour les messages) et des gestionnaires de mots de passe.

La nuance importante : E2EE décrit le trajet et les extrémités. La question "qui sont les bouts ?" compte. Dans une app de notes personnelle, les "deux bouts" peuvent être vos propres appareils. Dans un partage, ce sont vous et la personne à qui vous partagez. Le chiffrement de bout en bout ne dit rien, en soi, sur ce que le serveur voit d'autre : métadonnées, taille des fichiers, qui parle à qui, fréquence. On peut avoir un E2EE solide sur le contenu et une fuite de métadonnées à côté.

3. Zero-knowledge

Zero-knowledge est le terme le plus fort, mais aussi le plus galvaudé. Il décrit une architecture où le service ne possède littéralement aucune connaissance exploitable de vos données. Concrètement, la clé de déchiffrement est dérivée de votre mot de passe (ou d'un secret que vous seul détenez) et ne quitte jamais votre appareil en clair. Le serveur ne stocke que des blobs chiffrés opaques, qu'il serait incapable d'ouvrir même sous la contrainte.

La différence avec E2EE est subtile mais réelle, et nous l'avons décortiquée dans un article dédié sur ce qui sépare vraiment end-to-end et zero-knowledge. En résumé : E2EE décrit le chemin des données, zero-knowledge décrit ce que le service sait. Les deux se recouvrent souvent, mais pas toujours. Une architecture zero-knowledge bien faite implique presque toujours de l'E2EE ; l'inverse n'est pas garanti.

Ce que ça protège : à peu près tout ce qui vient du côté serveur. Piratage du serveur, employé curieux, réquisition, revente, entrainement d'IA sur votre contenu : rien de tout cela ne donne accès au clair, parce que le serveur n'a jamais eu la clé.

Ce que ça ne protège pas : votre propre appareil s'il est compromis (malware, appareil déverrouillé), un mot de passe faible ou réutilisé, et la perte du secret de récupération. Le zero-knowledge déplace la responsabilité vers vous. C'est le prix de l'ownership. Pour comprendre pourquoi ce déplacement change tout le jour d'un incident, voir notre analyse du chiffrement local face à une fuite de données.

Tableau comparatif

Critère	Chiffré au repos	Chiffré de bout en bout (E2EE)	Zero-knowledge
Qui détient la clé ?	Le fournisseur	Les extrémités (vous / destinataire)	Vous seul
Le serveur peut-il lire le contenu ?	Oui, à tout moment	Non, pour le contenu	Non, jamais
Protège contre le vol de disque	Oui	Oui	Oui
Protège contre le fournisseur / une réquisition	Non	Oui (contenu)	Oui
Protège les métadonnées	Non	Pas forcément	Selon l'implémentation
Récupération si mot de passe perdu	Facile (le fournisseur réinitialise)	Variable	À votre charge (phrase de récupération)
Exemple courant	SaaS de notes/docs classiques	Messageries chiffrées	Coffres chiffrés, apps local-first sérieuses

Ce que ça implique concrètement quand vous choisissez une app

Quelques réflexes pour ne plus vous faire piéger par le mot "chiffré".

Posez la seule question qui compte : qui détient la clé ? Si l'app peut réinitialiser votre mot de passe et vous rendre vos données, alors elle détient la clé, donc elle peut lire vos données. Ce n'est ni bien ni mal en soi, mais ce n'est pas du zero-knowledge.
Méfiez-vous de "chiffrement AES-256" tout court. AES-256 est un excellent algorithme, mais c'est une brique, pas une architecture. La vraie question n'est pas quel algorithme, mais qui a la clé et où elle vit. Si vous voulez comprendre ce que recouvre exactement cette étiquette, nous l'avons détaillé dans ce qu'est réellement l'AES-256-GCM.
Distinguez le contenu et les métadonnées. Une app peut chiffrer parfaitement vos fichiers et laisser filer leurs noms, leurs tailles, votre graphe de relations. Regardez ce que le serveur voit vraiment.
Vérifiez la récupération. En zero-knowledge, personne ne peut vous rendre l'accès si vous perdez votre secret. Une phrase de récupération (souvent 24 mots) est le bon signe : elle indique que la clé dépend de vous, pas du fournisseur.
Préférez local-first quand vos données sont sensibles. Si les données ne quittent pas votre machine par défaut, la surface d'attaque côté serveur disparait presque entièrement. Le cloud devient une option de sync, pas un dépôt obligatoire.

Où Filarr se situe (positionnement honnête)

Filarr est un workspace local-first chiffré : notes, fichiers et un graph qui les relie, le tout chiffré sur votre disque. Concrètement, chaque fichier est chiffré en AES-256-GCM avec sa propre clé (une File Encryption Key isolée par fichier), elle-même protégée par une clé dérivée de votre mot de passe via PBKDF2-SHA512 à 600 000 itérations (recommandation OWASP), avec Argon2id en option. La récupération passe par une phrase de 24 mots au standard BIP-39. Si vous voulez le détail de cette hiérarchie de clés, nous l'expliquons dans notre article sur KEK, FEK et le chiffrement par fichier.

Par défaut, tout est local : Filarr fonctionne 100% hors ligne, sans compte obligatoire. La sync cloud est optionnelle. Quand vous l'activez, le backend (Cloudflare R2, ou votre propre bucket S3-compatible en BYOS) ne reçoit que des blobs chiffrés opaques, ce qui place la sync dans le modèle zero-knowledge décrit plus haut. Le fonctionnement précis est détaillé dans notre explication de la sync zero-knowledge de Filarr.

Ce que Filarr ne résout pas, et il faut le dire clairement : le chiffrement ne protège pas un appareil déjà compromis, ni un mot de passe faible, ni la perte de votre phrase de récupération. Ce n'est pas non plus une messagerie E2EE multi-partie ni une certification de conformité. Filarr est un outil de chiffrement local, pas une garantie magique. Comparé à un Obsidian, il a moins de plugins et une communauté plus jeune ; comparé à un Notion, il n'a pas la collaboration temps réel à grande échelle. Le compromis est assumé : vous gagnez l'ownership réel de vos données contre un peu de responsabilité et un écosystème plus jeune.

Si vous voulez l'architecture défensive complète, sans filtre, nous l'avons documentée dans la sécurité de Filarr couche par couche.

FAQ

"Chiffré au repos", est-ce que ça veut dire que le fournisseur ne peut pas lire mes données ? Non. Chiffré au repos veut dire que les données sont chiffrées sur le disque du serveur, mais le fournisseur détient la clé et déchiffre vos données chaque fois qu'il les traite. Il peut donc les lire. Cela protège surtout contre le vol physique d'un disque, pas contre le fournisseur lui-même.

Zero-knowledge et chiffrement de bout en bout, c'est pareil ? Presque, mais pas exactement. Le chiffrement de bout en bout décrit le trajet des données (chiffrées d'un appareil à l'autre, illisibles pour le serveur intermédiaire). Le zero-knowledge décrit ce que le service sait : rien d'exploitable, aucune clé. Une bonne architecture zero-knowledge repose sur du chiffrement de bout en bout, mais l'inverse n'est pas toujours vrai.

Comment savoir en une question si une app est vraiment zero-knowledge ? Demandez : si je perds mon mot de passe, pouvez-vous me rendre mes données ? Si oui, l'app détient la clé, ce n'est pas du zero-knowledge. Si non, et qu'elle vous fournit une phrase de récupération que vous seul gardez, c'est bon signe.

Le zero-knowledge est-il toujours le meilleur choix ? Pas pour tout. Il déplace la responsabilité vers vous : mot de passe solide, phrase de récupération à ne pas perdre, et souvent pas de récupération assistée. Pour des données peu sensibles où vous voulez de la collaboration fluide, un modèle plus classique peut suffire. Pour des données personnelles ou confidentielles, le zero-knowledge (idéalement local-first) est le plus protecteur.

Une app peut-elle chiffrer mon contenu mais quand même en apprendre beaucoup sur moi ? Oui. Le contenu peut être chiffré et les métadonnées (noms de fichiers, tailles, dates, relations, fréquence d'usage) rester visibles côté serveur. Regardez toujours ce que le serveur voit en plus du contenu, pas seulement si le contenu est chiffré.