OrganisationPratique27 min de lecture16 octobre 2026

Gouverner l'observabilité

Livre blanc : un cadre de gouvernance de l'observabilité en quatre piliers (organisation, standards, coûts, conformité), avec matrice RACI, attributs obligatoires, tableau réglementaire, modèle de maturité, feuille de route sur douze mois, indicateurs, charte type et checklist d'arrivée d'un nouveau service (onboarding).

Pour : architectes · managers d’équipe · finance, risque et conformité · direction et DSIPrérequis : Aucun pour le résumé ; les chapitres 4 et 5 supposent de connaître OpenTelemetry et le Collector.

Mode de lecture

Résumé

L’observabilité est devenue un actif d’entreprise : elle coûte cher, elle contient des données sensibles et elle sert de preuve devant les régulateurs. Pourtant, dans la plupart des organisations, personne n’en est propriétaire. Chaque équipe instrumente à sa façon, c’est-à-dire ajoute à son code de quoi produire des signaux (métriques, journaux, traces), chaque outil impose son format et la facture arrive sans que l’on sache à qui l’imputer.

Ce livre blanc propose un cadre de gouvernance en quatre piliers, conçu pour être appliqué progressivement et sans dépendre d’un éditeur :

Organisation et rôles : qui décide, qui produit les signaux, qui les exploite et qui les paie.
Standards et OpenTelemetry, le standard ouvert qui sert à produire et transporter les signaux : un vocabulaire commun, des attributs obligatoires et des pipelines (les chaînes qui collectent, transforment et acheminent les signaux) pilotés par la configuration.
Coûts et volumétrie : des budgets d’observabilité par équipe, des règles de rétention (durée de conservation) et d’échantillonnage (ne garder qu’une partie des traces), une imputation lisible.
Conformité et souveraineté : les logs sont des données personnelles et des preuves réglementaires ; leur cycle de vie doit être maîtrisé de bout en bout.

Trois messages structurent le document. D’abord, la gouvernance n’ajoute pas un comité de plus : elle tient dans un ensemble de règles appliquées automatiquement dans les pipelines. Ensuite, le standard ouvert est la condition de la souveraineté : sans OpenTelemetry, changer de backend (l’outil qui stocke et affiche les données) reste un projet de migration. Enfin, la gouvernance se mesure ; le chapitre 9 propose les indicateurs qui permettent de savoir si elle fonctionne. L’article Votre observabilité n’a pas de propriétaire en donne une version courte.

1. Le constat : une observabilité sans propriétaire

La plupart des plateformes d’observabilité n’ont pas été conçues ; elles se sont accumulées. Un outil pour l’infrastructure, un autre pour les applications, un SIEM pour la sécurité (l’outil qui centralise les événements de sécurité), puis un APM (un outil de suivi de la performance des applications) pour un projet stratégique. Chacun avait sa logique au moment de son adoption. Ensemble, ils forment un système que personne ne pilote.

Cinq symptômes reviennent d’une organisation à l’autre :

La dérive des coûts. Le volume de données d’observabilité croît plus vite que le parc applicatif. Les licences facturées au volume ingéré, c’est-à-dire à la quantité de données reçues par l’outil, transforment chaque log de debug oublié en ligne budgétaire. La facture est globale, son imputation est impossible.
La prolifération des outils. Plusieurs agents, ces petits logiciels de collecte installés sur chaque machine, tournent sur le même hôte et collectent les mêmes données pour des destinations différentes. Les compétences se dispersent, les contrats s’empilent.
Des signaux hétérogènes. Le même service s’appelle de trois façons selon l’équipe. Les attributs (les étiquettes qui accompagnent chaque signal) ne se recoupent pas, les requêtes transverses échouent et la corrélation entre traces, métriques et logs reste manuelle.
Des données sensibles hors de contrôle. Adresses e-mail, identifiants clients ou jetons d’authentification finissent dans les logs. Ils sont ensuite répliqués, indexés et conservés plus longtemps que les données métier qu’ils décrivent.
La dépendance éditeur. Les agents propriétaires, les langages de requête spécifiques et les tableaux de bord non exportables rendent toute sortie coûteuse. La question de la réversibilité n’est posée qu’au moment du renouvellement.

