Minimum Worthy Product : le plus petit produit qui inspire confiance

En reconstruisant les surfaces publiques de ResumeGeni, je bute sans cesse sur la même frontière inconfortable. La version qui fonctionne techniquement n’est pas toujours celle que je placerai devant un candidat en recherche d’emploi. L’analyseur tourne. Le résultat s’affiche. Le parcours va jusqu’au bout. Et pourtant, quelque chose dans l’expérience dépense de la confiance au lieu d’en gagner. Je reste dessus une heure, je reconstruis la surface, la sensation disparaît — mais pas l’heure passée.

Cette tension, c’est tout le sujet de cet article. Deux forces tirent en sens inverse : livrer assez tôt pour mettre le produit au monde, et refuser de livrer un produit qui dilapide la confiance de l’utilisateur. La plupart des créateurs tranchent la tension en choisissant un camp puis en le défendant. La culture MVP choisit la vitesse. Le perfectionnisme choisit le fini. Les deux réponses échouent, parce que la tension est précisément le sujet.

Minimum Worthy Product pose une autre exigence : livrer le plus petit produit capable d’inspirer confiance, et non le plus petit produit que l’on peut défendre comme fonctionnel. Worthy est le plancher, pas le plafond. Minimum est une contrainte de périmètre, pas un rabais sur la qualité. Le créateur MWP retire des fonctionnalités jusqu’à ce que le produit puisse sortir, et tient chaque surface restante à un niveau que l’utilisateur perçoit. Le créateur MVP fait trop souvent l’inverse : il rogne la qualité pour préserver le périmètre. C’est cette substitution que les utilisateurs ressentent, et que les données révèlent.

En bref

MVP devait être un instrument d’apprentissage : le plus petit artefact capable de tester une hypothèse réelle auprès d’utilisateurs réels. La version dégradée est devenue un permis de livrer du travail bâclé. Minimum Worthy Product rétablit la contrainte manquante. Validez à moindre coût, puis construisez le plus petit produit capable d’inspirer confiance. Minimum taille dans le périmètre. Worthy tient la surface restante à un niveau que l’utilisateur perçoit.

---

Ce que le MVP a vu juste

L’idée originale du MVP n’autorisait nullement à livrer du travail bâclé. Elle donnait aux fondateurs un moyen d’arrêter de passer des mois à construire la mauvaise chose.¹

Eric Ries a écrit The Lean Startup pour traiter un échec précis : des ingénieurs bâtissant des produits élaborés pour des marchés inexistants. Le MVP était un instrument d’apprentissage. On construisait le plus petit artefact capable de tester une hypothèse précise auprès d’utilisateurs réels, on menait l’expérience, on mesurait ce qui se produisait, et l’on révisait sa compréhension selon que l’hypothèse survivait ou non au contact du réel. Le « minimum » du MVP désignait un effondrement du périmètre au service de l’apprentissage, pas un effondrement de la qualité au service de la livraison.

Le cadrage d’origine tient toujours. Je m’en sers. Ma séquence de validation de startup (problème, solution, canal, revenu, échelle) descend directement de Ries. L’argument en faveur du test des hypothèses peu coûteuses à valider avant d’investir dans du code est le même que celui du MWP en aval de la validation : à chaque étape son instrument. Les pages d’atterrissage et les entretiens sont des MVP de désirabilité. Les prototypes et les sondes techniques sont des MVP de faisabilité. Le MWP est l’exigence que l’on applique une fois les preuves de validation en main, au moment de construire la première chose réelle à laquelle des utilisateurs réels vont se fier.

Je ne plaide donc pas contre le MVP. Je plaide contre ce que le MVP est devenu en pratique.

Où la culture MVP s’est ramollie

Quelque part en chemin, « apprendre vite » est devenu « livrer n’importe quoi », et la substitution a fait de vrais dégâts.

Trois glissements ont brisé l’idée d’origine :

