La Data Science, de l’idée au produit

Il y a quelques mois, nous avons publié notre nouveau TechTrends sur les Produits Data Science. Il est disponible en téléchargement ainsi qu’en version papier à la demande.

Mais que raconte-t-il ? C’est ce que nous allons voir dans cet article, qui a pour objectif de vous fournir les principaux messages que nous relayons dans ce livre blanc, messages que nous portons au quotidien dans nos différents projets.

Commençons par le problème : De quoi parle-t-on ?

Dans l’optique de résumer de manière très schématique les problèmes les plus fréquents rencontrés sur les projets Data Science, nous avons réalisé avec une vidéo toute en sketchs faits à la main :

Vous l’aurez compris, il est relativement aisé d’aller droit dans le mur dans un projet Data Science. La tentation est forte d’aller trop vite, de surfer sur les buzzwords et de foncer tête baissée dans les données avant même de se poser une question simple mais essentielle : Quel est le problème que je cherche à résoudre ?

En réalité, nous ne proposons rien de révolutionnaire, mais expliquons comment appliquer une approche de Product Management, d’agilité et de Craftsmanship à des sujets data. Ce que l’on constate, c’est que beaucoup de projets data ne parviennent pas à appliquer les mêmes règles que pour les projets de développement plus classiques, principalement par méconnaissance, ou pire, par simple volonté de dire “regardez, nous aussi on fait de l’IA !”

Voyons donc quelle démarche nous proposons dans ce TechTrends.

Explorer

Cette phrase résume à elle seule la majorité écrasante des problèmes rencontrés dans les projets Data Science. Avant de foncer tête baissée dans nos notebooks, prenons le temps de réfléchir un peu !

Explorer les points de douleur

Afin de comprendre au mieux les problématiques et les objectifs de vos utilisateurs cibles, vous pouvez faire un exercice du type Experience Map afin de vous concentrer sur les points réellement bloquants et ne pas passer à côté de quelque chose.

Voici un exemple pour une problématique de détection de fraudes :

Vous avez identifié en détail la problématique à résoudre, c’est une bonne chose de faite. Maintenant, il faut trouver des idées de résolution de cette dernière. Et surtout, faire en sorte que les idées priorisées suscitent l’adhésion de tous les interlocuteurs cible (de la DSI au métier en passant par le management) car ils n’ont souvent pas l’habitude de se parler.

Pour cela, des ateliers d’idéation divergence/convergence, inspirés du Design Thinking, sont très efficaces.

Établir une vision produit

Les idées priorisées semblent intéressantes d’un point de vue business, mais restent encore relativement floues. Il est temps d’affiner la Vision Produit associée à ce Use Case. Pour cela, s’aider d’un canvas pensé pour l’occasion permet de s’assurer que nous n’oublions rien et que nous gardons un cap global.

Nous vous proposons le suivant, que vous pouvez adapter à votre contexte :

C’est aussi le bon moment pour identifier les contraintes d’ownership de la donnée ou de RGPD, car ces réflexions arrivent bien souvent trop tard dans un projet et peuvent le mettre à mal.

Identifier et lever les incertitudes

Lors de la définition de votre vision produit, vous avez très probablement émis des hypothèses structurantes sur le Use Case identifié, qui soulèvent un certain nombre d’incertitudes :

• Incertitudes UX concernant la fluidité de l’expérience utilisateur sur votre produit : nous sommes d’accord sur le fait que l’envoi d’un CSV hebdomadaire n’est pas pérenne. Par contre, le développement d’un nouveau front peut créer de nouveaux points de douleur si c’est mal fait, il faut donc mettre quelque chose entre les mains d’un utilisateur pour le valider ;
• Incertitudes sur la faisabilité technique de votre produit : ce peut être des incertitudes au niveau de la qualité de la donnée, au niveau de la possibilité de répondre par du Machine Learning, ou au niveau de votre infrastructure.