Ces symptômes ont une cause commune : l’observabilité est traitée comme un outillage technique, alors qu’elle est un flux de données d’entreprise. Un flux de données d’entreprise se gouverne : on définit ce qui entre, sous quelle forme, pour quel usage, pour combien de temps et à quel coût.

2. Définir la gouvernance de l’observabilité

La gouvernance de l’observabilité est l’ensemble des rôles, des règles et des mécanismes qui décident quels signaux sont produits, sous quelle forme, pour quels usages, pendant combien de temps et à quel coût. Elle couvre tout le cycle de vie du signal : instrumentation, collecte, transformation, transport, stockage, exploitation et suppression.

Son périmètre

Objet gouverné	Question à laquelle la gouvernance répond
Signaux (traces, métriques, logs, profils de consommation des ressources, événements)	Que collecte-t-on et qu’est-ce qu’on refuse de collecter ?
Schémas et attributs	Quel vocabulaire est obligatoire, recommandé ou interdit ?
Pipelines et agents	Qui configure les collecteurs et comment les changements sont-ils validés ?
Stockage et rétention	Combien de temps, à quel niveau de détail, sur quel hébergement ?
Accès	Qui peut lire quoi et comment ces accès sont-ils tracés ?
Coûts	Qui paie, sur quelle base, avec quel budget ?
Outils	Quels outils sont référencés, tolérés ou en voie de retrait ?

Ses objectifs

Utilité : chaque signal conservé doit servir un usage identifié (détection, diagnostic, SLO, c’est-à-dire objectif de qualité de service chiffré, sécurité, preuve réglementaire, capacité).
Cohérence : un même concept porte le même nom partout, ce qui rend la corrélation automatique.
Maîtrise : les coûts et les volumes sont prévisibles et imputables.
Conformité : les obligations légales sont satisfaites par construction, pas par audit a posteriori.
Réversibilité : l’organisation peut changer de backend sans réinstrumenter ses applications.

Ce qu’elle n’est pas

La gouvernance n’est pas un comité qui valide chaque tableau de bord. Elle n’est pas non plus un choix d’outil ; elle précède ce choix et lui survit. Enfin, elle n’est pas une contrainte imposée aux équipes produit : bien conçue, elle leur fournit 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é : faire du bon comportement le comportement le plus simple.

3. Pilier Organisation et rôles

La règle de base est simple : la plateforme d’observabilité appartient à une équipe, les signaux appartiennent à l’équipe qui les émet. Sans cette séparation, la plateforme devient le dépotoir des décisions que personne n’a prises.

Le modèle opérationnel

Trois modèles coexistent dans les organisations. Le modèle centralisé confie tout à une équipe unique ; il garantit la cohérence mais devient vite un goulet d’étranglement. Le modèle décentralisé laisse chaque équipe choisir ; il est rapide au départ et ingouvernable ensuite. Le modèle fédéré est celui que ce livre blanc recommande : une équipe plateforme fournit le socle et les règles, les équipes produit restent responsables de leur instrumentation et de leurs alertes.

Dans le modèle fédéré, la plateforme se comporte comme un produit interne. Elle a une feuille de route, un catalogue de services, des engagements de niveau de service et des utilisateurs dont elle mesure la satisfaction.

Les rôles

