Structure d’une stack data en scale-up + exemple de Payfit

Certaines problématiques data apparaissent quand l'entreprise grandit. Julie, data engineer chez 360Learning, décrit la structure de la stack data d'une scale-up.
Sommaire

On vous en avait déjà parlé dans cet article, le choix de vos outils data dépend de la taille de votre entreprise et surtout de votre niveau de maturité sur les sujets data.

J’aborderai donc dans ce contenu les problématiques, les challenges et les méthodes de travail liés au niveau de maturité de la scale-up spécifiquement.

Commençons par poser les bases : qu’est-ce qu’une scale-up ?

Il s’agit d’un statut intermédiaire entre la start-up et la licorne. Généralement, l’objectif de ce type d’entreprise n’est plus d’itérer pour rechercher un business model viable, mais plutôt de suivre ce business model pour générer de la croissance.

C’est le cas de Payfit, de 360Learning ou encore de Tiller, dont je partagerai les exemples plus loin.

La structure d’une stack data idéale en scale-up

Voici un exemple de structure de stack data classique, inspirée par l’exemple de SumUp – ex-Tiller Systems. L’avantage, c’est que les outils data utilisés varient rarement d’une entreprise à l’autre. Vous pouvez donc considérer que ce schéma représente la stack data de 80% des scale-up.

Si l’on regarde ce schéma, on y voit différentes étapes. Pour chacune d’elle, vous serez amené à choisir les outils adaptés.

  1. Connectez vos data sources : ce sont les outils opérationnels depuis lesquels va être collectée la data. Par exemple, si vous utilisez Salesforce comme CRM, Salesforce sera une de vos data sources. Si vous utilisez Facebook Ads pour du marketing, même chose…
  2. Extrayez et chargez les données : ici, vous collectez la donnée depuis vos data sources et l’envoyez dans un espace de stockage unique. Vous pouvez le faire soit en utilisant du code, plus précisément le langage Python, soit avec des logiciels clés en main que l’on appelle ETL comme Fivetran ou Stitch.
  3. Stockez vos données : l’idée est de n’avoir qu’une source de données unique. C’est en fait un lieu unique où vous centralisez l’ensemble de votre data : c’est ce qu’on appelle un data warehouse, à l’image de BigQuery ou de Snowflake.
  4. Transformez les données **: lors de cette étape, vous formatez les données pour les rendre lisibles et utilisablespar les équipes métiers. **Des outils comme DBT vous permettent de le faire simplement, même si vous pouvez aussi utiliser Python ou votre ETL.
  5. Analysez la donnée en l’envoyant dans des outils de business intelligence utilisés pour le reporting, tels que Tableau ou Salesforce. Les équipes métiers peuvent ainsi facilement prendre les bonnes décisions, fondées sur la data et non pas sur de simples ressentis.

Les problématiques de structure d’une stack data d’une scale-up

Une base de données scalable

Plus l’entreprise grandit, plus les utilisateurs et les données sont nombreux, et donc plus le nombre de requêtes est important. Il est donc essentiel que la base de données puisse supporter la charge.

L’une des techniques utilisées par Julie consiste à créer des noeuds : les calculs intermédiaires sont ainsi traités séparément sur chaque noeud, puis les calculs finaux sont rassemblés sur le noeud central. C’est notamment ce que permet de faire BigQuery.

Vous pouvez ainsi travailler en parallèle sur de nombreuses requêtes et gagner ainsi du temps.

Vers l’ELT plutôt que l’ETL

Comme je le disais plus haut, l’ETL est un logiciel qui permet de récolter, de transformer et de stocker les données de l’entreprise. Dans le cas de l’utilisation d’un ETL, je formate ma donnée entre la data source et le data warehouse. Dès que j’ai besoin d’un nouveau type d’analyse, j’ai donc besoin d’aller de nouveau chercher la donnée dans ma data source puis de la transformer.

