Partie 2 : la charrue, ou imaginer la solution

Vous connaissez vos futurs utilisateurs, vous savez ce qu’ils cherchent à faire, les problèmes auxquels ils font face et quelles solutions ils ont mis en place pour y remédier. Vous avez également une idée de la solution que vous voudriez développer, et ce qui pousserait vos utilisateurs à l’adopter. Il s’agit maintenant de planifier et de commencer le développement de votre solution !

1. Partir d’une solution minimale

Lorsque l’on construit un produit et a fortiori un produit digital, il est crucial de réfléchir à la solution la plus minimale possible au problème que l’on cherche à résoudre. C’est tout le sens du M de MVP, ou Minimum Viable Product : la plus petite solution viable au problème. En tant que créateur de produit, il peut être pénible de n’envisager qu’une version minimale ou incomplète de la vision que l’on a dans la tête, mais c’est un effort nécessaire.

Que se passe-t-il sinon ? Mettons que mon objectif soit de construire le premier engin volant de l’histoire. Je lui imagine un cockpit, un moteur, quatre ailes, une soute pour les bagages, un allume cigare et une foule en délire à l’atterrissage. J’ai une vision, et je refuse de sacrifier sa complexité sur l’autel du pragmatisme. J’ai un plan détaillé pour le construire, je commence donc par assembler l’aile gauche inférieure puis l’aile gauche supérieure, ensuite l’allume cigare c’est important, puis … j’ai un doute sur le besoin d’avoir quatre ailes. Je refais mes calculs, je m’allume un cigare, en effet deux ailes suffiraient. Je démonte l’aile gauche supérieure pour en faire une aile droite. Sauf que mes tôles sont tordues, il me faut un outil pour les redresser. Je vais voir le voisin pour lui emprunter l’outil, bon il est parti en vacances. Le temps passe, mes investisseurs me demandent où en est mon aéroplane, la foule en délire est rentrée mettre ses pantoufles depuis un moment et tout ce que j’ai c’est une table de pique-nique option tabagisme passif.

Qu’est-ce qu’un MVP ?

Raisonner en MVP permet d’éviter l’écueil classique de beaucoup de produits modernes et de répondre au problème, ni plus, ni moins, sans aucune fonctionnalité superflue et donc sans effort inutile.

2. Raisonner en itérations

Une fois le MVP construit et les premiers utilisateurs pilotes identifiés (rien à voir avec les biplans), beaucoup reste à faire pour transformer un produit minimal en une version qui réalise la vision. A cette étape, l’erreur à ne pas faire est la même que celle qui a été évitée en construisant un MVP, à savoir raisonner cahier des charges - livraison.

Mettons que votre produit soit une ville, et vous êtes son dictateur (éclairé !). Votre vision est celle d’une métropole hébergeant un million d’habitants, avec des centaines de commerces et d’activités en tout genre. Votre MVP est un village de 300 habitants et vous avez des versions minimales de votre ensemble minimal de fonctionnalités : il y a une boulangerie, une école, une épicerie, un hôpital et un système de traitement des déchets, mais pas de bowling (car le bowling n’est pas une fonctionnalité minimale).

Même s’il y a un bowling dans votre vision, rien n’assure un retour sur investissement de cette “fonctionnalité” à ce stade : mieux vaut certainement renforcer l’épicerie d’abord. Viendra ensuite l’amélioration du système de traitement des déchets par exemple, pour accommoder la population grandissante.

Mettons que vous arriviez au stade où vous êtes certain qu’un bowling vous assure un retour sur investissement : ne construisez pas un bowling à 76 pistes ! Commencez avec 4, quitte à agrandir plus tard si la première itération fonctionne bien. Déjà avec 4 lignes il va falloir prévoir les chaînes logistiques, le transport et l’hébergement des nouveaux employés, qui vont également avoir un impact sur l’école et l’hôpital, etc.

Raisonner en itérations successives fonctionnelles permet encore une fois d’éviter un effet tunnel (Georges Gamow spolié par la startup nation NDLR) où vous passerez 6 mois à développer une fonctionnalité sans réelle utilisation.

SimCity 3000 nous apprend qu’on ne commence pas une ville en construisant un gratte-ciel

Prenons un dernier (et réel) exemple, cette fois en Data Science. Vous êtes une grande entreprise et puisque vous ne travaillez plus avec du papier et des fax vous avez de grands volumes de données. Ces données sont éparpillées et hétérogènes, donc inutilisables en l’état. Vous souhaitez donc mettre en place des flux de collecte, traitement (nettoyage, déduplication, etc.), transformation, centralisation de ces données, afin d’entraîner un modèle de machine learning sur ces données.

Mettons que vous ayez trois systèmes qui vous génèrent des données : Alice (A), Bob (B), Cooper (C), et que dans cette expérience de pensée : l’ingestion des données d’une source prend une semaine, le traitement en prend deux, la transformation un mois et l’entraînement d’un modèle un mois également peu importe le volume de donnée d’entraînement.

Option 1 : vous adoptez une approche holistique de votre pipeline de donnée, en commençant par la collecte A, la collecte B, puis la collecte C. Vous enchaînez ensuite sur le traitement A, B, puis C, etc. jusqu’à l’entraînement de votre modèle de machine learning sur l’ensemble de données A∪B∪C. Le temps total qu’il vous aura fallu pour avoir un modèle fonctionnel (et donc qui a de la valeur) est donc 25 semaines.

Planification holistique d’un chantier de data engineering + data science

Option 2 : vous adoptez une approche itérative où vous allez traiter successivement les 3 sources de données du début jusqu’à la fin :

Le même chantier avec une planification itérative

Vous obtenez votre premier modèle utilisable en onze semaines, et vous faites trois livraisons itératives. Dans l’hypothèse où l’entraînement du modèle est parallélisable moyennant une semaine de mise en place, entraîner votre modèle 3 fois au lieu d’une ne vous “coûte” que deux semaines supplémentaires sur un projet complet de 6 mois.

Avoir un cycle de validation plus court permet également :

• de donner de la visibilité aux parties prenantes du projet (les fameux stakeholders),
• de corriger la trajectoire plus rapidement en cas d’évolution du besoin (changer de modèle ou de type de prédiction, changer une source de donnée, etc.),
• de prendre des décisions sur des résultats concrets plus rapidement (les rendus en data engineering et data science peuvent être un peu impalpables pour les non-tech),
• de féliciter l’équipe plus régulièrement, etc.

Conclusion

Tout ce qui a été écrit ici est valable pour le développement de produit en général et n’est pas réservé aux produits d’IA et de Data. L’état d’esprit qui permet de créer itérativement de bons produits est le même que celui qui permet d’éviter de créer des produits qui ne répondent pas à un besoin (voir partie 1 de l’article), à savoir un regard pragmatique sur le problème et sur la solution. C’est une manière de s’assurer que l’on crée le plus de valeur en limitant les ressources allouées, qui plus est dans un monde aux ressources finies.

Vous avez une vision d’un produit qui répondrait à un problème mais vous ne savez pas par où commencer ?

Vous avez besoin d’une équipe en data engineering ou data science qui ne se contente pas d’écrire du code mais qui réfléchit réellement à où va le produit ?

N’hésitez pas à nous contacter !