Chiffrement E2E dans le navigateur : pourquoi c'est du snake oil

Début juillet 2026, un article de référence signé par l'auteur du blog technique devever.net remet sur la table une évidence dérangeante : un service web qui promet du chiffrement « de bout en bout » ne peut, par construction, tenir cette promesse. Pas forcément par malveillance, mais parce que le navigateur, en tant que plateforme, ne fournit tout simplement pas les briques nécessaires pour le faire.

Le chiffrement de bout en bout (E2E) est devenu un argument marketing incontournable : coffres-forts de mots de passe en ligne, services de partage de fichiers, portefeuilles de cryptomonnaies, messageries. La promesse est toujours la même : « même nous, l'opérateur, ne pouvons pas lire vos données ». L'article de devever.net démonte cette promesse avec un raisonnement simple, formulé comme une loi générale.

Une loi simple qui rend le chiffrement web incohérent

La loi énoncée tient en une phrase : un cryptosystème est incohérent si son implémentation est distribuée par l'entité même contre laquelle il est censé vous protéger.

Sur le web, ce cas de figure n'est pas une exception, c'est la règle. Le code JavaScript qui chiffre vos données dans votre navigateur est livré par le serveur, à chaque visite. Si l'opérateur de ce serveur est malveillant ou contraint de l'être, il n'a qu'une chose à faire : servir une version différente du script au chargement suivant, une version qui exfiltre vos clés ou vos données en clair. Aucune fonctionnalité du navigateur ne permet de distinguer ce cas d'un chargement légitime, ni de figer durablement l'identité du code exécuté pour un domaine donné.

Cela vaut la peine de le préciser : TLS protège déjà contre un tiers qui écoute le trafic entre vous et le serveur. Le chiffrement E2E, lui, prétend vous protéger contre l'opérateur du serveur lui-même. Mais ce même opérateur contrôle le code qui exécute ce chiffrement. La promesse s'effondre dès qu'on l'énonce clairement.

Le chiffrement comme théâtre juridique

Si cette faille est aussi évidente, pourquoi des entreprises investissent-elles autant dans ce type de fonctionnalité ? L'article avance une explication qui n'a rien de cryptographique : ce chiffrement sert avant tout de position juridique. En affichant du « E2E », une entreprise peut répondre à une réquisition judiciaire par un « nous ne pouvons techniquement rien faire », alors qu'en réalité, elle pourrait très bien pousser une version modifiée du client pour satisfaire la demande.

L'article cite deux précédents concrets qui montrent que cet argument juridique est loin d'être une garantie. Le premier est l'affaire Lavabit : lors de l'affaire Snowden, le FBI a tenté de contraindre l'opérateur de ce service de messagerie chiffrée à compromettre le code côté client pour accéder aux messages d'Edward Snowden. Son fondateur a préféré fermer entièrement le service plutôt que de s'exécuter, ce qui démontre au passage qu'il en avait la capacité technique. Le second est l'affaire FBI contre Apple, dans laquelle le FBI a cherché à contraindre Apple à produire une version compromise d'iOS pour déverrouiller l'iPhone d'un suspect. Apple a fini par ne pas avoir à trancher juridiquement, le FBI ayant retiré sa demande après avoir trouvé un autre moyen d'accéder à l'appareil.

Dans les deux cas, l'argument défendu par l'entreprise n'était pas « nous ne pouvons pas », mais « vous ne pouvez pas nous y obliger ». Une nuance essentielle : cet argument juridique repose largement sur une interprétation du droit américain (notamment la protection du code comme forme d'expression au titre du premier amendement), une protection qui n'a aucune raison de s'appliquer telle quelle dans d'autres pays, y compris en France.

Ce que ça change pour vos choix d'outils

Concrètement, que faire de cet argument quand vous évaluez un outil ou que vous devez en concevoir un pour un client ?

D'abord, distinguer les deux menaces que le chiffrement peut couvrir. Contre un attaquant réseau ou un point d'accès Wi-Fi compromis, TLS suffit largement, et c'est déjà le cas par défaut sur l'immense majorité des sites. Contre l'opérateur de la plateforme lui-même (ou contre quiconque peut le contraindre légalement), aucun chiffrement livré par cette même plateforme ne peut vous protéger, qu'il s'agisse d'une web app ou d'une application native dont l'éditeur contrôle les mises à jour et interdit les clients tiers.

Ensuite, se méfier d'un argument commercial précis : « chiffré côté client, nous ne voyons jamais vos données en clair ». Si le code qui chiffre est re-téléchargé à chaque visite depuis le serveur de cet éditeur, la protection ne tient que tant que l'éditeur reste de bonne foi et n'est soumis à aucune pression, légale ou autre. Ce n'est pas rien, mais ce n'est pas non plus ce que le terme « chiffrement de bout en bout » laisse entendre.

Enfin, pour les architectures qui ont réellement besoin d'exclure l'opérateur de la boucle de confiance, la seule voie cohérente passe par un client distribué indépendamment du serveur qui héberge les données : logiciel installé une fois, idéalement avec des mécanismes de vérification d'intégrité et de mises à jour que l'utilisateur contrôle, et non un script rechargé silencieusement à chaque session.

Notre lecture chez CZSyn

Quand un client nous demande du « chiffrement de bout en bout » sur une application web, notre premier réflexe est désormais de clarifier le modèle de menace avant d'écrire la moindre ligne de code. Chiffrer côté client avec une clé dérivée du mot de passe de l'utilisateur a un intérêt réel : ça protège contre un administrateur système curieux qui consulterait une base de données en clair, ou contre une fuite de données brute qui n'exposerait que du contenu chiffré. Mais ce n'est structurellement pas une protection contre l'éditeur de l'application lui-même, ni contre une réquisition judiciaire qui viserait ce dernier.

Notre position est simple : mieux vaut livrer un chiffrement au repos honnête, avec un contrôle d'accès strict et une gestion des clés rigoureuse, que de vendre une promesse de bout en bout qui s'effondrerait dès la première demande légale. C'est aussi un sujet de conformité pour les PME françaises qui manipulent des données sensibles (santé, juridique, finance) : sous RGPD, présenter une propriété de sécurité que votre architecture ne peut pas structurellement garantir est un risque en soi, pas seulement un abus de langage marketing.

Sources primaires

• devever.net, « Web-based cryptography is always snake oil ».
• W3C, spécification officielle de la Web Cryptography API.