Un dashboard n'est pas une décision
Mon premier vrai dashboard en alternance était magnifique. Le souci : presque personne ne l'ouvrait. Retour honnête sur une leçon que l'école ne m'avait pas apprise.
Une partie de ce que je publie ici vient directement de ces projets.
Quand j'ai commencé mon alternance comme Data Analyst, j'étais franchement fier de mon premier dashboard Power BI. Visuels propres, filtres qui répondent, rafraîchissement automatique : sur le papier, du beau travail. Sauf qu'au bout de quelques semaines, j'ai remarqué un truc gênant. Presque personne ne l'ouvrait.
C'est là que j'ai compris une leçon qu'aucun cours ne m'avait vraiment transmise : un dashboard n'est pas une décision. On peut livrer un rapport impeccable et rater l'essentiel, parce que personne ne s'en sert pour décider quoi que ce soit.
Mon erreur de débutant : soigner l'outil, oublier l'usage
Au début, je jugeais la qualité de mon travail à la propreté du rapport. Plus c'était complet et bien rangé, plus je pensais avoir bien bossé. Erreur classique de junior : j'optimisais l'outil, pendant que le métier, lui, continuait de piloter à l'intuition ou dans son bon vieux fichier Excel à côté.
Le déclic, ça a été d'arrêter de me demander « est-ce que mon dashboard est beau ? » pour me demander « est-ce que quelqu'un fait quelque chose de différent grâce à lui ? ». Pas la même question, pas du tout le même travail.
La question d'abord, le graphique après
Depuis, avant même d'ouvrir Power BI, je me pose trois questions :
- Qui va ouvrir ce rapport, et à quelle fréquence ?
- Quelle décision ce chiffre est censé éclairer ?
- Que se passe-t-il si le KPI passe au rouge ?
Si je n'arrive pas à répondre à la troisième, c'est mauvais signe : ce n'est pas un indicateur, c'est une jauge décorative. Chez La Poste, sur la traçabilité, un volume d'équipements ou un taux d'incidents ne m'intéresse que s'il déclenche une action concrète : un contrôle, un réajustement de flux, un échange avec le terrain.
Moins de pages, plus de signaux
Autre réflexe de débutant que j'ai dû désapprendre : croire qu'un gros rapport = un bon rapport. Un dashboard de 12 pages, ça rassure celui qui l'a commandé. Ça n'aide pas l'opérateur qui a trente secondes entre deux tâches.
Aujourd'hui je vise l'inverse :
- peu de KPI, chacun rattaché à un propriétaire métier
- un seuil clair, pas seulement une tendance
- un commentaire : l'anomalie, la cause probable, la prochaine étape
Power BI est génial pour ça, à condition de résister à l'envie d'ajouter « encore une vue, au cas où ». Spoiler : le « au cas où » n'arrive jamais.
La donnée ne remplace pas le terrain
Ce que je pensais le moins important au début, et qui s'est révélé le plus décisif : la qualité de la donnée source. Un modèle SQL propre et un flow Dataiku bien ficelé ne valent rien si les données d'entrée sont mal saisies. Une bonne partie du boulot, invisible, consiste à remonter la qualité : définitions partagées, règles de calcul, exceptions documentées.
C'est beaucoup moins vendeur que le machine learning sur un CV. Mais c'est exactement ce qui fait qu'un dashboard survit après la démo.
Si je devais le dire à un autre junior
Un exercice tout simple qui m'a beaucoup aidé : prends ton rapport le plus consulté et barre tout ce qui n'a jamais déclenché une décision. Ce qui reste, c'est ton vrai produit.
Et surtout : n'aie pas peur de poser des questions « bêtes » au métier. Au début j'avais peur de passer pour celui qui ne comprend rien. En vrai, c'est dans ces échanges que se joue 80 % du travail d'un Data Analyst.