Nous parlons ici de prototype, que certains appellent PoC (Proof of Concept). Quelle que soit appellation, rappelez-vous bien une chose : ces phases doivent être drastiquement limitées dans le temps. Il est arrivé trop souvent qu’un PoC dure 6 mois afin de traiter le sujet jusqu’au bout, mais ne mette autant de temps à être mis en production car pas compatible ou trop compliqué à refactorer. Nous recommandons une durée maximale de deux semaines pour un prototype, qui se focalise sur une question précise. Cette durée est renouvelable, mais dès que les plus grosses incertitudes sont levées, il faut savoir s’arrêter.

Il est important de bien noter la différence entre PoC et MVP (Minimum Viable Product) :

• Un PoC est jetable, son but étant d’aller très vite et de donner à l’utilisateur l’impression de réalité, afin de lever les plus grandes incertitudes avant de passer au développement du produit à proprement parler ;
• Un MVP répond aux contraintes de qualité sans compromis, c’est un produit minimal qui doit permettre de s’assurer que le tout soit techniquement faisable et économiquement viable (donc qu’il corresponde bien à ce que souhaite l’utilisateur)

Un MVP est ensuite enrichi jusqu’à ce qu’il soit vendable : c’est la notion de MMP (Minimum Marketable Product). Les releases suivantes seront alors des MMF (Minimum Marketable Features).

Donc, avant de vous lancer dans la réalisation d’un produit de bout en bout, vous pouvez réaliser des prototypes. Ces prototypes sont là pour lever des incertitudes, et n’ont aucune vocation à aller en production !

Converger vers la solution cible

Vous avez maintenant tous les éléments en main pour réaliser un produit de bout en bout qui réponde concrètement aux besoins de vos utilisateurs. Il est temps de se mettre en ordre de bataille pour faire un MVP !

S’organiser

Constituer son équipe

Pour réaliser un Produit Data Science, nous avons identifié 8 champs de compétences nécessaires :

• Data Ops
• Infrastructure / Architecture
• Data Engineering
• Développement logiciel
• Exploration / Statistiques
• Machine Learning
• Business
• Product Management

Plutôt que de chercher des titres sur un CV, il faut s’assurer de faire en sorte d’avoir une équipe pluridisciplinaire qui complète tous les champs de compétence nécessaire à la réalisation du produit.

Pour une meilleure compréhension, nous vous proposons un radar des compétences pour chaque profil type d’un projet data. Mais gardez en tête que le titre n’est pas important, il faut juste que l’équipe complète tout le spectre des compétences nécessaires.

L’important est de se souvenir qu’une équipe produit doit être pluridisciplinaire, et donc en mesure de gérer la chaîne de A à Z.

Définir une trajectoire

Le MVP d’un Produit Data Science correspond à une chaîne de traitement simple, mais de bout en bout, de l’ingestion des données à l’activation des résultats.

Rien de révolutionnaire, me direz-vous. Mais cela implique notamment pour un Data Scientist d’accepter dans un premier temps de mettre en production des modèles plus simples (qui peuvent aller des règles métier au réseau de neurones simple), pour itérer ensuite dessus. Certes un modèle plus avancé pourrait donner de meilleures performances, mais il mettrait plus de temps à être développé ou trop compliqué à industrialiser car le framework utilisé n’est pas compatible. Cela change du POC de 6 mois où on développe un modèle parfait, mais c’est indispensable pour s’assurer d’un passage en production efficace. Et parfois, cette version simplifiée répond déjà parfaitement au besoin de l’utilisateur final, donc autant tester cela rapidement et récupérer du feedback en conditions réelles !

Pour poser votre vision au-delà du MVP, vous pouvez utiliser des outils classiques comme les Story Map, que vous mettez à jour au fur et à mesure des avancements, avec de vrais objectifs pour les versions suivantes, et pas un objectif du type “améliorer le modèle”.

