Aller au contenu
MTTL, Mean Time To Learn

OrganisationPratique8 min de lecture

Votre observabilité n'a pas de propriétaire

Les plateformes d'observabilité coûtent de plus en plus cher, contiennent des données sensibles et servent de preuve devant les régulateurs. Pourtant, rares sont les organisations capables de dire qui en est responsable. Un cadre de gouvernance en quatre piliers.

Pour : architectes · managers d’équipe · finance, risque et conformité · direction et DSIPrérequis : Aucun. Le livre blanc associé détaille chaque pilier.

Mode de lecture

Posez une question simple dans votre organisation : qui décide de ce qu’on journalise ? Pas qui installe l’agent (le petit logiciel qui collecte les données sur chaque machine), pas qui gère le contrat. Qui décide qu’un log, une ligne de journal écrite par une application, mérite d’être produit, transporté, indexé, conservé douze mois et payé ?

La réponse la plus fréquente est un silence, suivi de « ça dépend des équipes ». C’est le symptôme d’une observabilité sans propriétaire. Elle fonctionne, souvent bien. Mais elle dérive : en coûts, en formats, en outils, en données que personne n’aurait dû collecter.

Cet article résume un cadre de gouvernance en quatre piliers, détaillé dans le livre blanc Gouverner l’observabilité.

Changer d’outil ne suffit pas

Section intitulée « Changer d’outil ne suffit pas »

Quand la facture explose, le premier réflexe est de changer d’outil. On migre d’un éditeur à un autre, ou vers une stack open source (un assemblage d’outils libres). Quelques trimestres plus tard, les mêmes symptômes réapparaissent sur la nouvelle plateforme, parce que rien n’a changé dans la façon de décider.

Le changement de regard consiste à traiter les données d’observabilité comme ce qu’elles sont : un flux de données d’entreprise. Or un flux de données d’entreprise se gouverne. On définit ce qui entre, sous quelle forme, pour quel usage, pendant combien de temps, qui y accède et qui paie. Les équipes data font cela depuis des années pour leurs entrepôts. L’observabilité n’a simplement pas encore fait ce chemin.

Gouverner ne veut pas dire créer un comité qui valide chaque tableau de bord. Une bonne gouvernance est presque invisible : ses règles sont codées dans les pipelines (les chaînes qui acheminent les données) et dans la CI, l’intégration continue qui vérifie automatiquement chaque modification avant sa mise en production. Les équipes produit y gagnent une instrumentation par défaut, des tableaux de bord prêts à l’emploi et une facture lisible. Le principe directeur est celui du chemin balisé : rendre le bon comportement plus simple que le mauvais.

Quatre piliers, quatre règles

Section intitulée « Quatre piliers, quatre règles »

Organisation : la plateforme a un propriétaire, le signal aussi

Section intitulée « Organisation : la plateforme a un propriétaire, le signal aussi »

Le modèle qui fonctionne est fédéré. Une équipe plateforme fournit le socle, les bibliothèques d’instrumentation et les règles. Chaque équipe produit reste propriétaire de ses signaux, de ses SLO (ses objectifs de qualité de service chiffrés) et de ses alertes. Autour, un comité d’observabilité léger se réunit une fois par mois avec un ordre du jour fixe : évolutions du schéma, exceptions, dépassements de budget, retraits d’outils. Les modèles d’équipe comparent cette organisation aux autres.

La règle : aucun signal n’entre dans la plateforme sans un attribut qui désigne l’équipe propriétaire.

Standards : OpenTelemetry comme langue commune

Section intitulée « Standards : OpenTelemetry comme langue commune »

OpenTelemetry, le standard ouvert qui sert à produire métriques, journaux et traces, sépare la production des signaux de leur stockage. On instrumente une fois, c’est-à-dire qu’on ajoute une seule fois au code de quoi émettre ses signaux ; le backend, l’outil qui stocke et affiche les données, devient un choix réversible. Les conventions sémantiques, des noms communs pour décrire une requête HTTP ou un appel à une base de données, fournissent le vocabulaire, mais avec une nuance que beaucoup ignorent : chaque convention a un statut de stabilité, qui dit si ses noms peuvent encore changer. Les conventions HTTP sont stables depuis fin 2023, le cœur de celles des bases de données depuis 2025, alors que les conventions GenAI sont toujours au statut Development en 2026.

La règle : seuls les attributs stables peuvent servir de base à une alerte, à un SLO ou à une imputation de coût. Et la configuration des collecteurs vit dans Git, l’outil où les équipes conservent l’historique de leur code, comme n’importe quel code.

Coûts : rendre visible avant de refacturer

Section intitulée « Coûts : rendre visible avant de refacturer »

