Chiffrement des e-mails : TLS, de bout en bout et RGPD

On compare souvent l'e-mail à une carte postale : quiconque lit en chemin voit tout. Le chiffrement des e-mails détermine si c'est vrai. Cet article décrit ce que permettent le chiffrement du transport et le chiffrement de bout en bout, ce que les tribunaux et les autorités de contrôle en ont dit et quelle technique fait la différence dans la pratique.

L'article tient compte de la jurisprudence, de la technique et des exigences des grands fournisseurs de messagerie jusqu'à fin octobre 2026.

La structure de l'article suit le parcours d'un e-mail. Viennent d'abord le critère juridique et les notions, puis la jurisprudence et le point de vue des autorités de contrôle. Ensuite, la technique : chiffrement du transport, lecture de l'en-tête du message, protection contre les expéditeurs falsifiés et méthodes de bout en bout comme S/MIME et OpenPGP. L'article se termine par une aide à la décision indiquant quel chiffrement convient à quel type d'e-mail.

Chiffrement des e-mails et RGPD : quel est le critère

Les données à caractère personnel doivent être traitées de manière à être protégées contre tout accès non autorisé. C'est ce que prévoit l'art. 5, par. 1, point f, du RGPD. Selon le paragraphe 2, le responsable du traitement doit aussi pouvoir le démontrer. La forme concrète de cette protection est régie par l'art. 32 du RGPD : il faut prendre des mesures conformes à l'état de la technique et adaptées au risque. La disposition ne prescrit aucun procédé déterminé. Le chiffrement n'y figure que comme mesure possible.

Les catégories particulières de données, comme les données de santé, relèvent de l'art. 9 du RGPD. Le besoin de protection y est d'emblée plus élevé. Mais même des e-mails en apparence anodins contiennent des données à caractère personnel : une adresse d'expéditeur avec le nom complet suffit déjà.

En 2026, la situation juridique se résume ainsi : il n'existe pas d'obligation générale de chiffrement de bout en bout pour chaque e-mail. Il n'existe pas non plus d'autorisation générale d'envoyer des e-mails non chiffrés. Ce qui compte, c'est le risque pour les personnes concernées et ce qui est raisonnablement exigible selon l'état de la technique. Quiconque envoie des données à caractère personnel par e-mail a donc besoin d'une décision motivée, que l'on peut présenter en cas de doute.

Chiffrement du transport, de bout en bout et signature : bien distinguer

Au quotidien, on mélange trois choses qui font des choses différentes.

Le chiffrement du transport sécurise la connexion entre deux stations. Il repose sur TLS (Transport Layer Security), le successeur de SSL. Sur chaque tronçon, le contenu est transmis chiffré. Sur le serveur de messagerie lui-même, en revanche, il est en clair, car le serveur doit traiter et stocker l'e-mail.

Le chiffrement de bout en bout (E2E) chiffre le contenu dès le logiciel de messagerie de l'expéditeur. Seul le destinataire peut le déchiffrer. Les serveurs intermédiaires ne voient que des données inexploitables. S/MIME et OpenPGP se sont imposés pour cela.

La signature est autre chose : elle ne chiffre rien, mais atteste de qui provient un e-mail et qu'il n'a pas été modifié en route. Elle joue un rôle important dans l'échange des clés, car les clés publiques se transmettent le plus souvent par des e-mails signés.

Les deux procédés ont une limite commune : l'objet, l'expéditeur et le destinataire restent en général lisibles. Le guide de la Conférence des autorités de protection des données (DSK) rappelle que ces circonstances de la communication peuvent elles aussi nécessiter une protection.

Jurisprudence sur le chiffrement des e-mails : quand le chiffrement du transport suffit

Les tribunaux ont tranché la question à plusieurs reprises ces dernières années, avec des résultats en apparence contradictoires. En y regardant de près, les décisions suivent une ligne : plus le dommage possible est grand, plus les exigences sont élevées.

