Ce qu’il faut décider avant de construire un MVP

Un MVP n’est pas une version réduite de chaque idée de votre feuille de route. C’est le plus petit produit utile qui permet à un groupe défini de personnes d’accomplir un flux de travail important et qui donne à l’équipe des preuves pour la décision suivante.

Ce mot — preuves — mérite qu’on s’y arrête.

L’analyse de CB Insights sur les causes d’échec des start-ups (s’ouvre dans un nouvel onglet), publiée en mars 2026, a examiné 431 entreprises financées par capital-risque ayant fermé publiquement depuis 2023. Elle relève un manque de capitaux dans 70 % des cas et une mauvaise adéquation produit-marché dans 43 %.

Son observation la plus utile porte sur le moment où surviennent les échecs d’adéquation : « deux tiers des échecs d’adéquation produit-marché concernaient des entreprises en phase précoce qui n’ont jamais trouvé de marché. »

L’argent, c’est la façon dont cela finit. Ne pas apprendre assez vite est souvent la raison. Le même principe vaut pour un outil interne : sa première version doit prouver qu’un flux de travail important fonctionne mieux.

La première version n’est donc pas une démonstration de votre ambition. C’est un instrument pour découvrir quelque chose. Les décisions ci-dessous déterminent si elle peut le faire.

Ce qu’un MVP n’est pas

Trois contresens causent l’essentiel des dégâts, et il vaut mieux les nommer avant de planifier :

• Une version moins chère du produit complet. Baisser la qualité partout vous laisse quelque chose que personne ne peut juger. Réduisez plutôt le périmètre, et construisez correctement ce qui reste.
• Un prototype. Un prototype répond à une question de conception puis est jeté. Un MVP est un vrai logiciel avec de vrais utilisateurs, et il doit être maintenable.
• Une architecture définitive. La première version doit pouvoir changer. Les décisions coûteuses à annuler méritent plus de réflexion que les autres.

La question utile n’est pas « quel est le minimum que nous puissions construire ? » C’est « quel est le minimum que nous puissions construire qui nous apprendrait encore quelque chose sur quoi nous agirions ? »

Faut-il vraiment développer sur mesure ?

Avant de cadrer un développement sur mesure, il vaut la peine de se demander si vous en avez déjà besoin.

Le logiciel sur mesure est la bonne réponse quand votre flux de travail est vraiment spécifique, quand vous devez posséder le résultat, ou quand les outils du marché ne peuvent pas se connecter comme votre activité fonctionne.

C’est souvent la mauvaise première réponse quand un outil no-code, un tableur ou un produit existant vous permettrait de tester la même hypothèse cette semaine.

Une séquence utile consiste à valider la demande avec la chose la moins chère qui marche, puis à développer sur mesure une fois que vous savez quelles parties en ont vraiment besoin.

Beaucoup de produits à succès commencent comme un processus manuel ou un assemblage d’outils. Ils ne deviennent du logiciel sur mesure que là où cet assemblage commence à faire mal.

Développer sur mesure trop tôt dépense votre budget à prouver ce qu’un test bien moins cher aurait pu vous dire. Le faire trop tard vous laisse lutter contre des outils qui ne conviennent plus.

Répondez-y honnêtement avant de commencer à définir le périmètre, pas après.

Commencez par le flux de travail de l’utilisateur

Avant de parler technique, décrivez qui utilisera le produit, dans quelle situation cette personne se trouve et la tâche qu’elle doit accomplir. Si cela reste flou, le flou vous suit dans chaque écran et chaque fonction.

Écrivez le flux principal comme une courte séquence. Par exemple : un client soumet une demande, un membre de l’équipe l’examine, le système enregistre la décision, et les deux parties voient l’étape suivante.

Le Government Digital Service britannique en fait une phase de découverte. Son manuel des services (s’ouvre dans un nouvel onglet) est direct sur l’ordre des choses : « avant de vous engager à construire un service, vous devez comprendre le problème à résoudre. »

Il évoque environ quatre à huit semaines comme durée typique de cette découverte, se terminant par une décision explicite sur l’existence même d’un service viable.

Une investigation courte et bornée avec un vrai go/no-go coûte moins cher qu’une construction qui découvre la même chose au cinquième mois.

Définissez ce qui entre dans le périmètre

Séparez ensuite l’indispensable de l’utile plus tard. Connexion, permissions, paiements, notifications, rapports, intégrations et outils d’administration comptent peut-être tous, mais la première version n’a pas besoin de les développer tous au même niveau.

Un bon périmètre a une raison pour chaque fonctionnalité. Gardez une fonctionnalité dans la première version si elle satisfait au moins un de ces tests :

