La difficile valorisation des projets de MLOps

Dans un monde numérique bouleversé par une digitalisation généralisée, les entreprises font de plus en plus appel aux nouvelles technologies afin d’augmenter leur efficacité. Les Nouvelles Technologies d’Information et de Communication (NTIC) s’intègrent progressivement depuis les années 70 avec, par exemple, l’apparition des micro-ordinateurs, puis plus fortement à la fin du XX^e siècle avec l’utilisation d’internet et des courriers électroniques. Plus récemment, les entreprises profitent d’outils ERP (Enterprise Ressource Planning) pour faciliter leur gestion, ou encore s’appuient sur des objets connectés pour suivre, harmoniser et automatiser leurs activités.

Ces nouveautés génèrent de très nombreuses données devenant ainsi le nouvel or noir du numérique. Les entreprises ont à leur disposition de nombreuses solutions permettant de les valoriser : « modern Datawarehouse », Business Intelligence, Data Viz, etc. Les domaines d’applications sont nombreux et touchent tous les secteurs. En particulier, sur la base de ces données, il devient ainsi possible de mettre en place des analyses descriptives, diagnostiques, prédictives, voire prescriptives. Ce type d’approche mobilise très souvent des solutions basées sur le Machine Learning qui a suscité un fort engouement ces dernières années.

En effet, selon une étude de NewVantage Partners, on observe que 55% des 65 entreprises de FORTUNE 1000 ont investi en 2019 au moins 50 millions de dollars dans des projets Big Data et IA. Cependant, aux vues des investissements des entreprises dans ce domaine, il est inacceptable de constater que – selon Gartner – jusqu’en 2020 seulement 13% des projets de Machine Learning ont été industrialisés.

Pour expliquer ce paradoxe, Saegus a étudié les nombreux freins à l’épanouissement de la Science des Données dans les organisations : la délicate gestion des Data Scientists, un usage sous-optimal des ressources (outils, données et humaines), des enjeux culturels ralentissant l’adoption de la culture Data par toutes les parties prenantes, etc. Tous ces facteurs contribuent à la dégradation de la rentabilité des initiatives en Sciences des Données (voir notre article correspondant). Parmi ces freins, l’opérationnalisation des modèles constitue une difficulté majeure. Autrement dit, le grand enjeu que rencontre cette discipline est la mise en production des solutions de ML et tout ce que cela implique. Par analogie, cet enjeu est comparable à ceux de la culture DevOps qui est présentée plus en détail dans la suite de l’article.

Zoom sur le DevOps

Les problèmes de l’ancien modèle

Comme décrit dans la précédente section, depuis l’émergence de l’informatique, les entreprises s’appuient massivement sur les outils et les services liés au numérique, secteur en perpétuelle évolution. Le déploiement de ces derniers est complexe, voire problématique et nécessite une méthodologie élaborée. Par exemple, en génie logiciel, 66% des projets dépassent le budget et un tiers des projets ne tiennent pas les délais selon une étude de McKinsey & Oxford. Avant l’apparition du DevOps, comme nous pouvons le voir sur le schéma ci-dessous, deux équipes indépendantes intervenaient lors de la création de nouveaux produits digitaux. Une équipe de développement se chargeait de collecter les besoins métiers et de développer le produit, puis de tester le bon fonctionnement de celui-ci. S’il était conforme aux attentes, une autre équipe « opérationnelle » prenait le relais et assurait son exploitation dans un environnement de production.

Cette approche pose de nombreux problèmes. Tout d’abord, la présence de deux équipes a divisé les responsabilités et a créé des objectifs antagonistes. L’équipe de développement a pour objectif de modifier et faire évoluer l’application le plus rapidement pour suivre les exigences et les besoins des utilisateurs. Elle corrige les bugs, et ajoute de nouvelles fonctionnalités – parfois dans un délai court, tentant de minimiser les coûts et en n’attachant pas toujours une priorité maximale à la qualité. L’équipe des opérationnels assure le maintien de l’application et garantie sa stabilité et sa qualité. Pour cela, elle utilisera plus de temps et augmentera le coût nécessaire pour le déploiement d’une nouvelle version. Cette dissonance de priorité et d’objectifs peut entraîner des blocages et des allers-retours entre les deux équipes, ayant des conséquences néfastes sur le projet.

