Comment surveiller la disponibilité d’un site Web : un guide étape par étape

La plupart des équipes apprennent que leur site est en panne par un email d’un client, un post sur les réseaux sociaux ou un tableau de bord de ventes qui reste plat silencieusement. Le temps que quelqu’un remarque, la panne dure depuis aussi longtemps que la plainte s’est fait attendre, et les dégâts ont commencé bien avant.

La surveillance du uptime comble cet écart avec un mécanisme simple : des vérifications automatisées lancées sur votre site à intervalles réguliers, depuis l’extérieur de votre propre réseau, qui déclenchent une alerte dès qu’une réponse est erronée ou absente. La configuration ne prend que quelques minutes. Pour obtenir une information fiable, il faut prendre en compte plusieurs décisions que la plupart des tutoriels ignorent, car un moniteur laissé avec ses paramètres par défaut rate les vraies pannes et alerte à tort pour des problèmes imaginaires.

Ce guide parcourt ces décisions en sept étapes : définir ce que signifie « disponible », choisir les types de vérifications, régler la fréquence, vérifier depuis plusieurs emplacements, configurer les alertes, filtrer les faux positifs, et rapporter le uptime face à un SLA.

Une idée lie ces sept étapes : traiter le moniteur comme une pile de vérité, pas une simple vérification. DNS prouve que le nom se résout, TCP prouve que le service est joignable, TLS prouve que les navigateurs lui font confiance, HTTP prouve que l’application répond, la validation du contenu prouve que la bonne page est rendue, et la surveillance des parcours prouve qu’un visiteur peut terminer sa tâche. Construisez la pile de l’extérieur vers l’intérieur, et chaque alerte indique la couche défaillante au lieu de se contenter de dire « site down ».

Étape 1 : Définissez ce que signifie « disponible » pour votre site

La définition la plus paresseuse de disponible est « le serveur répond ». C’est aussi celle qui fait le plus défaut. Un hôte peut répondre au ping alors que le processus de serveur web est mort. Un serveur web peut renvoyer un HTTP 200 tout en servant une page de maintenance, un template à moitié rendu ou le contenu de quelqu’un d’autre après un détournement DNS. Aucun de ces cas n’est considéré comme disponible par un visiteur.

Il est utile de nommer les trois états de panne. Panne dure : l’hôte ne répond à rien du tout. Panne douce : le serveur renvoie un 200 tout en affichant une erreur de base de données, un template vide, ou le contenu de quelqu’un d’autre après un détournement DNS. Panne fantôme : vos serveurs sont sains, mais un CDN cassé ou une défaillance de routage régionale cache le site à une partie de votre audience. Un moniteur qui ne détecte que la panne dure rate les deux autres états, qui sont plus fréquents.

Donc, avant de configurer quoi que ce soit, notez ce qui doit être vrai pour que votre site soit véritablement disponible :

• Le domaine se résout à la bonne adresse, rapidement.
• Les pages critiques répondent avec un code de statut de succès. Critique signifie la page d’accueil plus toutes celles dont la panne coûte de l’argent ou de la confiance : paiement, connexion, inscription, API clés.
• La réponse contient le bon contenu. Un mot-clé ou un élément qui n’apparaît que si la page est bien rendue, ainsi un template d’erreur servi avec un 200 échoue toujours au test.
• Le certificat est valide et la réponse arrive dans un délai acceptable en tant qu’utilisateur.

Cette liste n’est pas bureaucratique. Elle correspond directement aux couches où les requêtes échouent réellement, et les échecs se produisent dans DNS, TCP, TLS et HTTP de manières distinctes. Une vérification qui teste juste une couche ignore les trois autres. La liste indique aussi quelles URL surveiller : pas toutes les pages du site, mais celles selon votre définition.

Pour un site e-commerce, la surveillance de la page d’accueil pourrait indiquer : renvoie un 200 en moins de 3 secondes, contient « Livraison gratuite », présente un certificat avec plus de 14 jours restants, se résout via le CNAME attendu vers le CDN. La surveillance du paiement est plus stricte : renvoie 200, contient « Récapitulatif de commande », échoue si le script du fournisseur de paiement est manquant. Les deux URL comptent comme disponibles. Elles ne méritent pas la même définition.

Étape 2 : Choisissez vos types de vérification de disponibilité

Avec la définition prête, choisissez les vérifications qui valident chaque partie. Cinq types de vérification couvrent presque tous les scénarios de disponibilité, et chacun peut mentir s’il est pris pour preuve de toute l’expérience :

