Comment définir le périmètre d’un MVP (et le rendre estimable)

Pour définir le périmètre d'un MVP, écrivez le problème que vous testez et l'utilisateur qui le rencontre, décrivez le parcours unique qui l'amène de son arrivée au moment où il obtient de la valeur, puis rangez toutes les autres idées en « indispensable », « important », « souhaitable » ou « pas cette fois ». Rédigez ensuite chaque indispensable sous forme de user story courte avec ses critères d'acceptation. C'est ce document qui permet à un développeur de vous donner une estimation fiable.

Voici la méthode étape par étape, avec un modèle à reprendre.

Pourquoi le périmètre compte plus que la liste de fonctionnalités

L'Agile Alliance, reprenant Eric Ries, décrit le MVP comme la version d'un produit qui permet de « collecter le maximum d'apprentissage validé sur les clients avec le moins d'effort ». Le mot clé, c'est l'apprentissage. Un périmètre qui veut couvrir tous les utilisateurs et tous les cas repousse le moment où vous saurez si quelqu'un veut du produit.

Ce retard coûte cher. Dans l'étude 2026 de CB Insights sur 431 startups financées par du capital-risque et fermées, 43 % évoquent un mauvais product-market fit et 70 % ont manqué de capital. Un périmètre serré, c'est dépenser moins avant de savoir.

Étape 1 : écrire le problème et le pari en trois phrases

Avant toute fonctionnalité, notez :

1. Qui a le problème (soyez précis : « les femmes de ménage indépendantes à Casablanca qui prennent leurs réservations par WhatsApp », pas « les prestataires de services »).
2. Ce que le problème leur coûte aujourd'hui (temps, réservations perdues, argent).
3. Ce que vous devez apprendre : l'hypothèse qui, si elle est fausse, tue l'idée. Par exemple : « Les prestataires accepteront des réservations via une application plutôt que par WhatsApp. »

Toute fonctionnalité ajoutée ensuite doit aider à répondre à la phrase 3. Sinon, elle attend.

Étape 2 : décrire le parcours principal

Le parcours principal, c'est le chemin le plus court entre « l'utilisateur arrive » et « l'utilisateur obtient la valeur ». Écrivez-le en étapes numérotées, une ligne chacune. Pour un produit de réservation :

1. Le client ouvre le lien et voit les créneaux disponibles.
2. Il choisit un créneau, saisit son adresse et son téléphone.
3. La prestataire reçoit une notification et accepte.
4. Le client reçoit une confirmation.

Quatre étapes. Pas de comptes, de notes, de paiement ni de messagerie. Ils viendront peut-être ensuite, mais le parcours fonctionne sans eux et vous pouvez observer si les gens vont jusqu'au bout.

Avec deux types d'utilisateurs, décrivez les deux côtés du même parcours et demandez-vous si l'un d'eux peut être géré à la main au début. Un fondateur qui confirme les réservations lui-même pendant quelques semaines, c'est un MVP tout à fait valable.

Étape 3 : trier avec la méthode MoSCoW

Listez toutes les idées de fonctionnalités, puis classez-les dans quatre catégories. Les définitions viennent du cadre DSDM de l'Agile Business Consortium :

• Must have (indispensable) : sans cela, inutile de lancer.
• Should have (important) : important mais pas vital ; le produit reste viable sans, éventuellement avec un contournement.
• Could have (souhaitable) : utile, moins d'impact s'il manque.
• Won't have this time (pas cette fois) : exclu de cette version, d'un commun accord.

Le même référentiel recommande de limiter les indispensables à 60 % de l'effort au maximum, avec environ 20 % de souhaitables qui servent de marge. Si votre liste d'indispensables remplit tout le budget, il ne reste rien pour les imprévus que tout projet rencontre. Coupez jusqu'à ce que ce ne soit plus le cas.

La liste « pas cette fois » est aussi utile que celle des indispensables. Écrire « pas de messagerie intégrée en v1 » tranche la question pour toute l'équipe et l'empêche de revenir par la petite porte.

Étape 4 : fixer le temps, pas les fonctionnalités

La méthode Shape Up de Basecamp fait une distinction très utile pour un fondateur : « Une estimation part d'une conception et aboutit à un chiffre. Un appétit part d'un chiffre et aboutit à une conception. » Décidez combien de temps le MVP vaut pour vous (six semaines ? dix ?) et adaptez le périmètre pour qu'il tienne. Shape Up parle de « temps fixe, périmètre variable ».

Concrètement : donnez à votre développeur cet appétit en même temps que la liste des indispensables, et demandez-lui ce qui rentre. Cette discussion produit de meilleurs périmètres qu'un devis sur une liste de souhaits. Elle se combine bien avec des livraisons hebdomadaires, qui montrent chaque semaine l'avancement par rapport à l'appétit.

Étape 5 : ce qu'il faut laisser hors de la première version

