/w=32,quality=90,fit=scale-down){kind=small}
Raphael Thys
Les technologies de machine learning sont au point et se perfectionnent de plus en plus. Les données sont de plus en plus nombreuses et accessibles. Les capacités de calcul n’ont jamais été aussi importantes et faciles à activer. Malgré cela et bien que des succès manifestes aient envahi notre quotidien, de nombreux projets à base d’IA sont des échecs pour la plupart des entreprises.
La conduite du changement au cœur du problème…
Le premier facteur d’échec des projets de data sciences est l’humain. Quand on intègre de l’IA dans un processus on impacte le processus et les personnes qui y participent. Cela peut sembler évident, mais la grande majorité des entreprises néglige cet aspect en supposant que les gens vont s’adapter à ce changement puisqu’il permet, en général, un gain d’efficacité.
Toutefois, un large ensemble de salariés ne se sent pas ou peu concerné par l’efficacité de l’entreprise ; du moins pas assez pour s’adapter aux changements avec de la bonne volonté.
De plus, une réduction de la charge de travail liée à l’automatisation implique parfois une réduction du budget associé. Quel manager voudrait voir son équipe et son budget réduit en raison d’un gain d’efficacité ?
Enfin, la délégation d’une tâche dite complexe à une IA nécessite la confiance de celui qui va en exploiter les résultats. Nous avons besoin de comprendre pour faire confiance, or on ne peut comprendre aisément le pourquoi du comment du fonctionnement d’une IA.
… renforcée par de réelles difficultés de mise en production…
Le deuxième facteur d’échec des projets de data science est l’incapacité de leurs équipes à faire la mise en production dans de bonnes conditions.
Bien trop d’entreprises sont persuadées que leurs data scientists sont des magiciens capables de réaliser un projet d’IA de la collecte de données en passant par l’expérimentation jusqu’à la mise en production. La réalité étant que les data scientists sont très bons en modélisation mais généralement bien en peine de déployer des modèles en production.
Pour mettre en production un modèle, il faut investir dans des ressources dédiées à l’industrialisation. De nouveaux titres de postes sont inventés (« machine learning engineers »), mais ils reflètent un travail d’intégration technique qui a toujours existé dans le domaine du développement logiciel. Un modèle de machine learning ne peut faire l’économie de cette étape, tant au niveau de l’intégration applicative (les flux d’échanges de données pour alimenter le modèle et l’exposition des résultats aux autres applications du SI) que de l’intégration technique (déploiement sur le socle d’exécution, supervision, log, ordonnancement, sauvegarde, disponibilité, continuité…).
Il faut bien comprendre que le data scientist a la charge de l’expérimentation, il travaille en laboratoire et met au point des modèles répondant à des problèmes client. A l’inverse, le machine learning engineer est à l’usine, en charge de l’industrialisation de la chaîne de production. Ces rôles requièrent des compétences différentes mais aussi des personnalités différentes ; le data scientist a un esprit plus créatif alors le machine learning engineer est plus rigoureux et résiliant au stress.
… et amplifiée par un manque de collaboration avec les métiers
Le troisième facteur d’échec des projets d’IA est le manque de collaboration avec les métiers.
Les équipes data sciences sont souvent isolées dans l’organisation afin d’assurer leur indépendance et agilité. Cette indépendance se fait parfois au détriment d’une collaboration suffisamment étroite avec les métiers. En effet, pour de nombreux projets d’IA, l’implication du métier se limite à la définition du problème à traiter et à la validation de la solution.
Lorsque l’usage envisagé du modèle est mal compris par les équipes data science, un décalage peut se former entre ce que fait le modèle et ce qu’il en est attendu. La réussite d’un modèle data science nécessite un travail conséquent de définition de la problématique à traiter et du cas d’usage associé à effectuer en partenariat avec les équipes métiers.
Ce travail est souvent sous-estimé et le manque de collaboration avec les métiers peut poser problème à différents niveaux de la chaîne de recherche et développement d’une solution de data science.
Au niveau de la collecte de données, l’équipe data science peut collecter les mauvaises données et insérer inconsciemment un biais dans leur modèle. Par exemple, l’utilisation d’une donnée disponible a posteriori de la réalisation du phénomène à prédire. Un autre exemple de ce type est l’utilisation de données fortement corrélées avec la donnée à prédire mais avec sans impact causal (ex : le genre pour la prédiction de l’attribution d’un prêt).
Les équipes data science ne sont pas non plus capables d’identifier toutes les anomalies sans l’aide des métiers qui possèdent l’expertise nécessaire pour juger ces anomalies. Les données anormales peuvent impacter significativement la pertinence des modèles. A l’inverse des données peuvent être identifiées comme anormales sous l’angle statistique alors qu’elles représentent des situations réelles dans le contexte.
Afin de s’affranchir des problèmes de désalignement des modèles avec les objectifs métiers, il est nécessaire de définir une métrique métier sur la base de laquelle le modèle sera évalué. Le but de cette métrique est de refléter l’impact métier du modèle. Trop souvent les modèles sont évalués sur la base de métriques purement techniques qui ont généralement le défaut de considérer chaque situation pour laquelle le modèle va effectuer une prédiction comme équivalente. En réalité, c’est rarement le cas. Prenons l’exemple d’un modèle d’identification du churn, dans le cas où on utilise une métrique technique pour l’évaluation du modèle, on fait l’hypothèse que tous les clients sont aussi importants, en réalité on veut souvent se prémunir de la perte des clients les plus rentables en priorité.
Au-delà de l’insertion potentielle de biais, une collaboration avec les équipes métiers permet un gain d’efficacité considérable. Cette collaboration permet par ailleurs une meilleure compréhension du métier par les data scientists, ce qui est un des attraits forts de ce métier.
La solution : une expertise en conduite du changement à amener…
Afin de résoudre ces problèmes, il va être nécessaire d’accompagner les entreprises dans leur transformation aussi bien sur le plan technique qu’organisationnel. La mise en lumière des enjeux SI et leur explication de manière claire avec les équipes de direction est au cœur de la solution à apporter.
Les équipes en charge d’un projet data science doivent aborder les problématiques dans leur globalité avec une dimension processus, organisation et culture. Elles doivent préparer cette stratégie de conduite du changement en collaboration avec toutes les parties prenantes de l’entreprise : les équipes métiers comme les équipes informatiques.
Pour chaque modèle développé, il va être nécessaire d’apporter une interprétation de son fonctionnement et de ses prédictions. Cette interprétation peut se faire au niveau global et/ou au niveau local afin d’expliquer les facteurs influençant chaque prédiction. Cela permet de gagner la confiance des experts métiers qui vont pouvoir constater que le modèle s’appuie sur un raisonnement similaire au leur et donc faciliter leur adhésion.
… reposant sur une prise en compte des problématiques de production dès la phase de conception…
Il va s’agir alors de développer de façon progressive et raisonnée avec des approches MLops, en fonction des enjeux réels et de la maturité des équipes qui auront la charge d’en assurer la maintenance et l’exploitation.
…en collaboration étroite avec les métiers…
Les projets d’IA doivent alors être développés en partenariat avec les métiers de l’entreprise. Cela passe par une importante de phase de cadrage et définition du besoin durant laquelle les experts métiers sont autant impliqués que les équipes IT. Selon les organisations, les interlocuteurs peuvent être les métiers opérationnels ou bien leurs représentants comme la direction de l’organisation, de la transformation ou même parfois la DSI.
Durant cette phase, l’équipe projet va s’attacher à définir la métrique métier qui va guider tout le processus de développement. Celle-ci va permettre de s’assurer du bon alignement de la solution avec les objectifs métiers de l’entreprise.
… et mettre en place un processus structuré
Une des clés du succès d’un projet réussi passe par 5 phases élémentaires afin d’offrir un maximum de points d’étapes avec les équipes métiers. L’objectif premier de cette démarche est d’éviter de sauter trop vite à l’étape de modélisation sans avoir correctement posé le problème.
Identification de cas d’utilisation
Le but de cette étape est d’identifier en partenariat avec les métiers les cas d’utilisation de la data science au sein de l’entreprise. Cette étape a pour but de faire comprendre à l’entreprise et ses instances de direction ce que l’on peut faire et ne pas faire avec de la data science. Il s’agit de leur donner les clés pour identifier si un cas d’utilisation respecte les contraintes imposées par la data science (complétude et qualité des données, timing etc).
Cadrage et identification du besoin
Durant cette étape, l’équipe projet identifiera le besoin métier, le contexte et l’utilisation envisagée du modèle ainsi que les métriques métiers permettant de mesurer le bénéfice attendu. C’est aussi au cours de cette étape que vont être définies les contraintes techniques de la solution : urbanisme, cadre technique et d’exploitation, politique de sécurité SI etc.
Étude de faisabilité
Cette étape a pour but de valider la faisabilité technique d’un cas d’utilisation des data sciences, d’identifier la méthode à utiliser et d’estimer la charge. Pour cela, il va falloir effectuer un audit des données pour en définir la qualité et la pertinence vis-à-vis du problème à traiter. L’équipe projet va également devoir s’attacher à l’estimation d’un modèle de base (baseline), modèle le plus simple possible demandant le minimum d’effort. Sur la base de sa performance on pourra estimer la complexité du problème à traiter et la charge associée.
Preuve de concept
Le développement d’un projet Proof of Concept (preuve de concept) a pour but de produire un produit fonctionnel permettant le test de la solution en situation réelle. Durant cette phase seront produits les modules de nettoyage des données, d’extraction des caractéristiques (feature engineering) et d’entraînement de modèle et prédiction. Si besoin, une première version d’une interface de restitution des résultats doit être développée durant cette étape. Cette phase peut se conclure par la réalisation d’un AB test qui permet l’évaluation du modèle en situation réelle.
A l’issue de cette phase, le code développé est documenté, testé et prêt au déploiement.
Mise en place des pratiques MLOps
Une fois la preuve de concept effectuée et testée, il faut maintenant se concentrer sur la résilience et la flexibilité de la solution. En effet, le modèle est estimé sur la base de données historiques qui vont différer de plus en plus des données que le modèle traitera en production au fur et à mesure de la vie du modèle.
L’équipe en charge du projet pourra également être amenée à estimer de nouveaux modèles plus performants qu’il faudra mettre en production et mettre en place des workflows de déploiement automatisés de modèles.
L’objectif de cette phase est également de mettre en place différents outils d’exploitation et d’intégration de modèle afin d’assurer le bon fonctionnement de la solution en production, en faciliter la maintenance et le processus de déploiement.
En conclusion
Les raisons d’échecs des projets data science sont avant tout humaines et organisationnelles. Ne pas sous-estimer les étapes de préparation, de conduite du changement et adopter une démarche scientifique dans ce type de projet permet d’améliorer significativement les chances de réussite !