Chaque signal stocké résulte d’un choix, souvent implicite, de le conserver. La gouvernance rend ce choix explicite. On mesure d’abord les volumes par équipe et par service, on les montre à chaque équipe sans la faire payer (c’est le showback), puis on attribue des budgets. La refacturation effective ne vient qu’une fois les chiffres acceptés par tous. Les leviers techniques sont connus : filtrage à la source, échantillonnage en queue, maîtrise de la cardinalité, rétention par paliers. L’échantillonnage en queue ne garde qu’une partie des traces, choisies une fois la requête terminée, par exemple celles en erreur. La cardinalité est le nombre de combinaisons d’étiquettes d’une mesure, qui fait grossir le stockage. La rétention par paliers place les données sur un stockage rapide, puis sur un stockage moins cher à mesure qu’elles vieillissent. Ces leviers sont détaillés dans Gouverner les données d’observabilité.

La règle : chaque classe de données a une durée de conservation minimale et maximale, fixée à l’avance. La durée maximale compte autant que la minimale.

Conformité et souveraineté : les logs sont des données personnelles

Section intitulée « Conformité et souveraineté : les logs sont des données personnelles »

C’est le pilier le plus souvent oublié et le plus exposé. Les logs contiennent des e-mails, des identifiants, des adresses IP. La CNIL, l’autorité française de protection des données, recommande de conserver les journaux d’accès entre six mois et un an et d’y minimiser les données personnelles. DORA, le règlement européen sur la résilience opérationnelle numérique du secteur financier, impose aux entités financières des journaux protégés contre l’altération et une surveillance des pannes de journalisation. NIS2, la directive européenne sur la cybersécurité, arrive en France via le projet de loi Résilience : son examen en séance, prévu à l’Assemblée nationale le 7 octobre 2026, a été retiré de l’ordre du jour la veille, sans nouvelle date à ce jour. L’AI Act, le règlement européen sur l’intelligence artificielle, exigera la journalisation des systèmes d’IA à haut risque, avec une application désormais reportée au 2 décembre 2027 pour la plupart d’entre eux (annexe III) et au 2 août 2028 pour les autres (annexe I).

Ces textes convergent sur quatre exigences : savoir ce qui est journalisé, le conserver pendant une durée justifiée, en garantir l’intégrité et en contrôler l’accès. Un seul cadre de gouvernance peut y répondre. Quant à la souveraineté, elle repose sur trois conditions : un hébergement maîtrisé, un format ouvert et une réversibilité écrite dans les contrats. L’article Observabilité et souveraineté numérique développe ce point.

La règle : les données personnelles sont filtrées à la passerelle, le point de passage commun par lequel transitent les données avant d’être stockées, par des règles testées en CI, non au bon vouloir de chaque développeur.

Par où commencer ?

Section intitulée « Par où commencer ? »

Une feuille de route réaliste tient en douze mois et trois phases.

  1. Poser les bases (0 à 90 jours). Nommer un sponsor (un membre de la direction qui porte le sujet) et un responsable de plateforme. Inventorier les outils, les agents et les volumes. Rédiger une charte d’observabilité d’une page et la liste des attributs obligatoires, avec deux ou trois équipes pilotes.
  2. Rendre la règle exécutable (mois 3 à 6). Déployer des passerelles OpenTelemetry communes, y appliquer le filtrage des données personnelles et la validation du schéma, publier le showback par équipe, valider les durées de conservation avec le DPO (le délégué à la protection des données).
  3. Piloter (mois 6 à 12). Contrôles en CI et à l’ingestion (la réception des données par la plateforme), budgets par équipe, stockage non modifiable pour les journaux de preuve, plan de sortie testé pour chaque backend.

Trois pièges reviennent souvent :

  • Commencer par les interdits. Une gouvernance qui interdit avant d’offrir un chemin balisé est contournée dès la première urgence.
  • Refacturer trop tôt. Imputer des coûts sur des chiffres contestés détruit la confiance dans toute la démarche.
  • Confondre gouvernance et choix d’outil. Un appel d’offres n’est pas une politique d’observabilité. La gouvernance précède l’outil et lui survit.

Enfin, mesurez. Une douzaine d’indicateurs suffit. Mon préféré : la part des données stockées qui n’ont jamais été lues. Il révèle directement les données produites par habitude plutôt que par besoin.

Pour aller plus loin

Section intitulée « Pour aller plus loin »

L’observabilité a longtemps été un sujet d’outillage. Elle est devenue un sujet de décision : sur l’argent, sur les données personnelles, sur la preuve et sur la dépendance aux éditeurs. La technique reste nécessaire, mais elle ne suffit plus. Ce qui manque le plus souvent, plus qu’un collecteur ou un backend, c’est quelqu’un qui décide, des règles écrites et des pipelines qui les appliquent.

Le livre blanc Gouverner l’observabilité détaille ce cadre : matrice RACI (qui réalise, qui tranche, qui est consulté, qui est informé), attributs obligatoires, leviers de coûts, tableau réglementaire, modèle de maturité en cinq niveaux, feuille de route, indicateurs, charte type et checklist d’arrivée d’une nouvelle équipe (onboarding).

Quand tu ne sais pas, tu demandes ; mais quand tu sais, tu partages. Vos retours d’expérience sont les bienvenus.

Sources

Section intitulée « Sources »