Voici les fonctionnalités ajoutées le plus souvent « parce que toutes les applis les ont » :

• La connexion via plusieurs réseaux sociaux (une seule méthode suffit).
• Les paramètres utilisateur et les préférences de notification.
• Les tableaux de bord et statistiques d'administration (un outil d'analytics et l'interface de la base de données suffisent).
• Les notes et avis, avant d'avoir assez de transactions à noter.
• La messagerie intégrée (des liens e-mail, téléphone ou WhatsApp font l'affaire au début).
• Une deuxième langue, sauf si votre premier marché l'exige.
• Des applications natives sur les deux stores, alors qu'une application web responsive testerait la même hypothèse.

Les écarter, ce n'est pas bâcler la qualité. Ce que vous construisez doit être solide : l'Agile Alliance cite la qualité insuffisante parmi les erreurs classiques, car un produit qui plante ne dit pas si l'idée fonctionne. Les raccourcis dans le code lui-même créent une dette technique que vous paierez plus tard, et les prototypes générés par IA ont leurs propres limites, décrites dans ce que le vibe coding peut et ne peut pas faire pour un MVP.

Étape 6 : rédiger pour qu'un développeur puisse estimer

Un développeur ne peut estimer que ce qui est précis. Pour chaque indispensable, écrivez une user story et ses critères d'acceptation.

Des user stories qui passent le test INVEST

La grille INVEST, que l'Agile Alliance attribue à Bill Wake (2003), demande qu'une bonne story soit indépendante, négociable, utile, estimable, petite et testable. « Estimable » et « petite » sont les deux critères qui décident de la fiabilité du chiffre obtenu.

En tant que client, je veux choisir un créneau disponible, afin de réserver un ménage sans téléphoner.

Des critères d'acceptation sous forme d'exemples

L'Agile Alliance définit le test d'acceptation comme « une description formelle du comportement d'un logiciel, généralement exprimée sous forme d'exemple ou de scénario d'usage ». Écrivez-en deux à cinq par story :

• Les créneaux déjà réservés ne s'affichent pas.
• Impossible de réserver un créneau qui commence dans moins de deux heures.
• Après la réservation, le client voit une confirmation avec la date, l'heure et l'adresse.

Restez dans le langage métier. La même page prévient que des tests trop techniques deviennent difficiles à lire et à maintenir pour les non-développeurs.

Le reste du document de périmètre

• Plateformes : web, iOS, Android ; quels navigateurs et appareils.
• Utilisateurs et volume : nombre d'utilisateurs attendus sur les trois premiers mois.
• Intégrations : paiement, cartes, e-mail, SMS, avec les liens vers leur documentation.
• Contenus et langues : qui écrit les textes, dans quelles langues.
• Ce qui existe déjà : maquettes, charte, nom de domaine, données à importer.
• La liste « pas cette fois ».
• Les questions ouvertes : ce que vous ne savez pas encore. Mieux vaut les écrire que les cacher.

Avec ce document, vous comparez les estimations ligne par ligne et vous vérifiez le total au regard du coût habituel d'un MVP. Il indique aussi le bon type de contrat : un petit périmètre bien défini peut se faire au forfait ; un périmètre plein de questions ouvertes convient mieux à la régie ou à l'abonnement (voir forfait, régie ou abonnement).

Questions fréquentes

Combien de fonctionnalités doit avoir un MVP ?

Le minimum nécessaire pour boucler le parcours principal et tester votre hypothèse centrale. Comptez les étapes du parcours plutôt que les fonctionnalités : la plupart des bons MVP tiennent en un parcours de quatre à huit étapes.

Quelle différence entre un MVP et un prototype ?

Un prototype montre comment quelque chose pourrait fonctionner, souvent sans vraies données. Un MVP est utilisé par de vrais utilisateurs en conditions réelles, ce qui permet de mesurer leur comportement.

Qui doit rédiger le périmètre du MVP, le fondateur ou le développeur ?

Le fondateur écrit le problème, le parcours et les priorités ; le développeur les challenge, ajoute les contraintes techniques et estime. Prévoyez un ou deux allers-retours.

Faut-il rédiger un cahier des charges complet ?

Non. Quelques pages avec le problème, le parcours principal, des user stories priorisées avec critères d'acceptation et une liste « pas cette fois » suffisent pour estimer et démarrer.

Sources

1. Minimum Viable Product (MVP), Agile Alliance, consulté en octobre 2026
2. Top reasons startups fail, CB Insights, mars 2026
3. MoSCoW Prioritisation (DSDM Project Framework), Agile Business Consortium, consulté en octobre 2026
4. Shape Up, chapter 3: Set Boundaries, Basecamp, consulté en octobre 2026
5. INVEST, Agile Alliance, consulté en octobre 2026
6. Acceptance Testing, Agile Alliance, consulté en octobre 2026