Peu importe le domaine où vous exploitez de la donnée (santé, retail, supply, financier, …), la transition d’un projet de Data Science / Intelligence Artificielle (I.A.) depuis la phase de POC (Proof Of Concept) à la phase de mise en production est complexe (problèmes budgétaires, mauvaise organisation, outils non compatibles, etc). Ce n’est pas pour rien que selon l’analyste Nick Heudecker de Gartner, plus de 85% des projets de Data Science échouent. Cela est appuyé par une autre étude du MIT Sloan montre que seules 10% des entreprises voient un vrai ROI de leur projets IA. Pourtant, la mise en production est nécessaire pour que votre projet d’I.A. apporte de la valeur à l’entreprise mais surtout pour qu’elle soit utilisable avec des données du monde réel : prédiction du trafic d’un site, de l’intérêt d’un client à un produit, des ventes, etc.

Avant la mise en production d’un projet de Data Science, le data scientist devra industrialiser son projet mais sera limité par ses différentes compétences. C’est pourquoi il devra s’appuyer sur les connaissances d’un data engineer pour rendre cette phase d’industrialisation sans douleur. Ces questions se posent donc :

Comment peut-il aider le data engineer dans la mise en production d’un projet Data ?
Comment le data scientist peut-il faciliter la mise en production ?
Qu’est-ce qu’il doit faire pour transformer l’initiative ?

Pour répondre à ces questions, nous allons répartir notre réponse autour de 4 axes, chacun abordant une thématique générale plus ou moins technique : cadrer le sujet, obtenir la confiance des équipes, rendre stable l’infrastructure, stabiliser les performances du modèle, aider à la communication.

Avant de vous lancer dans le cœur de l’article, il peut être nécessaire d’avoir du recul sur un projet d’Intelligence Artificielle, à savoir ses enjeux, sa composition et son organisation. Pour vous les démystifier, notamment dans le secteur de la Supply Chain, nous vous invitons à regarder notre webinar AVISIA “L’IA au Service de la Supply Chain” : 

https://www.brighttalk.com/webcast/17108/405587/lia-au-service-de-la-supply-chain

Axe 1 : cadrage du sujet 

Dans une grande entreprise ou dans une entreprise avec une équipe data conséquente, le data scientist aura vraisemblablement un rôle plus circonscrit que dans une start-up ou petite entreprise : dans ce cas-là, il devra notamment aider à trouver un projet qui peut bénéficier à l’entreprise, justifier l’enjeu business, et convertir cet enjeu en problématique data concrète. Néanmoins, peu importe son rôle et l’étendue de ces attributions, le data scientist peut grandement aider au cadrage du sujet et donc à sa réussite.

Valider la faisabilité du projet ✔️

Même si le projet vient de l’équipe data, il faut vérifier qu’il est réalisable en effectuant une étude de faisabilité. Par exemple, pour un projet d’analyse d’images dont l’objectif est de détecter des produits défectueux, il faut vérifier que :

