Faire de l’observabilité un outil de décision, pas une collection de dashboards

Le problème réel

Le client ne manquait pas de données.

Métriques, logs et dashboards existaient déjà. Pourtant, au moment de prendre une décision de release ou d’évaluer un changement risqué, les équipes revenaient encore vers les mêmes personnes capables de reconstituer mentalement les dépendances et les conséquences possibles.

Le problème n’était donc pas la quantité de télémétrie. C’était son rapport aux décisions.

Ce que nous avons trouvé

Les tableaux de bord répondaient correctement à certaines questions d’exploitation : saturation, disponibilité d’un composant, état d’une infrastructure.

Ils répondaient beaucoup moins bien à des questions comme :

• quel service peut être affecté par ce changement ;
• quel signal permet réellement d’autoriser ou de bloquer une release ;
• qui possède ce signal ;
• quelle absence de donnée doit empêcher une décision.

Ajouter des collecteurs ou des dashboards supplémentaires aurait augmenté le volume d’information sans corriger ce défaut de conception.

Notre intervention

Nous avons inversé le raisonnement habituel.

Au lieu de partir des outils disponibles, nous sommes partis des décisions à prendre : go/no-go, risque de changement, propriété d’un incident, impact potentiel et niveau de preuve attendu.

Pour chaque décision, nous avons évalué les signaux existants, identifié les trous, puis construit une architecture cible et une séquence d’adoption qui conservaient ce qui était déjà utile.

L’arbitrage

Le choix n’a pas été « quel nouvel outil acheter ? ».

Le choix a été de différer une partie de l’extension technique afin de définir d’abord le jeu de preuves minimal, les responsabilités et les questions auxquelles l’observabilité devait répondre.

Cela évitait un remplacement greenfield coûteux tout en donnant une direction claire aux investissements suivants.

Ce qui a changé

La télémétrie a cessé d’être discutée uniquement comme une stack technique. Elle a été reliée à des décisions identifiables.

Les équipes pouvaient distinguer un signal nécessaire à une décision de release d’un dashboard simplement utile au confort d’exploitation. La trajectoire d’architecture est devenue plus simple à défendre auprès de l’ingénierie comme de la gouvernance.

Ce que nous retenons

Une plateforme d’observabilité ne crée pas de confiance parce qu’elle collecte beaucoup de données.

Elle crée de la confiance lorsqu’une équipe sait quelle question chaque signal permet de trancher, qui en est responsable et ce qui se passe lorsque ce signal manque.