Obfuscation des e-mails : quelle méthode reste efficace en 2026 ?

• Afin de protéger les adresses e-mail des collecteurs de spam, diverses techniques d’obfuscation HTML·CSS·JavaScript ont été testées et comparées selon leur taux de blocage
• Les tests menés sur 426 échantillons de texte et 399 échantillons de liens montrent que la plupart des techniques basées sur JS ainsi que celles en CSS et SVG atteignent 100 % de blocage
• Même des méthodes anciennes comme les entités HTML et l’encodage d’URL conservent une forte efficacité
• En revanche, l’affichage sous forme d’image, la substitution de symboles et l’inversion du sens du texte nuisent gravement à l’accessibilité et à l’usage
• En 2026, les approches jugées les plus sûres et les plus pratiques pour protéger une adresse e-mail sont les transformations JS, le chiffrement AES et les mécanismes d’interaction utilisateur

---

Comparatif des techniques d’obfuscation d’adresses e-mail (état en 2026)

• Présentation, avec statistiques à l’appui, de diverses techniques d’obfuscation destinées à masquer une adresse e-mail aux collecteurs de spam (harvesters), ainsi que de leur efficacité réelle
• Après avoir protégé chaque adresse e-mail selon une méthode différente, l’étude a mesuré si les harvesters y accédaient sur 426 échantillons (texte) et 399 échantillons (liens) afin d’en déduire le taux de blocage
• La plupart des techniques basées sur JavaScript ainsi que certaines approches en CSS·SVG ont obtenu un taux de blocage de 100 %
• Même des méthodes plus anciennes comme les entités HTML et l’encodage d’URL conservent un taux de blocage élevé
• Certaines techniques dégradent fortement l’accessibilité ou l’utilisabilité, ce qui les rend inadaptées à un usage réel

1. Techniques de protection d’un e-mail en texte brut

• Il s’agit d’afficher directement l’adresse e-mail sur la page tout en empêchant les harvesters de la lire grâce à différentes techniques HTML·CSS·JS
• L’efficacité peut être maximisée en combinant plusieurs techniques pour protéger chaque segment

• Aucune protection (No protection)

  • Taux de blocage : 0 % (0 blocage sur 426)
  • L’adresse e-mail est exposée telle quelle et collectée par tous les harvesters

• Entités HTML (HTML Entities)

  • Taux de blocage : 95 %
  • Des bibliothèques côté serveur la décodent automatiquement, mais dans les faits la plupart des harvesters sont bloqués

• Commentaires HTML (HTML Comments)

  • Taux de blocage : 99 %
  • Ne permet de bloquer que les harvesters les plus basiques, peu capables d’interpréter les balises HTML
  • Simple, mais conserve malgré tout une forte efficacité

• HTML SVG

  • Taux de blocage : 100 %
  • Masque l’adresse e-mail dans le texte interne d’un objet SVG
  • Accessible aux lecteurs d’écran pour personnes malvoyantes
  • L’utilisation de l’élément <object> est indispensable ; avec <img> ou du SVG inline, le code source risque d’exposer l’adresse
  • Dépend des polices, ce qui impose de spécifier une web font

• CSS display:none

  • Taux de blocage : 100 %
  • Exploite les limites des harvesters incapables d’appliquer les règles de style
  • Permet de préserver l’accessibilité ; l’usage de display:none est recommandé plutôt qu’un masquage purement visuel

• Concaténation de chaînes en JS (Concatenation)

  • Taux de blocage : 100 %
  • Facile à mettre en œuvre sans dépendance externe
  • Comme l’e-mail complet est présent dans le HTML, la sécurité reste faible

• JS Rot18

  • Taux de blocage : 100 %
  • Utilise un chiffrement par rotation de caractères similaire à ROT13
  • Les harvesters simples ne peuvent pas le décoder, mais la technique est vulnérable aux collecteurs qui ignorent JS

• Transformation JS (Conversion)

  • Taux de blocage : 100 %
  • Le HTML ne contient qu’une chaîne dépourvue de sens, qu’une fonction JS transforme en véritable adresse e-mail
  • La plupart des harvesters ne pouvant ni exécuter le DOM ni JS, la reconstruction est impossible
  • Une technique simple et très efficace

• Chiffrement AES en JS

  • Taux de blocage : 100 %
  • Protège l’adresse e-mail via un chiffrement AES-256
  • Utilise l’API SubtleCrypto du navigateur et ne fonctionne qu’en HTTPS
  • Le déchiffrement est impossible sans le fichier JS

• Interaction utilisateur en JS (User interaction)

  • Taux de blocage : 100 %
  • L’adresse e-mail n’est affichée que lorsque l’utilisateur interagit avec la page
  • Le harvester devrait exécuter le DOM et simuler des événements utilisateur, ce qui le rend pratiquement inopérant

• Substitution de symboles en HTML (Symbol substitution)

  • Taux de blocage : 96 %
  • Remplace certains caractères par “AT”, “DOT”, etc.
  • L’utilisateur doit corriger l’adresse manuellement, ce qui dégrade l’expérience d’usage

• Instructions HTML (Instructions)

  • Taux de blocage : 100 %
  • Ajoute à l’adresse des indications manuelles du type “remove the .fluff”
  • Seuls des humains ou des IA peuvent l’interpréter, mais la gêne pour l’utilisateur est importante

