Il existe une phrase qu’on entend souvent quand un site dysfonctionne : « pourtant l’outil de surveillance n’a rien signalé ». Elle est presque toujours vraie, et c’est bien le problème.
La quasi-totalité des outils de supervision répondent à une seule question : est-ce que le serveur répond ? Cette question a cessé d’être intéressante il y a longtemps. Un site peut renvoyer un 200 OK en 180 millisecondes et n’afficher, pour un visiteur, qu’un empilement de texte brut sans mise en page, sans bouton, sans possibilité de commander.
Ce que mesure vraiment un test de disponibilité
Un test de disponibilité classique ouvre une connexion, demande une page, reçoit un code de réponse, mesure le temps écoulé, et referme. Si le code appartient à la famille des 200, c’est vert.
Or cette page qu’il vient de recevoir n’est qu’un document HTML. Elle ne devient un site qu’une fois que le navigateur a téléchargé les feuilles de style, les scripts et les polices qu’elle réclame. Le test, lui, ne les demande jamais. Il ignore donc par construction tout ce qui se passe après la première réponse.
Trois conséquences concrètes, et nous les avons toutes vues sur des sites réels :
Une feuille de style qui disparaît au moment d’un déploiement. La page répond parfaitement, le visiteur voit une page nue. Vert.
Une base de données qui ne répond plus, et un WordPress qui sert alors une page d’erreur soignée avec un code de réponse impeccable. Vert.
Un noindex oublié après une mise en ligne, qui demande poliment à Google de ne pas référencer la page. Vert, pendant les trois semaines où le trafic s’effondre.
Le deuxième problème, moins visible : l’outil qui alerte trop
Admettons que vous ayez un outil plus curieux, qui regarde au-delà du code de réponse. Un autre piège vous attend, et il est plus insidieux, parce qu’il ressemble à de la vigilance.
Un outil qui envoie quarante courriels quand un serveur héberge quarante sites finit filtré. Un outil qui alerte sur une lenteur passagère, sur un avertissement de console, sur une différence de mise en page qui vient d’une refonte volontaire, finit filtré aussi. Et le jour où il a raison, personne ne lit.
Une supervision filtrée est plus dangereuse qu’une absence de supervision, parce qu’elle donne le sentiment d’être couvert. C’est ce qui nous est arrivé, et le récit de la matinée où j’ai reçu 47 alertes dont 43 étaient fausses est probablement plus parlant qu’une explication de principe.
Les trois questions à poser à qui surveille votre site
Vous n’avez pas à devenir expert du sujet. Trois questions suffisent à savoir si votre site est surveillé ou seulement pingué.
« Est-ce que vous vérifiez la page, ou seulement le code de réponse ? » La bonne réponse mentionne les feuilles de style et les scripts. La réponse évasive parle de « monitoring 24/7 » sans jamais dire ce qui est mesuré.
« Comment vous savez que la base de données répond ? » La bonne réponse repose sur quelque chose de vérifiable dans le contenu de la page, une phrase qui ne peut venir que de la base. Sans ça, une page d’erreur de la bonne couleur passe pour un site en bonne santé.
« Qu’est-ce qui ne déclenche pas d’alerte ? » C’est la question qui trie vraiment. Une supervision sérieuse sait dire ce qu’elle refuse de signaler, et pourquoi. Une supervision qui prétend tout alerter finira dans un dossier que personne n’ouvre.
Le classement qu’on a fini par adopter
En reprenant notre propre moteur de détection, nous avons séparé deux familles de problèmes, et cette séparation a plus changé la vie de nos boîtes mail que n’importe quel réglage de seuil.
Ce qui empêche un visiteur d’utiliser le site. Le site ne répond plus, la base est muette, le certificat est invalide, le tunnel d’achat renvoie une erreur. Ça mérite un courriel, et à toute heure.
Ce qui abîme le site sans l’arrêter. Une mise en page dégradée, une lenteur inhabituelle, un noindex en place, un fichier manquant. Ça mérite d’être écrit noir sur blanc dans l’outil, avec la cause exacte, et d’être traité le lendemain matin. Pas de réveil à trois heures.
La conséquence technique est nette : dans notre moteur, un problème d’apparence ne peut plus, structurellement, être annoncé comme une panne. Ce n’est pas un réglage qu’on peut mal cocher, c’est une règle du code.
Ce que ça change pour vous, concrètement
Si vous vendez en ligne, la question n’est pas « mon site est-il en ligne » mais « un client peut-il commander à cette minute ». Ce sont deux questions différentes, et seule la seconde a un rapport avec votre chiffre d’affaires.
Si vous êtes responsable marketing, la question est « est-ce que Google voit encore mes pages ». Un noindex oublié ne se voit dans aucun tableau de bord de disponibilité, et il se paie trois semaines plus tard dans les statistiques d’audience.
Si vous êtes DSI, la question est « qu’est-ce qu’on mesure, et qui peut le vérifier ». C’est le point 4 de notre grille de diagnostic technique en douze points, et c’est celui sur lequel la réponse est le plus souvent partielle.
Pour aller plus loin
La suite logique de cet article, c’est la liste : sept pannes qu’un test de disponibilité ne voit pas, avec pour chacune le symptôme, la raison pour laquelle elle passe inaperçue, et la façon de la détecter. Le récit de notre propre erreur est dans 47 alertes un matin, 43 étaient fausses.
L’outil que nous avons construit pour répondre à ces trois questions s’appelle UptimeEZ, son code est public, et c’est lui qui tient la partie surveillance de notre filet de sécurité. Si vous voulez simplement savoir ce qu’il trouverait sur votre site, demandez-nous de le brancher : la réponse arrive en quelques minutes.