Sommaire
- Les trois sens d'« e-mail chiffré »
- Le chiffrement de transport : nécessaire, pas suffisant
- Le bout-en-bout : PGP vs S/MIME
- Le chiffrement à accès zéro du fournisseur
- Le problème des métadonnées que tout le monde saute
- Où se situent vraiment les grands fournisseurs
- Un cadre de décision
Les trois sens d'« e-mail chiffré »
« E-mail chiffré » est l'une des expressions les plus galvaudées du marché de la vie privée, parce que presque tous les fournisseurs peuvent l'affirmer en toute honnêteté tout en désignant des choses complètement différentes. Il existe trois couches de chiffrement distinctes dans l'e-mail, et elles défendent contre trois adversaires différents :
- Le chiffrement de transport (TLS / STARTTLS) — la connexion entre deux serveurs de messagerie est chiffrée. Cela arrête un écoutant passif sur le câble. C'est désormais quasi universel et c'est le strict minimum, pas une fonctionnalité.
- Le chiffrement de bout en bout (PGP ou S/MIME) — le corps du message est chiffré sur l'appareil de l'expéditeur avec la clé publique du destinataire, si bien que seule la clé privée du destinataire peut l'ouvrir. Aucun serveur du chemin ne peut le lire.
- Le chiffrement à accès zéro du fournisseur — le fournisseur stocke ta boîte chiffrée avec des clés dérivées de ton mot de passe, de sorte que même lui ne peut pas lire les messages présents dans ton compte.
Quand un fournisseur grand public dit « ton e-mail est chiffré », il parle presque toujours de la couche 1, parfois de la couche 1 plus le chiffrement de disque au repos. Quand un ingénieur soucieux de sa vie privée demande de l'e-mail chiffré, il parle presque toujours de la couche 2 ou 3. Cet écart est tout le sujet de ce guide.
Le chiffrement de transport : nécessaire, pas suffisant
TLS — généralement négocié sur SMTP via STARTTLS — chiffre le saut entre deux serveurs de messagerie. Sa valeur est réelle : il empêche quelqu'un qui surveille le réseau de lire ton courrier en vol, et l'infrastructure moderne l'utilise presque partout.
Mais TLS est saut par saut, pas de bout en bout. Un message traverse en général plusieurs serveurs entre l'expéditeur et le destinataire, et à chaque saut il est déchiffré, traité, puis re-chiffré pour l'étape suivante. Cela signifie que chaque serveur de la chaîne — ton fournisseur, celui du destinataire et tout relais intermédiaire — manipule le message en clair. Le chiffrement de transport protège le message des inconnus sur le câble ; il ne fait rien pour le protéger des fournisseurs eux-mêmes.
Il y a un second piège : STARTTLS est opportuniste par défaut. Si le serveur récepteur n'annonce pas TLS, beaucoup d'expéditeurs basculeront silencieusement vers une remise en clair plutôt que d'échouer. Donc « nous utilisons TLS » ne garantit même pas qu'un message donné a été chiffré sur tout le chemin. Voilà pourquoi le chiffrement de transport, tout essentiel qu'il soit, est le plancher et non le plafond.
Le bout-en-bout : PGP vs S/MIME
Le chiffrement de bout en bout (E2EE) déplace le chiffrement aux extrémités. L'expéditeur chiffre le message avec la clé publique du destinataire ; seule la clé privée du destinataire peut le déchiffrer. Comme les serveurs intermédiaires ne détiennent jamais la clé privée, aucun ne peut lire le corps — ni ton fournisseur, ni un relais, ni le fournisseur du destinataire. C'est le même modèle à clé publique qui sous-tend les gestionnaires de mots de passe en CLI et la gestion des clés que nous couvrons pour les développeurs ; la différence porte sur qui gère la distribution des clés.
Deux standards dominent, et leur différence tient entièrement à la confiance et à la distribution des clés :
PGP (OpenPGP). Une « toile de confiance » décentralisée. Les utilisateurs génèrent leurs propres paires de clés et échangent directement leurs clés publiques, en les vérifiant hors bande (une empreinte au téléphone, une clé signée par un contact commun). C'est d'une souplesse maximale et n'exige aucune autorité centrale, mais la distribution des clés est manuelle, d'où la réputation de friction de PGP. C'est le standard chez les particuliers, les journalistes et les communautés open-source.
S/MIME. Les clés publiques sont liées à des identités par des certificats émis par une autorité de certification (AC) centrale. Cela simplifie grandement le déploiement dans une organisation gérée — le service informatique provisionne les certificats de façon centralisée — mais lie ta confiance à cette hiérarchie d'AC. S/MIME est le choix courant en entreprise et dans l'administration, où une PKI gérée existe déjà.
Les deux offrent la même garantie centrale : un message qu'aucun serveur intermédiaire ne peut lire, plus une signature numérique qui prouve l'expéditeur et l'absence d'altération. Le coût, dans les deux cas, c'est que le destinataire doit aussi participer. Tu ne peux pas envoyer de façon transparente un message E2EE à quelqu'un sans clé.
Le chiffrement à accès zéro du fournisseur
Il existe un troisième modèle qui contourne la douleur de la distribution des clés pour le cas courant d'une boîte privée : le chiffrement à accès zéro chez le fournisseur.
Ici, le fournisseur chiffre ta boîte stockée avec des clés dérivées de ton mot de passe, sur ton appareil, de sorte que le serveur ne stocke que du texte chiffré pour ton compte. Même le fournisseur ne peut pas lire le courrier au repos. Proton Mail en est l'implémentation la plus connue : les messages entre utilisateurs Proton sont chiffrés de bout en bout par défaut, et toute la boîte est conservée sous chiffrement à accès zéro, si bien que Proton lui-même ne peut pas la lire.
La limite honnête tient à la nature de l'e-mail. Quand un utilisateur Proton écrit à un utilisateur Gmail, le message ne peut pas être chiffré de bout en bout sauf si l'utilisateur Gmail a aussi PGP, parce que l'autre bout n'a pas de clé. Proton gère cela en te laissant envoyer un message protégé par mot de passe à un non-utilisateur : le destinataire l'ouvre via un lien et un mot de passe que tu partages séparément. C'est un vrai pont, mais il faut partager le mot de passe par un autre canal — la même contrainte fondamentale que PGP, emballée plus commodément.
Le chiffrement à accès zéro séduit parce qu'il te donne une boîte lisible, cherchable sur l'appareil, sans configuration, que le fournisseur ne peut quand même pas lire — sans forcer chaque correspondant à gérer des clés.
Le problème des métadonnées que tout le monde saute
C'est le point le plus important et le plus ignoré de toute discussion honnête sur l'e-mail chiffré : le chiffrement protège le contenu, pas les métadonnées.
Même avec un chiffrement de bout en bout impeccable, les éléments suivants circulent généralement en clair et peuvent être journalisés par ton fournisseur, celui du destinataire et le réseau :
- qui a envoyé le message et qui l'a reçu,
- l'horodatage,
- la taille du message,
- et, dans beaucoup d'implémentations, la ligne d'objet.
Donc le chiffrement répond à « qu'a dit le message », mais pas à « qui parle à qui, quand et à quelle fréquence ». Pour un modèle de menace où cacher tes contacts compte — pas seulement tes mots — le chiffrement du contenu seul ne suffit pas. Les fournisseurs qui minimisent la conservation des métadonnées, et les outils de couche réseau, traitent une autre partie du problème. Considère la limite des métadonnées comme un fait de conception de l'e-mail, pas un défaut d'un fournisseur particulier, et planifie en conséquence.
Où se situent vraiment les grands fournisseurs
| Fournisseur | En transit | Au repos | Bout-en-bout par défaut | Le fournisseur peut lire ton courrier |
|---|---|---|---|---|
| Gmail (grand public) | TLS | Oui (Google détient les clés) | Non | Oui |
| Outlook / Microsoft 365 (grand public) | TLS | Oui (Microsoft détient les clés) | Non | Oui |
| Gmail Workspace + CSE / S/MIME | TLS | Oui | Seulement si configuré | Réduit avec CSE |
| Proton Mail | TLS | Accès zéro (tu détiens les clés) | Oui, entre utilisateurs Proton | Non |
Le schéma est constant : les services grand public chiffrent en transit et au repos mais détiennent les clés, ils peuvent donc — et pour des fonctionnalités et des demandes légales, le font — lire le contenu. Atteindre le bout-en-bout sur Gmail ou Outlook est possible mais demande une configuration délibérée (S/MIME, ou chiffrement côté client sur des offres payantes précises). Proton Mail est conçu E2EE-et-accès-zéro par défaut, ce qui en fait le fournisseur le plus souvent cité quand « e-mail chiffré » désigne la couche 2 ou 3 plutôt que la couche 1.
Une note sur la vérification, dans l'esprit de la souveraineté des données : une affirmation de chiffrement que tu ne peux pas inspecter est une assertion, pas une garantie. Les clients open-source — Proton publie les siens — permettent à des examinateurs indépendants de confirmer que les clés sont générées sur ton appareil et que le texte en clair n'atteint jamais le serveur. Préfère les fournisseurs dont les affirmations sont vérifiables à ceux qui se contentent de les énoncer.
Un cadre de décision
Arrête de demander « quel e-mail est le plus chiffré » et demande plutôt « qui ne doit pas pouvoir lire ceci, et le destinataire est-il prêt à participer ? »
Le chiffrement de transport suffit quand le contenu est ordinaire et que ta seule crainte est un écoutant réseau. Tout fournisseur sérieux te le donne déjà ; il n'y a rien à configurer.
Utilise le bout-en-bout (PGP ou S/MIME) quand des messages précis doivent être illisibles par tout serveur du chemin et que le destinataire peut détenir une clé — un collègue, la source d'un journaliste, une organisation avec du S/MIME géré. Accepte l'étape d'échange de clés comme le prix de la garantie.
Utilise un fournisseur à accès zéro comme Proton Mail quand tu veux toute ta boîte illisible par le fournisseur sans forcer chaque correspondant à faire du PGP, avec un repli protégé par mot de passe pour le message chiffré occasionnel vers un externe.
Quoi que tu choisisses, retiens deux choses. D'abord, les métadonnées ne sont pas chiffrées — le chiffrement cache les mots, pas la relation. Ensuite, vérifie l'affirmation : préfère les clients open-source et une juridiction respectueuse de la vie privée pour que « on ne peut pas lire ton courrier » soit vérifiable plutôt que croyable.
Pour le volet stockage de la même panoplie privacy, vois notre guide du stockage cloud chiffré pour développeurs, et pour la question plus large de garder ses données hors des services soumis à la juridiction américaine, le pilier sur la souveraineté des données.
