Métadonnées cloud : ce que ton provider zero-knowledge voit quand même (2026)

Quelles métadonnées ton cloud zero-knowledge expose-t-il encore ?

Le zero-knowledge chiffre le contenu mais pas les signaux d'usage. Proton Drive, Tresorit et pCloud Crypto conservent tous en clair : taille des fichiers (octets), timestamps création/modification, IP source (log 30 jours), fréquence d'accès et user-agent. Par recoupement, ces signaux suffisent à profiler un usage et peuvent contribuer à une ré-identification - c'est le principe de l'analyse de trafic. Et la logique des transparency reports des fournisseurs zero-knowledge le confirme : ce qu'ils peuvent livrer sous réquisition porte sur des métadonnées (logs de connexion, IP, timestamps), jamais sur le contenu chiffré qu'ils ne peuvent techniquement pas déchiffrer.

L'essentiel

Le zero-knowledge protège le contenu de tes fichiers : ni le provider, ni un attaquant qui pénétrerait ses serveurs, ni un État qui imposerait un warrant ne peut lire ce que tu stockes. C'est la promesse cryptographique de Proton Drive, Tresorit, pCloud Crypto et Nextcloud E2E.

Mais autour de ce contenu chiffré gravite une couche entière de signaux qui restent en clair côté serveur : la taille de chaque fichier, les timestamps de création et modification, les logs d'accès, l'IP source, la fréquence de connexion, parfois la structure d'arborescence ou le hash du contenu chiffré. Ces signaux sont des métadonnées - et leur fuite, en 2026, suffit dans de nombreux cas à reconstruire ton usage, ton profil, et parfois ton identité.

Le grand mensonge implicite du marketing zero-knowledge consiste à laisser croire qu'un service "zero-knowledge" ne sait rien sur toi. La réalité est plus nuancée : il ne sait pas ce qu'il y a dedans tes fichiers, mais il sait avec précision quand tu uploades, depuis où, dans quel volume et à quelle fréquence. Pour la grande majorité des usages, c'est suffisant. Pour un profil à haut risque (journaliste, activiste, lanceur d'alerte), c'est précisément le maillon faible.

Cet article décompose ce que Proton Drive, Tresorit, pCloud Crypto et Nextcloud E2E ne chiffrent pas, ce qu'on peut en déduire, et les sept gestes concrets pour limiter la fuite sans bloquer l'usage.

Que voit vraiment un cloud zero-knowledge malgré le chiffrement ?

Pour comprendre ce qui fuit, il faut distinguer trois zones de données dans tout cloud :

1. Zone contenu - les octets bruts du fichier (texte, image, vidéo). Chiffrés côté client par les services zero-knowledge.
2. Zone métadonnées de fichier - nom, taille, type MIME, timestamps, identifiant interne. Partiellement chiffrés selon le service.
3. Zone métadonnées techniques - IP source, user-agent, version client, latence, fréquence de requêtes, durée de session. Jamais chiffrés (impossibles à chiffrer côté client par construction).

Le zero-knowledge sérieux protège la zone 1 et chiffre une partie de la zone 2 (noms, structures de dossiers). La zone 3 reste systématiquement en clair, car les serveurs en ont besoin pour fonctionner.

Audit Proton Drive : ce qui fuit malgré OpenPGP

Le whitepaper Proton Drive de 2023 (mis à jour 2024) liste explicitement les informations conservées non chiffrées côté serveur :

• Taille de chaque fichier en octets, arrondie au bloc de chiffrement (16 KB par défaut). Permet de distinguer une photo (3-5 MB), un PDF (200 KB - 5 MB), un film (700 MB+), une archive ZIP (variable).
• Timestamps de création, modification et dernier accès, en UTC, résolution seconde. Permet de tracer l'activité quotidienne et de corréler avec d'autres signaux.
• Identifiant interne (UUID) de chaque fichier et de chaque utilisateur. Permet de joindre logs d'accès et fichiers.
• IP source de chaque connexion, conservée 30 jours dans une logique anti-fraude/anti-abus. Permet de localiser approximativement l'utilisateur ou de détecter des changements de pays.
• User-agent et version du client utilisé. Permet de profiler la plateforme et de cibler d'éventuelles vulnérabilités.
• Fréquence d'accès par fichier, conservée à des fins de performance (cache, prefetch).

À cela peut s'ajouter un hash du contenu chiffré, utilisé pour la déduplication intra-utilisateur. Un tel hash ne permet pas de retrouver le contenu, mais permet de savoir si deux fichiers chiffrés appartenant au même utilisateur sont identiques - utile pour économiser le stockage, problématique si l'utilisateur dépose le même fichier sensible sous plusieurs comptes.

Audit Tresorit : modèle proche, transparence inférieure

Tresorit chiffre côté client le contenu et les noms (implémentation confirmée par des audits de sécurité indépendants). Mais le whitepaper public est moins détaillé que celui de Proton : il mentionne la conservation de la taille et des timestamps "à des fins opérationnelles" sans préciser la rétention. Les logs d'accès sont conservés "tant que nécessaire" - formulation juridique floue.

