Joseph Delassalle
expertise/fiabilite-observabilite

Fiabilité & observabilité : détecter les pannes avant vos utilisateurs

Le problème

Votre monitoring existe, mais il ne sert à rien au moment où ça compte : des dashboards que personne ne regarde, des alertes que tout le monde ignore parce qu’elles crient en permanence, et des incidents découverts par le support client plutôt que par la supervision.

Pour la direction, ça se traduit en risques concrets : des pannes que vos clients voient avant vous — et qu’ils racontent ; des astreintes qui usent les équipes jusqu’au départ des meilleurs ; et des arbitrages à l’aveugle, parce que personne ne peut dire si la plateforme va mieux ou moins bien qu’il y a six mois. Quand ça casse, le diagnostic commence par vingt minutes de recherche de la bonne information.

L’observabilité n’est pas une pile d’outils, c’est une discipline : savoir à quelles questions votre production doit pouvoir répondre, et instrumenter pour ça.

La méthode

  1. Faire l'état des lieux

    Ce qui est mesuré, ce qui devrait l'être, ce qui hurle pour rien. On part de vos incidents récents : qu'aurait-il fallu voir, et en combien de temps ?

  2. Définir des SLI/SLO qui décident

    Deux ou trois indicateurs sur les parcours réels des utilisateurs, définis avec vos équipes — pas le CPU des machines. Un SLO n'est utile que s'il peut déclencher une décision.

  3. Refondre la supervision

    Des alertes actionnables ou pas d'alerte : chaque réveil nocturne correspond à une action concrète, le reste va dans un tableau de bord ou à la poubelle. Outillage sobre — Prometheus, Grafana, logs structurés, tracing là où il apporte quelque chose.

  4. Transférer l'autonomie

    Runbooks d'incident, boucle post-mortem sans recherche de coupable, et une équipe formée à exploiter sa propre observabilité. L'outillage qui reste est celui que vous comprenez et faites vivre sans moi.

Sur le terrain

Pas de promesses hors-sol : des articles qui montrent comment je travaille, sur de vrais systèmes.

Format de mission

  • En direct avec moi, avec vos équipes d'exploitation et de développement autour de la table.
  • Sur site (axe Lille–Bruxelles) ou à distance.
  • Cadrée par les services critiques : on commence par ce qui fait mal, pas par un chantier global.
  • Livrables qui restent : SLO documentés, règles d'alerte versionnées, runbooks, boucle post-mortem installée.

Parlons de votre infra — 30 min, sans engagement

Questions fréquentes

Faut-il remplacer toute notre stack de monitoring ?
Rarement. Le problème est plus souvent dans ce qu'on mesure et ce qui alerte que dans l'outil. Si Prometheus et Grafana sont en place, on les garde et on les fait travailler ; on ne remplace que ce qui coûte plus qu'il ne rend.
C'est quoi, un SLO « pragmatique » ?
Un objectif défini sur un parcours utilisateur réel, que votre équipe peut tenir, et qui déclenche une décision quand il se dégrade — ralentir les mises en production, prioriser un chantier de fiabilité. Pas une batterie d'indicateurs copiée sur les pratiques d'un géant du web qui a mille fois vos moyens.
Nos alertes sonnent en permanence et tout le monde les ignore. Par où commencer ?
Par l'inventaire : pour chaque alerte, quelle action concrète attend-on de la personne réveillée ? S'il n'y en a pas, l'alerte devient une courbe sur un tableau de bord, ou disparaît. La fatigue d'alerte n'est pas une fatalité, c'est un backlog qu'on traite.
Est-ce que vous prenez l'astreinte à notre place ?
Non — externaliser l'astreinte, c'est externaliser la connaissance de votre production. L'objectif est de la rendre tenable pour vos équipes : moins d'alertes et de meilleures alertes, des runbooks qui font gagner les premières minutes d'un incident, et un temps de résolution (MTTR) qui baisse parce que le diagnostic démarre avec la bonne information sous les yeux.
Combien de temps dure ce type de mission ?
La mission est cadrée par vos services critiques, pas par un chantier global : on traite d'abord ce qui fait mal. Chaque périmètre couvert livre des résultats utilisables — SLO documentés, alertes révisées, runbooks — et la durée dépend du nombre de services traités. C'est l'état des lieux initial qui la rend prévisible.