← Retour au blog

Construire une culture data

Lucian BLETAN

La culture data ne se décrète pas. Elle se construit dans les rituels comme les revues d’indicateurs, les tests et les partages d’apprentissages. Le but n’est pas de tout mesurer mais de mieux décider ensemble avec des définitions claires et des retours rapides.

prérequis

  • un sponsor côté direction et un sponsor opérationnel.
  • 5 KPIs d’entreprise définis publiquement.
  • un espace partagé simple type wiki interne ou repo git.

aperçu rapide

  • fixer un glossaire court des KPIs et le tenir à jour.
  • installer une revue régulière et courte des écarts.
  • lancer des tests modestes plutôt que des paris géants.
  • rendre visibles les décisions et qui en est l’owner.
  • former par la pratique sur des cas réels plutôt que des slides.
  • mesurer l’adoption via les consultations, les commentaires et les tests lancés.

mindmap des piliers

culture data

rituels

revue hebdo

post mortem

demo publique

metrics

glossaire unique

owner identifie

5 kpis max

tests

hypothese claire

mesure impact

apprentissage

acces

wiki ouvert

sql pour tous

transparence

tutoriel pas-à-pas

étape 1 publier le glossaire des KPIs

Définir pour chaque KPI la formule, la source, l’owner et la période.

KPI: taux de réachat
Formule: clients réacheteurs / clients totaux à 30 jours
Source: analytics.orders
Owner: ops
Périmètre: FR web uniquement

étape 2 instaurer une revue hebdo de 15 minutes

Gardez le même ordre du jour. Les décisions sont notées et les actions assignées.

cat > rituel.md <<'EOF'
- écarts notables (1 slide ou 1 tableau)
- hypothèses et causes possibles
- décisions et tests à lancer
- suivi des actions en cours
EOF

étape 3 créer une file de petits tests

Une hypothèse, une mesure, une date de fin, un owner. Pas de tests sans métrique.

-- couverture des tests par équipe (90 derniers jours)
SELECT equipe, COUNT(*) AS nb_tests
FROM tests
WHERE date_debut >= CURRENT_DATE - INTERVAL '90 day'
GROUP BY equipe
ORDER BY nb_tests DESC;

étape 4 écrire et partager les apprentissages

Format court, réutilisable et facile à chercher.

cat > learning.md <<'EOF'
contexte:
hypothèse:
résultat:
ce qu'on garde:
prochain pas:
EOF

étape 5 donner accès et sécuriser la compréhension

Accès en lecture pour tous, droits d’édition aux owners, et une page “comment lire nos chiffres”.

à lire avant d'utiliser les chiffres
- période, périmètre et unités sont toujours indiqués
- les méthodes changent parfois (voir CHANGELOG_KPI.md)
- en cas de doute, demander à l'owner indiqué sur la fiche

exemples

cas revue produit du mardi

- KPI principal: activation J7
- écart: -1,8 point semaine dernière
- hypothèse: friction sur l'étape profil
- test: simplifier formulaire (2 champs), cible 50% du trafic
- mesure: activation J7 vs contrôle
- owner: produit
- fin: J+14
-- vérification rapide de l'impact (exemple)
SELECT variant, ROUND(100*AVG(activated_j7),1) AS act_j7
FROM ab_activation
WHERE start_date >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY variant;

erreurs courantes et solutions

  • trop d’indicateurs crée de la confusion. Plafonnez à 5 KPIs d’entreprise et 2 KPIs d’équipe.
  • docs privées créent des silos. Le wiki doit être ouvert en lecture avec des liens depuis chaque dashboard.
  • débats sans fin sur des définitions floues. La fiche KPI avec formule validée fait foi.
  • effets d’annonce sans impact. Exigez des tests avec owner, date et mesure.
  • oubli des décisions crée de l’inertie. La trace écrite est obligatoire après chaque revue.

faq

  • Faut-il un outil dédié ? Pas forcément. Un simple repo git ou un wiki interne suffit pour démarrer proprement.
  • Qui maintient le glossaire ? Chaque owner de KPI. Il est relu par l’équipe data une fois par mois.
  • Que faire si un KPI change de calcul ? Il faut versionner, dater et expliquer le changement. Gardez l’ancien en parallèle une semaine si possible.

tags