Produit Minimum Digne

Alors que je reconstruis les surfaces publiques de ResumeGeni, je bute sans cesse sur la même ligne inconfortable. La version qui fonctionne techniquement n’est pas toujours celle que je mettrai devant un candidat. Le parseur tourne. La sortie s’affiche. Le flux se termine. Et pourtant, quelque chose dans l’expérience dépense la confiance au lieu de la gagner. Je m’y attarde une heure, je reconstruis la surface, et la sensation disparaît, mais l’horloge, elle, continue.

Cette tension, c’est l’essai. Deux forces s’opposent : expédier assez tôt pour mettre le produit au monde, et refuser d’expédier un produit qui dilapide la confiance de l’utilisateur. La plupart des bâtisseurs résolvent la tension en choisissant un camp et en le défendant. La culture MVP choisit la vitesse. Le perfectionnisme choisit la finition. Les deux réponses échouent, parce que la tension est justement le cœur du sujet.

Le Produit Minimum Digne est une norme différente — livrer le plus petit produit qui gagne la confiance, et non le plus petit produit que vous pouvez défendre comme fonctionnel. Digne est le plancher, pas le plafond. Minimum est une contrainte de périmètre, pas une remise sur la qualité. Le bâtisseur MWP coupe des fonctionnalités jusqu’à ce que le produit puisse être expédié et tient chaque surface restante à un niveau que l’utilisateur peut ressentir. Le bâtisseur MVP fait trop souvent l’inverse : il coupe la qualité pour protéger le périmètre. Cette substitution, c’est ce que les utilisateurs ressentent dans les données.

TL;DR

MVP était censé être un outil d’apprentissage : le plus petit artefact qui teste une véritable hypothèse avec de vrais utilisateurs. La version dégradée est devenue une permission d’expédier du travail faible. Le Produit Minimum Digne restaure la contrainte manquante. Validez à peu de frais, puis construisez le plus petit produit qui mérite la confiance. Minimum coupe le périmètre. Digne tient la surface restante à un standard que l’utilisateur peut ressentir.

---

Ce que MVP avait de juste

L’idée originale de MVP ne donnait pas la permission d’expédier du travail faible. 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 répondre à un mode d’échec bien précis : des ingénieurs construisant des produits élaborés pour des marchés qui n’existaient pas. Le MVP était un instrument d’apprentissage. Vous construisiez le plus petit artefact capable de tester une hypothèse spécifique avec de vrais utilisateurs, vous meniez l’expérience, vous mesuriez ce qui se passait, et vous mettiez à jour votre compréhension de la survie de cette hypothèse au contact du réel. Le « minimum » dans MVP signifiait un effondrement du périmètre au service de l’apprentissage, pas un effondrement de la qualité au service de l’expédition.

Le cadrage original tient toujours. Je m’en sers. Ma séquence de validation de startup (problème, solution, canal, revenu, échelle) est en aval de Ries. L’argument en faveur du test d’hypothèses peu coûteuses à valider avant d’investir dans du code est le même argument pour MWP en aval de la validation : l’instrument de chaque étape doit correspondre à son étape. Les pages d’atterrissage et les entretiens sont des MVPs pour la désirabilité. Les prototypes et les « spikes » sont des MVPs pour la faisabilité. MWP est la norme que vous appliquez lorsque les preuves de validation sont déjà en main et que vous construisez la première chose réelle à laquelle de vrais utilisateurs feront confiance.

Je ne m’oppose donc pas à MVP. Je m’oppose à ce que MVP est devenu en pratique.

Là où la culture MVP s’est relâchée

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

Trois glissements ont brisé l’idée originale :

1. « Si vous n’êtes pas gêné par la première version de votre produit, c’est que vous l’avez lancée trop tard » (la formule de Reid Hoffman⁴) est devenue la permission d’être gêné par le soin apporté, et non par le périmètre. La revendication initiale porte sur le nombre de fonctionnalités : expédiez si peu de fonctionnalités que votre futur vous sera gêné de voir à quel point le produit faisait peu. La version dégradée porte sur le métier : expédiez quelque chose de si brut que votre futur vous sera gêné de l’aspect et du ressenti du produit. Ce ne sont pas les mêmes phrases.

2. « Expédier vite » a remplacé « apprendre vite » comme résultat mesurable. L’apprentissage est un processus lent, agaçant, qui produit de l’intuition qualitative. L’expédition est un processus rapide, lisible, qui produit un artefact daté. Quand vous ne pouvez plus distinguer les deux, l’artefact l’emporte par défaut. Les équipes expédient chaque semaine et cessent totalement d’apprendre, parce que personne ne mesure ce que l’équipe a appris.