Le plus ancien cas de la série date de 2020. Le tribunal administratif de Mayence a décidé le 17 décembre 2020 (n° 1 K 778/19.MZ) si un avocat peut envoyer à ses clients des e-mails protégés uniquement par un chiffrement du transport. La décision est analysée au regard des art. 32 et 5 du RGPD. Selon le principe énoncé, le chiffrement du transport suffit pour la communication par e-mail des avocats. Le bout en bout n'est donc nécessaire qu'en cas de risque accru, au cas par cas.

L'ordonnance de la Cour fédérale de justice du 22 mars 2021 (AnwZ (Brfg) 2/20) est elle aussi souvent citée, mais elle n'est pertinente que de façon limitée. Elle concerne la boîte aux lettres électronique spéciale des avocats, dont l'architecture de sécurité repose sur des modules de sécurité matériels propres. Il n'existe pas de droit au chiffrement de bout en bout dans ce cadre. Elle se transpose difficilement aux e-mails ordinaires.

L'affaire de la cour d'appel de Karlsruhe montre la ligne suivie dans les relations commerciales. Un pirate avait pris le contrôle de la messagerie d'un concessionnaire automobile et envoyé à l'acheteur une facture manipulée indiquant un autre numéro de compte. L'acheteur a payé sur le mauvais compte. Le 27 juillet 2023, la cour a jugé (n° 19 U 83/22) que les mesures de protection nécessaires dépendent des attentes légitimes de sécurité des partenaires commerciaux. Le paiement au fraudeur n'a pas libéré l'acheteur, qui a dû payer une seconde fois. Le tribunal régional de Mosbach avait statué différemment en première instance.

La cour d'appel de Schleswig est parvenue à un autre résultat en décembre 2024. Il s'agissait là aussi d'une facture manipulée, cette fois à l'égard d'un consommateur et pour environ 15 000 euros. Selon le communiqué de presse de la cour, la facture aurait dû être envoyée avec un chiffrement de bout en bout, car une attaque de pirate est un risque prévisible. Le client a pu opposer une créance de dommages et intérêts à la demande de paiement et n'a pas eu à payer de nouveau. La cour avait autorisé le pourvoi, mais selon son communiqué de presse, l'arrêt est néanmoins définitif. Une analyse de ces décisions, y compris d'un jugement du tribunal administratif de Düsseldorf du 2 avril 2026 (29 K 7351/23), figure dans l'article Sicherheitsvorkehrungen beim Versand von E-Mails.

Comment concilier tout cela ? Ce qui compte, semble-t-il, c'est le besoin de protection et le potentiel de dommage. Entre entreprises, les tribunaux ont jusqu'ici plutôt accepté des mesures standard. Lorsqu'un consommateur vire une somme élevée sur un compte que seul un e-mail non protégé lui a indiqué, on exige davantage. Le nom du procédé est secondaire. L'essentiel est que la mesure réduise réellement le risque concret. Reste ouverte, par exemple, la question de savoir si le consentement du destinataire à un chiffrement plus faible suffit. Il n'existe pour l'instant aucune décision fiable à ce sujet.

Guide de la DSK et BSI : le critère des autorités de contrôle

Le 27 mai 2021, la Conférence des autorités indépendantes de contrôle de la protection des données (DSK) a adopté le guide « Mesures de protection des données à caractère personnel lors de la transmission par e-mail », version du 16 juin 2021. La Bavière a voté contre. Le document est accessible publiquement (en allemand) et établit une distinction claire.

En cas de risque normal, le guide exige un chiffrement du transport obligatoire, fondé sur la directive technique TR-03108-1 du BSI. En cas de risque élevé, les responsables du traitement doivent employer régulièrement un chiffrement de bout en bout et un chiffrement du transport qualifié, c'est-à-dire par exemple avec DANE ou DNSSEC. Un secret professionnel est considéré comme un indice de risque élevé, à examiner au cas par cas.

Les amendes pour des e-mails non chiffrés sont rares, les autorités de contrôle agissent moins par des sanctions que par des documents comme celui-ci. Le guide n'en a pas moins du poids comme critère : dans les litiges sur les factures manipulées, on a débattu de la possibilité de s'appuyer sur les indications des autorités de contrôle. La cour d'appel de Karlsruhe les a jugées sans objet dans l'affaire qu'elle traitait. Le guide n'est pas contraignant. Quiconque s'en écarte devrait toutefois pouvoir le justifier.

