Le chiffrement bout-en-bout expliqué sans jargon ni marketing
Le chiffrement bout-en-bout (E2EE pour End-to-End Encryption, parce qu’en informatique on adore les acronymes qui impressionnent les investisseurs) est le niveau de protection où personne – absolument personne – entre vous et votre destinataire ne peut lire vos données. Pas le fournisseur, pas ses employés, pas ses sous-traitants, pas l’autorité qui débarque avec un mandat. Si la section sécurité et chiffrement cloud couvre l’architecture complète, cet article se concentre sur la couche qui génère le plus de promesses marketing et le plus de malentendus. Car comme l’explique l’ANSSI dans son guide des bonnes pratiques, le chiffrement n’a de valeur que si on comprend ce qu’il protège et ce qu’il sacrifie.
En deux phrases : avec l’E2EE, vos fichiers sont chiffrés sur votre appareil avant d’être envoyés au serveur. Le serveur stocke un blob opaque qu’il ne peut pas déchiffrer. C’est la différence entre envoyer un colis transparent à la poste et envoyer un coffre-fort verrouillé dont seul le destinataire a la clé.
Comment ça fonctionne (vraiment)
Le principe est simple, l’implémentation est diabolique. Quand vous activez l’E2EE sur un cloud comme Proton Drive (activé par défaut) ou Tresorit, voici ce qui se passe :
- Votre appareil génère une clé de chiffrement – soit dérivée de votre mot de passe via un algorithme comme Argon2, soit une clé aléatoire protégée par votre mot de passe maître.
- Le fichier est chiffré localement avant de quitter votre machine. Le client cloud transforme votre document en données illisibles.
- Le blob chiffré voyage jusqu’au serveur (protégé en transit par TLS, donc doublement chiffré pendant le transport).
- Le serveur stocke le blob sans jamais voir le contenu en clair. Il ne possède pas la clé, ne l’a jamais eue, et ne peut pas la reconstituer.
- Au téléchargement, le blob revient vers votre appareil, qui le déchiffre localement avec votre clé.
Tout ça se passe en coulisses. Vous ne voyez rien, sauf peut-être un léger ralentissement sur de très gros fichiers (le chiffrement/déchiffrement local consomme du CPU et de la RAM).
Le problème, c’est tout ce que le serveur ne peut plus faire quand il ne voit pas le contenu de vos fichiers. Et c’est là que le marketing s’arrête et que la réalité commence.
Pas de recherche plein texte côté serveur – le serveur ne peut pas indexer ce qu’il ne peut pas lire. Proton Drive ne vous permet pas de chercher dans vos documents, seulement par nom de fichier. Pas de prévisualisation en ligne pour certains formats – ouvrir un PDF ou une image directement dans le navigateur nécessite un déchiffrement, qui doit se faire côté client. Certaines implémentations le gèrent, d’autres non. Pas de collaboration en temps réel native – si le serveur ne peut pas lire le document, il ne peut pas gérer la co-édition. Google Docs fonctionne parce que Google voit tout. Avec l’E2EE, la co-édition nécessite des protocoles de synchronisation de conflits bien plus complexes (Tresorit y arrive, mais avec des limitations).
Le partage de fichiers devient aussi plus compliqué. Pour partager un fichier chiffré bout-en-bout avec quelqu’un, il faut échanger des clés de manière sécurisée. Les implémentations modernes utilisent la cryptographie asymétrique (chaque utilisateur a une paire clé publique/clé privée), mais ça suppose que le destinataire ait aussi un compte sur le même service.
Le zero-knowledge pousse la logique encore plus loin
Si l’E2EE garantit que le fournisseur ne peut pas lire le contenu de vos fichiers, le zero-knowledge pousse la logique jusqu’à ne rien savoir du tout – ni les noms de fichiers, ni les métadonnées, ni la structure de vos dossiers. En pratique, rares sont les services qui atteignent un vrai zero-knowledge complet. La plupart des clouds « E2EE » chiffrent le contenu mais conservent les métadonnées en clair pour pouvoir fonctionner (afficher l’arborescence, trier par date, calculer l’espace utilisé).
Le chiffrement en transit et au repos reste la fondation
On pourrait croire que l’E2EE rend le chiffrement en transit et au repos obsolète. C’est faux. L’E2EE ajoute une couche au-dessus des deux autres, il ne les remplace pas. TLS protège les métadonnées et les échanges de clés pendant le transport. Le chiffrement au repos protège le blob chiffré lui-même contre un accès physique aux disques. Supprimer ces couches sous prétexte que l’E2EE suffit serait comme retirer les murs d’une maison sous prétexte que le coffre-fort dans la chambre est solide.
Qui devrait activer l’E2EE ? Les professionnels qui manipulent des données sensibles – avocats, médecins, comptables, journalistes d’investigation. Toute personne ou organisation pour laquelle une fuite de données aurait des conséquences légales, financières ou personnelles graves. Si votre cloud contient des photos de vacances et des recettes de cuisine, l’E2EE est un luxe agréable mais pas vital. Si votre cloud contient des contrats clients, des dossiers patients ou des documents stratégiques, l’E2EE passe de « fonctionnalité premium » à « obligation morale ».
Côté fournisseurs en 2026 : Proton Drive chiffre tout bout-en-bout par défaut, sans exception. Tresorit aussi, avec une orientation entreprise. pCloud propose l’E2EE via son option Crypto (payante, non activée par défaut). kDrive d’Infomaniak propose le chiffrement côté serveur avec des clés suisses, mais pas un E2EE complet par défaut – un compromis entre sécurité et fonctionnalité qui convient à la majorité des usages professionnels. Google Drive et OneDrive ? Chiffrement en transit et au repos, clés détenues par Google et Microsoft respectivement, pas d’E2EE natif pour les fichiers (Google propose un chiffrement côté client pour Workspace Enterprise, mais c’est une autre histoire tarifaire).
Le verdict : l’E2EE est le niveau de chiffrement le plus solide que vous puissiez obtenir dans le cloud. Mais c’est aussi le plus contraignant. Avant de l’activer partout, posez-vous une question simple : est-ce que les limitations (pas de recherche serveur, collaboration plus lourde, récupération impossible si vous perdez votre clé) valent la garantie que même votre fournisseur ne peut pas lire vos fichiers ? Pour les données critiques, la réponse est presque toujours oui. Pour le reste, le chiffrement standard avec un fournisseur de confiance dans une juridiction solide (comme la Suisse) est souvent le meilleur compromis.