Construire un programme de data literacy

En 2018, Airbnb avait un problème que la plupart des CDO envieraient : trop d'enthousiasme pour la data. Les analystes étaient submergés de demandes ad hoc, les équipes métier construisaient des métriques contradictoires, et la même question, « combien avons-nous d'utilisateurs actifs ? », renvoyait quatre réponses différentes selon l'interlocuteur. Leur réponse, la « Data University », est aujourd'hui citée dans tous les decks sur la literacy qui circulent en conférence. Mais voici ce que ces decks omettent : Airbnb n'a pas commencé par enseigner le SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète →. Ils ont commencé par découvrir que leurs collaborateurs n'arrivaient pas à s'accorder sur les définitions, ne savaient pas interpréter le résultat d'une expérimentation, et ignoraient lequel des quatre chiffres d'« utilisateurs actifs » méritait leur confiance. **La formation a été la *dernière* chose qu'ils ont construite, pas la première.**

Cette inversion, c'est toute la leçon. La plupart des programmes de data literacy échouent parce qu'ils démarrent par le curriculum : une licence LinkedIn Learning, un lunch-and-learn sur les dashboards, un cours obligatoire que tout le monde clique et oublie avant jeudi. Vous savez déjà que la culture data est l'objectif. Cette leçon porte sur le mécanisme : comment construire un programme de literacy qui fait bouger un comportement précis pour un rôle précis, rattaché à une décision que quelqu'un prend réellement, et instrumenté pour que vous puissiez prouver que ça a marché.

Partez des décisions, pas des compétences

L'approche par les compétences est séduisante parce qu'elle est propre. Vous listez les compétences : lire un graphique, comprendre la significativité statistique, écrire une requête, vous attribuez des niveaux de mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtrise, et vous rattachez une formation à chacun. Cela produit une matrice magnifique et presque aucun changement de comportement, parce que cela répond à une question que personne dans le business ne se pose. Un VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → Ventes régional ne se lève pas le matin en voulant « améliorer sa maîtrise de la data ». Il se lève en voulant faire son chiffre.

Inversez. Commencez par un inventaire des décisions : les dix à quinze décisions récurrentes d'une fonction que la data devrait éclairer et qu'elle n'éclaire pas, ou mal. Puis remontez jusqu'au déficit de literacy qui bloque une meilleure décision.

Prenez une équipe merchandising qui réapprovisionne chaque semaine. La décision est concrète, à haute fréquence, et coûteuse si on se trompe. Quand vous les interrogez, vous découvrez que le vrai déficit n'est pas qu'ils ne savent pas lire un dashboard : c'est qu'ils ne font pas confiance au forecast de demande, donc ils le contournent au feeling et achètent les mêmes SKU que d'habitude. Le déficit de literacy ici n'est *pas* « comment utiliser Tableau ». C'est « comment interpréter l'intervalle de confiance d'un forecast et savoir quand s'y fier plutôt que le contourner ». C'est une compétence enseignable, ancrée dans une décision. Le cours Tableau l'aurait totalement manquée.

Voilà le recadrage central : la literacy n'est pas une connaissance dans la tête de quelqu'un ; c'est la capacité à prendre une meilleure décision au moment où la décision se prend. Votre unité d'analyse est la décision, pas la personne ni la compétence.

Construisez l'inventaire via des entretiens structurés avec les responsables de fonction. Posez trois questions par décision récurrente :

• Quelles données utilisez-vous *actuellement* pour cet arbitrage, et sur quoi vous appuyez-vous réellement à la place ?
• Où vous faites-vous mal : quelles décisions tournent mal et pourquoi ?
• Si vous disposiez d'un chiffre ou d'une vue en qui vous aviez confiance, lequel serait-ce ?

L'écart entre « les données que vous devriez utiliser » et « ce sur quoi vous vous appuyez à la place » constitue votre curriculum. Il n'est presque jamais générique. C'est « nos responsables finance ne savent pas que notre métrique de revenu exclut les remboursements » ou « nos marketeurs prennent un lift de 2 % pour un effet réel alors que le test n'avait pas la puissance pour le détecter ».

Segmentez par rôle, puis par rapport à la data

Une fois les décisions identifiées, résistez à l'envie de construire un programme unique. L'erreur de conception la plus fréquente après le « curriculum d'abord », c'est le « one-size-fits-all ». Un dirigeant qui valide une allocation de capital de 40 M$ et un analyste supply-chain qui règle un modèle de réapprovisionnement ont besoin d'une literacy radicalement différente, et les traiter de la même façon fait perdre du temps au dirigeant et rate la cible de l'analyste.

Segmentez l'organisation selon son rapport à la data, pas selon la séniorité. Un modèle à quatre niveaux utile :

