MVP SaaS : comment lancer une première version utilisable en 90 jours

Le MVP SaaS (produit minimum viable) est la première version de votre logiciel qui peut être utilisée, et payée, par de vrais clients. Pas une maquette, pas une démonstration commerciale : un outil qui rend un service complet sur un périmètre réduit. Lancer un MVP en 90 jours est réaliste pour la plupart des projets, à condition de prendre les bonnes décisions dans les deux premières semaines. Voici la méthode que nous suivons, étape par étape.

Ce qu'un MVP est, et ce qu'il n'est pas

• Ce n'est pas un prototype cliquable : un prototype teste une idée, un MVP rend un service.
• Ce n'est pas une version bâclée : les fondations (comptes, données, paiement, sécurité) doivent être solides, sinon vous reconstruirez tout.
• Ce n'est pas la moitié du produit final : c'est un parcours complet, de bout en bout, sur un seul cas d'usage.
• C'est un outil d'apprentissage : il sert à découvrir ce que les clients utilisent vraiment, avant d'investir davantage.

Semaines 1 et 2 : cadrer sans pitié

Choisir un seul parcours clé

Listez tout ce que votre produit pourrait faire, puis isolez le parcours qui apporte le plus de valeur à un client précis. Formulez-le en une phrase : « Un gérant de salle de sport crée un abonnement, encaisse et suit les présences ». Tout ce qui n'est pas nécessaire à cette phrase sort du MVP. Les demandes « ce serait bien d'avoir » vont dans une liste pour plus tard.

Dessiner les écrans

Cinq à dix écrans suffisent souvent. Des maquettes simples, validées avec deux ou trois futurs utilisateurs, évitent les allers-retours coûteux en développement. C'est aussi le moment de fixer les règles métier : statuts, calculs, cas d'erreur.

Fixer les critères de succès

Comment saurez-vous que le MVP fonctionne ? Par exemple : cinq clients pilotes l'utilisent chaque semaine pendant un mois, et trois acceptent de payer. Des critères écrits évitent de prolonger indéfiniment la phase de « encore une fonctionnalité ».

Semaines 3 à 5 : poser les fondations

Avant les fonctionnalités visibles, l'équipe met en place les briques que tout le produit réutilisera :

• Comptes, connexion et invitations d'équipe, avec des rôles simples (administrateur, utilisateur).
• Isolation des données entre clients (multi-tenant) dès le modèle de données.
• Facturation : plans, essai gratuit, paiement récurrent ou manuel selon le marché.
• Déploiement automatisé, environnement de test, sauvegardes et suivi des erreurs.
• Design system : les composants d'interface qui rendront chaque nouvel écran rapide à construire.

Semaines 6 à 11 : développer par cycles de deux semaines

Chaque cycle livre une version testable. Vous l'essayez, vos clients pilotes aussi, et le cycle suivant intègre les retours. Trois cycles suffisent en général pour couvrir le parcours clé : création, usage quotidien, facturation. L'ordre compte : commencez par le cœur du parcours, terminez par les écrans de confort (statistiques, exports, préférences).

Pendant cette phase, résistez à deux tentations : ajouter des fonctionnalités hors périmètre parce qu'un pilote les a demandées, et repousser les tests sur de vraies données. Les pilotes qui saisissent leurs vrais dossiers révèlent les cas particuliers qu'aucune maquette ne montre.

Semaine 12 : lancer auprès des pilotes

1. Vérifiez sécurité, sauvegardes, performances et parcours de paiement sur l'environnement de production.
2. Préparez une page d'accueil claire, un guide de démarrage et un canal de support (email ou WhatsApp).
3. Onboardez les pilotes vous-même, par visio ou sur place : vous apprendrez plus en une heure d'observation qu'en un mois de statistiques.
4. Fixez un rendez-vous de retour avec chaque pilote après deux semaines d'usage.

Après le lancement : mesurer et décider