1. le premier utilisateur ne peut pas accomplir le flux principal sans elle
2. elle réduit un risque de livraison déjà identifié
3. il donne à l’équipe le contrôle dont elle a besoin dès le premier jour
4. l’omettre imposerait une réécriture plutôt qu’un ajout

Si une fonctionnalité n’en satisfait aucun, c’est une décision ultérieure et non une coupe. La consigner ainsi désamorce souvent la dispute sur son retrait.

Décidez comment vous saurez que ça a marché

Avant le début de la construction, convenez du résultat qui justifierait de continuer, de changer de direction ou d’arrêter. Sans cela, chaque issue paraît encourageante.

Choisissez des signaux observables dans les premières semaines d’usage réel, pas ceux qui demandent un an de données :

• les gens accomplissent le flux principal sans qu’on les guide
• ils reviennent sans qu’on les relance
• le travail manuel remplacé par le produit diminue nettement
• quelqu’un demande la fonctionnalité suivante plutôt qu’un correctif de base

Écrivez ce que vous attendez et pour quand. Comparer cela à ce qui arrive est tout l’intérêt d’une sortie précoce.

Écrivez ce que « terminé » veut dire

Définissez ce que « fonctionne » signifie avant le début du développement. Utilisez des critères d’acceptation observables : l’utilisateur peut soumettre une demande, la bonne personne peut l’examiner, et le système enregistre correctement le résultat.

Les recommandations du GDS sur la rédaction des user stories (s’ouvre dans un nouvel onglet) décrivent les critères d’acceptation comme « une liste de résultats que vous utilisez comme liste de contrôle pour confirmer que votre service a fait son travail », chacun formulé sous la forme c’est fait quand… — un énoncé.

L’intérêt est qu’ils peuvent être vérifiés par quelqu’un qui ne les a pas construits.

Au niveau de la version, The Scrum Guide (s’ouvre dans un nouvel onglet) définit la Definition of Done comme « une description formelle de l’état de l’incrément lorsqu’il satisfait aux mesures de qualité requises pour le produit ».

Que vous pratiquiez Scrum ou non, l’idée voyage. Un seuil de qualité écrit et accepté empêche « terminé » de signifier autre chose pour chaque personne dans la conversation.

Fixez les règles de données avant le schéma

Décidez quelles informations le produit doit stocker et qui peut y accéder. Confidentialité, permissions, conservation, sauvegardes et besoins d’audit se planifient plus facilement avant les premières tables de base de données et intégrations.

Pour les produits qui traitent des données personnelles de personnes dans l’UE, procéder dans cet ordre est la loi, pas une préférence.

Les orientations de la Commission européenne sur la protection des données dès la conception et par défaut (s’ouvre dans un nouvel onglet) décrivent des mesures qui s’attachent aux toutes premières étapes de la conception du traitement, avec des réglages par défaut tels que « les données à caractère personnel sont traitées avec le plus haut niveau de protection de la vie privée ».

Le Comité européen de la protection des données a adopté des lignes directrices sur l’article 25 (s’ouvre dans un nouvel onglet) dans leur version finale en octobre 2020, si vous avez besoin de la position détaillée du régulateur.

En pratique, c’est une courte liste à écrire : ce que vous collectez, pourquoi, qui peut le voir, combien de temps vous le gardez et comment quelqu’un obtient sa suppression.

Y répondre avant de concevoir la base de données coûte bien moins cher que de l’ajouter après coup.

Choisissez la technologie et l’IA avec soin

Choisissez la technologie autour du produit et de ses contraintes. Un framework moderne peut convenir, mais le meilleur choix dépend des utilisateurs, des données, des intégrations, des besoins de livraison et des personnes qui maintiendront le logiciel.

L’IA mérite la même discipline. Décidez si elle soutient le flux principal, ce qui se passe quand sa sortie est fausse, et comment une personne peut la relire ou la corriger, avant de la traiter comme une exigence produit.

Il y a maintenant des raisons mesurées d’être prudent. Le 2025 DORA report (s’ouvre dans un nouvel onglet), qui s’appuie sur les réponses de près de 5 000 professionnels de la technologie, indique que « l’adoption de l’IA continue d’avoir une relation négative avec la stabilité de la livraison logicielle ».

Une production plus rapide sans tests ni relecture solides ne se cumule pas en livraison plus rapide. Elle se cumule en reprises.

Prévoyez les revues, les accès, la reprise

Prévoyez les points de revue avant la première ligne de code. Des démonstrations courtes, une liste de tâches partagée et des décisions écrites que chacun peut voir permettent de corriger le cap tant que corriger le cap coûte encore peu.