Les Data Consumers lisent la data produite par d'autres et agissent dessus. La majorité de l'organisation se trouve là : le VP Ventes, le responsable marketing, le chef de magasin. Leur cible de literacy est l'*interprétation et le scepticisme* : lire correctement un graphique, savoir ce qu'une métrique exclut, repérer un axe trompeur, demander « comparé à quoi ? ». Ils n'ont pas besoin de SQL. Le leur enseigner est une vanity metric.

Les Data Explorers se servent eux-mêmes. Ils construisent leurs propres dashboards, découpent la data, appliquent leurs propres filtres. Leur déficit porte généralement sur la *méthodologie* : ils savent extraire la data mais en tirent de mauvaises conclusions. Corrélation contre causalité, taille d'échantillon, logique de cohortes, différence entre un taux et un volume brut.

Les Data Producers crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éent les actifs sur lesquels les autres s'appuient : analystes, data scientists, ingénieurs. Leur déficit de literacy est rarement technique ; il porte sur la *communication et la gouvernance*. Ils savent construire le modèle mais ne savent pas expliquer l'incertitude à un VP non technique, ou bien ils créent une cinquième métrique d'« utilisateurs actifs » parce qu'ils n'ont pas vérifié la semantic layersemantic layerUne couche de définitions métier partagée entre données brutes et rapports, pour que chacun calcule revenu, churn ou marge de la même manière.Voir la définition complète → d'abord.

Les Data Leaders allouent les ressources et fixent la direction à partir de la data. Leur cible est de *poser les bonnes questions et résister aux mauvaises réponses* : savoir quand la promesse de ROIROIReturn on Investment : le rapport entre le profit net et le coût d'un investissement. Un ROI de 300 % signifie que chaque dollar investi en rapporte 3.Voir la définition complète → d'un fournisseur est infalsifiable, quand une corrélation est vendue comme une causalité, quand exiger un test contrôlé avant d'engager du budget.

Rattachez chaque décision récurrente au niveau qui la porte. Votre curriculum a désormais un *quoi* (la décision) et un *qui* (le niveau), et vous pouvez concevoir une intervention proportionnée à chacun. Le dirigeant a droit à une session de travail de 90 minutes sur l'interprétation des résultats d'expérimentation, en prenant pour cas ses trois dernières initiatives ratées. L'analyste a droit à un atelier pratique sur la semantic layer et sur la façon de communiquer des intervalles de confiance. Même programme, doses délibérément différentes.

Concevez des interventions qui collent au workflow

Voici la vérité inconfortable sur la formation : la courbe de l'oubli est brutale. Un cours isolé perd l'essentiel de sa valeur retenue en quelques semaines, sauf si l'apprenant l'applique immédiatement. Le principe de conception le plus efficace est donc d'intégrer la literacy dans le workflow où la décision se prend, pas dans une salle de cours des semaines plus tôt.

Trois tactiques, par ordre croissant de durabilité :

1. L'accompagnement au point de décision. Mettez l'interprétation *dans* l'outil. Un dashboard qui affiche une métrique doit aussi afficher sa définition au survol, sa fraîcheur de données et une bande de confiance, pour que le consumer apprenne à la lire correctement chaque fois qu'il l'utilise, et pas une seule fois dans un cours. C'est là qu'une semantic layer justifie son coût : elle fait de la définition « correcte » la *seule* définition disponible.

# Semantic layer metric definition — the literacy lives in the config
metric: active_users
  label: "Active Users (28-day)"
  description: "Distinct users with >=1 qualifying session in trailing 28 days.
                EXCLUDES internal test accounts and bot traffic."
  owner: growth-analytics
  gotcha: "Not comparable to 'MAU' in the 2021 board deck (different window)."

Ce champ gotcha fait plus de travail de literacy qu'un deck n'en fera jamais, parce qu'il apparaît au moment précis où quelqu'un pourrait mal utiliser le chiffre.

2. Des cohortes ancrées dans une décision. Plutôt que des cours à inscription libre, animez des cohortes organisées autour d'une décision partagée et en cours. L'équipe merchandising apprend à interpréter un forecast *pendant qu'elle planifie les achats du trimestre suivant*, avec son vrai forecast. L'apprentissage a une conséquence immédiate, ce qui est le seul moyen fiable de le convertir en comportement durable. La cohorte crée aussi une redevabilité entre pairs : la norme se déplace parce que tout le monde se déplace ensemble.

3. Des data champions intégrés dans les fonctions. Airbnb, Bloomberg et d'autres ont convergé vers la même structure : un réseau distribué de « champions », non pas des analystes à temps plein, mais des opérationnels respectés dans chaque fonction qui reçoivent une formation plus poussée et deviennent la première ligne de support locale. Cela résout le problème de scalabilité (une équipe data centrale ne peut pas répondre à toutes les questions) et le problème de confiance (on accepte plus volontiers un conseil data d'un pair que d'une fonction centrale perçue comme bureaucratique). Budgétez leur temps explicitement ; un rôle de champion purement « en plus de votre poste » meurt en silence.