• • L’équipe dispose des données afférentes, c’est-à-dire des images ! Il faut savoir si elles sont récupérables par l’équipe, et par quel biais (prises de photo par les vendeurs ou l’équipe ? capteur automatique ?). Bien entendu, il faut savoir si la qualité des données est suffisante pour le projet. De plus, si le projet va jusqu’à l’industrialisation, est-ce qu’il sera possible de récupérer les images au bon moment et avec la bonne fréquence pour appliquer nos traitements ?
  • Ensuite, sait-on quelles images représentent un produit défectueux ? Autrement dit, dispose-t-on des labels pour pouvoir apprendre à notre algorithme à distinguer les produits défectueux des produits corrects ?
  • Le data scientist, fort de son expérience, doit savoir justement si un projet de Data Science est nécessaire. Les raisons pour lesquelles ce ne serait pas le cas sont multiples :
    • réalité du besoin : les directeurs ont-ils simplement besoin de savoir les régions ou modèles avec le plus de défauts ? c’est-à-dire des analyses descriptives judicieusement réalisées ?
    • apport du projet : le projet cherche-t-il à remplacer un processus « manuel » déjà existant ? si c’est le cas, sur quels points la Data Science ferait mieux ? Potentiellement parce que cela sera plus rapide que le faire par des personnes, moins cher, plus efficace. L’équipe doit définir clairement l’apport qu’elle pense apporter.
  • Il doit aussi aider à définir un périmètre réalisable :
    • quel sera notre individu au sens statistique, autrement dit le périmètre d’intervention ? Est-ce pertinent de détecter des défauts sur des véhicules neufs, d’occasion ou tous ?
    • quel sera notre objectif statistique : doit-on détecter le nombre de défauts ? leur endroit ? le fait qu’il y en ait au moins un ou pas du tout ?
    • quel sera notre périmètre temporel ? cela est surtout important pour les problématiques de prévisions temporelles, mais il sera tout de même nécessaire de savoir si les prédictions seront effectuées quotidiennement, en combien de temps elles doivent être faites, à quel horizon temporel.

Traduction de l’objectif business 🗨️

Une fois que l’étude de faisabilité est validée et que le sujet est pertinent pour l’entreprise, il faut ensuite s’assurer que l’objectif retranscrit corresponde bien à une problématique qui puisse être traitée par l’équipe data. Une telle problématique doit pouvoir être quantifiée, doit pouvoir être optimisée (la data peut permettre d’identifier des leviers d’action).

Par exemple, une entreprise qui souhaite adapter le prix des produits qu’elle vend a un objectif business clairement défini d’améliorer la marge. Ici, pour une équipe data, choisir “d’optimiser la marge” ne correspond pas directement à un processus data bien identifié :

• Quelle définition prendre de la marge ? Il est fort vraisemblable que les différentes équipes (produit, marketing, finance, …) aient des définitions différentes. Le rôle de data scientist est de réunir ces personnes autour de la table, comprendre leurs définitions, les implémenter, les comparer, restituer ses travaux et aider à statuer.
• Ensuite, il ne sera pas forcément immédiat de traduire cet objectif métier en objectif data qui puisse se plier au cadre parfois précis de la Data Science. Pour reprendre l’exemple précédent, hors certains domaines de recherche, il n’est pas simple de récupérer des données et d’écrire dans un langage “Optimise la marge de ces véhicules”. Une solution est de circonscrire le sujet : “Prédire le temps de commande d’un produit pour proposer aux experts d’en changer le prix en fonction de son prix et des indicateurs de navigation sur le produit”.

Exemple de processus de traduction d’un objectif métier en objectif Data Science

Axe 2 : confiance et sponsoring des parties prenantes

Aujourd’hui, un des problèmes majeurs des data scientists est de maintenir la confiance dans l’utilisation de la Data Science pour les équipes opérationnelles. En effet, il y a de plus en plus de projets qui s’appuient sur des modèles de type “black box” (ex : Random Forest, XGBoost). Ceci pour gagner en performance, vis-à-vis des modèles traditionnels, mais confronte les équipes opérationnelles à une complexité d’interprétabilité.

De plus, si votre projet est bien cadré mais que vous n’arrivez pas à convaincre les parties prenantes de son utilité, alors il est possible que les experts ne comprennent pas la nécessité d’une approche de type I.A. La capacité à pouvoir bien expliquer est très importante car cela vous permettra de mener à bout le projet, de maintenir une ligne sur le budget, voire d’en débloquer d’autres.

Renforcer la confiance grâce à de l’I.A. interprétable – XAI 🔮

L’interprétabilité d’un modèle est nécessaire pour différents raisons, notamment pour :

