Ce qu’est réellement le monitoring de site web
Dans sa forme la plus simple, le monitoring de site web est une vérification externe : une requête envoyée à votre site depuis un endroit qui n’est pas vos propres serveurs, à intervalle répété, pour vérifier un signal précis, généralement « ai-je reçu une réponse 200 dans un délai raisonnable ? ». Cette seule vérification détecte déjà la panne la plus courante : le serveur est injoignable, expire en délai, ou renvoie une page d’erreur au lieu de votre site.
Un vrai monitoring va plus loin qu’un simple ping disponible/indisponible. Il vérifie le temps de réponse (pour qu’un site qui « charge » en 12 secondes compte quand même comme un problème), le certificat TLS (pour apprendre qu’un certificat expire des semaines avant que les navigateurs préviennent les visiteurs), la résolution DNS (pour qu’un enregistrement mal configuré ne reste pas invisible), et de plus en plus le contenu de la réponse lui-même : un code 200 avec un message d’erreur dans le corps reste une page cassée.
L’objectif n’est pas d’empiler des vérifications exotiques. C’est de vérifier depuis l’extérieur de votre infrastructure, selon un calendrier assez serré pour qu’une panne soit détectée en minutes plutôt que découverte par un ticket support.
Quoi surveiller en premier
Si vous partez de zéro, surveillez dans cet ordre : (1) la page d’accueil et toute autre URL qu’un client ouvrirait directement — connexion, checkout, site marketing lui-même ; (2) l’expiration du certificat TLS, parce qu’elle échoue silencieusement jusqu’au jour où elle n’échoue plus silencieusement ; (3) l’expiration du domaine, pour la même raison ; (4) les enregistrements DNS, si vous avez déjà vu un fournisseur DNS changer quelque chose sans vous prévenir ; (5) tout endpoint API dont dépend un autre service, car ces pannes sont invisibles pour un humain qui navigue sur le site.
Un seul site avec une URL principale, TLS et domaine couvre les 80 % les plus utiles de ce qui peut casser silencieusement. Tout le reste — DNS, enregistrements d’authentification email (SPF/DMARC), routes API individuelles — vaut la peine d’être ajouté une fois les bases couvertes, pas avant.
La checklist de monitoring en production
Utilisez ceci comme première checklist de production pour un petit site ou une app SaaS. Vous n’avez pas besoin de tous les moniteurs possibles dès le premier jour ; vous avez besoin de couvrir les pannes qui feraient écrire un client en premier.
1. Accessibilité publique : surveillez la page d’accueil ou l’URL marketing principale depuis l’extérieur de votre infrastructure. Cela détecte les pannes DNS, serveurs hors ligne, déploiements cassés et erreurs de routage qui font disparaître tout le site.
2. Parcours client : surveillez l’URL dont un utilisateur payant dépend le plus — connexion, checkout, dashboard, réservation ou endpoint de santé API. Une page d’accueil peut être verte pendant que le parcours qui génère le revenu est cassé.
3. Signaux de confiance : surveillez l’expiration TLS, l’expiration du domaine, les redirections et le DNS. Ils sont ennuyeux jusqu’au jour où ils échouent ; alors les navigateurs, fournisseurs email ou clients vous bloquent avant même que votre code applicatif ne tourne.
4. Travail interne silencieux : ajoutez des moniteurs heartbeat pour les crons, files, imports planifiés et sauvegardes. Les checks externes ne voient pas un worker de file mort vendredi ni une sauvegarde arrêtée depuis trois semaines.
5. Propriétaire des alertes : envoyez les alertes à une personne ou un canal réellement surveillé, exigez des échecs consécutifs avant de prévenir, et notez qui possède le moniteur. Un moniteur sans propriétaire est seulement une ligne de log.
6. Communication client : si les clients dépendent du service, reliez les moniteurs à une status page. Quand le site est hors ligne, une page d’incident claire réduit le support et montre que quelqu’un traite déjà le problème.
Des règles d’alerte qui ne crient pas au loup
Le moyen le plus rapide de rendre le monitoring inutile est d’alerter au premier échec. Les réseaux ont des accrocs transitoires qui n’ont rien à voir avec votre site : une seule requête échouée depuis une seule probe location est du bruit de fond normal, pas un incident.
Une règle viable : exigez deux ou trois échecs consécutifs, idéalement depuis plus d’une probe location, avant de déclencher une alerte. Cela transforme « bruyant et ignoré » en « rare et fiable ». Associez-le à un intervalle de vérification adapté au downtime que vous pouvez tolérer avant que quelqu’un doive le savoir : toutes les 5 minutes pour ce qui fait face aux clients, toutes les 15 à 30 minutes pour les outils internes où un court délai importe peu.
Les alertes de temps de réponse ont besoin de leur propre seuil, séparé de la vérification disponible/indisponible : un site « disponible » mais qui met 8 secondes à répondre est un vrai problème qu’une vérification binaire d’uptime ne verra jamais.
Erreurs qui laissent les pannes passer
Surveiller seulement la page d’accueil. Si checkout, connexion ou votre API sont des chemins séparés, une panne limitée à l’un d’eux n’apparaîtra pas dans une vérification de page d’accueil.
Vérifier depuis un seul emplacement. Un seul point de vue ne peut pas distinguer « mon site est hors ligne » de « cette route réseau est en panne ». Vérifier depuis quelques points de sonde permet de l’écarter.
Personne ne possède les alertes. Un moniteur qui appelle un canal Slack que personne ne lit, ou une boîte filtrée dans un dossier, n’est pas du monitoring : c’est une trace après coup. Les alertes ont besoin d’une vraie destination et d’un vrai propriétaire.
Traiter « pas d’alerte » comme « tout va bien ». Un moniteur mal configuré, en pause ou qui cesse silencieusement de s’exécuter ressemble exactement à un site sain, jusqu’au jour où cela compte. C’est pourquoi les vérifications de type heartbeat (voir notre guide sur le monitoring cron) comptent aux côtés des vérifications externes : elles confirment que le monitoring lui-même continue de tourner, pas seulement l’élément qu’il observe.
Comment Holter le fait
Holter exécute des vérifications externes — uptime, temps de réponse, TLS, DNS et signaux associés — depuis plusieurs points de sonde, et les associe à des moniteurs heartbeat pour les éléments qui échouent silencieusement, comme les crons, files et sauvegardes qui s’arrêtent simplement. Les alertes sont configurables pour exiger des échecs consécutifs avant de vous prévenir, au lieu de réveiller quelqu’un pour un seul accroc.
Le plan Free est vraiment gratuit : 5 moniteurs, vérifications toutes les 5 minutes, aucune carte bancaire. C’est assez pour couvrir les URL centrales, TLS et domaine d’un vrai site dès aujourd’hui, et pour voir si l’alerting correspond vraiment à la façon dont votre équipe travaille avant de payer quoi que ce soit.
Holter surveille cela pour vous : checks externes et heartbeats pour les pannes silencieuses. Offre gratuite : 5 moniteurs, checks toutes les 5 minutes, sans carte bancaire.
Créer votre premier moniteur — gratuit