Rôle	Porté par	Responsabilités principales
Sponsor exécutif	DSI, CTO ou VP Engineering	Arbitre les budgets et les priorités, porte la politique d’observabilité
Responsable de la plateforme	Head of Observability ou Platform Lead	Porte la feuille de route et le catalogue ; rédige et fait appliquer la politique d’observabilité
Équipe plateforme	SRE et platform engineers	Exploite les collecteurs, les pipelines et les backends ; fournit les bibliothèques d’instrumentation
Propriétaire de service	Tech lead de chaque équipe produit	Instrumente son service, définit ses SLO, tient son budget d’observabilité
Champion observabilité	Un développeur volontaire par équipe	Relaie les standards, remonte les besoins, accompagne ses pairs
Sécurité et RSSI	Équipe sécurité	Définit les journaux de sécurité requis, leur intégrité et leurs accès
DPO	Délégué à la protection des données	Valide les données personnelles collectées et les durées de conservation
FinOps	Contrôle de gestion IT	Impute les coûts, suit les budgets, alerte sur les dérives

La matrice RACI

R : réalise. A : approuve et rend compte. C : consulté. I : informé.

Décision	Sponsor	Resp. plateforme	Équipe plateforme	Propriétaire de service	Sécurité	DPO	FinOps
Politique d’observabilité	A	R	C	C	C	C	C
Choix des backends et des outils	A	R	C	I	C	I	C
Attributs obligatoires	I	A	R	C	C	C	I
Instrumentation d’un service	I	I	C	A/R	I	I	I
Règles de rétention	I	A	R	C	C	C	C
Filtrage des données personnelles	I	A	R	C	C	C	I
Budget d’observabilité par équipe	A	C	C	R	I	I	R
SLO et alertes d’un service	I	I	C	A/R	I	I	I
Accès aux données d’observabilité	I	A	R	C	C	C	I

Le comité d’observabilité

Un comité léger, réuni une fois par mois, suffit. Il réunit le responsable de la plateforme, deux ou trois champions, un représentant sécurité, le DPO à la demande et le FinOps. Son ordre du jour est fixe : évolutions du schéma, demandes d’exception, dépassements de budget, retraits d’outils. Ses décisions sont tracées dans un registre versionné (dont chaque modification est conservée), à côté de la configuration des pipelines.

Le comité ne valide pas l’instrumentation au quotidien. Les règles qu’il adopte sont codées dans les pipelines et dans la CI, l’intégration continue qui vérifie automatiquement chaque modification de code ou de configuration ; une règle qui ne peut pas être automatisée doit être questionnée.

4. Pilier Standards et OpenTelemetry

OpenTelemetry est le standard de référence recommandé pour l’instrumentation et la collecte. Ce choix est stratégique plus que technologique : il sépare la production des signaux de leur stockage. Les applications sont instrumentées une fois ; le backend devient un choix réversible.

Les conventions sémantiques comme langue commune

Les conventions sémantiques d’OpenTelemetry définissent les noms, les types et les unités des attributs. Elles évoluent par versions : la v1.44.0 est parue en août 2026. Chaque convention porte un statut de stabilité (Stable, ou Development tant que ses noms peuvent encore changer) ; ce statut doit guider la gouvernance. Les conventions HTTP sont stables depuis la v1.23.0 (novembre 2023), le cœur des conventions des bases de données depuis la v1.33.0 (mai 2025, avec MariaDB, SQL Server, MySQL et PostgreSQL). Les conventions GenAI, en revanche, restent au statut Development et ont été déplacées en juin 2026 (v1.42.0) dans un dépôt dédié pour évoluer plus vite.

La règle de gouvernance qui en découle : seuls les attributs Stable peuvent servir de base à une alerte, à un SLO ou à une imputation de coût. Les attributs Development sont autorisés pour l’exploration, avec un suivi des versions pour anticiper les renommages.

Les attributs obligatoires

Un petit nombre d’attributs de ressource, ceux qui décrivent la source du signal (le service, sa version, son environnement), doit être présent sur tout signal admis dans la plateforme. Un signal qui ne les porte pas est rejeté ou mis en quarantaine (mis de côté pour examen) par le pipeline.

