A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnus il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et spécialistes de l’IA externes à Devoteam Revolve.

Nous recevons aujourd’hui Christophe Blefari, Data Engineer depuis 8 ans. Christophe anime également une newsletter sur le Data Engineering et une chaîne Youtube de vulgarisation. Vous pouvez le retrouver sur son site, sur Youtube ou sur Twitch.

Comment définis-tu ton métier ?

Je suis Data Engineer. Depuis que je suis sorti de l’école en 2014, je vois mon métier comme celui d’un ingénieur, ou software engineer, qui travaille avec de la donnée. Cela peut recouvrir de nombreuses réalités, de cas d’usage et d’applications : déplacer la donnée d’un système vers un autre, créer des visualisations de données, ou développer des applis qui font des prédictions de ML.

Mon métier consiste à essayer de couvrir une partie de ces cas d’usage, en faisant du développement logiciel. Certaines pratiques de développement sont cependant spécifiques au domaine, et diffèrent des règles du logiciel standard.

Il s’agit donc de construire les systèmes pour gérer le cycle de vie de la donnée ?

Pour vulgariser, on crée une plateforme de données. Donc il y a une notion d’infrastructure, d’architecture, et une surcouche logicielle pour permettre à tous les acteurs de la donnée de travailler avec. En fonction des entreprises, les frontières sont différentes, entre les missions d’un ou une data engineer, et celles des data scientists, data analysts, business analysts, etc. Mais le socle commun entre tous ces métiers, c’est la donnée, qui est stockée dans une base.

En général, les Data Engineers déplacent la donnée, la récupèrent d’une source pour la mettre dans les systèmes internes, faire des premières transformations, la préparer, et la nettoyer. Le plus souvent, ça s’arrête là, ils ou elles ne font pas la surcouche métier, mais fournissent les outils pour que les analystes puissent le faire. Le ou la Data Engineer est vraiment un partenaire au sein de l’équipe data, qui fait du développement logiciel pour les équipes data et les équipes métier.

En tant que freelance, quelles sont tes missions ?

J’interviens le plus souvent sur du temps partiel, sur des missions où j’accompagne les entreprises à démarrer leur process de Data Engineering. De fait, le contexte n’est pas celui d’équipes structurées; je travaille généralement sur la définition de la vision, sur le choix des briques à mettre en place. Je fais aussi de l’accompagnement au recrutement, en faisant passer les tests techniques pour recruter les premières et premiers Data Engineers des équipes.

Actuellement, je suis dans une mission plus opérationnelle sur la mise en place d’une infrastructure technique avec des process data. C’est encore une phase exploratoire, quand le projet passera en production, il sera pris en charge par une autre équipe.

Quelles sont les qualités d’un bon Data Engineer ?

Cela dépend du niveau de seniorité recherché.

A mon sens, sur un profil junior on ne va pas rechercher des compétences techniques, hormis la programmation. On attend des soft skills comme l’autonomie, la curiosité, et la capacité à résoudre des problèmes. Quand le pipeline casse, le métier de Data Engineer est assez difficile – on subit une grosse pression, tout le monde réclame l’accès à sa donnée. Cette pression peut mener à faire les mauvais choix au mauvais moment, résoudre des problèmes dans ces conditions est assez difficile. On cherche donc des profils capables de débugguer, de comprendre le fonctionnement d’un système. Il faut aussi une bonne capacité d’apprentissage, car il est impossible d’être un ou une bonne Data Engineer en junior. Résoudre des problèmes demande d’y avoir été confronté au préalable, il faut avoir connu des incidents en production.

Pour un profil senior : être très bon en logiciel, connaître les bonnes pratiques du développement logiciel, comprendre la donnée (savoir faire du SQL, comprendre les modèles de données, avoir les bonnes pratiques). Dans une équipe Data, le ou la Data Engineer est le référent technique, c’est le premier point d’entrée quand il y a un problème avec la donnée. Il faut donc être humainement capable d’épauler l’équipe, d’entrer très vite dans le problème, bref être compétent rapidement. Ici aussi, on cherche de fortes compétences en résolution de problème.

Quels sont tes outils de prédilection ? 

J’ai toujours codé en Python. Au-dessus du langage de programmation, il y a une myriade d’outils, open source ou non. Par exemple, pour orchestrer les flux, j’utilise beaucoup Airflow. Il existe de nombreuses alternatives, mais j’apprécie vraiment la vision développée par Airflow et la façon de créer du pipeline. Ensuite, il y a du SQL, et là les technologies derrière peuvent varier : Postgres pour une base open source, des solutions Cloud pour le warehouse (BigQuery, Snowflake, Redshift). Personnellement j’ai toujours eu une préférence pour BigQuery, c’est aussi le plus simple à utiliser pour démarrer. Un compte Google suffit. Ce sont en tous cas mes choix techniques personnels.

Dans le domaine du Data Engineering, deux mondes s’opposent : Python et Java. Ce sont deux écosystèmes en conflit, qui se critiquent. Pour ma part, j’ai testé Spark en 2015, j’avais trouvé cela trop compliqué et je n’ai pas suivi cette voie. Ce sont en tous cas deux branches qui génèrent des choix d’infrastructure très différents.

Quels sont les outils qui te manquent ?

De mon point de vue, en tant que Data Engineer, il ne manque rien : s’il manque quelque chose, on peut le développer. Plus généralement, le plus souvent, ce qui manque est de l’ordre du process, pas de la technologie. Beaucoup de problèmes sont maintenant adressés par la technologie, mais elle n’apporte pas toujours une solution. On se plaint beaucoup de la qualité de la donnée, pour autant la réponse n’est pas un outil. Une solution technique ne résout jamais le problème à l’échelle de l’entreprise : il faut un process, des responsables, et organiser l’entreprise autour de la qualité de la donnée. Les outils ne s’administrent pas tout seuls.

