Entre lenteurs, pannes ou bugs intermittents, les utilisateurs n’hésitent plus à signaler leurs frustrations face aux applications métiers. Mais leurs plaintes ne racontent qu’une partie de l’histoire. Avant de pouvoir corriger, encore faut-il comprendre ce qui se passe vraiment.
Cet article ouvre notre série consacrée à l’observabilité, en explorant comment les DSI peuvent reprendre le contrôle sur la performance perçue de leurs applications.
Lorsque des utilisateurs métiers vous appellent avec énervement parce que « ça rame tout le temps » ou que « l’appli n’est pas dispo », c’est le signe que quelque chose ne va pas. Pour un DSI ou un responsable applicatif, ces plaintes quotidiennes sont un véritable casse-tête. Elles révèlent des problèmes techniques qui perturbent le travail des équipes métiers et, par ricochet, impactent le bon fonctionnement du business. Attendre que les utilisateurs se plaignent et se contenter de leurs retours est toutefois une approche qui montre vite ses limites. Non seulement elle met l’IT en position réactive, mais elle risque aussi de laisser passer de nombreux soucis inaperçus.
En pratique, beaucoup d’utilisateurs finaux ne contactent même pas immédiatement la DSI au premier souci. Une étude a montré que 8 utilisateurs sur 10 (81 %) tentent d’abord de résoudre eux-mêmes leurs incidents informatiques avant de faire appel au support. Ils redémarrent leur application, cherchent des solutions sur Internet ou demandent de l’aide à un collègue. Ce n’est qu’en dernier recours, après avoir perdu du temps et de la patience, qu’ils sollicitent les équipes IT. Autrement dit, de nombreux petits tracas quotidiens passent sous le radar de la DSI tant que le problème n’est pas critique. Pendant ce temps, le mécontentement des utilisateurs augmente, et leur productivité baisse.
Du côté de la DSI, ne pas avoir connaissance immédiate de ces problèmes signifie subir les conséquences a posteriori : utilisateurs frustrés, demandes de correctifs en urgence, réunions de crise avec les métiers pour comprendre ce qui cloche. À l’échelle de l’entreprise, chaque interruption ou lenteur applicative peut entraîner un manque à gagner. Comme le rappelle un rapport de F5, « ne pas résoudre le problème de la mauvaise expérience utilisateur peut entraîner une baisse des revenus, l’abandon des applications et une perte de réputation ». Personne n’a envie d’en arriver là.
Pourquoi ces problèmes courants ne sont-ils pas détectés plus tôt par l’IT ? Souvent, la réponse tient aux outils classiques de supervision (ou monitoring). Historiquement, les équipes d’exploitation IT configurent des indicateurs et des alertes sur l’infrastructure : disponibilité des serveurs, utilisation CPU, mémoire, taux d’erreur, etc. Si un serveur tombe ou si une base de données atteint 100 % d’utilisation disque, une alerte se déclenche et l’équipe intervient. La surveillance fournit ainsi une visibilité de base sur la « santé » du système en mesurant des métriques prédéfinies. En bref, la supervision indique quand quelque chose ne va pas.
Le problème, c’est que cette visibilité traditionnelle reste assez binaire. Très souvent, on n’a que des voyants rouges ou verts sans explication détaillée. Oui, une alerte signale qu’un composant est « down » ou qu’une métrique dépasse un seuil, mais pourquoi ? Quelle en est la cause racine ? Comme le formule Lori MacVittie : « Oui, l’application A fonctionne mal et les utilisateurs se plaignent. Mais pourquoi ? Est-ce le réseau ? Leur appareil ? La plateforme ? L’environnement d’orchestration ? ». La supervision classique ne répond pas à ces questions. Les équipes IT se retrouvent donc à fouiller dans différentes consoles et journaux pour corréler les informations manuellement et trouver l’aiguille dans la botte de foin. Pendant ce temps, les utilisateurs attendent…
Par ailleurs, le monitoring traditionnel est conçu pour détecter des problèmes connus à l’avance. On définit des seuils et des scénarios d’alerte basés sur ce qu’on anticipe comme défaillance. Or, dans des systèmes de plus en plus complexes et distribués, de nombreux bugs ou ralentissements imprévus peuvent survenir sans forcément déclencher d’alarme immédiate. Une requête inhabituelle qui fait lentement grimper la latence, une combinaison de micro-événements qui dégradent l’expérience utilisateur sans provoquer de panne franche – ce sont typiquement le genre de soucis qui échappent aux radars tant qu’un utilisateur ne les remonte pas.
Face à ces défis, on entend de plus en plus parler d’observabilité comme d’une évolution nécessaire des pratiques DevOps et IT. Mais de quoi s’agit-il exactement ? Observabilité et monitoring sont des notions liées, qu’il convient de distinguer. En résumé, « la surveillance vous indique qu’un problème est en cours, tandis que l’observabilité vous dit ce qui se passe, pourquoi, et comment y remédier ». Autrement dit, la supervision traditionnelle répond à la question « Y a-t-il un problème ? » alors que l’observabilité vise à répondre à « Que se passe-t-il exactement et pourquoi ? ».
D’un point de vue plus formel, « l’observabilité est la capacité à comprendre l’état interne d’un système à partir de ses sorties externes ». En pratique, cela revient à collecter, centraliser et analyser un maximum de données techniques provenant des systèmes : les métriques (indicateurs chiffrés de performance), les logs (journaux d’événements détaillés), les traces (suivi d’une transaction de bout en bout) et d’autres événements. En croisant ces données, on peut reconstituer le fil des événements et obtenir une vue plus holistique de ce qui se passe dans l’infrastructure et les applications. L’observabilité permet en somme de comprendre le « pourquoi » derrière le « quoi ».
Il ne s’agit pas seulement d’empiler des graphiques jolis sur un tableau de bord, mais bien de fournir aux équipes IT une connaissance exploitable de l’état du système. Là où un monitoring classique se contentera de signaler un taux d’erreur élevé, une bonne plateforme d’observabilité aidera à corréler ce pic d’erreurs avec, par exemple, un déploiement récent, une saturation réseau ou un appel API externe défaillant. Elle va mettre en relation les symptômes et les causes potentielles. Ainsi, les équipes d’exploitation ne se contentent plus de constater qu’« il y a un problème » : elles peuvent plus rapidement cerner où et pourquoi le problème survient, puis agir en conséquence.
L’observabilité ne remplace pas le monitoring. Elle en révèle enfin tout le sens.
En introduisant progressivement ce vocabulaire, nous poserons les bases pour la suite de cette série de billets. On retiendra donc quelques définitions clés (que l’on détaillera davantage ultérieurement) :
- la supervision/monitoring = surveiller des indicateurs connus pour détecter les anomalies, avec génération d’alertes quand un seuil critique est atteint ;
- l’observabilité = collecter et exploiter l’ensemble des signaux émis par le système pour en comprendre le fonctionnement interne et diagnostiquer finement tout écart de comportement ;
- et l’exploitation = les opérations IT au quotidien – les équipes en charge de faire tourner le SI et d’intervenir en cas d’incident.
L’observabilité est en quelque sorte le nouvel atout de ces équipes d’exploitation pour passer d’une posture purement réactive (éteindre les incendies au fur et à mesure) à une posture proactive d’anticipation des problèmes.
Adopter l’observabilité, pour un DSI, ce n’est pas embrasser un énième buzzword technologique de plus. C’est avant tout répondre à un besoin bien réel : mieux comprendre son SI pour mieux le piloter, au service des utilisateurs et du métier. Les bénéfices concrets se font sentir à la fois pour les équipes IT et pour le business. Parmi ces bénéfices, on peut citer :
- Détection proactive des anomalies : repérer les problèmes avant qu’ils n’impactent les utilisateurs finaux (idéalement, ces derniers ne s’aperçoivent même plus de certains dysfonctionnements, car ils sont corrigés en amont).
- Résolution plus rapide des incidents : en disposant de données riches et corrélées, les techniciens localisent la cause des pannes beaucoup plus vite, ce qui réduit le temps de résolution et les interruptions de service.
- Satisfaction utilisateur accrue : moins d’interruptions non détectées, de meilleures performances perçues, en somme une expérience plus fluide. Finalement, il y a moins de plaintes et l’activité métier peut se dérouler sans mauvaises surprises.
Il n’est donc pas surprenant que les entreprises investissent de plus en plus ce domaine. D’après une étude récente, 59 % des organisations ayant mis en place des solutions d’observabilité indiquent être désormais capables d’identifier des problèmes de performance qu’elles ne soupçonnaient pas auparavant, et d’y remédier avant même que les utilisateurs ne soient affectés. En somme, elles découvrent des « signaux faibles » qui auraient autrefois dégénéré en appels furieux des utilisateurs, et les traitent de façon préventive.
Observabilité ne signifie pas pour autant abandonner le monitoring traditionnel : il s’agit plutôt de le compléter et de le faire évoluer. Les outils en place (supervision infrastructure, APM, etc.) restent utiles pour les indicateurs de base et l’alerting immédiat sur les gros incidents. L’observabilité vient enrichir cette base en ajoutant une profondeur d’analyse et une corrélation des données qui faisaient défaut jusqu’ici. En combinant les deux approches, la DSI gagne en visibilité et en réactivité pour garantir une expérience sans accroc aux utilisateurs.
Enfin, au-delà de la technique, adopter l’observabilité s’inscrit souvent dans une démarche plus large d’amélioration continue et de culture DevOps. En comprenant finement ce qui se passe dans le SI, les équipes IT peuvent être plus agiles dans leurs décisions. Par exemple, prioriser une optimisation de code ou augmenter les ressources d’un service devient plus aisé quand on dispose de données concrètes plutôt que de simples intuitions. Comme le résume un article spécialisé, pour un DSI « c’est un investissement dans la résilience et l’agilité de l’infrastructure, qui se traduira par une meilleure satisfaction des utilisateurs et une efficacité opérationnelle accrue ». Dit autrement, l’observabilité rend la DSI proactive plutôt que subie, ce qui profite in fine à toute l’entreprise.
En conclusion, si vos utilisateurs se plaignent de vos applications, il est peut-être temps de changer de paradigme. Mettre en place de l’observabilité, c’est permettre à l’IT d’avoir une longueur d’avance : détecter les problèmes avant tout le monde, comprendre d’où ils viennent et agir vite, afin que les dysfonctionnements n’affectent plus (ou beaucoup moins) le quotidien des métiers.
👉 Dans le prochain article de cette série, nous verrons comment définir et mesurer concrètement les « défauts » d’une application pour identifier les bons indicateurs de performance et construire un pilotage fiable.
