Le Machine Learning n’est pas une baguette magique – beaucoup d’entreprises l’ont appris à leurs dépens. Il est possible d’obtenir de très bons résultats, à condition de respecter quelques principes. Et de bien comprendre que le ML et les data scientists ne sont qu’un maillon d’une chaîne beaucoup plus vaste d’un produit ML réussi.
“ Comment ça, on ne fait pas de machine learning, nous ?” Combien d’équipes data ont eu droit à cette question ? Employé à bon escient, le machine learning peut accomplir des prouesses. D’où cette question fréquente de la part des directions générales.
Mais pour certains usages, ou dans certains contextes, le résultat sera nul, puisque l’entreprise aura investi de l’argent, sans gain de ROI. Voire très négatif, si la solution créée ajoute de la frustration dans le parcours utilisateur, et démotive les équipes internes. Malheureusement, dans la grande majorité des cas, c’est ce qui attend les projets de machine learning.
D’après Venture Beat, 87% des projets de Data Science ne vont jamais en production. Quant à ceux en production, peu d’entre eux rapportent véritablement des gains. Selon une étude MITxBCG, seules 10% des entreprises qui l’ont mise en place obtiennent des bénéfices financiers avec l’IA. Or, ces projets continuent de coûter de l’argent.
Entre les entreprises qui sont persuadées qu’il faut absolument faire du machine learning, parce que tout le monde le fait (effet FOMO, fear of missing out), et des acteurs qui forment à la hâte des data scientists en leur promettant monts et merveilles, l’emballement est réel ; les résultats, beaucoup moins.
Prendre en compte les limites du produit
Déployer des produits intégrant du ML nécessite une certaine connaissance de ce que peut et ne peut pas faire le machine learning. Le ML est un outil, pas une baguette magique qui résout tous les maux. Par conséquent, avant de “mettre de l”IA partout dans l’entreprise”, il est primordial d’acculturer les collaborateurs, en particulier les métiers qui seront utilisateurs de ces solutions. Il est nécessaire que les utilisateurs comprennent comment ils collaboreront avec ces produits.
Par exemple, pour tirer au mieux parti d’un Large Language Model (LLM), tel que ChatGPT, il est essentiel de comprendre qu’il s’agit d’un modèle de langage, accélérant par exemple la rédaction d’un compte-rendu, d’une synthèse, d’un pitch, mais que ce n’est pas un modèle de connaissance ; il n’est donc pas à utiliser comme une méga-encyclopédie, du moins pas sans connaissance ou regard critique sur le résultat produit par le modèle.
Apporter une solution aux problèmes identifiés
Il ne faut pas essayer de résoudre un problème qu’on n’a pas. Un produit ML doit être conçu pour supprimer ou atténuer un irritant, une difficulté rencontrée par les utilisateurs. Les difficultés récurrentes, difficiles à résoudre de manière déterministe, telles que des prédictions de churn, de la reconnaissance d’objets spécifiques sur des images ou de la détection de signaux faibles, constituent de bons candidats pour le ML.
La phase de discovery d’un produit intégrant du Machine Learning doit être adaptée aux exigences de cet outil, mais sans oublier cette notion fondamentale : répondre à un besoin utilisateur. Une fois celui-ci posé, et si le besoin peut être satisfait par du Machine Learning, la première étape essentielle est celle de la découverte des données nécessaires : s’assurer que ces données existent, en quantité et qualité suffisante.
La seconde étape consiste à identifier le modèle de ML le plus adapté pour résoudre la problématique. Ensuite, il convient de tester dès que possible le modèle dans un prototype, avec les données disponibles pour vérifier les premières hypothèses posées. Ce prototype sert alors de base pour collecter les retours utilisateurs et améliorer le produit.
Optimiser le ML par la collaboration
Créer des produits basés sur du ML demande de revoir la chaîne de fabrication des produits, pour instaurer de la collaboration, voire de la coparentalité. Car dans les entreprises, les équipes data, à l’image de la data en elle-même, sont souvent silotées. Les métiers comprennent les données, mais ne communiquent généralement pas avec les autres équipes.
Les data engineers traitent les données sans savoir comment elles vont être utilisées. Les data scientists ne maîtrisent pas forcément les données à 100% et ne se préoccupent pas de la mise en production. Les développeurs, dans le meilleur des cas, recevront le code qui tourne. Si, par chance, un modèle créé dans ces conditions est déployé, il est peu probable qu’il apportera de la valeur.
Les équipes doivent donc collaborer étroitement. Mieux, elles doivent être empathiques, montrer de l’intérêt pour le travail du voisin, comprendre ses attentes et ses challenges. Le mode solo permettra certainement d’aller plus vite sur une partie du travail, mais ajoutera des semaines de travail aux collègues, pour un résultat qui pourrait finalement aller à la poubelle.
Déterminer l’utilisation du produit
Il ne faut pas oublier que le ML n’est souvent qu’une brique de la solution, à intégrer avec d’autres briques qui constitueront un produit final. Les rôles propres à la création d’un modèle de ML sont ceux du Data Scientist et du ML Engineer, mais ils n’ont pas vocation à travailler en vase clos. La synchronisation avec le reste de l’équipe produit est un enjeu crucial.
Sur un périmètre produit simple, une équipe agile, pluridisciplinaire, autonome pourra être en charge du produit complet, ce qui favorise la connaissance des enjeux de chaque membre de l’équipe et l’intégration des technologies. Pour un produit de taille plus importante, les spécialistes du ML peuvent être intégrés à des feature teams ou des équipes transverses fournissant de l’expertise quand celle-ci est nécessaire.
Capitaliser sur le MLOps
Une fois le cas posé, il faut confirmer que la solution pourra être intégrée dans votre produit. Si vos équipes ne possèdent malheureusement pas le don de clairvoyance, il faudra faire un minimum d’analyse et se projeter sur le cycle de vie du produit. Quelles données sont disponibles à l’instant T et lors de l’utilisation de la solution ? Quelles sont les contraintes sur les ressources ? Les délais ? Attention néanmoins à ne pas tomber dans le piège de la sur-analyse. Il faut pouvoir tester rapidement un concept avec de la data.
Il s’agit ici d’industrialiser la démarche, ce qu’on appelle du MLOps. Il faudra s’assurer qu’une idée brillante des data scientists ne finira pas dans les cartons, après des essais infructueux et coûteux, parce que ces éléments n’auront pas été examinés au départ. Les exigences du MLOps sont à intégrer au plus tôt dans la phase de Discovery pour éviter la désillusion et la frustration des métiers une fois le projet initié.
Si la promesse et les contraintes de ce formidable outil sont comprises et intégrées dès cette étape, alors votre projet ML aura toutes les chances de finir en un produit ML réussi !