Attribut	Origine	Usage en gouvernance
`service.name`	Convention OTel	Identité du service, clé de toute corrélation
`service.version`	Convention OTel	Comparaison avant et après déploiement
`service.namespace`	Convention OTel	Regroupement par domaine métier
`deployment.environment.name`	Convention OTel	Séparation production et hors production, règles de rétention différenciées
`<org>.team`	Extension interne	Propriétaire du signal, routage des alertes
`<org>.cost_center`	Extension interne	Imputation des coûts
`<org>.data_classification`	Extension interne	Niveau de sensibilité, déclenche le filtrage et la rétention adaptés

Les extensions internes vivent dans un espace de noms propre à l’organisation (un préfixe qui lui est réservé), jamais dans un espace réservé par OpenTelemetry. Elles sont décrites dans un registre de schéma versionné, au même format que les conventions officielles, ce qui permet de générer la documentation et les contrôles automatiquement.

Des pipelines gouvernés par la configuration

L’architecture de référence comporte deux étages de collecteurs, les composants qui reçoivent, transforment et réexpédient les signaux. Les agents, au plus près des charges de travail, enrichissent les signaux avec les métadonnées d’infrastructure. Les passerelles, centralisées, appliquent les politiques : validation du schéma, filtrage des données personnelles, échantillonnage, routage vers les backends. C’est à l’étage passerelle que la gouvernance devient exécutable.

La configuration de ces collecteurs est traitée comme du code : stockée dans Git, revue, testée en CI et déployée de façon traçable. À grande échelle, un plan de contrôle (un poste de pilotage centralisé) fondé sur le protocole OpAMP, dont la spécification est encore au statut Beta, permet de piloter une flotte de collecteurs : inventaire, distribution de configuration, état de santé. Il répond à une question que la plupart des organisations ne savent pas traiter aujourd’hui : quelle configuration tourne réellement sur chaque agent ?

Les contrôles automatiques

En CI : vérification que chaque service déclare les attributs obligatoires et utilise des noms conformes au registre.
À l’ingestion, c’est-à-dire à la réception des données : rejet ou quarantaine des signaux non conformes, avec un compteur par équipe.
En continu : détection des dérives de cardinalité (le nombre de combinaisons de valeurs d’une métrique, qui fait grimper les coûts) et des attributs inconnus, signalées au propriétaire du service.

Sources : notes de version des conventions, conventions HTTP, conventions des bases de données, transfert des conventions GenAI et leur statut.

5. Pilier Coûts et volumétrie

Le coût de l’observabilité relève de la décision plus que de l’outil : chaque signal stocké résulte d’un choix, souvent implicite, de le conserver. La gouvernance rend ces choix explicites et les rattache à un propriétaire.

Rendre le coût visible

La première étape est la mesure. Le pipeline compte, pour chaque équipe et chaque service, les volumes ingérés par type de signal, la cardinalité des métriques et le volume stocké par niveau de rétention. Ces compteurs sont eux-mêmes des métriques, exposées dans un tableau de bord accessible à tous.

L’imputation suit l’attribut <org>.cost_center. On commence par le showback : chaque équipe voit ce qu’elle consomme, sans refacturation. Le chargeback, c’est-à-dire la refacturation effective, ne vient qu’une fois les données fiables et acceptées. Passer directement à la refacturation sur des chiffres contestés détruit la confiance dans la démarche.

Les budgets d’observabilité

Chaque équipe dispose d’un budget exprimé en volume ou en coût mensuel, négocié avec le FinOps et le responsable de la plateforme. Le budget n’est pas une sanction mais un outil d’arbitrage : une équipe qui veut plus de détail sur un service critique peut réduire ses logs de debug ailleurs. Les dépassements déclenchent une alerte au propriétaire, puis un passage en comité s’ils persistent.

Les leviers techniques