De plus, il arrive qu’il y ait peu de communications continues entre les deux équipes sur les problèmes rencontrés et les besoins changeants. Pour être performante, l’entreprise doit déployer sa solution le plus rapidement possible. Celle-ci présentera par la suite de nombreuses mises à jour permettant de corriger les bugs et d’améliorer le contenu. Le manque de communication pénalise le rythme de développement et d’exploitation de tels projets, rendant la surveillance et le déploiement des applications ardus, alimentant ainsi le risque de blocages.

Pour résoudre les dysfonctionnements de cette approche, la méthodologie du « DevOps » est apparue en 2007, imaginée par Patrick Debois.

Qu’est-ce que le DevOps ?

Le DevOps est avant tout une philosophie qui permet aux entreprises d’évoluer vers une approche dynamique orientée client pour le développement et la livraison de leurs applications, complétée par un contrôle de la qualité de la production irréprochable. Ainsi, les nouvelles évolutions sont intégrées et déployées continument et itérativement sur tout le cycle de vie du projet. La conception et la gestion du cadre d’opération des solutions sont traitées tout au long du projet, des prémices lors de la phase de cadrage jusqu’à la surveillance post-production. Cette méthodologie permet à l’entreprise de gagner en agilité et d’accélérer le « Time to Market » des produits. Pour cela, elle combine les compétences entre les équipes de « développement » et « opérationnelles » autrefois séparées, qui suivront des principes communs :

• Culture : améliorer les attitudes de l’entreprise au service du développement
• Automatisation : automatiser le plus possible les différentes procédures
• Lean : optimiser l’utilisation des ressources afin de diminuer les coûts
• Mesure : localiser rapidement les erreurs, analyser le comportement des utilisateurs en mettant en place des remontées d’informations efficaces
• Testing : mise en place de nombreux tests (unitaires, fonctionnels, d’intégration) garantissant le bon déroulement des développements itératifs
• Partage : mieux communiquer entre les équipes sur les problèmes et les améliorations possibles de l’application

Les composantes du DevOps sont présentées dans le schéma ci-dessous. Les deux équipes « Dev » et « Ops » sont imbriquées et partagent un même cycle sur lequel les différents segments du DevOps se suivent chronologiquement. Sa représentation, sous la forme du symbole de l’infini, témoigne d’une logique d’itération dans le temps : à la fin d’un cycle, un autre redémarre.

Grâce à l’automatisation des tâches, le DevOps fluidifie et accélère les interactions entre les parties prenantes du projet, ce qui supprime les temps morts. Le déploiement continu associé à l’automatisation des tests accélèrent le développement. Ces gains de temps provoquent mécaniquement une réduction des coûts et accélèrent la mise à disposition de l’application.

Un métier pluridisciplinaire a émergé de cette philosophie : l’ingénieur DevOps. Tout d’abord, il doit posséder des compétences techniques de développement et d’exploitation de logiciel. Il présente également une expertise sur de nombreux outils spécifiques au DevOps.  Il doit également faire preuve de compétences « humaines » : il sait prendre du recul pour comprendre le point de vue des autres, et en faire la synthèse afin de mener à bien le projet.

Généralisation de la culture “Ops”

De nouveaux besoins

Ainsi, cette culture Ops s’est développée en réponse aux besoins rencontrés lors du développement logiciel et d’applications. De nos jours, ces solutions sont souvent constituées de nouveaux types de composants leur permettant d’être plus modulables, sécurisées, innovantes et intelligentes (cloud, ML, grande quantité de données, …). Or, l’intégration de ces nouvelles technologies dans les applications a augmenté les risques pour le bon déroulement des projets. Bien souvent, ce type de produits nécessite l’intervention de nouveaux métiers – Data Scientist / Data Engineer / Data Analyst… Cela ravive les difficultés rencontrées par le passé dans la gestion du cycle de vie des projets. C’est particulièrement le cas lors de l’accompagnement d’un produit d’une phase de développement à une phase de production, a fortiori étant donnée cette nouvelle diversité fonctionnelle de parties prenantes.

Les insuffisances du DevOps au service de la Data et du Machine Learning

