My Money Bank est une banque experte sur le marché du financement en France métropolitaine et en Outremer, et qui a pour ambition de faire de sa banque une plateforme de croissance en Europe. La banque a lancé le projet Datahub en 2018, avec pour objectif de rationaliser le traitement de la donnée au sein de My Money Group, de façon plus efficace, sécurisée, et afin de capitaliser sur les différents usages possibles de la donnée.

Vincent Geoffray, IT Operations Manager, et Cyril Pino, IT Manager chez My Money Bank, retracent avec nous l’historique de ce projet et de ses enjeux, depuis sa V1 basée sur Kafka, jusqu’à sa V2 composée de services managés AWS, aujourd’hui en production.

Pouvez-vous présenter le contexte du projet Datahub ?

Le projet Datahub a pour objectif de rationaliser le traitement de la donnée au sein de My Money Group, de façon plus efficace, sécurisée, et afin de capitaliser sur les différents usages possibles de la donnée.

Notre premier objectif était de sortir d’une logique d’échange de données de point à point pour la transmettre entre les différents systèmes d’information de la façon la plus découplée possible. Nous avons donc mis en place un système où la production de la donnée est dissociée de la façon dont elle est consommée. Le Datahub produit et publie les données de façon événementielle, en mode publish/suscribe, de façon à être disponible pour tout consommateur qui en aurait besoin à l’avenir, et pour des cas d’usage qui ne sont pas encore identifiés aujourd’hui.

Quels ont été les premiers choix techniques pour ce projet ?

Nous avons choisi Kafka pour lancer ce projet d’urbanisation de notre infrastructure. Et afin de profiter du fait que toutes nos données allaient passer par ce tuyau unique, nous avons décidé de les stocker dans un datalake, pour développer ensuite de nouveaux cas d’usage. La première version du Datahub a été livrée en 2018. Nous avions pour cible une solution Cloud, mais en IaaS, avec nos propres clusters Hadoop, déployés sur des instances EC2.

Nous utilisions AWS comme simple hébergeur des VM, provisionnées avec Terraform et configurées avec Ansible. Ce choix répondait à notre objectif d’être Cloud indépendant et de pouvoir déployer cette solution quel que soit le provider.

Comment avez-vous ensuite fait évoluer le Datahub ?

Après 18 mois de développement pour gérer la suite Hadoop par nous-mêmes, nous avons constaté que l’équipe nécessaire pour maintenir une telle infrastructure en IaaS était bien plus conséquente que ce que nous pouvions engager. Les délais de mise en œuvre étaient longs, et nous étions sur le chemin critique d’un grand projet de transformation.

Nous avons donc étudié une autre solution, pour passer du Datahub V1 qui n’avait jamais connu la production, à une V2 composée de services managés AWS. Notre objectif était de réduire la complexité de la plateforme, et donc le nombre de ressources nécessaires pour la déployer et la maintenir. Nous avons donc choisi d’aller vers un assemblage de services AWS, pour ne plus avoir à micro manager notre infrastructure. Le point critique n’était plus d’être transportable dans un autre Cloud, mais d’avoir une solution disponible et prête à créer de la valeur.

Nous avons donc mené un POC, avant de faire une première release en MVP. En moins de trois mois, nous avons pu déployer une recette stable : nous avons plus avancé durant cette période que pendant les 18 mois passés sur la V1. Nous avons donc stoppé la V1, nous n’avions tout simplement pas assez de compétences en interne pour gérer et manager des clusters, sans parler des enjeux de sécurité posés par ce type d’infrastructure. Une solution basée sur des services AWS à plus haute valeur ajoutée était plus coûteuse que notre V1, mais nous avons bénéficié de l’expertise d’AWS sur le tuning des clusters, ce qui a facilité le déploiement et nous a permis d’engager moins de moyens humains. Nous avons pu déployer notre premier cluster EMR en quelques jours, un résultat incroyable au vu de notre précédente expérience. Ensuite, quelques semaines ont suffi pour sécuriser le cluster avec des certificats d’authentification. Nous avons dû pivoter sur certains éléments pour adapter notre solution, réinventer la couche entre les différentes briques AWS, avec des lambdas notamment, mais nous avions une solution iso fonctionnelle, sortie très rapidement, évolutive selon nos besoins, et que nous comprenions. Ce fut un grand succès.

A quel moment avez-vous sollicité l’accompagnement de Devoteam Revolve ?

