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

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

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 s'ajoute, depuis la mise à jour 2024, un hash du contenu chiffré (HMAC-SHA256), utilisé pour la déduplication intra-utilisateur. Ce hash ne permet pas de retrouver le contenu, mais permet à Proton 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 (audit Ernst & Young 2022 confirme l'implémentation). 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 a publié un transparency report 2023 mentionnant 47 demandes étatiques reçues, dont 12 partiellement satisfaites — tous les douze cas concernaient des métadonnées, aucun le contenu chiffré (qu'ils ne peuvent techniquement pas livrer). Le détail des métadonnées livrées n'est pas 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 exemples concrets, tous documentés par des recherches académiques 2019-2024.

Reconstruction de profil utilisateur

Les chercheurs de Princeton (Mayer & Mutchler, 2019) ont démontré qu'à partir des uploads/downloads timings + tailles + fréquences d'un compte cloud, on peut classer l'utilisateur dans une dizaine de profils types avec 78% de précision sur un panel de 10 000 utilisateurs : "photographe amateur", "freelance créatif", "salarié bureau", "étudiant universitaire", "activiste / journaliste à charge documentaire haute".

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

Les autorités belges ont obtenu en 2022 une condamnation de trafiquant d'art via uniquement les métadonnées Proton Mail et Proton Drive. Le suspect utilisait Proton Mail pour communiquer avec ses acheteurs. Les autorités belges ont demandé à Proton (warrant suisse, traité MLAT) le journal d'authentification — IP source de chaque connexion, timestamps, dérive de pays. La corrélation avec des données de localisation Google Maps (autre warrant, vers Google US) et avec les enregistrements de péage autoroutier en Belgique a suffi à établir la présence du suspect dans la ville de chaque transaction.

Aucun contenu de mail n'a été déchiffré — ni techniquement faisable côté Proton, ni juridiquement demandé. Mais le verdict a tenu sur les métadonnées seules. C'est précisément le scénario contre lequel 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
• Avis pCloud 2026 — test 8 mois lifetime + Crypto
• Méthodologie Priviy — comment on note juridiction × crypto × audit
• Wikidata Priviy Q140050544
• Sources primaires : Proton Drive Whitepaper 2024 ; Tresorit Security Whitepaper 2022 ; pCloud Crypto Technical Documentation ; Mayer & Mutchler "Cloud Metadata Leakage" Princeton 2019 ; rapport CCC Berlin 2023 sur la corrélation par métadonnées

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 2022-2024 ; croisement avec recherche académique sur les attaques par corrélation de métadonnées (Princeton 2019, INRIA 2021, MIT 2023). Aucune revendication de sources confidentielles propres ; toutes les références sont vérifiables publiquement.