Gouverner la télémétrie

Mode de lecture

IngénieurDécideur

Sans gouvernance, la télémétrie suit une pente naturelle : chaque équipe ajoute des métriques, des attributs et des logs, personne n’en retire et la rétention reste celle par défaut. Le résultat se voit d’abord sur la facture, ensuite dans les requêtes qui ralentissent, parfois dans un audit qui découvre des données personnelles dans des logs conservés trop longtemps.

Gouverner la télémétrie, c’est décider à l’avance ce qui peut être collecté, en quelle quantité, pour combien de temps et vers où, puis vérifier automatiquement que ces décisions sont respectées. Quatre outils suffisent : le contrat de données, le budget de cardinalité, la politique de rétention et une revue trimestrielle.

Le contrat de données

Le glossaire le définit comme une règle écrite, vérifiée en intégration continue, qui fixe pour un signal les attributs autorisés, le budget de cardinalité, la rétention et la destination. Je recommande d’y ajouter deux champs : un propriétaire et la présence éventuelle de données personnelles.

Voici à quoi peut ressembler un contrat pour une métrique. Le format est un exemple illustratif, à adapter à votre outillage ; il ne correspond pas au schéma d’un outil précis.

signal: http.server.request.duration
type: histogramme
proprietaire: equipe-paiement
usage: [slo-paiement, tableau-de-bord-paiement]
attributs_autorises:
  - service.name
  - http.request.method
  - http.response.status_code
  - http.route              # route normalisée, jamais le chemin brut
attributs_interdits:
  - user.id                 # non borné : à porter par les traces
  - url.full
budget_cardinalite: 5000    # séries actives maximum pour ce signal
donnees_personnelles: non
retention: classe-exploitation
destination: stockage-metriques-chaud

Trois choix de ce contrat méritent d’être expliqués.

Le champ usage. Chaque signal doit servir à quelque chose : un SLO, une alerte, un tableau de bord, une décision. Un signal sans usage déclaré est le premier candidat à la suppression lors de la revue. C’est la règle de sobriété proposée dans la leçon 3 du parcours DSI.

Les noms d’attributs. Les conventions sémantiques OpenTelemetry fournissent des noms et des significations standardisés. Je recommande de les utiliser plutôt que d’inventer un vocabulaire maison : les contrats restent lisibles d’une équipe à l’autre et d’un outil à l’autre.

Les attributs interdits. La documentation Prometheus déconseille explicitement de porter par des labels des dimensions à forte cardinalité comme des identifiants d’utilisateur ou des adresses électroniques. Écrire ces interdits dans le contrat les rend vérifiables.

Vérifier en intégration continue

Un contrat qui n’est vérifié qu’en revue humaine finit par être ignoré. Je recommande trois vérifications automatiques, du plus simple au plus complet :

Vérification	Ce qu’elle bloque	Outils possibles
Nommage et format	noms non conformes, unités absentes	promtool check metrics pour les métriques au format Prometheus
Conformité aux conventions	attributs inconnus ou mal typés	OTel Weaver, qui valide un registre de conventions sémantiques
Contrat	attributs interdits, signal sans propriétaire ni usage	un test maison qui compare l’instrumentation déclarée aux contrats

La troisième vérification est à mon avis la plus utile ; c’est aussi celle qu’un outil générique ne peut pas fournir telle quelle, puisqu’elle dépend de vos contrats. Elle peut commencer petit : un script qui refuse une fusion lorsqu’un nouveau signal n’a pas de contrat.

Le budget de cardinalité

La cardinalité est le nombre de séries temporelles distinctes produites par une métrique. Elle croît de façon multiplicative avec les labels, ce que le simulateur d’explosion de cardinalité rend visible.

Un budget de cardinalité fixe un plafond de séries actives par signal, par service ou par équipe. Je recommande de le poser à deux niveaux :

• par signal, dans le contrat, pour arrêter en revue l’attribut qui ferait exploser une métrique ;
• par équipe, comme enveloppe globale, pour que l’équipe arbitre elle-même entre ses signaux.

Le budget doit aussi être appliqué à l’exécution, parce qu’une erreur passe toujours la revue un jour. Côté Prometheus, les paramètres de collecte sample_limit et label_limit font échouer la collecte d’une cible qui dépasse un plafond (configuration Prometheus). Dans un OpenTelemetry Collector, les processeurs de filtrage et de transformation suppriment ou recodent les attributs interdits avant l’export. Le simulateur du coût au Collector chiffre l’effet de ces leviers.

Le circuit de dérogation. Un budget sans dérogation possible est contourné. Je recommande un circuit court et écrit : l’équipe demande, justifie l’usage, propose une durée ; l’équipe plateforme estime l’impact ; la décision est tracée dans le contrat avec une date de fin. Une dérogation sans date de fin devient la règle.

La rétention

Toutes les données n’ont pas la même durée de vie utile. Je recommande de définir un petit nombre de classes de rétention et de rattacher chaque signal à une classe dans son contrat.

