Supervision : savoir qu'un service tombe avant les clients

« Votre site ne marche plus. » Quand c’est un client qui le dit, la panne a déjà coûté deux fois : le service perdu pendant tout le temps où personne ne savait, et la confiance de celui qui l’a découverte. Une supervision n’empêche pas les pannes. Elle réduit le temps entre le moment où quelque chose casse et celui où quelqu’un qui peut réparer le sait.

Ce guide de notre rubrique Infrastructure et cloud décrit ce qu’une supervision doit regarder, qui doit recevoir l’alerte, et comment éviter le piège le plus courant : l’alerte que plus personne ne lit.

Pourquoi on découvre les pannes trop tard

Parce qu’un service arrêté ne se plaint pas. Un serveur tombé n’envoie aucun message, une tâche de nuit qui ne s’est pas lancée ne laisse aucune erreur, un formulaire qui n’enregistre plus rien continue d’afficher son message de remerciement. Sans dispositif dédié, la première alerte vient de l’extérieur, et souvent tard.

L’ouvrage de référence de Google sur l’exploitation de ses services, Site Reliability Engineering, pose les deux questions auxquelles une supervision doit répondre : qu’est-ce qui est cassé, et pourquoi. La première se traite de l’extérieur, la seconde de l’intérieur.

Ce qu’il faut surveiller : quatre couches

1. L’extérieur : tester comme un utilisateur

Le livre de Google distingue deux approches. La surveillance en boîte noire teste le comportement visible de l’extérieur, comme un utilisateur le verrait ; la surveillance en boîte blanche s’appuie sur les mesures exposées par le système lui-même, journaux compris. La première dit ce qui est cassé maintenant ; la seconde aide à comprendre pourquoi, et parfois à voir venir.

Pour une entreprise de taille moyenne, la première est la plus urgente : une sonde qui appelle chaque service toutes les minutes, depuis un autre endroit que le serveur surveillé. Une sonde installée sur la machine qu’elle surveille s’arrête avec elle.

2. L’usure : ce qui prévient avant la panne

Le même ouvrage retient quatre signaux d’or : la latence, le trafic, les erreurs et la saturation. Pour un serveur d’entreprise, la saturation se lit d’abord sur le disque et la mémoire : un disque qui se remplit de journaux arrêtera tôt ou tard la base de données qui écrit dessus.

Les certificats méritent une place à part, parce que leur durée raccourcit. Let’s Encrypt a annoncé la réduction progressive de ses certificats, aujourd’hui de 90 jours :

1. 13 mai 2026

   Certificats de 45 jours disponibles sur demande, pour les premiers utilisateurs.

2. 10 février 2027

   Le profil par défaut passe à 64 jours.

3. 16 février 2028

   Le profil par défaut passe à 45 jours.

Let’s Encrypt précise que la plupart des utilisateurs dont le renouvellement est automatique n’auront rien à changer, déconseille le renouvellement manuel et recommande de surveiller les renouvellements manqués. Plus un certificat est court, plus un renouvellement en panne se voit vite : chez les clients.

Les sauvegardes, enfin, sont un signal d’usure comme un autre : une sauvegarde qui échoue en silence depuis des semaines est une panne qui attend son heure. Notre guide des sauvegardes d’un serveur à soi détaille quoi vérifier, et à quel rythme.

3. Le résultat : un service peut répondre et ne plus travailler

C’est la couche la plus souvent oubliée, et celle qui coûte le plus cher. Une sonde qui reçoit une réponse correcte conclut que tout va bien. Elle ne sait pas si le travail a été fait.

Sur Palmora Property, un portail immobilier que nous opérons, des garde-fous de publication bloquent un import vide avant qu’il ne publie un site sans aucun bien, alors que le traitement qui l’aurait fait se serait terminé « avec succès ». Ce contrôle porte sur le résultat, pas sur l’état du programme.

La leçon est la même dans les deux cas : surveiller ce qui est réellement produit, pas ce qui est configuré. Notre guide pour superviser ses workflows n8n détaille ces contrôles sur le résultat.

4. Le silence : l’absence de signal est une alerte

Une tâche qui ne se lance plus ne produit aucune erreur. La parade est de surveiller ce qui doit arriver : la sauvegarde de la nuit envoie un signal en fin de course, et c’est l’absence de ce signal à l’heure prévue qui déclenche l’alerte. Le principe vaut pour tout ce qui tourne à heure fixe : imports, rapports, synchronisations.

Qui reçoit l’alerte, et pour quoi faire

Une supervision ne vaut que par ce qui se passe après l’alerte. Le livre de Google le formule en une règle :

Concrètement :

• une personne nommée par service, avec un remplaçant pour les absences, et pas une boîte partagée que tout le monde suppose lue par quelqu’un d’autre ;
• une action écrite par type d’alerte : que vérifier d’abord, qui prévenir, à partir de quand déclencher le plan de reprise ;
• deux niveaux : ce qui doit réveiller quelqu’un, et ce qui peut attendre le lendemain matin ;
• aucune alerte permanente : une alerte qui sonne tous les jours sans conséquence apprend à l’équipe à les ignorer toutes.

La supervision ne remplace pas les personnes qui administrent les systèmes : elle leur donne le signal à temps, et le contexte pour agir. Elle ne remplace pas non plus le plan qui dit quoi faire quand la panne est grave, que nous détaillons dans le plan de reprise après sinistre.

Par où commencer

1. 01Listez vos services

   Visibles des clients ou des équipes, avec pour chacun une personne qui en répond.

2. 02Posez une sonde extérieure

   Sur chacun, hors du serveur surveillé, avec une alerte vers cette personne.

3. 03Ajoutez les signaux d’usure

   Disque, certificats, réussite des sauvegardes.

4. 04Surveillez un résultat par service

   Une demande enregistrée, un import qui contient des éléments, un rapport envoyé.

5. 05Relisez les alertes chaque mois

   Supprimez celles qui n’ont appelé aucune action, ajoutez celles qui ont manqué.

La supervision fait partie du socle d’infrastructure commun à vos projets, au même titre que les accès et les sauvegardes. Les autres articles de la rubrique couvrent les décisions voisines : les cinq postes qui gonflent une facture cloud, serveur dédié, VPS ou cloud, Kubernetes et les PME, n8n auto-hébergé en production, les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans, la migration cloud sans tout casser, la dépendance au cloud américain et NIS2 en France, dont le référentiel compte la supervision parmi ses objectifs.

Pour vos outils auto-hébergés, l’infogérance de notre sortie du SaaS couvre la supervision, les mises à jour et des sauvegardes testées. Pour un dispositif sur une infrastructure existante, décrivez-nous vos services.

Questions fréquentes

Sources

1. Google, Site Reliability Engineering, chapitre Monitoring Distributed Systems (nouvel onglet)sre.google
2. Let’s Encrypt, Decreasing Certificate Lifetimes to 45 Days, décembre 2025 (nouvel onglet)letsencrypt.org