Un mot sur le jugement : le modèle des champions échoue quand vous choisissez les champions pour leur compétence technique plutôt que pour leur influence. Vous voulez la personne vers qui les autres vont déjà avec leurs questions, puis vous montez *son* niveau. Choisir l'expert SQL discret que personne ne sollicite est une erreur fréquente et évitable.

Mesurez le changement de comportement, pas la présence

Si vous reportez des taux de complétion à votre board, vous obtiendrez de la complétion. Vous n'obtiendrez pas de literacy. La couche de mesure est ce qui sépare un vrai programme du théâtre, et c'est la pièce que la plupart des CDO sautent parce qu'elle est réellement difficile.

Mesurez à trois niveaux, en étant honnête sur le fait que chacun devient plus difficile et plus précieux à mesure qu'on descend :

Métriques d'activité (facile, faible) : inscriptions, complétion, présence en atelier. Suivez-les pour l'hygiène opérationnelle uniquement. Ne les présentez jamais comme de l'impact. Elles vous disent que le programme tourne, pas qu'il fonctionne.

Métriques d'adoption (intermédiaire) : les gens utilisent-ils réellement la data différemment ? Volume de requêtes sur les sources gouvernées contre tableurs officieux. Nombre de décisions passant par la semantic layer. Réduction des définitions de métriques contradictoires. Usage des dashboards en self-service par des consumers qui ouvraient auparavant des tickets. Ce sont des proxys du comportement, et ils sont instrumentables : vous avez déjà les logs.

Métriques de résultat (difficile, fort) : les décisions se sont-elles améliorées ? Cela exige d'avoir défini les décisions en amont, et c'est pourquoi l'inventaire des décisions paye deux fois. Pour l'exemple du merchandising : le taux de contournement du forecast a-t-il baissé, et les ruptures ou les surstocks ont-ils diminué en conséquence ? Pour l'équipe marketing : la part de budget engagée *après* un test correctement calibré a-t-elle augmenté ? Pour les dirigeants : la part d'initiatives dotées d'une métrique de succès définie et d'un critère d'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt a-t-elle progressé ?

Concevez un petit nombre de ces mesures de résultat sous forme de comparaisons avant/après ou traité/non traité. Lancez le programme de cohortes dans deux régions sur cinq d'abord, gardez-en trois en contrôle, et comparez la qualité des décisions. Ce n'est pas de la rigueur pour la rigueur : c'est votre défense quand la finance demandera pourquoi le programme de literacy mérite le budget de l'an prochain. « Les régions passées par la cohorte merchandising ont réduit les dépréciations de surstock de 11 % par rapport au contrôle » est une phrase qui renouvelle des budgets. « Nous avons formé 4 000 personnes » ne l'est pas.

Une mise en garde sur la mesure : l'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → est contestée. Les résultats business ont de multiples causes, et un CFO avisé dira que votre programme de literacy ne peut pas revendiquer la totalité des 11 %. Il a raison. Présentez cela comme une contribution, préenregistrez votre comparaison avant de commencer, et choisissez des décisions dont la chaîne causale est assez courte pour être défendue. Ne surpromettez pas ; un chiffre modeste et crédible vaut mieux qu'un chiffre gonflé qu'il faudra retirer.

Points clés

• Construisez l'inventaire des décisions avant le curriculum. Interrogez les responsables de fonction pour identifier les dix à quinze décisions récurrentes où l'écart entre « les données qu'ils devraient utiliser » et « ce sur quoi ils s'appuient à la place » révèle le besoin réel et précis de literacy. Le curriculum découle des écarts, pas d'un framework de compétences.

• Segmentez par rapport à la data, pas par séniorité. Les Consumers ont besoin d'interprétation et de scepticisme ; les Explorers de méthodologie ; les Producers de communication et de gouvernance ; les Leaders de savoir poser les questions difficiles. Enseigner le SQL aux consumers est une vanity metric : concevez des doses proportionnées.

• Intégrez la literacy dans le workflow, pas dans la salle de cours. L'accompagnement au point de décision (définitions et gotchas dans la semantic layer), les cohortes ancrées dans une décision en cours et des champions choisis parmi les opérationnels influents battent n'importe quel cours isolé, parce qu'ils déjouent la courbe de l'oubli.

• Reportez l'adoption et les résultats, jamais la complétion. Instrumentez le volume de requêtes gouvernées et le nombre de définitions contradictoires (adoption), et montez des comparaisons avant/après ou traité/contrôle sur les décisions que vous avez inventoriées (résultats). Préenregistrez la comparaison et revendiquez une contribution, pas le mérite de l'ensemble.

• Choisissez les champions pour leur influence, puis formez-les, pas l'inverse. La personne à qui votre équipe apporte déjà ses questions vaut dix experts silencieux. Financez son temps explicitement, sinon le rôle meurt en silence.