Que surveille réellement votre prestataire sur le réseau et les serveurs ?

La supervision n’est souvent qu’un mot dans le contrat

La supervision est mentionnée dans presque toutes les offres d’infogérance. En soi, cette mention ne veut rien dire. On peut disposer d’un outil qui vérifie chaque minute si les serveurs répondent à un ping, et appeler cela de la supervision. Il peut y avoir des graphiques que personne ne regarde. Des alertes peuvent arriver dans une boîte de réception qui en contient déjà un millier.

La différence entre disposer d’une supervision et savoir ce qui se passe tient à trois points. Ce qui tombe réellement en panne est-il surveillé ? Un écart par rapport à la normale est-il transmis à une personne précise ? Quelqu’un prend-il le temps, une fois par mois, d’expliquer ce qu’il faut en conclure ?

Il existe un test simple. Demandez à votre prestataire combien de fois, au cours du dernier trimestre, la supervision a détecté un problème avant qu’un membre du personnel ne le signale. Une réponse précise signifie que l’outil remplit sa fonction. Une réponse générale signifie généralement que la supervision sert à confirmer les pannes, et non à les anticiper.

Ce n’est pas un reproche adressé aux prestataires. La supervision est la partie du contrat qui reste le plus facilement au stade de la simple déclaration, car personne ne la vérifie tant que tout fonctionne. Mieux vaut la vérifier avant.

Ce qu’il faut réellement surveiller

La liste est courte et n’a rien de secret. Il est utile de l’avoir sous la main, car elle montre très vite ce qui manque dans un contrat :

• disponibilité, c’est-à-dire si le service répond. Il ne s’agit pas seulement de savoir si le serveur répond à un ping, mais si ce dont les collaborateurs se servent fonctionne : le site web, la base de données, la messagerie, le partage de fichiers et le système de gestion des ventes
• saturation des liaisons. Une liaison qui atteint la limite de sa capacité pendant les heures de travail reste formellement opérationnelle, mais tout ce qui transite par elle ralentit et personne ne sait en expliquer la raison
• temps de réponse des nœuds du réseau. La hausse de la latence et les pertes de paquets apparaissent généralement bien avant la panne qui finit par bloquer quelqu’un
• espace disque disponible. Un disque plein arrête une base de données, une file d’attente de messagerie ou une tâche de sauvegarde. C’est aussi la panne la plus prévisible de toute l’informatique
• charge du processeur et de la mémoire, observée comme une tendance et non comme une mesure isolée. Un serveur dont la charge augmente progressivement depuis trois mois finira par atteindre sa limite
• état des sauvegardes. Il ne suffit pas de confirmer que la tâche a été exécutée. Il faut aussi vérifier si elle a couvert les données prévues, combien de temps elle a duré et si elle s’est achevée dans la fenêtre prévue
• erreurs dans les journaux des systèmes et des équipements. Pas toutes, uniquement certains motifs d’erreurs, car sinon personne ne les lira, même une seule fois
• certificats arrivant à expiration. Il s’agit d’une panne dont la date est connue à l’avance. Il n’y a donc aucune raison qu’elle surprenne qui que ce soit

À cela s’ajoutent les éléments propres à chaque entreprise. L’état des onduleurs, la température dans la baie, les files d’attente du système de gestion d’entrepôt ou le temps de réponse de la seule application dont dépend le travail de tout un service. Un prestataire qui connaît votre environnement pose lui-même ces questions. Si personne ne vous les a posées, la supervision a probablement été configurée à partir d’un modèle.

Les certificats expirent de plus en plus souvent

Un certificat qui arrive à expiration constitue la panne la plus prévisible dans l’informatique d’une entreprise, mais aussi l’une des plus fréquentes. Les conséquences sont immédiates et visibles pour les clients : un avertissement dans le navigateur, une interruption de l’intégration entre les systèmes ou une application mobile qui ne parvient plus à se connecter au serveur.

