Comment fonctionne la surveillance de disponibilité des sites web en 2026

Un service qui atteint 99,99 % de disponibilité est hors ligne moins de 53 minutes par an. Descendez à 99,9 % et vous perdez plus de huit heures. La surveillance de disponibilité est ce petit bout d'infrastructure qui détecte ces minutes au moment même où elles surviennent. Ce guide explique comment elle fonctionne, quoi surveiller, à quelle fréquence vérifier, et les erreurs qui transforment un outil utile en bruit de fond.

Ce que fait réellement un moniteur de disponibilité

Un moniteur de disponibilité exécute une petite boucle. Depuis un serveur situé quelque part sur l'internet public, il envoie une requête à une cible que vous avez désignée. Il enregistre la réponse, le code de statut et la durée de l'aller-retour. Il attend ensuite l'intervalle que vous avez choisi, puis recommence.

La sonde se trouve volontairement à l'extérieur de votre infrastructure. Si vous surveilliez depuis votre propre réseau, vous ne détecteriez pas les pannes qui semblent normales de l'intérieur mais cassent l'expérience pour les utilisateurs réels. C'est la différence entre la surveillance synthétique (une sonde externe) et la surveillance des utilisateurs réels (la télémétrie issue des visiteurs réels). La plupart des équipes utilisent les deux. La surveillance de disponibilité relève du côté synthétique.

Ce que vous pouvez réellement surveiller

Les outils modernes de surveillance couvrent bien plus que le HTTP. Les neuf types de sondes que l'on retrouve sur le marché répondent chacun à une question légèrement différente.

• Les vérifications HTTP renvoient un code de statut et un temps de réponse pour n'importe quelle URL.
• Les vérifications Ping (ICMP) confirment qu'un hôte répond au niveau réseau.
• Les vérifications SSL indiquent combien de jours il reste sur votre certificat.
• Les vérifications DNS confirment que les enregistrements A, AAAA, MX, TXT ou NS résolvent toujours vers les valeurs attendues.
• Les vérifications de port TCP confirment qu'un service est en écoute sur un port donné, ou qu'un port qui devrait être fermé est soudainement ouvert.
• Les vérifications WHOIS surveillent la date d'expiration de l'enregistrement de votre nom de domaine.
• Les vérifications Blacklist indiquent si votre IP d'envoi se retrouve sur Spamhaus, SORBS ou des listes similaires.
• Les Heartbeat inversent la relation : votre tâche envoie un ping au moniteur, et vous êtes alerté lorsqu'elle s'arrête.

À quelle fréquence vérifier

La fréquence de vérification est un compromis entre précision et bruit. Une cadence plus rapide détecte les pannes plus courtes mais génère plus de faux positifs liés à des micro-coupures réseau. Une cadence plus lente lisse le bruit mais passe à côté des courtes pannes qui comptent malgré tout dans votre budget d'erreur.

Une valeur par défaut pragmatique : 60 secondes pour HTTP et ping sur les services importants, 5 minutes pour les pages peu prioritaires, 15 minutes pour SSL, toutes les heures pour WHOIS. Ne descendez à 30 secondes que pour les services où une indisponibilité vous coûte mesurablement de l'argent à la minute. Aller en dessous de 30 secondes améliore rarement le résultat et engendre souvent une fatigue d'alerte.

Acheminer les alertes sans bruit

Une alerte que personne ne lit est pire que pas d'alerte du tout. Trois règles couvrent la majorité des équipes.

• Envoyez les alertes DOWN à un seul canal par défaut, idéalement celui que votre équipe consulte déjà (Slack, Discord, Telegram ou e-mail).
• Utilisez une règle de seuil d'au moins 3 échecs consécutifs avant de déclencher une astreinte. Une vérification manquée est du bruit. Trois d'affilée, c'est un signal.
• Acheminez les services critiques vers un outil d'astreinte (PagerDuty, Opsgenie) via un webhook signé. Acheminez tout le reste vers le chat. Acquittez les incidents pour stopper l'astreinte une fois qu'un humain est sur le coup.

Les erreurs qui tuent les programmes de surveillance

La première erreur est de ne surveiller que la page d'accueil. Une page d'accueil qui fonctionne ne vous dit presque rien sur le tunnel de paiement ou sur l'API à laquelle votre application mobile parle. Ajoutez des moniteurs HTTP spécifiques pour les URL qui comptent le plus pour le chiffre d'affaires ou pour votre charge de support.

La deuxième erreur est la diffusion silencieuse à tous les canaux. Chaque moniteur déclenche chaque canal, puis chaque membre de l'équipe coupe le son des plus bruyants, et l'incident réel finit par apparaître dans un canal muet. Définissez une route par défaut, acheminez les exceptions vers des personnes précises, et révisez vos règles chaque trimestre.

Une configuration de démarrage en 10 minutes

Si vous partez de zéro, la séquence pratique est courte. Créez un moniteur HTTP sur votre URL principale avec un intervalle de 60 secondes. Créez un moniteur SSL sur le même nom d'hôte avec une fenêtre d'avertissement de 30 jours. Créez une règle de notification qui achemine les alertes DOWN vers le chat de votre équipe. Ajoutez une page de statut si vous avez des utilisateurs externes qui se soucient de la disponibilité. Ajoutez des heartbeats pour les tâches cron qui gèrent votre facturation, vos rapports et vos sauvegardes. Vous êtes maintenant en avance sur l'opérateur médian.