Aujourd’hui, qu’on le veuille ou non, notre monde est intrinsèquement lié à celui du cloud computing. Aussi bien sur le plan industriel que sociétal. Cette révolution des mentalités a précipité le renversement de la structure monolithique classique, qui jusqu’alors supportait en vase clos le cycle complet des données, de l’ingestion à la restitution dans un tableau de bord. Les services du Cloud ont progressivement permis l’adoption d’une « modern data stack« , articulée sur des fondements tels que le « data lake« , puis le « data mesh« .

De ce fait, aujourd’hui, les acteurs de la BI (business intelligence) ne sont plus seuls à extraire et transformer les données brutes que de multiples sources, internes ou non à l’entreprise, recueillent en flux continu. Le mot d’ordre est “ouverture sur le monde”, via la prolifération de services API dans les systèmes d’informations internes et sur la Toile planétaire. Les directives préconisent dorénavant la mise en place de politiques de gouvernance inter-départementales pour encourager et encadrer l’idée de partage de leurs chères data.

• Partie 1 : Le Machine Learning en production et ses solutions ML Ops dans le Cloud
• Partie 2 : Pourquoi se lancer dans une démarche de Machine Learning
• Partie 3 : La définition d’un algorithme ML
• Partie 4 : Pour une stratégie de réutilisation des solutions

De Amazon EC2 au data mining

Faisons un peu d’histoire. Au tournant de la décennie 2010, l’innovation dans le domaine des technologies de l’information et la communication implique de grandes refontes organisationnelles. Notamment avec le lancement phare, en août 2006, du service Elastic Compute Cloud (EC2) par Amazon Web Services (AWS), permettant à quiconque de louer des instances de machines virtuelles, afin de mettre en ligne leurs propres projets applicatifs. Et qui dit plus de logiciel applicatif à la carte, dit plus de métadonnées générées et de ce fait plus de statistiques à produire et analyser.

Ainsi, aux environs de 2010, la culture de pilotage stratégique par les données (data-driven culture) a pour de bon le vent en poupe. « Les données numériques sont le nouveau pétrole » préfigure du capitalisme de demain: acquérir des gisements colossaux d’information et en extraire des signaux faibles – et gagner à se démarquer de la concurrence.

Les prouesses de l’analyse prédictive (et son penchant prescriptif) poussent les dirigeants à embaucher des profils experts en minage de données (data mining), une branche spécialisée de l’informatique de gestion. Ce poste atypique de numéricien manie l’art de piocher des tas de nombres pour en prélever de l’or, au moyen de théories statistiques et probabilistes qui débouchent le cas échéant sur la mise en place d’algorithmes d’apprentissage automatique à l’intérieur des plateformes décisionnelles. La mission de tels algorithmes sera d’enrichir la base de connaissances d’une part, et l’expérience utilisateur d’autre part, par parution de réponses « intelligentes » (“smart”) à des requêtes de recommandation, d’évaluation, de classification. Les notions de « data science » et de « data team » s’installent alors irréfutablement dans la culture dominante.

L’essor du métier de Data Scientist

Cette « data team » est en soi l’union de profils complémentaires pour faire fructifier des analyses sophistiquées dans le système de gestion de données. Il s’agit de faire coopérer des professions d’ingénieurs et de scientifiques. En effet, le titre « data scientist« , qui prend valeur de “métier le plus sexy du 21ème siècle” d’après la Harvard Business Review, fusionne les compétences suivantes :

• inclination à la recherche en mathématiques appliquées,
• talent de communicant,
• propension à élaborer des plans d’architecture infrastructurelle.

Une telle description de la profession de data scientist (d’influence états-unienne et similaire à maints égards à celle de numéricien) a de prime abord été déroutante pour les novices en la matière : habilité à percevoir les problèmes stratégiques de l’entreprise, aptitude à pousser une méthodologie de travail adéquate, envie de s’impliquer dans les réflexions sur les choix d’équipements logiciel et matériel, et dans la prise en compte des questions de sécurité et d’éthique… Jusqu’où s’étendent ses responsabilités, et à qui déléguer ses chantiers en cas de besoin ou de manque de compétence?

Pour approfondir le sujet, voir nos portraits de Data Scientist dans notre rubrique « Dans ta science ».

Entre agile et DevOps, le ML Ops

Vient vers 2017, en France et ailleurs, le creux de la vague. Le constat d’un marché encore trop immature finit par rebuter les dirigeants d’entreprise: un nombre trop restreint de preuves de concept de machine learning parvient à passer le cap de la mise en production.

Il s’agit alors de mettre en place, de la même manière que pour le génie logiciel, le bon écosystème au sein duquel la culture data science pourra s’épanouir. Les manifestes Agile et DevOps ont radicalement changé le paradigme de l’édition logicielle. Pourquoi ne pas s’inspirer de ces courants de pensée contemporains, pour créer un écosystème qui fluidifie le cycle de vie d’un produit incorporant de l’apprentissage automatique ? Un plan à dérouler sans accroc, de la phase de conception à la phase d’industrialisation, et bien entendu au-delà de la mise en production – dans la supervision des tâches d’exécution (aka le « run« ).

