Rate limit, files d'attente et antispam pour formulaires et bots

Rate limit, files d'attente et antispam sont trois couches de protection - sans elles, formulaires et bots Telegram/Discord deviennent vite un canal de spam, de flood et de DoS. Un CAPTCHA ne suffit pas : il faut limiter la fréquence, traiter en asynchrone et filtrer contenu et réputation. Ci-dessous - comment monter un schéma pratique pour sites et bots sans complexité inutile.

• Rate limit - combien de requêtes sont autorisées par fenêtre de temps depuis une IP, un compte ou un jeton
• File d'attente - tampon entre l'acceptation de la demande et le travail lourd (e-mail, CRM, LLM, webhook)
• Antispam - honeypot, CAPTCHA, heuristiques, listes noires et contrôle du contenu
• Règle - d'abord couper la fréquence et traiter en asynchrone, puis durcir les filtres
• Objectif - garder les leads réels et ne pas faire tomber le service sous un botnet

Pourquoi formulaires et bots sont attaqués en premier

Un endpoint public est une porte non verrouillée. Les bots de spam cherchent /contact, /api/lead et les webhooks du bot, puis envoient des milliers de messages : phishing, spam SEO, credential stuffing, force brute de codes promo. Sans limites, les factures e-mail/SMS/LLM montent, le CRM se remplit de déchets, les vrais leads se noient dans le bruit.

Symptômes typiques :

1. Pic de POST sur le formulaire avec zéro conversion commerciale
2. Textes identiques depuis des IP différentes - ou déchets uniques depuis une même plage
3. Files e-mail ou webhooks butent sur les plafonds du fournisseur
4. Le bot messagerie répond plus lentement ou tombe en timeout

Rate limit : quoi limiter et comment

Le rate limiting répond : « combien de fois en N secondes peut-on toucher cet endpoint ? ». La clé de limitation compte.

Fenêtres pratiques :

• Formulaire de leads : 3-5 envois réussis par IP toutes les 10 minutes, plus un plafond dur sur les échecs (validation, CAPTCHA fail)
• Login / OTP : séparé et plus strict - sinon force brute
• Commandes bot : 1 réponse lourde (génération, recherche) par utilisateur toutes les quelques secondes ; commandes légères - plus souple
• Plafond global sur processus ou worker - protège les pics même si les clés diffèrent

En dépassement : HTTP 429 avec Retry-After ; dans le bot - un court « attendez N secondes », sans révéler les seuils internes. Journalisez les déclenchements : ils montrent si la limite est trop souple ou trop dure.

Files d'attente : séparer réception et traitement

Le formulaire ne doit pas écrire synchrone dans le CRM, générer un PDF et appeler une API externe. Une file (Redis, RabbitMQ, SQS, Celery, BullMQ) prend la tâche après validation et répond vite : « demande acceptée ».

Ce que la file apporte :

• Lissage des pics - spam ou campagne ne fait pas tomber les processus web
• Retry en cas d'échec - retry avec backoff au lieu de perdre le lead
• Priorités - commandes payées au-dessus de « télécharger le PDF »
• Isolation - workers LLM/e-mail scalent à part du front

Flux formulaire :

1. CSRF / origin, honeypot, validation basique des champs
2. Rate limit
3. Enregistrer le lead en BDD avec statut queued
4. Push dans la file
5. HTTP 200/202 à l'utilisateur
6. Worker : scoring antispam → CRM / e-mail / notification

Idem pour les bots : accepter vite l'update Telegram ; réponses lourdes (RAG, image, parsing) dans la file. Sinon long polling / webhook accumule la latence.

Antispam : des couches, pas une case à cocher

Un reCAPTCHA ne clôt pas le sujet. Construisez une défense en profondeur.

1. Filtres peu coûteux à l'entrée

• Champ honeypot (caché aux humains, rempli par les bots)
• Temps minimal de remplissage (trop rapide = bot)
• Contrôle Referer / Origin et jeton CSRF
• Limite de taille du body et du nombre de pièces jointes