L’intégration de modèles d’intelligence artificielle et plus particulièrement de Machine Learning dans des applications a soulevé de nouveaux enjeux. La philosophie DevOps a essayé de s’adapter pour pouvoir répondre à ces nouveaux défis, mais les principes DevOps initialement définis ne suffisent plus pour mener à bien un projet ML. En effet, ces projets présentent de nombreuses spécificités qui ne sont pas couvertes ou sont mal traitées par le DevOps (voir le tableau ci-dessous).

Ainsi le DevOps ne permet pas de répondre à tous les besoins de ces nouvelles technologies, induisant l’émergence de nouvelles disciplines.

Pour prévenir au mieux les risques et accélérer l’intégration de nouvelles fonctionnalités, de nouvelles perspectives et tendances émergent chaque jour autour des idées du DevOps, déclinées pour chaque usage et générant une véritable ère des Ops : « MLOps », « DataOps », « SecOps », « ITOps », etc. Ces différentes notions sont décrites brièvement dans le tableau ci-dessous.

Pour mieux comprendre les dynamiques associées à ces nouvelles disciplines, nous avons mené une étude sur l’évolution de leur popularité sur Twitter, acteur majeur dans l’émergence, l’exposition et la popularité des nouvelles technologies. Après avoir récupéré l’ensemble des tweets mentionnant chacun des termes associés (DevOps, MLOps, DataOps, etc.), nous avons quantifié et dénombré leur nombre comme mesure de leur popularité sur les dernières années. Les courbes de popularité de ces différents termes sont présentées dans le graphique ci-dessous, avec le terme DevOps qui est présenté à part du fait de ses particularités (voir cadrant en haut à gauche).

Dans le monde de la Tech, le mouvement DevOps se positionne comme précurseur et semble être à l’origine des autres disciplines. En effet, nous observons sur le graphique que la première apparition du terme sur Twitter est en 2007, soit deux ans avant l’apparition d’autres mouvements Ops. De plus, nous observons qu’il y a une augmentation pseudo-exponentielle de sa popularité jusqu’à 2015, suivi d’une augmentation plus faible jusqu’à 2017, portant à 725 000 tweets sur le DevOps en une année (soit 2 000 tweets par jour !). L’inversion de la tendance de popularité à partir de 2017 peut s’expliquer en partie par la création de nouveaux mouvements Ops, entraînant un effet de vases communiquant. Ces mouvements complètent la philosophie du DevOps dans certains domaines nécessitant des pratiques plus spécifiques.

Pour autant, les nouveaux termes associés sont nettement moins représentés sur la Twittosphère avec un rapport de x40 par rapport au nombre de tweets sur le DevOps. Cela peut s’expliquer par le fait qu’avant le DevOps, la communauté des ingénieurs logiciels était déjà massive. Les autres disciplines (Big Data, Machine Learning, …), nettement plus jeunes, n’ont pas encore de communauté mature et manquent d’ailleurs de nombreuses ressources.

À l’origine de tout projet Data, une problématique forte qui s’impose aux organisations est la collecte, le stockage et le raffinage d’une grande variété de données volumineuses. C’est probablement l’une des raisons pour lesquelles nous pouvons voir que la popularité du DataOps augmente fortement dès 2015. Cela a également posé des questions relatives à la sécurité de ces données, d’où l’augmentation de la popularité en parallèle du concept de SecOps.

Il est très intéressant de remarquer que le développement de la popularité du MLOps est postérieur à celle du DataOps. Une première explication de cet ordonnancement fait écho à ce que nous avons décrit précédemment : la première difficulté d’un projet Data est la récupération automatisée de données qualifiées, d’où la primauté du DataOps. Une autre explication complémentaire relève du fait que le DataOps englobait initialement toutes les problématiques liées à l’opérationnalisation des données : du Data Engineering à la Data Science. La stagnation puis la diminution de la popularité du DataOps sur Twitter pourraient s’expliquer par la différenciation des problématiques opérationnelles associées à chaque segment fonctionnel (Data Engineering et Data Science), cédant donc un peu d’espace au MLOps.