Vérifications HTTP et HTTPS

La vérification de base. Elle demande une URL, vérifie le code de statut et, si bien configurée, confirme qu’un mot-clé apparaît dans le corps de la réponse. Tout code hors de la plage succès, comme les codes communs 4xx et 5xx, compte comme un échec. L’assertion de contenu différencie le « serveur a répondu » du « page chargée réellement » : un 200 portant un template d’erreur réussit une vérification naïve et échoue sur une vérification par mot-clé.

Vérifications Ping (ICMP)

La surveillance ping ICMP vérifie que l’hôte est joignable et mesure la latence et la perte de paquets. Elle est peu coûteuse, rapide et utile pour un triage au niveau réseau. Elle est faible comme seule vérification, car une machine peut répondre aux pings avec son serveur web arrêté, et certains réseaux priorisent bas ou bloquent ICMP.

Vérifications de ports TCP

Une vérification de port TCP confirme qu’un port spécifique accepte les connexions : 443 pour le web, 25 pour le mail, ou tout port personnalisé écouté par votre application. Elle détecte la panne classique intermédiaire où l’hôte répond au ping mais le processus de service a planté et le port refuse les connexions.

Vérifications DNS

La surveillance DNS vérifie que votre domaine se résout aux enregistrements attendus et suit la durée de résolution. Quand le DNS tombe en panne, par enregistrement expiré, mauvaise modification ou panne fournisseur, votre site est indisponible pour tout le monde, même si tous vos serveurs sont sains. C’est le mode de panne le plus souvent oublié.

Vérifications de certificat SSL

La surveillance de certificat SSL suit les dates d’expiration et les problèmes de chaîne de validation. Un certificat expiré est pratiquement une panne : les navigateurs affichent un avertissement plein écran que la plupart des visiteurs ne contourneront pas. Avec des durées de vie de certificat plus courtes, se baser sur un rappel calendaire ne suffit plus, alors laissez un moniteur compter les jours et alerter à 30, 14, et 7 jours.

Une pile de départ raisonnable : vérifications HTTP(S) avec assertions de contenu sur toutes les pages critiques, plus vérifications DNS et certificat sur le domaine, avec les vérifications ping et TCP ajoutées là où elles aident à différencier problèmes réseau et problèmes applicatifs.

Étape 3 : Réglez la bonne fréquence de vérification

L’intervalle de vérification est le plafond de la rapidité de détection. Une panne qui commence quelques secondes après une vérification réussie va durer presque tout l’intervalle avant que la prochaine vérification puisse la détecter, puis la vérification et l’alerte ajoutent encore du temps.

Face à un objectif de disponibilité, ce délai coûte cher. Un objectif mensuel de 99,9% tolère environ 43 minutes de panne. Un intervalle de cinq minutes peut consommer plus d’un dixième de ce budget avant que quiconque sache qu’il y a un problème, ce qui fait partie du véritable coût des arrêts. Considérez cela comme un budget de détection : décidez combien du budget mensuel vous êtes prêt à perdre avant que le premier humain soit informé. Avec 10% d’un budget 99,9%, vous obtenez environ 4 minutes, ce qui exclut une vérification toutes les cinq minutes avant même d’envisager une escalade. En termes de revenus, un site qui gagne 5 000 $/heure perd plus de 400 $ durant une fenêtre invisible de cinq minutes. Comme règle pratique :

• Toutes les minutes pour les objectifs critiques pour le chiffre d’affaires : paiement, connexion, APIs de paiement, tout ce qui est sous SLA formel.
• Toutes les 3 à 5 minutes pour les sites marketing standard et pages de contenu.
• Toutes les 15 à 60 minutes pour les outils internes, environnements de staging, et services à faible enjeu.

Les vérifications HTTP légères sont assez économiques pour être exécutées à haute fréquence partout. Les vérifications plus lourdes basées sur navigateur viennent souvent en complément à rythme plus lent, superposées aux vérifications rapides basiques. Pour un traitement plus approfondi de l’interaction entre intervalle et géographie, voyez ce guide sur la fréquence de surveillance et les emplacements.

Étape 4 : Surveillez depuis plusieurs emplacements

Un seul emplacement de surveillance vous donne un seul point de vue, ce qui crée deux modes de panne simultanés. Vous manquez les pannes qui affectent seulement certaines régions, comme un mauvais edge CDN, une mauvaise configuration geo-DNS, ou un problème de routage entre un FAI et votre hôte. Et vous subissez les problèmes du réseau d’un seul emplacement comme fausses alertes.