1. « Si la première version de votre produit ne vous fait pas honte, vous l’avez lancée trop tard » (la formule de Reid Hoffman⁴) est devenue un permis d’avoir honte de l’exécution, et non du périmètre. L’affirmation d’origine porte sur le nombre de fonctionnalités : livrez si peu de fonctionnalités que vous aurez honte, plus tard, de la maigreur du produit. La version dégradée porte sur le soin apporté au travail : livrez quelque chose de si grossier que vous aurez honte, plus tard, de son allure et de la sensation qu’il laissait. Ce n’est pas la même phrase.

2. « Livrer vite » a remplacé « apprendre vite » comme résultat mesurable. Apprendre est un processus lent, agaçant, qui produit une compréhension qualitative. Livrer est un processus rapide, lisible, qui produit un artefact daté. Quand on ne sait plus distinguer les deux, l’artefact gagne par défaut. Les équipes livrent chaque semaine et cessent complètement d’apprendre, parce que personne ne mesure ce qu’elles ont appris.

3. Le modèle du capital-risque (lever, croître, sortir) récompense le fait de livrer quoi que ce soit plutôt que de livrer bien. Si votre travail consiste à démontrer votre élan au prochain chèque, un produit édulcoré franchit au moins la barre du « nous avons livré ». Un produit digne de ce nom mais retardé est, vu de l’extérieur, indiscernable d’une équipe à l’arrêt. La pente des incitations descend.

Aucune de ces dégradations n’est imputable au MVP tel qu’il a été formulé. Elles sont ce que le MVP est devenu dans la bouche de gens qui avaient besoin d’une justification pour livrer du travail faible.

Les utilisateurs en subissent le résultat. Cela se voit dans les données. Le parcours d’accueil va jusqu’au bout, mais la deuxième session n’arrive jamais. Les utilisateurs ouvrent l’e-mail d’inscription et ne cliquent jamais sur le lien. Les tickets d’assistance se concentrent sur des tâches que le produit prétend prendre en charge. La courbe d’attrition décroît vers zéro au lieu de s’aplatir sur un noyau. Ces résultats ne sont pas des cas limites. Ils sont le coût central d’une construction menée à un niveau auquel l’utilisateur ne peut pas croire.

Minimum ne veut pas dire inachevé

Minimum est une contrainte de périmètre, pas un rabais sur la qualité.

Concrètement : définissez l’utilisateur. Définissez l’unique résultat que le produit promet de délivrer. Retirez toute fonctionnalité non indispensable à ce résultat. Puis tenez la surface restante à la barre de qualité pleine et entière. Minimum taille dans le périmètre jusqu’à ce que le produit puisse sortir. Minimum ne rabote pas l’exigence pour que le produit sorte plus tôt.

Les deux exigences côte à côte :

Dimension	MVP (tel qu’il est pratiqué)	MWP
Objectif	Livrer quelque chose pour prouver le mouvement	Livrer quelque chose qui gagne la confiance de l’utilisateur
Périmètre	Le plus petit artefact défendable comme fonctionnel	La plus petite surface qui tient la promesse validée
Barre de qualité	Fonctionne assez bien pour tourner	Le niveau que l’utilisateur perçoit
Règle d’arrêt	« C’est livré »	Les deux épreuves sont passées ; après trois reconstructions ratées, on reconstruit le brief
Signal de réussite	Une date au changelog	Cinq indicateurs de confiance : deuxième réussite, rapport J30/J1, forme de la cohorte, recommandation spontanée, friction qualité
Mode d’échec	Une première impression faible brûle la confiance	Le raffinement devient une cachette

Prenons un exemple concret. La promesse de ResumeGeni : un CV compatible ATS, correctement analysé par les systèmes de suivi des candidatures, qui donne au candidat une vraie chance d’atteindre le responsable du recrutement. La version minimale de cette promesse peut exclure :

• Les modèles personnalisés
• La collaboration en équipe
• Les tableaux de bord analytiques
• Les intégrations avec LinkedIn, Indeed ou les sites d’emploi
• L’historique des versions
• Les formats d’export au-delà d’un seul

