Un MVP, pas une version dégradée
Un MVP n'est pas un produit inachevé : c'est le plus petit périmètre qui permet de vérifier que des gens paient pour ce que vous proposez. La différence est entière. Une version dégradée coupe dans la qualité et donne un signal faux, parce que les utilisateurs partent pour des raisons qui n'ont rien à voir avec votre idée. Un MVP coupe dans le périmètre, et fait très bien ce qu'il fait.
Concrètement, cela veut dire arbitrer tôt et sans regret : quelles fonctionnalités partent en version 1, lesquelles attendent d'avoir des utilisateurs pour être décidées. C'est le travail du cadrage, et c'est ce qui détermine si le produit sort en huit semaines ou en huit mois.
Ce que tout SaaS demande, et qui prend du temps
La partie visible d'un SaaS, les écrans qui portent votre valeur, n'est jamais la plus longue à construire. Le socle l'est :
- l'authentification et la gestion des comptes, avec invitations, rôles et droits ;
- les abonnements : offres, essais gratuits, changements de formule, échecs de paiement, factures ;
- l'isolation des données entre clients (multi-tenant), qui se décide à la conception et se rattrape très mal ;
- un back-office d'administration, sans lequel chaque demande client devient une requête en base ;
- les tableaux de bord et les exports que vos utilisateurs réclameront dès le premier mois ;
- la conformité RGPD : consentement, durées de conservation, droit à l'effacement, sous-traitants ;
- l'observabilité, pour savoir qu'un paiement a échoué avant que le client ne l'écrive.
Les décisions qui coûtent cher si on les prend trop tard
Trois choix structurent un SaaS et se réécrivent difficilement : le modèle d'isolation des données entre clients, la modélisation des offres et des droits, et le découpage de la base de données. Les trois sont pris pendant le cadrage, pas au fil du développement.
Cela ne veut pas dire tout prévoir. Cela veut dire distinguer ce qui est réversible : l'apparence, les parcours, la plupart des fonctionnalités : de ce qui ne l'est pas, et mettre le temps de réflexion sur le second.
Piloter le produit après le lancement
Un SaaS livré est un produit qui commence. Les chiffres qui comptent : revenu récurrent mensuel, taux d'attrition, coût d'acquisition, revenu net conservé, doivent être mesurables depuis l'intérieur du produit, pas reconstitués à la main dans un tableur chaque mois.
L'instrumentation fait donc partie du périmètre : ce qui est suivi, où on le lit, et quelles alertes se déclenchent. C'est ce qui fait la différence entre subir l'attrition et la voir venir.
Quand une autre solution sera plus adaptée
- Les projets sans interlocuteur décisionnaire. Un SaaS demande des dizaines d'arbitrages de périmètre ; sans quelqu'un pour trancher, aucun planning ne tient.
- Un délai compatible avec le socle. Le socle décrit plus haut ne se compresse pas. Si le délai est la contrainte dure, on réduit le périmètre de la version 1 avant de démarrer.
- La reprise d'un SaaS existant sans audit. Sur du code en production que je n'ai pas écrit, un audit précède tout engagement.
- La recherche de financement ou le pitch investisseurs. Je construis le produit ; la levée n'est pas mon métier.
