Monitoring

Le monitoring est la surveillance continue d’un logiciel en production : disponibilité, temps de réponse, erreurs, usage des ressources. Il déclenche des alertes avant que les utilisateurs ne se plaignent et donne, après incident, les éléments pour comprendre ce qui s’est passé.

C’est une composante de la maintenance, pas une option.

Monitoring : définition simple

C’est quoi le monitoring ? C’est la surveillance continue d’un logiciel en production : un service vérifie à intervalle régulier qu’il répond et qu’il fait son travail, et prévient quelqu’un dès que ce n’est plus le cas. On dit aussi supervision ou surveillance applicative.

Que signifie monitoring pour un dirigeant ? Apprendre une panne avant ses clients, et savoir où chercher. Le monitoring ne répare rien : il réduit le temps qui sépare l’incident de la réaction.

Comment ça marche en pratique

Une sonde, un résultat attendu, un seuil. Un contrôle interroge le logiciel comme le ferait un utilisateur, compare la réponse à ce qui est attendu, et ne déclenche l’alerte que si l’écart dépasse le seuil fixé.

Quatre familles de signaux. Une surveillance utile couvre les quatre, pas seulement la première :

• la disponibilité : le service répond-il, vu de l’extérieur, à intervalle régulier
• les erreurs : leur nombre, leur nature, la page ou l’action concernée
• les temps de réponse : la lenteur qui s’installe avant la panne franche
• les ressources : espace disque, mémoire, quotas atteints chez l’hébergeur

Surveiller n’est pas journaliser. Le monitoring alerte pendant l’incident ; la journalisation garde la trace, pour expliquer ensuite. La CNIL recommande de tracer les créations, consultations, modifications et suppressions de données, avec l’auteur et l’horodatage, et de conserver ces journaux entre six mois et un an, jusqu’à trois ans pour un contrôle interne justifié (CNIL, délibération n° 2021-122 du 14 octobre 2021). C’est ce qui permet, après un incident, de dire qui a accédé à quoi.

Alerter quelqu’un, pas tout le monde. Deux erreurs se compensent mal : alerter sur tout, et l’équipe cesse de lire ; n’alerter sur rien, et la panne est signalée par un client. Chaque alerte doit avoir un destinataire nommé, un seuil assumé et une conduite à tenir.

La sonde qui dérange. Le 24 septembre 2026, en contrôlant les 16 pages d’un site en hébergement mutualisé, nous avons envoyé quatre requêtes à la fois : 9 pages sur 16 ont répondu 429, « trop de requêtes ». Deux à la fois, avec 400 ms de pause : 16 sur 16. La première version de notre rapport y voyait des pages invalides et un plan du site inaccessible ; c’était faux. Le rythme d’un contrôle se règle sur l’hébergement, et une réponse 429 n’est jamais une panne du site.

La réponse n’est pas le résultat. Un e-mail accepté par le serveur n’est pas un e-mail arrivé ; une sauvegarde terminée n’est pas une sauvegarde qui se restaure. Les contrôles utiles suivent le parcours principal jusqu’au bout : une commande passée, un devis envoyé, une réservation enregistrée.

Le monitoring dans un projet de logiciel sur mesure

Délai : la liste se prépare pendant la recette. Les parcours à surveiller sont ceux qu’on a vérifiés à la livraison, pendant la recette. Nous ne publions pas de durée pour cette étape ; elle dépend du nombre de parcours et de l’hébergement.

Budget : l’outil, et quelqu’un pour réagir. Un outil de surveillance envoie des alertes, il ne les traite pas. Chez nous, 30 jours de corrections sont offerts après la livraison, puis le suivi mensuel, en option, se chiffre sur devis ; le délai d’intervention en cas de panne se fixe dans ce devis, selon ce que la surveillance couvre.

Risque : qui l’apprend en premier. Sans surveillance, une panne se découvre par un utilisateur bloqué ; avec, par une alerte adressée à une personne nommée. C’est le principe de notre tierce maintenance applicative : vérifier que le logiciel fait son travail, pas seulement qu’il répond.

Ce qu’il faut vérifier. Dans un contrat de maintenance, faites préciser ce qui est surveillé, à quelle fréquence, qui reçoit l’alerte hors des heures de bureau, sous quel délai il intervient, et si les restaurations de sauvegarde sont testées. Le monitoring se met en place avec la mise en production, pas après le premier incident ; il prolonge les mesures du guide sécurité des applications web.