Quel est le quotidien de l’équipe Devoteam Revolve en projet ? Quels sont les challenges techniques à relever et quelles solutions sont apportées ? Derrière une mise en production réussie, un déploiement ou un Proof of Concept, il y a des consultantes et des consultants, une équipe, des technologies et beaucoup d’expertise et d’intelligence collective ! Cette série d’articles vise à vous dévoiler l’envers du décor, à travers leur témoignage.

Peux-tu te présenter ?

Je suis consultant Devoteam Revolve depuis deux ans et demi. J’ai aujourd’hui treize ans d’expérience. J’ai commencé par de l’IT Service Management, puis de l’animation de R&D et de projets Infrastructure, et enfin du conseil Cloud. L’ITSM et les projets Infra m’ont permis de développer une vision transverse de la DSI et des interactions entre métiers qui la composent.

Mes années dans le conseil Cloud m’ont donné ma culture AWS, et la conviction que le Cloud public est la seule et unique manière de tirer les bénéfices du Cloud. Puis je me suis formé en Data Science et Machine Learning, et j’ai rejoint Devoteam Revolve pour travailler sur ces sujets, la data sur le Cloud.

Quelles sont tes missions au quotidien ?

Je fais principalement de la gestion de projet (delivery management). J’interviens sur plusieurs axes : cadrage des besoins, discussion avec le client et les équipes techniques pour comprendre les enjeux, les priorités, les “pain points”, afin de comprendre ce qu’on devrait faire et de quelle manière. Je travaille à la mise en place de l’équipe et son organisation pour livrer le produit ou la solution, puis le pilotage et l’animation de l’équipe.

J’interviens aussi dans les relations entre différentes équipes ou métiers : sécurité, architecture, décideurs, ingénierie… afin de faire du lien entre les différents acteurs.

Sur quel sujet travailles-tu actuellement ?

J’effectue une mission de conseil dont l’objectif est de dresser l’état des lieux d’une plateforme Data, afin d’établir les options de réversibilité possibles vers du “On Premise” ou une autre fournisseur de Cloud public. Il s’agit de voir dans quelle mesure le choix du fournisseur AWS peut être remis en cause, et mesurer l’effort pour éventuellement évoluer vers un autre provider. J’ai travaillé sur cette mission avec deux autres consultants de Devoteam Revolve, et j’étais chargé de l’analyse de l’architecture, de l’analyse des données et de la synthèse. Cette mission a impliqué de nombreux ateliers pour compléter l’information, échanger avec l’équipe en charge de la plateforme, les architectes et ops qui gèrent les plateformes cible envisagées. 

Dans un premier temps, nous avons mené une analyse de l’existant, et évalué les différentes plateformes : quelles sont les fonctionnalités ? Quels écarts entre une solution AWS, Azure ou on premise ? L’idée est de faire un état des lieux neutre, puis de conduire des ateliers pour se projeter sur l’architecture cible.  Nous avons collecté des données pour objectiver les ressentis, et pour chaque service, chaque brique, pouvoir qualifier et quantifier l’effort à fournir et la stratégie de migration. L’analyse produite a permis de chiffrer et planifier au niveau macro ce projet de réversibilité.

Est ce simple de faire de la réversibilité sur le Cloud sur des projets data ?

Ce n’est pas “simple” car ce sont des projets au long court. Sur ce projet, l’étude montre que migrer 50 cas d’usage et un demi peta de données prendrait 12 à 15 mois. Cela peut paraître long, cependant nous avons pu conclure que migrer de AWS vers Azure reste possible. Il existe des équivalences technologiques qui permettent de l’envisager sereinement. Par contre, la réversibilité vers le “On Premise” est peu envisageable. Les clouds privés sont pauvres en  services, limités à  l’infrastructure as a service. Or la plateforme Data de ce client tire parti de nombreux services data avancés d’AWS : des clusters Hadoop managés, Glue pour faire du Spark sans gérer les clusters, etc.

Tous ces services managés permettent à l’équipe de livrer plus vite de nouvelles fonctionnalités ou de nouveaux cas d’usage aux utilisateurs en réduisant les efforts de Design, de Build et de Run. “On premise” ces services devraient être reconstruits, ce qui signifie partir de zéro, commander des machines, des serveurs, construire des clusters et faire du développement spécifique.

Quelle est notre position en tant que partenaire AWS ?

