Interview du Datalab de BNPP PF : Construisez votre plateforme de datascience interne !
Le 10 mai dernier, nous sommes allés interviewer Jérémie Guez, Responsable du Data Lab de BNP Paribas Personal Finance sur le site de Unicity à Levallois.
Construire sa propre plateforme de data science…? Eux, ils l’ont fait ! Elle s’appelle Sparrow.
OCTO a réalisé le premier POC de son architecture. Depuis, ça a généré plusieurs pratiques auxquelles OCTO croit et souhaite mettre en valeur sur son Blog.
Retour sur son interview :
Bonjour Jérémie, avant de commencer peux-tu te présenter ?
Bonjour, Jérémie Guez, Responsable du Data Lab de BNPP PF depuis janvier 2019.
J’ai fait des études autour des mathématiques appliquées et des statistiques à l’Université Paris-Dauphine, et une année de spécialisation à Telecom Paris.
En mai 2017, j’ai rejoint l’équipe du data lab de PF en tant qu’interne. Initialement, je suis issu du monde des startups où je traitais des sujets de machine learning et de NLP.
La plateforme de data science Sparrow s’est lancée 3 mois avant mon arrivée.
Peux-tu nous dire quel périmètre Sparrow couvre ?
L’objectif de Sparrow à la base était de faire de la data science et de la veille tech. Il n’y avait pas d’écosystème qui le permettait chez BNPP PF, ni de lieu où être agile pour installer les packages, travailler facilement et rapidement.
Sparrow, c’est faire du POC, de l’exploration, pas de l’industrialisation. La partie exploratoire reste libre, c’est une place à l’innovation. L’outil est très reconnu en interne et adopté par les autres équipes.
Sparrow contient aussi les données ?
Sparrow n’est pas directement connecté à nos base de données. L’objectif reste de faire de l’exploration. Nous mettons donc à disposition les données nécessaires à l’étude. Une fois l’étude terminée, on décide de passer ou non dans une phase d’industrialisation. Dans tous les cas, les données sont supprimées après la phase d’exploration.
On fait principalement de l’intégration par batch quotidien : ça couvre la plupart des cas d’usage et ça suffit pour de l’exploration. On peut bien sûr intégrer la donnée au fil de l’eau au cas par cas si nécessaire.
Construire en interne votre propre plateforme de data science, c’est une initiative rare dans les Data Labs...
En fait nous avons lancé cette initiative il y a quelques années déjà, à une époque où le marché des plateformes de data science n’était pas très mature. Investir dans le développement de notre propre plateforme était donc logique, surtout dans une optique de maîtrise des budgets.
Lorsqu’on investit dans une offre d’éditeur, on est obligé d’avoir un investissement massif dès le départ pour en tirer des bénéfices. Au contraire, en construisant notre plateforme nous avons pu avoir des investissements plus faibles mais plus réguliers, au fur et à mesure de notre maîtrise des différentes étapes vers l’IA en production. C’était d’autant plus intéressant que ça laissait le temps au marché de se stabiliser, et il serait toujours temps plus tard d’investir dans une offre éditeur si le besoin s’en faisait sentir.
Ce que nous n’avions pas anticipé était le bénéfice que nous avons tiré de cette démarche. Avoir la maîtrise technique de notre plateforme (code, propriété intellectuelle, SLA, etc.), des capacités de réversibilité, une transparence sur ce qui s’y exécute est une vrai plus-value. Et ça nous a apporté des compétences en interne, notamment DevOps, ce qui est un avantage fort à l’heure de l’industrialisation de l’IA.
Aujourd’hui, si c’était à refaire, c’est surtout ce facteur de montée en compétences qui nous ferait reprendre la même décision.
Tu dirais que les data scientists du Data Lab sont devenus experts DevOps ?
Non, mais au moins aujourd’hui ils peuvent parler le même langage avec les experts. Ce qu’ils ont acquis est une sensibilité aux problématiques de déploiement et de production : quand ils accompagnent les BUs, ils peuvent les aider à penser directement aux bonnes pratiques pour la mise en production à venir.
L’équipe apprend beaucoup sur l’infrastructure, le packaging et l’industrialisation dans la construction de Sparrow.
L’équipe Data Lab a de vraies compétences autour de l’architecture et du DevOps. Ce savoir-faire est déjà un différenciant énorme et justifie en soi d’avoir conçu notre propre plateforme. Le niveau de maturité sur ces sujets est donc différent des data scientists des lignes métiers.
Quelles difficultés a rencontré l’équipe ?
Les data scientists de l’équipe ont eu du mal à prendre le double rôle de data scientists et de devops / exploitant de la plateforme. Ils avaient envie de se concentrer davantage sur la partie data science.
J’ai donc essayé de montrer à l’équipe qu’ils étaient en train d’acquérir des compétences DevOps très rares pour des data scientists.
Quels ont été les facteurs d’adoption de la plateforme en interne ?
- Le prix : Pas de coûts de licence, pas de coût d’installation
- Pas de problème de confidentialité, les données restent chez BNPP
- Ce n’est pas une blackbox, tous les composants sont maîtrisés par le Data Lab
- L’ambition : on ne va pas forcément faire mieux, mais on veut devenir une alternative légitime à un Dataiku ou Domino DataLab
- L’équipe a mis en place des MOOCs sur Sparrow pour l’onboarding des utilisateurs
Le vrai facteur de réussite est le côté self-service de la plateforme. Le métier a accès à son environnement Sparrow en quelques heures (maximum) à partir du moment où il a une machine disponible.
C’est une belle histoire… mais, vous avez forcément eu des moments de doute ?
Oui bien sûr, au départ la vision de tout ce qu’on allait devoir faire et apprendre en Ops nous a effrayé. Ce n’était pas le mandat initial, mais avec mon passé, j’ai tenté de donner une orientation “produit” à Sparrow : “je le propose à mes clients, je l’améliore continuellement”. On s’est tous raccroché à cette vision pour mettre le focus sur ce qui est important et ne pas attaquer 36 chantiers en même temps !
Ensuite quand le succès a commencé à arriver et que le nombre d’utilisateurs grandissait, on a eu une charge de support très importante et beaucoup de pression pour trouver la solution : on avait clairement sous-estimé le run.
La solution : refondre la plateforme et faire une v2 de Sparrow. On la pense plus grande, on prend en compte une multitude d’utilisateurs et on automatise au maximum le support et le self-service. Par exemple, on a mis en place un chatbot pour le support de niveau 1.
Et si c’était à refaire... Tu préconiserais de partir sur du build ou du buy ?
Tout dépend de la maturité de la donnée et de la taille de l’entreprise.
Dans le cas d’une petite entreprise, l’achat d’une plateforme peut être bénéfique.
Chez BNPP PF, la stratégie est différente, ce n’est pas concevable de mettre de la data bancaire dans le cloud public, même si le hardware reste plus puissant, stable et rapide.
Sparrow, c’est 140 utilisateurs, une centaine de projets à l’étude, plus de 300 conteneurs up simultanément. Pour ce niveau d’utilisation, les coûts de licence d’une plateforme éditeur seraient trop chers.
Tu mentionnais tout à l’heure que Sparrow était une plateforme d’exploration et pas de production. À l’heure où tout le monde parle de machine learning en production, ce n’est pas un peu étrange ?
On a bien sûr l’objectif d’aller en production. En revanche, on considère que ce n’est pas le rôle de Sparrow. On fait une distinction nette entre ce qui relève de l’exploration et ce qui relève du passage en production.
Pour la partie “exploration”, notre enjeu est de mettre la donnée et des environnements à disposition des data scientists très rapidement, avec un accompagnement à l’usage et une veille en parallèle pour proposer les dernières technologies pertinentes. C’est là où Sparrow intervient.
Pour la partie mise en production, nous avons une infrastructure dédiée et un pipeline très spécifique qui nous a permis d’industrialiser nos premiers scores.
Et donc, la mise en production se passe complètement hors de la plateforme ?
Oui. En tant que tech, je trouve qu’il manque beaucoup de choses sur les plateformes de data science pour aller en production : packaging, linting, etc. On voit qu’elle sont orientées davantage exploration.
Du coup on a pris le parti de gérer cette partie à côté. L’industrialisation se fait dans un projet “classique” auquel prennent part les data scientists côté métiers. Ils sont accompagnés par les data scientists du Data Lab, et on donne des guidelines de développement et de packaging pour faciliter la transition exploration / production.
On voit d’ailleurs que nos pratiques commencent à essaimer en interne. Les métiers ont commencé à recruter des profils DevOps. C’est un bénéfice indirect qui vient du fait de développer sa propre plateforme…
Dans ce cas, quelle est la proposition de valeur de Sparrow ?
Elle est multiple, et à destination des BU :
- Accès aux données & gestion des droits
- Environnements facilement accessibles avec les technos nécessaires (indispensables pour les data scientists)
- Self-service et onboarding facile
- On fait une veille technologique en parallèle pour les aider et défricher les nouveaux sujets techniques
Au final, on les aide à explorer et à se mettre dans les meilleures conditions pour aller en production par la suite, mais ce dernier point reste dans leur périmètre.
Et alors quelle place pour les data scientists du Data Lab si ce sont les métiers qui font l’exploration ?
On a trouvé une répartition des rôles entre l’IT et le métier : exploration “générale” et exploration “focus métier”. Les personnes qui font du design de data science et celles qui industrialisent n’ont pas les mêmes profils.
Ensuite, au niveau de notre équipe Sparrow, on s’est séparé en 2 équipes.
- 1 pôle ML
- 1 pôle plateforme
Par ailleurs, grâce à l’expertise que le Data Lab a développé autour du NLP, chatbots et moteurs de recherche, nos data scientists ont créé des liens et acquis une certaine légitimité. Ce sont des sujets transverses en complémentarité avec le savoir faire des métiers.
Si tu devais résumer la clef du succès de Sparrow ?
C’est la data science et une proximité très forte entre les 2 pôles ML et plateforme grâce à leur colocalisation.
Un mot pour conclure ?
Tout d’abord un grand merci aux équipes du Data Lab et aux personnes qui ont collaboré depuis 2 ans avec nous. Le collectif est au centre de notre réussite, il est primordial d’y associer toutes les parties prenantes. Quelque soit les projets, le meilleur moyen d’apprendre et de progresser c’est de sortir de sa zone de confort.
Nous sommes sortis de notre zone de confort en 2017 et aujourd’hui on le regrette pas !