8 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
MVP, pour minimum viable product : produit minimum viable. Le terme revient dès qu’on parle de lancer un logiciel, et il désigne le plus souvent une première version. L’application, avec moins de fonctionnalités.
Allen Holub, architecte logiciel et formateur en agilité des organisations, rappelle qu’il en existe deux définitions. La plus ancienne, celle de Frank Robinson, qui a forgé le terme, en fait bien un produit. C’est celle que la plupart des gens ont en tête. L’autre vient d’Eric Ries, dans Lean Startup, et Holub la résume ainsi : « the minimum thing that tests the viability of a product idea ». La plus petite chose qui teste la viabilité d’une idée de produit.
Ce n’est pas une version 1. Ce n’est pas un produit du tout. C’est un test.
Un MVP répond à une seule question : ce produit vaut-il la peine d’être développé ? Si le test passe, l’idée est viable, et il devient raisonnable de construire. S’il échoue, on évite de passer des mois à construire ce dont personne ne veut.
Le MVP idéal, selon Holub, ne demande aucun développement. Son exemple : le MVP de DoorDash, c’était livrer des pizzas. Cela testait la viabilité de la livraison de repas à domicile, sans une ligne de code.
Quand il en faut, il reste minuscule. Holub parle d’un MVP qui se monte « in a day or two, maybe a couple of weeks on the outside ». Pour y arriver, il reprend la méthode de Ries : prendre le plus petit ensemble de fonctionnalités imaginable, le couper en deux, puis encore en deux, puis encore une fois. Et ne tester qu’une chose à la fois.
Dans un billet plus récent, il resserre encore la limite. Un MVP logiciel qui demande plus de quelques jours pour être construit et mis en ligne est, selon lui, beaucoup trop gros.
Parce qu’on ne sait pas d’avance quelles idées fonctionneront. Quand Microsoft mesure l’effet de ses idées par expérience contrôlée, une sur trois seulement améliore l’indicateur visé. Un tiers n’a aucun effet, un tiers le dégrade (Kohavi et Thomke, Harvard Business Review, 2017). Personne ne sait d’avance lesquelles. On l’apprend à l’usage.
Sans test, cet apprentissage arrive après la construction.
Un créateur d’application l’a raconté en vidéo. Fin 2024, il lance un logiciel en ligne, qu’il construit en public pendant trois à quatre mois. Il fait appel à un développeur, pour 25 000 €, et à une graphiste. Au lancement, les inscrits sont nombreux. Mais il manque des fonctionnalités qu’ils jugent essentielles. La trésorerie est épuisée, ce que rapporte l’application ne couvre pas ses coûts, et il la met en pause.
Ce récit ne dit rien de la qualité du travail fourni. Il dit autre chose. Le budget a été engagé sur une liste de fonctionnalités, avant le moindre retour d’utilisateur. Ce dont les utilisateurs avaient besoin, il l’a appris au lancement. À ce moment-là, il n’y avait plus d’argent pour le construire.
Les trois se ressemblent : petits, rapides, souvent incomplets. Ils ne répondent pas au même doute.
Le MVP répond à la question : ce produit mérite-t-il d’exister ? Ce qu’on en garde, c’est la réponse.
Le prototype répond à une autre : cette conception fonctionne-t-elle comme on le croit ? Un croquis d’écran au tableau blanc en est un. Un modèle qui teste le comportement d’une partie du programme sous la charge en est un autre. Celui-là doit être écrit en code de qualité production, puisqu’il rejoint ensuite le code principal. Holub résume la différence en deux phrases : « A prototype tests a design. An MVP determines if a product is worth building. »
La preuve de concept vient plus tôt encore. Elle vérifie qu’une décision technique encore à l’étude tiendra. Si l’on doute que la base de données supporte la charge, on écrit un programme qui ne fait rien d’autre qu’y écrire des données et les relire. Le résultat ne ressemble en rien au logiciel final.
Le spike, enfin, vient du vocabulaire de Jez Humble et Dave Farley, les deux auteurs du livre qui a défini la livraison continue. Dans Continuous Delivery (p. 425), c’est une réalisation jetable d’une exigence précise, menée pour réduire un risque d’analyse, de développement ou de test. Le code se jette. Seule la réponse compte.
Choisir l’instrument, c’est d’abord nommer son doute. Un doute sur la valeur appelle un MVP. Un doute sur la conception appelle un prototype. Un doute sur la faisabilité technique appelle une preuve de concept ou un spike.
Holub décrit deux écoles.
La première veut mettre le MVP entre les mains de clients potentiels au plus vite. Le code peut être bâclé. Il est jetable, et c’est le mot qui compte. Cette école parie que l’idée va échouer, et dépense donc le minimum.
La seconde traite le MVP comme le cœur d’un « squelette ambulant » : le premier morceau d’un système qui grandira ensuite par petites étapes. Elle parie que l’idée va marcher. Le code doit donc être de qualité production dès le départ. Le périmètre reste minuscule, et d’après l’expérience de Holub, un code de qualité se monte plus vite qu’un code bâclé.
Chacune se défend. Les mélanger, non. « These two approaches cannot coexist », écrit Holub. Faire d’un MVP de mauvaise qualité le cœur d’un système, c’est construire sur un noyau pourri dont on ne se débarrasse plus.
Dans son billet de septembre 2026, il penche pour la seconde école. Construire le MVP en code de production, avec ses tests et une interface correcte, n’ajoute selon lui qu’environ un jour. Et le résultat sert ensuite de squelette ambulant.
Dave Farley préfère au big upfront design une conception qui évolue par petits pas (vidéo « How To Avoid Big Upfront Design », chaîne Modern Software Engineering). Pour nous, un MVP construit en code de production suit ce chemin : il grandit pas à pas au lieu d’être conçu entièrement d’avance.
Ce que la première école codait à la main, des outils d’IA le produisent aujourd’hui. On décrit l’application voulue, sans lire le code que l’IA écrit : c’est le vibe coding. Holub lui reconnaît une place, celle des prototypes jetables.
Le créateur d’application en est arrivé là. En 2025, il découvre le vibe coding, et il estime que cela lui aurait pris deux jours, pour 0 €. Sur un point, son calcul rejoint celui de Holub : un test de quelques jours peut apprendre ce qui manque aux utilisateurs avant que le budget ne soit dépensé.
Mais un code jetable reste jetable. Le prototype vibe-codé répond à la question de l’idée. Il ne devient pas la fondation du logiciel qui suivra. Ce qu’un « cela marche » ne garantit pas, nous le détaillons dans notre article sur la création d’une application avec l’IA.
Un MVP qui passe ne clôt rien. Holub décrit la suite. On met en ligne la plus petite chose possible. La réaction est presque toujours « c’est bien, mais… ». Ce « mais » désigne le plus petit changement suivant. On le fait, on le met en ligne, et on recommence. Il ajoute : pas de grosse spécification en amont, y compris quand c’est une IA qui la reçoit.
Cette boucle ne s’arrête pas au lancement, et beaucoup l’oublient : on reste toujours dans une logique de test. Jeff Bezos, fondateur d’Amazon, l’écrit dans sa lettre aux actionnaires de 2016 : le « jour 2 », c’est l’immobilisme, et c’est pourquoi, chez Amazon, c’est toujours le « jour 1 ». Dans notre approche adaptative, chaque fonctionnalité est une hypothèse confrontée à la réalité de vos utilisateurs.
Nous développons votre application sur mesure pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer.
Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez. Une application n’est jamais finie.
Pourquoi ne pas tout prévoir dès le départ, la liste des fonctionnalités et le calendrier ? C’est la question que pose notre article sur l’approche prédictive et l’approche adaptative.
Notre guide reprend en détail les expériences de Kohavi, et ce que coûtent ensuite les fonctionnalités que personne n’utilise.
Vous avez une idée à tester, ou un logiciel à faire développer ? On en parle ?
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.
Quel budget pour créer une application ? Le montant ne suffit pas : visez un objectif plutôt qu'une liste, avec des utilisateurs dès le premier mois.