Ce que la version minimale ne peut pas exclure : une analyse fidèle du CV source, une évaluation honnête des manques, des réécritures concrètes réellement adaptées à l’offre, un export qui s’ouvre proprement dans Word, et un parcours qui met le candidat en sécurité. On peut livrer sans modèles. On ne peut pas livrer avec des conseils vagues, des exports cassés ou une rédaction qui donne à un utilisateur fragilisé le sentiment que le produit le prend pour un pigeon.

Minimum est un couteau appliqué au backlog du produit. Worthy est un couteau appliqué à la surface qui reste.

Worthy est le plancher

Un produit digne de ce nom n’a pas à contenir tout ce que vous imaginez. Tout ce qu’il contient doit respecter l’utilisateur.

Au sens opérationnel, worthy signifie que le produit résout le problème validé suffisamment bien pour que l’utilisateur emporte sa confiance dans l’interaction suivante. Il voit ce que vous étiez en train de construire et il croit qu’il y aura une suite. La première session cesse d’être une épreuve à endurer pour devenir une poignée de main qui ouvre la porte à la deuxième. Les produits dignes de ce nom accumulent de la confiance. Les produits à moitié dignes la dépensent.

La confiance ne se simule pas. Les produits que les utilisateurs connaissent déjà façonnent ce qu’ils attendent du vôtre.⁵ Quand votre produit se situe sous ces attentes (boutons qui ne répondent pas, textes qui tergiversent, parcours qui les abandonnent à mi-chemin), les utilisateurs enregistrent l’écart avant même de savoir le formuler. Ils partent, ils ne reviennent pas, et aucun e-mail de réengagement ne sauvera la session qu’ils ont déjà classée sans suite.

La question est-ce digne de ce nom ? n’est pas une question de goût. C’est une question de confiance. La réponse de l’utilisateur se lit dans son comportement.

La validation d’abord, la dignité ensuite

L’objection la plus forte au MWP : ce sont les utilisateurs qui décident de la dignité d’un produit, par le contact, pas la conviction de celui qui le fabrique. Exact. Le MWP ne remplace pas le jugement de l’utilisateur. Il vous empêche de brûler une confiance déjà validée avant que les premiers utilisateurs réels aient pu juger.

Le contact avec l’utilisateur relève de la validation. Avant de construire, vous testez si le problème est réel, si votre solution y répond, si vous pouvez atteindre les utilisateurs et s’ils paieront. Les preuves viennent des pages d’atterrissage, des entretiens, des tests concierge, des prototypes et des listes d’attente. J’ai détaillé cette séquence ailleurs. Une hypothèse qui survit au parcours du combattant a gagné le droit d’être construite.

Le MWP commence après la validation. La validation demande si quelqu’un veut la promesse. Le MWP demande si la surface livrée mérite la confiance que la validation a déjà gagnée. La rétention, la recommandation et les données de friction qualité disent ensuite si le jugement a tenu.

Sauter la validation en appelant le résultat MWP donne une belle réponse à une question que personne n’a posée. Sauter le MWP en appelant le résultat « lean » donne un produit édulcoré qui dilapide la confiance déjà gagnée par la validation.

La bonne séquence : valider à moindre coût auprès d’utilisateurs réels, puis construire le plus petit produit digne de la promesse validée. Faites les deux. N’en sautez aucun.

Les deux épreuves : Jiro et Steve

Un produit doit passer deux épreuves distinctes avant que je le déclare terminé.

Le Jiro Test demande si le travail est juste. Des preuves que le produit fonctionne. Le produit gère ses cas limites. Les détails invisibles tiennent. Les affirmations citent des preuves concrètes. Pas de faux-fuyants ; je crois que ne vaut pas preuve. Le Jiro Test sépare le métier de la simple ambition. J’ai écrit sur la philosophie de qualité Jiro appliquée aux agents IA ; la même discipline vaut pour toute surface produit. La barrière de la preuve est la façon dont je rends cette épreuve opérationnelle dans les rapports de code.

