Fait partie du guide Lancer un SaaS : les décisions qu'on ne reprend pas sans payer

Le MVP que j'ai raté avant de savoir en construire un bon

En janvier 2026, j’ai regardé le dépôt d’asap-website-builder, un constructeur de sites en Rust et Astro que j’avais commencé en décembre. Le compteur affichait 961 commits en deux mois, et le nombre d’utilisateurs affichait zéro. Deux mois plus tard, je lançais Deviso.pro, un outil de devis et factures pour paysagistes, en Next.js. Celui-là a trouvé des clients qui payaient, avec 558 commits.

Le 19 mai, quand j’ai décidé de tout reconstruire sous le nom d’asap.cool, la décision tenait en une ligne dans le dépôt : « deviso.pro a des users, c’est le seul actif à protéger ». Pas le projet le plus abouti ni celui avec le plus de code, celui que des gens utilisaient. C’est depuis cet aveu que je te parle de MVP, parce que c’est l’étape du guide lancer un SaaS où j’ai vu partir le plus de budget, à commencer par le mien.

1 076 commits pour zéro utilisateur

Ce que j’avais construit pendant ces deux mois, je peux te le décrire de mémoire : une API en Rust, un rendu Astro, un catalogue de variantes de sites, Stripe branché. En mai, j’y suis même revenu pour un pivot vers des pages générées par IA, 115 commits de plus, jamais fini. Tout marchait. Ce qui manquait, c’est quelqu’un qui en avait besoin au point de sortir sa carte, et je ne l’avais jamais cherché parce que j’avais toujours une brique de plus à finir avant de montrer.

Deviso, à l’inverse, était plus petit, moins propre, et il faisait une seule chose : sortir un devis, puis la facture qui va avec, pour un métier précis. Des paysagistes l’ont essayé et ont payé. Le 19 mai j’ai donc jeté le gros projet et gardé le petit, et je suis reparti de ce qui avait des utilisateurs, avec la même promesse. La suite est dans la case study asap.cool.

Un MVP ne se juge pas à ce qu’il contient. Il se juge à qui paie pour l’utiliser.

Ce que le mot voulait dire avant d’être vidé

« MVP » n’est pas une invention du Lean Startup. Le terme date de 2001, chez Frank Robinson, et sa définition ne parle pas de taille : c’est le produit qui maximise le retour rapporté au risque, pour le vendeur et pour le client. Le sujet n’était pas de faire petit, mais de trouver l’optimum.

En 2009, Eric Ries reprend le mot pour désigner la version qui permet d’apprendre le maximum sur les clients avec le moins d’effort. Dans le même billet, il écrit que sa méthode n’est pas une affaire de produits minimaux, que le MVP impose un surcoût (parler aux clients, instrumenter, mesurer), et que celui d’IMVU, sa propre boîte, a pris six mois.

En 2013, Steve Blank corrige publiquement : un MVP n’est pas toujours une version plus petite ou moins chère du produit final. Les deux auteurs de référence ont donc dit, chacun de leur côté, que « faire un MVP » ne voulait pas dire « faire la version pas chère ». Quand j’entends la phrase en réunion, c’est pourtant presque toujours ce qu’elle veut dire.

Le retournement qui m’a servi, c’est celui de Ries : un MVP bien fait coûte plus cher qu’un développement naïf, parce qu’il ajoute la mesure. Mes 1 076 commits n’avaient rien de tout ça. J’avais construit sans jamais mesurer, et j’appelais ça un MVP parce que le mot était disponible.

La liste de quarante lignes, et pourquoi aucune méthode ne la tranche

Avril 2026, premier cadrage d’Optimo France, un SaaS pour pâtissiers qui lit les factures fournisseurs et calcule les marges. La liste du fondateur fait quarante lignes, partagée à l’écran. Je lui demande d’en retirer une, une seule. Il ne retire rien, et ce n’est pas de l’entêtement : « export comptable » et « notifications par mail » ont exactement le même statut, des choses qu’il faudra bien faire un jour.

Le problème n’est pas la liste, c’est l’absence de critère. Et les méthodes que j’aurais pu lui sortir pour en fabriquer un demandent chacune quelque chose qu’il n’avait pas ce jour-là.

MoSCoW a un garde-fou que presque personne ne cite : l’organisme dépositaire recommande de ne pas dépasser 60 % de l’effort en Must Have, sinon le projet prend un risque d’échec. Mais ça se calcule en pourcentage d’un effort total, et sans chiffrage, tout redevient Must. Ce que j’en garde, c’est le W : Won’t have this time, un report daté, pas un abandon.

RICE demande un Reach en personnes par période, des clients par trimestre par exemple. Le jour du cadrage d’Optimo, ce nombre valait zéro sur toutes les lignes, ou celui que le fondateur avait envie d’y mettre. Intercom, qui a créé la méthode, écrit d’ailleurs que les scores ne sont pas une règle rigide.

Kano, en 1984, dans le contrôle qualité industriel, a montré que satisfaction et insatisfaction sont deux dimensions distinctes. Certaines fonctionnalités ne peuvent que nuire par leur absence sans rien apporter par leur présence. Mais classer ta liste selon Kano suppose une enquête auprès d’utilisateurs, et au jour zéro, tu n’en as pas.

Le story mapping de Jeff Patton est le seul qui marche sans utilisateurs, parce qu’il ne note rien : il découpe. La carte se construit à partir du travail que les gens font déjà à la main. Chez Optimo, c’était un pâtissier avec des factures papier et un tableur, et ça, je pouvais aller le regarder.

Optimo : quinze modules, quatre lots, et une mise en service après sept semaines

