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. webvise le traite comme un contrat d'apprentissage : un utilisateur, un parcours, une métrique de succès, et une liste stricte de ce qui est hors périmètre.
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 développeur, mais ils briefent souvent le mauvais artefact. Ce guide vous donne le modèle attendu avant un build MVP cadré, avec les exemples et les coupes qui évitent qu'un projet de 3 à 5 semaines devienne une réécriture trimestrielle.
- Le document doit acheter de l'apprentissage, pas de l'exhaustivité. Si un champ n'aide pas à prouver l'hypothèse commerciale, supprimez-le.
- Un seul parcours suffit pour la version une. Plus de parcours signifie plus d'états, plus de tests et un lancement plus lent.
- La liste hors périmètre protège le budget. Une fonctionnalité n'est pas coupée tant que tout le monde ne peut pas voir où elle a été placée.
- Le développeur a besoin de décisions, pas d'essais. Nommez l'utilisateur, l'événement, la donnée, le responsable et la métrique de lancement.
- Un bon brief MVP tient en 2 pages. Le vrai travail consiste à choisir ce qu'on n'écrit pas.
Le modèle est un contrat d'apprentissage
Un PRD classique décrit un produit. Un document d'exigences MVP décrit un test. La première ligne doit nommer l'hypothèse risquée qui justifie de construire le produit.
Cette distinction change le périmètre. Un document produit rassemble des possibilités, tandis qu'un document MVP impose un choix binaire sur ce que de vrais utilisateurs doivent accomplir avant que le prochain investissement ait du sens.
Les builds MVP de webvise sont cadrés autour du premier objectif d'apprentissage. Si votre première version nécessite l'authentification, un parcours principal, une base de données, le déploiement et l'analytique, elle appartient à un projet de 3 à 5 semaines. Cinq rôles utilisateur et trois tableaux de bord pointent généralement vers une phase ultérieure, après que le premier test a prouvé la voie.
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 précise, plus il est facile pour un développeur sérieux de chiffrer le travail sans gonfler l'estimation pour compenser l'ambiguïté.
| Section | Quoi écrire | Test de validation |
|---|---|---|
| Hypothèse risquée | La conviction commerciale que cette version doit prouver | Si elle est fausse, vous changez le produit ou vous arrêtez |
| Utilisateur principal | Un type d'utilisateur nommé, pas un segment de marché | Un développeur peut se représenter la personne utilisant le produit |
| Parcours principal | Les étapes de la première action jusqu'à la valeur | Le parcours peut être testé par un inconnu |
| Métrique de succès | Un seul chiffre qui détermine si la version une a fonctionné | La métrique est visible dans les 30 jours suivant le lancement |
| Hors périmètre | Les fonctionnalités tentantes mais exclues | Chaque partie prenante peut pointer les mêmes coupes |
| Données et intégrations | Systèmes, fichiers, API, paiements, e-mail, authentification | Aucune dépendance cachée n'apparaît en semaine deux du build |
| Contrainte de lancement | Budget, calendrier, légal, appareil, navigateur, langue | La contrainte peut bloquer le périmètre avant que le code commence |
| Décideur | La personne autorisée à accepter les coupes | Le développeur ne fait pas office de médiateur à chaque débat interne |
Ne dissimulez 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 manquante dans le 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.
- Parcours principal : 5 à 10 étapes de l'entrée jusqu'à la valeur.
- Métrique de lancement : le chiffre mesurable dans les 30 premiers jours.
- Systèmes requis : Stripe, Resend, CRM, tableur, CMS ou API interne.
- Liste hors périmètre : toutes les fonctionnalités que vous choisissez de ne pas construire maintenant.
- Règle d'acceptation : qui valide quand le build correspond au brief.
Pour un partenaire de build qui challengera ce document avant que le code commence, le service de développement MVP de webvise inclut le cadrage produit, la priorisation des fonctionnalités, le design UI, le développement full-stack, le déploiement et l'analytique de base.
Éliminer les fonctionnalités avec la grille des cinq questions
La plupart des conflits de périmètre surviennent parce que chaque fonctionnalité semble raisonnable isolément. La grille règle ce problème. Une fonctionnalité reste dans le MVP uniquement si elle survit aux cinq questions.
| Question | Conserver quand | Couper quand |
|---|---|---|
| Cela prouve-t-il l'hypothèse risquée ? | La réponse change la prochaine décision de financement, de vente ou de build | Cela rend seulement le produit plus complet en apparence |
| Le premier utilisateur en a-t-il besoin ? | L'utilisateur principal ne peut pas atteindre la valeur sans cela | Un type d'utilisateur ultérieur l'apprécierait |
| Peut-on le mesurer en 30 jours ? | Les données d'usage, de paiement, de complétion ou de réponse apparaîtront rapidement | Le signal nécessite une audience large que vous n'avez pas encore |
| Cela réduit-il le risque opérationnel ? | Cela prévient la fraude, la perte de données, un échec du support ou une exposition légale | Cela existe parce qu'un concurrent l'a |
| Un humain peut-il le faire manuellement pour la version une ? | Le travail manuel briserait la promesse ou créerait un traitement de données non sécurisé | Le travail manuel est contraignant mais acceptable pour les dix premiers utilisateurs |
La question du travail manuel fait économiser beaucoup d'argent. De nombreux fondateurs construisent des écrans d'administration, des cas limites de facturation et des centres de notification avant de savoir si quelqu'un utilisera le produit deux fois.
Mini-récit : une seule sortie comptait
Dans un MVP immobilier, le produit n'a pas démarré comme une plateforme fintech générique. Il a démarré avec une seule sortie : un acheteur devait recevoir une attestation de financement ferme sans consultation du bureau de crédit, pendant que le système comparait les offres des banques partenaires en arrière-plan. Cette sortie a façonné le périmètre davantage que n'importe quelle liste de fonctionnalités.
Cette sortie a rendu le périmètre du MVP limpide. Le parcours de financement a été construit, la génération automatisée de certificats PDF mise en place, et un tableau de bord d'administration pour le contrôle du cycle de vie des demandes a été développé. Le build a utilisé la stack de production standard : Next.js, React, tRPC, TypeScript, PostgreSQL, Drizzle ORM, Tailwind CSS, et Vercel.
| Décision de périmètre | Exemple anonymisé | Pourquoi c'est resté |
|---|---|---|
| Utilisateur principal | Acheteur immobilier | Le parcours du certificat commence avec cet utilisateur |
| Parcours principal | Formulaire de financement multi-étapes | Il capture les données nécessaires à un certificat valide |
| Sortie de succès | Certificat dans le délai promis | La promesse commerciale dépend du délai |
| Dépendance de données | Comparaison des banques partenaires | Le produit ne peut pas tenir la promesse sans la comparaison |
| Besoin d'administration | Tableau de bord du cycle de vie des demandes | L'équipe avait besoin de contrôle après soumission |
| Barre de performance | Chargement mobile rapide et bon score Lighthouse | Le tunnel devait inspirer confiance avant la saisie de données sensibles |
Une sortie précise rend un parcours long plus simple qu'une poignée de fonctionnalités vagues.
Mini-récit : les MVP vibe-codés échouent à la passation
Lovable, Bolt, et v0 sont utiles pour les prototypes parce qu'ils compressent le temps entre l'idée et l'URL publique. L'échec commence quand ce prototype est rebaptisé MVP et accueille un client payant avant que quiconque ne soit responsable de l'authentification, de l'accès aux données, des workflows d'administration ou de l'observabilité.
Dans le teardown MVP vibe-codé, la règle pour les fondateurs qui apportent ces codebases est claire : reconstruire de zéro. Un build propre sur la stack standard prend 3 à 6 semaines. La récupération 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 qui n'ont jamais été conçus délibérément.
C'est pourquoi le document d'exigences doit inclure la surface de passation. Si un client paie, le MVP a besoin d'un vrai modèle de données, de règles de session, d'actions d'administration et de monitoring dès le premier jour. Si le document dit seulement connexion, tableau de bord et fonctionnalité IA, le développeur comblera les parties les plus risquées sans votre contribution.
Comment remettre le document à une agence
Envoyez le document avant la première estimation, puis jugez l'agence sur les questions qu'elle pose. Un bon développeur coupe, challenge et séquence le périmètre. Un développeur moins rigoureux accepte toutes les fonctionnalités et cache le coût dans un devis plus élevé.
- Fourchette budgétaire : précisez s'il s'agit d'une décision à 5 000 €, 15 000 € ou 50 000 € avant que le périmètre s'élargisse.
- Calendrier : nommez la date de lancement et la raison pour laquelle elle compte.
- Preuves existantes : incluez les chiffres de liste d'attente, les interviews, les liens de prototype, les lettres d'intention payantes ou les données de workflow manuel.
- Comptes requis : listez les accès Stripe, Vercel, Supabase, PostHog, CRM, e-mail et domaine avant le démarrage.
- Liste des interdits : précisez ce qui ne peut pas arriver, comme stocker des données médicales, utiliser un backend no-code, ou lancer sans journaux d'audit.
- Responsable des coupes : nommez la personne qui peut supprimer une fonctionnalité dans les 24 heures.
Pour contexte, webvise construit des MVPs avec Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel, CI/CD, analytique et déploiement dans le périmètre initial. La stack soutient l'objectif : un MVP assez propre pour grandir quand le test fonctionne.
Le test final avant l'envoi
Lisez chaque ligne et demandez-vous si elle aide le développeur à prendre une décision de périmètre. Si elle ne change pas ce qui sera construit, mesuré, coupé ou reporté, supprimez-la.
| Ligne faible | À réécrire en | Pourquoi ça fonctionne |
|---|---|---|
| Les utilisateurs peuvent gérer leur profil | Les acheteurs peuvent modifier leur nom, e-mail, téléphone et montant de financement avant la génération du certificat | Nomme l'utilisateur, les champs et le parcours |
| Tableau de bord d'administration | Le personnel peut voir les nouvelles demandes de certificat, changer le statut et télécharger le PDF généré | Précise le vrai travail d'administration |
| Recommandations IA | Le système signale les données de financement manquantes avant soumission en utilisant d'abord des règles de validation fixes | Évite un périmètre IA vague jusqu'à ce que la règle soit connue |
| Paiements plus tard | Stripe est hors périmètre pour la version une, sauf si un pilote payant est signé avant le démarrage | Transforme une idée future en déclencheur |
| Compatible mobile | Le formulaire de financement doit être utilisable sur un téléphone étroit avant le polish desktop | Rend la contrainte d'appareil testable |
Un document d'exigences MVP court semblera inconfortable parce qu'il expose la vraie décision. C'est précisément l'objectif. Le document doit rendre évident ce sur quoi vous pariez, ce que vous refusez de construire, et quel résultat justifiera la prochaine version.
webvise aide les fondateurs à transformer cette décision en une première version livrée plutôt qu'en une liste de fonctionnalités gonflée. Si votre brief MVP est proche mais encore trop large, envoyez-le à webvise et vous entendrez exactement ce qui serait coupé avant la première semaine de build.