La différence entre une PoC et un MVP (et pourquoi les confondre coûte cher)
Comme il existe beaucoup de terminologie propre au monde de la data + IA qui génère de la confusion (vous n’avez pas besoin de savoir la différence entre un data warehouse et un data lake ; c’est pour ça que nous sommes là), la même chose se produit avec les termes propres à l’exploitation des entreprises modernes qui cherchent à être agiles. Parmi celles-ci, il y en a deux qui ont tendance à générer beaucoup de conflits : la PoC (proof of concept / preuve de concept) et le MVP (minimum viable product / produit minimum viable).
Une PoC répond à une question / Un MVP résout un problème.
La distinction est vraiment simple, une fois que vous savez ce que vous regardez.
Une preuve de concept (PoC) existe pour répondre à une seule question : est-ce que ça pourrait être fait ? Attention à la conjugaison verbale : ici nous sommes dans le domaine du potentiel. L’objectif est de partir d’une partie délimitée du problème, essayer de le résoudre avec les données réelles disponibles (ou ce qui s’en approche), et voir si l’idée fonctionne ou non. En définitive, c’est un expériment : il n’a pas d’utilisateurs, souvent même pas d’interface, ça ne tourne pas tout seul, etc. Ce qu’on cherche avec ça, pour être évident, c’est prouver le concept : voir si c’est faisable ou si ça a du sens.
Un produit minimum viable (MVP) répond à une question plus complexe : est-ce que ça marche dans le monde réel ? Ici nous parlons au présent, sur quelque chose de beaucoup plus solide et qui regarde vers l’avenir immédiat. C’est un développement qui doit (au moins partiellement) tourner en production, doit pouvoir s’intégrer aux systèmes existants, et doit pouvoir être donné à quelqu’un qui n’a rien à voir avec tout le processus de développement de la solution et qui soit capable de l’opérer. Dit simplement, c’est la plus petite et plus réduite version possible de quelque chose qui résout effectivement un problème particulier : peut-être pas avec toutes les fonctionnalités qu’il pourrait avoir, mais complet dans son origine et son cas d’usage.
À ce stade, il faut clarifier que ce n’est pas que l’un est “meilleur” que l’autre. Ce n’est pas une différence de qualité, mais de purpose et de fonction spécifique : la PoC doit démontrer que quelque chose est possible, et le MVP doit démontrer que c’est utile.
L’écart entre la PoC et le MVP est là où meurent les projets
C’est ici que les premiers conflits ont tendance à apparaître : la PoC fonctionne, génère beaucoup d’enthousiasme, et celui qui a reçu ce développement demande à la mettre en production. Ne pas comprendre la différence entre les deux concepts génère beaucoup d’inconfort lorsque le stakeholder (légitimement anxieux de voir les résultats) suppose que le pas entre l’un et l’autre est d’appuyer sur un bouton (ou pire, une simple question de volonté). Mais malheureusement, la réalité n’est pas toujours si simple.
Peut-être que vous n’y avez jamais réfléchi, mais regardez les différences concrètes entre l’un et l’autre :
- Ingestion automatisée des données. Dans la PoC vous avez téléchargé un CSV, un JSON, un type de données, et vous l’avez traité manuellement. En production, ces données doivent arriver seules, tous les jours, sans que personne ne fasse rien. Et encore faut-il qu’elles arrivent propres, nettes et prêtes à utiliser : pas de bidouillage ad-hoc.
- Infrastructure. La PoC a tourné sur la machine de quelqu’un. Et la phrase “mais c’est impossible, ça marche sur mon ordinateur” a été dite par des milliers ou des millions de devs dans l’histoire pour une raison : le MVP doit tourner quelque part qui ne soit pas la machine de la personne qui l’a créé.
- Monitoring. Dans une PoC, il n’existe pas de notion d’“erreur”, en tant qu’on suppose qu’on est en phase de validation d’une solution. Mais le MVP fait déjà des choses réelles, donc quand quelque chose inévitablement erre, fail, ou se casse, vous devez le découvrir le plus tôt possible.
- Re-entraînement. Le modèle de la PoC a été entraîné une fois. Mais un MVP nécessitera probablement un re-entraînement ou des ajustements au fur et à mesure que les données changent.
Chacun de ces points est un vrai travail, avec de vraies heures, qui coûte vrai argent.
PoC de churn vs. MVP de churn
Pour rendre ça encore plus concret, prenons un exemple très précis. Supposons qu’on nous demande un modèle pour prédire quels clients vont quitter l’entreprise : ni plus ni moins qu’un modèle classique de churn.
Si ce dont vous avez besoin est une PoC, ça signifie prendre les données historiques, entraîner un modèle et mesurer s’il prédit mieux que ce que vous avez aujourd’hui. Vous aurez probablement besoin de deux à trois semaines d’un data scientist et d’un peu de temps libre d’un data engineer qui vous aide avec un premier dump de données. À la fin, vous aurez un notebook de prototype, quelques métriques, et une réponse honnête sur le fait que l’idée est faisable ou non.
Maintenant, si ce dont vous avez besoin est un MVP, ça signifie connecter les sources de données, construire un pipeline qui tourne automatiquement, gérer l’analyse de qualité des données, entraîner le modèle, définir les seuils de décision avec l’équipe métier, construire une interface où quelqu’un peut voir les résultats, monitorer la performance et définir quand et comment se re-entraîner. Ici nous parlons, selon le cas et l’échelle, de deux à six mois de travail d’une équipe avec des data scientists, engineers, analysts et probablement quelqu’un avec une vision plus produit.
Qu’est-ce que “un modèle de churn” ? Les deux. Mais l’un coûte dix fois plus que l’autre, car l’un est une promesse avec beaucoup de garanties, mais l’autre génère un impact réel et tangible.
Et c’est ce que vous devez retenir de cet article : si vous n’avez pas une conversation franche et honnête sur laquelle des deux vous achetez avant de commencer, les chances que le projet se termine bien diminuent considérablement.
Quand est-ce que chacun a du sens
Il n’y en a pas un meilleur que l’autre. C’est une question de timing.
Faites une PoC quand :
- Vous ne savez pas si le problème peut être résolu avec les données que vous avez.
- Vous devez convaincre quelqu’un en interne que ça vaut l’investissement.
- Vous voulez comparer les approches avant de vous engager sur une.
Faites un MVP quand :
- Vous savez déjà que le problème peut être résolu (idéalement parce que vous avez déjà fait une PoC et avez bien documenté les décisions et hallazgos).
- Il y a un vrai utilisateur qui va utiliser ça toutes les semaines.
- Vous avez le budget pour construire non seulement le modèle mais tout ce qui l’entoure.
- Il y a quelqu’un en interne qui va owner ça quand ça se termine.
La question qui vaut la peine d’être posée
Avant de commencer tout projet de données ou IA, il y a une question qui devrait être posée lors de la première réunion :
L’objectif de ce projet est-il de savoir si quelque chose peut être fait, ou que quelque chose fonctionne en production ?
Si c’est le premier, c’est une PoC. Cela a une portée, un coût et un calendrier. Si c’est le deuxième, c’est un MVP. Cela a une portée différente, un coût différent et un calendrier différent. Et si vous ne savez pas lequel des deux vous avez besoin, c’est exactement la conversation à avoir avant de parler de budget.