Ce qu’on a fait de la liste, le fondateur et moi, ce n’est pas quarante scores. On l’a redécoupée en quinze modules, regroupés en quatre lots, avec cinq jalons. Le premier lot portait ses recettes, ses matières premières et une marge calculée, avec le cloisonnement des données financières déjà en place ; la lecture automatique des factures, décidée dès la première semaine, a changé trois fois de moteur avant de se stabiliser fin mai. S’il avait fallu s’arrêter après le premier lot, il avait déjà des chiffres justes.

Ce découpage est tranché en code, pas dans un document : 965 commits, 56 migrations, quatorze décisions d’architecture écrites, et la mise en service est arrivée après sept semaines de travail.

Ce que le lot 1 a laissé de côté porte une raison écrite à côté de chaque ligne. Le format que je tiens, c’est une phrase : la ligne, puis ce qui devrait être vrai pour qu’elle revienne. Du genre : « reporté tant qu’aucun client n’a demandé le fichier », avec le nom du module devant.

Ce qui sort du lot 1 ne disparaît pas. Il attend une preuve.

La justification compte autant que la coupe. Six mois plus tard, quand quelqu’un ressort la ligne, la phrase répond à sa place, et si la condition n’est toujours pas remplie, la ligne reste où elle est. C’est comme ça que je travaille en SaaS sur-mesure, et le détail du projet est dans la case study Optimo.

SimplyJury : ce que je retire d’un MVP que je n’ai pas construit

Sur SimplyJury, en avril 2026, j’ai repris un MVP livré par un autre prestataire, pour le mettre en production puis le maintenir. La question n’était plus quoi construire mais quoi enlever, et j’ai enlevé : la page pricing dès la mi-mai, puis fin août les frais de déplacement et les disponibilités. Des fonctionnalités qui existaient, qui compilaient, et que personne n’utilisait assez pour justifier de les maintenir.

Retirer est plus dur que couper avant de construire, parce que le code est là et que quelqu’un l’a payé. Ce qui m’a aidé, c’est la même règle : une raison par retrait, dans le message du commit, pour le jour où la question reviendra. Le dépôt en est à 692 commits et 55 migrations depuis la reprise, et une bonne part ont servi à le rendre tenable plutôt qu’à l’agrandir.

Sur GoPronos, un prototype Lovable repris pour aller sur les stores, ça a été plus brutal : 40 commits le premier jour, le 22 mai, pour sortir l’app de son générateur, avec 19 migrations héritées dont les noms étaient des UUID. Si ton MVP existe déjà et qu’il est no-code, c’est un autre chantier, celui de la reprise.

Ce qui ne se coupe jamais, même au lot 1

Une liste qui ne dirait que « coupe » produirait l’erreur inverse. Il y a des briques que je garde au lot 1 quoi qu’il arrive, parce que leur absence coûte plus cher que leur présence, et qu’aucun score ne les fera remonter dans un classement.

• La facturation conforme, si le produit se vend. Mon propre produit, asap.cool, est un logiciel de facturation : c’est le domaine où je n’ai pas le droit de me tromper, et j’ai quand même découvert le 19 juillet 2026 qu’aucune facture n’avait jamais été vérifiée avant scellement, parce que le contrôle répondait OK quand le validateur n’était pas branché. Chez un client, je ne repousse jamais cette brique à un lot 2.
• L’isolation des données entre clients. Sur Deviso, les modèles d’organisation existaient, mais les données métier n’étaient pas scopées, et un audit au printemps 2026 a sorti des accès croisés entre comptes. Huit jours plus tard, asap.cool démarrait avec l’isolation forcée en base sur chaque table ; il y en a 105 aujourd’hui. Le détail est dans choisir son architecture.
• Les sauvegardes, restaurées au moins une fois. Sur asap.cool, la case « backups testés » est restée décochée de mai à septembre 2026, et quand je l’ai enfin traitée, la procédure documentée ne pouvait pas marcher. Sur SimplyJury, l’hébergeur gratuit n’offrait aucune sauvegarde ; la chaîne de migrations était le seul chemin de reconstruction, et huit d’entre elles n’avaient jamais existé.

Ces briques, l’utilisateur ne les voit jamais. Elles ne feront recommander le produit à personne, et c’est pour ça qu’au sens de Kano ce sont des must-be : leur absence indigne, leur présence n’émeut pas. Un fondateur qui les coupe pour aller plus vite ne gagne pas de temps, il le paiera au moment de la première mise en service, quand il n’aura plus le choix.

Le SEPA que j’ai construit puis supprimé

Il reste une catégorie, celle des lignes dont je ne sais ni si je les garde ni si je les coupe. Sur asap.cool, en juillet 2026, j’ai écrit une spécification SEPA et open banking : le prélèvement automatique des factures, la réconciliation bancaire. Un stub est arrivé dans le code. En septembre, je l’ai supprimé, avec la raison dans le commit : provisionné, mais lu par personne.

La raison écrite de la coupe existe aussi après coup, et elle vaut autant que celle que j’écris avant : la prochaine fois qu’un client demandera le prélèvement, je saurai que la question a déjà été posée, et à quelle date. La différence avec asap-website-builder, c’est que cette fois la coupe a une trace : un commit, une date, une phrase. En janvier, j’avais 1 076 commits et aucune phrase.

Alors ce que je fais, moi, sur mes projets comme chez mes clients : un lot livrable, qui se termine par une mise en production dont le fondateur peut se contenter, et une raison écrite pour chaque ligne qui n’y est pas. Le reste de la liste garde sa phrase et attend son tour.

Si tu as une liste et que tu veux qu’on la regarde ensemble, ligne par ligne, prends un créneau : trente minutes, et la première question sera de savoir laquelle tu retires.