Le logiciel de monitoring site web, d’une simple vérification de disponibilité à tout un parcours utilisateur

Un logiciel de monitoring de site web est un ensemble de machines situées en dehors de votre infrastructure qui ouvrent votre site selon un calendrier, en votre nom, et vous préviennent au moment précis où la réponse cesse d’être celle que vous attendez. C’est toute l’idée. Tout le reste de cette page n’est qu’un détail sur ce qui compte comme la réponse : un code de statut, un fragment de texte sur la page, un temps de réponse, un champ JSON, une date d’expiration de certificat, une lecture de CPU, ou le résultat d’un parcours de paiement en cinq étapes.

La raison pour laquelle cela doit s’exécuter depuis l’extérieur est que les pannes dont vous avez le plus besoin d’être informé sont invisibles de l’intérieur. Un serveur dont le disque est plein continue de se déclarer sain sur son propre tableau de bord. Un enregistrement DNS qui pointe vers une adresse mise hors service se résout parfaitement bien depuis le bureau où le cache est encore chaud. Un certificat expiré à 2 heures du matin casse tous les navigateurs de la planète pendant que votre propre équilibreur de charge continue de répondre. La surveillance de disponibilité externe est ce qui comble cet écart, parce qu’elle voit exactement ce que voit un visiteur.

La seconde raison est la preuve. Quand votre hébergeur vous dit que la panne a duré quatre minutes et que vos clients vous disent qu’elle a duré une heure, un relevé indépendant de chaque vérification, depuis chaque emplacement, avec horodatage, tranche le débat. C’est aussi à partir de ce relevé que sont construits un rapport de disponibilité mensuel et une page de statut publique.

1. Étape 1VérifierUn point de contrôle exécute votre vérification à l’intervalle que vous avez défini, jusqu’à une fois par minute, depuis les emplacements que vous avez choisis.
2. Étape 2ConfirmerUn échec est revérifié depuis d’autres points de contrôle avant que quoi que ce soit ne soit déclaré en panne, afin qu’un mauvais itinéraire réseau ne soit pas confondu avec une panne.
3. Étape 3AlerterLes contacts abonnés à ce moniteur sont prévenus sur les canaux qu’ils ont choisis, puis à nouveau lorsque le service est rétabli.
4. Étape 4EnregistrerChaque résultat est conservé avec son emplacement et son horodatage, alimentant les chiffres de disponibilité, l’historique des incidents et les rapports.

Le serveur ne répond plus. La panne évidente, et toujours la plus fréquente : le site expire ou renvoie une page d’erreur que personne ne voit avant qu’un client n’appelle. La surveillance de disponibilité envoie une requête HTTP ou HTTPS vers votre adresse jusqu’à une fois par minute depuis plus de 300 points de contrôle, confirme la panne depuis d’autres emplacements avant de déclarer quoi que ce soit hors ligne, et alerte les personnes abonnées à ce moniteur.

Le certificat expire. Un certificat qui expire à 2 h du matin bloque tous les navigateurs de la planète alors que le serveur, lui, répond parfaitement : rien d’anormal dans vos propres journaux. La surveillance des certificats SSL suit la date d’expiration, la chaîne de confiance et le nom d’hôte du certificat, et vous prévient des semaines à l’avance plutôt qu’au moment où plus rien ne fonctionne.

Le domaine expire. L’avis de renouvellement est parti vers une adresse que plus personne ne lit, ou un enregistrement de serveur de noms a été modifié par quelqu’un qui ne travaille plus ici. La surveillance de l’expiration de domaine surveille la date d’enregistrement et les réponses DNS qui vont avec, pour qu’un domaine sur le point d’expirer soit une chose qu’on vous annonce et non une chose que vous découvrez.

Le domaine se retrouve sur liste noire. Une IP d’hébergement mutualisé, un compte compromis ou un serveur de messagerie mal configuré suffisent, et le premier symptôme est en général le silence : vos e-mails cessent tout simplement d’arriver. La surveillance des listes noires confronte votre domaine et votre adresse IP à des dizaines de listes selon un calendrier régulier et vous signale le jour même l’apparition d’un signalement.