Nous avons fait appel à Devoteam Revolve au moment où nous avons voulu industrialiser la v2. Armand a commencé à travailler avec nous pour nous aider à déployer entièrement en infra as code, de façon à pouvoir reproduire ce qu’on allait faire en UAT sur d’autres environnements. Pour ce faire, il y avait beaucoup de code à produire, et l’expertise de Devoteam Revolve sur le développement de briques AWS avec Terraform s’est révélée cruciale pour nous. Nous avons pu avancer rapidement sur des sujets pointus, des requis de sécurité, de configuration, d’application de droits restreints sur le datalake, avec des policy très fines et du least privilege. Nous avions besoin d’une expertise sur le fonctionnement d’IAM, et nous avons constaté que les équipes de Devoteam Revolve maîtrisaient ces sujets, elles ont les compétences et l’expérience nécessaires pour bien faire le design de ces solutions. Nous avons rapidement sécurisé la solution, puis nous avons continué à ajouter des fonctionnalités en mode agile.

Quels sont les services AWS utilisés dans cette nouvelle version ?

Nous utilisons principalement MSK, le service managé Kafka, AWS Lambda, des bases de données RDS, des buckets S3 pour le Datalake, et plusieurs clusters EMR.

Comment a évolué la collaboration avec Devoteam Revolve ?

Si les consultants de Devoteam Revolve n’ont pas travaillé sur la partie ingestion, ils ont par contre contribué au développement de nouvelles fonctionnalités à base de services AWS, sujet sur lequel ils nous apportent une expertise précieuse. Ce qui était intéressant est que les consultants Devoteam Revolve étaient vraiment intégrés dans l’équipe, on ne les voyait pas comme des externes. Ce qui devait être au départ une mission sur 3 mois s’est transformé en un accompagnement de 2 ans, et aujourd’hui nous continuons à construire et faire évoluer cette plateforme avec Devoteam Revolve.

Au départ, nous avons surtout sollicité Devoteam Revolve pour des compétences Ops et DevOps. Au fur et à mesure du développement de la plateforme, nous avons eu des besoins croissants sur la partie développement et la Data Science, et Devoteam Revolve a élargi sa gamme de services autour de la Data, avec des profils experts sur ces sujets. Erwan par exemple a un fort background de développement, mais il sait également travailler sur la partie MLOps. De fait, les contributeurs Devoteam Revolve nous aident maintenant à développer les usages autour de la Data Science.

C’est notre prochain challenge, nous avons automatisé et industrialisé la plateforme, traité nos usages primordiaux, maintenant nous voulons développer de nouveaux cas d’usage et rechercher de la valeur ajoutée dans le potentiel de data de l’entreprise.

Quels sont les challenges de cette couche Data Science ?

Nous n’en sommes qu’au tout début, il y a beaucoup de possibilités, de très nombreux services du côté AWS, et pour cela nous apprécions le conseil des équipes Devoteam Revolve pour faire les choix les plus adaptés à nos usages. La particularité de ce domaine, c’est qu’il évolue très vite, et le bon choix aujourd’hui ne sera peut-être plus pertinent dans 3 mois. La capacité à se remettre en question et à pouvoir faire évoluer rapidement notre solution est cruciale. Les consultants de Devoteam Revolve nous apportent une vision critique des services AWS, on voit que leur veille fonctionne bien, et nos échanges nous permettent de nous adapter rapidement. Les évolutions sont nombreuses, et fréquentes : parfois pour améliorer la sécurité, parfois pour augmenter le niveau de service d’une solution, ou mettre en place du finops pour optimiser les coûts.

Le finops fait partie intégrante de notre façon de travailler au même titre que la sécurité, nos développeurs infra ont aussi des compétences Scala/Sparks, sécurité et FinOps. De fait, il est compliqué de trouver des gens qui s’intègrent dans cette équipe multi-casquettes. C’est un challenge, et Devoteam Revolve arrive à nous accompagner sur tous ces aspects.

Pour résumer, quelle est la plus value de l’accompagnement Devoteam Revolve ?

Quand on recherche des profils avec une forte valeur ajoutée, le plus souvent on trouve des experts qui sont très spécialisés. Ils n’apportent de l’expertise que sur un domaine, et nous devons donc superposer plusieurs profils avec des compétences très spécifiques. Cela amène une complexité dans la gestion du planning et des compétences.

Quand nous proposons des missions à Devoteam Revolve, nous recherchons certes une expertise, mais nous attendons surtout des membres d’une équipe agile, et nous apprécions vraiment que ce soit toujours vu comme une opportunité et non comme une contrainte. Apprendre, découvrir de nouveaux sujets fait partie de l’état d’esprit des consultants Devoteam Revolve. Un Ops pourra se mettre au développement sur Scala si c’est important pour l’équipe et pour le produit, et cela nous apporte une vraie facilité de gestion. Cela fait partie de la valeur ajoutée de Devoteam Revolve, ils sont très ouverts sur la technologie, et toujours prêts à apprendre de nouvelles choses pour le bon fonctionnement de l’équipe.

Quelles sont les prochaines étapes ?

Les prochains challenges à relever sont la Data Science et la Data visualisation, nous voulons pouvoir mettre à disposition des utilisateurs finaux des outils pour faire leur reporting de façon autonome, en explorant la donnée sur différentes périodes d’historique.