• Le data scientist, auteur du modèle, qui doit comprendre les relations que le modèle a trouvées, pour communiquer les résultats dans l’entreprise, pour vérifier l’intuition des experts métiers (voire la sienne !), pour débugger son modèle.
• Les équipes métiers, qui vont utiliser le résultat du modèle, doivent avoir confiance en sa performance et comprendre ce qui fait son utilité  Un modèle qui n’est pas compris ni éprouvé sera malheureusement rarement utilisé…
• Les auditeurs & les régulateurs, c’est-à-dire les personnes en charge de vérifier le bon fonctionnement des systèmes. Par exemple dans la banque, le besoin d’interprétabilité est nécessaire pour le valider en interne (dans l’équipe ou pour l’Inspection Générale), mais aussi pour se conformer aux exigences réglementaires (ACPR, AMF, BCE).

Le fait de pouvoir interpréter facilement et efficacement des modèles complexes en facilite l’emploi et doit être un outil dans la panoplie du data scientist moderne. Grâce aux framework d’XAI, l’interprétabilité et la performance deviennent accessibles : ils permettent de déterminer à la fois ce qui joue pour la prédiction d’un individu (sens et importance), et pour tous les individus (importance des variables). Il existe différents frameworks d’interprétabilité (SHAP, Lime, PDP) qui vont permettrent de mieux collaborer entre les parties et éclaircir les secrets des modèles de machine learning. 

Exemple de XAI: Interprétation du prix d’achat d’un appartement à Paris 

Si vous souhaitez plus de détails sur les techniques d’interprétabilité, vous pouvez lire notre article ci-dessous :  https://www.avisia.fr/news/tribune-expert/interpreter-modeles-machine-learning/.

Faire du Data Storytelling pour communiquer efficacement ✨

Communiquer rapidement, c’est bien, mais bien communiquer c’est mieux ! Lorsque vous présentez vos résultats, pensez à faire du Data Storytelling. Pour cela, identifiez quelques KPI et idées qui vous paraissent intéressantes, puis racontez une histoire avec celles-ci pour retenir l’attention des décideurs. Par exemple, si vous voulez expliquer en quoi consiste l’interprétabilité, alors vous pouvez créer plusieurs situations dans une journée et expliquer le besoin d’interpréter : « Quand je lis mes emails, je ne comprends pas pourquoi on me recommande ce produit ! », « Je ne comprends pas la décision de ne pas m’accorder ce crédit », « Pourquoi on me diagnostique une fracture ? ».

Les 5 piliers d’un data storytelling réussi : de bonnes données, la présentation a un objectif clair et partagé, l’audience est identifiée pour adapter le message, les visuels sont convaincants, une histoire est racontée.

Prouver la valeur de la Data Science en itérant rapidement 🚴

La communication dans un projet de Data Science doit être fréquente car il faut prouver la valeur de votre initiative et maintenir le lien de collaboration avec les équipes métier. Ici, le data scientist aura pour rôle d’établir d’abord un état des lieux du sujet, indiquer les chiffres globaux, apporter un aspect chiffré à la problématique. Cela permettra de confirmer ou infirmer les hypothèses initiales du sujet, faciliter la validation du cadrage par les équipes métier, mais aussi les rendre impliquées dès le début. Puis, si le sujet s’y prête, le data scientist va créer un premier modèle simple pour partager rapidement des premiers résultats probants et analyser si le critère de succès est validé : par exemple, au lieu de se lancer dans des modèles de recommandations très complexes, une baseline qui marche très bien et de recommander les best-sellers de la marque ou les produits achetés ensemble. C’est le concept assez connu de Minimum Viable Product (ou son équivalent data science, le Minimum Viable Model), c’est-à-dire délivrer un première version du projet « suffisamment bonne ». Ensuite, il va itérer son modèle en le rendant de plus en plus performant (potentiellement de plus en plus complexe).

Illustration du concept de MVP

