Votre cahier des charges décrit une V1, pas un MVP : comment le cadrer

La plupart des cahiers des charges qu'on nous envoie ne décrivent pas un MVP. Ils décrivent une V1. Un produit fini, propre, complet, avec ses réglages fins, son back-office soigné et ses fonctionnalités de confort. Sur le papier, ça rassure. Dans la réalité, ça allonge le délai de six mois et ça repousse d'autant le seul moment qui compte vraiment : celui où vous saurez si les gens veulent ce que vous construisez.

La confusion est logique. Quand on n'a jamais piloté un développement, on décrit ce qu'on veut posséder à la fin, pas ce qu'il faut construire en premier pour apprendre le plus vite. Un MVP n'est pas une V1 en plus petit. C'est un objet différent, avec un objectif différent. La V1 vise à servir un utilisateur. Le MVP vise à produire une preuve. Confondre les deux, c'est payer le prix d'un produit fini pour répondre à une question qu'un dixième du périmètre aurait tranchée.

Cet article n'est pas une plaidoirie pour livrer moins. C'est une méthode pour relire votre propre cahier des charges et séparer, ligne par ligne, ce qui produit de la preuve de ce qui produit seulement du confort. La grille tient en quatre preuves et une règle. Vous pouvez l'appliquer ce soir sur votre document.

“Un MVP n'est pas la plus petite chose que vous pouvez construire. C'est la plus petite chose qui répond à la plus grosse question.”

Chaque ligne d'un cahier des charges appartient à l'une de deux familles. Soit elle produit de la preuve : elle vous apprend quelque chose que vous ne pouvez pas savoir depuis votre bureau. Soit elle produit du confort : elle rend le produit plus complet, plus rassurant, plus professionnel, sans rien vous apprendre que vous ne sachiez déjà. Le confort n'est pas inutile. Il est juste rarement urgent.

Le problème, c'est que le confort ressemble à du progrès. Un back-office avec quinze filtres, une gestion fine des rôles, un paramétrage exhaustif, trois langues d'entrée de jeu : tout cela remplit le document et donne le sentiment d'avancer. Mais rien de tout cela ne vous dit si votre produit résout un vrai problème pour un vrai client prêt à payer. Vous construisez la maison avant d'avoir vérifié que le terrain est constructible.

Ce chiffre est célèbre, et il faut le lire avec prudence : il vient d'une étude sur quatre applications internes, pas d'un panel géant. Mais l'ordre de grandeur est confirmé par tout praticien honnête. La majorité de ce qu'on construit ne sert quasiment jamais. Chaque fonctionnalité de confort dans votre premier lot a donc de bonnes chances d'être du temps et de l'argent dépensés pour quelque chose que personne n'utilisera.

La discipline du MVP n'est pas de couper au hasard. C'est de trier avec un critère unique : qu'est-ce que cette ligne me fait apprendre ? Si la réponse est rien, elle attend la V1. Si la réponse est quelque chose que je ne peux valider que sur le marché, elle passe en priorité.

Ce tri se double d'un choix de méthode de construction (aller vite en no-code ou investir dans le sur-mesure) qu'on a détaillé dans no-code ou sur-mesure : comment choisir. Les deux décisions se renforcent : moins de périmètre rend le sur-mesure abordable plus tôt.

Voici le cœur de la méthode. Une fonctionnalité mérite sa place dans le premier lot si, et seulement si, elle produit au moins une de ces quatre preuves. Passez chaque ligne de votre document au filtre. Celles qui n'en produisent aucune ne sont pas mauvaises, elles sont juste prématurées.

Les quatre preuves, dans l'ordre où le risque doit tomber.

Un exemple chez nous. Gramlab, c'était un produit cadré au strict minimum : assez pour prouver le désir et le modèle, pas un gramme de plus. Résultat, 5000 $ encaissés en 15 jours et une offre de rachat à 85K $. Les quatre preuves, faites vite, avant de construire quoi que ce soit de complet.

