Attaque de bots sur un formulaire : ce qui se passe vraiment et comment s’en proteger
Le 4 septembre au matin, notre administration WordPress ne répondait plus. Erreur 524, écran blanc, impossible de se connecter. Le site public, lui, tournait normalement. Un script automatisé pilonnait le formulaire de contact depuis plusieurs heures. Voici ce qui se passe concrètement dans ces cas-là, et les cinq couches de protection à poser dans le bon ordre.
Une attaque de formulaire ne ressemble pas à ce qu’on imagine
Il n’y a pas de piratage, pas de vol de données, pas de page défigurée. Un script remplit votre formulaire des centaines de fois par heure. Chaque soumission déclenche du code : validation des champs, écriture en base, tentative d’envoi de mail, parfois un appel à un service externe.
Un hébergement mutualisé dispose d’un nombre fixe de processus pour exécuter ce code. Quand ils sont tous occupés, plus rien ne s’exécute. Votre site public continue de s’afficher parce qu’il est servi depuis un cache, sans passer par ce code. C’est d’ailleurs le même cache qui divise par six notre temps de réponse serveur. Votre administration, elle, ne peut pas être mise en cache. Elle meurt la première.
C’est ce qui rend ces incidents difficiles à repérer : de l’extérieur, tout va bien. Le premier symptôme visible est presque toujours un administrateur qui n’arrive plus à se connecter.
Le phénomène n’a rien de marginal. Le Bad Bot Report 2025 d’Imperva établit que le trafic automatisé a dépassé le trafic humain pour la première fois en dix ans : 51 % du trafic web mondial, dont 37 % de bots malveillants, contre 32 % un an plus tôt. Le rapport attribue cette hausse aux grands modèles de langage, qui permettent aujourd’hui d’écrire un bot fonctionnel sans savoir programmer.
La première chose à faire n’est pas de bloquer une adresse IP
C’est pourtant le réflexe, et il ne sert souvent à rien. Si votre site passe par un service de protection type Cloudflare, votre serveur ne voit plus l’adresse du visiteur : il voit celle du proxy. Vous pouvez remplir votre fichier .htaccess de règles de blocage, elles s’appliqueront au réseau de distribution, pas à l’attaquant.
Le filtrage doit porter sur l’en-tête CF-Connecting-IP, en tête de fichier, pour intervenir avant que PHP ne démarre. Une règle qui bloque après le démarrage de PHP ne vous protège pas : le processus a déjà été consommé.
Et de toute façon, un bot sérieux change d’adresse toutes les vingt requêtes. Le blocage individuel est un pansement, pas une stratégie.
Les cinq couches, dans l’ordre où il faut les poser
L’ordre compte, parce que chaque couche coûte quelque chose. Les premières sont gratuites en ressources et invisibles pour vos visiteurs. Les dernières coûtent des processus serveur ou du confort d’utilisation.
1. Le champ piège
Un champ de formulaire masqué en CSS, que jamais aucun humain ne remplira. Si le champ arrive rempli, c’est un robot. Coût nul, aucune gêne pour le visiteur, et ça élimine la majorité des scripts les plus basiques. C’est la première chose à poser, toujours.
2. La vérification invisible
Turnstile chez Cloudflare, ou son équivalent chez Google. Le visiteur ne voit rien, ou coche une case au pire. Le contrôle se fait côté navigateur, avant que votre serveur ne soit sollicité. C’est la couche la plus rentable pour ce qu’elle coûte.
Attention à un piège d’installation : tant que la clé n’est pas renseignée et le module réellement activé, le composant est présent dans la page et ne fait rien. Nous avons eu ce cas exact. Installé, visible, inactif.
3. La limitation de débit au niveau du réseau de distribution
C’est la couche qui a réellement stoppé notre attaque. Elle s’applique avant votre serveur : au-delà de N soumissions par minute depuis une même adresse, la requête est rejetée sans jamais atteindre PHP. Les règles de limitation de débit documentées par Cloudflare permettent de cibler une URL précise.
Une subtilité qui nous a coûté un essai raté : sur WordPress, un formulaire de contact ne poste pas sur l’URL de la page. Il poste sur un point d’entrée de l’API, dont le chemin ne ressemble en rien à celui de la page visible. Une règle écrite sur l’URL exacte de la page ne verra jamais passer la moindre soumission. Il faut une condition qui couvre les deux, du type « le chemin contient /contact ».
4. Le filtre applicatif
Analyse du contenu du message, mots-clés interdits, nombre de liens, limite de soumissions par heure et par adresse. C’est utile, mais c’est la couche qui produit le plus de faux positifs, et elle s’exécute dans PHP, donc elle consomme ce que vous cherchez à préserver.
5. Le blocage manuel
En dernier recours, sur les plages d’adresses persistantes. Utile en pleine crise, à nettoyer une fois l’orage passé.
Les trois pièges qui font perdre des clients
Le mode observation qu’on oublie de basculer
Notre module antispam a passé onze mois à tout détecter et à tout laisser passer. Il avait été installé en mode journalisation, le temps de calibrer les règles, et personne n’avait noté la date de bascule. Le jour de l’attaque, il avait des centaines de lignes de journal et zéro blocage à son actif.
La règle à retenir : tout module de sécurité déployé en mode observation doit avoir sa date de bascule écrite quelque part, dans un calendrier ou dans un ticket. Pas dans la tête de celui qui l’a installé.
Le filtre qui bloque vos vrais prospects
Une fois le mode actif enclenché, on a commencé à recevoir des captures d’écran de visiteurs bloqués. Une de nos règles rejetait tout message de moins de 150 caractères ne contenant aucun mot du métier. Sauf que le champ message était facultatif. Un prospect qui laissait son nom, son numéro et « rappelez-moi » se retrouvait classé en spam par sa propre concision.
Il y a une logique générale derrière : chaque fois que vous ajoutez une couche en amont, relâchez les filtres applicatifs en aval. Une vérification invisible et une limitation de débit rendent inutiles les règles heuristiques agressives, qui ne servent plus qu’à écarter vos propres clients.
Pensez aussi à exempter les comptes administrateurs de ces filtres. Sinon vous ne pourrez pas tester votre propre formulaire, ou pire, vous le testerez en étant connecté et vous conclurez que tout fonctionne.
Le message d’erreur qu’on lit mal
Sur Contact Form 7, deux phrases se ressemblent et n’ont rien à voir. « Une erreur est survenue lors de l’envoi » signale un rejet antispam. « Un ou plusieurs champs contiennent une erreur » signale un échec de validation, souvent un jeton de sécurité périmé par le cache. Distinguer les deux fait gagner une demi-journée. Les quatre causes possibles d’un formulaire muet sont détaillées dans cet article.
Ce que dit la réglementation
Un point qu’on oublie souvent : un formulaire de contact collecte des données personnelles, ce qui place sa protection dans le champ du RGPD. L’article 32 du règlement, publié par la CNIL, impose des mesures techniques garantissant « la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes ».
La disponibilité est explicitement citée. Un site rendu inaccessible par une attaque qu’aucune protection n’a freinée n’est pas seulement un problème commercial.
Le plan en quatre points
| Quand | Action | Effet attendu |
|---|---|---|
| Aujourd’hui | Ajouter un champ piège au formulaire | Élimine les scripts les plus simples, coût nul |
| Cette semaine | Activer une vérification invisible, clé comprise | Filtre avant le serveur, invisible pour le visiteur |
| Cette semaine | Poser une limitation de débit couvrant l’URL de la page et le point d’entrée de l’API | Protège les processus serveur en cas de pic |
| Ensuite | Relâcher les filtres applicatifs et exempter les administrateurs | Supprime les faux positifs sur les vrais prospects |
« On avait installé le module de sécurité, on avait installé la vérification anti-robot. Les deux étaient là, dans le site, et aucun des deux n’était actif. Une protection qu’on n’a jamais vérifiée après installation, ce n’est pas une protection, c’est une ligne dans une liste de tâches. »
Comment vérifier que vos protections fonctionnent vraiment
Trois tests, quinze minutes, à refaire après chaque intervention sur le site.
- Soumettre le formulaire depuis une navigation privée, déconnecté de l’administration. Un compte administrateur contourne la plupart des filtres.
- Soumettre dix fois de suite. Si la onzième passe encore, votre limitation de débit ne couvre pas le bon chemin.
- Ouvrir le journal du module de sécurité et vérifier qu’il contient des blocages, pas seulement des détections. C’est la différence entre un module actif et un module qui regarde passer.
Notre site est resté debout parce que son cache statique servait les pages sans réveiller PHP. C’était de la chance, pas de la conception. Aujourd’hui les cinq couches sont en place, et la limitation de débit a rejeté l’attaque suivante sans que personne ne s’en aperçoive.
Vos protections sont-elles réellement actives ?
Champ piège, vérification invisible, limitation de débit, filtres applicatifs : on vérifie les cinq couches et on teste vos formulaires en conditions réelles. Rapport sous 48 heures ouvrées.
Sources et références
- Imperva (groupe Thales), 2025 Bad Bot Report, 2025.
- Cloudflare, Rate limiting rules, documentation officielle Cloudflare WAF.
- CNIL, Règlement européen sur la protection des données, chapitre IV, article 32 « Sécurité du traitement ».
Jean Fagnon est le fondateur de Kefa Global Network, agence web installée en France qui conçoit et maintient des sites pour des TPE, des PME et des cabinets libéraux. L’incident décrit dans cet article s’est produit sur le site de l’agence le 4 septembre 2026.
Publié le 5 septembre 2026.