Le MVP d’un Produit Data Science

read time

3 min

Le MVP d’un Produit Data Science

La notion de MVP est maintenant largement démocratisée pour les produits web et mobiles. Définir les parcours et fonctionnalités indispensables pour un coût maîtrisé est un exercice que pratique la majorité des Products Managers. Mais comment appliquer le même principe à un Produit Data Science ?

Un modèle naïf, mais activé

Dans sa version la plus simple, un Produit Data Science est constitué de données prises en entrée (préparation), d’un algorithme qui les combine et les transforme en données de sortie (modélisation). Cette donnée est ensuite délivrée à l’utilisateur final de telle sorte qu’il puisse en tirer de la valeur (activation).

Une chaine de traitement simple, de bout en bout

Dans le cadre d’un MVP, l’objectif sera de simplifier au maximum ces trois briques.

Ingestion et préparation de la donnée

Lorsque vous avez imaginé votre Produit Data Science, vous avez probablement vu grand. Vous imaginiez déjà le croisement de dizaines de sources de données de format et de nature différents. Dans le cadre de la réalisation de votre MVP, vous allez vous contenter de l’ingestion des sources absolument nécessaires. Les autres pourront être ajoutées au gré des améliorations ultérieures.

Modélisation

Concernant la modélisation, nous allons chercher à nous abstraire d’un modèle de Machine Learning. Des algorithmes plus complexes pourront être mis en place par la suite. Néanmoins, dans un premier temps, nous allons nous contenter d’algorithmes dits naïfs. Cela signifie qu’ils se contenteront d’appliquer des règles métier sous la forme de règles mathématiques simples ; comme des moyennes ou des briques de Machine Learning pré-implémentées.
Non seulement cette approche permet d’obtenir rapidement un modèle en production, mais elle a de plus l’avantage d’obliger l’équipe à acquérir la connaissance métier pour réaliser cet algorithme, ce qui sera fort utile pour la suite.

Activation

Il reste maintenant à délivrer le résultat de ce premier modèle à l’utilisateur final. Nous avons vu que l’interface utilisateur cible de notre produit doit être IPAP, dans le cadre d’un MVP. Cependant, nous nous concentrerons sur les aspects Intuitif et Actionnable, et nous laisserons de côté les aspects Pratique et Personnalisable.
Pour cela, mettons automatiquement à disposition les résultats à notre utilisateur sous la forme la plus simple. Cette action lui permettra de comprendre les résultats du modèle et de les actionner. Les subtilités dans les résultats et leur mise en perspective avec d’autres éléments via des visualisations complexes n’est pas à l’ordre du jour, pas plus que l’interfaçage avec les outils du quotidien. Le seul objectif ici est de permettre à l’utilisateur de tester notre produit en conditions réelles. Ainsi, il pourra nous orienter sur sa pertinence.

Tester en conditions réelles

Photo d'une autoroute dans le brouillard

Par définition, le MVP est imparfait. Des prédictions ou recommandations risquent d’être erronées et l’activation peut ne pas être appropriée à certaines situations.
Dans quelques rares cas, la valeur apportée par le MVP est telle que l’on peut s’en accommoder. Malheureusement, les problèmes traités par un Produit Data Science sont souvent critiques. Il est alors nécessaire de prendre quelques dispositions pour permettre de tester votre MVP en conditions réelles ; et de bénéficier de retours utilisateurs tout en limitant l’impact de ces imperfections.

Garder une activation manuelle

En vision cible, le produit sera entièrement indépendant et automatisé. Néanmoins, il peut être intéressant de garder dans un premier temps une part manuelle pour l’activation. Prenons le cas d'un outil de type chatbot dédié à de la relation client. Plutôt que de proposer directement un moteur de conversation totalement automatisé, le MVP pourrait consister à aider les membres du service client (qui continueraient à piloter les conversations eux-mêmes) en leur suggérant des réponses appropriées. On apporte ainsi de la valeur (gain de temps) ; mais on récolte aussi un retour sur la qualité de la réponse (sélectionnée ou non).

Sur un sujet aussi critique que la prédiction de défaillance de pièces d’un avion, Air France utilise un système de test ingénieux. L’outil devait prédire la défaillance potentielle d’une pièce présente en plusieurs exemplaires sur un avion ; une principale, en position critique, dont la panne empêche l’aéronef de partir, et trois autres dont la défaillance permet de décoller sous condition. Ainsi, lorsque le modèle prédisait une défaillance de l’équipement sur la position critique, celle-ci était permutée avec une autre située sur une position moins critique. De cette manière, le risque de faux positif par mauvaise prédiction était écarté (pas de pièce changée inutilement), tout en permettant d’observer le comportement de la  pièce pour confirmer la défaillance (récolter des retours utilisateurs). Cela a permis de commencer à apporter de la valeur ; si la pièce déplacée en position moins critique rencontrait effectivement une défaillance, on évite l’annulation et l’avion pourra partir sous tolérance.

A/B Testing

Cette solution est utile lorsqu’il s’agit de remplacer un outil existant. Une partie des choix est réalisée par l’ancien outil et une partie par le nouveau. Dans le cas où il y a un nombre d’occurrences suffisant, on peut orienter un faible pourcentage de choix vers l’outil test. L'objectif est de garder une significativité statistique tout en limitant l’impact sur l’utilisateur.

Restreindre le périmètre

Lorsque le produit doit gérer beaucoup de situations, il est intéressant de se focaliser sur une sous-partie du problème. Prenons l’exemple d’un Produit Data Science ayant pour objectif de prédire les ventes d’une chaîne de magasins de fruits et légumes. Pour éviter de courir le risque de confier la totalité de l’approvisionnement à votre MVP, vous pouvez commencer par tester sur quelques magasins ou certains fruits spécifiques.

Trois stratégies s’offrent alors à vous :

Tableau explicatif des trois stratégie de MVP pour un produit Data Science

Quelle que soit la stratégie adoptée, l’enjeu sera par la suite de gérer l’élargissement progressif de votre produit au fur et à mesure que ses performances s’amélioreront.

Publié le 20 juin 2019

Mis à jour le 26 mars 2024

clipboardCopier le lien
Ecrit par
Nathan Chauliac
Nathan Chauliac Diplômé de l’EDHEC puis de Centrale Paris, Nathan début sa carrière dans la négociation de partenariats et le développement commercial pour diverses entreprises. Il rejoint Thiga en 2016 où il se passionne pour les produits Data Science. En tant que Head of Data Product Management, Nathan accompagne ses clients dans l’adoption d’une démarche produit de : l’initiation de leur premier produit Data Science à la mise en place d’une organisation produit pour les équipes les plus matures. Après 5 années passées chez Thiga, Nathan rejoint Alma, en tant que Head of Product.

Les prochains évènements

La Product Conf Paris

calendar

15 May 2024

Découvrir

Transformed Workshop by Marty Cagan

calendar

25 Apr 2024

Découvrir

Filles_ordinateur

Envie de partager tes idées ?


Plus de 20.000 passioné.e.s du Produit viennent sur notre média chaque mois. Retours d’expérience, opinions clivantes, n’hésite pas à nous proposer des contenus.

 

Contacter la rédaction