Un MVP a un seul but : vérifier que quelqu'un est prêt à payer. Tout ce qui ne sert pas cette vérification est du temps perdu. Mais entre « aller vite » et « construire n'importe comment », il y a une frontière, et elle se situe à des endroits précis.
Ce qu'on peut légitimement bâcler
Au démarrage, ces raccourcis sont sains :
- Le back-office. Une interface d'administration moche fait très bien l'affaire pendant un an. Personne d'externe ne la voit.
- L'automatisation des cas rares. Si trois clients par mois ont besoin d'un traitement particulier, faites-le à la main. Automatiser trop tôt fige une règle métier qui va changer.
- La montée en charge. Un serveur unique tient des milliers d'utilisateurs. Concevoir pour un million alors qu'on en a zéro est la forme la plus coûteuse de procrastination.
- Le design système complet. Cinq composants bien faits suffisent au début.
Les trois décisions qu'on ne rattrape pas
En revanche, trois choix structurent tout le reste. Les reporter coûte une réécriture.
1. Le modèle de données
C'est le point de non-retour. Si vous démarrez avec un utilisateur qui appartient à une seule organisation, et que six mois plus tard un client veut gérer trois filiales, la migration touche chaque requête de l'application.
Posez la question au premier jour : qui possède une donnée ? Un utilisateur, une équipe, une organisation ? Même si vous ne vendez qu'à des indépendants au départ, un identifiant d'organisation présent dès le début ne coûte presque rien et évite le pire.
2. L'authentification et les permissions
Ajouter des rôles après coup signifie relire chaque contrôleur pour se demander « qui a le droit de faire ça ? ». Une couche d'autorisation même minimale (deux rôles suffisent) installe le réflexe et l'endroit où l'écrire.
3. Les tests sur le chemin critique
Pas une couverture de 100 %, ce serait absurde à ce stade. Mais l'inscription, le paiement et l'action principale du produit doivent être couverts. Ce sont les trois parcours dont la panne vous coûte des clients, et ce sont ceux que vous modifierez le plus souvent.
Le moment charnière
Le passage du MVP au produit se joue rarement sur la technique. Il se joue quand le support commence à prendre plus de temps que le développement.
Les signaux à surveiller :
- vous répondez plusieurs fois par semaine à la même question ;
- vous corrigez des données à la main en base ;
- une nouvelle fonctionnalité casse systématiquement quelque chose d'ancien.
Le premier signal appelle de la documentation ou un changement d'interface. Le deuxième, un outil d'administration. Le troisième, des tests, et c'est le plus urgent, parce qu'il ralentit tout le reste.
En pratique
Un MVP honnête se construit en six à dix semaines. Le produit qui suit se construit en continu, par incréments courts, avec des utilisateurs qui voient chaque livraison.
Ce qui distingue les projets qui tiennent, ce n'est presque jamais la sophistication technique du départ. C'est d'avoir eu, dès le début, un modèle de données qui reflète honnêtement le métier.