Le site est signalé comme malveillant. Une extension compromise se met à servir quelque chose que Google n’aime pas, et les navigateurs affichent un écran rouge devant votre page d’accueil alors que le site fonctionne. La surveillance des malwares confronte vos URL à la base Google Web Risk en continu, pour que le signalement vous vienne de nous et non de votre courbe de trafic.

Les cinq tournent depuis la même liste de moniteurs, avec les mêmes contacts et sur la même facture — c’est tout l’intérêt. Ce sont les pannes qui partagent un seul symptôme, « chez moi le site marche », et elles coûtent le moins cher surveillées ensemble.

La disponibilité est le plancher, pas le plafond. Un site peut répondre à chaque requête par un 200 parfaitement sain alors que son formulaire de connexion est cassé, que sa recherche ne renvoie rien, ou que son API s’est mise à envoyer un tableau vide là où elle envoyait auparavant votre catalogue produits. Ces trois vérifications couvrent toute l’échelle : le serveur répond, le parcours qui le traverse se termine, et les réponses lisibles par une machine derrière lui restent correctes.

La lenteur est la panne que personne ne déclare. Les pages qui mettent huit secondes à charger ne déclenchent aucune alerte de panne, elles perdent simplement, en silence, les visiteurs qui n’allaient pas attendre - et cela dure des semaines avant que quiconque ne le remarque. Ces vérifications surveillent les trois couches où cela démarre généralement : la page telle qu’un vrai navigateur la charge, la machine qui la sert, et la base de données dont elle dépend.

Ce groupe existe à cause d’un type de panne bien particulier : rien ne s’est cassé, mais Internet a cessé de vous faire confiance. Un certificat expiré, un domaine que personne n’a renouvelé, un signalement de malware dû à une extension compromise, ou un serveur de messagerie atterri sur une liste noire, mettront chacun hors ligne un site pourtant parfaitement sain - et aucun d’entre eux n’apparaîtra dans une vérification de disponibilité qui ne lit que les codes de statut.

N’importe quel script peut vous envoyer un e-mail la première fois qu’une requête dépasse son délai. Le plus difficile, dans un service de surveillance, n’est pas de détecter les pannes, c’est d’avoir raison à leur sujet, parce qu’un service qui vous réveille à 3 heures du matin pour un accroc de routage se fait couper le son en moins d’un mois - et un moniteur réduit au silence ne protège plus rien.

Une vérification en échec n’est donc jamais, à elle seule, une alerte. HostTracker revérifie d’abord le site depuis d’autres points de contrôle. Si un emplacement ne parvient pas à joindre votre serveur alors que les autres le peuvent, il s’agit d’un problème réseau entre ce point de contrôle et vous, et c’est enregistré comme tel plutôt qu’escaladé. Vous décidez du nombre de confirmations nécessaires avant qu’un moniteur ne bascule en panne, et vous pouvez augmenter ce nombre pour un site derrière un réseau instable, ou le réduire pour un site où chaque seconde compte.

Un travail planifié reçoit le même traitement, dans l’autre sens : programmez une fenêtre de maintenance, et le moniteur continue de vérifier et d’enregistrer, mais personne n’est réveillé pour un déploiement dont tout le monde était déjà informé. Et comme chaque résultat porte l’emplacement d’où il vient, l’alerte elle-même est diagnostique. En panne depuis chaque point de contrôle, c’est un problème serveur. En panne depuis un seul pays, c’est un problème de routage ou de CDN. Lent depuis trois des douze emplacements que vous avez choisis, c’est un problème de capacité qui n’est pas encore devenu une panne.

La détection n’est que la moitié du travail d’un service de surveillance ; l’autre moitié consiste à joindre la bonne personne sur un canal auquel elle répondra vraiment. HostTracker envoie des alertes de panne par e-mail, SMS, appel vocal, Telegram, Slack, Microsoft Teams, PagerDuty, Viber, Discord, Pushover, Pushbullet, Mattermost, notification push et webhook, et vous pouvez en utiliser autant que vous le souhaitez à la fois.

