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

[GN⁺]

Commentaires sur Hacker News

• Avant, je faisais attention au scraping d’emails, mais maintenant je laisse simplement mon adresse affichée sur mon site web
  Le filtrage du spam est suffisamment bon
  Cela dit, cette revue des techniques était intéressante. J’ai été surpris de voir que des méthodes simples restent assez efficaces

  • Depuis le début des années 2000, j’affiche mon email en clair sur mon blog avec un lien mailto: et je ne reçois que quelques spams par jour
    C’est peut-être parce que le filtrage de Zoho fonctionne bien, mais je ne pense pas qu’il soit particulièrement meilleur que les grands services
  • Les bots de collecte ont déjà récupéré des millions d’adresses pour la plupart, donc ils ne se soucient pas de quelques emails rares
    Du coup, on peut utiliser sa propre méthode simple, mais si on la publie, elle risque d’être neutralisée immédiatement
  • Depuis que j’ai mis mon email sur le site web de mon entreprise, je reçois plus de 1 500 spams par mois
  • J’ai fait pareil en publiant mon email, mais si des méthodes simples comme les entités HTML ou display:none peuvent en bloquer plus de 90 %, cela vaut peut-être le coup d’y réfléchir à nouveau
  • Je pense qu’un email finit de toute façon par fuiter. En revanche, le spam basé sur les LLM a de plus en plus de chances de contourner les filtres

• Mon email apparaît en clair plus de 90 fois dans les commits d’un dépôt open source populaire sur GitHub
  Pourtant, je n’ai presque jamais reçu de spam en 8 ans
  Le format entouré de < et > perturbe peut-être les collecteurs
  Aujourd’hui, il semble que l’achat de listes d’emails soit plus courant que la collecte directe

  • J’ai configuré des adresses wildcard sur mon domaine
    Je reçois souvent du spam vers des adresses comme git@, contact@, admin@
    Récemment, j’ai même reçu des emails usurpant le PDG sur une fausse adresse comme finance@
    Ironiquement, l’email affiché en clair sur mon profil HN ne reçoit presque pas de spam

• Mon hypothèse, c’est que les collecteurs d’emails ne parsèrent pas le HTML et se contentent de chercher les chaînes autour du caractère @
  Parser du HTML coûte cher, donc cette approche simple peut être efficace
  C’est probablement pour cela que les entités HTML fonctionnent

  • Les collecteurs ont peut-être appris que le spam envoyé à des adresses obfusquées a un faible taux de réponse
    Ils les ignorent donc peut-être complètement
  • Oui, la plupart font juste une recherche simple dans les octets, mais côté marketing black hat, il existe diverses techniques de scraping
  • Au final, tout dépend du degré d’acharnement de l’adversaire. Un attaquant irrationnel s’accrochera jusqu’au bout
  • L’extraction par jetons autour de @ fonctionne aussi très bien avec quelques variantes mineures

• L’article est bien écrit, mais je regrette qu’il ne mentionne pas la méthode qui consiste à posséder tout un domaine pour donner un email unique à chaque destinataire
  Quand du spam arrive, il suffit de bloquer cette adresse
  Ou alors on peut carrément vivre sans email. Aujourd’hui, les emails temporaires suffisent pour la plupart des usages

  • J’utilise aussi ce système depuis 20 ans
    Mais la plupart des spams viennent du fait que des amis ou des membres de ma famille partagent mon adresse avec des apps
    Pour les emails publics, une simple méthode de liaison JavaScript suffisait à bloquer 100 % des collectes
  • J’avais essayé autrefois de générer un email unique pour chaque personne, mais j’ai fini par simplifier vers une adresse unique basée sur une liste blanche
    L’effet est similaire et c’est bien plus simple à gérer

• Il existe une méthode qui consiste à cacher sur le site web une adresse email tarpit
  Elle est masquée en CSS, donc invisible pour les humains, et si un bot envoie un mail dessus, son IP est bloquée pendant 24 heures

  • Mais cela risque aussi de bloquer des serveurs mail majeurs comme Google
    Comme il y a aussi du spam provenant de comptes Gmail, les effets de bord sont importants
  • Dans un esprit similaire, il y a Project Honey Pot

• Le contenu est bon, mais je pense que le titre « Email address obfuscation » serait plus approprié
  Cela dit, ce genre d’article peut aussi apprendre des choses aux spammers

  • Employer “email” à la place de “email address” prête à confusion. Selon le contexte, on lit souvent cela comme « message électronique »
  • La façon dont le contact est affiché sur le site de Greg Egan était tellement obscure qu’il était impossible à déchiffrer

• Je me suis demandé si des formulations comme “me at foobar dot com” étaient encore efficaces, alors j’ai fait un test
  En utilisant un LLM pour décoder plusieurs méthodes d’obfuscation d’emails, j’ai constaté que presque tout ce qui n’était pas basé sur du CSS ou du JS restait interprétable
  Malgré cela, aujourd’hui les filtres anti-spam fonctionnent bien, donc publier son email en clair ne pose pas vraiment de gros problème
  Au contraire, ce sont surtout les emails de notification de services qui sont pénibles

  • Une meilleure méthode consisterait à faire utiliser un peu de CPU au visiteur pour générer un email à jeton unique
    En cas d’abus, il suffirait de jeter cette adresse
    L’idéal serait que le client et le serveur mail prennent en charge une telle API
  • Les collecteurs basés sur des LLM pourraient être meilleurs que les humains pour interpréter des consignes
    C’est pourquoi une obfuscation basique qui bloque les bots simples à base de regex reste encore utile
  • Il y a aussi la BD liée xkcd 1808

• En début d’année, je fabriquais un interpréteur Brainfuck en C et j’ai essayé de l’utiliser pour l’obfuscation d’emails
  Chaque email était stocké comme un programme Brainfuck, puis un interpréteur JS l’exécutait pour afficher le texte en clair
  Le JS était chargé depuis un domaine externe et, après vérification du referer, envoyait le vrai code
  Bien sûr, c’est inutile contre les collecteurs qui exécutent déjà du JS, mais c’était une expérience d’obfuscation créative assez amusante

  • Je me demande en quoi cette méthode diffère vraiment d’un simple chiffrement XOR en JS
  • Si un collecteur envoie une capture d’écran à un LLM ou à un OCR, cette méthode sera probablement neutralisée

• Cet article ressemble aussi un peu à un guide pour rendre les collecteurs d’emails plus intelligents

  • Oui, mais l’exécution de JS ou de CSS, le rendu SVG, etc. restent des opérations coûteuses, donc cela pèse encore sur les bots à grande échelle