Et le cloud ?

Je suis passé sur le Cloud depuis 2019, mais ça dépend beaucoup du contexte client. Toutes les start-up sont sur le Cloud, les grandes entreprises sur Cloud et on-premise, et le secteur public reste on-premise. Il est intéressant de noter qu’on arrive à une étape de la maturité technologique où tous les services on-premise essaient de répliquer une offre de service similaire au cloud.

Le niveau de service et la simplicité apportées par le cloud ont tout changé.

Est-ce que les services managés Cloud, toujours plus nombreux, changent la façon dont tu travailles ?

Cela dépend de l’entreprise : est-ce qu’on développe ou on achète (build ou buy) ? Le coût du build est porté par la ressource humaine, le buy permet d’affecter ses ingénieurs sur d’autres sujets. Le Cloud apporte de nombreux services managés en effet, mais on peut aussi lancer une VM et installer le service dans sa version open source. C’est un débat propre à chaque entreprise, pour ma part cela dépend des services. J’ai tendance à utiliser des services managés Postgres, pour Airflow ça peut varier, mais si je me sens limité par la version managée, ou si le surcoût est trop élevé, je me pose la question de le faire moi-même.

Le ML ops, mythe ou réalité, ou un idéal vers lequel tendre ?

ML Ops, DevOps, DataOps… c’est une philosophie que chaque entreprise implémente de manière différente. Je pense que le plus important est de fournir aux équipes de développement les outils pour les rendre autonomes, que ce soit dans le déploiement des applications ou des modèles, puis leur monitoring et le versionning.

De nombreuses entreprises ont développé une approche similaire pour simplifier le déploiement du Machine Learning, cependant elles ne sont pas si nombreuses à faire du ML en production. A vrai dire, le ML Ops a surtout un intérêt quand on a beaucoup de modèles. Je me méfie par ailleurs des mots clés et des concepts marketing. Restons pragmatiques : il s’agit de fournir une plateforme simple d’utilisation pour les développeurs, qu’ils soient software ou data. 

Quels sont les challenges que tu rencontres le plus fréquemment ?

D’une année sur l’autre, déplacer de la donnée d’une source vers une destination est une mission récurrente. Beaucoup d’entreprises en sont encore là, elles ont besoin d’une infrastructure pour déplacer la donnée de toutes leurs API marketing, des réseaux sociaux, d’un outil CRM/sales vers un warehouse, etc.

Ensuite, il y a la partie transformation et préparation de la donnée. Le challenge, c’est de répondre à l’éternel débat, est-ce qu’on développe un flux, est-ce qu’on utilise un outil open source ou sa version Cloud ? De nombreuses entreprises en sont encore à cette étape de réflexion.

Ce qui te passionne dans ton métier ?

Je suis entré dans le métier de la donnée par la visualisation. Je faisais des visus en Javascript, et j’ai trouvé ça génial. Prendre des chiffres, en faire des tableaux dynamiques, interactif, pour que les gens puissent les manipuler et comprendre des choses. Ça m’a passionné. J’y reviendrai un jour, il faut juste que je trouve le temps ! 

Ce qui me passionne également dans la donnée, c’est que le milieu est encore nouveau, il y a plein de choses à faire. Ce n’est pas un domaine aussi standardisé, hiérarchisé, que peut l’être le software engineering. Il y a beaucoup de marge de manœuvre, de choix technologiques à faire. On a accès à des entreprises avec des échelles incroyables, des tables avec des milliards de lignes. J’adore aussi mon métier car je peux travailler sur toute la chaîne de valeur de la donnée, du challenge technique à l’échelle jusqu’à la visualisation.

Comment en es-tu venu à faire des vidéos et une newsletter ?

Quand j’étais petit, je voulais être prof de maths. J’ai toujours gardé cette envie de transmettre du savoir, d’aider les gens à comprendre. Depuis 6 ans je donne des cours d’informatique en fac. La transmission est limitée à des petits groupes, j’avais envie de toucher plus large. Le Data Engineering est en pénurie de talents : il y a peu de Data Engineers, et très peu de bons data engineers.

A mon échelle, j’ai envie de montrer ce qu’est le métier. C’est comme ça que j’ai commencé à faire de la veille sur Twitch, à écrire, puis à proposer une newsletter hebdomadaire. Mon KPI, c’est de convertir des Data Scientists pour qu’ils deviennent Data Engineers ! Plus il y aura de Data Engineers, moins les équipes data seront frustrées dans leurs missions. Aujourd’hui il n’y pas encore assez de répondant côte engineering pour aller aussi loin que ce que les équipes voudraient, et la charge de l’engineering est parfois portée par les Data Analysts et les Data Scientists, ce qui peut générer de la frustration.

Pour finir, des sources d’inspiration ?

Quand j’ai commencé, mes principales sources d’inspiration ont été les grandes start-up américaines. Uber, Netflix, Airbnb, Lyft… toutes ont des blogs techniques qui abordent de nombreux sujets de façon très complète. Il y a beaucoup à apprendre, mais attention, tout le monde n’a pas la force de frappe d’un Netflix, qui face à un problème, va développer une solution maison. Mais c’est super pour comprendre les concepts.

Je recommande aussi un livre sorti récemment, “Fundamentals of Data Engineering”, par Joe Reis et Matt Housley. C’est super complet, le livre pose toutes les bases du Data Engineering et le vocabulaire.