Dans la TR-03108, le BSI décrit le transport sécurisé des e-mails pour les fournisseurs, certification comprise. Pour les exploitants de serveurs de messagerie, c'est la référence technique. La TR-03182 y ajoute une recommandation sur l'authentification des e-mails.

Bien mettre en œuvre le chiffrement du transport : TLS 1.3, port 465, MTA-STS et DANE

Les logiciels de messagerie et les serveurs parlent plusieurs protocoles. SMTP (Simple Mail Transfer Protocol) est utilisé depuis 1982 et transmet les e-mails. ESMTP en est la variante étendue. Les abréviations dans l'en-tête montrent ce qui s'est passé sur chaque tronçon : ESMTPS signifie que TLS a été négocié. ESMTPSA signifie en plus que l'expéditeur s'est authentifié avec un nom d'utilisateur et un mot de passe.

La négociation peut se faire de deux façons. Avec le TLS implicite, la connexion est chiffrée dès le départ. Pour l'envoi depuis le logiciel de messagerie, le RFC 8314 prévoit le port 465, et pour la récupération IMAP sur le port 993 ou POP3 sur le port 995. Avec STARTTLS, la connexion démarre sans chiffrement et les deux parties négocient ensuite seulement le passage au chiffrement. Cette étape peut être perturbée par des attaquants. L'étude « Why TLS is better without STARTTLS » (USENIX Security 2021) décrit des attaques par rétrogradation et par injection. Le TLS implicite est donc considéré comme le meilleur choix, même si le port 587 avec STARTTLS reste souvent proposé en parallèle.

Quant aux versions : TLS 1.0 et 1.1 sont officiellement obsolètes depuis le RFC 8996 (mars 2021). TLS 1.2 est le minimum, TLS 1.3 l'objectif, comme le prévoit aussi la directive technique BSI TR-02102-2.

Un problème subsiste entre les serveurs. Le chiffrement y passe le plus souvent par STARTTLS et n'est souvent qu'opportuniste : si la négociation échoue, la connexion retombe en clair. De nombreux serveurs de messagerie proposent un mode qui refuse la remise lorsqu'aucun TLS n'est établi. Cela passe lui aussi en général par STARTTLS et n'est pas un TLS implicite.

Deux procédés comblent cette lacune :

• MTA-STS (RFC 8461) : le domaine du destinataire publie une politique selon laquelle TLS avec un certificat valide est obligatoire. Les serveurs émetteurs s'y conforment. DNSSEC n'est pas nécessaire. Il existe les modes testing et enforce. Les rapports sur les problèmes sont fournis par TLS-RPT.
• DANE : dans le DNS, un enregistrement TLSA définit quel certificat le serveur du destinataire utilise. Cela suppose DNSSEC. DANE garantit l'authenticité du serveur destinataire contre la rétrogradation et l'attaque de l'homme du milieu.

Pour Exchange Online, selon Microsoft, le SMTP entrant avec DANE est généralement disponible depuis le 22 octobre 2024, mais désactivé par défaut. MTA-STS est pris en charge selon la documentation de Microsoft. Des outils en ligne permettent de vérifier si son propre domaine publie de telles politiques, plus de détails dans la section suivante.

Vérifier le chiffrement : lire l'en-tête et tester le serveur destinataire

Si un e-mail est bien arrivé chiffré, c'est indiqué dans l'en-tête du message. Dans les versions classiques d'Outlook, on double-clique sur le message, puis Fichier, Propriétés, champ En-têtes Internet. Dans le nouvel Outlook et dans la messagerie web, le chemin est différent. La navigation dans les menus change selon les versions, il vaut donc la peine de consulter l'aide du logiciel concerné.

