Un propriétaire de site découvre généralement que son site est en panne de la même façon que les clients : par un courriel de support, un avis de rétrofacturation ou une baisse des achats qui apparaît dans le tableau de bord analytique le lendemain matin. À ce moment-là, l’incident a déjà plusieurs heures et le chiffre d’affaires est perdu.
La surveillance de la disponibilité du site web consiste à détecter les pannes avant que cela n’arrive. Mais la question “le site est-il en ligne ?” s’avère plus complexe qu’elle ne le paraît. Un site peut renvoyer un code 200 OK alors que le bouton de paiement est cassé. Un site peut être accessible depuis les États-Unis et indisponible en Europe. Un site peut être techniquement en ligne tout en échouant pour les utilisateurs parce que le fournisseur DNS connaît des délais d’attente ou que le certificat SSL a expiré à 2 h du matin.
Ce guide couvre l’aspect opérationnel de la surveillance de la disponibilité du site web : quoi vérifier, d’où vérifier, à quelle fréquence, et quoi faire lorsqu’une alerte se déclenche. Il s’adresse aux propriétaires qui gèrent leur propre site, et non aux équipes SRE disposant d’un mur de tableau de bord dédié. L’objectif est de mettre en place une surveillance fiable, puis de l’ignorer jusqu’à ce qu’elle vous alerte.
Ce que signifie vraiment “Disponible”
Il existe un écart entre “le serveur a répondu” et “un utilisateur a pu acheter quelque chose”. La surveillance de la disponibilité se situe dans cet écart.
Une simple vérification de disponibilité ping votre URL et cherche un code de statut 200. C’est le minimum. Elle détecte les défaillances catastrophiques (serveur en panne, DNS cassé, réseau inaccessible) et rate tout ce qui est plus subtil : un processeur de paiement qui renvoie une erreur 500 lors du paiement, une configuration CDN qui sert une page blanche, une erreur JavaScript qui casse le bouton de connexion sur Safari.
La surveillance réelle de la disponibilité superpose plusieurs vérifications pour que “le site est en ligne” signifie qu’un utilisateur réel, sur un navigateur réel, à un emplacement réel, peut faire ce pourquoi il est venu. Le glossaire Dotcom-Monitor fournit une définition plus complète de la disponibilité d’un site web si vous souhaitez la version formelle.
Un modèle courant de panne réelle : un déploiement un vendredi soir intègre une nouvelle balise analytique. Le HTML renvoie toujours 200 OK depuis toutes les régions, donc un outil simple de disponibilité affiche vert tout le week-end. Le lundi matin, le support croule sous les tickets car la balise tierce bloque le gestionnaire d’envoi du formulaire de paiement sur Safari. Une vérification via un vrai navigateur sur la page de paiement aurait détecté l’échec dans un délai d’intervalle de sondage. Une simple vérification HTTP ne le pouvait pas.
Pourquoi la surveillance de la disponibilité est importante
Le coût des interruptions varie énormément selon l’entreprise, mais les catégories de dommages sont constantes : transactions perdues, SLAs non respectés, réputation de marque affectée, pénalités de référencement dues à des robots explorateurs qui rencontrent des pages d’erreur durant une panne prolongée, et coûts internes d’intervention lors d’incidents.
Pour les sites e-commerce, même quelques minutes d’indisponibilité durant les pics de trafic peuvent représenter des milliers de dollars de commandes perdues. Pour les fournisseurs SaaS, une panne prolongée peut entraîner des crédits SLA et éroder la confiance client mise des années à bâtir. Pour les sites média et d’édition, une panne pendant un cycle d’actualité brûlante entraîne un trafic qui ne revient tout simplement jamais.
La surveillance de la disponibilité réduit le temps entre la survenue d’un problème et sa résolution. Ce temps moyen de détection (MTTD) est souvent le levier principal pour réduire l’impact total d’un incident.
Comment fonctionne la surveillance de la disponibilité
La plupart des surveillances de disponibilité reposent sur des contrôles synthétiques : des requêtes automatisées envoyées depuis des nœuds de surveillance répartis dans le monde. Ces vérifications sont effectuées à intervalles réguliers — de quelques secondes à quelques minutes — et enregistrent si la cible a répondu correctement dans un délai acceptable.
Une vérification typique implique qu’un agent de surveillance dans un lieu géographique précis envoie une requête HTTP à votre URL, puis évalue la réponse selon un ensemble de règles. A-t-elle renvoyé un code de statut 2xx ou un erreur serveur critique ? Le temps de réponse est-il inférieur au seuil ? La page contenait-elle le contenu attendu ? Toutes les ressources de la page se sont-elles chargées correctement ?
Lorsqu’une vérification échoue, le système ne déclenche généralement pas d’alerte immédiatement. Il essaie plutôt de relancer depuis le même nœud et, tout aussi important, depuis différents nœuds. Cela élimine les micro-coupures réseau transitoires et les problèmes localisés du nœud de surveillance lui-même, qui généreraient des fausses alertes constantes. Ce n’est que lorsqu’une défaillance est confirmée depuis plusieurs emplacements que le système déclenche une alerte.
Comment surveiller le temps de fonctionnement du site Web : les cinq vérifications indispensables à tout site
Le conseil standard est de “surveiller la disponibilité”. Cela ne capture pas la plupart des points de défaillance. Voici les cinq types de vérifications qui détectent les pannes réelles que les propriétaires de sites rencontrent en production.
1. Vérification du statut HTTP(S)
La vérification basique. Appelez une URL, attendez un code 2xx, alertez pour tout autre chose. Configurez-la pour la page d’accueil, la page de tarification, la page de paiement, et toute page de destination associée à du trafic payant. Cela détecte les pannes graves et les échecs de négociation SSL.
Exécutez-la depuis plusieurs emplacements. Une vérification depuis un seul centre de données américain indiquera “en ligne” pendant que les clients à Sydney verront une erreur CloudFront.
2. Vérification de résolution DNS
Un site qui ne peut pas être résolu est un site qui n’existe pas, même si le serveur fonctionne. Les problèmes DNS sont généralement dus à des pannes du fournisseur (Route 53 a connu quelques pannes notables), des domaines expirés ou des problèmes de propagation après un changement de record.
Une vérification de surveillance DNS résout votre domaine via plusieurs résolveurs publics et alerte quand la réponse change de manière inattendue ou que la recherche échoue complètement.
3. Validité du certificat SSL
Les certificats expirent. Ils sont révoqués. Ils sont mal configurés lors d’un renouvellement Let’s Encrypt qui a échoué silencieusement. Un visiteur qui rencontre un avertissement de certificat expiré part immédiatement. Il ne clique pas sur “Avancé > Continuer quand même”.
La surveillance des certificats SSL vérifie la chaîne de certificats, la date d’expiration et le statut de révocation. Configurez une alerte d’expiration 30 jours avant, puis 14 jours, puis 7 jours. Vous voulez du temps pour renouveler le certificat sans générer une page d’incident.
4. Vérification complète de la page avec vrai navigateur
Un code 200 n’est pas la même chose qu’une page fonctionnelle. Les sites modernes dépendent des bundles JavaScript, des scripts tiers (analytique, paiement, chat), et des ressources servies par CDN. Chacun peut échouer alors que le HTML renvoie encore un 2xx.
Une vérification avec vrai navigateur de la surveillance de page web charge la page comme Chrome le ferait, exécute JavaScript, et vérifie que les éléments critiques du DOM apparaissent. C’est la vérification qui attrape les problèmes du type “le site semble cassé” que les vérifications HTTP pures manquent.
5. Vérification des transactions critiques
Pour une application SaaS, la vérification la plus importante est “l’utilisateur peut-il se connecter ?”. Pour un site e-commerce, c’est “l’utilisateur peut-il terminer un paiement ?”. Ce sont des flux multi-étapes impliquant une session, un envoi de formulaire, un appel API et une page de confirmation finale.
La surveillance synthétique des transactions exécute un parcours utilisateur scripté à intervalle régulier (connexion, recherche, ajout au panier, paiement) et alerte si une étape échoue. L’outil EveryStep de Dotcom-Monitor vous permet d’enregistrer ces parcours dans un vrai navigateur sans coder.
Si vous ne configurez qu’une seule vérification au-delà du simple HTTP, faites celle-ci. La surveillance des transactions est le signal le plus proche du revenu réel.
Choisir les intervalles et emplacements de surveillance
D’où vérifier
Un seul emplacement de surveillance constitue un point de défaillance unique. Si votre nœud de vérification est en Virginie et qu’AWS us-east-1 rencontre un problème régional, vous aurez une fausse panne. Si votre nœud est en Virginie et que le CDN est dégradé sur son edge européen, vous manquerez une panne réelle.
La solution est une surveillance distribuée depuis plusieurs géographies. Le réseau global de surveillance de Dotcom-Monitor effectue des vérifications depuis des centres de données en Amérique du Nord, Europe, Asie-Pacifique et Amérique du Sud.
Pour un petit site, trois à cinq emplacements suffisent. Choisissez-en un proche de chaque groupe majeur de clients, plus un plus éloigné pour détecter des problèmes de chemin réseau. Ne payez pas pour 30 emplacements si vos clients sont tous dans un seul pays.
Une règle pratique : alertez quand au moins deux emplacements reportent une défaillance dans une fenêtre de 30 à 60 secondes. Cette fenêtre correspond à environ deux cycles de vérification consécutifs d’une minute, ce qui filtre les aléas ponctuels d’un nœud unique tout en détectant rapidement les vraies pannes.
À quelle fréquence vérifier
La fréquence des vérifications fait un compromis entre coût et délai de détection. Les intervalles courants :
- 1 minute pour les pages génératrices de revenus (paiement, connexion, pages de destination payantes).
- 5 minutes pour les pages marketing principales et la surveillance API
- 15 minutes pour les pages secondaires, outils internes et contenu à faible trafic.
Une vérification toutes les 5 minutes signifie qu’une panne peut durer jusqu’à 5 minutes avant d’être détectée. Le coût de cette fenêtre dépend du chiffre d’affaires généré par la page affectée par minute. Le calculateur de disponibilité de Dotcom-Monitor aide à évaluer cela face à votre SLA.
Les vérifications à la minute coûtent plus cher (certains outils facturent par contrôle, d’autres par moniteur). Pour la plupart des petits sites, une couverture à la minute sur les trois chemins générateurs de revenus, et à cinq minutes ailleurs est le bon compromis.
Routage des alertes qui est réellement pris en compte
Le mode d’échec ici est la saturation d’alertes. Si votre système vous dérange à chaque micro-problème, vous commencez à l’ignorer, et la vraie panne passe inaperçue. Quelques règles pratiques :
Mettez en place une politique N-sur-M. N’alertez pas au premier échec unique. Alertez quand 2 contrôles sur 3 (ou 3 sur 5) échouent consécutivement. Cela supprime la plupart des faux positifs sans retarder significativement les vraies alertes.
Séparez critiques et non-critiques. L’alerte “paiement cassé” doit vous réveiller à 3 h du matin. L’alerte “page marketing lente” peut être envoyée dans un canal de discussion en journée. Configurez des routages distincts. La fonction d’alertes Dotcom-Monitor supporte canaux par moniteur, chaînes d’escalade et règles d’horaires.
Utilisez des fenêtres de suppression pendant la maintenance planifiée. Si vous poussez une mise à jour qui provoque un court instant de coupure, supprimez les alertes sur les moniteurs concernés durant ce laps. Ne les désactivez pas. La suppression doit expirer automatiquement.
Escaladez après délai. Si le premier contact ne reconnaît pas dans les 5 minutes, alertez un second. Après 15 minutes, un troisième. Sortir quelqu’un d’une réunion est normal. Manquer une panne car le premier intervenant était en vol ne l’est pas.
Ajoutez un “dead man’s switch”. Un outil de surveillance qui se tait n’est pas équivalent à un site sain. Exécutez un contrôle “battement de cœur” qui vous alerte si aucun contrôle ne se manifeste depuis 10 minutes. Cela détecte un problème au niveau du fournisseur de surveillance lui-même.
Classifiez vos canaux. Les alertes critiques doivent passer par téléphone ou SMS, pas email. L’email convient pour les résumés quotidiens et les rapports de dépassement SLA à 99,95%. Un canal Slack bruyant pour les avertissements est acceptable. Un appel téléphonique à 3 h du matin doit signifier un problème réel.
Que faire lorsqu’une alerte se déclenche
Une alerte est le début d’un processus, pas la fin. Notez ce qu’il faut faire pour vos trois types d’alertes les plus probables avant qu’elles n’arrivent. Le but est d’éliminer la prise de décision durant les cinq premières minutes d’un incident.
Un runbook minimal pour une alerte “site en panne” :
- Ouvrez le tableau de bord de surveillance. Confirmez la panne depuis au moins deux emplacements avant de la considérer comme réelle.
- Vérifiez le déploiement le plus récent. Si une mise à jour a eu lieu dans les 30 dernières minutes, commencez par un rollback puis enquêtez.
- Contrôlez les statuts des fournisseurs en amont : page de statut DNS, page de statut CDN, page de statut hébergeur. La plupart des pannes viennent d’un tiers.
- Si c’est un problème tiers, publiez une annonce sur votre propre page de statut et cessez d’essayer de le corriger de votre côté.
- Si c’est un problème interne, consultez les logs applicatifs pour le pic d’erreurs, identifiez le service en défaut, redémarrez ou faites un rollback.
- Après résolution, réalisez un post-mortem de 15 minutes. Notez ce qui a échoué, comment vous l’avez détecté, ce qui l’a corrigé. Vous ne vous souviendrez pas des détails dans trois mois.
Modes de défaillance communs et à quoi ils ressemblent
Un guide de terrain rapide pour que l’alerte ne soit pas la première fois que vous voyez le symptôme.
Certificat SSL expiré. Toutes les vérifications HTTPS échouent simultanément partout. La vérification HTTP (port 80) fonctionne encore si vous la servez. Solution : renouveler le certificat. Prévention : alertes d’expiration SSL à T-30, T-14 et T-7 jours.
Panne du fournisseur DNS. Certaines vérifications échouent, d’autres réussissent, sans schéma géographique clair. Votre TTL détermine la durée de la panne vue par un utilisateur. Solution : changer de fournisseur ou attendre. Prévention : un fournisseur DNS secondaire pour le même domaine.
Problème régional de CDN. Échecs de vérification depuis une région géographique, succès ailleurs. Les pages retournent 5xx ou restent bloquées. Solution : purge du cache CDN ou basculement vers l’origine. Prévention : surveillance multi-régions pour détecter rapidement.
Bundle JavaScript cassé par déploiement. Vérifications HTTP passent (200 OK). Vérifications vrai navigateur échouent car éléments DOM absents. Symptôme : clients signalent “le bouton ne fonctionne pas”. Solution : rollback. Prévention : contrôles vrai navigateur sur pages critiques et blocage du déploiement si la vérification synthétique échoue.
Délai d’attente sur script tiers. La page charge lentement. Vérifications de transactions échouent de façon intermittente à l’étape dépendante du script (chat, analytics, test A/B). Solution : charger le script de façon asynchrone, configurer des timeouts, le retirer s’il n’est pas essentiel. Prévention : alertes de temps de chargement sur pages critiques.
Comment choisir le bon outil
Le marché offre des dizaines d’options. UptimeRobot et Pingdom gèrent bien la disponibilité basique. StatusCake, Site24x7, et Uptrends rivalisent sur le prix et le champ fonctionnel. Datadog Synthetics et New Relic Synthetics conviennent aux équipes déjà sur ces plateformes APM.
Les questions à poser, dans l’ordre :
- Effectue-t-il des vérifications depuis les géographies où se trouvent réellement mes clients ?
- Supporte-t-il les vérifications vrai navigateur et les transactions multi-étapes, pas seulement HTTP ?
- Les alertes s’intègrent-elles aux canaux que je surveille (SMS, téléphone, PagerDuty, Slack) ?
- Propose-t-il une page de statut publique que mes clients peuvent consulter ?
- Quel est le prix pour des intervalles d’une minute pour les contrôles critiques que je nécessite ?
Dotcom-Monitor couvre la pile complète depuis une seule plateforme : disponibilité, synthétique, monitoring des applications web, API, plus la couche d’alerte et les rapports de disponibilité et SLA. Consultez les tarifs pour voir ce que représente une couverture multi-contrôles à la minute pour un site de votre taille.
Que faire cette semaine
Configurez des vérifications HTTP(S) sur vos trois principales pages génératrices de revenus depuis au moins trois emplacements géographiques à intervalles d’une minute. Ajoutez la surveillance d’expiration SSL. Ajoutez une vérification vrai navigateur sur votre transaction la plus importante (connexion ou paiement). Configurez des alertes SMS avec une politique d’échec 2-sur-3. Notez ce que vous ferez si chacune se déclenche.
