# Spam massif sur les formulaires d’inscription et de contact > Les formulaires fonctionnent parfaitement, c’est bien le problème : des centaines de faux comptes, de messages de contact ou d’avis générés par des bots arrivent sans qu’aucun humain n’ait rempli quoi que ce soit. C’est l’inverse d’un formulaire qui ne s’envoie pas, et ça se traite différemment. - Source canonique : [https://allaux.fr/wordpress-woocommerce/problemes/spam-formulaires-inscriptions](https://allaux.fr/wordpress-woocommerce/problemes/spam-formulaires-inscriptions) - Langue : FR - Dernière mise à jour : 2026-08-03 ## Réponse directe > Regardez d’abord d’où viennent les soumissions dans les journaux d’accès du serveur : quelques adresses IP se bloquent au pare-feu, un réseau distribué non. Ajoutez ensuite un champ honeypot au formulaire, invisible pour un humain et rempli par la plupart des robots. Si l’inscription publique ne vous sert pas, décochez-la dans WooCommerce > Réglages > Comptes et confidentialité. ## Comment je procède 1. **Identification du point d’entrée** — Je regarde quel formulaire est visé : inscription sur /mon-compte/, contact, avis produit, ou tentatives sur xmlrpc.php, car chacun appelle une réponse différente. 2. **Mesure du volume et de l’origine** — Je vérifie dans les logs si les soumissions viennent d’un petit nombre d’adresses IP, un ciblage, ou de milliers d’adresses différentes, un réseau de bots distribué, ce qui change la réponse à apporter. 3. **Mise en place d’un filtre invisible** — J’ajoute un champ honeypot, invisible pour un visiteur humain mais rempli automatiquement par la plupart des bots, ce qui permet de rejeter silencieusement leur soumission sans CAPTCHA visible. 4. **Ajout de reCAPTCHA v3 si nécessaire** — Pour un volume plus important, j’ajoute Google reCAPTCHA v3, basé sur un score de comportement, sans challenge visible pour un visiteur légitime. 5. **Fermeture des points d’entrée inutiles** — Je limite ou désactive xmlrpc.php s’il n’est pas utilisé, et je désactive l’inscription publique côté WooCommerce si le guest checkout couvre déjà le besoin réel. ## Ce que je traite régulièrement - Des dizaines de faux comptes créés chaque jour sur /mon-compte/ - La boîte mail de contact reçoit des centaines de messages de spam - Des avis produit avec des liens suspects apparaissent en attente de modération - Des tentatives de connexion répétées sur wp-login.php ou xmlrpc.php visibles dans les logs - Le formulaire fonctionne normalement pour un vrai client, le problème n’est pas technique mais volumique ## Pourquoi un formulaire WordPress attire les bots Les points d’entrée par défaut de WordPress — inscription, commentaires, formulaire de contact — n’ont aucune protection anti-bot native. Un bot n’a besoin que de trouver l’URL du formulaire et d’y envoyer une requête POST directement, en contournant n’importe quel CAPTCHA visuel qui ne serait pas réellement vérifié côté serveur. Sur une boutique WooCommerce, l’option « Autoriser les clients à créer un compte pendant la commande » associée à une page /mon-compte/ publique est une cible fréquente des bots spécialisés dans la création de comptes en masse. Un autre point d’entrée souvent oublié est xmlrpc.php, une ancienne API WordPress régulièrement exploitée pour des tentatives de connexion par force brute ou du spam de pingback, distincte des formulaires visibles mais tout aussi exposée. Les mitigations réelles, à peu près par ordre d’effort : un champ honeypot invisible que seuls les bots remplissent, Google reCAPTCHA v3 qui note le comportement sans challenge visible pour un humain, une limitation du nombre de requêtes par adresse IP, et enfin la désactivation pure et simple de l’inscription publique si le guest checkout couvre déjà le besoin réel des clients. ## Un formulaire spammé n’est pas un site piraté > Ajouter un honeypot ou reCAPTCHA sur les formulaires existants se fait en quelques heures, c’est de la configuration. Si le volume de requêtes est massif et ciblé, avec des tentatives de connexion insistantes, ça peut relever d’une attaque plus large nécessitant une limitation au niveau serveur, plus proche d’un problème de sécurité que de spam de formulaire. ## Pages liées - **Site WordPress piraté** — Quand le volume de requêtes dépasse le spam de formulaire et ressemble à une attaque ciblée. ([/wordpress-woocommerce/site-pirate](/wordpress-woocommerce/site-pirate)) - **Extension sur mesure** — Ajouter un filtre honeypot ou une vérification reCAPTCHA sur mesure aux formulaires existants. ([/wordpress-woocommerce/extension-sur-mesure](/wordpress-woocommerce/extension-sur-mesure)) - **Maintenance WordPress** — Un suivi régulier permet de repérer un pic de spam avant qu’il ne s’aggrave. ([/services/maintenance](/services/maintenance)) ## FAQ ### Comment savoir si mes formulaires reçoivent du spam automatisé ou de vrais visiteurs malintentionnés ? Le volume et le motif temporel des soumissions parlent d’eux-mêmes : un afflux régulier, à toute heure, avec des adresses e-mail générées de façon similaire, est presque toujours un bot plutôt que des personnes. ### Le CAPTCHA que j’ai déjà installé ne sert à rien, pourquoi ? Souvent parce qu’il n’est vérifié que côté visuel, sans validation côté serveur de la réponse envoyée : un bot qui poste directement sur l’URL du formulaire n’a jamais besoin de le voir. ### xmlrpc.php, je ne sais même pas ce que c’est, dois-je m’en inquiéter ? C’est une ancienne API de WordPress, distincte de vos formulaires visibles, régulièrement ciblée par des tentatives de connexion automatisées. Je vérifie si elle est utilisée par une extension avant de la limiter ou de la désactiver. ### Est-ce que bloquer les bots va gêner mes vrais clients à l’inscription ? Un honeypot est invisible pour un visiteur humain, et reCAPTCHA v3 ne demande aucune action pour un comportement jugé normal : les deux sont conçus pour ne pas ajouter de friction à un vrai client. ### Faut-il vraiment désactiver l’inscription publique sur ma boutique ? Seulement si le guest checkout couvre déjà le besoin réel de vos clients. Sinon, je préfère filtrer les créations de compte plutôt que fermer complètement la fonctionnalité.