Dans les en-têtes, ce sont les lignes Received qui intéressent. Chaque serveur qui transmet le message en ajoute une. Les serveurs modernes y inscrivent la version du protocole et le procédé, par exemple TLSv1.3 et TLS_AES_256_GCM_SHA384. L'extrait ci-dessous est reconstitué, avec des espaces réservés à la place des vraies adresses.

L'en-tête n'est toutefois pas une preuve sans faille au sens de l'art. 5, par. 2. Il ne prouve que les tronçons sur lesquels un serveur a ajouté la ligne. Là où interviennent des redirections ou des passerelles, une lacune subsiste. Il reste néanmoins utile comme élément d'une documentation.

Avant l'envoi, on peut tester ce que sait faire un serveur destinataire. CheckTLS interroge ses capacités sans envoyer d'e-mail et indique notamment si TLS est proposé et s'il existe un enregistrement TLSA pour DANE. Le résultat « no TLSA » est courant pour de nombreux domaines. Le service internet.nl vérifie STARTTLS, DANE ainsi que SPF, DKIM et DMARC. Selon la documentation, MTA-STS ne fait pas partie de l'évaluation.

Si le résultat TLS est négatif, il est utile d'en informer le destinataire. On peut aussi envisager un portail ou une pièce jointe chiffrée, nous y revenons plus bas. Pour son propre site web et ses mesures de protection, le contrôle RGPD de sites web offre une première orientation. Des contrôles de sécurité pour les domaines, y compris l'authentification des e-mails, se trouvent dans les Web Security Checks.

SPF, DKIM et DMARC : protection contre les expéditeurs falsifiés

Le chiffrement protège contre l'espionnage, pas contre la falsification. C'est justement de cela qu'il s'agissait dans les affaires de factures : un attaquant envoie un e-mail qui semble provenir du véritable expéditeur, ou utilise une messagerie détournée. Trois procédés complémentaires aident contre les expéditeurs falsifiés.

La pression en faveur de leur adoption est venue récemment des grands fournisseurs. Depuis le 1er février 2024, Google et Yahoo exigent de tous les expéditeurs notamment SPF ou DKIM, TLS et un faible taux de spam. Quiconque envoie plus de 5 000 e-mails par jour à des adresses Gmail a besoin de SPF, DKIM et d'au moins une politique DMARC. Microsoft a introduit des exigences similaires pour les expéditeurs à gros volume vers Outlook.com, Hotmail et Live à partir du 5 mai 2025. Les règles détaillées figurent dans la documentation de Google.

Le guide de la DSK prévoit que DKIM et DMARC soient vérifiés à la réception. Une évolution se dessine ici, que les responsables du traitement ont intérêt à ne pas ignorer. Des informations complémentaires sur les messages falsifiés figurent dans l'article E-Mails, Phishing und die Echtheit elektronischer Nachrichten. La gestion des expéditeurs et pièces jointes inconnus et du spam fait l'objet d'un article distinct.

Bout en bout avec S/MIME et OpenPGP : état des lieux 2026

Quiconque veut ou doit aller au-delà du chiffrement du transport dispose de deux procédés établis. Les deux chiffrent le contenu dans le logiciel de messagerie. Les deux nécessitent des clés échangées au préalable. Le guide de la DSK qualifie le bout en bout de « protection la plus efficace », car il protège aussi les données au repos.

S/MIME

S/MIME fonctionne avec des certificats délivrés par une autorité de certification. Ils sont directement utilisables dans Outlook, Apple Mail et de nombreux autres logiciels. L'expéditeur obtient la clé publique du destinataire le plus souvent par un e-mail signé, dont le certificat peut être repris.

Beaucoup de choses ont changé pour les certificats depuis 2021. Les anciennes classes 1 à 4 sont dépassées. Depuis le 1er septembre 2023 s'appliquent les Baseline Requirements du CA/Browser Forum, avec quatre types qui se distinguent par l'étendue de la vérification : Mailbox-, Organization-, Sponsor- et Individual-validated. Le forum publie lui-même l'état actuel des exigences.

OpenPGP

