Minimum ne veut pas dire bâclé
Le mot qui compte dans le sigle est « viable ». Un MVP est utilisé par de vrais utilisateurs, dans leur vrai travail, avec leurs vraies données. Il doit donc être fiable sur le peu qu'il fait. Une version instable ne produit aucun apprentissage exploitable : les utilisateurs abandonnent avant d'avoir pu dire si l'idée avait de la valeur.
Ce n'est pas non plus un prototype. Un prototype sert à montrer, il se jette. Un MVP sert à mesurer, il se prolonge. Cette distinction change tout dans la façon de le construire : on peut réduire le périmètre autant qu'on veut, on ne réduit pas la qualité des fondations sur lesquelles la suite va s'empiler.
Choisir ce qu'on enlève
Tout l'exercice consiste à identifier l'hypothèse la plus risquée et à ne garder que ce qui permet de la tester. Si le pari porte sur l'usage, un back-office sophistiqué est superflu : une saisie manuelle en interne suffit pour démarrer. Si le pari porte sur le volume, l'inverse est vrai.
Les candidats habituels à l'ajournement sont l'administration complète, les cas particuliers, les intégrations secondaires, la personnalisation et le reporting avancé. Ce qui ne se coupe pas : le parcours principal de bout en bout, la fiabilité des données et le minimum de sécurité.
La suite compte autant que le lancement
Un MVP livré sans plan de lecture ne sert à rien. Avant de démarrer, il faut savoir ce qu'on observera et ce qui déclenchera quelle décision : continuer, corriger la trajectoire ou arrêter. Un MVP qui ne peut pas conduire à un arrêt n'est pas un test, c'est une première version déguisée.
Ce cadrage se prépare pendant la phase de cadrage, qui transforme l'intention en périmètre chiffré. Pour un dirigeant qui hésite encore sur l'approche à retenir, notre comparatif no-code et développement sur mesure pose les critères de décision. Et quand la question est de savoir qui pilote la trajectoire produit, notre offre de CTO on demand répond au besoin sans recrutement.