Les contacts s’abonnent par moniteur plutôt que par compte, si bien que le développeur responsable du parcours de paiement n’est pas alerté pour une page d’atterrissage marketing, et que la personne qui renouvelle les domaines ne reçoit pas chaque délai HTTP dépassé. Les canaux peuvent être échelonnés comme une escalade d’alerte : un message Telegram immédiat, puis un appel téléphonique si le site est toujours en panne quelques minutes plus tard, puis une escalade vers une seconde personne. Les alertes de rétablissement sont envoyées sur les mêmes canaux, si bien qu’un incident se referme toujours explicitement au lieu de s’estomper.

Les webhooks sont là pour les cas qu’aucun des canaux précédents ne couvre. Ils publient l’incident vers l’outil que vous utilisez déjà, qu’il s’agisse de PagerDuty, d’un bot de discussion interne, d’une file de tickets, ou d’un script qui redémarre un service et rapporte ce qu’il a fait.

Chaque résultat de vérification est conservé, ce qui transforme un flux d’alertes en quelque chose sur lequel on peut vraiment raisonner. Le tableau de bord affiche l’état actuel de chaque moniteur ainsi que sa disponibilité sur n’importe quelle période que vous choisissez ; le journal des incidents liste chaque panne avec son début, sa durée et les emplacements qui l’ont constatée ; et des rapports de disponibilité et de SLA programmés peuvent arriver dans une boîte de réception chaque semaine ou chaque mois sans que personne n’ait à se connecter, ce qui est généralement exactement ce que réclame une conversation autour d’un SLA ou un contrat client.

Quand vos utilisateurs ont besoin de la même information, la publier vaut mieux que d’y répondre quarante fois. Créez une page de statut publique gratuite à partir des moniteurs que vous exploitez déjà : pourcentages de disponibilité en direct, une chronologie des incidents que vous pouvez annoter au fur et à mesure de l’avancement, et des mises à jour par e-mail ou RSS pour qui s’y abonne. Ce sont les mêmes données que celles affichées par votre tableau de bord, filtrées selon ce que vous acceptez de rendre public.

Si vous déboguez déjà avec un assistant IA ouvert, le réseau de surveillance peut lui répondre directement. Le serveur MCP de HostTracker pour assistants IA expose des vérifications instantanées via le Model Context Protocol, si bien que Claude, Cursor et d’autres clients MCP peuvent lancer une vérification HTTP depuis l’Europe et l’Asie, résoudre du DNS, rechercher des inscriptions sur liste noire ou tracer un itinéraire réseau, et relire les résultats dans la même conversation où vous cherchez ce qui s’est cassé.

Il utilise votre propre jeton d’API HostTracker et les mêmes 300+ points de contrôle que tout le reste de cette page. Il n’y a pas de tableau de bord séparé à apprendre, ni rien à garder synchronisé, car c’est le même service qui répond.

Chaque type de vérification présent sur cette page est disponible sur chaque offre. Ce que l’offre détermine, c’est l’échelle : combien de moniteurs vous exploitez et à quelle fréquence ils sont autorisés à vérifier. C’est délibéré, car la différence entre un blog personnel et une boutique en ligne n’est pas dans les fonctionnalités dont ils ont besoin, mais dans la rapidité avec laquelle ils doivent être informés d’un problème.

L’offre gratuite est permanente et surveille deux sites toutes les 30 minutes, ce qui suffit à détecter un certificat expiré ou un site tombé en panne pendant la nuit. Les offres payantes démarrent avec Solo à 9 $ par mois, puis Webmaster à 14 $ et Business à 29 $, avec un niveau Enterprise pour les parcs plus importants. Les nouveaux comptes bénéficient d’un essai de 30 jours avec 100 moniteurs et des vérifications à la minute, sans carte bancaire requise, afin que vous puissiez mesurer un vrai mois de votre propre disponibilité avant de vous engager.

La façon honnête de choisir est de partir de votre intervalle de vérification et de remonter. Si une panne de cinq minutes ne vous coûte rien, surveillez toutes les cinq minutes et payez moins cher. Si elle vous coûte des commandes, surveillez chaque minute, et l’offre se rentabilise dès la première fois qu’elle vous évite cinquante minutes de panne passée inaperçue. Comparez toutes les offres et tous les tarifs de surveillance.