{"id":34061,"date":"2026-06-05T13:31:42","date_gmt":"2026-06-05T13:31:42","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-availability-monitoring\/"},"modified":"2026-06-05T13:38:21","modified_gmt":"2026-06-05T13:38:21","slug":"website-availability-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/website-availability-monitoring\/","title":{"rendered":"Surveillance de la disponibilit\u00e9 du site Web : un guide pratique pour rester en ligne"},"content":{"rendered":"
\"Tableau
La surveillance de la disponibilit\u00e9 effectue des v\u00e9rifications continues depuis plusieurs r\u00e9gions et achemine les alertes avant que les clients ne les remarquent.<\/figcaption><\/figure>\n

Un propri\u00e9taire de site d\u00e9couvre g\u00e9n\u00e9ralement que son site est en panne de la m\u00eame fa\u00e7on que les clients : par un courriel de support, un avis de r\u00e9trofacturation ou une baisse des achats qui appara\u00eet dans le tableau de bord analytique le lendemain matin. \u00c0 ce moment-l\u00e0, l\u2019incident a d\u00e9j\u00e0 plusieurs heures et le chiffre d\u2019affaires est perdu.<\/p>\n

La surveillance de la disponibilit\u00e9 du site web consiste \u00e0 d\u00e9tecter les pannes avant que cela n\u2019arrive. Mais la question “le site est-il en ligne ?” s\u2019av\u00e8re plus complexe qu\u2019elle ne le para\u00eet. Un site peut renvoyer un code 200 OK alors que le bouton de paiement est cass\u00e9. Un site peut \u00eatre accessible depuis les \u00c9tats-Unis et indisponible en Europe. Un site peut \u00eatre techniquement en ligne tout en \u00e9chouant pour les utilisateurs parce que le fournisseur DNS conna\u00eet des d\u00e9lais d\u2019attente ou que le certificat SSL a expir\u00e9 \u00e0 2 h du matin.<\/p>\n

Ce guide couvre l\u2019aspect op\u00e9rationnel de la surveillance de la disponibilit\u00e9 du site web : quoi v\u00e9rifier, d\u2019o\u00f9 v\u00e9rifier, \u00e0 quelle fr\u00e9quence, et quoi faire lorsqu\u2019une alerte se d\u00e9clenche. Il s\u2019adresse aux propri\u00e9taires qui g\u00e8rent leur propre site, et non aux \u00e9quipes SRE disposant d\u2019un mur de tableau de bord d\u00e9di\u00e9. L\u2019objectif est de mettre en place une surveillance fiable, puis de l\u2019ignorer jusqu\u2019\u00e0 ce qu\u2019elle vous alerte.<\/p>\n

Ce que signifie vraiment “Disponible”<\/h2>\n

Il existe un \u00e9cart entre “le serveur a r\u00e9pondu” et “un utilisateur a pu acheter quelque chose”. La surveillance de la disponibilit\u00e9 se situe dans cet \u00e9cart.<\/p>\n

Une simple v\u00e9rification de disponibilit\u00e9<\/a> ping votre URL et cherche un code de statut 200. C\u2019est le minimum. Elle d\u00e9tecte les d\u00e9faillances catastrophiques (serveur en panne, DNS cass\u00e9, r\u00e9seau 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.<\/p>\n

La surveillance r\u00e9elle de la disponibilit\u00e9 superpose plusieurs v\u00e9rifications pour que “le site est en ligne” signifie qu\u2019un utilisateur r\u00e9el, sur un navigateur r\u00e9el, \u00e0 un emplacement r\u00e9el, peut faire ce pourquoi il est venu. Le glossaire Dotcom-Monitor fournit une d\u00e9finition plus compl\u00e8te de la disponibilit\u00e9 d\u2019un site web<\/a> si vous souhaitez la version formelle.<\/p>\n

Un mod\u00e8le courant de panne r\u00e9elle :<\/strong> un d\u00e9ploiement un vendredi soir int\u00e8gre une nouvelle balise analytique. Le HTML renvoie toujours 200 OK depuis toutes les r\u00e9gions, donc un outil simple de disponibilit\u00e9 affiche vert tout le week-end. Le lundi matin, le support croule sous les tickets car la balise tierce bloque le gestionnaire d\u2019envoi du formulaire de paiement sur Safari. Une v\u00e9rification via un vrai navigateur sur la page de paiement aurait d\u00e9tect\u00e9 l\u2019\u00e9chec dans un d\u00e9lai d\u2019intervalle de sondage. Une simple v\u00e9rification HTTP ne le pouvait pas.<\/p><\/blockquote>\n

Pourquoi la surveillance de la disponibilit\u00e9 est importante<\/h2>\n

Le co\u00fbt des interruptions varie \u00e9norm\u00e9ment selon l\u2019entreprise, mais les cat\u00e9gories de dommages sont constantes : transactions perdues, SLAs non respect\u00e9s, r\u00e9putation de marque affect\u00e9e, p\u00e9nalit\u00e9s de r\u00e9f\u00e9rencement dues \u00e0 des robots explorateurs qui rencontrent des pages d\u2019erreur durant une panne prolong\u00e9e, et co\u00fbts internes d\u2019intervention lors d\u2019incidents.<\/p>\n

Pour les sites e-commerce, m\u00eame quelques minutes d\u2019indisponibilit\u00e9 durant les pics de trafic peuvent repr\u00e9senter des milliers de dollars de commandes perdues. Pour les fournisseurs SaaS, une panne prolong\u00e9e peut entra\u00eener des cr\u00e9dits SLA<\/a> et \u00e9roder la confiance client mise des ann\u00e9es \u00e0 b\u00e2tir. Pour les sites m\u00e9dia et d\u2019\u00e9dition, une panne pendant un cycle d\u2019actualit\u00e9 br\u00fblante entra\u00eene un trafic qui ne revient tout simplement jamais.<\/p>\n

La surveillance de la disponibilit\u00e9 r\u00e9duit le temps entre la survenue d\u2019un probl\u00e8me et sa r\u00e9solution. Ce temps moyen de d\u00e9tection (MTTD) est souvent le levier principal pour r\u00e9duire l\u2019impact total d\u2019un incident.<\/p>\n

Comment fonctionne la surveillance de la disponibilit\u00e9<\/h2>\n

La plupart des surveillances de disponibilit\u00e9 reposent sur des contr\u00f4les synth\u00e9tiques : des requ\u00eates automatis\u00e9es envoy\u00e9es depuis des n\u0153uds de surveillance r\u00e9partis dans le monde. Ces v\u00e9rifications sont effectu\u00e9es \u00e0 intervalles r\u00e9guliers \u2014 de quelques secondes \u00e0 quelques minutes \u2014 et enregistrent si la cible a r\u00e9pondu correctement dans un d\u00e9lai acceptable.<\/p>\n

Une v\u00e9rification typique implique qu\u2019un agent de surveillance dans un lieu g\u00e9ographique pr\u00e9cis envoie une requ\u00eate HTTP \u00e0 votre URL, puis \u00e9value la r\u00e9ponse selon un ensemble de r\u00e8gles. A-t-elle renvoy\u00e9 un code de statut 2xx<\/a> ou un erreur serveur critique ? Le temps de r\u00e9ponse est-il inf\u00e9rieur au seuil ? La page contenait-elle le contenu attendu ? Toutes les ressources de la page se sont-elles charg\u00e9es correctement ?<\/p>\n

Lorsqu\u2019une v\u00e9rification \u00e9choue, le syst\u00e8me ne d\u00e9clenche g\u00e9n\u00e9ralement pas d\u2019alerte imm\u00e9diatement. Il essaie plut\u00f4t de relancer depuis le m\u00eame n\u0153ud et, tout aussi important, depuis diff\u00e9rents n\u0153uds. Cela \u00e9limine les micro-coupures r\u00e9seau transitoires et les probl\u00e8mes localis\u00e9s du n\u0153ud de surveillance lui-m\u00eame, qui g\u00e9n\u00e9reraient des fausses alertes constantes. Ce n\u2019est que lorsqu\u2019une d\u00e9faillance est confirm\u00e9e depuis plusieurs emplacements que le syst\u00e8me d\u00e9clenche une alerte.<\/p>\n

Comment surveiller le temps de fonctionnement du site Web : les cinq v\u00e9rifications indispensables \u00e0 tout site<\/h2>\n

Le conseil standard est de “surveiller la disponibilit\u00e9”. Cela ne capture pas la plupart des points de d\u00e9faillance. Voici les cinq types de v\u00e9rifications qui d\u00e9tectent les pannes r\u00e9elles que les propri\u00e9taires de sites rencontrent en production.<\/p>\n

\"Diagramme
Chaque couche d\u00e9tecte des d\u00e9faillances que la couche inf\u00e9rieure ne peut pas voir.<\/figcaption><\/figure>\n

1. V\u00e9rification du statut HTTP(S)<\/h3>\n

La v\u00e9rification basique. Appelez une URL, attendez un code 2xx, alertez pour tout autre chose. Configurez-la pour la page d\u2019accueil, la page de tarification, la page de paiement, et toute page de destination associ\u00e9e \u00e0 du trafic payant. Cela d\u00e9tecte les pannes graves et les \u00e9checs de n\u00e9gociation SSL.<\/p>\n

Ex\u00e9cutez-la depuis plusieurs emplacements. Une v\u00e9rification depuis un seul centre de donn\u00e9es am\u00e9ricain indiquera “en ligne” pendant que les clients \u00e0 Sydney verront une erreur CloudFront.<\/p>\n

2. V\u00e9rification de r\u00e9solution DNS<\/h3>\n

Un site qui ne peut pas \u00eatre r\u00e9solu est un site qui n\u2019existe pas, m\u00eame si le serveur fonctionne. Les probl\u00e8mes DNS sont g\u00e9n\u00e9ralement dus \u00e0 des pannes du fournisseur (Route 53 a connu quelques pannes notables), des domaines expir\u00e9s ou des probl\u00e8mes de propagation apr\u00e8s un changement de record.<\/p>\n

Une v\u00e9rification de surveillance DNS<\/a> r\u00e9sout votre domaine via plusieurs r\u00e9solveurs publics et alerte quand la r\u00e9ponse change de mani\u00e8re inattendue ou que la recherche \u00e9choue compl\u00e8tement.<\/p>\n

3. Validit\u00e9 du certificat SSL<\/h3>\n

Les certificats expirent. Ils sont r\u00e9voqu\u00e9s. Ils sont mal configur\u00e9s lors d\u2019un renouvellement Let’s Encrypt qui a \u00e9chou\u00e9 silencieusement. Un visiteur qui rencontre un avertissement de certificat expir\u00e9 part imm\u00e9diatement. Il ne clique pas sur “Avanc\u00e9 > Continuer quand m\u00eame”.<\/p>\n

La surveillance des certificats SSL<\/a> v\u00e9rifie la cha\u00eene de certificats, la date d\u2019expiration et le statut de r\u00e9vocation. Configurez une alerte d\u2019expiration 30 jours avant, puis 14 jours, puis 7 jours. Vous voulez du temps pour renouveler le certificat sans g\u00e9n\u00e9rer une page d\u2019incident.<\/p>\n

4. V\u00e9rification compl\u00e8te de la page avec vrai navigateur<\/h3>\n

Un code 200 n\u2019est pas la m\u00eame chose qu\u2019une page fonctionnelle. Les sites modernes d\u00e9pendent des bundles JavaScript, des scripts tiers (analytique, paiement, chat), et des ressources servies par CDN. Chacun peut \u00e9chouer alors que le HTML renvoie encore un 2xx.<\/p>\n

Une v\u00e9rification avec vrai navigateur de la surveillance de page web<\/a> charge la page comme Chrome le ferait, ex\u00e9cute JavaScript, et v\u00e9rifie que les \u00e9l\u00e9ments critiques du DOM apparaissent. C\u2019est la v\u00e9rification qui attrape les probl\u00e8mes du type “le site semble cass\u00e9” que les v\u00e9rifications HTTP pures manquent.<\/p>\n

5. V\u00e9rification des transactions critiques<\/h3>\n

Pour une application SaaS, la v\u00e9rification la plus importante est “l\u2019utilisateur peut-il se connecter ?”. Pour un site e-commerce, c\u2019est “l\u2019utilisateur peut-il terminer un paiement ?”. Ce sont des flux multi-\u00e9tapes impliquant une session, un envoi de formulaire, un appel API et une page de confirmation finale.<\/p>\n

La surveillance synth\u00e9tique<\/a> des transactions ex\u00e9cute un parcours utilisateur script\u00e9 \u00e0 intervalle r\u00e9gulier (connexion, recherche, ajout au panier, paiement) et alerte si une \u00e9tape \u00e9choue. L\u2019outil EveryStep<\/a> de Dotcom-Monitor vous permet d\u2019enregistrer ces parcours dans un vrai navigateur sans coder.<\/p>\n

Si vous ne configurez qu\u2019une seule v\u00e9rification au-del\u00e0 du simple HTTP, faites celle-ci.<\/strong> La surveillance des transactions est le signal le plus proche du revenu r\u00e9el.<\/p><\/blockquote>\n

Choisir les intervalles et emplacements de surveillance<\/h2>\n

D\u2019o\u00f9 v\u00e9rifier<\/h3>\n

Un seul emplacement de surveillance constitue un point de d\u00e9faillance unique. Si votre n\u0153ud de v\u00e9rification est en Virginie et qu\u2019AWS us-east-1 rencontre un probl\u00e8me r\u00e9gional, vous aurez une fausse panne. Si votre n\u0153ud est en Virginie et que le CDN est d\u00e9grad\u00e9 sur son edge europ\u00e9en, vous manquerez une panne r\u00e9elle.<\/p>\n

La solution est une surveillance distribu\u00e9e depuis plusieurs g\u00e9ographies. Le r\u00e9seau global de surveillance<\/a> de Dotcom-Monitor effectue des v\u00e9rifications depuis des centres de donn\u00e9es en Am\u00e9rique du Nord, Europe, Asie-Pacifique et Am\u00e9rique du Sud.<\/p>\n

Pour un petit site, trois \u00e0 cinq emplacements suffisent. Choisissez-en un proche de chaque groupe majeur de clients, plus un plus \u00e9loign\u00e9 pour d\u00e9tecter des probl\u00e8mes de chemin r\u00e9seau. Ne payez pas pour 30 emplacements si vos clients sont tous dans un seul pays.<\/p>\n

Une r\u00e8gle pratique : alertez quand au moins deux emplacements reportent une d\u00e9faillance dans une fen\u00eatre de 30 \u00e0 60 secondes. Cette fen\u00eatre correspond \u00e0 environ deux cycles de v\u00e9rification cons\u00e9cutifs d\u2019une minute, ce qui filtre les al\u00e9as ponctuels d\u2019un n\u0153ud unique tout en d\u00e9tectant rapidement les vraies pannes.<\/p><\/blockquote>\n

\u00c0 quelle fr\u00e9quence v\u00e9rifier<\/h3>\n

La fr\u00e9quence des v\u00e9rifications fait un compromis entre co\u00fbt et d\u00e9lai de d\u00e9tection. Les intervalles courants :<\/p>\n