De l'idée au MVP : que faut-il construire en premier ?

Le premier produit doit produire une preuve, pas une impression

Face à une idée nouvelle, l'équipe imagine naturellement la solution complète : espace client, automatisations, tableau de bord, notifications et personnalisation. Le MVP devrait pourtant commencer ailleurs. Il doit rendre testable l'hypothèse qui pourrait invalider tout le projet.

Construire en premier ne signifie donc pas coder les écrans les plus visibles. Il faut identifier ce que l'on ignore encore : le problème est-il assez important, le public adoptera-t-il le nouveau comportement, l'entreprise peut-elle délivrer la promesse, le modèle peut-il fonctionner ? Le périmètre dépend de cette incertitude.

Reformulez l'idée comme une situation à améliorer

« Créer une plateforme pour les artisans » décrit une forme, pas une valeur. Commencez par une situation précise : qui rencontre quel obstacle, dans quel contexte et avec quelle conséquence ? Plus le problème est vague, plus le produit devient une liste d'options supposées utiles.

Le GOV.UK Service Manual conseille d'étudier les objectifs des utilisateurs, leurs pratiques actuelles et leurs frustrations avant de concevoir le service. Cette étape ne promet pas une certitude absolue. Elle permet d'éviter de traiter une intuition interne comme un besoin démontré.

Interrogez des personnes réellement concernées, observez leurs outils et examinez les traces disponibles : demandes reçues, recherches, tickets, tableurs ou contournements. Ce que les personnes font révèle parfois un problème différent de ce qu'elles déclarent souhaiter.

Cherchez l'hypothèse la plus risquée

Une hypothèse est risquée si sa fausseté rend le projet inutile ou non viable. Elle n'est pas forcément technique. Une équipe peut savoir construire un moteur de réservation et ignorer si les professionnels accepteront de maintenir leurs disponibilités. Dans ce cas, l'adoption est plus risquée que le code.

Classez les incertitudes en quatre familles : désirabilité, capacité d'usage, faisabilité opérationnelle et viabilité économique. Puis choisissez celle qui cumule fort impact et faible niveau de preuve. C'est elle que la première expérience doit attaquer.

Le Service Manual britannique recommande de concentrer la phase alpha sur les hypothèses les plus risquées et de construire juste assez pour tester différentes idées, sans viser immédiatement la qualité de production. Cette distinction protège le budget et le calendrier.

Choisissez la forme de test la moins coûteuse qui reste crédible

Toutes les hypothèses ne nécessitent pas une application fonctionnelle. Une page d'offre et des entretiens peuvent tester l'intérêt. Un prototype cliquable peut vérifier la compréhension d'un parcours. Un service exécuté manuellement derrière une interface simple peut éprouver la valeur avant l'automatisation.

Le guide GOV.UK sur les prototypes rappelle qu'un prototype peut aller du croquis au code interactif et qu'il doit être choisi selon la question posée. Il précise aussi que le code de prototype n'offre pas nécessairement les garanties de sécurité, de performance ou de maintenabilité exigées en production.

Cette limite mérite d'être annoncée. Une démonstration convaincante ne doit pas devenir par inertie le socle du produit. Si le test fonctionne, l'équipe décide ensuite ce qui peut être conservé, durci ou reconstruit.

Définissez un parcours complet, même très étroit

Un MVP composé de morceaux isolés produit peu d'apprentissage. Mieux vaut permettre à un petit groupe d'accomplir une tâche de bout en bout que montrer à tout le monde une interface riche sans résultat final.

Pour un outil de devis, le parcours initial pourrait être : créer un client, sélectionner trois prestations, générer un document et l'envoyer. La bibliothèque complète, les relances automatiques et les statistiques viendront plus tard. Le test porte déjà sur la promesse centrale : réduire l'effort nécessaire pour produire un devis exploitable.

Pour une place de marché, une simple mise en relation gérée manuellement peut révéler si l'offre et la demande se rencontrent. Une plateforme sophistiquée ne résout pas l'absence de participants ni la faiblesse de la proposition de valeur.

Fixez le signal attendu avant de lancer

Sans critère préalable, chaque réaction devient interprétable comme un encouragement. Définissez ce qui constituerait une preuve suffisante pour investir, un signal mitigé qui appelle une nouvelle expérience et un résultat qui impose d'arrêter ou de reformuler.

Les indicateurs doivent correspondre au risque. Pour la compréhension, observez la réussite d'une tâche et les erreurs. Pour l'intérêt, mesurez les engagements réels plutôt que les compliments. Pour la rétention, vérifiez si les personnes reviennent accomplir le même travail sans relance exceptionnelle.

Évitez le seuil arbitraire présenté comme scientifique. Un test avec cinq personnes ne prédit pas un marché. Il peut toutefois révéler des incompréhensions majeures. Une campagne d'inscription mesure une intention, pas l'usage futur. Chaque preuve a une portée qu'il faut nommer.

Incluez dès le départ les conditions invisibles de la promesse

Le parcours visible n'est qu'une partie du produit. Si la valeur dépend d'un traitement humain, d'une donnée externe, d'un délai ou d'une compétence rare, testez aussi cette chaîne. Une expérience séduisante peut cacher un service impossible à délivrer économiquement.

Calculez le temps réellement passé, les exceptions, les demandes de support et les erreurs. Identifiez ce qui peut rester manuel à faible volume et ce qui deviendra un blocage. Le MVP ne doit pas automatiser trop tôt, mais il doit éclairer le futur coût de la promesse.

La sécurité, la protection des données et l'accessibilité ne sont pas des ornements de version finale. Leur profondeur varie selon le test, mais une expérience impliquant de vraies personnes et données exige des précautions proportionnées. Un prototype protégé et alimenté par des données fictives n'a pas le même risque qu'un service ouvert.

Organisez la décision qui suit l'expérience

Un MVP utile mène à une décision : poursuivre, ajuster, changer d'hypothèse ou arrêter. Documentez les observations, les limites de l'échantillon et les nouvelles questions. Ne transformez pas automatiquement chaque demande individuelle en fonctionnalité.

La recherche utilisateur doit se poursuivre en bêta et en production. Le GOV.UK Service Manual recommande notamment d'associer tests, données d'usage, support et retours des personnes qui délivrent le service.

Ce qu'il faut construire en premier est donc la plus petite preuve utile. Parfois, ce sera un écran. Parfois, un processus manuel, une simulation ou une page. La rigueur ne se mesure pas au volume de code, mais à la qualité de la question et à la clarté de la décision rendue possible.

Pistes de lecture

1. GOV.UK Service Manual, How the alpha phase works
2. GOV.UK Service Manual, Making prototypes
3. GOV.UK Service Manual, User research in beta

Pour aller plus loin

Si votre idée attire déjà une longue liste de fonctionnalités, un cadrage court peut isoler l'hypothèse à tester et concevoir un premier périmètre réellement décisif.