Cette liste n’est pas théorique. Chacune de ces sept pannes est arrivée sur un site que nous surveillons, et aucune n’aurait été vue par un test de disponibilité classique. Pour chacune : ce que voit le visiteur, pourquoi l’outil de surveillance reste vert, et à quoi il faut regarder pour la détecter.
1. La feuille de style qui disparaît après une mise à jour
Le symptôme. Le visiteur reçoit la page, mais sans mise en page. Les titres sont énormes, les images en pleine largeur, les colonnes empilées, le bouton de commande ressemble à un lien souligné. Sur mobile, c’est illisible.
Pourquoi ça passe. Le fichier CSS manque, mais la page HTML, elle, répond parfaitement. Le cas le plus fréquent sur WordPress vient des extensions de cache qui fusionnent les feuilles de style dans un fichier généré : quand ce fichier est purgé et jamais régénéré, la page continue de le réclamer et reçoit une erreur 404. Le test de disponibilité ne demande pas ce fichier, donc il ne le voit pas.
Comment la détecter. Il faut demander chaque feuille de style et chaque script que la page réclame, vérifier qu’ils répondent, et vérifier leur poids par rapport à ce qu’ils pesaient quand tout allait bien. Un fichier qui répond 200 avec zéro octet est aussi cassé qu’un fichier absent, et c’est un cas qu’on rencontre plus souvent qu’on ne le croit.
2. La base de données muette derrière un code 200
Le symptôme. Une page d’erreur propre, parfois jolie, souvent en anglais. « Error establishing a database connection ». Le site est totalement inutilisable.
Pourquoi ça passe. C’est le cas le plus contre-intuitif de la liste : le serveur web fonctionne, il sert une page, et il la sert avec un code de réponse 200 OK. Techniquement, tout va bien. Métier, rien ne va.
Comment la détecter. Deux méthodes complémentaires. La première consiste à reconnaître les messages d’erreur : notre moteur en porte 41, parce que MySQL, MariaDB, WordPress, Laravel et PHP n’écrivent pas les mêmes phrases quand ils perdent leur base. La seconde est plus robuste : retenir une phrase qui ne peut venir que de la base, tirée du contenu du site, et vérifier qu’elle est toujours là. Si le texte de votre page d’accueil a disparu, la base n’a pas répondu, quelle que soit la page servie à la place.
3. Le noindex oublié après une mise en ligne
Le symptôme. Aucun. Le site est parfait. Le trafic organique s’effondre trois semaines plus tard.
Pourquoi ça passe. La balise qui demande aux moteurs de ne pas indexer la page est légitime pendant la recette, sur un site de préproduction. Elle devient une catastrophe quand elle survit à la mise en production. Et elle est invisible pour tout le monde : elle ne change rien à l’affichage, rien au temps de réponse, rien au code de réponse.
Comment la détecter. En lisant les instructions d’indexation dans le HTML reçu à chaque vérification. C’est peu coûteux, et c’est le genre de contrôle qui n’a d’intérêt que s’il tourne en continu : personne ne pense à le faire le jour où le problème apparaît.
4. Le certificat qui expire un samedi
Le symptôme. Le navigateur affiche un avertissement de sécurité pleine page. Beaucoup de visiteurs referment l’onglet, et une partie d’entre eux ne reviendront pas.
Pourquoi ça passe. Le renouvellement automatique fonctionne dans la grande majorité des cas, ce qui fait justement qu’on cesse d’y penser. Quand il échoue, il échoue en silence. Et un outil qui ne vérifie que la disponibilité peut très bien continuer à obtenir une réponse, selon la façon dont il gère les erreurs de certificat.
Comment la détecter. En regardant la date d’expiration à chaque passage, et en prévenant plusieurs jours avant, pas le jour même. Le corollaire souvent oublié : il faut aussi surveiller l’expiration du nom de domaine, qui ne se renouvelle pas tout seul, et dont l’oubli coûte beaucoup plus cher qu’un certificat.
5. Le domaine que personne n’a renouvelé
Le symptôme. Le site n’existe plus. Les adresses de courriel du domaine ne fonctionnent plus non plus, ce qui rend souvent la récupération plus longue.
Pourquoi ça passe. Le rappel de renouvellement part vers une adresse de courriel qui n’est plus lue, souvent celle d’un ancien prestataire ou d’un salarié parti. Aucun outil de supervision de disponibilité ne va interroger un registre de noms de domaine.
Comment la détecter. En interrogeant les registres, et en traitant cette échéance comme n’importe quelle autre : une date, un délai d’alerte, un responsable. C’est la panne la plus bête de la liste, et l’une des plus longues à réparer.
6. La sauvegarde nocturne qui s’est arrêtée en silence
Le symptôme. Aucun, pendant des mois. Puis un besoin de restauration, et la découverte que la dernière sauvegarde utilisable date de mars.
Pourquoi ça passe. Une tâche planifiée qui ne tourne plus ne produit rien : ni erreur, ni courriel, ni ligne de journal. Son absence est parfaitement silencieuse, et c’est ce qui la rend dangereuse. Une sauvegarde jamais testée n’est pas une sauvegarde, c’est une supposition.
Comment la détecter. En inversant la logique de surveillance. Ce n’est pas l’outil qui interroge la tâche, c’est la tâche qui prévient l’outil quand elle a fini. Si le signal n’arrive pas dans la fenêtre attendue, l’alerte part. C’est le seul mécanisme qui transforme un silence en information.
7. La faille publiée sur une extension que vous avez
Le symptôme. Aucun, jusqu’au jour où le site est utilisé pour envoyer du spam, injecter des liens, ou pire.
Pourquoi ça passe. Entre la publication d’une faille et sa mise à jour chez vous, il y a une fenêtre. Elle se compte en jours quand quelqu’un suit le sujet, en mois quand personne ne le suit. Et la supervision de disponibilité n’a aucune raison de s’y intéresser.
Comment la détecter. Les versions des logiciels installés se lisent dans le HTML que le site envoie déjà, sans rien lui demander de plus. Il suffit ensuite de les comparer aux failles publiées. Ce n’est pas un audit de sécurité complet, et il ne faut pas le vendre comme tel : c’est un filet qui attrape le cas le plus fréquent, celui de la version en retard sur un correctif connu.
Le point commun des sept
Aucune de ces pannes ne se voit dans un tableau de bord qui n’affiche que du vert et du rouge. Cinq d’entre elles sont complètement silencieuses : rien ne change à l’écran, rien ne ralentit, personne ne se plaint. Elles se paient plus tard, en trafic perdu, en commandes non passées, en données non restaurables.
C’est pour ça que nous avons arrêté de chercher un outil qui les couvre et que nous l’avons écrit. Le raisonnement complet est dans votre site répond, et il est cassé quand même, et la façon dont nous nous sommes trompés en chemin est dans 47 alertes un matin, 43 étaient fausses.
Pour aller plus loin
L’outil s’appelle UptimeEZ. Il vérifie ces sept points, plus quelques autres, sur chaque page qu’il suit. Son code est public sous licence MIT, donc ce qu’il mesure est vérifiable par votre équipe technique ou par n’importe quel prestataire.
Si vous préférez que ce soit nous qui regardions, la surveillance fait partie de notre filet de sécurité. Et pour la version DSI de l’exercice, sur tout un système et pas seulement sur un site, c’est notre grille de diagnostic technique en douze points.
Pour aller plus loin
- Vos sauvegardes tournent, est-ce qu’elles se restaurent : les six façons dont une restauration rate en silence
- Grille de diagnostic technique en douze points : la liste à passer sur votre propre infrastructure
- Retour arrière d’une mise en production à 23h : ce que donne une panne quand le repli était prêt
- Plan de reprise d’activité en PME : l’exercice à l’oral qui révèle la moitié des trous