End-to-end vs zero-knowledge : quelle différence ?

Q: Contre quoi chacun protège ?

Réponse rapide. Le chiffrement end-to-end (E2EE) est une propriété de communication : seules les deux extrémités peuvent lire le message ; les intermédiaires ne le peuvent pas. Le zero-knowledge est un modèle de déploiement pour le stockage : le serveur garde vos données chiffrées avec des clés qu'il n'a pas. La plupart des services modernes axés vie privée implémentent les deux — Signal est E2EE pour le chat, Filarr est zero-knowledge pour la sync cloud. Les termes se chevauchent mais ne sont pas synonymes.

Les deux termes sont utilisés comme synonymes dans les pages marketing, les billets de blog sécurité, et même certains papiers académiques. Ce ne sont pas la même chose.

Cet article donne la définition précise de chacun, montre où ils se chevauchent, où ils ne le font pas, et comment évaluer les affirmations de chiffrement de tout service axé vie privée.

Qu'est-ce que le chiffrement end-to-end (E2EE) ?

Le chiffrement end-to-end est une propriété des systèmes de communication. La définition est simple : seules les deux extrémités peuvent lire le contenu ; aucun système intermédiaire qui transporte le message ne le peut.

L'exemple canonique est Signal Messenger. Quand vous envoyez un message :