Nous avons une expertise très forte sur AWS, donc cela influe nécessairement nos préconisations. Ce sont des produits que nous maîtrisons, avec lesquels nous savons bien travailler, mais cela ne nous empêche pas de mener cette étude de réversibilité vers Azure, et de constater que c’est possible. Nous avons à cette occasion travaillé avec les experts Azure de Devoteam M Cloud, cela nous a permis de découvrir plus en profondeur cette offre. Il n’y a pas de biais sur les conclusions, si un jour ce client souhaite partir sur Azure, l’étude montre dans quelles conditions il peut le faire, mais cette migration ne sera pas menée par Devoteam Revolve.

Qu’est-ce que tu penses de l’offre Data sur Azure ?

J’ai découvert lors de cette mission Azure Synapse Analytics. Comme ça l’offre semble plus intégrée que son équivalent chez AWS, qui est réparti sur de nombreux services, des briques élémentaires avec lesquelles on peut tout construire. Azure propose un choix un peu différent, sur le papier cela semble un peu plus cohérent, l’offre est mieux packagée. Cependant, cette offre comporte beaucoup de produits rebrandés ou repackagés. Ce type de réorganisation de catalogue fait qu’il est difficile de suivre les évolutions d’Azure si on n’est pas plongé dans le sujet chaque jour.

Tu travaillais en parallèle sur un autre projet, peux-tu en parler ?

Il s’agit de gestion de projet dans le contexte d’une migration massive vers AWS. Au début de l’année 2020, le client a mené une étude suite à laquelle il a pris la décision de fermer ses deux Datacenters et de migrer tout sur le Cloud AWS. La migration a commencé au deuxième semestre 2020, avec la construction d’une méthodologie pour migrer 5 applications, et la mise en place des équipes. J’ai rejoint le projet durant cette phase, pour travailler avec les Solution Architect dédiés à la migration de chacune de ces applications, et les équipes techniques responsables de ces applications.

La seconde phase du projet s’étend jusqu’à fin 2021 avec le passage à l’échelle et la migration des 250 autres applications, en utilisant la méthodologie définie sur les cinq premières applications. Sur le projet, mon travail consiste à animer la migration des factories, les entités en charge du parc applicatif. Nous travaillons avec ces équipes pour les aider à migrer leur parc, nous les aidons dans le cadencement et l’animation du planning. Nous nous assurons aussi que les pilotes des migrations reçoivent bien les lignes directrices du programme, et dans l’autre sens que les points de blocage soient remontés aux bons interlocuteurs. L’objectif est que la migration soit tenue dans les délais et dans le budget.

Sur quels autres sujets Data as tu travaillé ?

J’ai eu l’occasion de travailler sur plusieurs projets de Data Lake, notamment le déploiement d’un Datalake sur AWS. Récemment, nous avons aussi réalisé un POC sur une solution de Computer vision pour une société de protection. L’objectif était de remplacer le système actuel par une solution de traitement et de filtrage automatisé des vidéos de surveillance. L’analyse des vidéos avec AWS Rekognition visait à réduire le nombre de faux négatifs remontés aux opérateurs. Ce projet nous a permis de tester les solutions de reconnaissance vidéo sur AWS, et d’essayer d’autres approches avec des librairies configurées et déployées manuellement.

Comment le métier de la Data évolue-t-il ?

Le marché évolue très vite. Il y a quelque temps encore, on travaillait presque exclusivement sur des plateformes de Data Ingénierie, dédiées au traitement de l’information et à l’acheminement des données. Aujourd’hui près de la moitié des demandes que nous recevons concernent une plateforme plus globale. La plateforme actuelle contient toujours un Data Lake et un pipeline de données, mais elle inclut aussi une stack Data Science. Ce sont par exemple des outils pour les Data Scientists et les Data Engineers, pour entraîner, préparer les modèles et les faire passer en production. C’était un sujet émergent il y a deux ans, aujourd’hui il représente une part non négligeable des projets sur lesquels nous travaillons.

Est ce que cela change la façon dont on adresse les projets ? Quels sont les points de vigilance ?

On ajoute des couches, donc cela implique de prendre en compte de nombreuses nouvelles problématiques. La partie Data est maintenant un acquis, on ne se pose plus vraiment de questions, on déroule les bonnes pratiques connues en fonction du contexte client.

