Publié par

Il y a 3 semaines -

Temps de lecture 8 minutes

Data Scientists et Data Engineers, ensemble sinon rien

Du fait de la méconnaissance de ces profils par les entreprises, la combinaison entre les Data Scientists et Data Engineers n’est pas toujours harmonieuse. En conséquence les projets Data Sciences, souvent, ne voient pas le jour. Pourtant il faut mettre un point tout particulier à la collaboration entre ces profils essentiels. Explications et pistes fonctionnelles.

 

Lorsqu’on parle d’équipes agiles, on pense généralement à un groupe détenteur de l’ensemble des expertises pour développer à elle seule le produit souhaité. Ces équipes multi-compétences sont bien connues et intégrées pour les produits plus « classiques » : applications web, mobile… Cependant, les organisations de ce type ne sont pas automatiques pour des équipes Data. A la vue de leurs compétences et du buzz généré autour de ce métier, les entreprises imaginent peut-être que les Data Scientists peuvent régler seuls tous les problèmes. La réalité est bien différente.

Dans la réalité, chaque personne a son rôle et une expertise à apporter au produit :

Les Data Engineers sont avant tout des développeurs. Leurs principales missions ? Concevoir le Data Lake de l’entreprise, maintenir l’environnement technique et intégrer les différents flux de données pour permettre aux Data Scientists de les utiliser. Ils garantissent aussi une plateforme performante, à jour et fiable. Leurs forces sont avant tout la conception et l’architecture, il n’est alors pas demandé d’être expert en Machine Learning.

Les Data Scientists utilisent principalement les mathématiques. Sur la base de nombreux exemples, ils apportent un autre angle de vue pour résoudre les problèmes métiers (ex. : moteur de recommandations de produit, détection de la fraude, détection d’attrition, etc.). Entre l’analyse des données et le développement logiciel, ils appliquent leurs connaissances en programmation et en algorithmique sur les données, potentiellement avec des grands volumes.

 

Ces deux profils ne détiennent pas les mêmes compétences même s’ils travaillent généralement sur un environnement Big data. Des T-shapes génériques mettent en exergue un recouvrement :

Fig 1 : T-shapes génériques du Data Scientist et Data Engineer

 

Les « Connaissances » du Data Engineers sont les « Expertises » du Data Scientists et inversement. Il existe bel et bien un recouvrement. Cependant celui-ci n’est pas complet, certaines zones ne sont pas recouvertes. Voilà pourquoi, seule une bonne collaboration permet de réaliser avec qualité l’ensemble du travail.

Des intérêts différents, un objectif commun

Ces deux équipiers ne partagent pas les mêmes intérêts, en termes d’outils, d’organisation ou de convictions techniques. Lorsqu’on prend un peu de hauteur, des besoins et des objectifs communs sont identifiables. Un use case pourrait voir le jour en production sans une collaboration entre les deux profils, mais le résultat pourrait manquer de performance. A l’instar des organisations d’il y a quelques dizaines d’années, créer des silos par expertise revient à favoriser une organisation souvent peu efficace. Cela se traduit par des modèles non performants ou qui ne voit jamais la mise en production.

Fig 2 : Complémentarité du Data Scientist et Data Engineer

 

Sans l’un des trois éléments centraux (Le Data Scientist, Le Data Engineer et l’environnement Data), la mise en production des use cases performants en Data Science est impossible. Malheureusement on observe souvent le même constat : cette complémentarité essentielle n’est que partiellement comprise.

Si les entreprises entendent le besoin de faire travailler ensemble, Data Scientist et Data Enginner, la plupart ne sont pas en mesure d’organiser cette complémentarité harmonieuse, de comprendre l’apport et évaluer le ROI. Dans ces conditions, mixer les profils n’est alors pas souhaité par les sociétés. Du fait de cette incompréhension, les équipes ne libèrent pas leur potentiel. Elles s’empêchent donc d’utiliser la Data comme un réel vecteur d’innovation.

Si les deux personnes savent développer, les attentes envers chacun d’eux ne sont pas du tout les mêmes. On demande à un Data Engineer d’être un développeur craft capable de créer un code maintenable, évolutif dans le temps et le tout industrialisé. Et on attend du Data Scientist qu’il valorise les données du Data Lake en développant sous notebooks ou IDE des algorithmes. Pourtant, ce dernier, sans les compétences du Data Engineer ne peut pas forcément coder proprement (voir un résumé du livre Clean code) et livrer facilement un produit maintenable. A l’inverse, un Data Engineer est capable de créer des modèles simplistes basés principalement sur des règles métiers. Il ne sait probablement pas optimiser le modèle de Deep Learning ou choisir la meilleure architecture du réseau afin d’obtenir des performances accrues.

Les deux rôles sont bel et bien complémentaires. Cette union permet d’aller plus loin tout et favoriser la qualité.