Tresorit publie un transparency report, mais avec moins de granularité que Proton. Par construction, ce qu'un service zero-knowledge peut livrer sous réquisition se limite aux métadonnées (logs, IP, timestamps) : le contenu chiffré reste hors de portée. Le détail précis des métadonnées livrées n'est en général pas rendu public.

Audit pCloud Crypto : zero-knowledge partiel

Le modèle pCloud Crypto chiffre uniquement le Crypto Folder - un dossier séparé activé via l'add-on payant. Le reste du compte (les fichiers hors Crypto) reste géré avec des clés serveur. Pour le Crypto Folder :

• Le contenu et les noms sont chiffrés côté client (clé dérivée du mot de passe Crypto).
• La taille des fichiers Crypto reste en clair, comme pour le reste du compte.
• Les timestamps sont conservés en clair.
• Le hash du contenu chiffré est utilisé pour la déduplication.

Pour un utilisateur pCloud qui met ses documents sensibles dans Crypto Folder et le reste de ses fichiers (musique, photos vacances) hors Crypto, le ratio Crypto / non-Crypto en lui-même est une métadonnée révélatrice. Si 90% des fichiers d'un compte sont dans Crypto Folder, cela suggère un usage privacy-conscious - information potentiellement intéressante pour une autorité.

Audit Nextcloud E2E : meilleure granularité, friction max

Le module E2E (End-to-End Encryption) de Nextcloud, depuis sa version 25, chiffre côté client contenu, noms et arborescence. C'est l'implémentation la plus complète parmi les services audités ici. Mais :

• L'instance Nextcloud reste un serveur web traditionnel, donc l'IP source, les timestamps et les logs d'accès sont visibles dans les logs Apache/Nginx - sauf à les désactiver explicitement (perte de capacité de debug).
• La taille des fichiers chiffrés reste lisible car c'est le serveur qui alloue le stockage.
• Le module E2E n'est compatible qu'avec les clients desktop et iOS/Android - pas le web - ce qui restreint l'usage.

Sur le papier, Nextcloud E2E self-hosté en juridiction protectrice est la solution la plus défensive. En pratique, le coût opérationnel (administration, mises à jour, sauvegardes, certificats TLS) et le risque d'erreur humaine en font une solution réservée aux profils techniques.

Ce qu'on peut reconstruire à partir des métadonnées

Trois mécanismes concrets. Il ne s'agit pas d'affaires nominatives mais d'illustrations de ce que des métadonnées seules permettent de déduire.

Reconstruction de profil utilisateur

À partir des timings d'upload/download, des tailles et des fréquences d'un compte cloud, on peut raisonnablement classer un utilisateur dans des profils types - sans jamais déchiffrer le contenu. C'est le principe du fingerprinting comportemental : des catégories comme "photographe amateur", "freelance créatif", "salarié bureau", "étudiant universitaire" ou "activiste / journaliste à forte charge documentaire" se distinguent par des signatures d'usage différentes.

Le profil "activiste / journaliste" se signale par des burst d'upload de tailles homogènes (1-3 MB par fichier, suggérant des documents PDF scans), à horaires irréguliers (différents des 9h-18h salariat), depuis des IP variées (suggérant mobilité ou VPN), avec des accès consultatifs très espacés mais récurrents sur les mêmes UUID de fichiers. Aucune de ces déductions ne nécessite de déchiffrer le contenu.

Identification par corrélation

L'identification par corrélation consiste à croiser les métadonnées d'un service avec d'autres traces (logs d'un autre fournisseur, données de localisation, relevés divers). Un fournisseur zero-knowledge ne peut pas livrer le contenu, mais ses logs de connexion (IP source, timestamps) peuvent, sous réquisition légale, être croisés avec d'autres sources pour situer une personne. Le cas public de Proton en 2021 l'illustre : sur ordre d'un tribunal suisse, Proton a dû journaliser puis communiquer l'adresse IP d'un compte - sans jamais déchiffrer le moindre contenu.

Dans ce type de scénario, aucun contenu n'est déchiffré - ni techniquement faisable, ni nécessaire : les métadonnées de connexion seules suffisent à orienter une enquête. C'est précisément ce contre quoi un journaliste enquêtant sur des sujets sensibles doit se prémunir.

Déduction d'arborescence par taille et structure

Même quand les noms de fichiers sont chiffrés (cas Proton Drive, Tresorit), la distribution des tailles dans une arborescence est révélatrice. Un dossier contenant 30 fichiers de 1.5 MB en série suggère des scans PDF de documents A4 noir et blanc - comportement typique d'archivage administratif. Un dossier contenant 1 fichier de 4 GB suggère un film. Un dossier contenant 200 fichiers de 50-200 KB suggère des emails exportés en .eml.

Combiné aux timestamps, cela permet de reconstituer quand l'utilisateur a archivé quoi, sans rien savoir du contenu lui-même. Pour une enquête, c'est largement suffisant pour orienter d'autres demandes ou pour piloter une perquisition physique.