Le Steve Test demande si le travail mérite d’exister. Un point de vue visible. Une cohérence d’ensemble. Une surface qui préserve la dignité de l’utilisateur. Un mécanisme de plaisir ou de clarté que le lecteur peut identifier, pas une vague promesse. Le Steve Test sépare le produit du stock. Une chose livrée n’est pas automatiquement une chose digne de ce nom. La démonstration complète sur le goût comme système technique tient dans un autre article ; ici, la définition opérationnelle ci-dessus suffit à porter le propos.

Les deux épreuves doivent être passées. Si Jiro échoue, on s’arrête et on corrige. Si Steve échoue, on reconstruit. Si les deux échouent, le problème est en amont, dans le brief.

La question à poser quand le jugement hésite est la plus simple de toute la pile : est-ce que je signerais cela de mon nom sans broncher ? Si la réponse est non, le travail n’est pas encore digne de ce nom.

La preuve sous vos pieds : blakecrosley.com

La page que vous lisez a commencé comme une petite expérience dans ma transition sans feuille de route. Elle fait aussi partie de la démonstration.

Pas de React. Pas de Tailwind. Pas de webpack, pas de Vite, pas de bundler, aucune étape de build. FastAPI sert le site entier directement : HTMX, Alpine.js, Jinja2 et du CSS pur, rien entre les deux. Sur la version du 17 avril 2026, le transfert initial de la page pèse entre 45 et 60 Ko et Lighthouse affiche 100 sur 100 en performance, accessibilité, bonnes pratiques et SEO.³ Le site tourne en dix langues, publie de bout en bout un nouveau guide ou un nouvel article en un seul git push, et ne contient aucun node_modules/ nulle part dans le dépôt.

La version MVP du site aurait suivi le conseil par défaut de 2026 — Next.js, Tailwind, Vercel. Elle serait sortie en un week-end. Elle aurait été correcte. Vous seriez arrivé ici, la page se serait chargée en un temps respectable. La différence n’aurait pas tenu à la capacité. Elle aurait tenu au goût. J’ai écrit sur la façon dont un score Lighthouse parfait se construit réellement ; en résumé, chaque Ko de données que le lecteur n’a pas à télécharger est une forme de respect.

La version MWP a demandé plus de travail. Elle a exigé d’écrire de zéro les patterns HTMX, de régler la typographie à la main, d’auto-héberger les polices, de faire passer la chaîne i18n par Cloudflare D1 et de traiter l’absence d’outil de build comme une fonctionnalité. La version MWP n’est pas techniquement plus capable que la pile par défaut. Elle est plus intentionnelle. Et cette intention se manifeste par moins de coutures visibles pour le lecteur.

Métier invisible. Le lecteur ne voit pas les décisions. Le lecteur ressent l’absence de friction. L’absence de friction est le mécanisme.

La preuve côté client : ResumeGeni

ResumeGeni place la barre plus haut, parce que l’utilisateur n’est pas en train de flâner. Il essaie d’améliorer un document qui décidera peut-être s’il obtient un entretien d’embauche.

La validation de ResumeGeni est revenue nette : page d’atterrissage, liste d’attente, publications ciblées sur Reddit et LinkedIn, 340 inscriptions par e-mail en deux semaines, 12 demandes directes sur la date d’ouverture du produit et 3 propositions spontanées de payer pour un accès anticipé.⁷ La séquence de validation disait : construisez. Construire était la décision facile. À quoi devait ressembler cette construction, voilà la décision difficile — et c’est là que le MWP a fait le vrai travail.

Deux catégories de coupes. La première portait sur les fonctionnalités : modèles, collaboration, analytique, dizaines de variantes d’export, intégrations avec les sites d’emploi. Toutes coupées. Aucune ne fait partie de la promesse.