3. Le schéma venture (lever, croître, sortir) récompense l’expédition de n’importe quoi plutôt que l’expédition juste. Si votre mission est de démontrer une dynamique au prochain chèque, un produit édulcoré passe au moins la barre du « nous avons expédié ». Un produit digne retardé ressemble de l’extérieur à une équipe en panne. Le gradient d’incitation pointe vers le bas.

Aucune de ces dégradations n’est la faute de MVP tel qu’il a été écrit à l’origine. Ce sont les formes que MVP a prises dans la bouche de ceux qui avaient besoin d’une défense pour expédier du travail faible.

Les utilisateurs en ressentent le résultat. Vous le ressentez dans les données. L’onboarding se termine, mais la deuxième session n’arrive jamais. Les utilisateurs ouvrent le courriel d’inscription et ne cliquent jamais sur le lien. Les tickets de support se regroupent autour de tâches que le produit prétend gérer. La courbe de désabonnement décroît vers zéro au lieu de s’aplanir en un noyau. Ces résultats ne sont pas des cas limites. Ils constituent le coût central d’une construction à un standard auquel l’utilisateur ne peut pas croire.

Minimum ne veut pas dire inachevé

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

Opérationnellement : définissez l’utilisateur. Définissez l’unique résultat que le produit prétend livrer. Supprimez toute fonctionnalité non requise pour ce résultat. Puis tenez la surface restante au plein niveau de qualité. Minimum coupe le périmètre jusqu’à ce que le produit puisse être expédié. Minimum ne coupe pas le standard pour que le produit puisse être expédié plus tôt.

Exemple concret. La promesse de ResumeGeni est un CV prêt pour les ATS qui donne à un candidat une vraie chance de passer les systèmes de suivi de candidatures. La version minimale de la promesse peut exclure :

• Les modèles personnalisés
• La collaboration d’équipe
• Les tableaux de bord d’analytique
• 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 : un parsing précis du CV source, une évaluation honnête des lacunes, des réécritures concrètes qui correspondent vraiment à la description du poste, un export qui s’ouvre proprement dans Word, et un flux qui fait sentir au candidat qu’il est en sécurité. Vous pouvez expédier sans modèles. Vous ne pouvez pas expédier avec des conseils vagues, des exports cassés, ou des textes qui donnent à un utilisateur vulnérable le sentiment que le produit le prend pour un pigeon.

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

Digne est le plancher

Un produit digne n’a pas besoin de contenir tout ce que vous imaginez. Tout ce qu’il contient, en revanche, doit respecter l’utilisateur.

Digne au sens opérationnel 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 construisiez et il croit qu’il y a plus à venir. 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 accumulent de la croyance. Les produits à demi dignes la dépensent.

Vous ne pouvez pas feindre la confiance. Les utilisateurs arrivent avec des attentes façonnées par les produits qu’ils connaissent déjà.⁵ Lorsque votre produit se situe en dessous de ces attentes (boutons qui ne répondent pas, textes qui louvoient, flux qui les abandonnent à mi-chemin), les utilisateurs enregistrent l’écart avant même de l’articuler. Ils partent, ils ne reviennent pas, et aucun courriel de rétention ne sauvera la session qu’ils ont déjà abandonnée.

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

La validation vient d’abord, la dignité vient ensuite

L’objection la plus forte au MWP est que les utilisateurs déterminent la dignité par le contact, non par la conviction du créateur. Exact. Le MWP ne remplace pas le jugement de l’utilisateur. Le MWP vous empêche de brûler une confiance validée avant que les premiers vrais utilisateurs n’aient eu l’occasion de juger.

Le contact utilisateur appartient à la validation. Avant de construire, vous testez si le problème est réel, si votre solution proposée y répond, si vous pouvez atteindre les utilisateurs, et s’ils paieront. La preuve vient des pages d’atterrissage, des entretiens, des tests en mode concierge, des prototypes et des listes d’attente. J’ai écrit sur cette séquence en détail. Une hypothèse qui survit à ce gantelet a mérité 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 expédié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é décident si le jugement tient la route.

Sauter la validation et appeler le résultat MWP produit une belle réponse à une question que personne n’a posée. Sauter le MWP et appeler le résultat lean produit un produit édulcoré qui coûte la confiance que la validation a déjà gagnée.

La bonne séquence : validez à peu de frais avec de vrais utilisateurs, puis construisez le plus petit produit digne pour la promesse validée. Faites les deux. N’en sautez aucun.

Les deux tests : Jiro et Steve

Un produit doit passer deux tests différents avant que je ne le considère terminé.