• Image HTML

  • Taux de blocage : 100 %
  • Affiche l’adresse e-mail sous forme d’image
  • Inaccessible aux personnes malvoyantes, impossible à copier, etc. : l’utilisabilité s’effondre

• CSS content

  • Taux de blocage : 100 %
  • Affiche l’adresse e-mail via le pseudo-élément ::after
  • Visible visuellement, mais impossible à copier, et reconstructible à partir du seul HTML
  • Considérée comme une technique sans intérêt réel

• Sens du texte en CSS (Text direction)

  • Taux de blocage : 100 %
  • Inverse la chaîne avec direction: rtl
  • Si le harvester ignore le CSS, l’adresse se décode facilement
  • Le texte est copié à l’envers, ce qui dégrade l’usage

2. Techniques de protection des liens cliquables

• Il s’agit de protéger l’attribut href d’un lien mailto:
• Si le texte du lien contient l’adresse e-mail, il faut aussi appliquer en parallèle une technique d’obfuscation du texte

• Aucune protection

  • Taux de blocage : 0 % (0 blocage sur 399)
  • Adresse e-mail entièrement exposée

• Entités HTML

  • Taux de blocage : 100 %
  • Malgré le décodage automatique côté serveur, la plupart des harvesters sont bloqués

• Encodage d’URL

  • Taux de blocage : 95 %
  • Le décodage est facile, mais dans les faits la plupart des harvesters sont bloqués

• Redirection HTTP

  • Taux de blocage : 100 %
  • Masque le lien mailto: en le faisant passer pour un lien classique
  • Configuration d’une redirection 302 ou 301 dans .htaccess
  • Utilisation de nofollow, noindex pour empêcher l’indexation par les moteurs de recherche
  • Le flag QSA est nécessaire si l’on veut préremplir automatiquement des champs d’e-mail

• HTML SVG

  • Taux de blocage : 100 %
  • Masque le lien e-mail à l’intérieur d’un SVG
  • Préserve l’accessibilité, avec obligation d’utiliser <object>
  • Une police doit être spécifiée

• Concaténation de chaînes en JS

  • Taux de blocage : 100 %
  • Peut être implémentée sans dépendance externe
  • Comme l’e-mail est directement inclus dans le HTML, ce n’est pas sûr

• JS Rot18

  • Taux de blocage : 99 %
  • Rotation de caractères similaire à ROT13
  • Les harvesters simples ne peuvent pas le décoder

• Transformation JS (Conversion)

  • Taux de blocage : 100 %
  • Le HTML ne contient qu’un faux lien, que JS transforme ensuite en véritable mailto:
  • Le harvester n’ayant accès qu’au HTML, la reconstruction est impossible
  • Une technique simple et très efficace

• Chiffrement AES en JS

  • Taux de blocage : 100 %
  • Lien e-mail chiffré en AES-256
  • Utilise l’API SubtleCrypto du navigateur et nécessite HTTPS

• Interaction utilisateur en JS

  • Taux de blocage : 100 %
  • Le lien n’est activé qu’après interaction de l’utilisateur avec la page
  • Il est difficile pour un harvester de reproduire ce comportement

3. Critiques et objections

• À l’argument selon lequel « les spammeurs n’explorent pas le web, ils achètent des bases de données fuitées »
  • Les adresses e-mail de cette page, bien qu’exposées uniquement ici, ont reçu des milliers de spams
• À l’argument selon lequel « il n’y a pas besoin de protection »
  • Les contenus populaires sont collectés de façon intensive ; si un contenu peut devenir viral, une protection est nécessaire
• À l’argument selon lequel « un filtre antispam suffit »
  • Ces techniques sont gratuites à mettre en œuvre sans faux positifs et gagnent à être utilisées en complément des filtres
• À l’argument selon lequel « une technique devient inutile une fois connue »
  • Les statistiques montrent que des techniques identiques restent efficaces depuis plusieurs décennies

4. Méthodologie de l’expérience

• Des adresses e-mail protégées par chaque technique d’obfuscation ont été réellement publiées pour servir de honeypots destinés aux harvesters
• Lorsqu’un spam arrivait, la technique de protection de l’adresse concernée était considérée comme compromise
• Les messages ont été regroupés par spammeur afin de produire des statistiques basées sur le nombre d’expéditeurs
• Afin que le filtrage antispam ne fausse pas les résultats, un serveur mail et un client ont été mis en place directement
• Comme les harvesters de texte et ceux de liens sont différents, les statistiques ont été séparées
• L’échantillon reste encore limité, mais la fiabilité statistique devrait progresser à mesure que le nombre de liens augmente

Conclusion

• Les techniques JS de transformation, de chiffrement et d’interaction utilisateur offrent le meilleur niveau de sécurité et d’accessibilité
• CSS display:none et les objets SVG obtiennent aussi d’excellents résultats en matière d’accessibilité et de blocage
• La substitution de symboles, les images et l’inversion du sens du texte sont déconseillées, car elles nuisent fortement à l’usage
• Lorsqu’il faut publier une adresse e-mail, une simple transformation JS ou un chiffrement AES constitue en 2026 le choix le plus efficace