GUIDE DE CADRAGE · SAAS ET APPLICATIONS WEB
Cadrer un MVP SaaS
Un MVP n'est pas une version réduite de tout. C'est un parcours complet qu'un utilisateur réel peut terminer, avec les rôles, les données et la reprise que ce parcours exige.
Discuter du périmètre de votre produitJiangmen, Chine. Travailler à l’échelle mondiale.
Commencer par un parcours, de bout en bout
Décrivez le parcours avec les mots de l'utilisateur : ce qu'il apporte, ce qu'il fait, ce qu'il emporte. Si une étape exige une autre personne ou un autre système, elle fait partie du périmètre.
Un portail client qui reçoit une demande, l'attribue à un membre de l'équipe et affiche l'avancement est un parcours complet. Un tableau de bord à six modules inachevés ne l'est pas.
Rôles et permissions se décident tôt
Qui peut créer, modifier, approuver et supprimer ? Quelles données chaque rôle voit-il ? Des permissions décidées après l'interface imposent souvent de refaire les écrans.
Écrivez chaque rôle en une phrase, puis parcourez le parcours principal avec chacun. Les manques repérés ici coûtent bien moins cher que ceux découverts en recette.
Données et intégrations déterminent le devis
Listez les systèmes que le produit doit lire ou alimenter, et le comportement attendu si l'un est indisponible. Précisez les limites : quotas, pagination, authentification et message affiché en cas d'échec de synchronisation.
Si vous avez des tableurs ou une base ancienne, décrivez leur structure avec des extraits anonymisés. La migration est souvent sous-estimée parce que les données actuelles n'ont jamais été documentées.
Exclure volontairement
Facturation, modules de reporting, applications mobiles natives, authentification unique et recherche avancée relèvent souvent d'une deuxième phase. Les nommer hors périmètre n'est pas une faiblesse : cela rend la première version testable.
Actez par écrit ce que la première version ne fera pas, pour que personne ne découvre la limite au moment de la recette.
Des critères d'acceptation réellement testables
Pour chaque étape, écrivez le comportement attendu et le comportement en cas d'échec. Décidez ensuite qui valide et quelle preuve compte : un enregistrement d'écran, un compte de test, une liste de contrôles.
Rédigés ainsi, les critères transforment un « ça a l'air fini » en une décision que les deux parties prennent en une heure.
Questions fréquentes
Combien de fonctionnalités pour un MVP ?
Assez pour qu'un parcours soit terminé par chaque rôle concerné, pas plus. Une fonctionnalité qui ne sert ni ce parcours ni une obligation légale appartient à une version ultérieure.
Faut-il d'abord un design system ?
Pas un système complet. Fixez la mise en page, les schémas de formulaire et les états de composants du premier parcours, puis étendez-le avec le produit.
Et après la mise en ligne du MVP ?
Préparez la reprise en même temps que le périmètre : qui exploite, qui corrige, comment les données sont sauvegardées et comment la suite est priorisée. Les conditions de support se conviennent mieux avant le lancement.
Que se passe-t-il ensuite ?
- Examiner les objectifs, les utilisateurs et les fonctions essentielles.
- Confirmer les livrables, l’estimation en dollars américains et les principales étapes.
- Convenir des responsabilités et des critères de validation avant de commencer.