Cadrer un MVP : comment décider ce qu'on coupe

5 août 2026

Tout le monde est d'accord pour faire un produit minimum viable. Personne n'est d'accord sur ce qu'on coupe. Voici un cadre qui tranche.

Une équipe cadrant un produit dans un espace de travail partagé

Les débats de périmètre portent rarement sur les fonctionnalités. Ils portent sur le risque : chacun protège ce dont l'absence l'exposerait. Un cadre aide parce qu'il déplace la discussion de l'opinion vers une question vérifiable.

Le test en trois questions

  1. La promesse centrale se brise-t-elle sans cela ? Si un utilisateur ne peut pas accomplir la tâche unique pour laquelle le produit existe, on garde. Tout le reste est négociable.
  2. Un humain peut-il le faire manuellement au volume actuel ? Reporting, validations, accueil et facturation le permettent fréquemment, pour les cent premiers clients. Le manuel n'est pas un échec : c'est une décision peu coûteuse à revenir dessus.
  3. Est-ce plus difficile à ajouter plus tard ? Tout ce qui touche au modèle de données, aux permissions ou à la facturation devient plus cher avec le temps. Ces éléments méritent leur place en version un, même sans interface dédiée.

La question n'est pas « est-ce utile ». Tout ce qui figure sur la liste est utile, c'est pour cela que c'est sur la liste. La question est « qu'est-ce qui casse, et combien coûtera l'ajout dans trois mois ».

Ce qu'il faut couper en premier

  • Les interfaces d'administration. Une vue base de données et une personne compétente font mieux qu'un back-office à moitié construit, pendant des mois.
  • Les options de configuration. Chaque réglage est une branche à développer, tester et supporter. Choisissez une valeur par défaut, changez-la quand quelqu'un se plaint.
  • Les rôles utilisateurs secondaires. Chaque rôle supplémentaire multiplie les combinaisons de permissions et la surface de test.
  • Les traitements en masse, exports et intégrations que personne n'a explicitement demandés.

Ce qu'il ne faut jamais couper

Une authentification faite correctement, un modèle de données cohérent, une gestion d'erreurs qui indique ce qui a cassé, et la capacité d'exporter vos propres données. Invisibles en démonstration, ruineux à rattraper après coup. Les couper n'est pas une réduction de périmètre : c'est un emprunt sur l'année suivante à un taux prohibitif.

  • 1 tâche centrale que le produit doit accomplir
  • 100 clients qu'un processus manuel peut généralement servir
  • 3 mois l'horizon qui rend les coupes réversibles

Questions fréquentes

Quelle taille pour une première version ?

Assez petite pour atteindre de vrais utilisateurs en trois mois environ. Au-delà, la boucle de retour est trop lente pour corriger une hypothèse fausse, et l'investissement déjà consenti rend la correction politiquement difficile.

Que faire si le client exige toutes les fonctionnalités ?

Chiffrez-les séparément et ordonnez-les par dépendance. Présentées en phases avec des coûts visibles, la plupart des listes se réduisent d'elles-mêmes — parce que la conversation passe du vouloir au payer.

À lire ensuite

  • Onboarding client : les deux semaines qui décident de la fidélité
  • Prédire l'attrition sans équipe de data science
  • La page tarifs : ce que vous coûte le fait de cacher vos prix

Vous voulez la même chose pour votre entreprise ? Voir ce que nous faisons.

Accueil Services Showroom Blog