Le Test Jiro demande si le travail est correct. Preuves que le produit fonctionne. Cas limites gérés. Détails invisibles finis. Les affirmations citent des preuves concrètes. Pas d’hésitation ; je crois n’est pas une preuve. Le Test Jiro distingue le métier de l’aspiration. J’ai écrit sur la philosophie de qualité Jiro telle que la discipline s’applique aux agents IA ; la même discipline s’applique à chaque surface produit. L’Evidence Gate est la manière dont j’opérationnalise le test dans les rapports de code.

Le Test Steve demande si le travail mérite d’exister. Point de vue visible. Cohérence du widget entier. Dignité de l’utilisateur préservée. Un mécanisme de plaisir ou de clarté que le lecteur peut identifier, et non agiter vaguement. Le Test Steve distingue le produit de l’inventaire. Une chose expédiée n’est pas automatiquement une chose digne. L’argumentaire complet pour le goût comme système technique vit dans un essai séparé ; pour cet article, la définition opérationnelle ci-dessus porte le poids.

Les deux tests doivent passer. Si Jiro échoue, arrêtez et corrigez. Si Steve échoue, reconstruisez. Si les deux échouent, le problème vit en amont, dans le brief.

La question opérationnelle lorsque le jugement est incertain est la plus simple de la pile : signerais-je de mon nom sans broncher ? Si la réponse est non, le travail n’est pas encore digne.

La preuve sous vos pieds : blakecrosley.com

La page que vous lisez a commencé comme une petite expérience dans ma transition sans chemin. Elle fait aussi partie de l’argument.

Il n’y a pas de React. Il n’y a pas de Tailwind. Il n’y a pas de webpack, pas de Vite, pas de bundler, pas d’étape de build. L’ensemble du site fonctionne sur FastAPI, HTMX, Alpine.js, Jinja2, et du CSS simple, servi directement. Sur le build actuel, le premier affichage se situe entre 45 et 60 Ko et Lighthouse rapporte 100 sur 100 en performance, accessibilité, bonnes pratiques et SEO.³ Le site fonctionne en neuf langues, expédie de nouveaux guides et du contenu de blog de bout en bout en un seul git push, et ne contient aucun node_modules/ où que ce soit dans le dépôt.

La version MVP du site aurait suivi le conseil par défaut de 2026 — Next.js, Tailwind, Vercel. Elle aurait été expédiée en un week-end. Elle aurait été correcte. Vous auriez atterri ici, la page se serait chargée dans un temps respectable. La différence n’aurait pas été la capacité. La différence aurait été le goût. J’ai écrit sur comment un score Lighthouse parfait se construit réellement ; la version courte est que chaque Ko de charge utile que le lecteur ne télécharge pas est une forme de respect.

La version MWP a pris plus de temps. La version MWP exigeait d’écrire les patterns HTMX à partir de zéro, d’ajuster la typographie à la main, d’auto-héberger les polices, de faire passer le pipeline 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. La version MWP est plus intentionnelle. L’intention se manifeste par moins de coutures que le lecteur puisse remarquer.

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 élève la barre, parce que l’utilisateur ne fait pas que parcourir. L’utilisateur essaie d’améliorer un document qui pourrait décider s’il obtient un entretien d’embauche.

La validation de ResumeGeni est revenue propre : page d’atterrissage, liste d’attente, publications ciblées sur Reddit et LinkedIn, 340 inscriptions par e-mail en deux semaines, et une douzaine de réponses demandant quand le produit ouvrirait.⁷ La séquence de validation disait : construisez-le. Construire était la décision facile. Ce à quoi la construction allait ressembler était la décision difficile, et c’est là que le MWP a fait le vrai travail.

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

La seconde catégorie était le standard que j’étais prêt à tenir pour ce qui restait. Le standard ne se coupe pas. Le parseur 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 vulnérable comme une métrique de conversion. Le flux ne peut pas abandonner quelqu’un en pleine procédure parce que le chemin heureux était tout ce pour quoi j’avais le temps.

La version MVP aurait expédié un assistant à dix étapes, une sortie générique, un mur d’abonnement 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 certains utilisateurs une fois. Elle aurait aussi appris à la première cohorte à ne pas faire confiance au produit, et cette leçon devient une mauvaise fondation pour un cas d’usage vulnérable.

La version MWP est plus petite que je ne le voudrais. Chaque fonctionnalité que j’ai coupée, je la voudrai de retour. Le niveau à tenir : que le produit sur lequel les utilisateurs atterrissent les respecte. La fondation est la seule sur laquelle je sache bâtir.

Ce que les utilisateurs vous disent vraiment

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

