Les outils de monitoring de site web, en 2026, se choisissent par la question qu’ils savent poser. Il n’y a pas de classement universel : un agent système ne voit pas une redirection, un test Lighthouse ne surveille pas la nuit, un rapport de terrain n’existe pas tant que le trafic est trop faible. On assemble deux ou trois familles, et on évite d’acheter deux fois la même.
Cinq familles
Le contrôle HTTP externe. Une requête part d’un réseau qui n’est pas le vôtre. Elle relève le code, le TLS, les redirections, un extrait de contenu, le délai. C’est la définition du monitoring de site web. Des services de ce type existent depuis des années (UptimeRobot, Better Stack, Oh Dear, et d’autres). SiteGarde est dans cette famille : des URL vues de l’extérieur, pas un agent à installer sur la machine.
L’agent sur le serveur. CPU, mémoire, disque, processus, parfois les journaux. Indispensable quand vous administrez la machine, inutile à lui seul pour savoir ce que le visiteur reçoit. La différence est détaillée dans serveur ou site web.
Le parcours dans un navigateur. Un robot Playwright ou Puppeteer ouvre la page, exécute le JavaScript, parfois remplit un formulaire de test. Plus lourd qu’une requête HTTP, plus proche d’un utilisateur quand la page est vide sans script. À réserver à une ou deux URL, pas à des centaines.
Le laboratoire de performance. Lighthouse, en local ou dans une intégration continue, mesure un chargement dans des conditions fixées. Ce n’est pas une alerte de panne. L’écart avec les données de terrain est le sujet de RUM et labo.
La page de statut. Elle ne mesure rien. Elle publie ce que vous avez déjà décidé : incident en cours, maintenance. Utile pour les clients, à condition d’être alimentée par une vraie détection, pas rédigée trois jours après.
Les données de terrain (Chrome UX Report, rapport Signaux Web essentiels dans Search Console) ne sont pas un outil que vous installez. Elles apparaissent quand le trafic Chrome suffit. Elles ne remplacent pas une sonde.
Critères qui tranchent
Pour le contrôle HTTP, exigez des points vérifiables plutôt qu’une liste de fonctions marketing.
- Le contrôle part de l’extérieur, pas seulement du réseau de l’hébergeur.
- Vous pouvez exiger un code, une chaîne dans la page, et un certificat encore valide.
- L’alerte part au changement d’état, avec un seuil d’échecs consécutifs, vers un e-mail ou un webhook.
- Les essais sont conservés, assez longtemps pour une synthèse mensuelle.
- Vous choisissez les URL. Un outil qui ne sait surveiller que l’accueil laisse le paiement sans contrat.
Le prix et le pas minimum varient. Un pas de quelques minutes sur cinq URL critiques pèse peu. Le même pas sur dix mille fiches produit est un autre projet, souvent inutile si ces fiches ne cassent pas de façon isolée.
Éviter les doublons
Deux moniteurs HTTP sur les mêmes URL, avec les mêmes seuils, produisent deux alertes pour le même 500. Gardez-en un comme source de l’incident. Utilisez le second, si vous en avez un, seulement pour un angle mort : un autre réseau, comme dans le multi-localisations, ou une URL que le premier ne sait pas authentifier.
N’attendez pas d’un tableau d’audience qu’il sonne quand le site tombe. L’absence de visites se voit tard, et pour d’autres raisons qu’un 503. Le rôle de chaque famille tient en une phrase. Si vous ne savez pas laquelle a détecté le dernier incident, vous en avez une de trop, ou une qui n’est branchée sur personne.