Le sujet vient de se compliquer. En avril 2025, le CA/Browser Forum a adopté un calendrier visant à réduire la durée de validité maximale des certificats TLS publics. Jusqu’au 14 mars 2026, elle était de 398 jours. Depuis le 15 mars 2026, la limite est de 200 jours. Elle passera à 100 jours le 15 mars 2027, puis à 47 jours le 15 mars 2029. La période pendant laquelle une validation antérieure du domaine peut être réutilisée diminue également, jusqu’à atteindre 10 jours.

En pratique, cela signifie une chose. Un certificat qui était renouvelé une fois par an à l’occasion d’autres interventions devra l’être plusieurs fois par an, puis presque tous les mois d’ici quelques années. Une liste dans un tableur et un rappel dans le calendrier ne suffiront plus, car une erreur finira par se produire au fil des échéances.

La question à poser au prestataire est donc très précise. Comment savez-vous quand chacun de nos certificats expire ? Combien de jours à l’avance sommes-nous informés ? Le renouvellement est-il automatisé ? Si la réponse est que quelqu’un s’en souvient, ce n’est pas une réponse.

Une alerte et un rapport sont deux choses différentes

Une alerte concerne ce qui se passe maintenant. Elle doit prévenir une personne précise suffisamment tôt pour permettre une intervention avant que les conséquences ne surviennent. Une alerte sans destinataire n’est pas une alerte, mais une simple entrée dans l’historique.

Un rapport présente une tendance. Il doit montrer ce qui s’est passé au cours du mois, ce qui se dégrade et ce qu’il convient de faire avant qu’une panne ne survienne. Un rapport ne sert pas à prouver que tout allait bien. Il sert à prendre des décisions financières : faut-il ajouter des disques, augmenter la capacité d’une liaison ou remplacer un commutateur qui perd des paquets ?

Confondre les deux est une erreur courante. La liste de toutes les alertes du mois n’est pas un rapport, mais une impression. À l’inverse, un rapport dans lequel tous les indicateurs sont au vert alors que les utilisateurs se sont plaints pendant trois semaines de la lenteur du système ne décrit pas l’entreprise, mais seulement une sélection de graphiques.

Sans seuil ni destinataire, une alerte n’est qu’un graphique

La supervision commence à remplir son rôle lorsque des seuils sont définis. Il ne suffit pas de constater de manière générale qu’un disque se remplit. Il faut préciser : à partir de quelle valeur un avertissement apparaît-il, à partir de quelle valeur une alerte est-elle déclenchée et combien de temps cet état doit-il durer avant l’envoi d’une notification ? Sans cette dernière condition, un pic ponctuel réveillera quelqu’un en pleine nuit sans raison.

Le deuxième point concerne le destinataire. Une alerte doit être adressée à une personne précise ou à une astreinte, utiliser un canal adapté à la gravité de la situation et suivre une procédure définie si personne ne répond. Les notifications peuvent être envoyées par e-mail, par SMS ou sur la messagerie instantanée de l’équipe, selon l’urgence et l’heure à laquelle l’événement se produit. L’essentiel est de définir cette répartition à l’avance, et non pendant une panne.

Le troisième point concerne l’hygiène des alertes. Une alerte qui se déclenche tous les jours sans rien signifier n’est plus lue au bout de deux semaines. Toutes les autres finissent alors par être ignorées avec elle. Il faut donc ajuster les seuils et supprimer les notifications qui ne conduisent à aucune action. Cela relève de l’exploitation courante et ne prouve pas que la supervision a été mal conçue.

Si le contrat ne définit ni seuils ni destinataire, la supervision n’est qu’un graphique. Un joli graphique, mais il ne réveillera personne.

À quoi ressemble un rapport mensuel honnête

Un rapport honnête se lit en quelques minutes et permet de savoir quoi faire. Il n’a pas besoin d’être long. Il doit présenter les éléments qui ne ressortent pas des échanges quotidiens :

