Développement de MVP : ce que ce n'est pas

La moitié des débats que les fondateurs ont sur leur MVP portent en réalité sur le sens du terme. L’un imagine un prototype grossier, l’autre un produit dépouillé mais soigné, un troisième un lancement public avec une liste d’attente. Tant que tout le monde ne travaille pas à partir de la même définition, les discussions sur le périmètre tournent en rond.

La façon la plus rapide de s’aligner est souvent d’écarter d’abord les mauvaises définitions. Voici six choses que le développement de MVP n’est pas.

1. Ce n’est pas un produit de faible qualité

Le « minimum » dans MVP décrit le périmètre, pas le soin. Un MVP fait moins de choses que le produit final. Les choses qu’il fait, il doit les faire de façon fiable.

Si votre MVP gère des paiements, le flux de paiement doit fonctionner à chaque fois, gérer les échecs proprement et ne pas perdre d’argent. S’il stocke des données clients, ces données doivent être raisonnablement sécurisées. Rogner sur les fonctionnalités que vous avez choisi d’inclure ne rend pas le produit plus minimal — cela le rend peu fiable, et les produits peu fiables produisent des preuves peu fiables.

Le bon modèle mental : construire une tranche étroite du produit à un vrai niveau, pas le produit entier à un mauvais niveau.

2. Ce n’est pas un prototype

Un prototype existe pour explorer ou communiquer une idée. Ce peut être des écrans cliquables sans backend, ou une construction grossière qui s’effondre si vous l’utilisez mal. C’est très bien, car son rôle est de répondre à « ce design a-t-il du sens » ou « peut-on montrer ceci à une partie prenante ».

Un MVP existe pour générer des preuves à partir de l’usage réel. De vraies personnes accomplissent de vraies tâches et leur comportement vous dit si l’hypothèse tient. Cela ne fonctionne que si le produit fonctionne réellement. Un prototype et un MVP répondent à des questions différentes, et construire l’un alors qu’il vous fallait l’autre fait perdre des semaines.

3. Ce n’est pas un lancement public

Vous n’avez pas besoin d’une annonce de lancement, d’un post Product Hunt ou d’un site marketing pour avoir un MVP. Vous avez besoin d’utilisateurs — mais cela peut être cinq clients cibles dans un pilote fermé.

En fait, un pilote discret est souvent meilleur pour la validation précoce. Un petit groupe pertinent vous donne un retour approfondi et pardonne les aspérités. Un lancement public disperse votre attention, attire des utilisateurs qui ne sont pas votre cible, et transforme chaque bug en problème de réputation avant que vous ayez appris quoi que ce soit.

Lancez en fanfare plus tard, une fois que les preuves disent que le produit mérite d’être lancé.

4. Ce n’est pas « la version 1 du vrai produit »

Un MVP est une expérience. Une partie de ce que vous construisez survivra dans le vrai produit. Une partie devrait être jetée une fois que vous avez appris ce que vous deviez apprendre.

Traiter le MVP comme la fondation permanente conduit à la sur-ingénierie — construire pour une échelle que vous n’avez pas, ajouter de la configuration pour des cas d’usage que vous devinez, choisir une architecture pour un produit que vous n’avez pas validé. Construisez le MVP pour qu’il soit correct et sûr, pas pour qu’il soit l’architecture finale. Vous pouvez faire évoluer un MVP validé sans sur-concevoir celui qui ne l’est pas.

5. Ce n’est pas entièrement automatisé

Derrière l’expérience côté client, un MVP peut tourner sur du travail manuel. Si votre produit finira par associer des freelances à des projets avec un algorithme, le MVP peut faire cette association à la main. S’il générera des rapports automatiquement, une personne peut compiler les premiers.

Ce n’est pas tricher. Cela vous permet de tester si les gens veulent le résultat avant d’investir dans la construction de la machinerie qui le produit. La règle est que l’expérience du client doit paraître réelle et fiable ; ce qui se passe en coulisses peut être un tableur et un humain.

6. Ce n’est pas une liste de fonctionnalités figée à laquelle vous vous êtes engagé il y a des mois

La liste de fonctionnalités que vous avez écrite au début du développement du MVP est une hypothèse sur ce qui est nécessaire pour tester votre supposition. À mesure que vous construisez et montrez des versions précoces aux utilisateurs, cette hypothèse doit se mettre à jour.

Les fondateurs qui figent la liste de fonctionnalités au premier jour livrent souvent des choses que personne n’utilise et passent à côté de choses que tout le monde réclame. La discipline n’est pas « ne jamais changer le périmètre » — c’est « changer le périmètre sur la base de preuves, pas de la dernière conversation que vous avez eue ». Priorisez pour l’apprentissage le plus rapide possible, et revoyez la liste à chaque sprint.

Alors qu’est-ce que c’est ?

Le développement de MVP, c’est	Ce n’est pas
Un produit étroit construit à un vrai niveau	Un produit complet mal construit
Un système fonctionnel que de vrais utilisateurs peuvent utiliser	Un prototype cliquable
Souvent un petit pilote fermé	Nécessairement un lancement public
Une expérience, en partie jetable	L’architecture permanente
Manuel en coulisses quand c’est possible	Entièrement automatisé dès le premier jour
Une hypothèse qui se met à jour avec les preuves	Une liste de fonctionnalités figée

En clair : le développement de MVP consiste à construire le plus petit produit fiable qui permet à de vraies personnes d’accomplir une tâche significative, afin d’apprendre si l’idée fonctionne avant de dépenser pour la construction complète.

Pour un parcours plus complet du processus lui-même, voir notre guide du développement de MVP pour les fondateurs, et le guide du MVP d’Atlassian couvre la boucle sous-jacente construire-mesurer-apprendre.

Questions fréquentes

Un MVP est-il juste une version moins chère et de moindre qualité du produit ?

Non. Un MVP est un produit plus petit, pas un produit plus mauvais. Les fonctionnalités qu'il contient doivent fonctionner de manière fiable et sûre. Ce qui le rend minimal, c'est le nombre de problèmes qu'il résout, pas le niveau auquel il les résout.

Construire un MVP signifie-t-il que je dois le lancer publiquement ?

Pas nécessairement. Un MVP a besoin de vrais utilisateurs pour générer de vraies preuves, mais cela peut être un petit pilote fermé avec une poignée de clients cibles plutôt qu'un lancement public. L'objectif est d'apprendre de l'usage réel, pas de la couverture presse.

Un prototype est-il la même chose qu'un MVP ?

Non. Un prototype montre comment quelque chose pourrait fonctionner et n'est souvent pas construit sur une vraie infrastructure. Un MVP est un produit fonctionnel que de vraies personnes utilisent pour accomplir une vraie tâche, ce qui rend ses preuves dignes de confiance.

Un MVP peut-il être un processus manuel plutôt qu'un logiciel ?

En partie. L'expérience côté client doit généralement être un vrai logiciel, mais le travail en coulisses peut être manuel pendant la validation précoce — un humain faisant ce qu'un algorithme fera un jour. C'est une façon légitime de tester la demande avant de construire l'automatisation.