Méta-analyse et métriques métriques

1) Qu'est-ce qu'une méta-analyse

La méta-analyse est le contrôle de la mesure elle-même : les formules, les sources, la fraîcheur, la stabilité et le coût d'obtention des métriques. L'objectif est que chaque métrique soit une unité de connaissance vérifiable : reproductible, opportune, comparable entre les équipes et économique.

2) Modèle de métrique du squelette

• ID : 'metric _ key', propriétaire (Product/Data Owner), criticité (Gold/Silver/Bronze).
• Sens : définition, unités, agrégation, fenêtres (day/wow/bou/rolling).
• Formule et calque : SQL/DSL, calque sémantique (dimensions, filters), segments valides.
• Sources et linéage : tableaux, versions, dépendances (fiches/vitrines/modèles).
• SLO метрики: latency p95, freshness, coverage, accuracy, stability.
• Trust Signals : dernières vérifications, statut DQ, tests CI de formule.
• Économie : bytes scanned, cost-per-chart (CPC), cost-per-insight (CPI).
• Contrôle d'accès : RLS/CLS, sensibilité.
• Versioning : semver de formule ('ggr @ 2. 3. 0 '), journal des modifications.

3) « Métriques métriques » : ce qu'il faut mesurer

Qualité et confiance

Accuracy : divergence avec la référence/comptabilité (MAE/APE).
Consistency : correspondance entre sources/dashboards (formule canonique).
Freshness : âge des données vs SLO (sec/min).
Completeness : proportion de segments/dates remplis.
Stabilité : variance/volatilité sous conditions invariables (Levene/variance ratio).
Explainability : présence de formule/références/CI/gammes dans la carte.

Performance et coût

Latitude p95/p99 calcul/rendu.
Bytes scanné/demande.
CPC/CPI : coût du graphique/initiation.
Cache hit-rate et matérialisation.

Risque et utilisation

Adoption : proportion de dashboards/solutions utilisant la métrique.
Taux de rupture : taux de chute des tests/crash de fraîcheur.
Drift score : décalage des distributions après les changements de formule/source.
Charge de support : appels/incidents par métrique.

4) Couche sémantique et « Metric Store »

Grammaire unique : mesures, mesures, filtres, règles d'agrégation et de compatibilité.
API/Annuaire de métriques : recherche, cartes, versioning, lineage-graphe.
Calculs intermédiaires : matérialisations (daily/weekly), voyous canoniques.
Politique de publication : seulement de Metric Store à prod-dashboards/AI-visualisation.

5) Versioning et compatibilité

BouVer pour les métriques : 'MAJOR' est un changement de sens/agrégation cassant ; 'MINOR' est une nouvelle coupe/attribut ; 'PATCH' est une optimisation sans modifier la valeur.
Deprecation flow : avertissement, mode parallèle v1/v2, date d'arrêt, hyde de migration.
Tests contractuels : equality/inéquality, invariants (somme des sous-segments = entier).

6) Linéage et vérification des métriques

Upstream : sources, règles DQ, versions.
Bou : SQL/DBT/Nod DAG, vérification de la compatibilité des schémas.
Downstream : dashboards/modèles/rapports qui consomment la métrique.
Vérification : qui a changé la formule et quand, quel incident ou quel communiqué a influencé.

7) Observabilité des métriques (Observabilité métrique)

Profils temporels : saisonnalité, effets de calendrier, promos.
Anomalies : STL/ESD/BOCPD ; alertes avec sensibilité par criticité.
Check-gates : avant la sortie - comparaison de l'ancienne/nouvelle formule sur la coupe « or ».
Drift-monitoring : PSI/JS par segment ; les marqueurs de changement de source.

8) L'économie des métriques et des FinOps

Quotas/limites : max bytes scanné, délai d'exécution, off-peak rebuild.
Chargeback : les équipes paient « virtuellement » pour des rapports lourds.
Cache/matérialisation : profils de mystère et TTL.
Optimisation : formats de colonne, ZSTD, tri/clustering, pré-agrégats.

9) Gestion des changements (Change Mgmt)

Métriques RFC : objectif, risque, décalage prévu, plan de retrait.
A/B de formule : Calcul parallèle et comparaison des métriques v1 vs v2.
Communication : changelog dans la carte, bannière sur les dashboards liés.
Retour en arrière : commutateur rapide pour la matérialisation précédente.

