Guide · 5 min de lecture
Bloquer le spam sur un formulaire public
Mis à jour 2026-09-17
En bref
Combinez une vérification qui filtre les bots sans énigme pour les humains, une limitation de débit qui plafonne la vitesse d'envoi d'une source, et des champs obligatoires qui compliquent les réponses envoyées à l'aveugle.
Tout formulaire avec un lien public finit par attirer des bots, non pas parce qu'il est populaire, mais parce que les bots envoient à n'importe quelle URL de formulaire trouvée, de façon automatisée et non ciblée. La solution n'est pas de forcer les humains à prouver qu'ils le sont avec une énigme laborieuse — c'est une approche en couches : une vérification légère qui tourne de façon invisible pour la plupart des gens, une limite sur la vitesse d'envoi d'une source, et une validation qui fait plus facilement échouer un envoi scripté à l'aveugle. Ce guide couvre ce qui fonctionne vraiment et ce qu'il faut éviter.
Vérification anti-spam en arrière-plan
Les services anti-spam modernes font tourner une vérification en arrière-plan — en examinant les signaux du navigateur et le comportement — et n'affichent une énigme visible qu'au trafic qui semble suspect. La plupart des vrais visiteurs ne voient jamais rien du tout, ce qui est tout l'intérêt : un filtrage anti-spam qui ajoute de la friction aux répondants légitimes ne fait qu'échanger un problème contre un autre.
C'est un compromis nettement meilleur qu'un CAPTCHA à l'ancienne qui interrompt chaque envoi, puisqu'il ne demande une confirmation qu'au trafic qui semble réellement automatisé.
Limitation de débit
Une limitation de débit plafonne le nombre d'envois pouvant venir d'une source dans une fenêtre donnée, ce qui émousse le schéma de bot le plus courant : un script qui envoie le même formulaire à répétition aussi vite que possible. Elle n'exige pas que le bot paraisse suspect au préalable — elle arrête simplement le volume.
Les limites de débit doivent être assez généreuses pour qu'une vraie personne remplissant un formulaire quelques fois (en le testant, ou une famille envoyant séparément depuis une même connexion) ne les remarque jamais, et assez strictes pour qu'un flot scripté soit rapidement coupé.
Les champs obligatoires comme filtre
Marquer comme obligatoires les champs dont vous avez réellement besoin joue un double rôle : cela garde vos données de réponse exploitables, et cela relève la barre pour un bot qui envoie à l'aveugle sans inspecter la structure du formulaire. Un envoi auquel il manque des données obligatoires est rejeté avant même d'atteindre votre liste de réponses.
Ce n'est pas une défense principale à elle seule, mais superposée à une vérification et une limitation de débit, elle ferme la porte aux envois scriptés les plus grossiers qui ne prennent pas la peine de remplir un contenu réel.
Ce qu'il faut éviter
Résistez à l'envie d'ajouter une question de sécurité visible ou une énigme mathématique évidente à chaque formulaire — cela filtre les bots peu sophistiqués mais frustre aussi les vrais répondants, et un opérateur de bot déterminé s'y adapte de toute façon. Une vérification en arrière-plan qui n'escalade que pour le trafic suspect obtient le même filtrage sans cette taxe sur les vraies personnes.
Résistez aussi au réflexe de verrouiller un formulaire derrière un mot de passe pour arrêter le spam. Les mots de passe servent à restreindre qui peut voir le formulaire, pas contre le spam — utilisez-les quand vous voulez vraiment limiter l'accès à un groupe connu, pas comme mesure anti-bot pour un formulaire public.
Comment YeetForm gère cela
Dans YeetForm, les envois de formulaires publics sont vérifiés via Cloudflare Turnstile (une vérification en arrière-plan, pas une énigme visible pour la plupart des visiteurs) et limités en débit côté serveur, en plus des champs que vous avez marqués obligatoires. Turnstile se désactive automatiquement en développement local ou dans tout environnement où il n'est pas configuré, donc les tests ne sont pas bloqués.