{"id":28356,"date":"2023-02-25T08:32:53","date_gmt":"2023-02-25T08:32:53","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2023\/02\/25\/comment-surveiller-la-disponibilite-du-site-web-en-2023\/"},"modified":"2026-08-22T22:46:28","modified_gmt":"2026-08-22T22:46:28","slug":"comment-surveiller-la-disponibilite-du-site-web-en-2023","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/comment-surveiller-la-disponibilite-du-site-web-en-2023\/","title":{"rendered":"Comment surveiller la disponibilit\u00e9 d&#8217;un site Web : un guide \u00e9tape par \u00e9tape"},"content":{"rendered":"<figure id=\"attachment_34488\" aria-describedby=\"caption-attachment-34488\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34488\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime.webp\" alt=\"Illustration de la surveillance du temps de disponibilit\u00e9 du site web avec un tableau de bord de statut, un graphique de disponibilit\u00e9 et des v\u00e9rifications effectu\u00e9es depuis des emplacements autour d&apos;un globe\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34488\" class=\"wp-caption-text\">La surveillance du uptime lance des v\u00e9rifications programm\u00e9es sur votre site depuis l&#8217;ext\u00e9rieur de votre r\u00e9seau et alerte d\u00e8s qu&#8217;une r\u00e9ponse est incorrecte.<\/figcaption><\/figure>\n<p>La plupart des \u00e9quipes apprennent que leur site est en panne par un email d\u2019un client, un post sur les r\u00e9seaux sociaux ou un tableau de bord de ventes qui reste plat silencieusement. Le temps que quelqu&#8217;un remarque, la panne dure depuis aussi longtemps que la plainte s\u2019est fait attendre, et les d\u00e9g\u00e2ts ont commenc\u00e9 bien avant.<\/p>\n<p>La surveillance du uptime comble cet \u00e9cart avec un m\u00e9canisme simple : des v\u00e9rifications automatis\u00e9es lanc\u00e9es sur votre site \u00e0 intervalles r\u00e9guliers, depuis l&#8217;ext\u00e9rieur de votre propre r\u00e9seau, qui d\u00e9clenchent une alerte d\u00e8s qu\u2019une r\u00e9ponse est erron\u00e9e ou absente. La configuration ne prend que quelques minutes. Pour obtenir une information fiable, il faut prendre en compte plusieurs d\u00e9cisions que la plupart des tutoriels ignorent, car un moniteur laiss\u00e9 avec ses param\u00e8tres par d\u00e9faut rate les vraies pannes et alerte \u00e0 tort pour des probl\u00e8mes imaginaires.<\/p>\n<p>Ce guide parcourt ces d\u00e9cisions en sept \u00e9tapes : d\u00e9finir ce que signifie \u00ab disponible \u00bb, choisir les types de v\u00e9rifications, r\u00e9gler la fr\u00e9quence, v\u00e9rifier depuis plusieurs emplacements, configurer les alertes, filtrer les faux positifs, et rapporter le uptime face \u00e0 un SLA.<\/p>\n<p>Une id\u00e9e lie ces sept \u00e9tapes : traiter le moniteur comme une pile de v\u00e9rit\u00e9, pas une simple v\u00e9rification. DNS prouve que le nom se r\u00e9sout, TCP prouve que le service est joignable, TLS prouve que les navigateurs lui font confiance, HTTP prouve que l\u2019application r\u00e9pond, la validation du contenu prouve que la bonne page est rendue, et la surveillance des parcours prouve qu\u2019un visiteur peut terminer sa t\u00e2che. Construisez la pile de l\u2019ext\u00e9rieur vers l\u2019int\u00e9rieur, et chaque alerte indique la couche d\u00e9faillante au lieu de se contenter de dire \u00ab site down \u00bb.<\/p>\n<h2 id='\u00e9tape-1-d\u00e9finissez-ce-que-signifie-disponible-pour-votre-site'  id=\"boomdevs_1\" id=\"step-1-define-what-up-means-for-your-site\">\u00c9tape 1 : D\u00e9finissez ce que signifie \u00ab disponible \u00bb pour votre site<\/h2>\n<p>La d\u00e9finition la plus paresseuse de disponible est \u00ab le serveur r\u00e9pond \u00bb. C\u2019est aussi celle qui fait le plus d\u00e9faut. Un h\u00f4te peut r\u00e9pondre 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 \u00e0 moiti\u00e9 rendu ou le contenu de quelqu\u2019un d\u2019autre apr\u00e8s un d\u00e9tournement DNS. Aucun de ces cas n\u2019est consid\u00e9r\u00e9 comme disponible par un visiteur.<\/p>\n<p>Il est utile de nommer les trois \u00e9tats de panne. Panne dure : l\u2019h\u00f4te ne r\u00e9pond \u00e0 rien du tout. Panne douce : le serveur renvoie un 200 tout en affichant une erreur de base de donn\u00e9es, un template vide, ou le contenu de quelqu\u2019un d\u2019autre apr\u00e8s un d\u00e9tournement DNS. Panne fant\u00f4me : vos serveurs sont sains, mais un CDN cass\u00e9 ou une d\u00e9faillance de routage r\u00e9gionale cache le site \u00e0 une partie de votre audience. Un moniteur qui ne d\u00e9tecte que la panne dure rate les deux autres \u00e9tats, qui sont plus fr\u00e9quents.<\/p>\n<p>Donc, avant de configurer quoi que ce soit, notez ce qui doit \u00eatre vrai pour que votre site soit v\u00e9ritablement disponible :<\/p>\n<ul>\n<li><strong>Le domaine se r\u00e9sout<\/strong> \u00e0 la bonne adresse, rapidement.<\/li>\n<li><strong>Les pages critiques r\u00e9pondent avec un code de statut de succ\u00e8s.<\/strong> Critique signifie la page d\u2019accueil plus toutes celles dont la panne co\u00fbte de l\u2019argent ou de la confiance : paiement, connexion, inscription, API cl\u00e9s.<\/li>\n<li><strong>La r\u00e9ponse contient le bon contenu.<\/strong> Un mot-cl\u00e9 ou un \u00e9l\u00e9ment qui n\u2019appara\u00eet que si la page est bien rendue, ainsi un template d\u2019erreur servi avec un 200 \u00e9choue toujours au test.<\/li>\n<li><strong>Le certificat est valide<\/strong> et la r\u00e9ponse arrive dans un d\u00e9lai acceptable en tant qu\u2019utilisateur.<\/li>\n<\/ul>\n<p>Cette liste n\u2019est pas bureaucratique. Elle correspond directement aux couches o\u00f9 les requ\u00eates \u00e9chouent r\u00e9ellement, et <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/website-monitoring-errors-dns-tcp-tls-http\/\">les \u00e9checs se produisent dans DNS, TCP, TLS et HTTP<\/a> de mani\u00e8res distinctes. Une v\u00e9rification 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\u00e9finition.<\/p>\n<p>Pour un site e-commerce, la surveillance de la page d\u2019accueil pourrait indiquer : renvoie un 200 en moins de 3 secondes, contient \u00ab Livraison gratuite \u00bb, pr\u00e9sente un certificat avec plus de 14 jours restants, se r\u00e9sout via le CNAME attendu vers le CDN. La surveillance du paiement est plus stricte : renvoie 200, contient \u00ab R\u00e9capitulatif de commande \u00bb, \u00e9choue si le script du fournisseur de paiement est manquant. Les deux URL comptent comme disponibles. Elles ne m\u00e9ritent pas la m\u00eame d\u00e9finition.<\/p>\n<h2 id='\u00e9tape-2-choisissez-vos-types-de-v\u00e9rification-de-disponibilit\u00e9'  id=\"boomdevs_2\" id=\"step-2-choose-your-uptime-check-types\">\u00c9tape 2 : Choisissez vos types de v\u00e9rification de disponibilit\u00e9<\/h2>\n<p>Avec la d\u00e9finition pr\u00eate, choisissez les v\u00e9rifications qui valident chaque partie. Cinq types de v\u00e9rification couvrent presque tous les sc\u00e9narios de disponibilit\u00e9, et chacun peut mentir s\u2019il est pris pour preuve de toute l\u2019exp\u00e9rience :<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Type de v\u00e9rification<\/th>\n<th>Ce qu\u2019il v\u00e9rifie<\/th>\n<th>Ce qu\u2019il d\u00e9tecte<\/th>\n<th>O\u00f9 il peut induire en erreur<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>HTTP(S)<\/td>\n<td>Code de statut et contenu de r\u00e9ponse d\u2019une URL<\/td>\n<td>Erreurs serveur, pages d\u2019erreur servies avec un 200, contenu erron\u00e9 ou d\u00e9tourn\u00e9<\/td>\n<td>Un 200 peut porter un template erron\u00e9 ou une page d\u2019erreur mise en cache<\/td>\n<\/tr>\n<tr>\n<td>Ping (ICMP)<\/td>\n<td>L\u2019h\u00f4te r\u00e9pond aux requ\u00eates echo<\/td>\n<td>\u00c9checs r\u00e9seau et au niveau h\u00f4te, perte de paquets, probl\u00e8mes de routage<\/td>\n<td>Un h\u00f4te peut r\u00e9pondre aux pings alors que le service web ou TLS est cass\u00e9<\/td>\n<\/tr>\n<tr>\n<td>Port TCP<\/td>\n<td>Un port sp\u00e9cifique accepte les connexions<\/td>\n<td>Processus de service en panne sur un h\u00f4te qui r\u00e9pond toujours au ping<\/td>\n<td>Un port ouvert prouve qu\u2019un \u00e9couteur existe, mais pas que l\u2019application derri\u00e8re est saine<\/td>\n<\/tr>\n<tr>\n<td>DNS<\/td>\n<td>Le domaine se r\u00e9sout aux bons enregistrements<\/td>\n<td>Domaines expir\u00e9s, modifications rat\u00e9es, pannes du fournisseur DNS<\/td>\n<td>Un r\u00e9solveur peut avoir la bonne r\u00e9ponse alors qu\u2019une autre r\u00e9gion sert des enregistrements p\u00e9rim\u00e9s<\/td>\n<\/tr>\n<tr>\n<td>Certificat SSL<\/td>\n<td>Validit\u00e9 du certificat et jours avant expiration<\/td>\n<td>Certificats expir\u00e9s ou mal configur\u00e9s que les navigateurs bloquent<\/td>\n<td>Un certificat valide ne dit rien sur le contenu servi derri\u00e8re<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='v\u00e9rifications-http-et-https'  id=\"boomdevs_3\">V\u00e9rifications HTTP et HTTPS<\/h3>\n<p>La v\u00e9rification de base. Elle demande une URL, v\u00e9rifie le code de statut et, si bien configur\u00e9e, confirme qu\u2019un mot-cl\u00e9 appara\u00eet dans le corps de la r\u00e9ponse. Tout code hors de la plage succ\u00e8s, comme les <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/les-10-codes-de-statut-http-les-plus-courants\/\">codes communs 4xx et 5xx<\/a>, compte comme un \u00e9chec. L\u2019assertion de contenu diff\u00e9rencie le \u00ab serveur a r\u00e9pondu \u00bb du \u00ab page charg\u00e9e r\u00e9ellement \u00bb : un 200 portant un template d\u2019erreur r\u00e9ussit une v\u00e9rification na\u00efve et \u00e9choue sur une v\u00e9rification par mot-cl\u00e9.<\/p>\n<h3 id='v\u00e9rifications-ping-icmp'  id=\"boomdevs_4\">V\u00e9rifications Ping (ICMP)<\/h3>\n<p>La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/surveillance-icmp-dotcom-monitor\/\">surveillance ping ICMP<\/a> v\u00e9rifie que l\u2019h\u00f4te est joignable et mesure la latence et la perte de paquets. Elle est peu co\u00fbteuse, rapide et utile pour un triage au niveau r\u00e9seau. Elle est faible comme seule v\u00e9rification, car une machine peut r\u00e9pondre aux pings avec son serveur web arr\u00eat\u00e9, et certains r\u00e9seaux priorisent bas ou bloquent ICMP.<\/p>\n<h3 id='v\u00e9rifications-de-ports-tcp'  id=\"boomdevs_5\">V\u00e9rifications de ports TCP<\/h3>\n<p>Une <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/surveillance-des-ports-tcp-telnet-dotcom-monitor\/\">v\u00e9rification de port TCP<\/a> confirme qu\u2019un port sp\u00e9cifique accepte les connexions : 443 pour le web, 25 pour le mail, ou tout port personnalis\u00e9 \u00e9cout\u00e9 par votre application. Elle d\u00e9tecte la panne classique interm\u00e9diaire o\u00f9 l\u2019h\u00f4te r\u00e9pond au ping mais le processus de service a plant\u00e9 et le port refuse les connexions.<\/p>\n<h3 id='v\u00e9rifications-dns'  id=\"boomdevs_6\">V\u00e9rifications DNS<\/h3>\n<p>La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/outil-de-surveillance-dns-dotcom-monitor\/\">surveillance DNS<\/a> v\u00e9rifie que votre domaine se r\u00e9sout aux enregistrements attendus et suit la dur\u00e9e de r\u00e9solution. Quand le DNS tombe en panne, par enregistrement expir\u00e9, mauvaise modification ou panne fournisseur, votre site est indisponible pour tout le monde, m\u00eame si tous vos serveurs sont sains. C\u2019est le mode de panne le plus souvent oubli\u00e9.<\/p>\n<h3 id='v\u00e9rifications-de-certificat-ssl'  id=\"boomdevs_7\">V\u00e9rifications de certificat SSL<\/h3>\n<p>La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/ssl-certificate-monitoring\/\">surveillance de certificat SSL<\/a> suit les dates d\u2019expiration et les probl\u00e8mes de cha\u00eene de validation. Un certificat expir\u00e9 est pratiquement une panne : les navigateurs affichent un avertissement plein \u00e9cran que la plupart des visiteurs ne contourneront pas. Avec des dur\u00e9es de vie de certificat plus courtes, se baser sur un rappel calendaire ne suffit plus, alors laissez un moniteur compter les jours et alerter \u00e0 30, 14, et 7 jours.<\/p>\n<p>Une pile de d\u00e9part raisonnable : v\u00e9rifications HTTP(S) avec assertions de contenu sur toutes les pages critiques, plus v\u00e9rifications DNS et certificat sur le domaine, avec les v\u00e9rifications ping et TCP ajout\u00e9es l\u00e0 o\u00f9 elles aident \u00e0 diff\u00e9rencier probl\u00e8mes r\u00e9seau et probl\u00e8mes applicatifs.<\/p>\n<h2 id='\u00e9tape-3-r\u00e9glez-la-bonne-fr\u00e9quence-de-v\u00e9rification'  id=\"boomdevs_8\" id=\"step-3-set-the-right-check-frequency\">\u00c9tape 3 : R\u00e9glez la bonne fr\u00e9quence de v\u00e9rification<\/h2>\n<p>L\u2019intervalle de v\u00e9rification est le plafond de la rapidit\u00e9 de d\u00e9tection. Une panne qui commence quelques secondes apr\u00e8s une v\u00e9rification r\u00e9ussie va durer presque tout l\u2019intervalle avant que la prochaine v\u00e9rification puisse la d\u00e9tecter, puis la v\u00e9rification et l\u2019alerte ajoutent encore du temps.<\/p>\n<p>Face \u00e0 un objectif de disponibilit\u00e9, ce d\u00e9lai co\u00fbte cher. Un objectif mensuel de 99,9% tol\u00e8re environ 43 minutes de panne. Un intervalle de cinq minutes peut consommer plus d\u2019un dixi\u00e8me de ce budget avant que quiconque sache qu\u2019il y a un probl\u00e8me, ce qui fait partie du v\u00e9ritable <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/quel-est-le-cout-des-temps-darret\/\">co\u00fbt des arr\u00eats<\/a>. Consid\u00e9rez cela comme un budget de d\u00e9tection : d\u00e9cidez combien du budget mensuel vous \u00eates pr\u00eat \u00e0 perdre avant que le premier humain soit inform\u00e9. Avec 10% d\u2019un budget 99,9%, vous obtenez environ 4 minutes, ce qui exclut une v\u00e9rification toutes les cinq minutes avant m\u00eame d\u2019envisager une escalade. En termes de revenus, un site qui gagne 5 000 $\/heure perd plus de 400 $ durant une fen\u00eatre invisible de cinq minutes. Comme r\u00e8gle pratique :<\/p>\n<ul>\n<li><strong>Toutes les minutes<\/strong> pour les objectifs critiques pour le chiffre d\u2019affaires : paiement, connexion, APIs de paiement, tout ce qui est sous SLA formel.<\/li>\n<li><strong>Toutes les 3 \u00e0 5 minutes<\/strong> pour les sites marketing standard et pages de contenu.<\/li>\n<li><strong>Toutes les 15 \u00e0 60 minutes<\/strong> pour les outils internes, environnements de staging, et services \u00e0 faible enjeu.<\/li>\n<\/ul>\n<p>Les v\u00e9rifications HTTP l\u00e9g\u00e8res sont assez \u00e9conomiques pour \u00eatre ex\u00e9cut\u00e9es \u00e0 haute fr\u00e9quence partout. Les v\u00e9rifications plus lourdes bas\u00e9es sur navigateur viennent souvent en compl\u00e9ment \u00e0 rythme plus lent, superpos\u00e9es aux v\u00e9rifications rapides basiques. Pour un traitement plus approfondi de l\u2019interaction entre intervalle et g\u00e9ographie, voyez ce guide sur <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/frequence-de-la-surveillance-synthetique\/\">la fr\u00e9quence de surveillance et les emplacements<\/a>.<\/p>\n<h2 id='\u00e9tape-4-surveillez-depuis-plusieurs-emplacements'  id=\"boomdevs_9\" id=\"step-4-monitor-from-multiple-locations\">\u00c9tape 4 : Surveillez depuis plusieurs emplacements<\/h2>\n<p>Un seul emplacement de surveillance vous donne un seul point de vue, ce qui cr\u00e9e deux modes de panne simultan\u00e9s. Vous manquez les pannes qui affectent seulement certaines r\u00e9gions, comme un mauvais edge CDN, une mauvaise configuration geo-DNS, ou un probl\u00e8me de routage entre un FAI et votre h\u00f4te. Et vous subissez les probl\u00e8mes du r\u00e9seau d\u2019un seul emplacement comme fausses alertes.<\/p>\n<p>Choisissez des emplacements qui correspondent \u00e0 la localisation de vos utilisateurs. Un site desservant l\u2019Am\u00e9rique du Nord et l\u2019Europe doit \u00eatre v\u00e9rifi\u00e9 depuis les deux c\u00f4tes am\u00e9ricaines et au moins une ville europ\u00e9enne, pas depuis un seul centre de donn\u00e9es d\u2019un pays. Les plateformes disposant d\u2019un r\u00e9seau de surveillance global, Dotcom-Monitor parmi elles, vous permettent de s\u00e9lectionner des checkpoints sur plusieurs continents pour que le moniteur voie ce que votre audience r\u00e9elle voit.<\/p>\n<figure id=\"attachment_34495\" aria-describedby=\"caption-attachment-34495\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34495\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification.webp\" alt=\"Diagramme montrant une v\u00e9rification \u00e9chou\u00e9e d&apos;un emplacement de surveillance unique confirm\u00e9e par d&apos;autres emplacements avant d\u00e9clenchement d&apos;une alerte\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34495\" class=\"wp-caption-text\">V\u00e9rification multi-emplacements : une panne d\u00e9tect\u00e9e par un checkpoint est confirm\u00e9e par d\u2019autres avant qu\u2019une alerte ne soit d\u00e9clench\u00e9e.<\/figcaption><\/figure>\n<p>Plusieurs emplacements permettent aussi la double v\u00e9rification, dont d\u00e9pend l\u2019\u00e9tape 6 : lorsqu\u2019un site est signal\u00e9 en panne depuis un lieu, la plateforme v\u00e9rifie depuis d\u2019autres lieux avant de d\u00e9clarer le site indisponible. Et lorsqu\u2019un incident est r\u00e9el, le pattern g\u00e9ographique est votre premier diagnostic. Une panne depuis tous les emplacements pointe vers l\u2019origine, le DNS global, le certificat ou un mauvais d\u00e9ploiement. Une panne depuis une seule r\u00e9gion pointe vers un CDN, un routage r\u00e9gional, ou un fournisseur local. Un HTTP passant partout mais une assertion de contenu \u00e9chou\u00e9e pointe vers un mauvais template ou une page d\u2019erreur mise en cache. Chaque pattern est un ticket diff\u00e9rent pour un prestataire diff\u00e9rent, d\u2019o\u00f9 l\u2019importance de l\u2019analyse par emplacement avant de red\u00e9marrer un serveur.<\/p>\n<h2 id='\u00e9tape-5-configurez-les-alertes-et-l-escalade'  id=\"boomdevs_10\" id=\"step-5-set-up-alerting-and-escalation\">\u00c9tape 5 : Configurez les alertes et l\u2019escalade<\/h2>\n<p>La d\u00e9tection n\u2019a d\u2019importance que si la bonne personne agit. Avant le premier incident, d\u00e9cidez qui re\u00e7oit quelles alertes, par quel canal, et dans quel ordre :<\/p>\n<ul>\n<li><strong>Adaptez le canal \u00e0 la gravit\u00e9.<\/strong> L\u2019email convient pour un certificat expirant dans 30 jours. Une panne dure confirm\u00e9e doit sonner au t\u00e9l\u00e9phone, SMS, ou dans l\u2019outil d\u2019astreinte suivi par votre \u00e9quipe. La <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/fonctionnalites-alertes\/\">livraison d\u2019alerte<\/a> peut s\u2019effectuer par email, SMS, t\u00e9l\u00e9phone, et int\u00e9grations avec Slack, Teams et PagerDuty.<\/li>\n<li><strong>Escaladez en cas de silence.<\/strong> La premi\u00e8re alerte va \u00e0 l\u2019ing\u00e9nieur d\u2019astreinte. Sans reconnaissance dans un d\u00e9lai donn\u00e9, elle passe automatiquement au niveau suivant. Une alerte non vue est une alerte qui n\u2019existe pas.<\/li>\n<li><strong>Alertez sur la d\u00e9gradation, pas seulement la panne.<\/strong> Un temps de r\u00e9ponse qui triple est souvent le pr\u00e9lude \u00e0 une panne. Un seuil d\u2019alerte sur la performance vous donne du temps qu\u2019une alerte binaire up\/down ne donnera jamais.<\/li>\n<li><strong>Coupez le son pour la maintenance planifi\u00e9e.<\/strong> Les fen\u00eatres programm\u00e9es emp\u00eachent les d\u00e9ploiements de d\u00e9ranger qui que ce soit, ce qui prot\u00e8ge la cr\u00e9dibilit\u00e9 de toutes les alertes qui se d\u00e9clenchent.<\/li>\n<\/ul>\n<p>R\u00e9digez l\u2019alerte comme un contrat : ce qui a \u00e9chou\u00e9, d\u2019o\u00f9, depuis combien de temps, et ce qui a chang\u00e9 depuis la derni\u00e8re bonne v\u00e9rification. \u00ab \u00c9chec du contr\u00f4le contenu de paiement depuis Francfort et Londres pour deux cycles cons\u00e9cutifs ; DNS et TLS pass\u00e9s ; &#8216;R\u00e9capitulatif de commande&#8217; attendu non trouv\u00e9 ; dernier succ\u00e8s 09:41 UTC \u00bb donne au r\u00e9pondeur une hypoth\u00e8se de d\u00e9part. Un simple \u00ab site down \u00bb agit comme une sir\u00e8ne.<\/p>\n<p>Pour un ensemble complet de r\u00e8gles sur les seuils, le routage et les niveaux d\u2019escalade, voyez ces <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/website-monitoring-alerts\/\">pratiques d\u2019alertes pour la surveillance web<\/a>.<\/p>\n<h2 id='\u00e9tape-6-\u00e9liminez-les-faux-positifs'  id=\"boomdevs_11\" id=\"step-6-cut-out-false-positives\">\u00c9tape 6 : \u00c9liminez les faux positifs<\/h2>\n<p>Les faux positifs font mourir les programmes de surveillance. Quelques alertes \u00e0 3 heures du matin qui s\u2019av\u00e8rent sans cause, et l\u2019ing\u00e9nieur d\u2019astreinte finit par ignorer la seule vraie alerte. La plupart des fausses alertes viennent de quatre sources : des instabilit\u00e9s r\u00e9seau transitoires entre checkpoint et site, des d\u00e9lais trop courts par rapport au comportement normal du site, des probl\u00e8mes au niveau de la localisation de surveillance elle-m\u00eame, et des d\u00e9ploiements que personne n\u2019a signal\u00e9s au moniteur.<\/p>\n<p>Chacun a une parade directe :<\/p>\n<ul>\n<li><strong>Confirmez depuis un second emplacement avant d\u2019alerter.<\/strong> Une seule v\u00e9rification \u00e9chou\u00e9e doit d\u00e9clencher une re-v\u00e9rification imm\u00e9diate depuis d\u2019autres checkpoints, pas une page. Sur Dotcom-Monitor, un emplacement en d\u00e9saccord avec les autres d\u00e9clenche des v\u00e9rifications depuis tous les emplacements s\u00e9lectionn\u00e9s, pour que la mauvaise journ\u00e9e d\u2019un checkpoint ne d\u00e9clenche pas d\u2019alerte seul.<\/li>\n<li><strong>R\u00e9glez les d\u00e9lais \u00e0 partir de donn\u00e9es, pas d\u2019espoir.<\/strong> Basez les seuils sur les temps de r\u00e9ponse r\u00e9els de votre site, avec marge, pour que les pages lentes mais fonctionnelles soient des alertes de performance plut\u00f4t que des pannes fant\u00f4mes.<\/li>\n<li><strong>Validez le contenu, pas seulement la connectivit\u00e9.<\/strong> Les assertions par mot-cl\u00e9 fonctionnent dans les deux sens : elles d\u00e9tectent des pannes douces qu\u2019un code de statut manque, et emp\u00eachent un moniteur de signaler une page comme indisponible quand seul un widget tiers lent est probl\u00e9matique, car la v\u00e9rification cible ce qui doit \u00eatre rendu, pas tout ce qui pourrait l\u2019\u00eatre.<\/li>\n<li><strong>Mettez les d\u00e9ploiements au calendrier.<\/strong> Les fen\u00eatres de maintenance sont la solution la moins co\u00fbteuse aux faux positifs.<\/li>\n<\/ul>\n<p>Ensuite, triez le bruit restant en trois cat\u00e9gories lors d\u2019une revue hebdomadaire : mauvais point de vue, mauvais seuil, ou mauvaise d\u00e9finition de disponible. Un mauvais point de vue re\u00e7oit une confirmation multi-emplacement. Un mauvais seuil est r\u00e9ajust\u00e9 \u00e0 partir des temps de r\u00e9ponse r\u00e9els de votre site. Une mauvaise d\u00e9finition a une assertion de contenu plus stricte. Une alerte qui ne rentre dans aucune de ces trois cat\u00e9gories reste bruyante jusqu\u2019\u00e0 ce que vous la compreniez, car la cacher derri\u00e8re un intervalle plus long ne fait que retarder l\u2019incident r\u00e9el.<\/p>\n<h2 id='\u00e9tape-7-mesurez-le-uptime-par-rapport-\u00e0-votre-sla'  id=\"boomdevs_12\" id=\"step-7-measure-uptime-against-your-sla\">\u00c9tape 7 : Mesurez le uptime par rapport \u00e0 votre SLA<\/h2>\n<p>Chaque r\u00e9sultat de v\u00e9rification alimente un enregistrement permanent de disponibilit\u00e9, et ce record transforme la surveillance d\u2019un d\u00e9tecteur de fum\u00e9e en preuve. Les objectifs de disponibilit\u00e9 semblent abstraits jusqu\u2019\u00e0 ce que vous les convertissiez en minutes :<\/p>\n<table>\n<thead>\n<tr>\n<th>Objectif de disponibilit\u00e9<\/th>\n<th>Temps d\u2019arr\u00eat autoris\u00e9 par mois de 30 jours<\/th>\n<th>Temps d\u2019arr\u00eat autoris\u00e9 par an<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>99%<\/td>\n<td>7,2 heures<\/td>\n<td>Environ 3,7 jours<\/td>\n<\/tr>\n<tr>\n<td>99,9 % (\u00ab trois neuf \u00bb)<\/td>\n<td>43,2 minutes<\/td>\n<td>Environ 8,8 heures<\/td>\n<\/tr>\n<tr>\n<td>99,95 %<\/td>\n<td>21,6 minutes<\/td>\n<td>Environ 4,4 heures<\/td>\n<\/tr>\n<tr>\n<td>99,99 % (\u00ab quatre neuf \u00bb)<\/td>\n<td>4,3 minutes<\/td>\n<td>Environ 53 minutes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Le calcul explique le conseil pr\u00e9c\u00e9dent sur la fr\u00e9quence : au niveau quatre-neuf, un intervalle de v\u00e9rification de cinq minutes peut manquer plus de temps d\u2019arr\u00eat que le budget mensuel total. Testez vos propres objectifs avec un <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/calculateur-de-disponibilite\/\">calculateur de disponibilit\u00e9<\/a> pour voir ce que votre SLA promet r\u00e9ellement en minutes.<\/p>\n<p>Gardez le record ind\u00e9pendant. Si votre h\u00e9bergeur ou CDN s\u2019engage sur un SLA, votre demande de cr\u00e9dits repose sur vos propres donn\u00e9es mesur\u00e9es de l\u2019ext\u00e9rieur, pas sur la page de statut du fournisseur. Gardez ces preuves sobres et exportables : timestamp, localisation du checkpoint, IP r\u00e9solue, r\u00e9sultat TLS, statut HTTP, temps de r\u00e9ponse, et l\u2019assertion \u00e9chou\u00e9e. Une capture d\u2019\u00e9cran d\u2019une page de statut est un argument ; un historique des v\u00e9rifications avec emplacement est une preuve, que vous demandiez des cr\u00e9dits ou souteniez une page de statut publique. Des <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/uptime-and-sla-reports\/\">rapports programm\u00e9s de disponibilit\u00e9 et SLA<\/a> peuvent d\u00e9poser ce record automatiquement dans les bo\u00eetes mail des parties prenantes, ventil\u00e9s par v\u00e9rification et emplacement. Cette ventilation compte : une moyenne globale saine peut cacher une r\u00e9gion pass\u00e9e toute la journ\u00e9e de mardi en panne.<\/p>\n<h2 id='au-del\u00e0-du-uptime-surveillez-les-parcours-complets-des-utilisateurs'  id=\"boomdevs_13\" id=\"beyond-uptime-monitor-full-user-journeys\">Au-del\u00e0 du uptime : Surveillez les parcours complets des utilisateurs<\/h2>\n<p>Tout ce qui pr\u00e9c\u00e8de r\u00e9pond \u00e0 une question : le site est-il accessible et r\u00e9pond-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\u2019une v\u00e9rification d\u2019URL unique ne touche jamais.<\/p>\n<p>Pour les \u00e9quipes marketing, le parcours \u00e0 sc\u00e9nariser est celui promis par vos campagnes. Si le r\u00e9f\u00e9rencement payant envoie les visiteurs vers \u00ab Commencer l\u2019essai gratuit \u00bb, le script doit charger la page d\u2019atterrissage, cliquer sur le CTA, remplir le formulaire avec des donn\u00e9es s\u00fbres pour les tests, et confirmer l\u2019\u00e9tat de remerciement. Quand ce parcours casse en pleine campagne, le uptime de la page d\u2019accueil est une m\u00e9trique de vanit\u00e9.<\/p>\n<p>C\u2019est le r\u00f4le de la <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/synthetic-monitoring\/\">surveillance synth\u00e9tique<\/a> : sessions script\u00e9es dans un vrai navigateur qui parcourent \u00e9tape par \u00e9tape vos parcours critiques et signalent l\u2019\u00e9tape exacte qui a \u00e9chou\u00e9. Avec un enregistreur comme <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/fonctionnalites\/everystep\/\">EveryStep<\/a>, un flux de paiement ou de connexion devient un script supervis\u00e9 r\u00e9p\u00e9table sans \u00e9crire de code. Une fois les sept \u00e9tapes ici solides, la surveillance au niveau transactionnel est la couche suivante naturelle.<\/p>\n<h2 id='en-r\u00e9sum\u00e9'  id=\"boomdevs_14\" id=\"the-bottom-line\">En r\u00e9sum\u00e9<\/h2>\n<p>Bien surveiller le uptime d\u2019un site signifie construire la pile de v\u00e9rit\u00e9, pas cocher une case. D\u00e9finissez disponible en termes m\u00e9tier et nommez l\u2019\u00e9tat de panne contre lequel vous vous prot\u00e9gez. Couvrez chaque couche qu\u2019une requ\u00eate traverse avec des v\u00e9rifications HTTP, ping, TCP, DNS et certificat, et sachez o\u00f9 chacune peut tromper. Ex\u00e9cutez-les dans un budget de d\u00e9tection que votre SLA peut supporter. V\u00e9rifiez depuis les lieux de vie de vos utilisateurs. R\u00e9digez des alertes qui portent une hypoth\u00e8se, escaladez en cas de silence, confirmez avant d\u2019alerter, et gardez un enregistrement ind\u00e9pendant, exportable, de votre vraie disponibilit\u00e9, par r\u00e9gion et par v\u00e9rification.<\/p>\n<p>Configur\u00e9 ainsi, un moniteur de uptime cesse d\u2019\u00eatre une case \u00e0 cocher et devient le premier syst\u00e8me \u00e0 savoir qu\u2019un probl\u00e8me existe, des minutes avant vos clients. Ce gain de temps est tout l\u2019enjeu.<\/p>\n<section class=\"final-cta\">\n<h2 id='commencez-\u00e0-surveiller-votre-disponibilit\u00e9-en-quelques-minutes'  id=\"boomdevs_15\">Commencez \u00e0 surveiller votre disponibilit\u00e9 en quelques minutes<\/h2>\n<p>Configurez des v\u00e9rifications HTTP, ping, TCP, DNS et SSL depuis un r\u00e9seau mondial de surveillance avec <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/disponibilite\/\">la surveillance du uptime Dotcom-Monitor<\/a>, puis configurez les alertes que votre \u00e9quipe d\u2019astreinte saura vraiment prendre en compte. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">D\u00e9marrez un essai gratuit<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Comment surveiller le temps de disponibilit\u00e9 du site web \u00e9tape par \u00e9tape : v\u00e9rifier les types, la fr\u00e9quence, la v\u00e9rification multi-emplacements, les alertes et les rapports SLA.<\/p>\n","protected":false},"author":21,"featured_media":34490,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3446],"tags":[],"class_list":["post-28356","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-classifiee"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/28356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=28356"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/28356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34490"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=28356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=28356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=28356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}