Un formulaire de contact en panne a une signature discrète : la page s’affiche, le visiteur remplit, et rien n’arrive. Pas de 500 forcément, pas de site « down ». Les demandes sont perdues jusqu’à ce qu’un client le dise, ou jusqu’à ce qu’on compare le nombre de messages à celui de la semaine précédente. Le contrôle sert à voir la casse sans attendre ce coup de fil, et sans transformer la surveillance en source de faux leads.
Deux niveaux suffisent. Le premier tourne souvent. Le second est rare et n’entre pas dans le pipeline commercial.
Niveau 1 : la page contient encore le formulaire
Interrogez l’URL du formulaire depuis l’extérieur. Attendez un code 200 sur l’URL finale, après redirections. Puis cherchez dans le HTML un repère stable : la balise form, le name d’un champ que vous avez choisi, ou l’action du formulaire. Si ce repère disparaît, la page « marche » peut-être encore, mais plus personne ne peut écrire.
| Contrôle | Fréquence indicative | Il détecte |
|---|---|---|
| Code 200 de la page | Toutes les 5 minutes si la page est critique | Page cassée, redirection vers une erreur |
| Formulaire présent dans le HTML | Le même contrôle | Modèle vidé, plugin désactivé, mauvais noindex de page |
| Envoi de test | Une fois par jour, ou quelques fois par semaine | E-mail, CRM ou plugin d’envoi cassé |
| Captcha ou script seul | Pas en boucle automatique | À regarder quand le niveau 1 est vert et que les messages réels manquent |
Ce niveau ne clique pas sur « Envoyer ». Il ne crée pas de fiche dans le CRM. Il rate cependant le cas le plus sournois : le HTML est là, et l’envoi échoue. C’est le rôle du second niveau, pas une raison d’envoyer un POST chaque minute.
Le test d’URL aide à caler le premier niveau : code, redirection, extrait de HTML. Une fois le repère choisi, la surveillance le reprend toute seule. Un mot du paragraphe d’introduction est un mauvais repère : la prochaine réécriture du texte déclenchera une alerte. Un attribut de champ bouge moins.
Niveau 2 : un message de test qui ne vend rien
Une fois par jour au plus, ou quelques fois par semaine, envoyez un message de test si le formulaire le permet sans captcha infranchissable.
- Adresse destinataire dédiée, ou boîte de test, pas la file des commerciaux.
- Sujet ou champ fixe du type « test-surveillance », filtré pour ne pas créer de lead.
- Pas de copie vers le client, pas de SMS, pas de webhook de production si ce webhook crée une affaire.
- Un humain ou une règle simple vérifie que le message est arrivé. S’il n’arrive pas, c’est l’alerte.
Si un captcha, une double confirmation ou une protection anti-robot bloque cet envoi, ne la désactivez pas pour la sonde et ne cherchez pas à la contourner. Limitez-vous au niveau 1 automatique, et faites l’envoi réel à la main à un rythme que l’équipe tient vraiment. Un contournement de captcha est une faille, pas un contrôle.
Les pannes d’envoi les plus fréquentes sur WordPress : plugin de formulaire mis à jour, identifiants SMTP révoqués, e-mail du domaine rejeté, ou fichier trop filtré par l’hébergeur. La page, elle, reste en 200. Le message de test est le seul des deux niveaux qui voit ça.
Ne comptez pas sur le visiteur pour le signaler. Une partie abandonne. L’autre croit que « on vous répondra ». Le silence côté boîte de réception est compatible avec un formulaire qui a l’air sain.
Ce qu’il ne faut pas déclencher
N’alertez pas l’astreinte de nuit parce qu’un champ a changé de nom au déploiement de 18 h. Classez ça comme un contrôle à corriger : mettez à jour le repère. En revanche, une page de formulaire en 500, ou un test du matin qui n’est pas arrivé, intéresse quelqu’un le jour même. Le réglage des alertes trop sensibles est celui des faux positifs.
Le monitoring SiteGarde peut porter le niveau 1 sur l’URL publique : code et présence d’un extrait. Le niveau 2 reste un envoi maîtrisé, rare, vers la boîte de test. Les deux ne se remplacent pas. Quand vous changez le plugin de formulaire ou l’adresse de réception, refaites un envoi de test le jour même. Une sonde encore calée sur l’ancien champ dira que tout va bien, ou alertera en continu, selon le sens de l’erreur. Aucun des deux résultats n’est une preuve que les demandes arrivent.