Levier	Principe	Point de vigilance
Filtrage à la source	Supprimer les signaux sans usage identifié (health checks, ces appels réguliers qui vérifient qu’un service répond, logs de debug en production)	Documenter ce qui est supprimé pour ne pas perdre un signal utile au diagnostic
Niveaux de log par environnement	Debug hors production uniquement, sauf activation temporaire et tracée	Prévoir un mécanisme d’activation à la demande avec expiration automatique
Échantillonnage en tête	Décision à l’entrée de la trace, à un taux fixe	Simple et peu coûteux, mais aveugle aux erreurs rares
Échantillonnage en queue	Décision après la trace complète : on garde les erreurs et les traces lentes	Demande de la mémoire et un routage cohérent par identifiant de trace sur les passerelles
Maîtrise de la cardinalité	Interdire les identifiants uniques (utilisateur, requête) comme labels de métriques	Les placer dans les traces ou les logs, où ils coûtent moins
Agrégation	Transformer des logs répétitifs en métriques à la passerelle	Conserver un échantillon brut pour le diagnostic
Rétention par paliers	Données chaudes courtes, tièdes agrégées, froides compressées sur stockage objet	Aligner les paliers sur les usages réels et sur les obligations légales

La politique de rétention

La rétention se décide par usage, pas par outil. Les données de diagnostic perdent l’essentiel de leur valeur en quelques jours ; les tendances de capacité se lisent sur des agrégats ; les journaux de sécurité et de preuve réglementaire obéissent à des durées imposées (voir chapitre 6). Chaque classe de données reçoit une durée minimale et une durée maximale, fixées à l’avance et justifiées.

La durée maximale compte autant que la minimale : conserver trop longtemps coûte de l’argent et crée un risque juridique.

6. Pilier Conformité et souveraineté

Les données d’observabilité ont un double statut juridique. Elles sont une obligation : plusieurs textes imposent de journaliser et de pouvoir reconstituer un incident. Elles sont aussi un risque : les logs contiennent des données personnelles et doivent respecter les mêmes principes que les données qu’ils décrivent. La gouvernance doit tenir ces deux exigences en même temps.

Le cadre réglementaire applicable

Le tableau cite quatre textes. Le RGPD est le règlement européen sur la protection des données personnelles, dont la CNIL, l’autorité française de protection des données, précise l’application. DORA est le règlement européen sur la résilience opérationnelle numérique du secteur financier ; ses RTS sont les normes techniques qui le précisent et le risque TIC désigne le risque lié aux technologies de l’information et de la communication. NIS2 est la directive européenne sur la cybersécurité. L’AI Act est le règlement européen sur l’intelligence artificielle.

Texte	Ce qu’il exige des données d’observabilité	État au 16 octobre 2026
RGPD et recommandation CNIL sur la journalisation	Journaliser les accès et actions des utilisateurs habilités ; conserver ces journaux entre six mois et un an, jusqu’à trois ans lorsqu’ils servent à des contrôles internes ; protéger les journaux eux-mêmes	Recommandation de 2021 (délibération 2021-122), non contraignante mais référence en cas de contrôle
DORA, RTS sur le cadre de gestion du risque TIC, article 12	Procédures de journalisation couvrant contrôle d’accès, gestion des capacités, changements, exploitation et trafic réseau ; protection contre l’altération et la suppression ; détection des pannes de journalisation ; synchronisation des horloges	Applicable aux entités financières soumises au cadre complet (hors cadre simplifié de l’article 16 de DORA)
NIS2	Gestion des risques, détection et notification des incidents, ce qui suppose une journalisation exploitable	Transposition française par le projet de loi Résilience : l’examen en séance prévu le 7 octobre 2026 a été retiré de l’ordre du jour la veille, sans nouvelle date au 16 octobre ; version de travail du référentiel ReCyF (v2.5) publiée par l’ANSSI le 17 mars 2026
AI Act, articles 12, 19 et 26	Journalisation automatique des événements des systèmes d’IA à haut risque sur toute leur durée de vie ; conservation d’au moins six mois	Omnibus numérique (règlement 2026/1744) : application reportée au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I