Choisissez des emplacements qui correspondent à la localisation de vos utilisateurs. Un site desservant l’Amérique du Nord et l’Europe doit être vérifié depuis les deux côtes américaines et au moins une ville européenne, pas depuis un seul centre de données d’un pays. Les plateformes disposant d’un réseau de surveillance global, Dotcom-Monitor parmi elles, vous permettent de sélectionner des checkpoints sur plusieurs continents pour que le moniteur voie ce que votre audience réelle voit.

Plusieurs emplacements permettent aussi la double vérification, dont dépend l’étape 6 : lorsqu’un site est signalé en panne depuis un lieu, la plateforme vérifie depuis d’autres lieux avant de déclarer le site indisponible. Et lorsqu’un incident est réel, le pattern géographique est votre premier diagnostic. Une panne depuis tous les emplacements pointe vers l’origine, le DNS global, le certificat ou un mauvais déploiement. Une panne depuis une seule région pointe vers un CDN, un routage régional, ou un fournisseur local. Un HTTP passant partout mais une assertion de contenu échouée pointe vers un mauvais template ou une page d’erreur mise en cache. Chaque pattern est un ticket différent pour un prestataire différent, d’où l’importance de l’analyse par emplacement avant de redémarrer un serveur.

Étape 5 : Configurez les alertes et l’escalade

La détection n’a d’importance que si la bonne personne agit. Avant le premier incident, décidez qui reçoit quelles alertes, par quel canal, et dans quel ordre :

• Adaptez le canal à la gravité. L’email convient pour un certificat expirant dans 30 jours. Une panne dure confirmée doit sonner au téléphone, SMS, ou dans l’outil d’astreinte suivi par votre équipe. La livraison d’alerte peut s’effectuer par email, SMS, téléphone, et intégrations avec Slack, Teams et PagerDuty.
• Escaladez en cas de silence. La première alerte va à l’ingénieur d’astreinte. Sans reconnaissance dans un délai donné, elle passe automatiquement au niveau suivant. Une alerte non vue est une alerte qui n’existe pas.
• Alertez sur la dégradation, pas seulement la panne. Un temps de réponse qui triple est souvent le prélude à une panne. Un seuil d’alerte sur la performance vous donne du temps qu’une alerte binaire up/down ne donnera jamais.
• Coupez le son pour la maintenance planifiée. Les fenêtres programmées empêchent les déploiements de déranger qui que ce soit, ce qui protège la crédibilité de toutes les alertes qui se déclenchent.

Rédigez l’alerte comme un contrat : ce qui a échoué, d’où, depuis combien de temps, et ce qui a changé depuis la dernière bonne vérification. « Échec du contrôle contenu de paiement depuis Francfort et Londres pour deux cycles consécutifs ; DNS et TLS passés ; ‘Récapitulatif de commande’ attendu non trouvé ; dernier succès 09:41 UTC » donne au répondeur une hypothèse de départ. Un simple « site down » agit comme une sirène.

Pour un ensemble complet de règles sur les seuils, le routage et les niveaux d’escalade, voyez ces pratiques d’alertes pour la surveillance web.

Étape 6 : Éliminez les faux positifs

Les faux positifs font mourir les programmes de surveillance. Quelques alertes à 3 heures du matin qui s’avèrent sans cause, et l’ingénieur d’astreinte finit par ignorer la seule vraie alerte. La plupart des fausses alertes viennent de quatre sources : des instabilités réseau transitoires entre checkpoint et site, des délais trop courts par rapport au comportement normal du site, des problèmes au niveau de la localisation de surveillance elle-même, et des déploiements que personne n’a signalés au moniteur.

Chacun a une parade directe :

• Confirmez depuis un second emplacement avant d’alerter. Une seule vérification échouée doit déclencher une re-vérification immédiate depuis d’autres checkpoints, pas une page. Sur Dotcom-Monitor, un emplacement en désaccord avec les autres déclenche des vérifications depuis tous les emplacements sélectionnés, pour que la mauvaise journée d’un checkpoint ne déclenche pas d’alerte seul.
• Réglez les délais à partir de données, pas d’espoir. Basez les seuils sur les temps de réponse réels de votre site, avec marge, pour que les pages lentes mais fonctionnelles soient des alertes de performance plutôt que des pannes fantômes.
• Validez le contenu, pas seulement la connectivité. Les assertions par mot-clé fonctionnent dans les deux sens : elles détectent des pannes douces qu’un code de statut manque, et empêchent un moniteur de signaler une page comme indisponible quand seul un widget tiers lent est problématique, car la vérification cible ce qui doit être rendu, pas tout ce qui pourrait l’être.
• Mettez les déploiements au calendrier. Les fenêtres de maintenance sont la solution la moins coûteuse aux faux positifs.