Le fait de communiquer plus souvent et de livrer plus fréquemment rappelle les principes de la méthode agile. Cela permettra au métier de se sentir bien intégré au projet et impliqué, et de voir les résultats progresser au fur et à mesure du temps. À la différence de projets qui feront plus penser à de la R&D, où l’équipe métier aura l’impression que l’équipe data est déconnectée du monde réel et promettra des échéances à plusieurs mois, voire 1 ou 2 ans. Avec l’approche du MVP / MVM, les équipes métier seront plus enclines à devenir sponsors des projets data.

Vis ma vie avec les experts

Le monde du data scientist et de l’expert sont très différents et peuvent occasionner des problèmes de compréhension. Un « vis ma vie » consiste à ce qu’une personne technique prenne le rôle ou accompagne une personne d’une équipe métier pendant une journée normale 🤝. Cela permet de comprendre la nécessité du projet (automatiser une tâche quotidienne qui prends du temps par exemple), comprendre comment il est mis en place (dans quel outil ? par qui ?), comment il est utilisé (un nouvel outil très performant ne sera pas utile si la personne doit déjà en manipuler plusieurs autres et doit prendre des décisions rapidement), voire permet d’apporter de nouvelles idées de projets. Ces journées sont toujours les bienvenues car elles renforcent la cohésion d’équipe et fluidifient la coordination avec les experts.

Axe 3 : stabilité et scalabilité de l’infrastructure

Suite au feedback des experts après l’utilisation de votre projet Data Science et à l’identification des points d’amélioration, la solution doit être mise à jour pour prendre en compte ces modifications, sans apporter une régression au code mis en production. L’approche CI (Continuous Integration) / CD (Continuous Delivery) permet de construire un écosystème informatique où chaque modification est intégrée automatiquement et rapidement. Chaque modification de votre code se fait dans la tranquilité et la fiabilité. 

Cette approche peut être difficile et doit être anticipée avec un data engineer afin d’assurer en continu l’existant sans briser le projet en production. Pour savoir si un projet est mature niveau CI/CD, il faut se poser ces questions : est-il possible de savoir si le nouveau modèle est performant ? Est-il possible d’intégrer facilement de nouvelles variables dans le code existant ? L’article de Google sur le ML Test Score recense un très grand nombre de ce type de questions, qui doivent être traitées par le data engineer ou ML engineer, avec l’aide du data scientist.

Cette approche CI/CD permet d’augmenter la fréquence de distribution de votre projet grâce à l’introduction de l’automatisation au niveau des étapes de développement. L’idée de cette approche est d’intégrer (CI), de distribuer (CD) et de déployer en continu (CD). De manière très concrète, cela permettra au data scientist par exemple de pouvoir ajouter de nouvelles variables dans son modèle et de pouvoir le déployer facilement et rapidement en production.

Intégrer en continu son projet en production 

L’intégration continue (CI) pour le data scientist, toujours en collaboration avec le data engineer, consiste à apporter de nombreuses modifications à son code, à les tester, puis à les fusionner dans un référentiel partagé. Voici quelques exemples (non exhaustifs) de bonnes pratiques à adopter par le data scientist pour faciliter le travail du data engineer :

Déployer en continu son projet en production 

Toutes ces bonnes pratiques permettent de faciliter et simplifier au maximum la distribution continue (CD). Dans le cadre de celle-ci, les modifications apportées par le data scientist sont automatiquement testées, puis exportées dans un référentiel : un Bundle dans Dataiku DSS, une image Docker ou bien GitHub. Ce référentiel est prêt à être déployé dans un environnement de production et facilite la collaboration entre les différents acteurs de votre initiative. 

Une autre signification de CD peut être utilisée, à savoir le déploiement continu. Cette approche correspond au transfert automatique des modifications du data scientist depuis le référentiel vers l’environnement de production. Désormais, les utilisateurs utilisent les améliorations apportées sur le projet Data Science et pourront faire un feedback en continu au data scientist.

Cette partie est définie principalement par le data engineer mais doit être validée par le data scientist pour qu’il puisse rapidement itérer sur son projet.

Axe 4 : stabilité et suivi des performances 