Ces textes convergent sur quatre exigences : savoir ce qui est journalisé, conserver pendant une durée justifiée, garantir l’intégrité des journaux, contrôler qui y accède. Un cadre de gouvernance unique peut y répondre, plutôt qu’un chantier par réglementation.

Les données personnelles dans les signaux d’observabilité

Le principe de minimisation s’applique aux données d’observabilité. Concrètement :

Classer chaque service selon la sensibilité des données qu’il manipule, via l’attribut <org>.data_classification.
Filtrer à la passerelle : masquage ou hachage (remplacement par une empreinte non réversible) des e-mails, numéros de téléphone, adresses IP, identifiants clients et jetons, avec des règles testées en CI comme le reste de la configuration.
Interdire par défaut la capture des corps de requête et des contenus de prompts (les instructions envoyées à un modèle d’IA) ; l’autoriser au cas par cas, après avis du DPO.
Aligner la rétention des journaux sur celle des données sources : un log ne doit pas survivre durablement à la donnée qu’il décrit.
Tracer les accès à la plateforme d’observabilité elle-même, qui devient un système sensible.

Intégrité et valeur probante

Un journal altérable n’a pas de valeur de preuve. Les journaux de sécurité et de conformité sont séparés des journaux d’exploitation, écrits sur un stockage non modifiable pendant leur durée de conservation ; leur chaîne de collecte est elle-même surveillée : une source qui se tait doit déclencher une alerte. L’horodatage repose sur une source de temps de référence documentée.

Souveraineté et réversibilité

La souveraineté de l’observabilité se joue sur trois plans :

L’hébergement. Les journaux décrivent l’architecture, les failles potentielles et les usages. Pour les organisations sensibles, leur stockage relève d’un hébergement qualifié (SecNumCloud en France, la qualification de l’ANSSI pour les offres d’informatique en nuage) ou maîtrisé en interne, à l’abri des lois extraterritoriales.
Le format. Des signaux produits en OpenTelemetry peuvent être routés vers n’importe quel backend compatible. Le format ouvert est la condition technique de la souveraineté.
La réversibilité contractuelle. Chaque contrat précise les modalités d’export des données, des tableaux de bord et des règles d’alerte. Un plan de sortie est rédigé et testé avant la signature, pas au moment de la rupture.

Ces éléments ne constituent pas un avis juridique ; chaque organisation doit les valider avec son DPO et son service juridique.

7. Modèle de maturité en cinq niveaux

Sur le terrain, beaucoup d’organisations se situent entre les niveaux 1 et 2. L’objectif réaliste à douze mois est le niveau 3 sur les quatre piliers ; le niveau 4 se construit ensuite ; le niveau 5 n’est utile que pour les organisations dont l’observabilité est un enjeu réglementaire ou commercial majeur.

Une organisation est au niveau de son pilier le plus faible : un excellent modèle de coûts ne compense pas des journaux de sécurité altérables.

Niveau	Organisation et rôles	Standards et OTel	Coûts et volumétrie	Conformité et souveraineté
1. Subie	Aucun propriétaire ; chaque équipe choisit ses outils	Formats propriétaires, nommage libre	Facture globale, non imputée	Données personnelles présentes sans contrôle ; rétention par défaut des outils
2. Outillée	Une équipe exploite les outils, sans mandat de gouvernance	Premiers collecteurs OTel ; quelques conventions locales	Volumes mesurés globalement	Journaux de sécurité identifiés ; rétentions documentées partiellement
3. Définie	Modèle fédéré, RACI publié, comité d’observabilité actif	Attributs obligatoires, registre de schéma, passerelles centralisées	Showback par équipe, politique de rétention par usage	Filtrage des données personnelles à la passerelle, durées validées par le DPO
4. Pilotée	Plateforme gérée comme un produit, avec SLO et satisfaction mesurée	Contrôles en CI et à l’ingestion, configuration en Git, plan de contrôle de flotte	Budgets par équipe, échantillonnage en queue, chargeback	Stockage non modifiable pour les preuves, surveillance de la chaîne de collecte, plan de sortie testé
5. Optimisée	La gouvernance évolue à partir de ses propres indicateurs	Contribution aux standards ouverts ; backends interchangeables en pratique	Coût unitaire suivi (par transaction, par service) et en baisse	Conformité démontrable à la demande, sans projet d’audit dédié

