Dans le premier volet, nous avons vu comment les plaintes utilisateurs peuvent révéler un déficit d’observabilité.
Une nouvelle version part en production, quelque chose se met à casser, aucune alerte ne remonte… et les plaintes affluent : Ce scénario classique survient lorsque l’on se contente de surveiller quelques indicateurs techniques basiques, sans réellement comprendre pourquoi les problèmes apparaissent.
L’observabilité vise à dépasser le simple constat de panne applicative pour en expliquer les causes. Au lieu de découvrir les problèmes par les retours des utilisateurs, elle permet de voir toute la chaîne d’événements, du ralentissement d’une page au clic qui échoue, reliée à des signaux mesurables.
La définition d’un défaut, logiciel ou applicatif, dépend de qui regarde :
Pour l’utilisateur, c’est de la friction : interface peu intuitive, étape superflue, page lente, bug bloquant. Résultat : frustration, abandon, conversion en baisse.
Pour le système, c’est quelque chose de mesurable : code d’erreur HTTP 500, latence supérieure à 3 secondes, crash applicatif. C’est l’expression technique du problème ressenti par l’utilisateur.
Pour le métier, c’est une perte de valeur : ventes manquées, dossiers non traités, clients perdus. Gartner parle d’ailleurs d’observabilité business, les entreprises attendent des indicateurs liés à des métriques métier, pas seulement des tableaux de bord techniques.
Un défaut n’existe vraiment que lorsqu’il est mesuré, compris… et assumé par une équipe.
Nommer ces trois facettes est crucial. Un même incident se décrit ainsi : « les utilisateurs trouvent l’application métier lente » (défaut UX), « les requêtes dépassent 2s au P95 » (défaut technique), « on perd chaque mois 3% de ventes » (défaut métier).
Comment transformer une plainte brute des utilisateurs de votre logiciel ou application métier en indicateur actionnable ?
Voici 3 exemples de plaintes régulièrement entendues :
1. « C’est lent chez vous ! »
Analysez les percentiles de latence plutôt que la moyenne. Un temps moyen correct peut masquer qu’une minorité subit des délais énormes, ce sont eux qui disent « c’est lent ». Mesurez le P95 ou P99 : « 95 % des pages se chargent en moins de 800 ms ». Vous pouvez aussi utiliser un indice Apdex qui agrège les temps de réponse en score de satisfaction (0 à 1).
2. « Ça plante tout le temps »
Traduisez en taux d’erreur. Exemple : « 99 % des requêtes HTTP renvoient un code 2xx », soit 1 % d’erreur. Définissez ce qu’est un « plantage » (exception, code 5xx) et comptez-le.
3. « On perd des dossiers en route »
Suivez un taux de complétion. Google SRE propose de mesurer la « couverture d’un pipeline » : proportion de transactions traitées sur le total. « 100 dossiers créés doivent aboutir à 100 clôturés. S’il n’y en a que 95, le taux de complétion est de 95 %. »
En synthèse, chaque plainte doit être traduite en signaux mesurables : performance (temps), fiabilité (erreurs), complétude (processus terminés).
Une fois les indicateurs identifiés, on entre dans le vocabulaire de l’observabilité pilotée par objectifs.
Qu’est-ce que le SLI (Service Level Indicator) ?
La métrique observable représentant la qualité du service côté utilisateur. Souvent un taux de réussite, une latence, une disponibilité. Par exemple : « pourcentage de requêtes servies en <2s ».
Qu’est-ce que le SLO (Service Level Objective) ?
La valeur-cible pour un SLI donné, sur une période. Exemple : « 95 % des requêtes en <400 ms sur 30 jours ». C’est la tolérance au-dessous de laquelle on considère qu’il y a défaut. Chaque organisation doit définir ses propres SLO selon ses parcours critiques, il n’existe pas de formule magique.
Qu’est-ce que le Error budget (budget d’erreur) ?
Le « budget de fiabilité » autorisé. Si votre SLO est de 99 %, le budget d’erreur est de 1 %. C’est combien de défauts on accepte avant de considérer le niveau de service non tenu.
Selon Implementing Service Level Objectives, « un budget d’erreur mesure comment le SLI a performé par rapport au SLO. Il définit à quel point le service est autorisé à être non fiable et sert de signal pour savoir quand corriger le tir. »
On peut le « dépenser » progressivement : chaque erreur en consomme. Si on le brûle trop vite, c’est le signal qu’il faut freiner les nouvelles features et améliorer la fiabilité. Chez Google, ces budgets déclenchent le gel des déploiements quand ils sont presque épuisés.
Avec SLI, SLO et budgets d’erreur, l’organisation se dote d’une grammaire commune. Plutôt que « c’est trop lent », on dit : « notre SLI de latence P95 login est hors objectif cette semaine », une alerte immédiate sur un défaut concret et son ampleur.
Aucun catalogue universel ne convient à tous :
- une fintech surveillera les transactions et temps de paiement
- une plateforme vidéo le buffering et la qualité de lecture.
L’important est que vos indicateurs couvrent vos parcours critiques et reflètent vos seuils de tolérance.
Les vanity metrics : Des indicateurs qui impressionnent dans un rapport mais n’ont aucune action derrière. Un SLO à 99,9 % peut masquer l’essentiel.
Cas d’école : une entreprise SaaS se félicitait d’un uptime de 99,94 % tous voyants au vert, alors qu’une panne ciblée le week-end avait coûté 2,3 M$ de ventes manquées. Le CTO a réalisé qu’ils « optimisaient les tableaux de bord, pas les résultats métier ».
L’accumulation de métriques : Trop d’indicateurs tue l’indicateur. Suivre 120 graphiques sans hiérarchie noie l’attention. Mieux vaut quelques indicateurs clés bien définis que multiplier les mesures sans plan d’exploitation. Chaque métrique de votre tableau de bord a-t-elle un objectif ou une décision associée ? Sinon, est-elle nécessaire ?
La déconnexion métier/technique : Un taux d’erreur global de 0,1 % semble excellent, sauf si ces erreurs touchent uniquement le module de paiement ! Un temps moyen parfait peut occulter que les clients premium subissent des ralentissements. Croisez les données techniques avec les impacts métier : distinguez les SLI par segment d’utilisateurs, par fonctionnalité critique.
Des métriques sans objectif ni propriétaire : Une métrique orpheline (sans SLO associé, sans responsable) finit ignorée. Chaque indicateur devrait avoir quelqu’un qui comprend son sens et sait quoi faire s’il dévie. Sinon, vous obtenez des dashboards cimetière, jolis mais inertes.
Mesurer les défauts, c’est leur donner une forme exploitable. En convertissant des plaintes parfois floues en SLI et SLO précis, on reconnecte enfin la technique avec l’impact réel sur le métier. Cette approche permet de détecter les problèmes avant qu’ils ne touchent les utilisateurs, et de prioriser grâce à un langage commun : lorsqu’un SLO est dépassé, le défaut devient objectif et doit être traité.
Dans le prochain article, nous verrons quels outils et quelle démarche permettent de mettre en œuvre cette observabilité. Nous parlerons instrumentation, plateformes (Grafana, Datadog, New Relic, Splunk) et bonnes pratiques pour construire vos tableaux de bord orientés SLO, afin de détecter, comprendre et résoudre les défauts de façon proactive.