La seconde portait sur le niveau que j’étais prêt à tenir pour ce qui restait. Ce niveau, lui, ne se coupe pas. L’analyseur ne peut pas être faible. Les conseils ne peuvent pas être vagues. Les exports ne peuvent pas être cassés. Le texte ne peut pas traiter un utilisateur fragilisé comme une métrique de conversion. Le parcours ne peut pas abandonner quelqu’un en cours de route sous prétexte que je n’avais eu le temps de traiter que le chemin idéal.

La version MVP aurait livré un assistant en dix étapes, un résultat générique, un mur d’abonnement placé au meilleur moment et une page de feuille de route promettant tout ce qui avait été coupé. Elle aurait été fonctionnelle. Elle aurait peut-être converti quelques utilisateurs une fois. Elle aurait aussi appris à la première cohorte à se méfier du produit — et cette leçon devient une mauvaise fondation pour un usage aussi sensible.

La version MWP est plus petite que je ne le voudrais. Chaque fonctionnalité que j’ai coupée, je voudrai la récupérer. L’exigence, c’est que le produit sur lequel les utilisateurs atterrissent les respecte. C’est la seule fondation sur laquelle je sache bâtir.

Ce que les utilisateurs vous disent vraiment

Les utilisateurs disent rarement maintenant je crois en ce produit. Mais leur comportement laisse des traces.⁶

Cinq signaux que je surveille, calibrés pour un public de créateurs :

1. Taux de deuxième réussite. Le pourcentage d’utilisateurs activés qui reviennent et accomplissent une deuxième fois le résultat central, dans la fenêtre d’usage naturelle. La confiance se construit à la deuxième réussite, pas à la première. Pour les produits récurrents, je considère un taux inférieur à 30 % comme un signal de reconstruction. Pour les produits épisodiques, mesurez le cycle d’usage naturel suivant plutôt que de forcer une fenêtre de 30 jours.

2. Rétention à 30 jours rapportée à l’activation à 1 jour. Les e-mails de réengagement peuvent truquer la rétention brute. Pas le rapport. Pour les produits à usage hebdomadaire ou mensuel, ce rapport vous dit si l’activation relevait de la confiance ou d’une curiosité sans lendemain. En dessous de 0,25, j’y vois un avertissement ; en dessous de 0,15, un verdict.

3. Forme de la courbe de rétention par cohorte. Les produits dignes de ce nom s’aplatissent après la chute initiale. Les produits faibles continuent de décroître. Tracez les courbes : leur forme raconte ce que les moyennes dissimulent. Si la courbe ne s’aplatit jamais, il n’existe aucun noyau d’utilisateurs qui font réellement confiance au produit.

4. Part de recommandation spontanée non incitée. Le pourcentage de nouveaux utilisateurs activés arrivant par recommandation directe, résultat partagé ou bouche-à-oreille — hors canaux payants, hors primes de parrainage. On parle des produits dignes de ce nom. On oublie les produits faibles. Si la catégorie comporte un moment de partage naturel et que la recommandation spontanée reste sous les 10 % des nouveaux utilisateurs, le produit ne gagne pas sa recommandation.

5. Taux de friction qualité. Suivez les remboursements, les clics de rage, les tickets d’assistance, les exports échoués et les corrections manuelles pour 100 utilisateurs activés, par cohorte. Ce taux mesure la douleur que le produit inflige aux utilisateurs qu’il prétend servir. Il devrait baisser à mesure que le produit mûrit. S’il stagne ou grimpe, le problème est le produit, pas le processus d’assistance.

Aucun de ces signaux n’est une métrique de vanité. Chacun est difficile à truquer. Chacun renvoie à une expérience utilisateur réelle qui a gagné la confiance ou l’a perdue. Si vous ne pouvez pas citer les chiffres d’une cohorte précise sur les cinq, vous ne savez pas encore si votre produit est digne de ce nom.

Quand le MVP ou le prototype reste le bon geste

Le MWP n’est pas la bonne exigence pour tout artefact.

Trois cas où la logique du MVP ou du prototype reste juste :

