Aller au contenu

Audit data — outil d’analyse

DRI : Romain · Audit initial produit le 6 août 2026 · Rejeu mensuel ou avant un arbitrage structurant.

En deux mots

Ce project transforme les intuitions sur le funnel, la qualité et le comité en métriques reproductibles. Il conserve les agrégats utiles au pilotage, sans publier de classement nominatif.

Problème

La squad dispose de nombreuses données, mais les définitions, dénominateurs et limites sont dispersés. Les décisions produit risquent donc de partir d’un ressenti ou d’une comparaison invalide.

Hypothèse

Si chaque pari Q3 part d’une baseline reproductible et d’une limite explicite, alors la squad réduira les débats d’opinion et saura invalider plus vite un chantier, parce que les mêmes requêtes pourront être rejouées.

Outcome / métrique de succès

  • Chaque project Q3 utilise au moins une baseline de METRICS.md.
  • Toute comparaison de qualité rappelle son périmètre et sa couverture.
  • Les principaux trous de mesure ont un owner et une décision associée.
  • [target et date de mesure à confirmer]

Métriques de succès

  • Nombre de projects Q3 avec baseline et limite explicites.
  • Nombre de décisions de priorité modifiées ou confirmées par une mesure.
  • Part des trous P0 avec owner et échéance.

Plus petit incrément

Rejouer les quatre requêtes agrégées, mettre à jour les baselines, puis vérifier si un arbitrage Q3 change. Aucun dashboard permanent n’est nécessaire.

Learning goal

Identifier quelles métriques changent réellement une décision de priorité, et lesquelles ajoutent du reporting sans effet.

Kill criteria

Arrêter la maintenance de cette documentation si les mêmes définitions et contrôles vivent dans une surface de pilotage fiable, avec un owner explicite.

Périmètre

  • funnel projet ;
  • provenance et corrections des données consolidées ;
  • qualité d’extraction et convergence ;
  • alignement scoring ↔ décisions comité ;
  • premiers outcomes post-financement, quand la jointure le permet.

Hors-scope

  • Classement ou évaluation nominative des AM ;
  • export de données brutes ;
  • dashboard permanent ;
  • écriture dans les bases ;
  • haut de funnel CRM non accessible depuis le connecteur actuel.

DRI

Romain porte les définitions, le rejeu et la restitution. Les owners techniques des trous de mesure restent à désigner.

Résultats utiles

  • Le funnel 2026 montre surtout une friction de passation et d’abandon, pas un simple problème d’inscription (METRICS.md).
  • La provenance des données consolidées reste majoritairement manuelle, ce qui donne une baseline au chantier de fiabilité (METRICS.md).
  • L’alignement brut entre scoring et comité reste insuffisant pour automatiser davantage sans échantillonnage des divergences (METRICS.md).
  • Les documents manquants n’ont pas encore un cycle de vie assez propre pour mesurer l’intervention humaine (GAPS.md).

Rejouer l’audit

Utiliser un compte en lecture seule. Le contexte de connexion vit dans queries/00_connection.md.

psql "$DATABASE_URL" -f queries/01_source_quality.sql
psql "$DATABASE_URL" -f queries/02_funnel.sql
psql "$DATABASE_URL" -f queries/04_quality_convergence.sql
psql "$DATABASE_URL" -f queries/05_decisions.sql

La requête nominative historique reste dans l’archive locale. Elle n’est pas nécessaire au pilotage partagé.

Vérification

  • Requêtes SELECT uniquement.
  • Cadre temporel explicite.
  • Volumes distincts quand une table contient un historique.
  • Médiane et moyenne pour tout délai publié.
  • Vérification manuelle d’un échantillon avant une décision de règle.

Risques identifiés

  • Dénominateurs qui changent entre deux requêtes.
  • Confusion entre stock, flux et first-touch.
  • Surinterprétation d’un petit échantillon.
  • Dérive vers un classement individuel au lieu d’une amélioration du process.

Sources