Le US Government Accountability Office expose l’argument du risque dans son Agile Assessment Guide (s’ouvre dans un nouvel onglet), où la livraison incrémentale avec évaluation continue « peut réduire les risques de financer un programme qui échoue ou produit une technologie obsolète ».

Convenez de la propriété et des accès dès le début. Le projet doit avoir un dépôt de code clair, des environnements documentés, un chemin de déploiement convenu et un plan de reprise qui ne dépend pas du compte privé d’une seule personne.

La capacité DORA gestion de versions (s’ouvre dans un nouvel onglet) précise ce qui doit s’y trouver : code applicatif et dépendances, outils de création d’environnements, fichiers de composition de conteneurs, configuration cloud et artefacts d’IA tels que les prompts.

Sa base affichée : « la recherche montre constamment qu’un usage complet de la gestion de versions prédit la livraison continue ».

Les recommandations du GDS sur la gestion de versions (s’ouvre dans un nouvel onglet) ajoutent l’autre moitié de la règle, la revue : « chaque changement de code est relu par quelqu’un qui ne l’a pas écrit ».

Ensemble, ces habitudes rendent une reprise possible. Si recréer le système dépend de l’ordinateur portable de quelqu’un, vous n’avez pas un livrable — vous avez une dépendance.

Planifiez le calendrier et le budget

Un MVP resserré se planifie souvent autour d’une fenêtre de livraison de 6 à 8 semaines quand le périmètre s’y prête. C’est un repère de planification, pas une promesse universelle ; intégrations, validations et systèmes hérités inconnus peuvent changer le calendrier.

Il est utile de savoir comment les délais logiciels dérapent, car ils ne dérapent pas de la même façon dans les deux sens.

Une étude de 5 392 projets informatiques publiée dans le Journal of Management Information Systems (s’ouvre dans un nouvel onglet) a montré que les dépassements de coûts suivent une loi de puissance plutôt qu’une distribution normale.

La plupart des dépassements sont modestes, mais il existe « une queue épaisse comprenant un plus petit nombre de projets aux dépassements extrêmes ». Planifier sur la moyenne sous-estime le risque qui compte.

Ce n’est pas seulement un problème de start-up. L’évaluation à haut risque de l’informatique fédérale par le GAO (s’ouvre dans un nouvel onglet), publiée en janvier 2025, note que les investissements informatiques fédéraux « échouent trop souvent ou subissent des dépassements de coûts et des glissements de calendrier tout en contribuant peu aux résultats liés à la mission ».

Et cela pour une dépense annuelle supérieure à 100 milliards de dollars. L’échelle et le budget ne règlent pas cela ; la discipline de périmètre et des boucles de retour courtes, si.

Budgétez des décisions, pas seulement des heures de code. Cadrage, conception, construction, tests, déploiement, contenu, services tiers et corrections après le lancement s’ajoutent tous à ce qu’il faut pour rendre la première version utile.

Un exemple concret

Prenez un fondateur qui veut une plateforme de réservation : les clients réservent des rendez-vous, les prestataires gèrent des agendas, les deux parties paient et reçoivent des rappels, et un administrateur supervise l’ensemble. C’est un vrai produit avec une longue liste de fonctionnalités.

Le flux principal, lui, est étroit : un client trouve un créneau libre et le réserve, et le prestataire voit la réservation. Tout le reste soutient cela ou peut attendre.

Une première version disciplinée pourrait ressembler à ceci :

• Dans le périmètre : disponibilités du prestataire, réservation client, une confirmation et une vue simple des réservations à venir côté prestataire.
• Reporté : paiements dans l’application (prendre d’abord un acompte manuellement), rappels automatiques, avis, recherche multi-prestataires et tableau de bord d’administration.
• Décidé d’avance : quelles données client sont stockées et pour combien de temps, à qui appartient le dépôt, et ce que « une réservation a fonctionné » signifie comme critère d’acceptation.

La liste reportée n’est pas abandonnée — c’est la feuille de route. Mais livrer le cœur d’abord répond à la seule question qui compte tôt : les prestataires tiendront-ils leurs agendas à jour, et les clients réserveront-ils ?

Si oui, le reste vaut la peine d’être construit. Si non, aucune intégration de paiement ne l’aurait sauvé.

Pour commencer

Le but n’est pas de tout prédire. Le but est de rendre visibles les hypothèses importantes, de tester le flux principal et de créer une base produit qui peut être améliorée sans jeter le travail.

Si vous avez une idée mais pas de spécification complète, partez de l’utilisateur, du flux de travail et de la décision que la première version doit soutenir. Ces trois points suffisent pour engager une conversation de planification utile.