10) Rôles

Metric Owner : sens, formule, sorties, communications.
Data Engineer : fiabilité de pipline, performances.
Analyste/Scientifique : Validation et interprétation causale.
FinOps : coût et quotas.
Conformité/Confidentialité : accès, masquage, reporting.

11) Anti-modèles

SELECT dans la formule métrique.
Deux formules « officielles » d'une seule métrique.
Modifications manuelles dans le dashboard au lieu de changer dans le Metric Store.
Sans spécifier de fenêtre/base de comparaison.
Linéaire zéro et absence de propriétaire.
Les filtres cachés (différents pays/devises) → des chiffres non comparables.

12) Feuille de route pour la mise en œuvre

1. Inventory : liste des 50 meilleures métriques, propriétaires, criticité, formules actuelles.
2. Metric Store MVP : cartes, BouVer, API, lineage, tests CI.
3. Observabilité : freshness/latency/bytes scanned/anomalies, panneaux SLO.
4. FinOps : limites, cache, matérialisation, rapports de valeur.
5. Howernance : RFC/dégradation/reculs, politique de déperdition.
6. Échelle : « métriques » automatiques, intégration avec la visualisation AI/contexte.

13) Chèque métrique (avant publication)

• La carte métrique est remplie (définition, unités, segments, fenêtre).
• La formule est versionisée ; les tests de cohérence/invariants sont verts.
• Freshness/Latency SLO sont définis et surveillés.
• Sources DQ vertes ; lineage est transparent.
• Valeur de la demande dans les limites ; cache/matérialisation configurée.
• Les politiques d'accès (RLS/CLS) et le masquage ont été appliqués.
• Communication sur le changement préparée ; il y a un plan de repli.

14) Mini-modèles

14. 1 Carte métrique (YAML)

yaml metric:
key: ggr version: 2. 3. 0 owner: "product-data@company"
definition: "Bet amount minus win amount"
unit: "currency"
aggregation: "sum"
window: ["day","wow","mom"]
dims_allowed: ["country","device_os","provider","game"]
lineage:
sources: ["fact_bets","fact_payouts"]
transforms: ["ggr_daily. sql"]
slo:
freshness_s: 600 latency_p95_ms: 1500 accuracy_mae_pct: <=0. 5 finops:
max_bytes_scanned_mb: 2048 cache_ttl_min: 60 access:
sensitivity: "internal"
rls: ["tenant","region"]

14. 2 tests de formule (style dbt)

sql
-- invariant: GGR = bets - wins select count () as violations from (
select bets - payouts as ggr_calc, ggr from mart_daily
) t where abs(ggr_calc - ggr) > 1e-6;

14. 3 Politique d'alertes métriques

yaml alerts:
- name: ggr_freshness when: freshness_s > 600 severity: high action: [page:oncall-data, degrade:use_last_materialization]
- name: ggr_stability when: variance_ratio_week > 2. 5 severity: medium action: [open:investigation, add:banner_on_dashboards]

14. 4 Comparaison des versions de la formule

sql select dt, country,
ggr_v1, ggr_v2,
(ggr_v2 - ggr_v1) as delta,
100(ggr_v2 - ggr_v1)/nullif(ggr_v1,0) as delta_pct from compare_ggr_v1_v2 order by dt desc, abs(delta_pct) desc limit 100;

14. 5 Rapport « métrique métrique » pour le dashboard

yaml meta_dashboard:
tiles:
- metric: freshness_s target: <=600
- metric: latency_p95_ms target: <=1500
- metric: bytes_scanned_mb target: <=2048
- metric: anomaly_rate_7d target: <=0. 5%
- metric: adoption_rate target: >=80%

15) Résultat

Les méta-analyses font des métriques des objets d'ingénierie fiables : ils ont des propriétaires, des versions, des SLO, des tests et des coûts. Lorsque les cartes métriques, la couche sémantique, l'observabilité et les FinOps travaillent ensemble, l'organisation obtient des chiffres comparables, vérifiables et économiques, plutôt que des « vérités différentes ». C'est la base d'une analyse rapide, de bonnes décisions et d'une croissance évolutive.