Cinq signaux que je surveille, calibrés pour un public de bâtisseurs :

1. Taux de deuxième réussite. Le pourcentage d’utilisateurs activés qui reviennent et complètent le résultat central une deuxième fois 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 traite un taux de deuxième réussite inférieur à 30 % comme un signal de reconstruction. Pour les produits épisodiques, mesurez le prochain cycle d’usage naturel plutôt que de forcer une fenêtre de 30 jours.

2. Rétention à J+30 relative à l’activation à J+1. Le courriel de ré-engagement peut truquer la rétention brute. Le ratio, non. Pour les produits à usage hebdomadaire ou mensuel, le ratio vous dit si l’activation était de la confiance ou une curiosité ponctuelle. J’utilise moins de 0,25 comme avertissement et moins de 0,15 comme verdict.

3. Forme de la courbe de rétention par cohorte. Les produits dignes s’aplanissent après la chute initiale. Les produits faibles continuent de décroître. Tracez les courbes ; la forme raconte l’histoire que les moyennes cachent. Si la courbe ne s’aplanit jamais, il n’y a pas de noyau d’utilisateurs qui fait réellement confiance au produit.

4. Part de recommandation organique non incitée. Le pourcentage de nouveaux utilisateurs activés arrivant par recommandation directe, partage de sortie, ou bouche-à-oreille, pas par canaux payants, pas par pots-de-vin de programme de parrainage. On parle des produits dignes. On oublie les produits faibles. Si la catégorie a un moment naturel de partage et que la recommandation organique reste inférieure à 10 % de l’acquisition de nouveaux utilisateurs, le produit ne gagne pas la recommandation.

5. Taux de friction-qualité. Remboursements, clics de colère, tickets de support, exports échoués, corrections manuelles pour 100 utilisateurs activés, suivi par cohorte. Le taux, c’est la douleur que le produit inflige aux utilisateurs qu’il prétend servir. Le taux devrait tendre à la baisse à mesure que le produit mûrit. Si le taux est plat ou en hausse, le problème est le produit, pas le processus de support.

Aucun de ces signaux n’est une métrique de vanité. Chacun est difficile à truquer. Chacun renvoie à une véritable expérience utilisateur qui a soit gagné la croyance, soit échoué à le faire. Si vous ne pouvez pas nommer les chiffres d’une cohorte spécifique sur les cinq, vous ne savez pas encore si votre produit est digne.

Quand MVP ou le prototype restent le bon choix

Le MWP n’est pas le bon standard pour chaque artefact.

Trois cas où la logique MVP ou prototype reste correcte :

• Avant la validation. Pages d’atterrissage, entretiens, tests en mode concierge, prototypes cliquables. Le but est l’apprentissage, pas le métier. Expédiez la version laide qui teste l’hypothèse. Expédiez-la aujourd’hui. La séquence de validation est le bon playbook ici, pas le MWP.

• Spikes de faisabilité. Quand l’inconnue est technique (le modèle peut-il répondre à ce genre de requête avec la latence dont j’ai besoin ? la API supporte-t-elle la charge ? le parseur fonctionnera-t-il sur la longue traîne des entrées réelles ?), construisez le plus petit instrument jetable qui réponde à la question. N’essayez pas de le rendre digne. Rendez-le véridique.

• Surfaces bêta à 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 que quiconque puisse les juger, donc l’artefact correct est une bêta clairement étiquetée avec instrumentation par cohorte. Expédier une bêta n’est pas un substitut à la version digne ; expédier une bêta est la seule façon de découvrir ce que digne signifie. Étiquetez la surface honnêtement comme bêta. Ne la déguisez pas en v1.

Le MWP est pour la première vraie surface produit. Si vous êtes encore en amont de la surface (apprentissage, test, découverte), les bons outils vivent plus en arrière dans la séquence.

Le plafond de reconstruction

Un standard élevé sans règle d’arrêt devient de l’évitement.

La doctrine que j’applique à chaque travail non trivial a un plafond de reconstruction de trois tentatives honnêtes.² Une tentative honnête signifie que vous avez identifié l’axe qui a échoué, nommé le mouvement correcteur spécifique, changé l’approche matériellement, et réévalué le travail au regard des deux tests. Trois répétitions du même passage de finition ne comptent pas comme trois tentatives. Les répétitions comptent comme une tentative échouée répétée trois fois.

Après trois reconstructions honnêtes qui échouent à produire un produit digne, le problème n’est pas le métier. Le problème vit 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 grande pour le périmètre que vous pouvez réalistement tenir au standard. Parfois la validation était plus molle que vous ne le pensiez. Parfois le problème n’est pas du tout un problème produit.

