Modèle de document d'exigences MVP : le périmètre qui part en production
Un bon document d'exigences MVP n'est pas un backlog de fonctionnalités. Utilisez ce modèle pour définir l'apprentissage, couper le périmètre et briefer un build livrable.
Un modèle de document d'exigences MVP doit définir ce que la première version doit prouver, pas tout ce que le produit pourrait devenir. Chez webvise, nous le traitons comme un contrat d'apprentissage : un utilisateur, un workflow, une métrique de succès et une liste out-of-scope stricte.
Si votre document ressemble à un backlog de fonctionnalités, votre MVP est déjà trop grand.
Les fondateurs connaissent généralement le produit mieux que le builder, mais ils briefent souvent le mauvais artefact. Ce guide vous donne le modèle que nous voulons voir avant un build MVP à prix fixe, avec les exemples et les coupes qui empêchent un build de 3 à 5 semaines de devenir une réécriture sur un trimestre.
Le document doit acheter de l'apprentissage, pas de la complétude. Si un champ n'aide pas à prouver l'hypothèse commerciale, coupez-le.
Un workflow suffit pour la version une. Plus de workflows signifie plus d'états, plus de tests et un lancement plus lent.
La liste out-of-scope protège le budget. Une fonctionnalité n'est pas coupée tant que tout le monde ne voit pas où elle est passée.
Le builder a besoin de décisions, pas d'essais. Nommez l'utilisateur, l'événement, les données, le propriétaire et la métrique de lancement.
Un bon brief MVP peut tenir sur 2 pages. Le travail difficile consiste à choisir ce que vous n'écrivez pas.
Le modèle est un contrat d'apprentissage
Un PRD normal explique un produit. Un document d'exigences MVP explique un test. La première ligne doit nommer l'hypothèse risquée qui rend le produit digne d'être construit.
Cette distinction change le périmètre. Un document produit collecte des possibilités, tandis qu'un document MVP force une décision oui ou non sur ce que de vrais utilisateurs doivent faire avant que le prochain investissement ait du sens.
Les builds MVP webvise commencent à €5,000 parce que nous cadrons la première version autour de l'objectif d'apprentissage, pas autour d'un backlog rêvé. Si votre première version a besoin d'auth, d'un workflow central, d'une base de données, du déploiement et d'analytics, elle appartient à un build de 3 à 5 semaines. Si elle exige cinq rôles utilisateurs et trois dashboards, ce n'est plus le premier test.
Copiez ce modèle de document d'exigences MVP
Utilisez-le comme brief de deux pages avant de demander un devis. Plus la réponse est serrée, plus un builder sérieux peut chiffrer le travail sans gonfler l'estimation pour couvrir l'ambiguïté.
| Section | Ce que vous écrivez | Test de réussite |
|---|---|---|
| Hypothèse risquée | La croyance commerciale que cette version doit prouver | Si elle est fausse, vous changez ou arrêtez le produit |
| Utilisateur principal | Un type d'utilisateur nommé, pas un segment de marché | Un builder peut imaginer la personne utilisant le produit |
| Workflow central | Les étapes entre première action et valeur | Le workflow peut être testé par un inconnu |
| Métrique de succès | Un nombre qui décide si la version une a fonctionné | La métrique est visible dans les 30 jours après lancement |
| Out of scope | Les fonctionnalités tentantes mais exclues | Chaque partie prenante pointe vers les mêmes coupes |
| Données et intégrations | Systèmes, fichiers, APIs, paiements, e-mail, auth | Aucune dépendance cachée n'apparaît en semaine deux du build |
| Contrainte de lancement | Budget, calendrier, juridique, appareil, navigateur, langue | La contrainte peut bloquer le périmètre avant le code |
| Propriétaire de décision | La personne autorisée à accepter les coupes | Le builder ne médie pas chaque débat interne |
Ne cachez pas l'incertitude. Si vous ne connaissez pas encore la métrique, écrivez le proxy le plus proche et marquez-le comme provisoire. Une décision absente du document devient une réunion pendant le build.
Titre de travail : une phrase qui dit ce que fait le produit.
Utilisateur principal : le premier utilisateur que vous recruterez, pas tous les acheteurs possibles.
Workflow central : 5 à 10 étapes de l'entrée à la valeur.
Métrique de lancement : le nombre que vous pouvez mesurer dans les 30 premiers jours.
Systèmes requis : Stripe, Resend, CRM, tableur, CMS ou API interne.
Liste out-of-scope : chaque fonctionnalité que vous choisissez de ne pas construire maintenant.
Règle d'acceptation : qui signe quand le build correspond au brief.
Si vous voulez un partenaire de build qui challenge ce document avant le code, le service MVP development de webvise inclut cadrage produit, priorité des fonctionnalités, design UI, développement full-stack, déploiement et analytics de base.
Coupez les fonctionnalités avec le filtre en cinq questions
La plupart des conflits de périmètre arrivent parce que chaque fonctionnalité semble raisonnable isolément. Le filtre corrige cela. Une fonctionnalité reste dans le MVP seulement si elle passe les cinq questions.
| Question | Gardez-la quand | Coupez-la quand |
|---|---|---|
| Prouve-t-elle l'hypothèse risquée ? | La réponse change la prochaine décision de financement, de vente ou de build | Elle rend seulement le produit plus complet |
| Le premier utilisateur en a-t-il besoin ? | L'utilisateur principal ne peut pas atteindre la valeur sans elle | Un type d'utilisateur futur l'apprécierait |
| Peut-elle être mesurée en 30 jours ? | Des données d'usage, paiement, complétion ou réponse apparaîtront vite | Le signal exige une large audience que vous n'avez pas encore |
| Réduit-elle un risque opérationnel ? | Elle prévient fraude, perte de données, échec support ou exposition juridique | Elle existe parce qu'un concurrent l'a |
| Un humain peut-il le faire manuellement en version une ? | Le manuel casserait la promesse ou créerait une gestion de données risquée | Le manuel est pénible mais acceptable pour les dix premiers utilisateurs |
La question du travail manuel économise de l'argent réel. Beaucoup de fondateurs construisent des écrans admin, des cas limites de facturation et des centres de notifications avant de savoir si quelqu'un utilisera le produit deux fois.
Mini-histoire : OHYP avait une sortie qui comptait
Le 2026-02-20, nous avons publié la case study OHYP GmbH, un service immobilier berlinois qui avait besoin de certificats de financement pour acheteurs immobiliers. Le produit n'a pas commencé comme une plateforme fintech générique. Il a commencé avec une sortie : un acheteur devait recevoir un certificat contraignant en moins de 24 heures, sans enquête de crédit SCHUFA, pendant que le système comparait plus de 550 banques partenaires.
Cette sortie a rendu le périmètre MVP clair. Nous avons construit un formulaire de financement en 10 étapes, la génération automatisée de certificats PDF et un dashboard admin pour le cycle de vie des demandes. Le build a été livré en 6 semaines avec Next.js, React, tRPC, TypeScript, PostgreSQL, Drizzle ORM, Tailwind CSS et Vercel.
| Décision de périmètre | Exemple OHYP | Pourquoi c'est resté |
|---|---|---|
| Utilisateur principal | Acheteur immobilier en Allemagne | Le workflow de certificat commence avec cet utilisateur |
| Workflow central | Formulaire de financement en 10 étapes | Il capture les données nécessaires à un certificat valide |
| Sortie de succès | Certificat en moins de 24 heures | La promesse commerciale dépend du délai |
| Dépendance de données | Plus de 550 banques partenaires | Le produit ne peut pas tenir la promesse sans comparaison |
| Besoin admin | Dashboard du cycle de vie des demandes | L'équipe avait besoin de contrôle après soumission |
| Seuil de performance | 96 Lighthouse, chargement sous 1.2s | Le funnel devait inspirer confiance avant la saisie de données sensibles |
La leçon n'est pas que chaque MVP a besoin d'un formulaire en 10 étapes. La leçon est qu'une sortie nette rend dix étapes plus petites que cinq fonctionnalités vagues.
Mini-histoire : les MVP vibe-coded échouent au handoff
Lovable, Bolt et v0 sont utiles pour les prototypes parce qu'ils réduisent le délai entre idée et URL publique. L'échec commence quand ce prototype est renommé MVP et accepte un client payant avant que quelqu'un possède l'auth, l'accès aux données, les workflows admin ou l'observabilité.
Dans notre teardown des MVP vibe-coded, nous avons posé la règle que nous utilisons quand des fondateurs nous apportent ces codebases : nous reconstruisons de zéro. Un build propre sur notre stack prend 3 à 6 semaines. Le salvage prend 8 à 12 semaines parce que chaque correction doit respecter un schéma, une structure de routes et un modèle de données live que personne n'a conçus.
C'est pourquoi le document d'exigences doit inclure la surface de handoff. Si un client paie, le MVP a besoin dès le premier jour d'un vrai modèle de données, de règles de session, d'actions admin et de monitoring. Si le document dit seulement login, dashboard et fonctionnalité AI, le builder remplit les parties les plus risquées sans votre input.
Comment transmettre le document à une agence
Envoyez le document avant la première estimation, puis jugez l'agence aux questions qu'elle pose. Un bon builder coupe, challenge et séquence le périmètre. Un builder faible accepte chaque fonctionnalité et cache le coût dans un devis plus grand.
Bande budgétaire : dites si c'est une décision à €5,000, €15,000 ou €50,000 avant que le périmètre ne grandisse.
Calendrier : nommez la date de lancement et la raison pour laquelle elle compte.
Preuve existante : incluez chiffres de waitlist, interviews, liens de prototype, lettres d'intention payées ou données de workflow manuel.
Comptes requis : listez Stripe, Vercel, Supabase, PostHog, CRM, e-mail et accès domaine avant kickoff.
Liste de non strict : indiquez ce qui ne peut pas arriver, comme stocker des données médicales, utiliser un backend no-code ou lancer sans audit logs.
Propriétaire de coupe : nommez la personne qui peut retirer une fonctionnalité en 24 heures.
Pour contexte, webvise construit des MVP avec Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel, CI/CD, analytics et déploiement dans le périmètre initial. Cette stack n'est pas le sujet. Le sujet est que le MVP doit être assez propre pour grandir quand le test fonctionne.
Le dernier test avant l'envoi
Lisez chaque ligne et demandez si elle aide le builder à prendre une décision de périmètre. Si elle ne change pas ce qui est construit, mesuré, coupé ou reporté, retirez-la.
| Ligne faible | Réécrivez en | Pourquoi cela marche |
|---|---|---|
| Les utilisateurs peuvent gérer leur profil | Les acheteurs peuvent modifier nom, e-mail, téléphone et montant de financement avant génération du certificat | Cela nomme l'utilisateur, les champs et le workflow |
| Dashboard admin | Le staff peut voir les nouvelles demandes de certificat, changer le statut et télécharger le PDF généré | Cela décrit le vrai travail admin |
| Recommandations AI | Le système signale les données de financement manquantes avant soumission avec des règles fixes de validation d'abord | Cela évite le périmètre AI vague tant que la règle est inconnue |
| Paiements plus tard | Stripe est out of scope pour la version une sauf si un pilote payé est signé avant kickoff | Cela transforme une idée future en déclencheur |
| Mobile friendly | Le formulaire en 10 étapes doit être utilisable sur un téléphone de 390px de large avant le polish desktop | Cela rend la contrainte appareil testable |
Un document d'exigences MVP court sera inconfortable parce qu'il expose la vraie décision. C'est le but. Le document doit rendre évident ce sur quoi vous pariez, ce que vous refusez de construire et quel résultat justifiera la version suivante.
webvise aide les fondateurs à transformer cette décision en première version livrée, pas en liste de fonctionnalités gonflée. Si votre brief MVP est proche mais encore trop large, envoyez-le à webvise et nous vous dirons ce que nous couperions avant la première semaine de build.