Un MVP ne sert à rien sans mesure. Suivez l'activation (combien de comptes créés réalisent le parcours clé), la rétention (reviennent-ils la semaine suivante ?) et la conversion (combien paient à la fin de l'essai). Ces chiffres, même sur dix clients, guident la version suivante bien mieux que des opinions. C'est à ce moment que se décide le passage à l'échelle : nouvelles fonctionnalités, nouveaux segments, ou pivot.

Les pièges classiques du MVP

• Le périmètre qui enfle : chaque semaine d'ajout retarde le premier retour client.
• Les fondations sacrifiées pour aller vite, puis une réécriture complète à vingt clients.
• Le lancement repoussé par perfectionnisme : un MVP doit être propre, pas parfait.
• L'absence de pilotes engagés : sans utilisateurs réels, le MVP ne mesure rien.
• Pas de budget après le lancement : la version 2 est celle qui transforme les pilotes en clients.

Exemple : un MVP pour la gestion d'une école privée

Prenons un cas type. Une école privée gère inscriptions, scolarité, emplois du temps, absences, communication aux parents et paiements, le tout sur tableur et par messages. Le produit final pourrait tout couvrir ; le MVP, lui, choisit un seul parcours : « inscrire un élève, émettre les échéances de scolarité, suivre les paiements et relancer les parents ». Pourquoi celui-là ? Parce que c'est celui qui coûte le plus de temps à l'administration et qui touche directement la trésorerie de l'école.

• Écrans du MVP : liste des élèves, fiche élève avec responsables, échéancier, enregistrement d'un paiement, relances (email ou WhatsApp), tableau de bord des impayés, paramètres de l'école, facturation de l'abonnement.
• Hors MVP : emplois du temps, notes, absences, application mobile parents, bibliothèque, cantine. Ils viendront ensuite, une fois le parcours de base adopté.
• Fondations : comptes et rôles (direction, comptabilité), isolation des données par école, génération de reçus conformes, sauvegardes, déploiement automatisé.
• Critère de succès : trois écoles pilotes enregistrent toutes leurs échéances du trimestre dans l'outil et déclarent gagner du temps sur les relances.

La semaine type pendant le développement

Un MVP livré en 90 jours repose sur une organisation simple et régulière. Chaque semaine : un point de 30 minutes avec le fondateur pour valider les écrans livrés et trancher les questions ouvertes ; un environnement de test mis à jour en continu où chacun peut essayer les nouveautés ; une liste de décisions écrite, pour que les règles métier ne vivent pas seulement dans les conversations ; et, toutes les deux semaines, une démonstration de la version et la planification du cycle suivant. Les pilotes sont invités à partir du deuxième cycle, dès que le parcours clé tient debout.

Checklist avant d'ouvrir aux pilotes

1. Le parcours clé fonctionne de bout en bout, sans intervention manuelle de l'équipe technique.
2. Chaque client ne voit que ses données, et des tests automatiques le vérifient.
3. L'inscription, la connexion, la réinitialisation du mot de passe et l'invitation d'un collègue fonctionnent.
4. Les emails transactionnels arrivent (confirmations, rappels, factures) et ne tombent pas en spam.
5. Le paiement ou la facturation de l'abonnement est testé en conditions réelles.
6. Les sauvegardes automatiques tournent et une restauration a été testée.
7. Les erreurs en production remontent dans un outil de suivi avec alerte.
8. Les pages publiques (accueil, tarifs, contact) sont en ligne et référençables.
9. Les mentions légales, la politique de confidentialité et les conditions d'utilisation sont publiées.
10. Un guide de démarrage et un canal de support sont prêts.
11. Les données d'exemple permettent de découvrir le produit sans saisie fastidieuse.
12. Un rendez-vous de retour est planifié avec chaque pilote.

Lancer votre MVP avec Web Dimensions

Notre offre de développement SaaS suit exactement cette méthode : cadrage et maquettes, fondations, cycles de deux semaines avec versions testables, lancement et accompagnement. Pour estimer le budget, lisez aussi combien coûte le développement d'un SaaS, puis parlez-nous de votre projet.