En effet, le MLOps s’attache à travailler sur les spécificités d’un projet d’IA et de Machine Learning qui ne sont pas couvertes par le DataOps tels que le versionning, ou encore le monitoring des modèles de ML. La forte augmentation depuis 2018 du nombre de tweets sur le MLOps est un indicateur confortant notre vision sur l’intérêt porté à ce nouveau métier, et en même temps souligne sa prime jeunesse. Par ailleurs, contrairement au DevOps ou au DataOps, ce terme ne semble pas avoir atteint son plateau de popularité sur Twitter, montrant ainsi que le sujet reste pleinement d’actualité. Enfin, les courbes du DataOps et du MLOps se croisent en 2020, laissant penser que les enjeux du MLOps présentent actuellement une importance quelque peu supérieure au DataOps aux yeux de la communauté.

Chacun de ces mouvements est pour la plupart très récent, et de fait, il n’existe pas au sein de la communauté de consensus sur la définition de leurs périmètres, de leurs modus operandi, et des bonnes pratiques associées. En particulier, le MLOps apparaît comme le concept le plus juvénile, et pas des moins complexes. L’impérieuse nécessité d’une vision Ops se résume parfaitement par cette citation de Klaus Schwab, ingénieur, économiste et président du Forum Économique Mondial :

Dans le nouveau monde, ce n’est pas le gros poisson qui manque le petit ; c’est le plus rapide qui mange le plus lent.

Définition, objectifs, périmètre, outils… Retrouvez-nous bientôt pour la suite de cette tétralogie dédiée au MLOps ! En attendant, contactez nos expert·e·s Data pour en savoir plus.

Rédigé par Clément Moutard, Manager Data, et Martin Cudicio, Consultant Data

Dans un monde numérique en plein bouleversement, les entreprises font de plus en plus appel aux nouvelles technologies afin de tirer de la valeur de leurs données.  Cependant, selon Gartner, seulement 13% des projets de Machine Learning (ML) seraient industrialisés aujourd’hui.

L’un des principaux problèmes empêchant les modèles d’être exploités est lié à la difficulté de les opérationnaliser. Autrement dit, le grand enjeu que rencontre la Data Science est la mise en production des solutions de ML.

Le cycle de vie d’un projet ML est constitué de nombreuses phases et convoquent de nombreux métiers : aux côtés du Data Scientist et du Data Engineer qui modèlent la solution, le rôle du ML Engineer est essentiel dans la gestion à terme du projet.

Ses objectifs sont les suivants :

• Accélérer l’avancement des projets de ML en gérant le cycle de vie des modèles, de leur phase de développement à la post-production ;
• En amont, co-articuler le projet avec les pipelines de données qualifiées (pertinentes, fiables, de qualité) développées par le Data Engineer. Ces données sont remises au·à la Data Scientist afin qu’il puisse travailler au développement des modèles de ML ;
• Organiser la phase d’entraînement des modèles pour faciliter la phase d’intégration et de déploiement (selon des règles comme A/B testing, Canary Rollout) dans des environnements de production. Cela permet au·à la Data Scientist de versionner les modèles pour assurer leur gestion systématique ;
• Suivre la performance des modèles et des données et, s’il y a lieu, faire remonter les écarts, erreurs et métriques au Data Scientist pour assurer l’absence de semantic/concept drift. Le cas échéant, il est envisageable d’y remédier par un réentraînement des modèles, si possible automatiquement ;
• Suivre la bonne exposition des services ML, par exemple via l’encapsulation des modèles dans une application en collaboration avec une équipe de développement (DevOps et/ou Cloud Architect).

Le ML Engineer maîtrise les librairies de Data Science (Tensorflow, Scikit-Learn) et les outils de développement (Python, R. Jupyter), de DevOps (Airflow, Git, Ansible), de versionning et de ML Management (MLflow, AutoML, Kubeflow). Il est également à l’aise avec la méthodologie Agile afin d’assurer la gestion de projets (Scrum).

C’est un métier facilitateur et pluridisciplinaire qui s’appuie sur des frameworks de gestion de workflows, de versionning, et de ML management. Son rôle est clé, car il crée de la valeur rapidement.

En conclusion

La discipline du MLOps est récente et les pratiques ne sont pas encore harmonisées au sein de la communauté. Toujours en développement, elle garantit des activités très concrètes et innovantes. Si ces perspectives à la fois ouvertes et challengeantes vous intéressent, n’hésitez pas à contacter nos experts Data ou à candidater pour nous rejoindre ici. Au plaisir d’échanger !

Rédigé par Clément Moutard, Manager Data, et Martin Cudicio, Consultant Data