En tant que data scientist, il ne faut pas attendre que le responsable marketing de l’entreprise vienne vous voir en disant “Je n’ai plus aucun résultat du projet de votre équipe, je ne peux plus rien faire, c’est la catastrophe ! 😱”. La différence entre le développement logiciel classique et la Data Science c’est qu’il existe de multiples raisons pour que le projet ne délivre pas les performances attendues : tout le code tourne bien, les erreurs ne relèvent pas de l’infrastructure ou du code, mais davantage de l’analyse (ou du manque d’analyse).

Sélection d’un modèle parcimonieux

Le principe philosophique du rasoir d’Ockham est bien connu des statisticiens : il faut toujours préférer les raisonnements les plus simples. En Data Science, cela revient à choisir un modèle simple par rapport à un modèle complexe si la différence de performances des deux est faible. C’est-à-dire privilégier une approche avec peu de variables explicatives versus une approche avec beaucoup de variables. Or, quel sens cela a à l’ère des méthodes ensemblistes modernes (XGBoost, Forêts Aléatoires, …) qui sont tout aussi performantes même avec des variables inutiles ?

• Un modèle parcimonieux simplifiera bien plus toute la chaîne de collecte et de transformation de la donnée. S’il est suffisant de récupérer quelques variables pertinentes dans une seule base de données, tous les acteurs du projet seront soulagés et n’auront pas à aller chercher dans de multiples systèmes d’information différents la moindre information qui pourrait potentiellement s’avérer utile.
• Conséquemment, moins le projet de Data Science nécessite de variables, moins il y a de chances :
  • qu’une erreur vienne casser l’infrastructure ou dégrader les performances (valeur manquante, valeur anormale, nouvelle modalité, etc.) 💥
  • que l’interprétation du modèle soit complexe. Cela est vrai pour les modèles simples, mais aussi pour les modèles complexes car les méthodes d’interprétabilité sont sensibles à la corrélation.

Enregistrement des logs 📝

Quand le projet sera utilisé en production et même en pré-production (l’étape juste avant pour vérifier que tout se déroule bien), il est primordial de stocker l’ensemble des étapes réalisées lors du processus data. L’exemple suivant utilise la librairie Python logging pour stocker toutes les étapes effectuées dans un fichier de log (un fichier texte) qui sera lui bien sûr sauvegardé à chaque lancement du processus (tous les jours dans ce cas).

Exemple de codes d’utilisation de la librairie logging

De la récupération des données à une volumétrie globale de probabilités calculées, toutes les étapes sont loguées, et il devient donc possible de savoir, pour n’importe quel jour donné, où est-ce qu’il y a eu une erreur (au niveau du chargement des données, du calcul des variables, de la récupération du modèle, etc.)

Validation des performances 📈

Une fois que la création, le logging, le monitoring du modèle sont prêts, il ne suffit pas de vérifier les performances sur un autre jeu de données pour se dire qu’il est prêt à être déployé. Par contre, il n’est pas souvent souhaitable de déployer le modèle sur tous les individus / prospects. En effet, entre les erreurs d’infrastructures non prévisibles par les data scientists (un plantage total d’instances Amazon sur une zone par exemple), une inadéquation entre individus d’apprentissage et d’application, une mauvaise utilisation du projet par les équipes métier, etc., il existe un grand nombre de soucis que le projet peut rencontrer après le déploiement.

La bonne pratique dans tout projet data est de valider les performances par une méthode de tests :

• la plus connue est l’A/B testing : dans le cas d’un projet data science, cela correspond à appliquer le résultat de notre projet sur une proportion de la population (entre 5% et 50%), et à garder une majorité d’individus sur lesquels le projet ne sera pas déployé. Cela permet, s’il y a une erreur, de circonscrire le nombre d’individus concernés, mais bien sûr de mesurer la précision de l’algorithme et donc de quantifier le ROI du projet data.
• une autre méthode est le shadow deployement : dans ce cas, aucun individu ne sera impacté, mais l’équipe data sera en charge d’estimer si son projet est bénéfique. Par exemple, dans le cadre de la détection des clients appétents à une offre, il s’agit de laisser le centre d’appel décider qui contacter, mais analyser a posteriori la réussite du contact en fonction des prospects estimés « chauds ». Un autre exemple serait de comparer un modèle déjà en production à notre nouveau modèle « shadow« .