OpenPGP fonctionne sans autorité de certification centrale. Chacun génère sa propre paire de clés. L'authenticité est vérifiée par des empreintes ou par la certification de tiers. La DSK souligne expressément que la simple publication d'une clé sur un serveur de clés n'est pas un indice de son authenticité. Le Web Key Directory, par lequel un domaine met lui-même ses clés à disposition, est pratique. Une introduction à la signature est proposée par l'article E-Mails mit PGP signieren und verschicken.

La norme a évolué : le RFC 9580 (juillet 2024) remplace le RFC 4880. Il apporte de nouveaux formats de clés, des procédés modernes comme X25519 et Ed25519 ainsi que le chiffrement authentifié. Parallèlement, le projet GnuPG entretient avec LibrePGP une branche divergente. Cela complique la situation. Thunderbird utilise une bibliothèque propre appelée RNP au lieu de GnuPG, et Mozilla documente des problèmes avec des clés présentant des caractéristiques que RNP ne prend pas en charge. Les clés ne circulent donc pas toujours sans accroc entre les logiciels.

En pratique avec Outlook et Thunderbird

En pratique, on constate souvent une différence entre l'usage avec un seul compte et avec plusieurs comptes. Le plug-in GpgOL du paquet Gpg4win peut être configuré dans Outlook et fonctionne avec un seul compte. Avec plusieurs comptes, en revanche, une invite s'affiche à chaque envoi et l'attribution des clés peut se brouiller. Pour les environnements comptant beaucoup de comptes, c'est un obstacle.

Gpg4win est actuellement disponible en version 5.1.1 (publiée le 23 septembre 2026), comme le montre la page du projet. GpgOL fonctionne dans Outlook classique. Selon un message du forum GnuPG, la question de savoir si et quand il prendra en charge le nouvel Outlook reste ouverte. Dans Thunderbird, OpenPGP est intégré depuis la version 78, aucun programme complémentaire n'est nécessaire. La configuration se fait dans les paramètres du compte, sous Chiffrement de bout en bout. Avec un seul compte, on y parvient rapidement.

En décembre 2025, le BSI a examiné douze logiciels de messagerie gratuits. Selon le communiqué de presse, les logiciels diffèrent dans leur prise en charge du chiffrement de bout en bout. Les fonctions de sécurité ne sont souvent pas actives d'origine.

Un aspect secondaire est l'attaque Efail de 2018. Elle exploitait des contenus HTML actifs dans les e-mails pour exfiltrer des textes déchiffrés. Comme contre-mesure, on recommande des logiciels à jour et un affichage HTML désactivé pour les e-mails chiffrés. Une explication est proposée par le site efail.de. Il n'y a pas lieu de céder à la panique, mais l'exemple montre qu'une bonne cryptographie peut aussi échouer à cause de sa mise en œuvre.

Portails, passerelles et chiffrement Microsoft comme alternatives

Le plus grand obstacle au bout en bout est l'échange de clés avec chaque interlocuteur. C'est pourquoi de nombreuses organisations misent sur des solutions où l'effort incombe à l'expéditeur.

• Chiffrement par passerelle : un serveur de l'entreprise prend en charge S/MIME ou PGP. La protection va alors jusqu'à la passerelle du destinataire. Dans la boîte aux lettres, le message se trouve, selon la configuration, déchiffré. La question de la confiance se déplace vers l'exploitant de la passerelle.
• Portail : l'e-mail ne contient qu'une notification. Le message est récupéré dans le navigateur après une connexion. Le guide de la DSK cite lui aussi un portail web comme voie de communication à l'égard des personnes concernées.
• Microsoft Purview Message Encryption : utilisable dans le nouvel Outlook avec la licence adéquate. Les destinataires extérieurs à Microsoft reçoivent une procédure d'ouverture. Elle ne peut pas être combinée avec S/MIME sur le même message.
• Pièce jointe protégée par mot de passe : une archive en AES-256, créée par exemple avec 7-Zip, sert d'enveloppe. Le mot de passe est transmis par un autre canal, par exemple par téléphone (changement de média). Le SMS est un canal controversé et ne devrait être utilisé qu'avec réserve.