De plus en plus d’entreprises envisagent de passer à un modèle ELT, c’est-à-dire que je formate ma donnée une fois qu’elle a été stockée dans le data warehouse. Ainsi plutôt que de réaliser l’étape de transformation en amont de l’étape de chargement, elle est réalisée après. Cela permet de décorréler les deux actions et apporte une plus grande flexibilité.

Ainsi si l’on souhaite de nouveau apporter une transformation, je n’ai pas besoin de charger de nouveau l’ensemble des données et gagne donc un temps précieux.

Vers les ETL managés

Généralement, l’entreprise peut gérer toute sa collecte et sa transformation de données en autonomie, en utilisant le langage Python, assorti de l’outil Airflow. Cet outil permet notamment de programmer des workflows et donc d’automatiser certains traitements de la donnée.

Néanmoins, quand les équipes grandissent et demandent de plus en plus d’analyses, cela nécessite une bande passante importante des data engineers.

Je recommande donc d’utiliser des ETL managés, à l’image de Fivetran. Ce sont des logiciels permettant de simplifier et d’automatiser le traitement de la data. Par exemple, si un collaborateur vous demande une donnée spécifique, vous avez simplement à cocher une case, plutôt que de créer une nouvelle requête

Vers l’incrémental plutôt que le full refresh

Dans la plupart des entreprises, les requêtes quotidiennes chargent l’ensemble des données, ce qui demande une bande passante significative ainsi qu’un délai important. C’est ce qu’on appelle le full refresh.

En scale-up, on adopte de plus le chargement incrémental. Ce dernier permet d’actualiser uniquement les données modifiées depuis le dernier chargement, ce qui représente un gain de temps considérable.

Pour gagner du temps, les requêtes ne chargent pas l’ensemble des données chaque matin, mais uniquement les données modifiées depuis le dernier chargement.

Collaborer sur une stack data en scale-up

Plus le nombre de personnes avec lesquelles les data engineers sont amenés à collaborer augmente, plus la formalisation des process et l’automatisation prend de l’ampleur.

Ainsi, la gestion des accès à la base de données peut se transformer en une tâche très chronophage si de nouveaux salariés arrivent chaque semaine. Cette action peut donc être automatisée.

De même, tout le monde n’aura pas le même niveau d’accès aux données. Par exemple, les équipes sales ne voudront pas que d’autres départements aient accès à leur variable. Il faut donc définir des règles de visualisation claires.

Pour que l’ensemble des parties prenantes puisse avoir une vision sur ce qui existe et qui est responsable de telle ou telle donnée ou requête, Julie conseille de créer un data catalog – un peu comme un content manager pourrait créer un catalogue de contenus.

Enfin, pour que les data analysts et data scientists puissent travailler en toute autonomie, les data engineers doivent préparer un framework optimal.

De nouveaux challenges quant à la structure d’une stack data mature

Avec l’atteinte de la maturité data d’une scale-up, de nouvelles problématiques se posent.

  • Comme le data warehouse est la source ultime de vérité, les équipes veulent avoir ces données dans les outils qu’elles utilisent au quotidien. C’est ce qu’on appelle le reverse ETL.
  • Habituellement, les data engineers ont accès aux bases de données internes de type MongoDB. Il faut qu’ils soient très vigilants car un trop grand nombre de requêtes peut impacter la production. Or, chez Payfit ou 360Learning, le produit est au coeur de l’activité.
  • La question de la fréquence de la collecte des données se posent aussi : dans la plupart des petites entreprises, la data est récupérée en masse la nuit : c’est ce qu’on appelle le batch. L’idée serait de récolter les données quasiment en temps réel : c’est ce qu’on appelle le streaming.

Pour en savoir plus sur la mise en place d’une stack data, retrouvez mes cours dans la formation Emil sur le Marketing & Data Automation. Le programme se trouve ici !

Les internautes ont également consulté :
Pour développe mes compétences
Formation développeur web
Formation data scientist
Formation data analyst
Les internautes ont également consulté :

Suscribe to our newsletter

Receive a monthly newsletter with personalized tech tips.