Le protocole SMTP transmet les emails en clair depuis 1982. Malgré l’ajout progressif de TLS sur le transport, le contenu des messages reste lisible par chaque serveur intermédiaire. Cette faiblesse structurelle pousse aujourd’hui un nombre croissant de particuliers vers le chiffrement de bout en bout (E2E), longtemps réservé aux professionnels de la sécurité et aux journalistes.
JMAP, IMAP et limites du chiffrement de transport
Le chiffrement de transport (TLS entre serveurs SMTP/IMAP) protège le message en transit, pas au repos. Chaque relais MTA déchiffre puis rechiffre le contenu avant de le transmettre. Un fournisseur de messagerie, ou un attaquant qui compromet son infrastructure, accède au texte brut.
A découvrir également : Des failles critiques détectées dans certains routeurs domestiques
Avec la montée en puissance de JMAP comme successeur d’IMAP pour la synchronisation des boîtes, la couche transport gagne en efficacité, mais le problème fondamental reste identique. JMAP n’apporte aucun chiffrement E2E natif : il optimise la gestion des métadonnées et la synchronisation multi-appareils, sans toucher au contenu du message lui-même.
Nous observons que cette confusion entre chiffrement de transport et chiffrement de bout en bout persiste chez la majorité des utilisateurs. Beaucoup pensent que le cadenas affiché par leur client mail garantit la confidentialité totale du message. En réalité, il ne protège que le segment réseau entre leur appareil et le serveur.
Lire également : Les sauvegardes automatiques protègent contre la perte de données
Chiffrement PGP ou S/MIME : quel protocole pour un particulier
Deux standards dominent le chiffrement E2E des emails. Le choix entre les deux conditionne l’expérience utilisateur et la compatibilité avec les correspondants.
PGP et le modèle de confiance décentralisé
PGP (et son implémentation libre OpenPGP) repose sur un réseau de confiance : chaque utilisateur génère sa paire de clés et publie sa clé publique. Aucune autorité centrale ne valide l’identité. Ce modèle convient aux particuliers qui veulent garder le contrôle total, mais il impose de vérifier manuellement les empreintes de clés.
L’écosystème open source autour d’OpenPGP reste actif. Des clients comme Thunderbird intègrent désormais la gestion des clés OpenPGP sans extension tierce. La friction a diminué, mais elle n’a pas disparu : un correspondant qui n’a pas de clé PGP ne pourra pas lire le message chiffré.
S/MIME et la chaîne de certificats
S/MIME s’appuie sur des certificats X.509 délivrés par des autorités de certification. L’authentification de l’expéditeur est plus robuste, et la plupart des clients mail (Outlook, Apple Mail) gèrent S/MIME nativement. Le frein pour les particuliers reste le coût et la gestion du renouvellement des certificats, même si des autorités proposent des certificats gratuits pour un usage personnel.
- PGP : contrôle total de la clé, modèle décentralisé, mais nécessite que le correspondant utilise aussi PGP
- S/MIME : intégration native dans les clients courants, identité certifiée par un tiers, mais dépendance à une autorité de certification
- Les deux protocoles sont incompatibles entre eux : un message chiffré en PGP ne peut pas être lu par un destinataire configuré uniquement en S/MIME
Proton Mail et l’adoption grand public du chiffrement E2E
La croissance de Proton illustre un basculement. Le service revendique plus de 100 millions d’utilisateurs sur l’ensemble de sa suite (Mail, VPN, Drive). Tous ces comptes ne concernent pas exclusivement l’email, mais l’ordre de grandeur montre que le chiffrement E2E n’est plus un marché de niche.
Le modèle de Proton Mail supprime la friction technique qui freinait PGP. Le chiffrement E2E s’applique automatiquement entre comptes Proton. Pour les destinataires externes, l’expéditeur peut protéger le message par un mot de passe partagé, accessible via un lien sécurisé. Aucune gestion de clés côté destinataire.
Infomaniak propose une approche similaire : chiffrement activable en un clic depuis l’interface de rédaction, compatible avec n’importe quel fournisseur de messagerie. Ce type d’implémentation réduit la barrière d’entrée à quasi zéro pour l’expéditeur, même si le destinataire doit toujours effectuer une action (ouvrir un lien, saisir un mot de passe).
Nous recommandons aux particuliers qui échangent régulièrement des données sensibles (documents médicaux, pièces juridiques, informations fiscales) de privilégier un fournisseur avec E2E natif plutôt que de greffer PGP sur un service classique. Le gain en simplicité compense largement la perte de contrôle sur la gestion des clés.
Décisions RGPD récentes sur le chiffrement des emails
Le cadre réglementaire européen pousse aussi les particuliers à s’intéresser au chiffrement, indirectement. Deux décisions récentes illustrent la tension entre chiffrement de transport et chiffrement E2E au regard de l’article 32 du RGPD.
Un tribunal allemand (Tuta/cour allemande) a statué que l’absence de chiffrement E2E ouvre droit à indemnisation pour le client lorsque des données sensibles sont transmises par email sans protection suffisante. Cette décision établit un précédent : le simple TLS ne suffit pas quand le contenu est à risque élevé.
À l’inverse, le tribunal administratif de Düsseldorf (décision du 2 avril 2026) a reconnu qu’un chiffrement de transport correctement mis en oeuvre peut satisfaire l’article 32 du RGPD, à condition que l’organisation applique une approche proportionnée avec classification des données et E2E réservé aux cas à risque élevé.
- Pour les données de santé, juridiques ou financières : le chiffrement E2E devient un standard de fait, pas seulement une bonne pratique
- Pour les échanges courants : le chiffrement de transport (TLS) reste acceptable si le fournisseur applique des configurations à jour
- La charge de la preuve se déplace : en cas de fuite, c’est l’absence de chiffrement adapté au niveau de risque qui expose à des sanctions
Authentification et chiffrement : deux couches distinctes à ne pas confondre
Le chiffrement protège la confidentialité du contenu. L’authentification (SPF, DKIM, DMARC) protège l’identité de l’expéditeur. Les deux sont complémentaires, pas interchangeables.
Un email chiffré en PGP peut très bien être envoyé depuis un domaine sans DMARC. Le destinataire lit un message confidentiel, mais ne peut pas vérifier que l’expéditeur est légitime. À l’inverse, un email parfaitement authentifié par DMARC transite en clair si aucun chiffrement E2E n’est activé.
Un particulier soucieux de sécurité doit vérifier les deux couches : choisir un fournisseur qui applique DKIM et DMARC par défaut, et activer le chiffrement E2E pour les messages sensibles. La plupart des fournisseurs orientés vie privée combinent déjà ces deux aspects, ce qui simplifie la configuration.
Le chiffrement des emails par les particuliers ne relève plus de la paranoïa technique. Les outils existent, les interfaces se sont simplifiées, et la jurisprudence européenne commence à transformer la bonne pratique en obligation contextuelle. Le vrai défi reste l’interopérabilité : tant que l’ensemble des correspondants n’utilise pas un standard commun, le chiffrement E2E restera une démarche volontaire, appliquée message par message.
