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 c'est important pour l'activité - moins de spam dans le CRM et la boîte mail, factures SMS/LLM/API plus basses, les ventes ne voient que de vrais leads

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
• [ ] Les logs rate limit et spam-score se consultent par IP/hash, endpoint et score sans accès complet aux données personnelles (noms, e-mails, téléphones, texte des demandes)
• [ ] Test de charge : que se passe-t-il à 100 RPS sur /contact

Quand il est trop tôt pour tout mettre en place

Chaque projet n'a pas besoin de tout le dispositif d'un coup :

• Site statique sans formulaire ni bot - rien à protéger, pas besoin de limites
• Moins de 10-20 leads par jour et sans API/LLM externes - un captcha plus une limite au niveau hébergement/CDN (Cloudflare, Nginx) suffit ; une file séparée ne se rentabilise pas encore
• MVP précoce - validez d'abord que le marché veut le produit, ajoutez antispam et file à mesure que le trafic et les premières attaques augmentent
• Protection managée déjà en place (Cloudflare, WAF, formulaire avec antispam intégré) - exploitez d'abord ses limites et filtres, ne dupliquez pas l'infrastructure depuis zéro

Si le trafic et le nombre d'intégrations augmentent, revenez au schéma complet ci-dessus.

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

CRM — Customer Relationship Management — gestion de la relation client

SMS — Short Message Service — service de messages courts

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

endpoint — specific API URL that accepts requests — URL d'API précise qui accepte les requêtes

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

rate limiting — enforcing a cap on requests per time window — application d'un plafond de requêtes par fenêtre de temps

timeout — max wait before aborting

worker — background job processor

backoff — growing wait between retries after failures — pause croissante entre retries après des échecs

retry — automatic repeat of a failed request or job — répétition automatique d'une requête ou tâche échouée

long polling — client waits on an open request until the server has news — le client garde la requête ouverte jusqu'à une nouvelle du serveur

CSRF — Cross-Site Request Forgery — falsification de requête intersites

production — live environment serving real users — environnement live avec de vrais utilisateurs

circuit breaker — switch that stops calling a failing dependency for a while — coupe-circuit: arrête d'appeler une dépendance en panne un moment

dead letter — queue for messages that failed processing repeatedly — file pour messages qui ont échoué plusieurs fois

CDN — Content Delivery Network — réseau de diffusion de contenu

MVP — Minimum Viable Product — produit minimum viable

backend — server-side logic, APIs and data layer — logique serveur, API et couche données

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