Si votre adresse apparaît en clair dans le HTML du site, considérez qu’elle sera collectée. Les astuces de masquage comme name [at] domain ralentissent les robots les plus simples et gênent tous les humains. La vraie solution : ne pas publier d’adresse collectable. Utilisez un formulaire avec un champ piège et, si vous publiez une adresse, choisissez-en une dédiée au projet que vous pouvez retirer, plutôt que votre messagerie personnelle.

Comment les adresses sont collectées

Les collecteurs d’adresses sont de simples robots. Ils récupèrent les pages comme un moteur de recherche, puis utilisent des expressions régulières sur le HTML pour trouver tout ce qui ressemble à [email protected]. Ils n’ont pas besoin d’être sophistiqués : la plupart des sites leur donnent exactement ce qu’ils cherchent, un mailto: un lien. La collecte est alors très facile : l’adresse figure dans un href, dans un format standardisé, sur un attribut que les robots analysent déjà. Difficile de concevoir une meilleure balise.

On sous-estime souvent la suite. Une adresse collectée n’est pas spammée une seule fois : elle rejoint des listes vendues, fusionnées et revendues. Une fuite vieille de plusieurs années produit encore du spam. Impossible de l’annuler : il reste le filtrage strict ou l’abandon de l’adresse.

Pour être précis : un site tout neuf sans lien entrant peut attendre avant d’être exploré. Mais toute page liée sera visitée, et une seule visite d’un collecteur suffit.

Les astuces classiques et pourquoi elles échouent

Masquage du texte: écriture de name [at] domain [dot] com. Cette pratique existe depuis des décennies, et les collecteurs disposent d’expressions régulières pour les variantes courantes : [at], (at), AT, les espaces supplémentaires, tout y passe. Pendant ce temps, chaque visiteur doit reconstituer votre adresse à la main en espérant ne pas se tromper. Vous imposez une contrainte à tout le monde pour un filtre qui ne bloque que les robots les plus rudimentaires.

Encodage JavaScript: reconstituer l’adresse à l’exécution à partir de fragments encodés. C’est plus efficace : un collecteur qui ne récupère que le HTML brut ne voit rien. Mais les navigateurs sans interface coûtent peu aujourd’hui, et les collecteurs avancés affichent les pages avant de les analyser. L’encodage en entités HTML (he…) est encore pire : tous les analyseurs normalisent les entités avant de chercher, donc cela ne bloque rien. Et les contraintes sont pour vous : l’adresse ne fonctionne plus si JavaScript est désactivé et, selon l’implémentation, le copier-coller et les lecteurs d’écran ne fonctionnent plus non plus.

Une image de votre adresse: le pire compromis des trois. Les lecteurs d’écran n’obtiennent rien (et ajouter l’adresse en texte alternatif annule l’intérêt). Personne ne peut la copier. Le rendu est médiocre sur les écrans haute résolution. Et l’OCR coûte assez peu pour que les collecteurs déterminés lisent aussi les images.

Le point commun : le masquage est une course où l’attaquant change une ligne d’expression régulière tandis que vous dégradez l’expérience de tous les visiteurs légitimes. Cela ralentit la collecte sans l’arrêter. Et n’aide pas si l’adresse fuit ailleurs : commit git, newsletter ou carnet d’adresses tiers.

Ce qui fonctionne vraiment

Deux actions complémentaires.

1. Un formulaire de contact avec un champ piège

Un formulaire ne met aucune adresse dans votre HTML : il n’y a donc rien à collecter. Les envois arrivent dans une boîte via un point de réception. Les formulaires attirent leur propre spam (des robots qui remplissent tout formulaire trouvé), et la parade efficace la moins coûteuse est un honeypot: un champ caché que les humains ne voient jamais. Certains robots remplissent tous les champs ; un envoi contenant ce champ rempli est alors ignoré. Les robots plus avancés peuvent l’éviter, donc les contrôles de contenu côté serveur, la détection de campagnes et la vérification automatique restent actifs.

<form action="https://mailcontact.app/api/forms/your-form-id" method="POST" data-mailcontact-form>
  <label>Name <input name="name" autocomplete="name" /></label>
  <label>Email <input name="email" type="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
  <p data-contact-status role="status" aria-live="polite"></p>
</form>
<script defer src="https://mailcontact.app/forms/v1.js"
  crossorigin="anonymous" referrerpolicy="no-referrer"></script>

de mailcontact point de réception de formulaire accepte du FormData ou du JSON de toute origine, et répond en JSON. Le script injecte le contrôle caché, gère la vérification, garde le visiteur sur la page et conserve le brouillon en cas d’erreur. Les formulaires Free affichent un lien visible « Traité par mailcontact.app » ; Pro et Plus non. Les contrôles sont décrits dans le documentation antispam.

2. Une adresse dédiée par projet

Certains préfèrent écrire depuis leur messagerie, transférer un fil ou garder une copie dans les éléments envoyés. Très bien. Ne donnez simplement pas votre adresse personnelle. Chaque projet mailcontact dispose de son propre adresse [email protected] qui fonctionne immédiatement, sans enregistrement DNS ni serveur mail à gérer.

L’enjeu est de limiter l’impact. Une adresse de projet collectée envoie le spam dans cette seule boîte, pas celle de votre banque. Comme elle est remplaçable, retirez-la pour une nouvelle. La vraie solution n’est pas de la rendre illisible, mais de ne plus avoir à la protéger à tout prix.

La configuration pratique

  • Faites du formulaire votre canal principal, avec le champ piège activé. Pour aller plus vite, le générateur de formulaire de contact génère le HTML pour vous, et des guides par technologie couvrent sites statiques et GitHub Pages, où publier son adresse dans le HTML semble souvent être la seule solution.
  • Publiez l’adresse du projet en clair pour ceux qui préfèrent l’email. Oui, en clair : cette adresse peut être remplacée.
  • Les deux sources alimentent la même boîte de projet, avec notifications sur Discord ou par email, sans consulter sans cesse un tableau de bord.
  • Votre adresse personnelle n’apparaît jamais dans le HTML.

Cela ne supprime pas tout spam. Les champs pièges bloquent les robots simples, pas les personnes payées pour remplir les formulaires, et une adresse publiée finira par recevoir des indésirables. La différence est la maîtrise : changez une adresse de projet ou renforcez un formulaire au lieu de subir dix ans de spam sur une adresse impossible à changer.

Si vous créez un formulaire sur un site statique, ce guide présente les options.