Ce que j’arrêterais immédiatement si je recommençais en data
#22 Ou des leçons que j’ai apprises à la dure
Bonjour à tous,
Bienvenue à la 22e édition de cette newsletter. Nous venons de dépasser la barre de 2000 abonnés !
Vous êtes de plus en plus nombreux à lire cette newsletter, et franchement, soit vous aimez me lire, soit vous aimez la data. Dans tous les cas, bienvenue !
Si vous ne le saviez pas encore, j’ai créé une cheat sheet SQL gratuite (téléchargée par +1K personnes) qui recense 90 % des commandes essentielles pour travailler dans la Data, chacune illustrée par un exemple concret. Vous pouvez pratiquer directement dans le même notebook ! Pour la recevoir, c’est par ici !
La semaine dernière, j’ai eu une conversation avec une amie qui m’a rappelé à quel point certaines erreurs peuvent ralentir une carrière…
Donc pour cette édition, je fais un peu d’introspection et reviens sur mon parcours en Data.
Quand j’ai débuté, j’ai commis de nombreuses erreurs. Pas juste des petites erreurs anodines, mais des erreurs coûteuses qui ont ralenti ma progression et limité mon impact.
Avec le recul, j’aurais aimé qu’on me donne une feuille de route pour éviter ces pièges classiques. Si vous débutez en Data – ou même si vous avez déjà un peu d’expérience mais que vous sentez que quelque chose coince – cette édition est pour vous !
Voici cinq leçons que j’ai apprises à la dure et que j’aurais aimé connaître dès le premier jour.
Maîtrisez-les, et vous accélérerez votre carrière en évitant des pertes de temps inutiles.
1. Dire OUI à toutes les demandes
Au début, je pensais que mon rôle consistait à répondre à toutes les requêtes de données qui arrivaient dans ma boîte mail.
J’étais devenu un distributeur automatique de rapports et d’analyses, sans réel impact stratégique.
Le problème de dire oui à tout, c’est qu’on n’a plus le temps de se concentrer sur les analyses à forte valeur ajoutée. On passe ses journées à générer des rapports aléatoires utilisés une seule fois, à ajouter un filtre par-ci, une colonne par-là… sans jamais faire de vrai travail d’analyse. Et on a toujours l’impression d’être débordé.
Ce que je ferais différemment :
Apprendre à dire non (ou au moins pas tout de suite) et prioriser les tâches qui ont un réel impact business.
D’ailleurs, j’ai remarqué un truc : plus je repousse une demande, plus les gens trouvent des solutions par eux-mêmes. Comme quoi.
2. Surcomplexifier les dashboards
Je pensais qu’un bon dashboard devait offrir une vue exhaustive : j’y mettais des dizaines de graphiques, des filtres personnalisés et une multitude d’indicateurs.
Mais en réalité ? La plupart des parties prenantes ne les utilisaient même pas. Pire, cela les embrouillait plus qu’autre chose.
👉 Un bon dashboard n’est pas celui qui impressionne, mais celui qui est réellement utilisé.
Ce que je ferais différemment :
Faire simple. Me concentrer sur les questions clés du business. Si votre dashboard a besoin d’un mode d’emploi, il est trop compliqué.
Je limiterais les indicateurs à 2 ou 3 métriques essentielles que mes interlocuteurs peuvent facilement retenir et utiliser.
3. Apprendre des compétences “cool” mais inutiles
C’est tentant d’apprendre les dernières technologies à la mode – surtout quand on voit des offres d’emploi mentionner une vingtaine d’outils.
J’ai perdu des mois à apprendre des outils que je n’ai jamais utilisés en entreprise (coucou Machine Learning et Deep Learning 👋).
J’étais super fier de mes certifications Coursera… jusqu’à ce que je réalise que 90% des boîtes avaient surtout besoin de SQL, Python et data viz.
Ce que je ferais différemment :
Maîtriser les bases avant de me lancer dans des technologies avancées. Plutôt que de me disperser, j’appliquerais ces fondamentaux à des projets concrets pour pratiquer et prouver ma valeur aux entreprises.
À moins que votre travail n’exige un outil spécifique, concentrez-vous sur ce qui sert vraiment en entreprise.
4. Attendre des données “parfaites”
J’avais cette (mauvaise) habitude : repousser mes analyses en attendant d’avoir des données propres, complètes et bien structurées.
Je retardais mes livrables pour deux raisons : je passais trop de temps à nettoyer les données et je manquais de confiance pour rendre une analyse basée sur des données imparfaites.
Le problème, c’est que des données parfaites, ça n’existe pas.
Les données du monde réel sont toujours incomplètes. Si vous attendez qu’elles soient parfaites, vous ne livrerez jamais rien.
Ce que je ferais différemment :
Apprendre à travailler avec des données imparfaites. Faire des hypothèses raisonnables, communiquer sur les incertitudes et ajuster les analyses à mesure que de nouvelles données deviennent disponibles.
En entreprise, l’action est toujours préférable à l’inaction.
5. Penser que les stakeholders comprennent la data
J’ai déjà vu les équipes marketing, produit et finance interpréter le même taux de conversion de manière différente.
Ce que je pensais clair comme de l’eau de roche était en fait un brouillard épais pour mes stakeholders.
De plus, je pensais que mon travail s’arrêtait une fois mon analyse livrée. Mais la vérité, c’est que la plupart des décideurs ne parlent pas "data".
Si une analyse ne mène pas à une action concrète, c’est qu’elle n’a pas été comprise.
Ce que je ferais différemment :
Investir du temps dans la data storytelling. Rendre mes insights clairs, pertinents et convaincants.
Si vous voulez avoir un impact, ne vous contentez pas d’analyser : apprenez à communiquer efficacement.
En résumé
Si je pouvais recommencer, je me concentrerais moins sur "faire plus" et plus sur "faire ce qui compte" :
✅ Dire non aux demandes inutiles.
✅ Simplifier mes dashboards.
✅ Me concentrer sur les bases.
✅ Livrer vite, même avec des données imparfaites.
✅ Rendre mes analyses accessibles aux non-techs.
J’espère qu’avec ce partage, vous éviterez ces erreurs, et vous accélérerez votre progression en data – sans les frustrations et les pertes de temps que j’ai connues.
Si vous trouvez cette édition utile, un petit cœur me ferait très plaisir !
À la prochaine fois !