← Retour au blog

Data literacy: former par la pratique

Lucian BLETAN

Lire un dashboard et prendre une bonne décision sont deux choses différentes. La data literacy progresse quand on manipule des cas réels, que l’on écrit des définitions simples et qu’on obtient un feedback rapide. Fini les slides interminables. Place aux workshops courts basés sur un problème métier, un dataset propre et une mesure d’impact.

prérequis

  • un sponsor qui garantit 2 heures par équipe, chaque sprint.
  • un repository d’exemples propres (anonymisés) avec un glossaire.
  • un espace commun pour stocker exercices, solutions et feedbacks.

aperçu rapide

  • cibler des compétences observables (poser une question, écrire une query, expliquer un KPI).
  • utiliser des datasets internes connus plutôt que des données génériques.
  • travailler en binôme métier + data, 45 à 60 minutes par atelier.
  • finir chaque session par un mini livrable utile (query, note, chart annoté).
  • mesurer l’effet : temps de réponse, qualité des décisions, autonomie.
  • rejouer régulièrement les bases, complexifier ensuite.

mindmap de la pédagogie

data literacy

practice

real cases

pair programming

hands on

tools

sql basics

glossary

visualization

mindset

critical thinking

hypothesis first

impact driven

feedback

code review

peer learning

iteration

tutoriel pas-à-pas

étape 1 choisir un cas qui compte

Un irritant réel vaut dix exercices académiques. Le scope doit tenir en une phrase.

objectif: expliquer la baisse du taux d'activation à J7
scope: FR, web, 60 derniers jours
kpi: activation_j7 = utilisateurs actifs à J7 / nouveaux inscrits

étape 2 préparer un dataset minimal

Moins de colonnes, plus de clarté. Ajoutez un README et des exemples d’usage.

# structure d'un dossier d'atelier
mkdir -p workshops/activation_j7 && cd $_
printf "user_id,signup_date,active_j7,channel,device\n" > data.csv
echo "README.md" > .keep

étape 3 écrire la définition du KPI en clair

Texte, formule, owner, source. Cette fiche sert de “single source of truth”.

kpi: activation_j7
definition: utilisateurs actifs au moins 1 fois entre j1 et j7 / nouveaux inscrits
source: analytics.events
owner: product
notes: exclure les comptes test et internes

étape 4 répondre à la question avec une query simple

Une query qui tient sur un écran vaut mieux qu’un modèle complexe. Visualisez le flux de données.

Filter Date

Filter Active

Left Join

User ID

Group By

Calc

Raw Events

Signups

Active Users

Join

Channel Stats

Activation Rate

-- activation par channel (60 derniers jours)
WITH s AS (
  SELECT user_id, MIN(ts)::date AS signup_date, channel
  FROM events
  WHERE event = 'signup' AND ts >= CURRENT_DATE - INTERVAL '60 day'
  GROUP BY user_id, channel
),
a AS (
  SELECT user_id, 1 AS active_j7
  FROM events
  WHERE event = 'active'
    AND ts::date BETWEEN CURRENT_DATE - INTERVAL '60 day' AND CURRENT_DATE
  GROUP BY user_id
)
SELECT
  s.channel,
  COUNT(*) AS inscrits,
  SUM(COALESCE(a.active_j7,0)) AS actifs_j7,
  ROUND(100.0*SUM(COALESCE(a.active_j7,0))/NULLIF(COUNT(*),0),1) AS activation_j7_pct
FROM s
LEFT JOIN a ON a.user_id = s.user_id
GROUP BY s.channel
ORDER BY activation_j7_pct DESC;

étape 5 raconter le résultat en deux phrases

Un titre actionnable et 2 annotations. Pas plus.

titre: "activation J7 plus faible sur mobile web"
notes:
- "écart de 3,2 pts vs moyenne"
- "chute marquée depuis la release du nouveau formulaire le 12"

étape 6 décider d’un test et d’une mesure d’impact

Qui fait quoi, quand, comment on mesure. Finir par un rappel.

action: simplifier le formulaire mobile (2 champs) sur 50% du trafic
mesure: +1,0 pt d'activation J7 en 14 jours
owner: product
review: mardi prochain 9:30

exemples

cas atelier “retour produit”

Le but est de comprendre la logique d’analyse via un flow simple.

Data TeamMétierData TeamMétierloop[Workshop]Problème: Retours trop élevésDataset clean (orders + returns)Draft Query (taux par categorie)Code Review & OptimisationInsight (Category Shoes > 20%)Action (Update Size Guide)
-- taux de retour 14j par category
SELECT 
    category,
    ROUND(100.0*SUM(CASE WHEN returned_within_14d THEN 1 ELSE 0 END)/NULLIF(COUNT(*),0),1) AS retour_14j_pct
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '90 day'
GROUP BY category
ORDER BY retour_14j_pct DESC;

erreurs courantes et solutions

  • cours magistraux créent l’oubli rapide. Privilégiez des workshops courts sur des cas réels avec livrables.
  • datasets jouets génèrent peu d’adhésion. Utilisez des données internes anonymisées avec du contexte business.
  • objectifs flous mènent à la dérive. Visez une compétence observable par séance (ex: écrire 1 query correcte).
  • jargon cause le décrochage. Le glossaire doit être à portée de main avec des définitions one-line.
  • pas de mesure rend l’impact inconnu. Faites un avant/après sur un KPI précis.
  • solutions cachées créent de la frustration. Publiez les corrections et les best practices après l’atelier.

faq

  • Faut-il un programme long et coûteux ? Non. Un cycle de 4 workshops de 60 minutes suffit pour voir des progrès tangibles.
  • Comment évaluer la progression ? Utilisez une grille simple : autonomie sur les queries, clarté des titres, justesse des annotations.
  • Et si le niveau est très hétérogène ? Faites des binômes mixtes, des exercices à deux vitesses (basic/advanced) et rendez les corrections disponibles en asynchrone.