Votre téléphone chiffre le message avec une clé que le téléphone du destinataire détient (et que les serveurs Signal n'ont pas)
Le blob chiffré transite par les serveurs Signal
Le téléphone du destinataire le déchiffre

Les serveurs Signal voient des octets chiffrés entrer, des octets chiffrés sortir. Ils ne voient jamais de texte en clair. Même s'ils le voulaient, ils ne pourraient pas — les clés ne quittent jamais les appareils des utilisateurs.

L'E2EE n'est pas que de la messagerie. La même propriété s'applique à :

Appels voix et vidéo (Signal, FaceTime, WhatsApp)
Email (Proton Mail, Tutanota)
Partage de fichiers (Wormhole, Magic Wormhole, OnionShare)
Édition collaborative (certaines alternatives Google Docs avec capacité E2EE)

Le trait définissant est toujours le même : la donnée est chiffrée par une extrémité et déchiffrée uniquement par l'autre. Les serveurs intermédiaires sont des coursiers aveugles.

Qu'est-ce que le chiffrement zero-knowledge ?

Le chiffrement zero-knowledge est une propriété des services de stockage. La définition : le serveur stocke vos données chiffrées avec des clés qu'il n'a pas.

Comparé à l'E2EE, le zero-knowledge a une forme différente :

L'E2EE est une propriété d'une communication un-à-un ou un-à-plusieurs entre utilisateurs
Le zero-knowledge est une propriété de la relation d'un seul utilisateur avec son stockage cloud

L'exemple canonique est Bitwarden. Votre coffre de mots de passe est chiffré sur votre appareil avec une clé dérivée de votre mot de passe maître. Le coffre chiffré est uploadé sur les serveurs Bitwarden. Ils stockent un blob opaque. Quand vous vous connectez depuis un autre appareil, votre mot de passe maître déchiffre le coffre localement — les serveurs Bitwarden ne le voient jamais.

Autres services zero-knowledge : 1Password, Proton Drive, Tutanota Calendar, la sync cloud de Filarr, Cryptomator (combiné à n'importe quel cloud).

Si vous reformulez le zero-knowledge comme une « communication » entre votre vous-passé (au moment où vous uploadez) et votre vous-futur (au moment où vous téléchargez sur un nouvel appareil), ça devient un cas particulier d'E2EE. Mais les patterns de déploiement, les modèles de menace et les défis d'ingénierie sont assez différents pour justifier un nom différent.

Où E2EE et zero-knowledge se chevauchent ?

En pratique, les services modernes axés vie privée implémentent souvent les deux à la fois.

Une app de notes chiffrée typique :

Utilise le zero-knowledge pour le stockage personnel — vos notes sont stockées chiffrées sur le serveur, et le serveur ne peut pas les lire
Utilise l'E2EE quand vous partagez une note avec un autre utilisateur — le lien de partage ou l'invitation contient une clé chiffrée que seul le destinataire peut déchiffrer

Donc un seul produit peut être les deux. Filarr, par exemple, est zero-knowledge pour le stockage (vos blobs chiffrés sont sur Cloudflare R2 et les serveurs Filarr ne peuvent pas les lire) et serait E2EE pour toute future fonctionnalité de partage.

Où ne se chevauchent-ils pas ?

Trois cas concrets.

E2EE sans zero-knowledge. Une app de messagerie qui ne stocke pas les messages sur le serveur (ou qui ne les stocke chiffrés que brièvement pour la livraison). Signal est E2EE ; le serveur ne garde presque rien.

Zero-knowledge sans E2EE. Un coffre personnel sans fonctionnalités de partage ou de communication. Un utilisateur Bitwarden seul, un utilisateur Filarr seul sans aucun partage — la donnée est chiffrée zero-knowledge sur le serveur, mais il n'y a pas d'« autre extrémité » parce qu'il n'y a pas de communication.

Ni l'un ni l'autre. La plupart des services cloud. Google Drive chiffre au repos, mais Google détient les clés. Dropbox idem. iCloud idem (sauf pour les éléments derrière le toggle Apple Advanced Data Protection, qui est zero-knowledge).

Pourquoi la distinction compte pour les utilisateurs ?

La distinction compte quand on évalue une affirmation de vie privée. Considérez ces affirmations :

« Nous utilisons le chiffrement end-to-end pour protéger vos données. »

Ça a du sens pour une app de messagerie. Pour une app de notes ou un gestionnaire de mots de passe qui stocke des données dans le cloud, « chiffrement end-to-end » est techniquement un raccourci — le terme s'applique proprement à la communication. L'affirmation correcte est « zero-knowledge » ou « chiffrement côté client sans accès aux clés côté serveur ».

Quand les équipes marketing utilisent « E2EE » pour des produits de stockage, ça signifie en pratique la même chose que zero-knowledge, mais l'usage relâché peut cacher des trous. Lisez la documentation d'architecture, pas la page marketing.

« Vos données sont chiffrées en transit et au repos. »

Ça ne dit rien sur qui détient les clés. Un service peut chiffrer au repos avec des clés qu'il contrôle — c'est de la sécurité cloud standard, pas du zero-knowledge. Posez toujours la question : le service détient-il une copie de la clé de déchiffrement ?

« Nous ne partagerons jamais vos données. »

Une promesse, pas une garantie. Avec le zero-knowledge ou l'E2EE, le service ne peut littéralement pas partager vos données parce qu'il ne peut pas les lire. Sans l'un des deux, vous comptez sur le service pour tenir sa promesse, même sous pression légale.

Contre quoi chacun protège ?

Menace	E2EE protège ?	Zero-knowledge protège ?	Chiffrement côté serveur protège ?
Écoute réseau	✓	✓ (avec TLS)	✓ (avec TLS)
Serveur compromis par des hackers	✓	✓	✗ (les clés sont sur le serveur)
Opérateur du service lit vos données	✓	✓	✗
Réquisition gouvernementale au service	✓	✓	✗
Employé avec accès base de données	✓	✓	✗
Malware sur votre appareil	✗	✗	✗
Mot de passe / clé de récupération perdue	✓ mais données irrécupérables	✓ mais données irrécupérables	✗ (le service peut reset)

L'E2EE et le zero-knowledge offrent les mêmes protections dans leurs domaines respectifs. La différence est le quoi — communication vs stockage — et le comment.

Quelles questions poser avant de faire confiance à un service ?

Une checklist courte quand un service annonce E2EE ou zero-knowledge :

Où est documentée la dérivation de clé ? Un service sérieux publie ses paramètres de KDF (mémoire Argon2id, itérations PBKDF2) dans sa doc sécurité ou technique.
Que voit le serveur ? Des blobs chiffrés, OK. Des noms de fichiers en clair ? La structure des dossiers ? Les sujets de message ? Chaque métadonnée fuitée est un canal auxiliaire potentiel.
Que se passe-t-il en cas de réinitialisation de mot de passe ? Si le service peut reset votre mot de passe et vous redonner accès aux données, ce n'est pas du zero-knowledge. Le vrai zero-knowledge signifie : mot de passe perdu = données perdues (récupérables uniquement via votre propre code de récupération).
Le code est-il open source ou audité ? Une affirmation sans preuve publique est une affirmation marketing. Les audits indépendants et le code ouvert rendent les affirmations vérifiables.
Comment fonctionne le partage ? Si le service supporte le partage, le modèle de partage doit préserver l'E2EE — le serveur ne devrait jamais voir le contenu partagé en clair.

Appliquez ça à n'importe quel service chiffré avant de lui confier vos données.

Comment Filarr se classe sur cette échelle ?

Filarr est un workspace local-first où la sync cloud est zero-knowledge. Pour la situer dans le cadre ci-dessus :

Local-first d'abord. Vos fichiers vivent chiffrés sur votre disque. Aucun serveur n'est impliqué pour que l'app locale fonctionne — il n'y a ni « communication » ni « stockage » que le cloud doive médier.
Sync cloud zero-knowledge. Quand vous activez la sync cloud, vos fichiers sont chiffrés avec AES-256-GCM en utilisant des FEK par fichier, et uploadés comme blobs opaques. Le serveur stocke les blobs chiffrés et un vérificateur de mot de passe ; il ne voit jamais votre mot de passe, votre clé maître, ni aucun contenu de fichier.
Pairing multi-appareils. Quand vous pairez un nouvel appareil, votre appareil existant envoie votre clé maître au nouveau via un handshake ECDH — chiffré par une clé de session éphémère que le serveur ne peut pas dériver. Le serveur fait passer les octets de la clé chiffrée, ne voit rien d'utile.
Pas encore de partage. Filarr ne supporte pas actuellement le partage de fichiers entre utilisateurs. Quand le partage arrivera, il sera E2EE — les clés seront échangées de client à client, pas via le serveur.

Ce que voit le serveur Filarr : des blobs chiffrés opaques, les tailles des blobs (complétées vers des tailles cibles), les timestamps de sync, l'email du compte, un vérificateur de mot de passe. Ce qu'il ne voit pas : le contenu des fichiers, les noms de fichiers, la structure des dossiers, les titres de notes, tout le reste.

Lire l'architecture de sécurité complète de Filarr pour les paramètres précis et le modèle de menace derrière chaque choix de design.