Passerelles : sortir l'observabilité de la DSI

Pourquoi les projets d’observabilité échouent rarement à cause de l’outil

Quand un projet d’observabilité échoue, c’est rarement pour une raison technique. Les données sont là, les tableaux de bord aussi. On retrouve plutôt des situations comme celles-ci :

• la direction financière voit une facture qui augmente sans comprendre ce qu’elle achète ;
• les métiers ne se reconnaissent pas dans des courbes de CPU et de latence p99 ;
• la conformité découvre au moment de l’audit que les preuves existent mais ne sont ni conservées, ni exportables ;
• la direction ne sait pas dire si l’investissement a réduit le risque ;
• l’équipe technique, seule à regarder, s’épuise à défendre un budget que personne d’autre ne porte.

Tant qu’elle reste dans l’informatique, l’observabilité passe pour un centre de coût. Sa place change quand d’autres directions s’en servent pour décider, parce qu’elle leur donne un langage commun avec l’équipe technique.

Partir des questions des autres

On instrumente un système pour répondre à des questions. Je recommande donc de commencer un projet par l’inventaire de ces questions, avant de parler d’outil. À mon avis, la plupart viennent d’en dehors de l’équipe technique.

Qui demande	La question qu’on lui pose rarement	Ce que l’observabilité peut répondre
Direction métier, produit	nos clients réussissent-ils ce qu’ils viennent faire ?	taux de parcours aboutis, temps de bout en bout, par segment de clientèle
Direction financière	combien coûte une transaction, un client, une fonctionnalité ?	coût unitaire de l’infrastructure et de la télémétrie, coût par requête d’un LLM
Risque, conformité, juridique	pouvons-nous prouver ce qui s’est passé et le prouver à un tiers ?	journaux intègres, traces conservées, matrice de preuve DORA, NIS2, AI Act
Relation client, support	ce client a-t-il vraiment subi l’incident qu’il signale ?	la trace de sa requête, avec l’objectif de la retrouver en moins d’une minute
Achats	sommes-nous captifs de notre éditeur ?	standards ouverts, portabilité des données, coût de sortie
Ressources humaines, management	l’équipe tient-elle dans la durée ?	charge d’astreinte, alertes par nuit et par personne, bruit
Direction générale	où investir pour réduire le risque ?	exposition chiffrée des angles morts, valeur évitée

Un atelier pour commencer

Réunissez une demi-journée un représentant de chaque ligne de la colonne de gauche. Posez une seule question : « Qu’aimeriez-vous savoir sur nos services que vous ne savez pas aujourd’hui ? » La liste obtenue vaut une feuille de route. La méthode est détaillée dans l’étape 1 du guide.

Cinq passerelles à construire

flowchart LR
  O(("Observabilité"))
  O --- B["1. Business<br/>valeur et coût"]
  O --- ORG["2. Organisation<br/>qui décide, qui possède"]
  O --- MET["3. Métiers<br/>signaux traduits"]
  O --- SUP["4. Fonctions support<br/>finance, conformité, achats"]
  O --- PER["5. Personnes<br/>langage et rituels"]

1. Vers le business, en parlant valeur et coût

• Exprimer les SLO comme des promesses faites aux clients. « 99,5 % des paiements aboutissent en moins de deux secondes » parle à un directeur produit, alors que « latence p99 de l’API inférieure à 800 ms » ne lui dit rien.
• Calculer un coût unitaire, par transaction, par client ou par fonctionnalité. C’est le seul chiffre qu’un contrôleur de gestion peut comparer d’un mois sur l’autre.
• Chiffrer la valeur évitée à partir du coût d’un incident, de la durée d’exposition et des angles morts. Le calculateur d’exposition en donne un exemple pour l’IA.

2. Vers l’organisation, en disant qui décide et qui possède

• Qui choisit ce qui est collecté, qui paie la télémétrie, qui possède chaque alerte ? Tant que la réponse n’est écrite nulle part, personne ne s’en charge.
• Les contrats de données et un RACI transforment des bonnes intentions en règles. Voir le plan organisation et la partie VII de la méthode GenAI.

3. Vers les métiers, en traduisant les signaux

• Instrumenter les événements métier (commande validée, dossier instruit, prêt accordé) avec le même soin que les appels techniques et les relier aux traces. On parle parfois d’observabilité métier.
• Tenir un dictionnaire de traduction entre indicateur technique et indicateur métier (voir l’exemple plus bas).
• Construire des tableaux de bord par audience. Un tableau de bord d’exploitation n’est pas fait pour un comité de direction : à mon avis, il perd plus d’attention qu’il n’en gagne.

4. Vers les fonctions support (finance, conformité, achats)

• Finance : un budget de télémétrie suivi comme les autres, avec ses dérives et ses leviers. Voir le plan business.
• Conformité : la preuve est un sous-produit d’une instrumentation bien posée, à condition de la concevoir dès le départ. Voir l’intégrité des journaux et la matrice de preuve.
• Achats : une fois le contrat signé, il est trop tard pour obtenir la réversibilité. Elle se discute pendant la négociation.

5. Vers les personnes, avec un langage et des rituels communs

• Une revue mensuelle qui réunit technique, produit et finance autour de trois chiffres, à savoir la qualité de service vue du client, le coût unitaire et les incidents avec leurs causes.
• Des post-mortems ouverts aux métiers concernés. Ils y découvrent comment fonctionne le système et l’équipe technique y apprend ce que l’incident a réellement coûté.

Un exemple de traduction

Signal technique	Indicateur métier	Décision éclairée
latence p95 du service de paiement	taux de paniers abandonnés à l’étape paiement	prioriser l’optimisation ou un second prestataire de paiement
taux d’erreur du moteur de tarification	devis non émis par jour, chiffre d’affaires différé	arbitrer entre correctif immédiat et mode dégradé
jetons consommés par fonctionnalité d’IA	coût par conversation client assistée	ajuster le modèle, le cache ou le prix de l’offre
score de fidélité d’un assistant RAG	réclamations liées à une information erronée	déclencher la mise à jour de la base documentaire
alertes de nuit par personne d’astreinte	turnover et absentéisme de l’équipe	revoir les seuils, les rotations, les effectifs

Chaque ligne met en relation trois personnes qui ne se parlent pas toujours : celle qui voit le signal, celle qui porte l’indicateur et celle qui décide.

Pour la première ligne, la chaîne se lit comme suit. Elle se referme quand la décision modifie le signal.

flowchart LR
  S["Signal technique<br/>latence p95 du paiement"] -->|"traduction"| I["Indicateur métier<br/>paniers abandonnés"]
  I -->|"arbitrage"| D["Décision<br/>optimiser ou second prestataire"]
  D -.->|"effet mesuré"| S

Les signes qu’une passerelle manque

• Le projet d’observabilité est porté par la seule DSI, sans sponsor métier.
• Les tableaux de bord n’ont jamais été ouverts par quelqu’un d’extérieur à l’équipe technique.
• Aucun SLO n’est formulé dans les mots d’un client.
• Le coût de la télémétrie est découvert à la facture.
• La conformité n’a pas été consultée sur la rétention des journaux.
• Les post-mortems ne circulent pas au-delà de l’équipe d’exploitation.

Sur ce site

Chaque article et chaque formation se termine par un encadré Passerelles qui dit ce que le sujet change pour le business, l’organisation, les équipes et les métiers. Je m’y tiens sur toutes les pages, comme l’explique le manifeste.