Quiconque exploite une passerelle ou un portail auprès d'un prestataire conclut en général pour cela un contrat de sous-traitance au titre de l'art. 28 du RGPD. Les risques liés à Microsoft 365 pour le compte lui-même sont décrits dans l'article sur le token spraying.

L'arbitrage est sobre : qui redoute la gestion des clés obtient avec un portail ou une passerelle un compromis praticable. Il comporte des concessions par rapport à un véritable chiffrement de bout en bout, mais il vaut nettement mieux qu'un e-mail en clair au contenu sensible.

Cryptographie post-quantique pour l'e-mail : ce qui compte déjà aujourd'hui

Le bout en bout a une propriété souvent négligée : il n'offre pas de Perfect Forward Secrecy de lui-même. La DSK écrit à ce sujet que des e-mails interceptés peuvent être conservés puis déchiffrés plus tard en cas de divulgation de la clé privée. Avec les futurs ordinateurs quantiques, ce scénario pourrait se produire même sans perte de clé.

La normalisation est en cours. Avec le RFC 9936 (mars 2026), il existe une norme pour ML-KEM dans CMS, base de S/MIME. Pour TLS 1.3, la BSI TR-02102-2 prévoit des procédés hybrides combinant cryptographie classique et post-quantique. Il n'en découle aucune obligation d'agir au quotidien. Quiconque envoie des contenus qui devront rester confidentiels dans quinze ans devrait toutefois garder le sujet à l'œil.

Erreur d'envoi, violation de données et télécopie : les limites du chiffrement

Un inconvénient du chiffrement du transport vaut encore aujourd'hui : en cas d'adresse de destinataire erronée, il ne sert à rien. L'e-mail arrive chiffré sur le mauvais serveur et y est en clair. Avec le bout en bout, il en va autrement, à condition que le message ait été adressé au destinataire prévu. La DSK cite expressément l'adressage individuel comme mesure.

C'est pourquoi la part organisationnelle compte. Elle comprend la désactivation de la saisie semi-automatique pour les destinataires sensibles, un principe des quatre yeux pour les contenus délicats et la vérification de l'adresse avant l'envoi. La question de savoir si une erreur d'envoi doit être notifiée comme violation de données dépend du risque et relève d'une procédure distincte.

La télécopie apparaît elle aussi dans ce débat. Le Délégué régional à la protection des données et à la liberté d'information de Brême a comparé le fax aux e-mails non chiffrés sur une page consacrée aux guides. Dans une ordonnance de 2020 (11 LA 104/19), la cour administrative supérieure de Lunebourg a estimé qu'un examen au cas par cas était nécessaire pour les données particulièrement sensibles.

Quel chiffrement pour quel e-mail : aide à la décision

Des jugements et des lignes directrices, on peut tirer une règle empirique. Plus le potentiel de dommage et le besoin de confidentialité sont élevés, plus le bout en bout ou un portail entrent en considération. Pour les factures, une règle s'ajoute : toute modification des coordonnées bancaires se confirme par un second canal, par exemple par téléphone.

Le tableau sert d'orientation et ne constitue pas un conseil juridique. L'évaluation du risque incombe au responsable du traitement et doit être documentée. Un bref examen y aide : quel serait le pire dommage réaliste pour les personnes concernées ? Quelle en est la probabilité ? Quelle mesure le réduit sensiblement ?

Conclusion

Le chiffrement du transport est le minimum obligatoire et, en cas de risque normal, il est le plus souvent suffisant selon la DSK et la jurisprudence, s'il est mis en place de façon systématique et conforme à l'état de la technique. Cela comprend TLS 1.2 ou mieux 1.3, le TLS implicite dans le logiciel de messagerie ainsi que MTA-STS ou DANE côté serveur. En cas de risque élevé, on attend du bout en bout ou une solution équivalente.

Le chiffrement des e-mails reste un sujet d'arbitrages. La gestion des clés est pénible, les portails sont un compromis pragmatique, et contre la fraude, SPF, DKIM, DMARC ainsi qu'un second canal pour les données de paiement aident au moins autant que la cryptographie.