2. CAPTCHA et challenges

Affichez le challenge sur signal, pas toujours : après N tentatives, IP suspecte ou score élevé. CAPTCHA permanent nuit à la conversion ; ciblé presque pas.

3. Contenu et réputation

• Listes noires de domaines/URL dans le texte
• Détection de modèles répétés et de spam agnostique à la langue
• Contrôles e-mail (MX, domaines jetables)
• Pour les bots : filtre de liens, stop words, limite média

4. Signaux comportementaux

Historique : combien d'envois de cet appareil sont devenus achat ou chat utile. Nouvelle IP avec des dizaines de « buy seo » par minute - en quarantaine ou revue manuelle, pas direct dans le CRM du commercial.

Relier les trois couches

Ordre recommandé en production :

1. Validation et antispam peu coûteux (honeypot, taille, CSRF)
2. Rate limit par IP + id utilisateur/chat
3. Réponse rapide au client / messagerie
4. File avec plafond de jobs concurrents par worker
5. Antispam lourd et intégrations dans le worker (scoring, CRM, e-mail)
6. Alertes sur pics de 429 et croissance des jobs rejetés

Vous évitez ainsi de brûler CPU et budget fournisseurs sur des requêtes que la limite aurait déjà dû couper.

Checklist de mise en place

• [ ] Formulaire et bot ont des limites différentes selon le risque
• [ ] Circuit breaker global pour e-mail/SMS/LLM sortants
• [ ] 429 et messages bot sont clairs, sans indiquer comment contourner
• [ ] La file a une DLQ (dead letter) et un suivi de longueur
• [ ] Les leads suspects vont en quarantaine, pas en suppression silencieuse
• [ ] Logs rate limit et spam-score utiles sans PII complète
• [ ] Test de charge : que se passe-t-il à 100 RPS sur /contact

En résumé

Le rate limit coupe la fréquence, la file protège le backend et les budgets d'intégration, l'antispam sépare le bruit des leads. Ils ne marchent qu'ensemble : limite sans file fait tomber les handlers synchrones ; file sans filtres répand le spam dans le CRM ; filtres sans limite coûtent cher sous DDoS.

S'il faut concevoir la protection formulaires et bots pour votre stack (limites, file, quarantaine, monitoring) - contactez-moi. Repères support et évolutions - sur la page tarifs.

Questions fréquentes

En quoi le rate limit diffère-t-il de l'antispam ?

Le rate limit compte les tentatives ; l'antispam juge contenu et comportement. La limite stoppe le flood même avec des requêtes « propres » ; l'antispam attrape un spam rare mais toxique qui tient encore dans le quota.

Faut-il une file si le volume de leads est bas ?

Oui, s'il y a des API externes, de l'e-mail ou un LLM. Même à faible trafic, un timeout CRM synchrone casse l'UX du formulaire. La file est bon marché à vide et sauve au pic.

Le CAPTCHA est-il obligatoire sur chaque formulaire ?

Non. Préférez un challenge selon le risque : après séries d'erreurs, mauvaise réputation IP ou score anomal. Moins de gêne pour les humains, bots toujours coupés.

Sur un bot : limiter par chat_id ou par IP ?

Les deux. chat_id freine le flood d'un utilisateur ; IP/jeton webhook protège des updates falsifiés et du scanning. En groupe, les limites sont souvent plus dures qu'en privé.

Que faire des leads qui ressemblent à du spam ?

En quarantaine avec revue manuelle ou livraison différée, pas à la corbeille sans trace. Sinon vous perdez un lead légitime rare et ne voyez pas évoluer les motifs d'attaque.

Termes de l'article

webhooks — HTTP callbacks when events happen — rappels HTTP déclenchés par des événements

LLM — Large Language Model — grand modèle de langage

CRM — Customer Relationship Management — gestion de la relation client

PII — Personally Identifiable Information — informations personnelles identifiables

DDoS — Distributed Denial of Service — déni de service distribué