L’autoévaluation se fait pilier par pilier, avec des preuves : un document publié, une règle de pipeline, un tableau de bord. Une affirmation sans preuve vaut le niveau inférieur.

8. Feuille de route de mise en œuvre

La mise en œuvre tient en douze mois et vise le niveau 3 sur les quatre piliers. Chaque phase se termine par un jalon vérifiable ; on ne passe pas à la suivante sans l’avoir atteint.

Phase	Période	Actions clés	Jalon de sortie
1. Poser les bases	0 à 90 jours	Nommer sponsor et pilote ; inventaire outils et volumes ; charte d’observabilité publiée ; attributs obligatoires fixés	Charte signée et inventaire validé
2. Rendre exécutable	Mois 3 à 6	Passerelles OTel communes ; filtrage RGPD en passerelle ; showback par équipe ; rétention validée par le DPO	Niveau 3 sur deux piliers
3. Piloter	Mois 6 à 12	Contrôles CI et ingestion ; budgets par équipe ; preuves en stockage immuable ; plan de sortie testé	Niveau 3 sur les quatre piliers

Phase 1 : poser les bases (0 à 90 jours)

L’objectif est de créer le mandat et de mesurer l’existant. On nomme le sponsor et le responsable de la plateforme, puis on inventorie les outils, les agents déployés, les volumes ingérés et les contrats en cours. La charte d’observabilité et la liste des attributs obligatoires sont rédigées avec deux ou trois équipes pilotes, puis signées. Cette phase ne change encore rien à la production : elle produit la photographie de départ sans laquelle aucun progrès ne sera mesurable.

Phase 2 : rendre la règle exécutable (mois 3 à 6)

Les passerelles OpenTelemetry de référence sont déployées et les équipes pilotes y sont raccordées. Le filtrage des données personnelles et la validation des attributs obligatoires y sont appliqués. Le showback par équipe est publié et la politique de rétention par usage est validée avec le DPO et la sécurité. Le comité d’observabilité commence à siéger.

Phase 3 : piloter (mois 6 à 12)

Les contrôles passent en CI et à l’ingestion pour l’ensemble des équipes. Les budgets d’observabilité sont attribués et suivis. Les journaux de sécurité et de preuve basculent sur un stockage non modifiable avec surveillance de leur collecte. Un plan de sortie est rédigé et testé pour chaque backend. Les indicateurs du chapitre 9 deviennent l’ordre du jour du comité.

Le principal risque de cette feuille de route est de vouloir tout imposer dès la phase 1. Une gouvernance qui commence par des interdits avant d’offrir un chemin balisé est contournée.

9. Indicateurs de pilotage de la gouvernance

Une gouvernance qui ne se mesure pas devient un rituel. Une douzaine d’indicateurs suffit, revus chaque mois en comité d’observabilité et chaque trimestre avec le sponsor. Les cibles sont à fixer par chaque organisation à partir de sa mesure initiale ; ce tableau en donne la définition, pas la valeur.