Le plafond de reconstruction résout 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 expédié. Pas pur et en attente pour toujours.

Le perfectionnisme, c’est le métier sans courage. Si vous en êtes à la quatrième reconstruction de la même surface, vous avez cessé de faire un produit et vous utilisez le projet comme un endroit où vous cacher.

Points clés à retenir

Pour les fondateurs et les bâtisseurs solo : - Validez à peu de frais avant tout code. Le MWP s’applique après que la validation a confirmé l’adéquation au marché. - Coupez les fonctionnalités agressivement. Tenez la surface restante au plein niveau de qualité. - Expédiez au niveau digne. Plafonnez les reconstructions à trois. Escaladez ensuite le brief.

Pour les responsables produit et les PMs : - Mesurez directement les proxys de confiance : taux de deuxième réussite, ratio rétention J+30 sur J+1, forme de la courbe de cohorte, part de recommandation organique, taux de friction-qualité pour 100 utilisateurs. - Séparez les conversations de périmètre des conversations de qualité. Les coupes de périmètre sont négociables. Les coupes de qualité ne le sont pas. - Protégez l’expérience de votre première cohorte. Une première impression dégradée sur des utilisateurs vulnérables coûte des années à rattraper.

Pour les lead engineers : - Nommez une porte Jiro et une porte Steve pour chaque surface que vous expédiez. Les deux doivent passer. - Budgétisez le métier invisible. La différence entre « fonctionne » et « digne » vit généralement dans les détails que personne ne pointe. - Intégrez un plafond de reconstruction à votre processus pour que le perfectionnisme cesse de se cacher sous le raffinement.

Pour les designers : - Le point de vue n’est pas de la décoration ; c’est le mécanisme qui rend le produit reconnaissable. - Une surface digne refuse des choses, visiblement. Si l’équipe n’a rien refusé, le périmètre est mauvais. - Le test opérationnel dans l’ambiguïté : signeriez-vous de votre nom la décision sans broncher ?

Conclusion : livrer quand le produit mérite la confiance

La question directrice en produit n’est pas est-ce fini ? La question directrice est est-ce que cela mérite d’exister ?

Si la réponse est oui, livrez. Si la réponse est « pas encore, mais cela le sera dans 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.

L’approche est la manière dont je construis chaque produit auquel j’associe mon nom. L’état d’esprit MVP optimise pour les cycles. L’état d’esprit MWP se compose en une œuvre.

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

---

FAQ

Qu’est-ce qu’un Produit Minimum Digne ?

Un Produit Minimum Digne est la plus petite version publique d’un produit validé qui gagne la confiance de l’utilisateur plutôt que de la dépenser. Minimum signifie que le périmètre est réduit à la promesse centrale. Digne signifie que la surface restante atteint le niveau de qualité que l’utilisateur peut ressentir. La première chose réelle que de vrais utilisateurs voient doit mériter leur confiance, pas simplement fonctionner.

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

Un Minimum Viable Product tel qu’il a été écrit à l’origine était un instrument d’apprentissage : le plus petit artefact pour tester une hypothèse spécifique. En pratique, MVP s’est dégradé en une permission d’expédier du travail faible. Un Produit Minimum Digne restaure la contrainte manquante. La validation couvre la question de savoir si quelqu’un veut la chose (un travail pour les MVPs, les pages d’atterrissage et les entretiens). Le MWP couvre le standard que vous tenez quand vous construisez la première vraie version de ce que la validation a confirmé.

Quand les équipes devraient-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 en mode concierge, prototypes cliquables), pendant les spikes 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 qu’est digne. Le MWP s’applique à la première vraie surface produit, pas à chaque artefact en amont de celle-ci.

Comment mesurer si un produit est digne ?

À travers cinq proxys comportementaux de confiance, et non des métriques de vanité : taux de deuxième réussite (pourcentage d’utilisateurs activés qui complètent le résultat central une deuxième fois), rétention à J+30 relative à l’activation à J+1 (ratio, pas absolu), forme de la courbe de rétention par cohorte (plate contre décroissante), part de recommandation organique non incitée, et taux de friction-qualité (remboursements, exports échoués, tickets de support pour 100 utilisateurs activés). Un produit digne montre de la force sur les cinq ; un produit faible le montrera sur au moins un, et souvent sur tous.

---

La Porte du Digne

Un outil de décision pour appliquer le cadre à votre propre travail. Parcourez les cinq entrées, puis les trois rails de doctrine. Pas de score, pas de compteur gamifié. Un verdict qui nomme l’axe et le prochain mouvement.

---

Références