Un faux positif est une alerte alors que les visiteurs, eux, utilisent le site. Le coût n’est pas le message. C’est l’habitude de l’ignorer. Le jour où la panne est réelle, elle a la même tête que les dix précédentes. Réduire les faux positifs, c’est changer la règle de déclenchement, pas demander à l’équipe de « faire plus attention ».
La règle se juge sur deux erreurs. Alerter trop tôt fatigue. Alerter trop tard, ou plus du tout, laisse passer une panne. On resserre jusqu’à ce que les messages correspondent à des incidents qu’on aurait voulu connaître.
D’où viennent les alertes inutiles
| Cause | Ce que voit la sonde | Correctif |
|---|---|---|
| Un seul échec réseau | Timeout isolé, puis 200 | Exiger 2 ou 3 échecs consécutifs |
| Un seul lieu de contrôle | Échec local à la sonde | Confirmer depuis un second point |
| Délai plus court que la page lente | Timeout alors que la page finit par répondre | Relever le délai au-dessus du temps habituel |
| Redirection comptée comme une erreur | 301 ou 302 vers la bonne page | Accepter la redirection, juger l’URL finale |
| Pare-feu qui bloque la sonde | 403, 429 ou page « bot » | Autoriser la sonde, ou son user-agent, sans ouvrir le site |
| Mot-clé trop fragile | Le slogan a changé, la page est saine | Chercher un repère stable (titre de service, formulaire) |
| Maintenance annoncée | 503 prévu | Fenêtre de silence sur cette plage |
Le cas du pare-feu est fréquent : la sonde est un client qui revient souvent, sans navigateur complet. Le site la traite comme un abus. Les visiteurs n’ont rien. L’alerte dit « site en 403 ». Autoriser l’adresse ou l’identifiant de la sonde règle le faux positif. Augmenter encore le nombre d’essais ne fait que cogner plus fort. Si vos propres contrôles sont assez nombreux pour déclencher une limite, le rythme est trop haut : voir les requêtes HTTP trop nombreuses.
Une page de maintenance en 200, sans le contenu attendu, n’est pas un faux positif : c’est une panne que le seul code HTTP ne voit pas. Le mot-clé sert à ça. Choisissez une chaîne qui ne change pas à chaque retouche éditoriale. « Bienvenue sur notre site » disparaîtra à la prochaine refonte de texte. Le nom du formulaire de contact, ou un identifiant de page, tient plus longtemps.
Régler la confirmation
Deux ou trois échecs d’affilée, puis une alerte, est un réglage de départ sain pour une page web. À un contrôle par minute, trois échecs retardent le message d’environ trois minutes. Pour un paiement, c’est souvent acceptable. Pour un blog, vous pouvez espacer le contrôle lui-même plutôt que d’empiler les essais.
Le second point de contrôle sert quand une sonde est dans un réseau qui n’atteint pas votre CDN. Si les deux échouent, la panne est bien plus crédible. Si une seule échoue, corrigez la sonde ou le lieu, et n’ouvrez pas d’incident production.
Écrivez les fenêtres de maintenance dans l’outil avant le déploiement : les 503 de la fenêtre ne partent pas. Une fenêtre oubliée produit une rafale, puis quelqu’un coupe les alertes « pour la soirée » et oublie de les rouvrir. Mieux vaut une heure de silence prévue qu’une nuit entière sans surveillance.
Le message doit aider à classer le doute : URL, code, temps de réponse, lieu de la sonde. « Down » seul oblige à retester à la main, et la main finit par remplacer l’outil. Le canal qui reçoit ces messages, e-mail ou autre, doit rester lisible. S’il ne l’est plus, le problème est décrit pour les alertes e-mail : on groupe, on ne multiplie pas les destinataires pour compenser.
Revoir les règles avec les faits
- Pendant deux à quatre semaines, notez chaque alerte : vraie panne, ou non.
- Pour les non, classez la cause dans le tableau (délai, pare-feu, mot-clé, essai unique).
- Changez une règle, pas toutes. Attendez la semaine suivante.
- Gardez un œil sur les incidents découverts par un humain avant toute alerte. Ce sont les faux négatifs. Ils disent qu’on a trop assoupli, ou que l’URL surveillée n’est pas celle qui casse.
- Retirez les contrôles en double qui crient pour la même home. Une alerte suffit.
Le monitoring SiteGarde, comme tout contrôle externe, déclenchera de fausses alertes s’il est réglé plus sec que le site réel. Le bon réglage se voit dans le journal des alertes, pas dans la promesse de l’outil. Quand les messages correspondent aux pannes que l’équipe reconnaît, on peut de nouveau accepter qu’une alerte de nuit mérite d’être lue. Pas avant.