• Avant la validation. Pages d’atterrissage, entretiens, tests concierge, prototypes cliquables. L’objectif est d’apprendre, pas de soigner l’exécution. Livrez la version moche qui teste l’hypothèse. Livrez-la aujourd’hui. C’est la séquence de validation qui s’applique ici, pas le MWP.

• Sondes de faisabilité. Quand l’inconnue est technique (le modèle sait-il répondre à ce type de requête dans la latence dont j’ai besoin ? l’API encaisse-t-elle la charge ? l’analyseur tiendra-t-il sur la longue traîne des entrées réelles ?), construisez le plus petit instrument jetable qui répond à la question. Ne cherchez pas à le rendre digne de ce nom. Rendez-le véridique.

• Bêtas à effet de réseau. Les places de marché, les produits communautaires et les outils à effet de réseau ont besoin d’une vraie base d’utilisateurs avant qu’on puisse les juger : l’artefact correct est donc une bêta clairement étiquetée, instrumentée par cohorte. Livrer une bêta ne remplace pas la version digne de ce nom ; c’est le seul moyen de découvrir ce que « digne » veut dire ici. Étiquetez la surface honnêtement comme une bêta. Ne la déguisez pas en v1.

Le MWP vaut pour la première surface produit réelle. Si vous êtes encore en amont de cette surface (apprentissage, test, découverte), les bons outils se trouvent plus tôt dans la séquence.

Le plafond de reconstructions

Une exigence élevée sans règle d’arrêt devient de l’évitement.

La doctrine que j’applique à tout travail non trivial fixe un plafond de trois tentatives honnêtes.² Une tentative honnête suppose d’avoir identifié l’axe défaillant, nommé la correction précise, changé l’approche de façon substantielle et réévalué le travail au regard des deux épreuves. Trois répétitions de la même passe de finition ne comptent pas pour trois tentatives. Elles comptent pour une seule tentative ratée, répétée trois fois.

Après trois reconstructions honnêtes qui ne parviennent pas à produire un produit digne de ce nom, le problème n’est pas le métier. Il est en amont : dans le cadrage, le périmètre, le brief ou l’équipe. Arrêtez de reconstruire la surface et regardez la prémisse. Parfois la promesse était trop grosse pour le périmètre que vous pouvez réellement tenir à ce niveau. Parfois la validation était plus molle que vous ne le pensiez. Parfois le problème n’est pas du tout un problème de produit.

Le plafond de reconstructions règle deux échecs opposés. Il refuse de bénir le travail faible, et il empêche le raffinement de devenir une cachette. La cible n’est pas la perfection. La cible est digne et livré. Pas pur et éternellement en attente.

Le perfectionnisme, c’est le métier sans le courage. Si vous en êtes à la quatrième reconstruction de la même surface, vous avez cessé de faire un produit et commencé à vous servir du projet comme d’une cachette.

À retenir

Pour les fondateurs et créateurs solos : - Validez à moindre coût avant la moindre ligne de code. Le MWP s’applique après que la validation a confirmé l’adéquation au marché. - Coupez les fonctionnalités sans état d’âme. Tenez la surface restante à la barre de qualité pleine et entière. - Livrez au niveau « digne ». Plafonnez les reconstructions à trois. Ensuite, remontez au brief.

Pour les responsables produit et PM : - Mesurez directement les indicateurs de confiance : taux de deuxième réussite, rapport rétention J30 sur activation J1, forme de la courbe de cohorte, part de recommandation spontanée, taux de friction qualité pour 100 utilisateurs. - Séparez les discussions de périmètre des discussions de qualité. Les coupes de périmètre se négocient. Les coupes de qualité, non. - Protégez l’expérience de votre première cohorte. Une première impression dégradée sur des utilisateurs fragilisés coûte des années à rattraper.

Pour les responsables d’ingénierie : - Nommez une barrière Jiro et une barrière Steve pour chaque surface que vous livrez. Les deux doivent être franchies. - Prévoyez du budget pour le travail invisible. L’écart entre « ça marche » et « c’est digne » se loge en général dans les détails que personne ne montre du doigt. - Inscrivez un plafond de reconstructions dans votre processus, pour que le perfectionnisme cesse de se déguiser en raffinement.