Monitoring du projet 📺

Comme vu précédemment, un projet de Data Science peut tourner sans erreur mais toutefois ne pas donner les résultats escomptés. La création de logs est la première étape. Le monitoring du projet est la seconde étape et est encore plus vitale. Sans monitoring, toutes les erreurs silencieuses ne sont pas détectables, ne sont pas investigables, ne sont pas comprises. 🕵️‍♀️

• Le data scientist, étant owner de son modèle, doit stocker chaque modèle qu’il a entraîné et davantage ceux qui sont utilisés en production. Cela lui permettra de comparer a posteriori la performance de son modèle, d’en inspecter les variables déterminantes, de le comparer à un nouveau modèle. Du point de vue technique, les librairies pickle et joblib de Python permettent de sérialiser (enregistrer au format binaire) des objets de Data Science.
• Il doit bien sûr stocker les prédictions ou les sorties résultantes du projet. Une table doit être créée contenant la date et heure et calcul, le nom ou la version du modèle utilisé, la prédiction ou la sortie, le résultat après application d’un seuil ou d’une règle de gestion, l’identifiant de l’individu concerné. Cette historisation permettra de vérifier l’apport d’une modification du projet, mais aussi tout simplement de pouvoir analyser les résultats et les performances du projet en temps réel et de manière fiable.
• De plus, une dernière information importante peut être stockée : les jeux de données qui ont servi à créer les analyses ou modèles. Cela peut être très utile si le modèle a été perdu pour pouvoir le reproduire, mais aussi pouvoir recréer un modèle pour le comparer à l’ancien mais en étant sûr et certain d’utiliser les mêmes données. Ces jeux de données seront tout simplement sauvegardés dans l’outil de stockage employé par l’entreprise (SGBD, S3 chez Amazon, GCP, etc.)

Exemple de monitoring : les gains du projet sont mis à jour quotidiennement et affichés sur un écran de l’équipe data

Réapprentissage 🤔

Une fois que le modèle est correctement déployé, le travail du data scientist n’est pas encore fini, loin de là. Il existe de multiples raisons pour lesquelles la performance du modèle peut se dégrader autour du temps, toutes regroupées sous le terme de dataset shift :

• Covariate shift : les distributions ont changé entre votre échantillon d’apprentissage (qui a servi à créer votre modèle) et votre échantillon de test / application (sur lesquels vous allez appliquer votre modèle pour vérifier s’il est performant ou l’utiliser sur des données fraîches). Par exemple, si le but du projet est de distinguer les hommes des femmes et seul votre échantillon de test / validation contient des personnes de couleur de peau non blanche, alors vos données souffriront de covariate shift (et bien sûr, d’un fort biais racial). Il peut être dû :
  • à la mauvaise création des échantillons d’apprentissage / test,
  • à la création de données d’apprentissage qui ne reflètent pas du tout la réalité de votre domaine d’application,
  • au fait que votre environnement change au cours du temps (clients de plus en plus jeunes ou âgés par exemple).
• Concept drift : ici, c’est la relation entre les variables explicatives et la variable à expliquer qui va changer entre apprentissage et application. Par exemple, si le but du projet est de détecter de potentiels acheteurs, alors le drift implique que ce qui faisait qu’une personne était susceptible d’acheter par le passé n’est plus la même chose que dans le futur. Ce phénomène est aussi appelé concept shift, mais aussi model drift étant donné que le modèle qui explique nos données change.

Comment le détecter ? 🔎

