{"id":34138,"date":"2026-06-12T01:22:41","date_gmt":"2026-06-12T01:22:41","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-monitoring-alerts\/"},"modified":"2026-06-12T13:29:30","modified_gmt":"2026-06-12T13:29:30","slug":"alertes-de-surveillance-de-sites-web","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/alertes-de-surveillance-de-sites-web\/","title":{"rendered":"Alertes de surveillance de site Web – Maximisez le temps de disponibilit\u00e9 et r\u00e9duisez le bruit"},"content":{"rendered":"

Mise \u00e0 jour juin 2026 \u00b7 lecture de 11 minutes<\/em><\/p>\n

\"Ing\u00e9nieur
L’objectif n’est pas d’avoir plus d’alertes. C’est d’avoir moins d’alertes, mais chacune ayant un sens.<\/figcaption><\/figure>\n

<\/p>\n

Demandez \u00e0 tout ing\u00e9nieur de garde ce qu’il pense de sa surveillance et il vous dira la m\u00eame chose : les alertes ne sont pas le probl\u00e8me. C’est le bruit. Une pile typique d\u00e9clenche une alerte \u00e0 chaque \u00e9chantillon lent, \u00e0 chaque br\u00e8ve perte locale, \u00e0 chaque v\u00e9rification d\u00e9pendante qui \u00e9choue quand un service en amont tombe en panne. Apr\u00e8s quelques semaines, les gens arr\u00eatent de lire les alertes. Et la nuit o\u00f9 une panne r\u00e9elle survient, elle se retrouve dans le m\u00eame canal muet que 200 faux positifs.<\/p>\n

C’est ainsi que la fatigue li\u00e9e aux alertes augmente le temps moyen de r\u00e9solution. La d\u00e9tection n’a jamais \u00e9t\u00e9 le goulot d’\u00e9tranglement. Le signal a \u00e9t\u00e9 enterr\u00e9. Ce guide explique comment cr\u00e9er des alertes de surveillance de site web qui ne se d\u00e9clenchent que lorsque l’exp\u00e9rience utilisateur est r\u00e9ellement compromise, pour que votre \u00e9quipe leur fasse suffisamment confiance pour agir lorsqu’elles se produisent. Nous aborderons la logique de confirmation, les niveaux d’escalade, la suppression consciente des d\u00e9pendances et les calculs de seuil, avec les r\u00e9glages exacts qui distinguent une rotation de garde calme d’un pager que personne ne r\u00e9pond.<\/p>\n

Pourquoi la majorit\u00e9 des alertes sont du bruit et non du signal<\/h2>\n

Une alerte de surveillance a un seul but : informer un humain qu’il y a un probl\u00e8me \u00e0 r\u00e9soudre. La plupart des alertes \u00e9chouent \u00e0 cette t\u00e2che selon trois sch\u00e9mas communs, chacun ayant une solution simple.<\/p>\n

Les faux positifs sur un seul emplacement sont les plus fr\u00e9quents. Un agent de surveillance \u00e0 Francfort rencontre un accroc r\u00e9seau temporaire, le contr\u00f4le \u00e9choue, l’alerte se d\u00e9clenche, et votre site n’a jamais \u00e9t\u00e9 en panne pour un utilisateur r\u00e9el. Surveiller la disponibilit\u00e9 depuis un seul emplacement fait que certains de vos pages affichent des pertes de paquets entre votre moniteur et votre origine, pas de vraies pannes.<\/p>\n

Ensuite viennent les seuils instables (flapping). Vous r\u00e9glez une alerte de temps de r\u00e9ponse \u00e0 2 000 ms parce que cela semblait lent. Mais votre p95 (temps de r\u00e9ponse que vos 5 % de requ\u00eates les plus lentes rencontrent r\u00e9ellement) se situe d\u00e9j\u00e0 autour de 1 800 ms lors des pics de trafic, donc l’alerte se d\u00e9clenche chaque apr\u00e8s-midi, se r\u00e9sout d’elle-m\u00eame, et se d\u00e9clenche \u00e0 nouveau. Personne n’agit dessus parce qu’il n’y a rien \u00e0 faire. Le chiffre \u00e9tait mauvais, pas le site.<\/p>\n

Et puis il y a la temp\u00eate d’alertes. La r\u00e9solution DNS \u00e9choue pour votre domaine. Maintenant, votre contr\u00f4le de page d’accueil \u00e9choue, votre contr\u00f4le de connexion \u00e9choue, votre contr\u00f4le de panier \u00e9choue, vos contr\u00f4les API \u00e9chouent, et votre contr\u00f4le SSL \u00e9choue car le moniteur ne peut m\u00eame pas atteindre l’h\u00f4te. Une cause racine, quarante alertes, toutes d\u00e9clench\u00e9es dans la m\u00eame minute. L’ing\u00e9nieur de garde doit lire les quarante alertes pour trouver celle qui compte.<\/p>\n

Corrigez ces trois sch\u00e9mas et vous \u00e9liminez la majeure partie du bruit. La suite de ce guide explique comment.<\/p>\n

Confirmer une panne avant de pr\u00e9venir quelqu\u2019un<\/h2>\n

Le changement \u00e0 plus fort impact que vous pouvez faire est d’exiger une confirmation avant qu’une alerte ne soit d\u00e9clench\u00e9e, et Dotcom-Monitor est con\u00e7u pour appliquer exactement cela. Plut\u00f4t que de contacter d\u00e8s la premi\u00e8re v\u00e9rification \u00e9chou\u00e9e, vous configurez les conditions que l\u2019\u00e9chec doit respecter avant qu\u2019on n\u2019en parle : accord venant de plusieurs emplacements, et plusieurs \u00e9checs cons\u00e9cutifs. Les deux sont configur\u00e9s par moniteur, vous d\u00e9cidez donc combien de preuves chaque contr\u00f4le doit fournir avant de lancer une alerte.<\/p>\n

La confirmation multi-emplacements \u00e9limine le faux positif \u00e0 la source. Si une v\u00e9rification \u00e9choue depuis Francfort mais r\u00e9ussit simultan\u00e9ment depuis Dallas, Londres et Singapour, le probl\u00e8me vient de la route vers Francfort, pas de votre site. Une vraie panne \u00e9choue partout. C\u2019est le r\u00f4le du r\u00e9seau mondial de surveillance<\/a> de Dotcom-Monitor : quand un contr\u00f4le \u00e9choue, Dotcom-Monitor le reteste automatiquement depuis plusieurs sites avant d\u2019envoyer une alerte, ainsi un simple incident r\u00e9gional ne d\u00e9range jamais votre rotation de garde. Vous entendez seulement parler des pannes confirm\u00e9es par plusieurs points de vue.<\/p>\n

La logique d\u2019\u00e9checs cons\u00e9cutifs g\u00e8re les glitches momentan\u00e9s. Dans le syst\u00e8me d\u2019alertes<\/a> de Dotcom-Monitor, vous configurez une alerte pour qu\u2019elle ne se d\u00e9clenche qu\u2019apr\u00e8s deux ou trois \u00e9checs de suite, pas au premier. \u00c0 intervalle d\u2019une minute, cela ajoute un ou deux minutes de latence de d\u00e9tection en \u00e9change de la r\u00e9duction du bruit transitoire quasi \u00e0 z\u00e9ro. Pour la plupart des sites, ce compromis vaut clairement la peine, et comme le filtre est d\u00e9fini par moniteur, une page marketing peut tol\u00e9rer une confirmation plus lente qu\u2019un point de terminaison de paiement.<\/p>\n

La confirmation ajoute un l\u00e9ger d\u00e9lai. Si vous g\u00e9rez un syst\u00e8me o\u00f9 une seconde de panne est v\u00e9ritablement catastrophique, vous pourriez accepter plus de faux positifs pour une d\u00e9tection plus rapide. La majorit\u00e9 des \u00e9quipes ne sont pas dans ce cas, et ce compromis apporte des pagers plus calmes.<\/p>\n

Construisez des niveaux d\u2019escalade adapt\u00e9s \u00e0 la gravit\u00e9<\/h2>\n

Une alerte et une escalade ne sont pas la m\u00eame chose. L\u2019alerte signale qu\u2019une v\u00e9rification a \u00e9chou\u00e9. L\u2019escalade r\u00e8gle qui en est inform\u00e9, par quel canal, et ce qui se passe si personne ne r\u00e9pond. Une alerte uniforme, o\u00f9 chaque \u00e9chec alerte tout le monde de la m\u00eame mani\u00e8re, m\u00e8ne rapidement \u00e0 ce que l\u2019\u00e9quipe ignore ses pagers.<\/p>\n

\"Chemin
La gravit\u00e9 d\u00e9termine le canal. Le temps sans r\u00e9ponse d\u00e9termine l’escalade.<\/figcaption><\/figure>\n

<\/p>\n

Commencez par trier les \u00e9checs selon des niveaux de gravit\u00e9 et associer chacun \u00e0 un canal. Le principe est simple : plus le canal est bruyant, plus la barre \u00e0 franchir pour l\u2019utiliser est haute.<\/p>\n

\n\n\n\n\n\n\n\n
Gravit\u00e9<\/th>\nExemple<\/th>\nCanal<\/th>\nR\u00e9pondants<\/th>\n<\/tr>\n<\/thead>\n
Critique<\/td>\nPaiement ou connexion hors service, confirm\u00e9 depuis plusieurs emplacements<\/td>\nSMS, t\u00e9l\u00e9phone, PagerDuty<\/td>\nAssistance de garde, imm\u00e9diatement<\/td>\n<\/tr>\n
\u00c9lev\u00e9e<\/td>\nPage principale lente au-del\u00e0 du p95 pendant 10 minutes<\/td>\nSlack ou Teams, @on-call<\/td>\nAssistance de garde, dans l\u2019heure<\/td>\n<\/tr>\n
Faible<\/td>\nPage marketing lente, un seul actif en 404<\/td>\nR\u00e9sum\u00e9 par email, tableau de bord<\/td>\nR\u00e9vision le jour ouvrable suivant<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Puis ajoutez une escalade temporelle au-dessus de la gravit\u00e9. Une alerte critique arrive sur Slack et au technicien de garde en m\u00eame temps. Si elle est toujours active apr\u00e8s dix minutes, elle se r\u00e9p\u00e8te par SMS. Apr\u00e8s vingt minutes, elle notifie la garde secondaire ou le responsable d\u2019\u00e9quipe. Personne n\u2019a \u00e0 se souvenir d\u2019escalader manuellement \u00e0 3 heures du matin, et une alerte manqu\u00e9e ne devient pas une panne ignor\u00e9e.<\/p>\n

Dotcom-Monitor g\u00e8re cela avec des groupes de notifications et des horaires d\u2019escalade. Vous d\u00e9finissez qui est de garde, quels canaux chaque niveau utilise, et combien de temps une alerte attend avant de passer au responsable suivant. Il s\u2019int\u00e8gre aux canaux utilis\u00e9s par les \u00e9quipes, ainsi une notification Slack ou Microsoft Teams atteint les personnes actives et une escalade PagerDuty g\u00e8re les alertes hors heures. Le but est d\u2019orienter selon la gravit\u00e9, pas de diffuser tout partout en esp\u00e9rant qu\u2019on remarque quelque chose.<\/p>\n

Laissez les v\u00e9rifications de d\u00e9pendance supprimer les sympt\u00f4mes<\/h2>\n

La temp\u00eate d\u2019alertes est un probl\u00e8me structurel, et vous le r\u00e9solvez de fa\u00e7on structurelle. Vos contr\u00f4les ont un ordre de d\u00e9pendance, que la plupart des \u00e9quipes ignore. Une requ\u00eate vers votre page de panier d\u00e9pend d\u2019abord de la r\u00e9solution DNS, puis de la connexion TCP, puis de la r\u00e9ussite de la poign\u00e9e de main TLS, puis du retour HTTP de contenu, puis du succ\u00e8s m\u00eame de la transaction. Quand quelque chose en bas de cette cha\u00eene casse, tout ce qui est au-dessus \u00e9choue aussi.<\/p>\n

Classez donc votre surveillance dans l\u2019ordre dans lequel la requ\u00eate s\u2019ex\u00e9cute, et laissez la cause racine r\u00e9duire le bruit des sympt\u00f4mes. La surveillance multi-protocole de Dotcom-Monitor rend cela pratique : vous surveillez DNS, TCP, TLS, HTTP et la transaction compl\u00e8te comme contr\u00f4les s\u00e9par\u00e9s, ainsi quand un contr\u00f4le \u00e9choue vous voyez quelle couche a cass\u00e9 et alertez sur cette couche au lieu de la cascade derri\u00e8re.<\/p>\n

\"Infographie
Quand une couche basse casse, tout ce qui est au-dessus \u00e9choue aussi. Alertez sur la couche qui a cass\u00e9 en premier.<\/figcaption><\/figure>\n

<\/p>\n