Chez Deepki, la donnée est au cœur de notre métier puisque c’est à partir des informations obtenues sur les bâtiments, les compteurs, ainsi que les factures et les consommations, que nous pouvons savoir où et comment faire des économies d’énergie. Une bonne partie de ces données sont collectées automatiquement, via des scrapers, des API, ou remplies directement à la main par les utilisateurs de notre application Deepki Ready. Pour intégrer les données clients, nous utilisons aujourd’hui un outil ETL (Extract-Transform-Load) développé en interne, mais il n’en a pas toujours été ainsi. Dans un premier temps, nous verrons comment nous en sommes venus à développer notre propre ETL, puis nous détaillerons nos choix technologiques et comment ils ont impacté notre organisation.

La voie vers l’ETL

Avant l’implémentation de notre ETL, le fonctionnement chez Deepki était à peu près le suivant : chaque data-engineer était rattaché à un ou plusieurs Customer Success Managers (CSM) et il avait pour mission d’intégrer les données patrimoniales des clients. Cette approche permettait de pouvoir s’adapter aux données de chaque client, peu importe le format fourni. Cependant, plusieurs soucis ont émergé : tout d’abord, la base de code gonflait artificiellement, car cela impliquait parfois beaucoup de duplications entre nos clients. D’autre part, avec l’augmentation du nombre de clients, ce système souffrait d’un manque de scalabilité : plus de clients impliquait de recruter de plus en plus de data-engineers.

Avant de faire la transition, il était important de poser les besoins qu’il était nécessaire de satisfaire : maintenir la possibilité d’accepter les formats clients, car leur imposer un format pourrait être un frein (le client n’a pas forcément la possibilité/l’envie de changer le format de ses données, si son infrastructure dépend de celui-ci). D’autre part, rendre les CSMs indépendants : en étant autonomes, cela leur permettra d’être plus réactifs face aux demandes clients, et par la même occasion de libérer les data-engineers pour d’autres tâches. Il fallait donc un outil accessible, simple d’utilisation, et adaptable aux besoins spécifiques de chaque client, mais aussi facilement maintenable par les data-engineers. Une fois ces bases posées, il a été décidé de partir sur une solution développée en interne plutôt qu’une solution commerciale, ce qui nous donnait une maîtrise supplémentaire de l’outil.

Les technologies derrière cet ETL

Commençons par la “fin” : Load, ou quel stockage pour mes données ?

Pour choisir son stockage il faut connaître ses données. D’abord, à quels types de données avons-nous affaire ? Eh bien chez Deepki, un peu de tout : beaucoup de données numériques bien sûr, comme les consommations énergétiques des bâtiments, ou les montants de factures, mais aussi des données alpha-numériques (essentiellement texte) : toutes les informations sur les bâtiments, sur les compteurs… Et enfin, des données temporelles. On voit donc déjà la richesse et la diversité des informations exploitées. Un autre point important à prendre en compte est l’homogénéité : par exemple, est-ce que d’un bâtiment à l’autre, j’aurai toujours le même type d’informations, les mêmes champs à remplir, etc. Et là encore on se rend vite compte que d’un projet à l’autre, voire au sein d’un même projet, la quantité et le type d’informations peut varier grandement.

C’est pour ces raisons que, bien avant de mettre en place un ETL, le choix a été fait de stocker nos données sous MongoDB, une base de données noSQL, où la flexibilité que donne la gestion en documents permet un stockage facile de ces données.

Extract : quelles sources, quelles fréquences ?

Comme expliqué plus haut, un des aspects importants de notre ETL est sa capacité à pouvoir extraire l’information de plusieurs formats de fichiers différents, eux-mêmes remplis différemment au gré des clients. Cependant, Python et pandas nous ont grandement simplifié la tâche grâce à plusieurs points :

  • des méthodes adaptées à la lecture de fichiers csv, Excel, parquet, et bien d’autres
  • la possibilité de les convertir en un format unique, le Dataframe, permettant une manipulation simplifiée et homogène des données
  • le fait que ce format soit capable de stocker tout type de données, ce qui rend tout cet ETL entièrement configurable.

Chaque projet a ainsi un répertoire spécifique, dans lequel le chef de projet peut déposer les fichiers fournis par le client, ce qui nous amène au point suivant : l’intégration en temps réel. Ainsi, à chaque fois qu’un fichier est déposé (cela peut être fait automatiquement via sFTP par exemple), le processus d’intégration est relancé, permettant d’avoir ainsi des données à jour le plus rapidement possible. Nous utilisons pour cela le service SNS d’Amazon (voir notre article sur le sujet).

Transform : apporter de la cohérence aux données

Maintenant que les données sont extraites, il faut les transformer pour qu’elles répondent aux critères permettant à l’application de fonctionner. Une première transformation, simple mais nécessaire, est le renommage des colonnes avec des noms standardisés.

Vient ensuite le moment de “nettoyer” les données : enlever les lignes vides, convertir certains formats, etc. Nous gérons cette étape avec tout un panel d’outils que nous appelons transformers : plein de petites fonctions, qui sont autant d’outils très spécialisés, au service du chef de projet pour amener ses données à la qualité souhaitée.

Une fois les données extraites, il faut les nettoyer et les standardiser. Pour cela, nous avons notamment développé tout une “boîte à outils” que le CSM peut utiliser à son gré de façon simple pour lui permettre d’homogénéiser les données récupérées.

Conclusion

Ce passage à un outil ETL a permis de grands changements au sein de Deepki :

  • Tout d’abord, les data-engineers sont devenus une véritable équipe de développeurs qui a pu se consacrer à l’application Deepki Ready.
  • Ensuite, cet outil a facilité la standardisation des projets, ce qui a conduit à un gain tant au niveau de la maintenance des projets que leur amélioration globale.
  • Enfin, les CSM ont énormément gagné en autonomie, en n’ayant plus à taper une seule ligne de code mais simplement en rentrant la configuration de leurs projets et la façon dont les données vont être extraites.

L’étape d’après que nous envisageons maintenant est de développer une véritable IHM (Interface Homme-Machine) qui permette de réduire drastiquement cette étape de configuration, ainsi qu’améliorer grandement l’expérience utilisateur.