• La manière la plus simple est de comparer la performance du modèle telle qu’estimée au moment du déploiement et la performance quelques jours ou mois plus tard avec de nouvelles données. Cela suppose bien entendu qu’une métrique quantifiable ait été choisie (cf. 2e point de l’Axe 1), que les prédictions du modèle soient stockées (cf. point précédent de l’Axe 4), et que la vraie valeur de votre cible soit récupérable.
• Une approche qui ne nécessite pas les hypothèses précédentes et permet donc d’anticiper est d’examiner les jeux de données d’apprentissage et d’application :
  • L’approche simple mais laborieuse consiste à examiner chaque variable et vérifier si les modalités ou plages de valeurs sont les mêmes entre les deux échantillons.
  • L’approche astucieuse consiste à établir un modèle qui va essayer de déterminer si une observation appartient à l’un ou à l’autre des échantillons. Si le modèle ne fait pas mieux que le hasard, alors les deux échantillons sont quasi identiques et il n’y aura pas de covariate shift (cette approche ne permet pas d’apprécier la présence ou l’absence de concept drift). Cette approche est appelée adversarial validation. Si le modèle arrive à distinguer les deux échantillons, alors il y aura covariate shift mais pas forcément de concept drift. Un exemple : le projet souhaite identifier les futurs acheteurs mais ceux-ci se féminisent ; il est cependant tout à fait possible qu’hommes et femmes achètent exactement de la même façon qu’avant.

Niveau outils : dans le logiciel Data Science Studio de Dataiku, un plugin est disponible pour effectuer de telles analyses ⚙️.

Au niveau des solutions, si un mouvement dans les données est suspecté ou a été détecté, alors il sera nécessaire de réentraîner les modèles avec des données plus récentes. Vient rapidement la question : à quelle fréquence réentraîner ? Quand ? Bien sûr, il faut réentraîner quand les performances se dégradent. Mis à part cette situation, cela dépendra surtout de la problématique. S’il s’agit d’appétence produit ou d’en recommander, alors le réentraînement aura au moins lieu à chaque lancement d’un nouveau produit.

Conclusion et perspectives 🔚

Merci d’être arrivés jusqu’ici ! 👏 L’industrialisation de projets data est, comme cela peut se voir, très importante mais compliquée et jonchée de points d’attention qui peuvent faciliter ou compliquer un projet. Certains points peuvent être tautologiques mais il est très important de les avoir en tête ; une fois la tête dans le code, ce qui paraissait évident sur un article lu il y a quelques semaines devient un détail parmi tant d’autres stockés loin dans notre mémoire. Néanmoins, comme dans tous les métiers de la data, il ne faut pas demander au data scientist de retenir tous ces points et de les maîtriser : ne passons pas d’un mouton à cinq pattes d’un mouton à six pattes ! C’est grâce à l’expérience acquise de notre côté par nos missions AVISIA que tous ces points deviennent petit à petit des réflexes.

Notons cependant que, de la même manière que le métier de dataminer a évolué en data scientist, un nouveau métier émerge : celui du machine learning engineer. Avec lui une nouvelle composante du métier, le MLOps : le fait que le Machine Learning impacte les Opérations de l’entreprise. Le MLOps est l’application du DevOps, ensemble des processus de développement pour apporter de la valeur aux clients, appliqué à des problématiques de Data Science / machine learning. Les machine learning engineers, habiles sur le MLOps, vont essayer de transformer toutes ces bonnes pratiques data en bonnes pratiques de code : une partie de leurs prérogatives correspond à l’Axe 4, et se partageront l’Axe 3 avec les data engineer. À AVISIA, nous pensons que tout ce que nous avons cité dans l’article doit faire partie de la panoplie du data scientist moderne, même si un tel profil deviendra similaire à un profil de machine learning engineer.

Merci à nos experts Data Science AVISIA Nicolas Betin et Thibault Poissonnier pour la rédaction de ces articles, contactez-nous si vous souhaitez que nous vous accompagnions sur ces problématiques ! 📞