C'est quoi vraiment un MVP, et pourquoi ça n'a rien à voir avec un prototype ou une version bâclée.
On se fait souvent poser la même question en rencontre d'analyse : c'est quoi au juste, un MVP.
Minimum viable product. Mais viable, ça dit pas tout. Ça fonctionne sur papier, un truc viable. Ça répond à l'objectif technique. Sauf que ça garantit pas que quelqu'un va vraiment vouloir s'en servir. Il manque une couche là dedans, celle du désirable. Un outil qui fait ce qu'il doit faire, mais que personne a le goût d'ouvrir, c'est pas vraiment un succès.
La confusion la plus fréquente, c'est entre un MVP et un prototype. Un prototype, c'est jetable. On le fait vite, il est pas fini, il est même pas toujours codé, des fois c'est juste des maquettes qu'on montre au client pour valider une idée avant d'aller plus loin.
Un MVP, c'est autre chose. C'est un produit fini, solide, prêt à être commercialisé.
Réduit à l'essentiel, mais pas bâclé pour autant.
C'est là que le vrai piège commence. Quand on rénove, il y a ce réflexe classique, tant qu'à ouvrir le mur, on va le faire comme il faut. Sauf que pour un outil numérique, cette logique-là s'applique pas. Faire petit, ça veut pas dire faire moins bien. C'est même souvent le contraire. Plus c'est petit, plus notre équipe reste concentrée sur quelque chose de réaliste, de bien pensé. La sécurité, l'accessibilité, la couche visuelle, rien de ça se néglige parce que le produit est réduit. Le minimum, chez nous, inclut déjà tout ça.
Ce qui prend du temps dans un MVP, c'est rarement la construction elle-même. C'est la réflexion d'avant. On compare ça souvent à une fondation. Ça peut sembler long à couler, mais une fois que c'est solide, les murs montent vite. La vraie job, c'est de savoir ce qu'on enlève. Une fonctionnalité pensée, dessinée, à laquelle quelqu'un tient, et qu'on retire quand même parce qu'elle répond pas au premier objectif. C'est jamais facile à entendre, mais c'est ce qui permet de livrer quelque chose qui va vraiment servir, plutôt qu'une version gonflée de tout ce qu'on aurait aimé y mettre.
Et ça, ça compte, parce que tester avec de vrais utilisateurs révèle des choses qu'on peut pas deviner de notre bureau. On a déjà vécu ça dans un projet interne. On avait pensé le produit pour un type de clientèle précis, on avait mis toutes les énergies là dessus. Une fois testé sur le terrain, on a découvert qu'un tout autre groupe s'y intéressait bien plus. Ce genre de surprise là, on peut juste pas l'avoir en restant dans notre tête. Avancer longtemps sans mettre l'outil dans les mains de vraies personnes, c'est avancer à l'aveugle, et ça peut mener loin dans la mauvaise direction.
Il y a aussi une nouvelle tentation qui rentre dans le décor depuis quelque temps. L'IA rend l'exécution tellement rapide qu'on peut être tenté de tout coder d'un coup, sans faire le travail de tri. Le résultat ressemble plus à un genre de patchwork qu'à un MVP. C'est exactement l'inverse de la démarche.
L'IA, chez nous, sert surtout une fois que la réflexion est faite.
Elle exécute vite ce qu'on a déjà pensé comme il faut. Elle remplace pas le moment où quelqu'un s'assoit et décide c'est quoi l'objectif numéro un, celui qu'il faut aller tester en premier.
Puis parfois, la meilleure réponse à un problème, c'est même pas un outil numérique. On le nomme franchement quand c'est le cas. Un objet physique ou une rencontre peut être une bien meilleure solution qu'une application, si c'est vraiment ça qui répond au besoin.
Un MVP, dans le fond, c'est un produit solide que tu mets dans les mains de vraies personnes, qui va probablement être plus petit que ce que tu avais imaginé au départ, et qui vaut la peine pareil. Ça permet d'avancer de façon organique, de se tromper sans que ça coûte une fortune, et d'ajuster le tir au fur et à mesure. C'est exigeant, mais c'est de même qu'on construit quelque chose qui va vraiment servir.
Si le sujet t'intéresse, on en jase plus en détail dans le dernier épisode de Code 18. Le lien est par ici.
-ÈL
