Supervision 24/7 : quoi surveiller, quoi alerter, qui réveiller

15 juillet 2026 · 4 min de lecture · SOVALYX Technologies

Une supervision informatique 24/7 efficace ne consiste pas à tout mesurer, mais à détecter au plus tôt ce qui dégrade le service rendu aux utilisateurs — et à ne réveiller un humain que lorsqu'une action immédiate est nécessaire. Trois questions structurent tout le dispositif : quoi surveiller, à partir de quel seuil alerter, et qui réveiller quand l'alerte tombe à trois heures du matin.

Surveiller le service rendu, pas seulement les serveurs

La plupart des projets de monitoring 24/7 démarrent par les ressources : CPU, mémoire, disque, réseau. Ces métriques sont nécessaires pour diagnostiquer, mais elles disent peu de chose de l'essentiel : est-ce que le service fonctionne pour ceux qui l'utilisent ? Un processeur à 90 % peut être parfaitement sain ; une API qui répond en huit secondes ne l'est jamais.

Les métriques qui comptent se lisent du point de vue de l'utilisateur : latence des requêtes, taux d'erreurs, saturation des files d'attente, trafic anormalement bas — souvent le signe le plus précoce d'un incident. Ajoutez des sondes externes qui rejouent les parcours critiques (connexion, commande, paiement) depuis l'extérieur de votre réseau : c'est le seul moyen de voir ce que voit réellement un client. Et quand c'est possible, remontez une métrique métier — commandes par minute, dossiers traités — car c'est elle qui donne son sens à toutes les autres.

La démarche part donc des parcours critiques et redescend vers l'infrastructure, jamais l'inverse. Pour chaque système surveillé, vous devez pouvoir répondre à la question : quel service utilisateur se dégrade si ce composant tombe ?

Des seuils qui veulent dire quelque chose

Un seuil fixe posé arbitrairement — « alerte si le CPU dépasse 80 % » — produit surtout du bruit. Trois raffinements changent tout :

• La persistance : un pic de trente secondes est rarement un incident ; dix minutes au-dessus du seuil, si. Alertez sur des conditions durables, pas sur des instantanés.
• La tendance : un disque qui, au rythme actuel, sera plein dans six heures mérite une alerte avant de l'être. Les seuils prédictifs préviennent ; les seuils statiques constatent.
• Le contexte : les seuils de la production ne sont pas ceux de la recette, et la charge d'un lundi matin n'est pas celle d'un dimanche soir. Un seuil unique pour tous les environnements garantit des fausses alertes.

Enfin, reliez vos seuils à vos engagements : si votre SLA promet un niveau de disponibilité donné, vos alertes doivent se déclencher bien avant que le budget d'indisponibilité ne soit entamé, pas après.

Alerter n'est pas réveiller : les trois niveaux

Toutes les anomalies ne se valent pas. Un dispositif sain distingue trois niveaux :

1. Le ticket : une information utile sans urgence — certificat qui expire dans trente jours, disque à 70 %. Traité en heures ouvrées, jamais notifié en temps réel.
2. L'alerte en heures ouvrées : une dégradation réelle mais tolérable quelques heures — un nœud redondant en panne, une lenteur localisée.
3. Le réveil : un impact avéré ou imminent sur un service critique. C'est le seul niveau qui sonne la nuit, et il doit rester rare.

Qui réveiller ? Une personne nommée, pas une liste de diffusion. L'astreinte IT fonctionne avec une rotation claire, un acquittement obligatoire et une escalade automatique si l'alerte reste sans réponse au bout de quelques minutes. Et chaque alerte de réveil pointe vers un runbook : symptômes, premiers diagnostics, actions de contournement, critères d'escalade. Réveiller quelqu'un sans lui dire quoi faire, c'est perdre les minutes précieuses que la détection avait gagnées — des minutes dont le coût se calcule.

La fatigue d'alerte, l'ennemi silencieux

Le pire scénario n'est pas l'absence de supervision : c'est la supervision que plus personne n'écoute. Quand les alertes non actionnables s'accumulent, les équipes acquittent sans lire, filtrent les notifications, et l'alerte importante passe avec le bruit. La fatigue d'alerte se combat comme une dette technique :

• chaque alerte doit exiger une action ; si la réponse habituelle est « on attend que ça passe », elle doit être supprimée ou reclassée en ticket ;
• une revue périodique examine les alertes du mois : lesquelles ont déclenché une action réelle, lesquelles ont réveillé pour rien ;
• chaque incident nourrit la boucle : l'alerte a-t-elle détecté le problème avant les utilisateurs ? Sinon, que fallait-il surveiller ?

C'est un travail continu, et c'est précisément ce qui rend l'astreinte difficile à tenir en interne : trois personnes ne font pas une rotation 24/7 soutenable. Externaliser la supervision et l'astreinte sous SLA — ce que SOVALYX opère depuis Maurice — revient souvent moins cher qu'une rotation interne épuisée, et surtout plus fiable. Parlez-en avec un ingénieur plutôt qu'avec un commercial.

Checklist : votre supervision en six points

• Lister les parcours utilisateurs critiques et les surveiller depuis l'extérieur du réseau.
• Classer chaque alerte existante : réveil, heures ouvrées ou simple ticket.
• Ajouter persistance, tendance et contexte à chaque seuil statique.
• Associer un runbook à jour à chaque alerte capable de réveiller quelqu'un.
• Formaliser l'astreinte : rotation, acquittement, escalade, compensation.
• Tenir une revue mensuelle du bruit et supprimer ce qui n'a déclenché aucune action.

🧰 L'outil qui va avec : Combien vous coûte une heure d'arrêt ? — gratuit · 2 minutes.

Relu et optimisé par IA.