Comment mettre en œuvre une démarche d’observabilité

Pendant longtemps, l’observabilité a été traitée comme un sujet purement technique.
Un sujet d’ops.
Un sujet d’outils.

Dans les faits, quand un incident arrivait, le scénario était toujours le même :

• on voyait que “ça ne va pas”,
  
• on ne savait pas exactement où,
  
• encore moins pourquoi,
  
• et le business découvrait souvent le problème avant les équipes internes.
  
  

👉 Le SI était surveillé, mais pas réellement observable.

Avec le temps (et pas mal d’incidents), une conviction s’est imposée :
mettre en œuvre une démarche d’observabilité, ce n’est pas installer une stack, c’est changer de posture.

Voici comment nous l’abordons sur le terrain.

‍

Avant de commencer : l’observabilité n’est pas un projet outillé

‍

Premier point clé :
si vous démarrez par choisir un outil, vous êtes déjà mal partis.

L’observabilité n’est ni :

• un dashboard de plus,
  
• ni un nouveau système d’alerting,
  
• ni un chantier “tech only”.
  
  

👉 C’est un levier de pilotage, qui doit permettre de répondre à des questions simples :

• Est-ce que mes parcours critiques fonctionnent ?
  
• Est-ce que mes APIs tiennent leurs engagements ?
  
• Où ça casse ?
  
• Depuis quand ?
  
• Avec quel impact métier ?
  
  

À partir de là, la démarche peut commencer.

‍

Étape 1 – S’immerger dans l’existant (audit 360°)

‍

La première erreur serait de vouloir “réparer” sans comprendre.

Dans la plupart des SI que nous rencontrons :

• les outils sont nombreux,
  
• les équipes ont chacune leur vision,
  
• les signaux existent… mais ne se parlent pas.
  
  

On commence donc par un audit terrain, très concret :

• cartographie des outils de monitoring existants,
  
• analyse de leurs usages réels (pas ceux sur le papier),
  
• identification des parcours et services réellement critiques,
  
• interviews des parties prenantes (tech, ops, support, métier).
  
  

L’objectif n’est pas de juger, mais de répondre à une question essentielle :

Qu’est-ce qui empêche aujourd’hui une observabilité end-to-end ?

À l’issue de cette phase, on formalise les constats et les arbitrages dans un ADR (Architecture Decision Record).
Pas pour faire joli, mais pour poser une base claire et partagée.

‍

Étape 2 – Définir ce que “bien fonctionner” veut vraiment dire

‍

C’est souvent le moment le plus structurant.

On met tout le monde autour de la table (métier, IT, produit) et on travaille sur :

• les parcours critiques,
  
• les APIs à enjeu,
  
• les engagements réels vis-à-vis des clients et partenaires.
  
  

On introduit alors trois notions clés :

• SLI : ce que l’on mesure réellement
  
• SLO : l’objectif que l’on se fixe
  
• SLA : l’engagement contractuel éventuel
  
  

Ce travail permet de sortir des perceptions subjectives :

“ça marche plutôt bien”
“on a souvent des problèmes”

Pour aller vers quelque chose de factuel :

“le parcours de souscription est disponible à 99,8 % sur 30 jours”

👉 À partir de là, l’observabilité devient un sujet compréhensible par le business.

‍

Étape 3 – Poser les fondations techniques minimales

‍

Seulement maintenant, on parle technique.

Objectif : construire une base exploitable, sans chercher l’exhaustivité.

Cela passe généralement par :

• un standard de collecte clair,
  
• un correlation ID propagé de bout en bout,
  
• une centralisation des logs exploitable,
  
• une première expérimentation de tracing / APM,
  
• quelques métriques simples, mais fiables.
  
  

À ce stade, on ne cherche pas la perfection.
On cherche à valider que le pipeline fonctionne, et qu’il permet déjà :

• d’accélérer les diagnostics,
  
• de confronter plusieurs signaux,
  
• de détecter des comportements anormaux.
  
  

C’est souvent là que les équipes prennent conscience de la valeur réelle de l’observabilité.

‍

Étape 4 – Passer à une observabilité end-to-end orientée parcours

‍

Une fois les fondations posées, on peut changer d’échelle.

L’enjeu devient alors :
👉 passer d’une observabilité “par brique” à une observabilité par parcours utilisateur.

Concrètement :

• les traces sont collectées sur toutes les briques du parcours,
  
• elles sont enrichies avec du contexte métier,
  
• les dashboards sont construits autour des questions à se poser, pas des métriques disponibles.
  
  

Un bon dashboard doit permettre de répondre rapidement à :

• Est-ce que le parcours fonctionne ?
  
• Où est le point de rupture ?
  
• Est-ce un problème technique ou fonctionnel ?
  
  

À ce stade, les dashboards deviennent un point de rencontre entre :

• IT,
  
• support,
  
• produit,
  
• métier.
  
  

Étape 5 – Industrialiser et gouverner

‍

C’est souvent l’étape la plus négligée… et pourtant la plus critique.

Sans gouvernance :

• les dashboards se multiplient,
  
• les alertes redeviennent bruyantes,
  
• la démarche s’essouffle.
  
  

On travaille alors sur :

• un health model (score de santé par service / parcours),
  
• un catalogue d’alertes standardisées, basé sur les SLO,
  
• un RACI clair entre les équipes,
  
• des règles de rétention et d’accès aux données.
  
  

L’objectif est simple :
👉 faire de l’observabilité un réflexe industriel, pas un projet ponctuel.

‍

Ce qu’il faut retenir

‍

Mettre en œuvre une démarche d’observabilité, ce n’est pas :

• tout mesurer,
  
• tout centraliser,
  
• ni viser le zéro incident.
  
  

C’est :

• accepter que les incidents arrivent,
  
• se donner les moyens de les détecter avant les clients,
  
• comprendre rapidement leur impact réel,
  
• et piloter le SI sur la base de faits.
  
  

Quand c’est bien fait, l’observabilité devient :

• un levier de sérénité pour les équipes,
  
• un outil d’arbitrage pour le produit,
  
  

et un langage commun entre la tech et le business.