La gestion d'un projet data science peut être un vrai défi. Même si ces dernières années, nous avons bénéficié d'outils et de solutions technologiques pour accélérer leur mise en production, les projets data science nécessitent également une culture et un bon sens scientifique permettant de se poser la bonne problématique, ou plutôt la bonne question de recherche dont la résolution via un modèle IA apportera de la valeur business à l'entreprise. De plus, les projets data science présentent des caractéristiques intrinsèques telles que l’incertitude et l'expérimentation. Avoir un outil de suivi de la valeur business (ici la "value tracking tool" ou VTT) permettant de réduire cette incertitude et de réagir de manière appropriée à l’information disponible à chaque étape du projet est indispensable à son succès, mais définir la VTT n'est pas une mince affaire...

Lors des tests de recette de notre projet IA, j’avais un présentiment et je me disais : « est-ce que notre projet fera partie des 85% des projets data science qui inéluctablement finissent par échouer ?»

Et pourtant, nous avons « tout fait » pour le sécuriser. Nous avons livré :
1. Une prestation de conseil pour l’identification de la métrique business à tracker durant le projet avec le métier
2. Une activité d’évaluation (assessment) pour le choix du meilleur cas d’usage (quick win)
3. La définition d’une mesure qui traque la valeur business selon les performances des modèles deep learning (NLP) à entrainer … mais au fur à mesure que l’on commençait à recevoir les résultats de l’IA, nous avons compris que notre approche n’était pas complètement rodée.

Ce n’était pas une question de mauvaise compréhension du besoin, d’un manque de compétences en data science ni d’un non-savoir-faire en termes d’industrialisation.

La démarche suivie pour notre projet de Data Science

En effet, nos data scientists ont fait un énorme travail en termes de design et d’implémentation de leur process : spécialisation des modèles pré-entrainés dans le jargon du domaine du métier et fine-tuning des modèles pour une classification dont l’ensemble d’entrainement était alimenté par un framework Human-in-the-Loop Machine Learning (HuML) où le métier, très impliqué dans ce projet, réalisait la labélisation avec un outil off-the-shelf. Nous savions qu’il y avait une part de risque liée au volume de la labélisation car c’est du deep learning, mais l’un des objectifs du projet était de rendre le HuML partie intégrante de la (nouvelle) culture IA de l’entreprise et ainsi d’assurer l’apprentissage en continue des modèles.

D’un autre côté, nous sommes très attachés aux principes « opérations » de MLOps i.e., automatisation (pipelines CI/CD), reproductibilité, versioning, testing, monitoring … et nos pipelines étaient toutes automatisées, de la data pipeline de préparation de données à celle de l’entrainement des modèles, en passant par la pipeline HuML et par celle qui déploie les modèles, le tout dans un environnement cloud dont voici quelques termes clés : Azure DevOps, Databricks, MLFlow, PyTorch, AKS, Doccano, etc.

Nous avons beaucoup travaillé sur la valeur business/métier dans l’avant-projet en livrant une prestation AI Advisory incluant :

1. Des entretiens contextuels pour dresser le parcours utilisateur actuel et établir la courbe émotionnelle
2. Un atelier de définition et d’évaluation de la valeur business pour définir et prioriser les indicateurs de valeurs selon les objectifs stratégiques de l’entreprise
3. Et finalement, un atelier de parcours utilisateur cible permettant d’identifier les actions métier automatisables par l’IA.

Une fois le quick win sélectionné, le planning et le staffing approuvés selon les contraintes budgétaires du client, la prochaine étape consistait à bâtir l’outil (value tracking tool) nous permettant de suivre l’évolution de la valeur ou métrique business avec les résultats de l’IA. Nous avons bâti une relation mathématique directe entre les performances du modèle (accuracy) et des niveaux de satisfaction du métier liés à la qualité documentaire et au risque d’erreurs humaines (définis lors de l’advisory). En deux mots, il y avait une attente forte du métier dans la capacité de l’outil à identifier les risques.

La value tracking tool (VTT) était devenue l’obsession des data scientists. Nous n’avions que 3 sprints de 2 semaines pour générer les différentes versions des modèles (dépendantes de l’effort de labélisation du métier) et afficher la position du « point » correspondant sur la courbe du VTT. Durant ce temps, l’équipe front-end échangeait avec le métier sur l’ergonomie de l’IHM basés sur les prototypes de l’avant-projet. Côté data science, il nous suffisait de constater que les points sur la VTT « montaient » à la bonne vitesse au-dessus du seuil de valeur pour prouver que l’on apportait de la valeur. La VTT était tellement importante qu’elle était devenue le pré-requis pour déclencher les tests de recettes (UAT).

Durant les tests de recettes, le retour du métier était sans équivoque. L’IA ne procure pas suffisamment de bons résultats pour rassurer le métier sur son besoin premier : avoir confiance dans la capacité de l’outil à identifier les risques.

Analyse des difficultés rencontrées dans notre projet de Data Science

Même s’il est vrai qu’avec plus de labélisation les modèles pouvaient encore s’améliorer, je commençais à réaliser que la VTT n’avait pas rempli son rôle, car malgré les performances excellentes des modèles, l’utilisateur final n’était pas satisfait du retour de l’IA. Et la raison m’était apparue de manière très évidente, en effet, les résultats de l’IA étaient traités par des algorithmes de recherche approchante et par un ensemble de « règles » qui venaient finaliser la construction des résultats à retourner au front-end. Les performances des algorithmes de recherche approchante n’ont pas été prises en compte dans le VTT : la relation mathématique métrique business = fonction (métrique technique) était bien plus complexe que l’on imaginait. De plus, au fur et à mesure que nous présentions le tableau des résultats des UAT au métier, nous nous sommes rendu compte que nous aurions dû faire ce retour IA au métier de manière itérative en fin de chaque sprint avant les UAT, comme tout projet Agile qui se respecte. C’était dans la spécification de ce retour itératif avec le métier que se trouvait la clé de la VTT.

Dans tout projet informatique, il y a un contexte : c’était en effet un projet difficile en termes de planning avec une problématique liée à la licence de la solution Front End mais également avec des absences, parfois longues, liées au COVID et à la santé des proches des différents acteurs de ce projet ; il y a eu plusieurs mises en standby et redémarrages avec des réorganisations et des nouveaux on-boardings. Dans ce contexte, parfois les choses qui semblent si évidentes sont cachées derrière un voile d’optimisme non fondé.

Lessons Learned

Nous sommes toujours en discussion avec notre client pour continuer la labélisation HuML mais cette fois-ci, avec une évaluation adaptée du retour du backend (classification IA + recherche approchante). De cette discussion est apparue une nouvelle opportunité pour l’amélioration de l’Active Learning permettant de sélectionner les meilleurs échantillons à labéliser, … heureusement, car nous avons dépassé les coûts estimés pour ce projet.

Nous avons appris de nos échecs et nous allons forcément améliorer notre manière de livrer des projets data science. La session lessons learned a été en effet très utile et nous sommes ressortis grandis de cette expérience, car le sujet était très beau et la solution très innovante.