Sept gestes pour limiter la fuite en 2026

Aucun de ces gestes n'est cher ni techniquement complexe. Pour la plupart, ils s'appliquent en moins d'une heure de mise en place.

Geste 1 - Container chiffré local avant upload. Au lieu d'uploader fichier par fichier, place tes documents sensibles dans un container Cryptomator (gratuit, multi-OS) ou un volume Veracrypt. Le container apparaît au cloud comme un seul blob de taille fixe (que tu peux configurer). Le provider voit "un fichier de 5 GB" au lieu de "237 PDF de 200 KB à 4 MB". L'arborescence interne devient invisible.

Geste 2 - VPN multi-hop ou Tor pour l'accès. Brouille ton IP source. Un VPN simple (Mullvad, Proton VPN, IVPN) suffit pour la plupart des cas. Pour un profil à haut risque, Tor avec accès au cloud via leur onion service si disponible (Proton expose son onion service officiel à protonirockerxow.onion).

Geste 3 - Évite les uploads à horaires prévisibles. Si tu uploades toujours à 18h après le boulot, c'est une signature comportementale exploitable. Vary les horaires, batch tes uploads sur des plages d'1-2h irrégulières.

Geste 4 - Supprime les versions historiques. Les clouds zero-knowledge conservent souvent les versions précédentes des fichiers modifiés. Chaque version a son timestamp et sa taille - l'arbre temporel devient révélateur. Configure ton service pour limiter l'historique à 7 jours, ou purge manuellement.

Geste 5 - Sépare archive et collaboration. Ne mets pas tes archives sensibles et tes documents partagés sur le même compte cloud. Utilise deux providers ou deux comptes pour éviter qu'une seule fuite ne révèle toute ton activité numérique.

Geste 6 - Paie en cryptomonnaie ou cash voucher si possible. Proton accepte Bitcoin, pCloud accepte BitPay. La déconnexion entre identité de paiement et compte cloud réduit la traçabilité. Pour les plus prudents, paye avec un Bitcoin tumblé ou un Monero.

Geste 7 - Lis les transparency reports annuels. Proton, Tresorit, pCloud publient leurs statistiques de demandes étatiques. Vérifie chaque année : combien de demandes reçues, combien partiellement satisfaites, quelles juridictions demandeuses. Si ton provider voit ses chiffres exploser sans communication transparente, change de provider.

Notre verdict 2026

Pour la majorité des utilisateurs cloud privacy en 2026, la combinaison gagnante reste celle qu'on documentait dans E2E vs zero-knowledge cloud storage : Proton Drive ou Tresorit pour le contenu, accès via clients natifs, recovery key papier. Les métadonnées qui fuitent sont compatibles avec un modèle de menace "concurrence commerciale" ou "surveillance étatique passive".

Pour les profils à haut risque (journaliste enquêtant sur surveillance étatique, lanceur d'alerte, activiste politiquement exposé, dissident), le zero-knowledge classique ne suffit pas. Il faut empiler :

• Conteneur Cryptomator avant upload (couche 1)
• Accès via Tor ou VPN multi-hop (couche 2)
• Provider suisse hors 14 Eyes (couche 3)
• Paiement crypto désanonymisé (couche 4)
• Compte cloisonné des autres comptes nominatifs (couche 5)

Cet empilement coûte 1-2h de mise en place initiale et 5 minutes de friction par session. C'est le prix de la résistance à la corrélation par métadonnées en 2026 - un prix dérisoire quand on compare au coût d'une déanonymisation réussie.

Pour aller plus loin

• E2E vs zero-knowledge cloud storage - la base cryptographique
• 5/9/14 Eyes et ton cloud privacy - qui peut demander quoi
• CLOUD Act vs RGPD - l'entreprise européenne en 2026
• Proton Drive vs Tresorit vs pCloud - comparatif suisse 2026
• Comparateur cloud chiffré - trouvez le provider zero-knowledge qui minimise les métadonnées exposées
• Avis pCloud 2026 - test 8 mois lifetime + Crypto
• Méthodologie Priviy - comment on note juridiction × crypto × audit
• Wikidata Priviy Q140050544
• Sources primaires : whitepapers publics Proton Drive et Tresorit, documentation pCloud Crypto et Nextcloud E2E ; transparency reports des fournisseurs ; cas public Proton 2021 (journalisation d'IP sur ordre d'un tribunal suisse, confirmé publiquement par Proton).

Article publié le 5 juin 2026. Méthodologie : lecture des whitepapers publics Proton Drive (2023, mise à jour 2024), Tresorit (2022), pCloud Crypto, Nextcloud E2E v25 ; revue des transparency reports publics ; application des principes connus d'analyse de trafic et de corrélation de métadonnées. Guide éditorial explicatif : il n'avance aucune étude chiffrée ni affaire judiciaire qui lui seraient propres ; les exemples cités (dont le cas Proton 2021) sont publics et vérifiables.

Pour aller plus loin

Pour approfondir, consultez ce qu'est une fuite de données, ce qu'est une empreinte numérique et ce que sont les métadonnées.