Le clivage compromet les entreprises

Malheureusement, de nombreuses entreprises continuent de croire en la séparation de ces deux rôles. D’un côté, la DSI avec les Data Engineers et de l’autre, le Marketing avec les Data Scientists. Ce clivage créé par les organisations favorise l’inefficacité, l’imperfection et l’incompréhension.

En conséquence, les Data Scientists reclus déclarent souvent la plateforme comme insuffisante avec une fraicheur des données parfois inadaptée. Les entreprises se contentent d’utiliser la puissance du Big Data et de la Data Science pour faire du reporting de luxe sur l’activité ou les clients. L’autre option, pas moins triste, est de voir des tentatives de notebooks en production. Certains comme Netflix arrivent à conserver l’industrialisation et les outils d’intégration continue avec des notebooks en production (voir article : Scheduling Notebooks at Netflix). Attention. En dehors de quelques cas particuliers, la plus grande partie des tentatives reste un échec dû à un manque de maîtrise et de qualité logicielle. Les notebooks sont de bonnes solutions pour explorer mais ne sont ni pérennes, ni maintenables. Il est alors préférable de ne pas les laisser interagir avec d’autres systèmes. Seule la version industrialisée (versionnée, packagée et suivant la chaine de déploiement) du code peut obtenir sa place dans l’écosystème de production.

Les Data Engineers isolés constatent, quant à eux, que de nombreux notebooks consomment la majorité des ressources du cluster mutualisé. Cette surcharge provoque parfois des deadlocks au sein de leurs propres applications. Les Data Scientists ne sont ainsi pas considérés comme aptes à utiliser cette plateforme. La potentielle future entraide en est alors entachée.

Si par chance ces problèmes n’arrivent pas, au bout de quelques semestres le management observe la situation suivante : Le nombre de use cases en production est faible voire nul. Seuls des fichiers PowerPoint voient tristement le jour. L’avenir de la Data Science est alors compromis au sein de l’entreprise.

Que devons-nous alors faire ?

L’agilité s’applique particulièrement bien à la Data Science : nous avançons grâce à l’apprentissage. Échouer au plus vite puis rebondir est plus efficace que de construire des modèles trop complexes. Le feedback est primordial. On confronte les réalisations le plus souvent possible (au plus tard aux revues de sprint) à la réalité pour entrer dans une démarche de co-construction.

Aller en production

La Data Science a pour vocation d’être mise en production pour interagir directement avec les autres systèmes. Elle contribue à un outil décisionnel, une solution d’émission d’e-mails ou à un système de push sur les smartphones. Cette expertise ne doit pas exclusivement se conclure par des fichiers PowerPoint appelants des actions manuelles. La présentation des résultats sous cette forme peut en revanche être une étape transitoire de courte durée (quelques sprints).

Travailler ensemble

L’importance de travailler ensemble est compris. Il est alors temps d’évoluer. Les managers ne doivent plus entendre mais comprendre ce besoin. Peu importe le rattachement hiérarchique ou l’expertise, rapprocher géographiquement les personnes est un bon début. Data Scientists et Data Engineers dans un même bureau, le tout accompagné d’un Product Owner volontaire. La finalité du use case est ainsi adressée par la collaboration dès le début du projet.

Itérer sur le produit

Pour avancer sur la roadmap produit, des itérations sont à mettre en place :

  1. Préparer les données et mettre en place la CI/CD
  2. Créer un première modèle très naïf (potentiellement basé sur des règles métiers) et construire la chaine d’activation pour publier les prédictions aux applications tierces

Itérer vers un modèle plus complexe et mettre en place les moyens de récupération du feedback des utilisateurs (ex. : les utilisateurs indiquent si le modèle a fait une mauvaise prédiction afin de l’affiner)

Fig3 : Cycle de vie d’un produit Data Science

Obtenir de l’espace pour apprendre

Enfin on incite le management à favoriser la qualité et donner l’espace aux équipiers pour partager leurs apprentissages. Les Data Scientists et Data Engineers doivent maximiser le pair programming, les revues de code ou encore le mob programming. Ensemble, ils partagent leurs objectifs, contraintes et difficultés. Ils peuvent mettre en place les bonnes pratiques : utiliser un seul notebook à la fois lorsque les ressources sont partagées, éviter dans certains cas les montées intensives des données en mémoire ou encore limiter les ressources utilisées par chaque notebook.

 

Faire travailler les Data Scientists avec les Data Engineers, peu importe le positionnement dans l’entreprise, n’est plus une option. C’est une nécessité pour faire un pas vers la Data Science en production.

 

Cet article est le fruit de projets Studio, d’échanges lors des formations ou encore de lectures. Pour aller plus loin, je vous encourage à lire cet article Data engineers vs data scientists, l’une de mes sources de réflexion.

 

 

Publié par

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.