Pour les designers : - Le point de vue n’est pas une décoration ; c’est le mécanisme qui rend le produit reconnaissable. - Une surface digne de ce nom refuse des choses, et cela se voit. Si l’équipe n’a rien refusé, le périmètre est mauvais. - L’épreuve à appliquer dans le doute : signeriez-vous cette décision de votre nom sans broncher ?

Pour finir : livrer quand le produit inspire confiance

En produit, la question qui gouverne n’est pas est-ce terminé ? Elle est est-ce que cela mérite d’exister ?

Si la réponse est oui, livrez. Si la réponse est « pas encore, mais ce le sera en trois reconstructions honnêtes », continuez à travailler. Si la réponse est non, et qu’elle reste non après trois tentatives, reconstruisez le brief, pas la surface.

C’est ainsi que je construis chaque produit que je signe de mon nom. L’état d’esprit MVP optimise les cycles. L’état d’esprit MWP se capitalise en une œuvre.

Livrez le plus petit produit que vous puissiez respecter. Ne livrez pas avant. N’attendez pas au-delà. Minimum et worthy sont une seule et même instruction, tenue simultanément.

---

FAQ

Qu’est-ce qu’un Minimum Worthy Product ?

Un Minimum Worthy Product est la plus petite version publique d’un produit validé qui gagne la confiance de l’utilisateur au lieu de la dépenser. Minimum signifie que le périmètre est ramené à la promesse centrale. Worthy signifie que la surface restante atteint le niveau de qualité que l’utilisateur perçoit. La première chose réelle que voient des utilisateurs réels doit mériter leur confiance, pas seulement fonctionner.

En quoi le MWP diffère-t-il du MVP ?

Le Minimum Viable Product, tel qu’il a été formulé à l’origine, était un instrument d’apprentissage : le plus petit artefact permettant de tester une hypothèse précise. En pratique, le MVP a dégénéré en permis de livrer du travail bâclé. Le Minimum Worthy Product rétablit la contrainte manquante. La validation traite la question de savoir si quelqu’un veut la chose (c’est le rôle des MVP, des pages d’atterrissage et des entretiens). Le MWP traite du niveau que vous tenez quand vous construisez la première version réelle de ce que la validation a confirmé.

Quand les équipes doivent-elles utiliser un MVP plutôt qu’un MWP ?

Trois cas où la logique du Minimum Viable Product ou du prototype s’applique encore : avant la validation (pages d’atterrissage, entretiens, tests concierge, prototypes cliquables), pendant les sondes de faisabilité (code jetable qui teste la latence ou la qualité), et pour les produits à effet de réseau qui ont besoin d’une bêta étiquetée avec de vrais utilisateurs avant que l’équipe puisse définir ce qui est digne. Le MWP s’applique à la première surface produit réelle, pas à tous les artefacts qui la précèdent.

Comment mesurer si un produit est digne de ce nom ?

Par cinq indicateurs comportementaux de confiance, pas par des métriques de vanité : le taux de deuxième réussite (part des utilisateurs activés qui accomplissent une deuxième fois le résultat central), la rétention à 30 jours rapportée à l’activation à 1 jour (un rapport, pas une valeur absolue), la forme de la courbe de rétention par cohorte (plate ou décroissante), la part de recommandation spontanée non incitée, et le taux de friction qualité (remboursements, exports échoués, tickets d’assistance pour 100 utilisateurs activés). Un produit digne de ce nom est solide sur les cinq ; un produit faible se trahit sur au moins un, et souvent sur tous.

---

La barrière du digne

Un outil de décision pour appliquer ce cadre à votre propre travail. Parcourez les cinq entrées, puis les trois garde-fous de la doctrine. Pas de score, pas de jauge ludique. Un verdict qui nomme l’axe défaillant et le geste suivant.

---

Références