Pilier	Indicateur	Définition	Sens attendu
Organisation	Couverture de propriété	Part des services dont l’attribut `<org>.team` est renseigné et valide	Vers 100 %
Organisation	Adoption de la plateforme	Part des services en production collectés par les pipelines de référence	En hausse
Organisation	Délai d’onboarding	Temps entre la demande d’une équipe et son premier tableau de bord exploitable	En baisse
Standards	Conformité au schéma	Part des signaux ingérés portant tous les attributs obligatoires	Vers 100 %
Standards	Signaux en quarantaine	Volume rejeté ou isolé pour non-conformité, par équipe	En baisse
Standards	Outils hors référentiel	Nombre d’outils d’observabilité en service non référencés	En baisse
Coûts	Coût unitaire	Coût d’observabilité rapporté à une unité métier (transaction, utilisateur actif, service)	Stable ou en baisse
Coûts	Respect des budgets	Part des équipes dans leur budget d’observabilité	En hausse
Coûts	Données jamais lues	Part des volumes stockés sans aucune requête sur la période	En baisse
Conformité	Fuites de données personnelles	Occurrences détectées de données personnelles non filtrées dans les backends	Vers zéro
Conformité	Respect des rétentions	Part des classes de données dont la durée effective respecte la politique	Vers 100 %
Conformité	Silence des sources critiques	Nombre et durée des interruptions de collecte sur les journaux de sécurité	Vers zéro

L’indicateur « données jamais lues » mérite une attention particulière : il révèle directement les données produites par habitude plutôt que par besoin. Il donne au comité une base factuelle pour décider des suppressions.

Annexes

A. Charte d’observabilité type

Cette charte tient sur une page. Elle est signée par le sponsor et publiée à côté du registre de schéma.

Tout signal admis dans la plateforme a un propriétaire identifié.
Toute donnée d’observabilité conservée sert un usage documenté : détection, diagnostic, SLO, sécurité, preuve réglementaire ou capacité.
L’instrumentation utilise OpenTelemetry et les conventions sémantiques ; les extensions internes sont déclarées dans le registre de schéma.
Les attributs obligatoires sont présents sur tout signal ; un signal non conforme est rejeté ou mis en quarantaine.
Les données personnelles sont minimisées à la source et filtrées à la passerelle ; toute exception est validée par le DPO.
Chaque classe de données a une durée de conservation minimale et maximale, fixée et justifiée à l’avance.
Chaque équipe dispose d’un budget d’observabilité et voit sa consommation.
La configuration des collecteurs est versionnée, revue et déployée de façon traçable.
Les journaux de sécurité et de preuve sont protégés contre l’altération ; leur collecte est surveillée.
Tout outil d’observabilité est référencé et dispose d’un plan de sortie.

B. Checklist d’onboarding d’un service

C. Glossaire

Terme	Définition
Cardinalité	Nombre de combinaisons distinctes de valeurs d’attributs pour une métrique ; principal facteur de coût des bases de séries temporelles
Chargeback	Refacturation effective des coûts d’observabilité aux équipes consommatrices
Collecteur	Composant OpenTelemetry qui reçoit, transforme et exporte les signaux ; déployé en agent ou en passerelle
Conventions sémantiques	Registre OpenTelemetry des noms, types et unités d’attributs standardisés
Échantillonnage en queue	Décision de conserver ou non une trace après l’avoir observée en entier
OpAMP	Protocole OpenTelemetry de gestion à distance d’une flotte d’agents
Showback	Affichage de la consommation par équipe, sans refacturation
SLO	Objectif de niveau de service, exprimé sur un indicateur mesuré (SLI)

D. Références

Recommandation CNIL relative aux mesures de journalisation
CNIL, délibération 2021-122 du 14 octobre 2021 (Légifrance)
DORA, règlement délégué (UE) 2024/1774, article 12 : journalisation (EUR-Lex)
Projet de loi Résilience, dossier législatif (Assemblée nationale)
Report de l’examen du projet de loi Résilience (Next, mis à jour le 6 octobre 2026)
La directive NIS 2 (ANSSI)
AI Act, règlement (UE) 2024/1689 (EUR-Lex) et article 12 : enregistrement (Commission européenne)
Omnibus numérique, règlement (UE) 2026/1744 (EUR-Lex)
OpenTelemetry : notes de version des conventions sémantiques
OpenTelemetry : conventions GenAI, statut Development
OpenTelemetry : spécification OpAMP