Les métiers centrés sur les data se dotent ainsi des bonnes pratiques des ingénieurs logiciel, avec en premier lieu celle de l’itération rapide, associée à celle de la gestion de version dans un système tel que Git. D’autre part, le processus d’Intégration Continue/Déploiement Continu (CI/CD) et l’utilisation de conteneurs virtuels (Docker, Kubernetes) insufflent à la culture data science une véritable force de levier pour viabiliser le flux de production. Nait (vers 2018) le terme « Machine Learning Operations« , en référence à l’écosystème « Development Operations » qui propage déjà ces modes opératoires dans le milieu du développement applicatif conventionnel.

La définition de MLOps peut encore être débattue aujourd’hui, sur sa propre identité face à la philosophie « DevOps« . Le terme « Entraînement Continu (Continuous Training) » est ajouté en supplément de la boucle originale CI/CD. Hormis cette spécificité CT+CI/CD, quelles nuances majeures?

Objectivement, le terme MLOps désigne une organisation, un écosystème, à travers lequel les meilleures pratiques mûrissent au fil du temps pour garantir la robustesse d’un mécanisme opérationnel. L’intention première est que tout projet ML dispose d’un accès aux bonnes ressources, au sein d’un environnement de travail aménagé pour les activités des data scientists :

• Le mode d’organisation recommandé est ainsi basé sur une approche Agile permettant de s’adapter aux changements non planifiés (tels qu’une évolution du besoin client ou une anomalie bloquante détectée dans le système).
• De plus, la communauté MLOps promeut l’acculturation des data scientists au concept de livraison continue, de manière à réaliser l’exploit de faire passer leurs produits en production, qui plus est en minimisant autant que possible l’ajout de dette technique dans la pile existante.

La mécanique ML Ops en question porte plus explicitement sur l’engrenage d’une série de tâches que l’on a à mettre en œuvre, dans le but de produire et d’exposer à des clients un “estimateur”. Un service, qui pour opérer à la demande des calculs d’estimations statistiques, a recours à un modèle “formé” par une machine apprenante. Précisons aussi que l’intérêt commercial d’un tel service est d’imputer une valeur crédible sur une donnée que des analystes demandent à connaître. Mais que, pour des raisons de moyen (technique, financier, politique, …), l’entreprise renonce à acquérir via des procédures courantes, telles que l’installation de capteurs électroniques ou l’intervention d’experts humains.

Notre approche du ML Ops

À ce jour, pour la communauté ML de Devoteam Revolve, le ML Ops représente l’investissement dans un cadre structurel (organisationnel et infrastructurel) adéquat. Avec à la clé une rampe de lancement permettant de construire vite et bien le service lié à l’estimateur voulu.

Un mantra, qui est le nôtre : l’automatisation des tâches rébarbatives, en vue de “désautomatiser” le quotidien des acteurs humains. De manière à miser surtout sur le potentiel créatif et l’activité cérébrale des contributeurs. En faisant abstraction des routines “ops”.

Disons que les data scientists souhaitent avoir accès à une plateforme MLOps afin de réduire autant que possible les points de friction dans les conduits de mise sur le marché. Ne pas perdre de temps avec une intuition, la confronter en un clic à la jauge de satisfaction des utilisateurs de leur service ML.

Cette plateforme intègre bien sûr les précautions appropriées en termes de stabilité, de sécurité et de respect de la confidentialité des data sensibles. De manière à ce que tout produit ML bénéficie à la fois de la confiance des responsables sécurité des systèmes d’information (RSSI) et de celle des délégués à la protection des données (DPO).

Les directions d’entreprises sont maintenant, à l’aube de la décennie 2020, convaincues, et en phase d’acculturation à ce nouvel écosystème. Le machine learning peut indubitablement se montrer utile pour un large éventail d’applications critiques. L’enjeu phare est d’être en capacité de remédier aux diverses complexités de la discipline, dans un contexte commercial qui soulève la question de l’aptitude au passage à l’échelle.

Le passage au ML Ops pose cependant de nouvelles questions.

• Comment recruter de manière appropriée dans l’équipe ?
• Et comment judicieusement investir dans des solutions de marché, pour monter sa plateforme ?
• Mieux vaut-t-il bâtir soi-même ou se fier aux solutions distribuées sur le marché ?
• Comment sensibiliser les responsables métier aux principes et les contraintes d’adoption d’une solution ML, dans le souci de faire perdurer sa valeur ajoutée ?

La question de la responsabilité est par ailleurs un sujet critique du MLOps. L’engagement SLA (Service Level Agreement) à tenir auprès des clients d’un outil prédictif nécessite la mise en place de dispositions qui facilitent la gestion de crise. Qui convoquer d’urgence à 02h00 du matin en cas d’incident ? Qui pour porter quelle responsabilité en cas de défaillance ?

Autant de sujets que nous aborderons en profondeur dans le cadre d’un livre blanc consacré au Machine Learning en production, et aux solutions ML Ops dans le Cloud. A suivre très prochainement…