Trois cent douze soumissions du formulaire de réservation, entre deux heures et quatre heures du matin, sur une seule nuit. Un hôtel indépendant d’une trentaine de chambres, dont le formulaire recevait en temps normal une dizaine de demandes par jour réparties sur les heures d’ouverture, a découvert ce chiffre en consultant les notifications email envoyées par son plugin de réservation, saturé de messages sans contenu cohérent.
Ce type de saturation n’a que rarement une intention réelle de réservation derrière elle. Elle relève le plus souvent d’un test automatisé de formulaire, mené par un script qui explore le web à la recherche de points d’injection, de failles d’envoi d’email, ou simplement d’un relais pour envoyer du spam via le serveur de messagerie de l’hôtel. Ce n’est pas la protection anti-spam générique des commentaires ou des formulaires de contact, déjà largement documentée ailleurs : c’est un problème propre aux formulaires de réservation, qui déclenchent souvent une action métier (blocage provisoire d’une chambre, envoi d’un email de confirmation) même sur une soumission invalide.
Identifier ce qui distingue un bot d’un client qui hésite
Le premier réflexe erroné consiste à ajouter un CAPTCHA visuel agressif dès la première case du formulaire. Cela dégrade l’expérience des vrais clients, en particulier sur mobile, sans nécessairement arrêter un bot bien conçu. Mieux vaut observer ce qui distingue réellement une soumission automatisée : le temps de remplissage (un bot soumet en moins d’une seconde après le chargement de la page), l’absence totale de mouvement de souris ou de focus clavier enregistré côté JavaScript, et la présence de champs remplis alors qu’ils devraient rester vides pour un humain.
Mettre en place un champ honeypot invisible
La technique la plus simple à déployer reste un champ honeypot : un champ de formulaire caché visuellement (via CSS, jamais via display:none trop facilement détecté par les scripts, plutôt en le positionnant hors écran), que seul un remplissage automatisé viendra compléter :
<p style="position:absolute;left:-9999px;">
<label for="site_web">Ne pas remplir</label>
<input type="text" name="site_web" id="site_web" tabindex="-1" autocomplete="off">
</p>Côté traitement PHP, toute soumission où ce champ contient une valeur est silencieusement rejetée, sans message d’erreur qui renseignerait le script sur la raison du rejet :
if ( ! empty( $_POST['site_web'] ) ) {
wp_die( '', '', array( 'response' => 200 ) );
}Ajouter une vérification de délai minimal
En complément, un horodatage placé dans un champ caché au chargement du formulaire, comparé au moment de la soumission, permet de rejeter toute réservation envoyée en moins de trois secondes, un délai physiquement impossible à respecter pour un humain qui lit réellement les champs proposés.
Surveiller le taux de complétion plutôt que le seul volume
Un indicateur souvent négligé : le taux de formulaires abandonnés en cours de remplissage. Une automatisation bien conçue peut parfois contourner le honeypot ; elle laissera en revanche des traces différentes dans le taux de complétion réel des champs, notamment sur les champs qui nécessitent une interaction JavaScript (sélecteur de dates, calcul du prix affiché dynamiquement).
Ce que cela a changé concrètement pour cet hôtel
Après la mise en place du honeypot et du délai minimal, le volume nocturne est retombé à zéro dès la nuit suivante, sans qu’aucun client légitime n’ait signalé de difficulté à soumettre sa demande. Le gain n’était pas seulement en confort : chaque soumission déclenchait un envoi d’email via le service de messagerie transactionnelle de l’hôtel, facturé au volume, et ces trois cents messages nocturnes représentaient un coût direct et récurrent s’il n’était pas traité.
Un formulaire de réservation qui déclenche une action métier réelle (blocage de stock, envoi d’email) mérite une protection plus stricte qu’un simple formulaire de contact : le coût d’une soumission invalide n’y est pas nul.
En résumé
Le remplissage automatisé d’un formulaire de réservation se détecte par des signaux comportementaux simples : rapidité anormale, absence d’interaction, champs qui ne devraient jamais être remplis. Un honeypot combiné à un délai minimal règle la grande majorité des cas, sans imposer de friction visible aux clients réels.
