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.
Ce que je ne prends pas
- 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 SaaS complet en trois semaines. 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.
- 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.
Questions fréquentes
Combien coûte le développement d'un SaaS ?
Le coût dépend presque entièrement du périmètre de la version 1. Le socle technique — authentification, abonnements, back-office, isolation des données — représente une part fixe importante, quelle que soit votre idée. Vous recevez un prix ferme après un appel de cadrage gratuit.
Combien de temps pour livrer un MVP SaaS ?
6 à 12 semaines selon le périmètre. La fourchette dépend du nombre de rôles utilisateurs, de la complexité du modèle d'abonnement et des intégrations tierces à brancher.
Faut-il partir en multi-tenant dès le départ ?
Si vous vendez à des entreprises dont les données doivent être isolées, oui : c'est un choix d'architecture qui se rattrape très mal après la mise en production. Pour un produit vendu à des particuliers, c'est souvent inutile. On tranche au cadrage selon votre modèle de vente.
Vous branchez les paiements ?
Oui, via Stripe : offres, essais gratuits, changements de formule, échecs de paiement, factures et relances. C'est une des parties les plus sous-estimées d'un SaaS — les cas limites de facturation sont nombreux et ils touchent directement au revenu.
Le RGPD est-il pris en compte ?
Oui, pendant le développement et non après. Consentement, durées de conservation, droit d'accès et d'effacement, registre des sous-traitants, localisation des données : ces points sont traités dans la conception, parce que les rattraper implique de reprendre le modèle de données.