Supervision : ce qui est réellement surveillé, et qui regarde les alertes
Une supervision se juge sur trois choses écrites : la liste de ce qui est sondé, le seuil à partir duquel on alerte, et le nom de la personne réveillée. Sans ces trois éléments, la phrase « nous supervisons votre serveur » reste une intention. Voici comment les faire préciser avant l'incident, puis comment vérifier que la surveillance fonctionne encore.
La supervision n'est pas un service, c'est une liste
Un prestataire peut affirmer qu'il « supervise » un serveur sans que rien de vérifiable ne se produise : une sonde qui répond, une alerte envoyée à une adresse que personne ne consulte, un tableau de bord ouvert sur un écran. La question n'est donc pas celle de l'existence de la supervision, mais celle de son contenu. Elle se répond par un document : la liste des sondes, avec pour chacune la cible, la fréquence et le seuil retenu.
Cette liste n'a pas besoin d'être longue. Trois niveaux suffisent : la machine (répond-elle, le disque se remplit-il), le service (le serveur web écoute-t-il, la base accepte-t-elle une connexion) et l'usage (une page répond-elle avec le contenu attendu). Un site peut renvoyer un code 200 avec une page d'erreur, une base accepter les connexions et refuser les écritures : seul le troisième niveau voit ces pannes-là. Fréquence et seuil sont donc des clauses, pas des réglages.
Fréquence et seuils : les deux chiffres qui décident
La fréquence de sondage fixe la durée pendant laquelle une panne reste invisible. Une mesure toutes les cinq minutes signifie qu'un incident peut durer presque cinq minutes avant d'être vu, et ce délai s'ajoute au temps de prise en compte. Le contrat doit donc donner deux chiffres : l'intervalle de mesure et le nombre de mesures en échec avant alerte. Un seul échec produit du bruit sur un réseau instable ; en attendre trois retarde la détection. Il n'y a pas de bonne réponse universelle, seulement un arbitrage à écrire.
Le seuil se choisit par type de ressource : un disque en pourcentage et en délai avant saturation, une mémoire en tendance, un certificat en jours restants, un service en échecs consécutifs. Les seuils figés une fois pour toutes vieillissent mal : un serveur dont l'activité double légitimement déclenche des alertes sans objet; l'équipe cesse de les lire. La mesure vient aussi de l'intérieur, par les statistiques d'un moteur de base de données : la sonde dit que le service ne répond plus, le relevé interne dit pourquoi.
Qui regarde : canal, destinataire, escalade
Une alerte sans destinataire est un journal, pas une surveillance. Le contrat doit nommer le canal — message, appel, courriel — et la personne ou l'équipe qui le reçoit, avec les horaires correspondants. Une alerte par courriel adressée à une boîte partagée, la nuit et le week-end, revient à ne pas alerter : personne ne la lit avant l'ouverture, et la supervision n'aura servi qu'à dater la panne.
L'escalade est le second étage : si la première personne ne répond pas dans un délai fixé, qui est prévenu, et par quel moyen ? Ce délai et cette chaîne s'écrivent. Sans escalade, la permanence dépend de la vigilance d'une seule personne : ce n'est pas un dispositif, c'est un espoir. Reste la panne de la supervision elle-même : si le canal d'alerte passe par le serveur surveillé, l'incident devient silencieux. D'où le message envoyé à intervalle régulier en l'absence de problème, dont la non-arrivée constitue l'alerte.
Les angles morts les plus fréquents
Quatre pannes reviennent assez souvent pour être citées. Le certificat qui expire un jour de campagne : la sonde vérifie que le service répond, pas que le certificat présenté est valide. La sauvegarde qui échoue en silence depuis trois semaines : la tâche s'exécute, échoue, et personne ne lit le compte rendu. Le disque qui se remplit en une nuit faute de rotation des journaux. Et la tâche planifiée qui ne se déclenche plus, alors que le service qu'elle alimente se dégrade lentement.
Ces cas ont un point commun : ce sont des absences d'événement. Une panne bruyante se remarque ; une tâche qui ne tourne plus ne produit aucun message, donc aucune alerte. La surveillance doit inclure des contrôles d'absence : la dernière exécution date-t-elle de moins de vingt-quatre heures, le dernier fichier de sauvegarde est-il récent. Les journaux relèvent du même raisonnement : la CNIL recommande de les conserver six mois à un an sur une période glissante et de superviser le dispositif de journalisation.
Ce que doit contenir le rapport, et à quoi il sert
La supervision ne se prouve pas par un écran, elle se prouve par un document. Le rapport périodique devrait indiquer le nombre d'alertes reçues, celles qui correspondaient à un incident réel, celles qui n'étaient que du bruit, et le délai entre le déclenchement et la prise en compte. Un rapport qui ne contient que des courbes de disponibilité ne dit rien de la qualité de la surveillance.
Les faux positifs méritent une ligne à eux seuls. Un dispositif qui produit vingt alertes par semaine pour trois incidents réels entraîne une désensibilisation : les messages sont classés sans être lus, et la vraie panne passe dans le lot. Leur proportion est un indicateur de fiabilité. Demander aussi la trace des tests : une sonde désactivée puis jamais réactivée est un trou dans le périmètre que personne ne verra.
Six questions, et le genre de réponse qui tient
Une réponse qui tient est datée et vérifiable : un extrait de configuration, une règle d'alerte, un nom d'équipe, la dernière notification reçue. Une réponse qui ne tient pas est une affirmation générale — « tout est supervisé », « on est alerté en temps réel » — sans cible, sans seuil et sans destinataire. La différence ne demande pas de compétence technique : elle demande de refuser la phrase creuse.
Il faut enfin accepter que la supervision ne couvre pas tout, et l'écrire. Un service qui dépend d'un prestataire externe, une chaîne de paiement, un envoi de courriel : ces maillons ont leurs propres pannes, et l'exploitant du serveur n'y a pas accès. La question n'est pas de les mettre hors périmètre, mais de dire qui les surveille et comment l'information remonte.
- Quelles sondes, sur quelles cibles, à quelle fréquence ? Demander la liste, pas un exemple.
- Combien d'échecs consécutifs avant alerte, et sur quel seuil ?
- Qui reçoit l'alerte, sur quel canal, à quelles heures ?
- Qui est prévenu si la première personne ne répond pas, et au bout de combien de temps ?
- Comment savez-vous que le canal d'alerte fonctionne encore ?
- Quelles sondes contrôlent les tâches planifiées et les sauvegardes, et où voit-on leur dernière exécution ?