• ce qui s’est passé : les tickets et les pannes, quand ils sont arrivés, quand quelqu’un s’en est occupé et quand ils ont été clôturés
• combien de problèmes la supervision a détectés avant leur signalement par un utilisateur, car c’est le seul indicateur qui montre si elle fonctionne réellement
• les tendances de capacité : disques, liaisons et mémoire, avec une conclusion simple sur la date à laquelle la réserve sera épuisée
• état des sauvegardes, en précisant si un test de restauration a été réalisé pendant cette période et quel en a été le résultat
• les changements apportés à l’infrastructure, la personne qui les a demandés et la date de la demande
• les risques en suspens et les recommandations accompagnées de leur justification, et non une simple liste d’achats

Un rapport qui ne mentionne aucun problème mérite une attention particulière. Aucune infrastructure ne passe un mois sans incident. Il est plus facile de travailler avec un prestataire qui les décrit de lui-même qu’avec celui chez qui tout ne se révèle qu’au moment d’une panne majeure.

Il est également utile de préciser si le rapport est envoyé automatiquement ou si quelqu’un le relit avant l’envoi. Un système automatisé envoie la même chose chaque mois. Une personne ajoute une phrase sur ce qui l’a préoccupée. Cette phrase coûte généralement moins cher que la panne qu’elle signale.

Questions à poser à votre prestataire

C’est le moyen le plus direct de savoir où vous en êtes. Aucune de ces questions n’est agressive, et chacune peut recevoir une réponse en quelques phrases :

• ce qui est exactement supervisé. Demandez la liste des équipements et des services plutôt qu’une simple affirmation
• quels sont les seuils d’avertissement et d’alerte pour les disques, les liaisons, le processeur et la mémoire
• qui reçoit une alerte au milieu de la nuit et le week-end, et ce qui se passe si cette personne ne répond pas
• si l’astreinte en dehors des heures ouvrées est prévue au contrat ou dépend de la bonne volonté du prestataire
• où la solution de supervision est physiquement hébergée et à qui appartiennent les données collectées
• ce qui reste en votre possession si vous changez de prestataire : la configuration, l’historique et l’accès aux données
• combien de temps les métriques et les journaux sont conservés, car sans historique, aucune tendance ne peut être dégagée
• si vous pouvez obtenir un accès en lecture seule à un tableau de bord affichant l’état actuel
• si les sauvegardes sont vérifiées au moyen d’un test de restauration et à quelle fréquence
• si vous pouvez consulter un exemple de rapport mensuel, même avec les données d’un autre client masquées

La dernière question est généralement la plus révélatrice. Un prestataire qui produit des rapports réguliers dispose d’un tel document et peut vous le montrer sans préparation. Si l’exemple de rapport doit d’abord être créé, c’est qu’il n’existait pas jusqu’alors.

Notre propre approche

Nous assurons la supervision avec Elastic Stack sur l’infrastructure du client. Logstash collecte les données des équipements réseau via SNMP et syslog. Les données des serveurs et des systèmes sont transmises via Filebeat, Winlogbeat et Metricbeat. Selon la gravité de l’incident, les alertes sont envoyées par e-mail, par SMS ou sur une messagerie instantanée. Avec ce modèle, nous prenons en charge plusieurs milliers d’équipements.

Nous avons délibérément choisi une solution déployée chez le client. Les données restent dans l’entreprise, nous adaptons les seuils à l’environnement concerné et nous configurons la vue opérationnelle pour qu’elle indique en quelques dizaines de secondes ce qui pose problème à cet instant. Le périmètre de l’assistance, y compris l’astreinte 24 h/24 et 7 j/7, est défini dans le contrat. Cette condition doit y figurer et ne peut pas être considérée comme acquise. L’ordre de traitement des tickets dépend de ce qui bloque le plus l’activité.

Si vous souhaitez simplement vérifier ce qui est actuellement supervisé dans votre infrastructure et ce qui ne l’est pas, passez en revue les questions de cet article avec votre prestataire actuel. Les réponses donnent généralement une image très claire de la situation. Si cette image révèle plus de lacunes que de certitudes, nous serons heureux de l’examiner avec vous.

Voir ce projet