La plupart des PME découvrent que leur logiciel est en panne de la même façon : un client appelle. Ou envoie un e-mail. Ou, dans le pire des cas, s’en va simplement sans rien dire. Le temps que vous l’appreniez, le mal est fait.
Le monitoring et les alertes ne règlent pas cela en améliorant votre code. Un bug reste un bug, que vous le mesuriez ou non. Ce qu’ils changent, c’est le délai entre « quelque chose ne va pas » et « quelqu’un est en train de régler le problème ». Pour beaucoup de PME, ce délai se compte aujourd’hui en heures, parfois en week-end entier. Un bon monitoring le ramène à quelques minutes.
En même temps, un monitoring mal conçu est un problème en soi : un mur de notifications que plus personne ne regarde. Cet article traite donc de trois choses : ce que vous devez vraiment mesurer, ce qui ne doit surtout pas vous empêcher de dormir, et les quelques endroits où il faut au contraire agir de façon proactive.
Ce que le monitoring apporte vraiment
Remettons d’abord les attentes à leur place, car c’est souvent là que ça déraille. Le monitoring ne rend pas votre logiciel plus stable, au sens où moins de choses tomberaient en panne. Ce qu’il fait :
- Vous voyez les problèmes plus tôt. Un disque qui se remplit lentement ou une fuite de mémoire qui grimpe se voit des heures à l’avance, au lieu de n’apparaître qu’au moment où tout plante.
- Vous rétablissez plus vite. La bonne personne est prévenue immédiatement au lieu de le découvrir par hasard. Et de bonnes mesures ne vous disent pas seulement qu’il y a un problème, elles vous orientent aussi sur où il se trouve.
- Vous déployez plus sereinement. Si vos mises en production sont reliées au monitoring, vous voyez en quelques minutes si une nouvelle version fait tout s’emballer, et vous revenez en arrière avant que ça fasse vraiment mal.
- Vous savez ce qui est « normal ». En mesurant en continu, vous apprenez comment votre système se comporte un jour ordinaire. C’est seulement alors que les écarts sautent aux yeux.
Rien de tout cela n’exige une plateforme coûteuse ou une équipe de spécialistes. Pour une PME ordinaire, il s’agit d’une poignée de signaux bien choisis.
Commencez par ce que votre client remarque
L’erreur la plus fréquente que nous voyons : des entreprises mesurent cent chiffres techniques internes, mais ne savent pas si un vrai utilisateur reçoit en ce moment un message d’erreur. Inversez cela. Mesurez d’abord ce que votre client remarque, et seulement ensuite ce qui se passe sous le capot.
En pratique, cela se résume à quatre choses :
- Les erreurs. Quelle part des requêtes échoue ? C’est presque toujours votre signal le plus important, car une requête qui échoue touche directement un utilisateur. Attention aux erreurs silencieuses : une page qui se charge correctement mais qui est vide ou fausse compte aussi comme une erreur.
- La rapidité. Combien de temps prend une requête ? Ne la mesurez pas en moyenne, mais sous la forme « les 5 % les plus lentes ». Si une requête sur vingt prend cinq secondes, cela disparaît complètement dans une moyenne flatteuse, alors que vos clients en souffrent bel et bien.
- Le trafic. Combien de requêtes recevez-vous ? Surtout comme contexte : 5 % d’erreurs ne veut pas du tout dire la même chose avec 50 visiteurs qu’avec 50 000. Et un trafic qui chute soudain est souvent lui-même le symptôme d’une panne.
- La saturation. À quel point vos ressources sont-elles remplies, à quelle distance êtes-vous de la limite ? C’est votre signal d’alerte précoce.
Et puis le plus important, qu’aucun tableau de bord standard ne remplit pour vous : vos indicateurs métier. La connexion fonctionne-t-elle ? Les commandes passent-elles ? Les factures partent-elles, les paiements tournent-ils ? Un système peut être techniquement entièrement « au vert » alors qu’aucune commande n’est arrivée depuis une heure. C’est cela que vous voulez savoir en premier.
Ce qui ne doit surtout pas vous empêcher de dormir
Voici la partie que la plupart des gens font mal. Tout ce que vous mesurez ne mérite pas une alerte qui vous réveille la nuit.
Le piège principal consiste à déclencher des alertes sur des causes au lieu de symptômes. Un CPU à 90 % semble alarmant, mais ce n’est pas un problème en soi : si vos requêtes passent toujours vite et sans erreur, ce CPU fait simplement son travail. Cela ne devient intéressant que lorsqu’un CPU élevé s’accompagne d’une lenteur ou d’erreurs croissantes. Mesurez donc le CPU, vous en avez besoin pour diagnostiquer les problèmes, mais n’en faites pas une alerte.
Pourquoi c’est important : trop d’alertes, ou des alertes trop sensibles, mènent à ce qu’on appelle l’alert fatigue. Les gens commencent à ignorer les notifications parce que ce sont de toute façon presque toujours de fausses alertes, et c’est justement comme ça qu’ils ratent les vraies. Une alerte qui se déclenche doit signifier quelque chose.
Un test pratique pour chaque notification que vous envisagez : si cette valeur triple, est-ce que je fais quelque chose ? Si la réponse est non, ce n’est pas une alerte. Mettez-la sur un tableau de bord que vous consultez de temps en temps, et c’est tout.
La règle qui relie tout : alertez sur les symptômes, utilisez le reste pour diagnostiquer. Vos alertes répondent à la question « est-ce que les clients en souffrent ? ». Tous vos autres chiffres sont là pour que, dès qu’une alerte se déclenche, vous voyiez vite où ça coince.
L’exception : le stockage (et en partie la mémoire)
À cette règle « pas d’alerte sur les ressources », il y a une exception importante, qui mérite d’être bien comprise. Tout dépend de si une ressource se libère d’elle-même ou non.
Le CPU est élastique : un pic se résorbe dès qu’il est passé, et tout ce qui se produit, c’est un ralentissement passager. Le stockage, c’est l’inverse. Un disque ne va que dans un sens, vers plein, et ne se libère pas tout seul. Le mode de défaillance est en plus brutal et parfois irréversible : plus moyen d’écrire les logs, une base de données qui se corrompt ou se bloque, un système qui ne redémarre plus. Et, point crucial, c’est prévisible. Vous voyez la tendance des heures ou des jours à l’avance.
C’est pourquoi le stockage justifie, lui, une alerte proactive. La meilleure approche consiste ici à alerter sur la tendance (« disque plein dans quatre heures à ce rythme ») plutôt que sur un seuil fixe de 90 %. Ce seuil fixe arrive trop tard sur un petit disque qui se remplit vite, et bien trop tôt sur un grand disque qui se remplit lentement. Un disque plein touche d’ailleurs directement vos données, ce qui renvoie à la question de savoir si vos sauvegardes fonctionnent vraiment.
La mémoire se situe entre les deux. Une forte occupation de la mémoire est souvent très bien : c’est simplement votre système qui utilise l’espace disponible. Ce que vous voulez attraper, c’est la lente tendance à la hausse, une fuite qui grimpe vers un plantage. Donc : alertez sur la pente, pas sur la valeur instantanée.
Les connexions échouées : une mesure, deux histoires
Un bel exemple d’indicateur qui en vaut la peine, parce qu’il peut vous dire deux choses différentes à la fois.
Comme signal de fiabilité, un pic soudain de connexions échouées trahit une panne de votre système de connexion, par exemple après une mauvaise mise à jour, qui empêche vos vrais clients d’entrer. Comme signal de sécurité, la forme du pic trahit une attaque : beaucoup de tentatives échouées réparties sur beaucoup de comptes indiquent un essai automatisé de mots de passe volés, tandis que beaucoup de tentatives sur un seul compte signalent une attaque ciblée.
Vous ne déclenchez donc pas d’alerte sur un nombre absolu, car il y en a toujours quelques-unes qui échouent : les gens oublient leur mot de passe, c’est ainsi. Vous alertez sur un écart par rapport à votre niveau normal, et la forme de cet écart vous dit tout de suite lequel des deux problèmes vous avez. Cette seconde histoire, le volet sécurité, devient d’ailleurs de plus en plus pertinente maintenant que davantage d’entreprises sont soumises à des règles plus strictes ; voir aussi NIS2 pour les PME.
N’oubliez pas vos dépendances
Une dernière couche qu’on oublie facilement. La plupart des logiciels s’appuient sur des éléments extérieurs : une API externe, une base de données, un prestataire de paiement, un service d’e-mail. Énormément de pannes « inexplicables » ne viennent pas de votre propre code, mais de quelque chose dont vous dépendez.
Mesurez donc séparément le taux d’erreur et la rapidité de ces connexions. Ainsi, lors d’une panne, vous voyez tout de suite où est la faute, au lieu de chercher pendant des heures dans votre propre code alors que le problème est ailleurs.
Notre façon de faire chez Tandem
Ce ne sera pas une surprise si vous avez lu nos autres articles : nous restons délibérément sobres et modestes. Une PME n’a pas besoin d’une plateforme d’observabilité avec cinquante tableaux de bord, elle a besoin d’une poignée de signaux qui comptent. Mettre en place une pile de monitoring complète « parce qu’on peut », c’est simplement une variante de la sur-ingénierie : un coût que vous continuez à payer pendant des années, pour une visibilité que personne n’utilise.
Concrètement : nous alertons sur les symptômes qui touchent vos clients (requêtes qui échouent, qui deviennent trop lentes, processus métier qui s’arrêtent) et sur les quelques ressources qui lâchent de façon brutale et prévisible, comme le stockage. Le reste, nous le mesurons aussi, mais il est sur un tableau de bord, pas sur un bipeur. Chaque alerte qui se déclenche doit signifier qu’il faut agir. Ainsi le signal reste net et personne ne se met à l’ignorer.
Pour conclure
La valeur du monitoring ne tient pas au nombre de graphiques que vous collectionnez. Elle tient à la réponse à une seule question : savez-vous que quelque chose est en panne avant que votre client ne vous le dise ? Pour la plupart des PME, la réponse est aujourd’hui non, et cela se règle avec étonnamment peu de chose.
Vous doutez de remarquer la panne d’une partie critique de votre logiciel ? Nous regarderons volontiers cela ensemble. Pas de rapport de trente pages, juste un contrôle honnête des signaux que vous devriez vraiment surveiller. Prenons rendez-vous pour faire connaissance.
