Un MVP SaaS en trois semaines : ce qu'on y met, ce qu'on laisse

Vous avez une idée de logiciel en ligne : un outil pour votre secteur, un service que vos clients paieraient au mois. La tentation est de tout construire avant de lancer : toutes les fonctions, tous les cas, tous les réglages. C'est la meilleure façon de passer un an à développer un produit dont personne ne veut tel quel. Un MVP, pour « produit minimum viable », c'est l'inverse : la plus petite version qui permet de vérifier, avec de vrais utilisateurs, que l'idée tient. Trois semaines, c'est court. C'est justement l'intérêt : ça oblige à choisir. Voici comment nous faisons le tri.

Ce qu'un MVP doit prouver

Avant de lister des fonctions, il faut savoir ce qu'on cherche à apprendre. Un MVP répond à une question précise, par exemple :

• des artisans sont-ils prêts à envoyer leurs devis depuis cet outil plutôt que depuis leur tableur ?
• des cabinets vont-ils déposer leurs documents dans cet espace partagé avec leurs clients ?
• des responsables de site vont-ils remplir ce formulaire d'inspection sur tablette chaque semaine ?

Si la première version ne permet pas de répondre à cette question, elle n'est pas viable. Si elle contient beaucoup plus que nécessaire pour y répondre, elle n'est pas minimum.

Ce qu'on y met

Le parcours principal, de bout en bout

Le cœur du MVP, c'est le parcours qui apporte la valeur, complet du début à la fin. Pour un outil de devis : créer un client, composer un devis, l'envoyer, savoir s'il a été accepté. Pas de demi-parcours : un utilisateur qui ne peut pas aller jusqu'au bout ne peut pas vous dire si l'outil lui sert.

Des comptes et des accès propres

Inscription, connexion, mot de passe oublié, séparation des données entre clients. Ce n'est pas la partie la plus visible, mais c'est non négociable dès le premier utilisateur externe. Les données d'un client ne doivent jamais apparaître chez un autre.

Une interface simple mais soignée

Peu d'écrans, mais des écrans clairs. Un MVP peut être limité ; il ne doit pas être confus. Les premiers utilisateurs pardonnent un manque de fonctions, pas une interface incompréhensible.

De quoi mesurer

Savoir qui utilise quoi, combien de fois, et où les gens abandonnent. Sans mesure, le MVP ne vous apprend rien.

Un moyen de recueillir les retours

Un bouton, une adresse, un échange régulier avec les premiers utilisateurs. Ce sont eux qui vont écrire la suite de la feuille de route.

Ce qu'on laisse pour plus tard

• Les réglages avancés : personnalisations, modèles multiples, options pour chaque cas particulier.
• Les intégrations secondaires : connexion à tel logiciel comptable, à tel outil de messagerie. Une seule intégration, si elle est indispensable au parcours principal ; les autres attendront qu'on sache lesquelles sont demandées.
• Les tableaux de bord élaborés : quelques chiffres suffisent au début.
• L'application mobile, sauf si l'usage est par nature mobile. Une application web bien adaptée aux téléphones suffit souvent pour tester.
• L'automatisation de tout ce qui est rare : le premier mois, certaines opérations peuvent être faites à la main par vous, en coulisses.

Ce dernier point surprend souvent. Pourtant, faire à la main ce qui arrive deux fois par mois, le temps de vérifier que le produit intéresse, est une excellente façon de ne développer que ce qui sert.

Ce qu'on ne sacrifie jamais

Aller vite ne veut pas dire bâcler. Certaines choses sont là dès la première version :

• la sécurité des comptes et la séparation des données ;
• des sauvegardes ;
• un code propre, sur des technologies pérennes, qui servira de base à la suite plutôt que d'être jeté ;
• un hébergement fiable, en France.

Un MVP n'est pas un prototype jetable. C'est la première brique du produit. On commence là où la ressaisie ou l'attente coûte le plus, et on ajoute le reste ensuite, lot par lot, à partir de ce que les premiers utilisateurs font vraiment de l'outil.

Comment nous découpons le travail

Notre méthode s'y prête naturellement. La conception commence par des maquettes cliquables : c'est là qu'on fait le tri, écran par écran, entre ce qui entre dans la première version et ce qui attend. Le prix est fixé à ce moment-là, avant de coder. Ensuite, le développement avance par versions testables toutes les deux semaines, ce qui permet de mettre très tôt le produit entre les mains de quelques utilisateurs. Les durées et les prix « à partir de » de nos plateformes SaaS sont affichés sur la page Tarifs.

Les questions à vous poser

1. Quelle question précise votre première version doit-elle trancher ?
2. Quel est le parcours, et un seul, qui apporte la valeur ?
3. Avez-vous cinq à dix utilisateurs prêts à l'essayer dès la sortie ?
4. Qu'êtes-vous prêt à faire à la main pendant les premières semaines ?
5. Qu'est-ce qui vous ferait dire, dans trois mois, que l'idée tient, ou qu'elle ne tient pas ?

Si vous avez une idée de SaaS et que vous voulez savoir ce que serait sa première version, venez en parler lors d'un rendez-vous de 30 minutes, gratuit, en visio ou au studio à Nevers.