Classe	Exemples de signaux	Durée	Stockage
Diagnostic	traces nominales échantillonnées, logs de debug autorisés	quelques jours	chaud
Exploitation	métriques d’exploitation, logs applicatifs, traces en erreur	quelques semaines	chaud puis tiède
Tendance	métriques agrégées (par service, à résolution réduite)	plusieurs mois à quelques années	froid ou compressé
Preuve	journaux d’audit, traces à valeur probante	fixée par la politique de conservation et les textes applicables	froid, immuable si nécessaire

Les durées de ce tableau sont des ordres de grandeur illustratifs. Les durées de la classe Preuve ne se choisissent pas en fonction du coût : elles viennent de la politique de conservation de l’entreprise et des textes sectoriels, comme l’explique la leçon 2 du parcours DSI. Pour l’intégrité de ces journaux, voir l’intégrité des journaux d’audit.

Les données personnelles. Le RGPD pose les principes de minimisation des données et de limitation de la conservation (règlement (UE) 2016/679, article 5). Appliqués à la télémétrie, ils signifient qu’un identifiant d’utilisateur, une adresse IP ou un contenu de requête ne devraient être collectés que s’ils servent un usage déclaré et ne devraient pas être conservés plus longtemps que cet usage ne l’exige. Le champ donnees_personnelles du contrat rend ce choix explicite et vérifiable par le DPO.

La revue trimestrielle

Les contrats et les budgets vieillissent. Je recommande une revue trimestrielle d’une heure, réunissant l’équipe plateforme, les référents des équipes produit, un représentant FinOps et, une fois par an au moins, la sécurité et le DPO.

Ordre du jour type.

1. Évolution du volume et de la cardinalité par équipe depuis la revue précédente.
2. Les dix signaux les plus coûteux et leur usage déclaré.
3. Les signaux sans usage constaté sur le trimestre : supprimer ou justifier.
4. Les dérogations arrivées à échéance : clore ou renouveler avec une nouvelle date.
5. Les incidents où un signal a manqué : ajouter, avec un contrat.
6. Les écarts de rétention et de données personnelles relevés.
7. Les décisions, avec un porteur et une date.

Le point 5 compte autant que les autres. La gouvernance ne sert pas seulement à réduire : un post-mortem qui conclut à un trou d’observabilité doit pouvoir ajouter un signal rapidement. Voir le post-mortem sans blâme.

Ce qu’on mesure

Indicateur	Ce qu’il révèle
Part des signaux couverts par un contrat	l’étendue réelle de la gouvernance
Part des signaux avec un usage déclaré et constaté	la sobriété de la collecte
Séries actives par équipe, rapportées à leur budget	la tenue des budgets de cardinalité
Nombre de fusions bloquées par les vérifications de contrat	si les règles sont appliquées ou contournées
Dérogations ouvertes et dérogations échues	la discipline du circuit de dérogation
Signaux contenant des données personnelles hors contrat	le risque de conformité
Coût par équipe et coût par transaction métier	le lien avec le pilotage FinOps de la leçon 4

Liste de contrôle

• Un format de contrat de données est choisi et documenté
• Chaque nouveau signal arrive avec un contrat, un propriétaire et un usage
• Les noms d’attributs suivent les conventions sémantiques OpenTelemetry
• L’intégration continue bloque un signal sans contrat
• Un budget de cardinalité existe par équipe et il est appliqué à l’exécution
• Le circuit de dérogation est écrit et chaque dérogation a une date de fin
• Chaque signal est rattaché à une classe de rétention
• La présence de données personnelles est déclarée et revue avec le DPO
• La revue trimestrielle a lieu et produit des décisions tracées

Pour aller plus loin

• Qui possède les contrats et qui arbitre les dépassements dépend du modèle d’équipe.
• Le simulateur d’explosion de cardinalité montre pourquoi un seul attribut non borné change l’ordre de grandeur de la facture.
• Le schéma du pipeline de collecte montre où les règles s’appliquent.

Sources

• OpenTelemetry, Semantic Conventions et OTel Weaver.
• Prometheus, Metric and label naming et Configuration (sample_limit, label_limit).
• Règlement (UE) 2016/679 (RGPD), article 5.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Un budget de cardinalité par équipe transforme une facture qui dérive en une enveloppe pilotée. La revue trimestrielle est le moment où les arbitrages de coût se font avec des chiffres, voir le simulateur du coût au Collector.

OrganisationQui décide, qui possède

Le contrat de données donne une réponse écrite à « qui a le droit d'ajouter quoi » et un circuit de dérogation, au lieu d'une négociation au cas par cas.

HumainÉquipes, astreinte, compétences

Des règles vérifiées automatiquement en intégration continue évitent à l'équipe plateforme le rôle de police et aux développeurs les refus arbitraires.

MétiersProduit, finance, risque, relation client

Pour la conformité et le DPO : la rétention et la présence de données personnelles sont déclarées par signal, ce qui rend la minimisation démontrable.

Pourquoi des passerelles →