Zoom sur 5 organisations Data à connaître
Hello,
J'espère que tu vas bien ! 👋
Je suis ravi de te retrouver pour cette 3ème édition depuis le lancement de la communauté Data Gen. Si tu la reçois, c’est que tu fais partie de mes 598 personnes préférées !
Merci Guilhem 👋 pour ton retour d'expérience exceptionnel dans le podcast de cette semaine !
Avant tout, voici quelques infos utiles :
Inscris-toi au prochain webinar sur la stratégie data de BlaBlaCar.
On t'a transféré ce mail ? Inscris-toi à la communauté pour recevoir les prochaines éditions.
sur l'Analytics Engineering de la semaine dernière si tu l'as raté.
L'agenda de la semaine :
🔎 Le zoom sur 5 organisations Data observées en startups.
🎙 Le podcast avec Guilhem de Linkfluence.
📚 La ressource recommandée par Guilhem.
📢 Les éditions de septembre sont rendues possibles par Artefact, le cabinet de conseil spécialisé sur la Data 📢
Lien vers leurs postes ouverts : ici
🔎 Le zoom sur 5 organisations Data observées en startups (10 min)
Au fur et à mesure de mes échanges avec des Heads of Data, j’ai pu observer 5 modèles organisationnels qui reviennent souvent.
Ces modèles ont tous des avantages et des inconvénients. Les entreprises les font évoluer avec des réorganisations régulières pour continuellement adopter les plus pertinents en fonction de leurs priorités pour les quelques années suivantes.
1) Le modèle “Centralisé”
Toutes les équipes Data sont réunies sous un manager commun (ex : Head of Data, Chief Data Officer ou VP Data). Les profils techniques tels que les Data Engineers et les profils plutôt business tels que les Data Analysts / Scientists ont donc le même boss, participent aux mêmes meetings hebdomadaires et adhèrent à la même vision data.
Les avantages :
Ce modèle permet une meilleure collaboration entre les équipes Data Engineering et les équipes Data Analysts.
Par exemple, cette organisation sera optimale pour délivrer les projets data plus rapidement ou pour initier des chantiers data transverses qui nécessitent une collaboration accrue de la part de tous les profils (ex : migrations, culture avec définition des KPIs, etc.).
Les risques :
Un modèle centralisé peut introduire un silo entre les équipes Data Analysts et les équipes Business (ex : Produit et Marketing qui sont les clients internes des Data Analysts) et les conduire à collaborer de manière moins efficace.
2) Le modèle “Décentralisé”
Certains profils data tels que les Data Engineers et les Data Scientists ont un manager Data (ex : Head of Data), mais les équipes Data Analysts reportent à un manager Business (ex : Chief Product Officer pour les analystes spécialisés produit, Chief Marketing Officer pour les analystes spécialisés marketing, etc.).
Les avantages :
Ce modèle permet une meilleure collaboration entre les Data Analysts et les équipes Business (Product Manager, Marketeurs, etc.).
Par exemple, les Data Analysts passeront naturellement plus de temps avec leurs clients internes, comprendront mieux leurs enjeux, leurs process et pourront ainsi proposer des analyses et des solutions plus pertinentes.
Les risques :
Un modèle décentralisé peut générer un silo entre les équipes data techniques (comme les Data Engineers) et les équipes Data Analysts, et complexifier leur collaboration.
Par exemple, les Data Analysts auront plus de difficultés à obtenir les données dont ils ont besoin parce que leurs sujets ne seront pas toujours priorisés dans les roadmaps des Data Engineers.
3) Le modèle “Avec Full-Stack Data Engineer”
Dans ce modèle, le Data Engineer s’occupe de la stack data, de collecter la donnée brute des sources (e.g. CRM, back-office, etc.) mais aussi de préparer la donnée dans un modèle adapté aux besoins des Data Analysts (ex : construction d’un tableau de bord).
Les avantages :
Ce modèle permet de réduire le temps de mise à disposition des données - entre la collecte et la mise à disposition dans l’entrepôt de données - dans la mesure où ce sont les mêmes profils qui s’occupent de toute la chaîne.
Par ailleurs, les Data Engineers sont au contact des Data Analysts pour leur mettre à disposition les données. Ils comprennent donc les besoins business associés à leurs activités, ce qui favorise leur engagement et évite le syndrome de "l'exécutant".
On parle en détail de ce modèle dans l'épisode 11 sur Doctolib.
Les risques :
Il est très compliqué pour un Data Engineer de délivrer un travail de qualité sur toutes ces activités.
La partie modélisation des données risque d’être laissée de côté si l’équipe manque de temps. Celle-ci nécessite une grande collaboration avec les Data Analysts pour comprendre leurs besoins dans le détail (ex : analyses, tableaux de bords, etc.) et proposer un modèle de données global qui soit pertinent.
Malheureusement, par manque de temps, chaque modèle de données est souvent construit dans l’entrepôt en silo pour répondre à un projet spécifique, et il n’y a pas de cohérence globale. Cette situation peut entraîner des problèmes de Data Quality, des écarts et à terme des contradictions dans les analyses.
4) Le modèle “Avec Analytics Engineer”
Dans ce modèle, le Data Engineer s’occupe de la stack data et de la collecte des sources de données, mais c’est l’Analytics Engineer qui se charge de la modélisation des données. L'Analytics Engineer fait le lien entre les Data Engineers et les Data Analysts. Il s’occupe notamment d’harmoniser les modèles et de piloter les chantiers de définition des KPIs.
Les avantages :
Ce modèle permet de décharger les Data Engineers et d’atteindre une meilleure harmonisation des modèles et définition des KPIs, en ayant des profils à temps plein sur ces chantiers. Ainsi, les données mises à disposition répondent aux besoins des Data Analysts tout en supprimant les écarts et les risques d’analyses contradictoires.
On parle en détail de cette approche dans l'épisode 26 sur Swile. Par ailleurs, c'était l'objet du partagé dans l’édition #2 de la newsletter.
Les risques :
Dans un premier temps, certains Data Engineers peuvent être moins satisfaits et engagés dans l’entreprise car ils se concentrent sur la stack data et la collecte, et sont donc moins impliqués dans les projets business avec les Data Analysts ou Scientists (le fameux syndrome de "l'exécutant").
Par ailleurs, cette organisation rallonge le temps de mise à disposition des données car le process est plus lourd (ex : intégration de la nouvelle donnée dans le modèle global) et il y a plus de profils qui interviennent sur la chaîne (ex : Data Engineer et Analytics Engineer).
5) Le modèle “avec Full-Stack Data Analyst”
Dans ce modèle, le Data Analyst s’occupe des analyses complexes, des tableaux de bord (en partie) et de la modélisation dans l’entrepôt de données en fonction de ses besoins. Il ne produit qu’une faible partie des tableaux de bord parce qu’il met à disposition des outils pour que les équipes Business (Opérations, Produit, etc.) soient autonomes pour les produire. Il peut ainsi dédier plus de temps à la modélisation (celle dont s'occupait le Full-Stack Data Engineer dans le modèle précédent).
Pour que cette organisation fonctionne, les Data Engineers doivent mettre en place les outils et la documentation qui permettent aux Data Analysts (profils en général moins techniques) d’être autonomes dans la préparation des modèles de données (ex : DBT, bonnes pratiques de codes, etc.).
Les avantages :
Cette organisation permet de réduire le temps entre la mise à disposition de la donnée brute dans l’entrepôt et la génération d’un insight business (ex : analyse, exposition dans un tableau de bord).
Les Data Analysts sont autonomes pour modéliser la donnée sur toute la chaîne dès lors qu’ils ont identifié un besoin et dépendent moins des Data Engineers.
Ce modèle permet à une équipe limitée de fournir des données et des insights à un grand nombre de collaborateurs. C’est notamment le cas d’Aircall : en 2022, l’entreprise fournit de la donnée à 650 collaborateurs avec une équipe data de 15 personnes.
On parle de cette approche dans l'épisode 14 sur Aircall.
Risques :
Un peu comme pour le modèle “Full-Stack Data Engineer”, il est très compliqué pour un Data Analyst de délivrer un travail de qualité sur toutes ces activités.
D’un côté, il est possible que les analystes soient moins proactifs et pertinents dans leur propositions d’analyses ou de tableaux de bord, puisqu’ils ont également à leur charge des sujets techniques de modélisation.
Inversement, ils pourraient délaisser ces chantiers techniques, ce qui induirait une moins bonne harmonisation des modèles de données, des écarts et donc des risques d’analyses contradictoires.
Quel modèle choisir ?
Tout dépend du besoin et du contexte de l’entreprise.
Voici quelques exemples :
Si elle a des problèmes de collaboration entre les Data Analysts et leurs clients internes au Marketing ou au Produit, elle pourrait explorer la décentralisation.
Si à l’inverse, elle a des problèmes de collaboration entre les équipes techniques (Data Engineers) et les Data Analysts, et que cela l’empêche de lancer des initiatives structurantes telles qu’une migration ou un chantier d’harmonisation des KPIs, elle peut étudier une re-centralisation.
S’il existe une lenteur dans la mise à disposition des données depuis la source de données (ex : CRM) vers un modèle exploitable par les Data Analysts, elle peut examiner l’approche avec un Full-Stack Data Engineer.
A l’inverse, si la lenteur intervient entre la modélisation des données et leur usage dans une analyse ou un tableau de bord, elle peut explorer le modèle avec un Full-Stack Data Analyst.
Enfin, si elle accumule des problèmes de Data Quality et de contradictions dans les analyses, elle peut étudier la création d’un rôle Analytics Engineer.
Voilà pour le zoom de cette semaine ! Je rappelle que ce zoom est une synthèse de mes discussions avec une 30 aine de Heads of Data de startups et scaleups mais que ce n'est pas une analyse exhaustive du marché ! 😉
🎙 Le podcast avec Guilhem, pionnier du social listening
Dans cet épisode, Guilhem nous raconte la genèse de Linkfluence dans un marché en balbutiement, il nous parle d'exemples d’application sur Danone et Nike et revient sur l'énorme challenge technique qu'ils ont rencontré : traiter les centaines de millions de données générées par les réseaux sociaux et y appliquer les dernières technologies de pointe (e.g. computer vision, NLP, etc.)
Liens vers l’épisode : Spotify | Apple Podcasts | Deezer | Google Podcasts
📚 La ressource recommandée par Guilhem
Le code a changé est un podcast du journaliste Xavier de la Porte sur le numérique et son impact sur la société.