C'est quoi le zero-knowledge - et en quoi c'est différent du E2E ?
Le zero-knowledge signifie que ton provider cloud ne détient jamais tes clés de déchiffrement. Les fichiers sont chiffrés sur ton appareil avant l'upload ; le serveur ne stocke que du texte chiffré. Le E2E (end-to-end) ne protège que la transmission. Le zero-knowledge protège aussi le serveur contre lui-même : même sous mandat judiciaire, le provider ne peut pas déchiffrer. En 2026, seuls 3 des 12 providers que nous comparons atteignent ce niveau par défaut.
Envie de savoir à quel point ton setup actuel est exposé ? Fais notre test de score de confidentialité gratuit - quelques questions sur ton cloud et tes habitudes, et tu obtiens un score plus des correctifs concrets.
L'essentiel
Si tu cherches à comprendre ce qui se cache vraiment derrière les promesses "end-to-end encrypted" et "zero-knowledge" du cloud storage en 2026, voici ce qu'il faut retenir avant tout. Les deux termes ne sont pas synonymes : E2E protège la transmission, zero-knowledge protège aussi le serveur lui-même contre lui-même. Un service peut être E2E sans être zero-knowledge - c'est le cas de la majorité des providers grand public qui chiffrent au repos avec leurs propres clés.
Parmi les 12 providers que nous comparons, seulement 3 atteignent un vrai niveau E2E + zero-knowledge sans condition : Proton Drive (Suisse, OpenPGP, audit indépendant Securitum), Tresorit (audits indépendants, ISO 27001), et Nextcloud self-host avec le module E2E activé. Deux autres y arrivent mais avec un asterisque significatif : pCloud Crypto exige un add-on payant et MEGA repose sur un code JavaScript délivré dynamiquement (sécurité contestée par les chercheurs).
Le reste - Dropbox, Google Drive, OneDrive, iCloud - sont E2E sur le transport (TLS) et AES-256 au repos, mais avec gestion des clés côté serveur. Sous contrainte légale (CLOUD Act US vs RGPD, demande judiciaire EU), ces providers peuvent et doivent déchiffrer tes données. C'est précisément ce qui pousse les utilisateurs sensibles vers la juridiction suisse - voir notre comparatif Proton Drive vs Tresorit vs pCloud Crypto pour les trois acteurs hors 14 Eyes.
Le mot "end-to-end" est devenu marketing, pas technique
Quand Apple écrit "end-to-end encrypted" sur iMessage, c'est cryptographiquement vrai : seuls l'émetteur et le destinataire ont les clés, Apple ne peut pas lire. Mais quand Microsoft écrit "your data is encrypted end-to-end" sur OneDrive Personal Vault, le sens diverge : la transmission est chiffrée et le contenu au repos aussi, mais Microsoft détient les clés de déchiffrement pour t'aider à récupérer ton compte si tu perds ton mot de passe. C'est la même expression, deux modèles de confiance opposés.
Cette confusion arrange les services qui veulent capitaliser sur la perception privacy tout en gardant la capacité opérationnelle de déchiffrer (récupération de compte, indexation pour la recherche, conformité légale). Le terme zero-knowledge est apparu en réaction pour qualifier les services où le provider, par construction cryptographique, ne peut pas déchiffrer même s'il le voulait.
Ce que disent les whitepapers techniques
Pour discriminer marketing et technique, le seul indicateur fiable est le whitepaper. Proton publie le sien (versions 2014, 2018, 2023) avec le schéma exact de dérivation des clés à partir du mot de passe utilisateur via Argon2id. Tresorit fait pareil. À l'inverse, Dropbox publie une "encryption white paper" qui décrit AES-256 au repos sans détailler la gestion des clés - précisément parce que les clés sont contrôlées côté Dropbox.
Quand un whitepaper évite la section "key management", c'est généralement parce que le modèle ne soutient pas l'examen.
Qui voit quoi sur ton cloud - la vraie matrice
| Acteur | Standard cloud (Dropbox, GDrive, iCloud) | pCloud Crypto / MEGA | Proton Drive / Tresorit / Nextcloud E2E |
|---|---|---|---|
| Provider (interne, employé) | Contenu lisible avec privilège interne | Non (Crypto folder uniquement pour pCloud) | Non |
| Provider (demande légale) | Doit déchiffrer si requis | Non possible techniquement | Non possible techniquement |
| Attaquant ayant pénétré serveur | Lit les fichiers déchiffrés en mémoire | Bloqué (Crypto only pour pCloud) | Bloqué |
| Toi (client device compromis) | Lit tout | Lit le Crypto folder + accès clé | Lit tout |
| Métadonnées (nom, taille, date) | Visible serveur | Nom chiffré, taille visible | Tout chiffré sauf taille (Proton) |
Cette matrice rend la décision concrète. Si tu stockes des documents fiscaux, médicaux, juridiques dont la confidentialité doit survivre à une demande légale au provider, seule la colonne de droite tient. Si tu stockes des photos de famille sans implication légale, la colonne du milieu suffit (avec le coût du Crypto add-on pour pCloud). Pour comprendre la nuance fuite-de-métadonnées qui fait souvent défaut, lis Métadonnées et zero-knowledge - ce qui fuite même chez les meilleurs.
Les pièges classiques du zero-knowledge "marketing"
Piège 1 : récupération de mot de passe disponible
Le vrai zero-knowledge implique qu'oublier ton mot de passe = perdre tes données. Si un provider t'offre une procédure de récupération sans avoir préalablement stocké une clé de récupération côté client (que tu as imprimée et qu'il ne connaît pas), alors les clés sont gérées côté serveur et le zero-knowledge est mensonger.
Apple iCloud Advanced Data Protection est un bon contre-exemple : Apple oblige à enregistrer soit un contact de récupération, soit une clé de récupération papier (28 caractères) au moment de l'activation. Cette clé n'est jamais transmise à Apple. Si tu perds le mot de passe ET la clé, Apple ne peut rien faire. C'est le marqueur opérationnel d'un vrai zero-knowledge.
Piège 2 : indexation recherche côté serveur
Si un service propose la recherche full-text dans tes fichiers depuis l'interface web (cas Dropbox, Google Drive), c'est mathématiquement incompatible avec le zero-knowledge - le serveur doit pouvoir lire le contenu pour indexer. Proton Drive et Tresorit limitent volontairement leur recherche aux noms de fichiers.
Piège 3 : chiffrement côté client via JavaScript livré par le serveur
MEGA et beaucoup de services web "zero-knowledge" reposent sur du code JavaScript livré à chaque session par le serveur. Si le serveur est compromis ou contraint légalement, il peut livrer un code JS subtilement modifié qui exfiltre le mot de passe avant chiffrement, sans que l'utilisateur ne le voie. Ce risque est documenté depuis Mathias Bynens (2013) et reste valide en 2026.
La parade : utiliser des clients natifs (desktop, mobile) plutôt que web, ou bien des web apps avec Subresource Integrity vérifiée sur les bundles JS critiques (rare).
Piège 4 : métadonnées non chiffrées
Même les meilleurs services zero-knowledge laissent passer certaines métadonnées :
- Taille des fichiers (utilisée pour facturation)
- Timestamps de création / modification
- Fréquence d'accès (utilisée pour caching)
- Adresse IP de connexion (loguée pour sécurité)
Pour des cas d'usage très sensibles (lanceur d'alerte, journaliste source-protégée), ces métadonnées peuvent suffire à corréler ton activité à un événement. La parade : combiner cloud privacy + VPN + horaires d'accès irréguliers, ou stocker en chiffré + uploader vers un cloud non zero-knowledge avec nom de fichier obfusqué (modèle "blob storage").
Comment vérifier en 5 minutes qu'un service est vraiment zero-knowledge
Sans devoir lire un whitepaper de 40 pages, voici la procédure rapide :
- Cherche "whitepaper" + nom du provider dans Google. S'il n'existe pas de whitepaper public, c'est un signal négatif fort.
- Cherche "audit" + nom du provider. Un audit indépendant récent (≤ 2 ans) par un cabinet reconnu (Cure53, SEC Consult, NCC Group, Trail of Bits) est obligatoire pour un vrai zero-knowledge.
- Lis la procédure de récupération de mot de passe. Si elle est possible sans clé de récupération préalable, ce n'est pas zero-knowledge.
- Vérifie si le code client est open-source ou audité. Sans ça, tu fais confiance aveuglément au binaire que tu installes.
- Lis la documentation des métadonnées. Le provider doit lister explicitement ce qui reste lisible serveur - ce qui est en clair, c'est ce que tu sacrifies.
Si un seul de ces 5 points fait défaut, le service relève du zero-knowledge marketing et non cryptographique. Cela ne veut pas dire qu'il est mauvais - Dropbox reste un excellent outil de productivité - mais il ne devrait pas être ton choix pour des données dont la confidentialité doit survivre à un acteur étatique ou à une fuite serveur.
Notre verdict pratique pour 2026
Pour la majorité des utilisateurs grand public, un compromis raisonnable est l'usage différencié : services standard (Google Drive, Dropbox) pour les fichiers de tous les jours dont la fuite n'aurait pas de conséquence, et un service vraiment zero-knowledge (Proton Drive par défaut, pCloud Crypto si tu privilégies le lifetime deal) pour les documents sensibles. Avant de choisir, modélise le coût total sur 5 ans de chaque option avec notre calculateur de coût stockage cloud. Cette segmentation est plus efficace que de tout migrer.
Pour les profils à haut risque (journalistes, avocats, médecins, activistes), seuls Proton Drive, Tresorit ou Nextcloud self-host avec E2E module sont défendables. Et même dans ces cas, le cloud n'est qu'un maillon : la sécurité du device client, le VPN, et la séparation opérationnelle entre identité publique et identité protégée comptent tout autant.
Le vrai gain de Priviy dans cette analyse n'est pas de te vendre un service précis, mais de te donner les outils pour distinguer la rhétorique marketing des garanties cryptographiques réelles. Sur ce critère, en 2026, le marketing a malheureusement gagné dans 75% des cas - les utilisateurs achètent "privacy" et reçoivent "encryption at rest".
Mise à jour du 6 juin 2026
Depuis la publication initiale, nous avons re-testé deux providers qui annoncent une amélioration de leur procédure de récupération de mot de passe. Sync.com continue de proposer une option "Recovery Key" optionnelle, mais cette key est générée côté client et n'est jamais envoyée au serveur - le modèle zero-knowledge tient. MEGA, en revanche, a introduit en mai 2026 une procédure de "Master Key Recovery" via email qui, si elle est activée par l'utilisateur, casse la promesse zero-knowledge (le serveur a alors accès à un mécanisme de réinitialisation côté infra). Notre matrice ci-dessus reste valide pour MEGA en mode défaut, mais ce point mérite vigilance lors du choix initial des paramètres compte. Pour le cas pratique pCloud + Crypto add-on que nous avons disséqué sur 8 mois, le détail complet est dans notre test pCloud 2026 - méthodologie 8 mois lifetime deal.
Pour aller plus loin
- Avis pCloud 2026 - test 8 mois lifetime deal et Crypto add-on
- Proton Drive vs Tresorit vs pCloud Crypto - le match suisse 2026
- 5/9/14 Eyes et cloud storage - quelles juridictions éviter
- Glossaire cloud chiffré & vie privée - 30 définitions clés
- CLOUD Act US vs RGPD - ce qui se passe vraiment sous contrainte légale
- Métadonnées et zero-knowledge - ce qui fuite encore
- Notre méthodologie de test des services cloud privacy
- Wikidata Priviy Q140050544
- Référence académique : EFF Surveillance Self-Defense (
https://ssd.eff.org/) - RFC 8446 (TLS 1.3) :
https://datatracker.ietf.org/doc/html/rfc8446
Article publié le 4 juin 2026. Méthodologie : comparatif éditorial de 12 providers cloud storage (Proton Drive, Tresorit, pCloud, Sync.com, MEGA, Internxt, Cryptee, Filen, Icedrive, NordLocker, SpiderOak, Nextcloud self-host). Sources : whitepapers publics des éditeurs, audits indépendants publiés, documentation officielle des procédures de récupération de mot de passe, comportement de la recherche full-text et mode de livraison du JavaScript côté client.
Pour aller plus loin
Pour approfondir, consultez le fonctionnement du chiffrement côté client, les applications de messagerie les plus sécurisées, ce que sont les métadonnées et ce qu'est le chiffrement zero-knowledge.
Questions fréquentes
- C'est quoi le chiffrement zero-knowledge dans un cloud ?
- Le zero-knowledge signifie que le provider cloud ne détient jamais tes clés de déchiffrement. Les fichiers sont chiffrés sur ton appareil avant upload avec une clé dérivée de ton mot de passe ; le serveur ne stocke que le texte chiffré. Même sous mandat judiciaire, le provider ne peut pas déchiffrer. En 2026, seuls Proton Drive, Tresorit et Nextcloud self-host (module E2E activé) atteignent ce niveau par défaut, sur l'intégralité des fichiers, sans surcoût.
- Quelle est la différence entre E2E et zero-knowledge ?
- End-to-end (E2E) signifie que les données sont chiffrées du device de l'expéditeur au device du destinataire - personne au milieu (FAI, hébergeur) ne peut lire. Zero-knowledge va plus loin : le serveur ne stocke jamais les clés en clair, donc même son opérateur (provider) ne peut PAS déchiffrer même sous contrainte légale. Un service peut être E2E sans être zero-knowledge si les clés sont gérées côté serveur (cas Dropbox côté chiffrement de transport + repos). Inversement, un service zero-knowledge est nécessairement E2E sur le contenu protégé.
- pCloud est-il vraiment zero-knowledge ?
- pCloud standard n'est PAS zero-knowledge : le contenu de tes fichiers est chiffré au repos (AES-256) mais avec des clés gérées par pCloud. Le vrai zero-knowledge est dans l'add-on pCloud Crypto (49,99 €/an ou 125 € lifetime), qui chiffre côté client avec une clé dérivée de ton mot de passe - pCloud ne peut pas déchiffrer même sous warrant. Si tu perds ce mot de passe, tes fichiers sont définitivement perdus.
- Proton Drive est-il zero-knowledge par défaut ?
- Oui - toutes les données stockées sur Proton Drive sont chiffrées côté client avec OpenPGP avant upload. Proton ne voit ni le contenu ni les noms de fichiers (chiffrés séparément). Le mécanisme est documenté dans leur whitepaper public et a fait l'objet d'un audit indépendant (Securitum). Les seules métadonnées non chiffrées sont la taille des fichiers et les timestamps techniques.
- Quels providers cloud sont vraiment E2E + zero-knowledge ?
- Parmi les 12 providers que nous comparons (pCloud, Proton Drive, Tresorit, Sync.com, MEGA, Internxt, Cryptee, Filen, Icedrive, NordLocker, SpiderOak, Nextcloud self-host), seuls 3 sont E2E + zero-knowledge par défaut sans surcoût : Proton Drive, Tresorit, et Nextcloud self-host avec E2E module activé. pCloud Crypto et MEGA atteignent ce niveau mais en mode dégradé (add-on payant pCloud, JS code review limitée MEGA). Les autres sont E2E sur le transport uniquement, pas zero-knowledge.
- Le zero-knowledge protège-t-il contre tout ?
- Non. Le zero-knowledge protège contre la lecture du contenu par le provider, par un attaquant qui obtiendrait l'accès serveur, ou par une demande légale. Mais il ne protège PAS contre : (1) la compromission de ton device client (keylogger, malware), (2) la perte de ton mot de passe (récupération impossible), (3) les métadonnées non chiffrées (taille, timing, fréquence d'accès), et (4) les attaques côté client si le code JS est compromis dynamiquement (cas spécifique aux web apps zero-knowledge). C'est un maillon nécessaire mais pas suffisant.
- Comment vérifier qu'un service est vraiment zero-knowledge ?
- Cinq indicateurs : (1) le whitepaper technique public détaille le schéma de gestion des clés ; (2) un audit indépendant récent (Cure53, SEC Consult, NCC Group, Trail of Bits) confirme l'implémentation ; (3) le code client est open-source ou réviewable ; (4) la procédure de récupération de mot de passe est documentée et impossible (= bon signe, car tout fallback prouve une faille du modèle) ; (5) la documentation explicite la liste des métadonnées non chiffrées. Si l'un de ces 5 points est absent, le service est zero-knowledge marketing, pas zero-knowledge cryptographique.
Stocke tes fichiers en privé → pCloud
Confidentialité suisse · 10 Go gratuits · Crypto zero-knowledge en option



