Mettre en place une approche Analytics Engineering avec Swile
Hello,
J'espère que tu vas bien ! 👋
Je suis ravi de te retrouver pour cette 2ème édition depuis le lancement de la communauté Data Gen. Si tu la reçois, c’est que tu fais partie de mes 513 personnes préférées !
En train de rédiger cette édition dans un Coffee Shop aux Abbesses. Dis-moi si tu passes dans le coin, le café est excellent et je t’invite ! 👋☕️
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.
T’es Data Engineer et tu cherches ta nouvelle aventure ? Dis-le moi en réponse à ce mail, je te mets en relation avec un Head of Data qui recrute.
L'agenda de la semaine :
🔎 Le zoom sur l'approche Analytics Engineering.
🎙 Le podcast avec Arthur de Swile sur l'Analytics Engineering.
📚 Les ressources recommandées par Arthur.
🙋♀️ Les mouv' de la communauté Data de cet été.
💡 Le projet open source d'un membre de la communauté.
📢 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 l'approche Analytics Engineering (4 min)
Cette semaine, j’ai eu le plaisir d’échanger avec Arthur Péligry, Senior Analytics Engineer chez Swile, qui m’a parlé de ce que fait un Analytics Engineer au sein d’une organisation.
J’en ai profité pour lui poser une question que j’avais en tête depuis un moment : dans quel contexte est-il recommandé de créer un département Analytics Engineering ? Il a insisté sur 4 points.
1) Il n'y a pas de stratégie de modélisation commune
En bref :
Très souvent, les modèles sont créés en silo pour répondre à un besoin ou un projet data spécifique, sans être intégrés dans la vision globale. Chaque Data Analyst a ses propres requêtes sur son ordinateur qu’il ou elle va utiliser pour calculer les métriques en fonction de ses besoins.
"On se partage des requêtes SQL sur Slack, on s'envoie des petits bouts de code à droite à gauche mais on n’a pas vraiment de source de vérité pour notre nombre de clients, notre revenu ou notre MRR (Monthly Recurring Revenue).”
Comment les Analytics Engineers interviennent-ils ?
Leur objectif est d’harmoniser la manière dont les requêtes sont écrites entre les Data Analysts. Cela se fait via la centralisation des fichiers SQL dans un outil (ex : DBT, cf. définition ci-dessous). Les Analytics Engineers définissent avec les autres équipes la façon dont les modèles doivent être organisés, puis ils forment et accompagnent les Data Analysts dans l’usage de l’outil. Lorsque les Data Analysts ont besoin d’écrire une requête pour calculer une métrique, ils regardent dans DBT ou contactent leurs collègues pour vérifier si la requête n’existe pas déjà avant de l’écrire.
"DBT permet de déployer en collaboration des modèles de données tout en respectant les bonnes pratiques de développement (ex : code modulaire et portable, intégration continue, documentation, etc.)."
L’outil centralise l’ensemble des fichiers SQL (rangés dans des dossiers et sous-dossiers) qui définissent les modèles de données et donc les tables. Tous les Data Analysts peuvent retrouver les fichiers SQL dont ils ont besoin ou en ajouter de nouveaux. Il est possible de retrouver l’historique dans la mesure où les modèles sont versionnés avec git.
2) Les métriques clés qui ont des définitions différentes
En bref :
Ce deuxième point est une conséquence du premier. Si les Data Analysts écrivent leurs requêtes en silo et donc potentiellement en doublon, il y a de fortes chances que certaines métriques soient calculées différemment d’un département ou d’un projet à l’autre. Par exemple, le nombre d’utilisateurs actifs peut être différent pour les équipes Finance et Marketing car leurs membres n’en ont pas la même définition.
Comment les Analytics Engineers interviennent-ils ?
Leur objectif est d’aligner toutes les équipes sur des définitions de KPIs, ce qui représente un énorme chantier. Pour commencer, Arthur recommande d’identifier ses objets data prioritaires et ce qu’il appelle ses “champions” :
Les objets data prioritaires sont ceux pour lesquels aucune marge d’erreur n’est acceptable. Ce sont souvent les données liées aux transactions et aux clients.
Les “champions” sont les équipes qui sont les plus à même de consommer les données de manière autonome, qui connaissent bien les métriques et peuvent éventuellement faire des requêtes. Ce sont souvent les équipes Finance car elles ont l’habitude de travailler avec de la donnée, de faire des tableurs, etc.
Les Analytics Engineers doivent construire dans un premier temps le modèle lié aux KPIs prioritaires (ex : Revenu, Nombre de clients, etc.) tout en incluant les autres équipes (ex : Data, Marketing, Sales, etc.) afin qu’elles participent à leurs définition et qu’elles ne les découvrent pas au dernier moment.
"Si on arrive à servir des modèles à l'équipe finance et qu’elle a confiance dans la donnée, on a tout gagné."
Une fois que la modélisation et le processus fonctionne sur ce premier périmètre, les Analytics Engineers vont inclure les suivants de manière itérative.
3) Le pipeline de transformation des données n’est pas documenté
En bref :
Les Data Analysts ne parviennent pas toujours à savoir quand une table a été mise à jour, depuis quand une donnée a été calculée, à partir de quelle source, etc. ce qui complique leur usage. Comme expliqué dans le premier point, l’approche Analytics Engineering nécessite que les Data Analysts réutilisent des modèles construits par leurs collègues. Or, on ne peut pas être sûr que le modèle en question est le bon si on n’a pas accès à ces informations.
Comment les Analytics Engineers interviennent-ils ?
Ici, une fois de plus, DBT va permettre de documenter en détail tous les éléments sur les modèles qui sont nécessaires à leur usage. C’est le rôle des Analytics Engineers de définir quelles sont ces informations et de s’assurer que les Data Analysts les documentent à chaque fois qu’une modification est apportée aux modèles.
“On est garants que tout ce qui est fait est documenté, peut être consulté et est compréhensible par une personne de l'équipe Data mais aussi par une personne extérieure à l'équipe qui souhaite savoir ce qui se cache derrière telle ou telle métrique.”
4) Il n'y a pas de bonnes pratiques communes dans le code
En bref :
Lorsque les équipes ne suivent pas de bonnes pratiques de code communes (ex : un code de qualité optimisé par des profils plus seniors, des tests, une documentation systématique, etc.), les développements sont difficiles à maintenir dans le temps. Par exemple, dès qu’un membre de l’équipe s’en va, ses anciens collègues ont du mal à comprendre son code ou inversement, lorsque des nouvelles recrues arrivent, leur onboarding est difficile. Au fur et à mesure que l’entreprise grossit, de plus en plus de projets doivent être re-codés entièrement parce que l’équipe n’arrive plus à les faire évoluer.
Comment les Analytics Engineers interviennent-ils ?
Ici, l’objectif des Analytics Engineers est de définir ces bonnes pratiques en collaboration avec les autres équipes Data et puis de garantir qu’elles sont bien suivies (ex : relecture de code, vérification des tests, etc.). Ils s’inspirent notamment du professionnalisme de l’industrie logicielle traditionnelle.
“Avant chaque modification, suppression ou addition de code en production, il y a une relecture des pairs qui est faite. Il faut que le code soit cohérent avec les règles établies.”
Voilà pour le zoom de cette semaine, j'espère que ces éléments t'ont permis comme moi de mieux comprendre pourquoi certaines entreprises choisissent de créer un rôle dédié pour résoudre les problèmes évoqués. Initialement, ces activités étaient toujours partagées entre les Data Engineers et les Data Analysts mais ces derniers n’ont pas toujours le temps de les mener à bien.
Pour rappel, il n’y a pas de bonne ou de mauvaise organisation, il faut identifier laquelle est la plus pertinente par rapport au contexte de l’entreprise. 😉
🎙 Le podcast avec Arthur de Swile sur l'Analytics Engineering
Dans cet épisode, Arthur nous parle de son rôle de Senior Analytics Engineer, des problèmes qui justifient la création d'un département Analytics Engineer, de l'utilisation de DBT et du challenge de passer d'une approche individualiste à une approche collaborative.
Liens vers l’épisode : Spotify | Apple Podcasts | Deezer | Google Podcasts
📚 Les ressources recommandées par Arthur
La première est la newsletter blef.fr : elle propose chaque semaine un concentré d'articles et d'analyses data très pertinentes (👋 Christophe Blefari). La seconde est le blog Hacker Feed de YCombinator (l'incubateur le plus réputé des Etats-Unis) : il recense chaque jour de nombreux articles sur le business et la tech dont certains passionnants sur le data.
🙋♀️ Les mouv' de la communauté Data de cet été
💡 Le projet open source d'un membre de la communauté
Paul, Head of Data chez Nickel, développe en open source des fonctions BigQuery pour faciliter le travail des Data Analysts. Par exemple, la première permet d'afficher les statistiques d'une table directement dans l'UI de BigQuery. Et il cherche des bêta-testeurs pour avoir des retours !
Lien pour tester : ici (aucune installation ni compte à créer).
Tu peux lui faire un retour par mail (paul.marcombes@unytics.io) ou via Linkedin.
Si vous souhaitez partager un projet ou un challenge dans les prochaines éditions pour obtenir du feedback ou de l'aide de la communauté, n'hésitez pas à me contacter en répondant à ce mail ! J'en profite pour remercier Michael et Paul qui m'ont donné l'idée de cette rubrique. 🙏