Notez ce que la grille exclut : tout ce qui ne produit aucune de ces quatre preuves. Le paramétrage fin, la gestion avancée des rôles, le tableau de bord à quinze indicateurs, le multilingue, le design system exhaustif. Ce sont de vraies fonctionnalités de V1. Elles ne prouvent rien au stade du MVP, elles rassurent. Le confort attend son tour.

“Mettez dans le premier lot ce qui fait tomber le plus gros risque. Tout le reste est une opinion sur l'avenir.”

Une règle mérite d'être isolée, parce qu'elle est violée presque à chaque fois. Une fonctionnalité qui dépend d'un tiers que vous ne contrôlez pas ne va jamais dans le premier lot. Une API partenaire pas encore signée, un organisme de certification, un volume de fournisseurs pas encore recrutés, une intégration de paiement à friction réglementaire : tout ce qui repose sur quelqu'un d'autre pour exister.

La raison est simple. Une dépendance externe transforme votre calendrier en celui d'un tiers. Vous pouvez avoir la meilleure équipe et le meilleur périmètre, si votre livraison attend la signature d'un partenaire ou l'agrément d'un organisme, votre vitesse n'est plus la vôtre. Vous avez construit votre chemin critique sur une porte que quelqu'un d'autre ouvre quand il veut.

Ce principe a un effet secondaire précieux : il vous force à séparer ce qui crée la valeur de ce qui l'industrialise. Bien souvent, le geste manuel révèle que l'intégration coûteuse que vous vouliez construire n'était pas nécessaire au départ, et qu'une version bien plus simple suffisait à prouver le modèle.

Un cahier des charges et un MVP n'optimisent pas la même chose, et c'est toute la différence. Le premier optimise la complétude : plus le document est détaillé, plus il ressemble à un produit fini, plus il rassure. Le second optimise l'apprentissage : moins le périmètre est large, plus vite vous savez si le produit tient. Les deux logiques tirent dans des directions opposées.

L'enjeu n'est pas théorique. Quand un produit échoue, c'est rarement parce qu'il manquait une fonctionnalité. C'est parce qu'il n'y avait pas de marché pour lui, et qu'on l'a découvert trop tard, après avoir tout construit.

Un MVP bien cadré est la façon la plus économique de vérifier qu'il y a un marché avant de tout construire. La question à poser à chaque ligne de votre document tient en une phrase : ai-je besoin de ça pour paraître complet, ou pour apprendre si les gens en veulent ? La première réponse attend. La seconde passe.

Une fois la preuve de marché faite, la suite se joue sur l'exécution commerciale : on a détaillé un plan concret dans le plan go-to-market des 8 premières semaines.

La méthode se résume à une relecture disciplinée. Reprenez votre document, et pour chaque fonctionnalité, passez-la au crible de ces six questions. Celles qui échouent ne disparaissent pas, elles rejoignent la V1. Vous serez surpris de la taille du premier lot une fois le tri fait : souvent un tiers de ce que vous aviez écrit.

Ce tri n'engage rien de définitif. Une fonctionnalité repoussée n'est pas une fonctionnalité abandonnée. C'est une fonctionnalité qui attend d'avoir gagné le droit d'exister, une fois que le marché a confirmé qu'il y avait bien un produit à construire. Vous ne coupez pas votre ambition, vous ordonnez sa réalisation.

Il y a une raison de fond pour laquelle beaucoup de prestataires ne vous aideront pas à couper votre cahier des charges. Un périmètre plus large, c'est une facture plus grosse. Leur intérêt de court terme est aligné avec votre confort, pas avec votre apprentissage. Ils exécuteront le document tel quel, parce que le document tel quel les arrange.

Un partenaire qui pense comme un entrepreneur fait l'inverse. Il retire des lignes. Il repousse les dépendances. Il vous fait livrer le premier lot le plus vite possible, parce que son intérêt est votre résultat, pas votre périmètre. Ça se voit à une chose simple : est-ce qu'on vous propose d'ajouter, ou est-ce qu'on vous aide à retrancher ?

“Le meilleur cahier des charges n'est pas le plus complet. C'est celui qui vous fait apprendre le plus vite si vous aviez raison.”

Pour prolonger : prestataire ou partenaire, comment choisir et faire développer son premier logiciel métier.