Voici une vérité inconfortable : cet « e‑mail sécurisé » que vous venez d’envoyer a probablement voyagé sur Internet sous une forme qu’un attaquant suffisamment motivé pourrait lire. Pas parce que le chiffrement n’existe pas, mais parce que l’écosystème e‑mail comporte des couches de chiffrement qui protègent des choses différentes — et la plupart des gens ne comprennent pas quelle couche protège quoi.
Quand on parle de chiffrement des e‑mails, on parle en réalité de trois technologies distinctes qui résolvent trois problèmes distincts. Les confondre mène à une fausse confiance ou à une paranoïa inutile. Démêlons tout ça.
TLS: chiffrer le trajet
Transport Layer Security — TLS — est le chiffrement que vous obtenez par défaut avec la plupart des e‑mails modernes. Quand votre e‑mail passe de votre serveur de messagerie à celui du destinataire, TLS chiffre cette connexion. Quiconque intercepte le trafic ne voit que du charabia.
C’est la même technologie que le cadenas dans la barre d’adresse de votre navigateur. Elle est bien comprise, largement déployée et presque invisible. Quand vous envoyez un e‑mail via Gmail, Outlook ou tout service de messagerie réputé, TLS protège très probablement la connexion.
Mais TLS a une limitation critique : il ne chiffre que les données en transit. Une fois votre e‑mail arrivé sur le serveur du destinataire, il est déchiffré et stocké en texte clair (ou chifré avec les clés du serveur, auxquelles l’opérateur du serveur a accès). Si quelqu’un compromet le serveur de messagerie, ou si l’opérateur du serveur est contraint de remettre des données, TLS n’offre aucune protection.
Il y a une autre subtilité : TLS est négocié entre serveurs, et il n’est pas toujours garanti. Si le serveur du destinataire ne prend pas en charge TLS, ou s’il y a un problème de configuration, l’e‑mail peut revenir à une transmission non chiffrée. La plupart des grands fournisseurs exigent désormais TLS, mais ce n’est pas universel. Le rapport de transparence de Google montre qu’environ 10 % des e‑mails sortants de Gmail vont encore vers des serveurs qui ne prennent pas en charge le chiffrement.
Pour la plupart des e‑mails professionnels, TLS est suffisant. Il protège contre l’écoute passive — quelqu’un qui « branche une sonde » sur le fil entre les serveurs. Il ne protège pas contre des serveurs compromis, des demandes légales de données, ou des attaquants sophistiqués capables d’intercepter et de modifier le trafic.
S/MIME: le standard de l’entreprise
S/MIME — Secure/Multipurpose Internet Mail Extensions — chiffre le message e‑mail lui‑même, pas seulement la connexion. L’e‑mail est chiffré sur votre appareil avant de partir, et seul l’appareil du destinataire peut le déchiffrer. Les serveurs de messagerie intermédiaires ne voient que du contenu chiffré.
S/MIME utilise la même infrastructure de certificats que HTTPS. Vous obtenez un certificat auprès d’une autorité de certification, qui contient votre clé publique et vérifie votre identité. Quand quelqu’un veut vous envoyer un e‑mail chiffré, il utilise votre clé publique pour le chiffrer. Seule votre clé privée — qui ne quitte jamais votre appareil — peut le déchiffrer.
Le monde de l’entreprise adore S/MIME parce qu’il s’intègre aux infrastructures d’identité existantes. Si votre entreprise utilise déjà des certificats pour l’accès VPN ou la signature de code, étendre cela au chiffrement des e‑mails est relativement simple. Outlook prend en charge S/MIME nativement, tout comme la plupart des clients de messagerie d’entreprise.
Mais S/MIME a des frictions. L’expéditeur et le destinataire ont besoin de certificats. Il faut échanger des clés publiques avant de pouvoir communiquer en toute sécurité. La gestion des certificats est pénible — les certificats expirent, sont révoqués et doivent être sauvegardés. Si vous perdez votre clé privée, tout e‑mail chiffré pour cette clé est perdu à jamais.
Il y a aussi la question de la confiance. Les certificats S/MIME proviennent d’autorités de certification, ce qui signifie que vous faites confiance à ces AC pour vérifier correctement les identités et protéger leur infrastructure. Des attaquants étatiques ont déjà compromis des AC. Pour la plupart des modèles de menace, cela reste acceptable, mais ce n’est pas une sécurité de bout en bout au sens paranoïaque.
PGP: le choix cypherpunk
PGP — Pretty Good Privacy — est antérieur à S/MIME et adopte une approche philosophique différente. Au lieu de s’appuyer sur des autorités de certification, PGP utilise une « toile de confiance » où les utilisateurs vérifient directement les clés des uns et des autres. Il n’y a pas d’autorité centrale qui décide qui est qui.
La cryptographie est similaire à S/MIME : chiffrement à clé publique où seule la clé privée du destinataire peut déchiffrer le message. Mais la gestion des clés est radicalement différente. Vous générez vos propres clés, publiez votre clé publique sur des serveurs de clés ou votre site web, et vérifiez les clés des autres via une communication directe ou en faisant confiance à des personnes qui les ont déjà vérifiées.
PGP est populaire parmi les journalistes, les activistes et les chercheurs en sécurité — des personnes qui ont des raisons de se méfier des autorités centralisées. Il est aussi notoirement difficile à utiliser correctement. La gestion des clés est manuelle et sujette aux erreurs. Les outils ont historiquement été peu conviviales. Des études ont montré que même des utilisateurs techniques commettent des erreurs qui compromettent leur sécurité.
Le modèle de toile de confiance semble élégant mais passe mal à l’échelle. En pratique, la plupart des utilisateurs PGP vérifient soit les clés par des canaux secondaires (rencontre en personne, appel pour confirmer les empreintes), soit font confiance aux clés trouvées en ligne — ce qui annule une grande partie du bénéfice de sécurité.
Un débat continu existe dans la communauté sécurité sur la pertinence de PGP. Le protocole est ancien, les implémentations sont complexes et les problèmes d’ergonomie n’ont jamais été résolus. Certains soutiennent que des alternatives modernes comme Signal (pour la messagerie) offrent une meilleure sécurité avec moins de frictions. Mais pour l’e‑mail spécifiquement, PGP reste le standard du chiffrement de bout en bout en dehors de l’entreprise.
Choisir le bon chiffrement
Alors, quel chiffrement utiliser ? Cela dépend de ce contre quoi vous voulez vous protéger.
Pour les e‑mails professionnels généraux, TLS est probablement suffisant. C’est automatique, quasi universel, et cela protège contre les menaces les plus courantes. Assurez‑vous que votre fournisseur de messagerie impose TLS et envisagez d’activer MTA‑STS pour prévenir les attaques de rétrogradation.
Pour les secteurs réglementés ou les communications internes sensibles, S/MIME a du sens. L’infrastructure de certificats s’intègre à la gestion des identités en entreprise, et les principaux clients de messagerie le prennent en charge nativement. La surcharge de gestion des certificats est justifiée par les bénéfices de conformité et de sécurité.
Pour des communications vraiment sensibles où vous ne faites pas confiance à l’infrastructure — lanceurs d’alerte, journalisme, activisme — PGP ou une plateforme de messagerie sécurisée dédiée est approprié. Mais soyez réalistes quant aux défis d’ergonomie et à l’opsec nécessaire pour l’utiliser efficacement.
Note importante : le chiffrement protège le contenu, pas les métadonnées. Même avec PGP ou S/MIME, des observateurs peuvent voir qui envoie des e‑mails à qui, quand et à quelle fréquence. Pour certains modèles de menace, ces métadonnées sont aussi sensibles que le contenu. Si c’est votre situation, l’e‑mail n’est peut‑être pas l’outil adapté, quel que soit le chiffrement.
Frequently asked questions
Gmail est-il chifré ?
Gmail utilise TLS pour la transmission et chiffre les e‑mails stockés avec les clés de Google. Cela protège contre des attaquants externes mais pas contre Google lui‑même ni contre des demandes légales. Pour un chiffrement de bout en bout où Google ne peut pas lire votre e‑mail, il faudrait ajouter S/MIME ou PGP.
Puis-je utiliser S/MIME et PGP ensemble ?
Techniquement oui, mais c’est rarement nécessaire. Ils résolvent le même problème avec des modèles de confiance différents. Choisissez l’un des deux en fonction de votre environnement et de votre modèle de menace.
Pourquoi si peu de personnes utilisent le chiffrement des e‑mails ?
L’ergonomie. S/MIME et PGP nécessitent une configuration, une gestion des clés et une coordination avec les destinataires. Pour la plupart des gens, la friction dépasse le bénéfice perçu. TLS offre une sécurité « suffisamment bonne » pour les cas d’usage typiques.
Et les services d’e-mail chiffrés comme ProtonMail ?
Les services comme ProtonMail chiffrent votre boîte aux lettres avec des clés dérivées de votre mot de passe, de sorte que même eux ne peuvent pas lire vos e‑mails stockés. Les e‑mails entre utilisateurs ProtonMail sont chiffrés de bout en bout. Les e‑mails vers des utilisateurs externes peuvent être chiffrés avec un mot de passe ou reviennent à TLS.