Sur la Data Science, c’est différent : il y a beaucoup d’expérimentations sur le marché, de gens qui écrivent sur le sujet, des retours d’expérience… l’état de l’art n’est pas encore figé. Le sujet est moins mature que les Datalakes, notre travail sur ces plateformes se situe entre la R&D et l’industrialisation. Nous nous efforçons de synthétiser les bonnes pratiques, de les appliquer dans la plateforme mais aussi l’organisation que nous aidons le client a adopter. C’est une étape transitoire avant plus d’industrialisation. Dans 5 ans, on travaillera différemment, les plateformes ML Ops seront déployées de façon automatisée sur AWS; les pratiques seront harmonisées, et il n’y aura plus d’inconnues sur le “comment faire”. A l’image du DevOps aujourd’hui, les principes ne sont plus à inventer, on a juste à les implémenter correctement. Sur la Data Science, on essaie encore d’identifier les bonnes pratiques. Nous apprenons en même temps que nos clients : ils nous apportent des contextes, des occasions d’apprendre, nous leur apportons nos retours d’expérience acquis sur d’autres projets. C’est vraiment de la co-construction, il faut construire avec les contraintes et les spécificités de l’entreprise, mettre en place la bonne organisation et la bonne plateforme.

Comment a évolué l’équipe Devoteam Revolve ?

Il y a eu une belle croissance de l’équipe en 2020, avec l’arrivée de nouveaux profils et une montée en puissance sur la partie Data Science. Nous avons maintenant du répondant sur ce sujet, et nous pouvons répondre aux besoins de nos clients. Il est plus compliqué d’avoir des Data Engineers seniors, ils sont rares sur le marché.

Quant au “ML Ops”, c’est un poste qui est train de s’inventer : le ML Ops doit comprendre la Data science, la Data Engineering et la maintenance de ces systèmes. Suivant son profil, il sera plus orienté ingénierie ou ops, mais on a besoin des deux. C’est quelqu’un qui va savoir faire le lien entre les contraintes de la plateforme ML, comprendre ce qu’est un entraînement de données, un pipeline de données, un déploiement de modèle. Il connaît aussi les plateformes Data, Spark, le fonctionnement de ces technologies et leurs contraintes. Enfin, il comprend aussi la production, le DevOps, les bonnes pratiques d’automatisation, les pipeline de CI/CD de façon à pouvoir faire évoluer la plateforme et outiller les cas d’usage. Nous avons une position privilégiée car nous avons de bons profils sur ces métiers, Data science, Data engineering et ML Ops. Pour continuer à grandir, nous devons mettre ces gens compétents sur des projets en commun, avoir des espaces de jeu où faire travailler les bons Ops et les bons Data Engineers.

Quelles sont les briques technologiques pour répondre aux problématiques ML ?

Côté AWS, le cœur du réacteur est SageMaker. En deux ans, on est passé d’un ensemble de features intéressantes, mais qui devaient être combinées à d’autres produits pour faire une vraie plateforme ML Ops, à une plateforme complète aujourd’hui. AWS Glue est intégré à l’offre SageMaker, et plus globalement on peut bénéficier de tout l’écosystème Data AWS. Nous travaillons aussi avec des solutions open source comme Kubeflow, qui peut offrir le même type de fonctionnalité et de facilités pour le Data Scientist. Kubeflow s’appuie sur Kubernetes, la solution peut donc être adaptée à certains contextes clients.

Autour de ça, on fait graviter un certain nombre d’outils open source comme DVC, ML Flow, Delta (Databricks) pour répondre à des problèmes non traités par les outils coeur. Aujourd’hui la plateforme ML Ops est composée d’un cœur comme SageMaker, Kubeflow, ou une solution Google ou Azure, customisée et intégrée à d’autres “petits” outils pour couvrir l’ensemble des besoins.

Pour terminer, qu’est-ce que tu apprécies chez Devoteam Revolve ?

Je suis très satisfait de mon expérience chez Devoteam Revolve, j’ai trouvé beaucoup de sujets qui m’intéressent. En particulier, j’apprécie la liberté d’initiative – je n’ai jamais été censuré dans ce que j’ai pu proposer en tant que consultant. Si on a envie d’explorer un sujet, on peut y mettre un peu d’énergie, l’initiative est toujours bienvenue et bien accueillie, et si on arrive à convaincre on obtient un support en termes de moyens, et donc de temps. C’est ce qui fait que j’ai pu travailler avec la communauté Data, la faire grandir, travailler avec des gens en transverse quand on n’a pas de mission en commun. Je profite aussi de la forte expertise technique et de l’esprit d’entraide des consultants Devoteam Revolve. Quand on a une problématique, il y a du répondant et un vrai partage de connaissances et compétences.