Sommaire
- Ce que « stockage cloud chiffré » veut vraiment dire
- Zéro-connaissance vs côté serveur : qui détient les clés
- Les modèles de menace défendus par chaque conception
- Juridiction et métadonnées : la partie que le marketing saute
- Les vrais compromis du zéro-connaissance
- La place des fournisseurs E2E : Internxt et Proton Drive
- Un cadre de décision pour les développeurs
Ce que « stockage cloud chiffré » veut vraiment dire
« Chiffré » est l'un des mots les plus galvaudés du marché du stockage. Presque tous les fournisseurs peuvent affirmer en toute honnêteté que leur service est chiffré, parce qu'une couche l'est — et la couche qui compte est rarement celle de la page marketing.
Tout produit de stockage cloud comporte trois couches de chiffrement distinctes, qui protègent contre des choses totalement différentes :
- Chiffrement en transit — TLS protège les octets qui circulent entre ton appareil et le serveur. Cela arrête une écoute réseau. Tout fournisseur sérieux le fait ; c'est un prérequis, pas une fonctionnalité.
- Chiffrement au repos — les données sur les disques du fournisseur sont chiffrées, généralement en AES-256. Cela protège contre le vol physique d'un disque dans le centre de données. Mais le fournisseur détient la clé, donc cela ne fait rien contre le fournisseur, une réquisition judiciaire, ou une intrusion atteignant le coffre de clés.
- Chiffrement de bout en bout / zéro-connaissance — les données sont chiffrées sur ton appareil avec une clé que toi seul contrôles, avant même d'atteindre le serveur. Le fournisseur ne stocke que du texte chiffré qu'il ne peut pas lire.
Quand un développeur soucieux de sa vie privée demande un « stockage cloud chiffré », il pense presque toujours à la troisième couche. Quand un fournisseur grand public vante « vos données sont chiffrées », il pense presque toujours aux deux premières. Cet écart est tout le sujet de cet article.
Zéro-connaissance vs côté serveur : qui détient les clés
La seule question qui sépare les deux mondes est : qui peut déchiffrer tes fichiers sans ta coopération ?
Chiffrement côté serveur (classique). Le fournisseur génère et stocke les clés de chiffrement. Tes fichiers sont chiffrés au repos, mais le système même qui stocke le texte chiffré stocke aussi le moyen de le déchiffrer. C'est le modèle derrière l'expérience par défaut de Dropbox, Google Drive, OneDrive et la plupart des stockages cloud grand public. L'avantage est la commodité : le serveur peut indexer tes fichiers pour la recherche, afficher des aperçus, lancer une analyse antivirus, alimenter l'édition collaborative et réinitialiser ton mot de passe sans perte de données. Le coût est que le fournisseur — et quiconque peut atteindre légalement ou illégalement son coffre de clés — peut tout lire.
Chiffrement zéro-connaissance (bout en bout). La clé est dérivée de ton mot de passe sur ton appareil via une fonction de dérivation de clé comme Argon2 ou PBKDF2. Le texte clair est chiffré en local ; seul le texte chiffré est téléversé. Le fournisseur stocke une copie chiffrée de ton matériel de clé, enveloppée par une clé qui provient elle-même de ton mot de passe, donc le trousseau stocké est inutile sans toi. Le fournisseur ne peut donc pas lire tes fichiers, ne peut pas produire de texte clair en réponse à une réquisition, et ne peut pas réinitialiser ton mot de passe sans que tu perdes l'accès. Le terme « zéro-connaissance » décrit exactement cela : le service n'a aucune connaissance de ton texte clair.
La cryptographie ici n'a rien d'exotique — c'est le même schéma de chiffrement par enveloppe utilisé dans les gestionnaires de mots de passe comme ceux couverts dans notre guide des gestionnaires de mots de passe en CLI pour développeurs. Ce qui diffère entre fournisseurs, c'est la rigueur d'implémentation : quelle KDF, quel chiffrement, si les noms de fichiers et la structure des dossiers sont aussi chiffrés, et si le client est open source pour que la promesse soit vérifiable plutôt que crue sur parole.
Les modèles de menace défendus par chaque conception
Choisir un modèle de chiffrement, c'est en réalité choisir un modèle de menace. Fais correspondre ton adversaire à la conception, pas l'inverse.
| Menace | Au repos (côté serveur) | Zéro-connaissance (E2E) |
|---|---|---|
| Écoute réseau | Défendu (TLS) | Défendu (TLS) |
| Disque volé au centre de données | Défendu | Défendu |
| Le fournisseur lit tes fichiers | Non défendu | Défendu |
| Employé malveillant | Non défendu | Défendu |
| Réquisition judiciaire du contenu | Non défendu | Défendu (aucun texte clair à donner) |
| Intrusion atteignant le coffre de clés | Non défendu | Défendu (clés jamais utilisables sur le serveur) |
| Tu oublies ton mot de passe | Le fournisseur peut récupérer | Irrécupérable par conception |
| Logiciel malveillant sur ton appareil | Non défendu | Non défendu (le texte clair existe en local) |
Deux lignes méritent l'accent. Le zéro-connaissance ne te protège pas d'un logiciel malveillant sur ta propre machine — une fois que tu déchiffres en local, le texte clair est entre tes mains et dans ta RAM, donc l'hygiène du poste compte toujours. Et le zéro-connaissance reporte sur toi le risque de récupération de mot de passe : l'incapacité du fournisseur à lire tes données est la même propriété qui rend un mot de passe oublié irrécupérable. C'est une fonctionnalité, mais une fonctionnalité à double tranchant.
Juridiction et métadonnées : la partie que le marketing saute
Le chiffrement protège le contenu. Il ne protège pas à lui seul les métadonnées — et les métadonnées suffisent souvent.
Même un service zéro-connaissance parfaitement implémenté doit fonctionner. Il connaît l'email de ton compte (tu t'es inscrit avec), tes adresses IP à la connexion, ton volume de stockage, les tailles de fichiers, les horodatages de téléversement et — selon l'implémentation — les noms de fichiers et de dossiers. Certaines conceptions E2E chiffrent aussi les noms de fichiers ; beaucoup non. Les métadonnées ne sont généralement pas couvertes par la garantie zéro-connaissance, et ce sont précisément elles qui sont réquisitionnées en premier.
C'est là que la juridiction revient. Le régime juridique d'un fournisseur détermine quelles métadonnées peuvent être exigées et selon quelle procédure. Le CLOUD Act américain (2018) permet aux autorités américaines de contraindre les entreprises américaines à produire des données détenues n'importe où dans le monde. Le RGPD de l'UE et la loi fédérale suisse révisée sur la protection des données (LPD, en vigueur depuis septembre 2023) imposent des conditions plus strictes à la divulgation. C'est la même logique juridictionnelle que nous avons couverte pour l'email dans email auto-hébergé vs ProtonMail vs Fastmail et plus largement dans souveraineté des données : où un service est constitué est une variable technique primaire, pas une note de bas de page.
À retenir en pratique : associe un chiffrement de contenu solide à un fournisseur dans une juridiction respectueuse de la vie privée, et pars du principe que tes métadonnées sont visibles pour une procédure judiciaire suffisamment motivée, quoi qu'il arrive.
Les vrais compromis du zéro-connaissance
Le stockage zéro-connaissance n'est pas sans friction. Être honnête sur les coûts est le seul moyen de bien choisir.
La recherche et les aperçus se dégradent. Comme le serveur ne stocke que du texte chiffré, il ne peut pas construire d'index plein texte de tes documents ni afficher d'aperçus et de miniatures côté serveur comme le fait Google Drive. Les fournisseurs E2E cherchent soit côté client (après que ton appareil a déchiffré un index), soit limitent la recherche aux noms de fichiers. Pour un dossier de milliers de documents, la différence est notable.
La collaboration est plus difficile. L'édition collaborative en temps réel, celle qui a rendu Google Docs incontournable, a fondamentalement besoin d'un serveur capable de lire et de fusionner l'état du document. Les conceptions zéro-connaissance peuvent faire de la collaboration, mais de façon plus contrainte et avec des implémentations plus jeunes.
Le partage avec des non-utilisateurs exige un échange de clé. Envoyer un fichier chiffré à quelqu'un hors du service implique de transmettre une clé de déchiffrement par un canal séparé, ou d'utiliser une fonction du fournisseur qui génère un lien protégé par mot de passe. Ça marche, mais c'est une étape que les services classiques masquent.
La récupération de mot de passe te revient. Cela mérite d'être répété car c'est la manière la plus courante de perdre des données sur ces services. Sauvegarde la clé de récupération que le fournisseur te donne à l'inscription, range-la dans un endroit durable et hors ligne, et utilise un mot de passe fort et unique. Tout le modèle de sécurité repose sur ce mot de passe.
Aucun de ces points n'est une raison d'éviter le stockage zéro-connaissance — ce sont des raisons de l'utiliser délibérément, pour les données qui le justifient, plutôt que comme remplacement universel de tous les flux de travail.
La place des fournisseurs E2E : Internxt et Proton Drive
Deux fournisseurs reviennent sans cesse dans les comparatifs axés confidentialité parce qu'ils livrent des clients open source et un chiffrement de bout en bout par défaut, et non en option payante ou en mode réservé aux entreprises.
Internxt est un fournisseur basé dans l'UE (Espagne) proposant un stockage cloud zéro-connaissance, chiffré de bout en bout, avec des clients open source et une offre gratuite. Son positionnement est une suite complète de confidentialité (drive, plus des outils de confidentialité adjacents), et sa base européenne le place sous le RGPD. Comme le client est open source, la promesse zéro-connaissance est vérifiable plutôt qu'affirmée.
Proton Drive est le composant de stockage de l'écosystème Proton — basé en Suisse, chiffré de bout en bout, open source, avec une offre gratuite. Si tu utilises déjà Proton Mail ou Proton VPN, Drive s'intègre au même compte et à la même juridiction suisse, ce qui en fait une façon naturelle de garder des fichiers chiffrés à côté d'un email chiffré. Le même modèle zéro-accès qui protège une boîte Proton protège les fichiers de Drive.
Aucun n'est une réponse universelle. Ce sont les bons outils quand tu as précisément besoin que le fournisseur soit incapable de lire tes données, et que tu acceptes les compromis de recherche/collaboration en échange.
Un cadre de décision pour les développeurs
Arrête de demander « quel est le stockage cloud le plus sécurisé » et commence à demander « quelles sont ces données, et qui ne doit pas les lire ? »
Utilise un stockage classique (Drive/Dropbox/OneDrive) quand : tu as besoin d'une recherche plein texte rapide dans les documents, d'une collaboration en temps réel, d'aperçus riches, et que les données ne sont pas assez sensibles pour justifier la friction. La commodité est une exigence légitime.
Utilise un stockage zéro-connaissance (Internxt, Proton Drive) quand : le contenu doit rester illisible pour le fournisseur — documents personnels, archives d'identifiants, données clients sous NDA, sauvegardes de projets sensibles, tout ce que tu ne voudrais pas voir produit sous réquisition. Accepte que la recherche soit locale et que le partage nécessite une clé.
Pour le code source : continue d'utiliser Git sur une forge pour le flux de travail ; utilise le stockage chiffré pour les sauvegardes de dépôts, les gros fichiers binaires et les artefacts de build que tu ne veux pas voir indexés par un tiers. Ne mets pas de secrets actifs dans des fichiers bruts sur un stockage quelconque — utilise un gestionnaire de secrets dédié ou un coffre chiffré.
Quel que soit ton choix, vérifie la promesse. Préfère les clients open source pour que le chiffrement soit auditable, préfère une juridiction respectueuse de la vie privée pour que les métadonnées soient plus difficiles à exiger, et sauvegarde ta clé de récupération dès l'inscription à un service zéro-connaissance. La meilleure cryptographie du monde est anéantie par un mot de passe oublié sans voie de récupération.
Pour le contexte plus large du maintien de tes données hors des services sous juridiction américaine, consulte notre pilier sur la souveraineté des données et le guide pratique de migration dans alternatives à Google.