Ensuite, triez le bruit restant en trois catégories lors d’une revue hebdomadaire : mauvais point de vue, mauvais seuil, ou mauvaise définition de disponible. Un mauvais point de vue reçoit une confirmation multi-emplacement. Un mauvais seuil est réajusté à partir des temps de réponse réels de votre site. Une mauvaise définition a une assertion de contenu plus stricte. Une alerte qui ne rentre dans aucune de ces trois catégories reste bruyante jusqu’à ce que vous la compreniez, car la cacher derrière un intervalle plus long ne fait que retarder l’incident réel.

Étape 7 : Mesurez le uptime par rapport à votre SLA

Chaque résultat de vérification alimente un enregistrement permanent de disponibilité, et ce record transforme la surveillance d’un détecteur de fumée en preuve. Les objectifs de disponibilité semblent abstraits jusqu’à ce que vous les convertissiez en minutes :

Le calcul explique le conseil précédent sur la fréquence : au niveau quatre-neuf, un intervalle de vérification de cinq minutes peut manquer plus de temps d’arrêt que le budget mensuel total. Testez vos propres objectifs avec un calculateur de disponibilité pour voir ce que votre SLA promet réellement en minutes.

Gardez le record indépendant. Si votre hébergeur ou CDN s’engage sur un SLA, votre demande de crédits repose sur vos propres données mesurées de l’extérieur, pas sur la page de statut du fournisseur. Gardez ces preuves sobres et exportables : timestamp, localisation du checkpoint, IP résolue, résultat TLS, statut HTTP, temps de réponse, et l’assertion échouée. Une capture d’écran d’une page de statut est un argument ; un historique des vérifications avec emplacement est une preuve, que vous demandiez des crédits ou souteniez une page de statut publique. Des rapports programmés de disponibilité et SLA peuvent déposer ce record automatiquement dans les boîtes mail des parties prenantes, ventilés par vérification et emplacement. Cette ventilation compte : une moyenne globale saine peut cacher une région passée toute la journée de mardi en panne.

Au-delà du uptime : Surveillez les parcours complets des utilisateurs

Tout ce qui précède répond à une question : le site est-il accessible et répond-il correctement ? Cela ne vous dit pas si un visiteur peut chercher dans le catalogue, ajouter au panier, payer ou se connecter, car ces flux couvrent plusieurs pages, scripts et services tiers qu’une vérification d’URL unique ne touche jamais.

Pour les équipes marketing, le parcours à scénariser est celui promis par vos campagnes. Si le référencement payant envoie les visiteurs vers « Commencer l’essai gratuit », le script doit charger la page d’atterrissage, cliquer sur le CTA, remplir le formulaire avec des données sûres pour les tests, et confirmer l’état de remerciement. Quand ce parcours casse en pleine campagne, le uptime de la page d’accueil est une métrique de vanité.

C’est le rôle de la surveillance synthétique : sessions scriptées dans un vrai navigateur qui parcourent étape par étape vos parcours critiques et signalent l’étape exacte qui a échoué. Avec un enregistreur comme EveryStep, un flux de paiement ou de connexion devient un script supervisé répétable sans écrire de code. Une fois les sept étapes ici solides, la surveillance au niveau transactionnel est la couche suivante naturelle.

En résumé

Bien surveiller le uptime d’un site signifie construire la pile de vérité, pas cocher une case. Définissez disponible en termes métier et nommez l’état de panne contre lequel vous vous protégez. Couvrez chaque couche qu’une requête traverse avec des vérifications HTTP, ping, TCP, DNS et certificat, et sachez où chacune peut tromper. Exécutez-les dans un budget de détection que votre SLA peut supporter. Vérifiez depuis les lieux de vie de vos utilisateurs. Rédigez des alertes qui portent une hypothèse, escaladez en cas de silence, confirmez avant d’alerter, et gardez un enregistrement indépendant, exportable, de votre vraie disponibilité, par région et par vérification.

Configuré ainsi, un moniteur de uptime cesse d’être une case à cocher et devient le premier système à savoir qu’un problème existe, des minutes avant vos clients. Ce gain de temps est tout l’enjeu.

Questions fréquemment posées