Fluidifier

La réalisation technique d’un Produit Data Science passe nécessairement par la création d’une usine logicielle adaptée. Elle doit avoir la particularité de faire bénéficier d’une mise en production rapide, tout en favorisant l’amélioration et l’innovation.

Si l’équipe redoute la mise en production et la perçoit comme une contrainte qui ralentit les phases exploratoires et donc l’innovation, c’est qu’elle n’est pas adaptée.

Industrialisation et packaging ne sont pas les ennemis du notebook

La phase d’industrialisation, au-delà des problématiques techniques de packaging, de refactoring et de tests, doit aussi permettre d’accélérer les phases exploratoires dans les notebooks des Data Scientists. Il est notamment possible de s’organiser pour faire en sorte que les packages réalisés et les transformations industrialisées soient utilisables directement dans les notebooks. Le Data Scientist se sert alors d’une base de code contrôlée, et non de son code exploratoire initial qui est susceptible de planter à tout moment.

Les équipes les plus matures développent aussi régulièrement leurs propres bibliothèques internes pour toutes les tâches d’exploration et de transformation de leurs données, afin de pouvoir se concentrer sur la réelle valeur ajoutée de la tâche à réaliser.

Exporter et mettre à disposition son modèle

A quoi bon entraîner des centaines d’arbres de décision si le modèle final est trop long à charger alors que le besoin requiert un temps de réponse minimal ? Vous comprenez tout l’intérêt de réfléchir au produit dans son ensemble avant d’implémenter quoi que ce soit, et surtout de mettre en production de manière itérative.

La partie serving de modèle de Machine Learning peut s’avérer être un calvaire si elle n’est pas pensée au plus tôt. Le choix de passer par le format de sérialisation standard du framework utilisé pour l’entraînement ou bien de passer par un format pivot indépendant peut avoir un fort impact sur les choix initiaux. Faites ce choix en prenant en considération les connaissances de l’équipe, les contraintes de votre environnement de production, ainsi que les Use Cases futurs que vous comptez développer afin de ne pas avoir à recommencer.

Monitorer tout le workflow pour réagir au plus tôt

Un bon monitoring va au-delà de l’alerting. Par exemple, monitorer toute votre chaîne de traitement vous permettra d’identifier des patterns anormaux dans vos données d’entrée qui pourraient perturber vos prédictions. C’est notamment à partir d’un bon monitoring des performances en production, couplé à du feedback métier, qu’il est intéressant de prioriser ses prochains développements, car on s’assure ainsi de se concentrer sur la problématique qui ajoute le plus de valeur au produit (et ce n’est pas toujours “améliorer le modèle” !).

Gérer la jungle des modèles et expérimentations menées

Enfin, quand on commence à multiplier les expérimentations et le nombre de personnes sur le projet, il devient rapidement impossible de savoir quel modèle correspond à quoi, sur quelles données il s’est entraîné, avec quelles features, etc. C’est un élément crucial pour prioriser les développements et bien gérer la mise en production des modèles ainsi que les phases d’A/B Testing.

Pour cela, les géants du web ont implémenté leur propre Machine Learning Platform (ex: Uber avec Michelangelo). D’un point de vue open source, le projet MLflow semble peu à peu se démarquer et est en train de devenir un standard.

Le petit mot de la fin

Dans ce TechTrends, nous parlons de Produit Data Science, et non pas simplement de projet. Et c’est bien là l’essentiel, qui est malheureusement souvent oublié. Un modèle de Machine Learning n’est pas une fin en soi, c’est un des éléments d’un produit complet qui doit répondre à un besoin concret.

Ce TechTrends n’aurait pas vu le jour sans la co-écriture de Nathan Chauliac, Product Manager chez Thiga, ainsi que l’aide de plus d’une trentaine de Xebians dans l’écriture, la correction et la relecture du contenu. Un grand merci à eux !