La réponse courte
Un MVP (produit minimum viable) est le test le moins cher possible d’une idée de logiciel. Son but n’est pas de construire un produit, mais de répondre à deux questions avec des faits : des gens s’en servent-ils vraiment, et paieraient-ils ? Pour y répondre, un logiciel complet n’est presque jamais nécessaire. Un tableur partagé, un formulaire relié à quelques automatisations, ou même un service rendu à la main en coulisse suffisent souvent.
C’est ce qui distingue cette page de celle sur le SaaS sur mesure : le SaaS est la version solide, avec comptes séparés, paiement et sécurité, que l’on construit une fois la demande prouvée. Le MVP sert à savoir s’il faut la construire.
Pour qui, et pour qui ce n’est pas
Beaucoup d’idées de logiciel naissent dans un métier. Un artisan a perfectionné un tableur de chiffrage que ses confrères lui envient. Un commerçant a bricolé un système de réservation qui marche mieux que ceux du marché. Une PME a un outil interne que ses partenaires demandent à utiliser.
La démarche MVP convient si :
- vous connaissez le problème de l’intérieur ;
- vous pouvez joindre quelques futurs utilisateurs prêts à tester et à vous dire la vérité ;
- vous acceptez qu’une première version soit incomplète, voire en partie faite à la main ;
- vous voulez décider sur des faits avant d’investir dans un développement.
Ce n’est pas la bonne démarche si :
- vous avez déjà des clients qui ont signé pour un besoin précis : c’est alors un projet de logiciel sur mesure ;
- l’idée n’a jamais été confrontée à une seule personne extérieure. Commencez par une dizaine de conversations avec des clients potentiels : c’est gratuit et souvent décisif ;
- personne ne peut s’occuper des premiers utilisateurs : un test sans retours ne prouve rien.
Quatre façons de tester, de la moins chère à la plus chère
| Forme de test | Ce qu’on construit | Ce qu’elle prouve | Sa limite |
|---|---|---|---|
| Page de précommande | Une page qui décrit l’outil et propose de réserver ou de s’inscrire, éventuellement en payant | Que l’offre intéresse, et à quel prix | Ne prouve pas que l’outil sera utilisé |
| Service fait à la main | Le client reçoit le résultat ; derrière, quelqu’un le prépare à la main | Que le résultat a de la valeur et revient chaque semaine | Ne tient pas au-delà de quelques clients |
| Assemblage sans code | Formulaire, base de données en ligne, scénario d’automatisation (n8n, Make), courriels automatiques | Que le parcours fonctionne et que les utilisateurs reviennent | Fragile si le nombre d’utilisateurs grandit beaucoup |
| Logiciel réduit | Une seule fonction, codée proprement, avec comptes séparés | Que le produit tient techniquement et commercialement | Le plus cher et le plus long des quatre |
La plupart des idées devraient passer par l’une des trois premières avant la quatrième. Les outils d’automatisation sont présentés sur les pages n8n et automatisation ; si l’idée part d’un tableur, voir aussi remplacer Excel.
Le service fait à la main surprend souvent. Pourtant, si personne ne veut d’un résultat préparé à la main, personne n’en voudra quand il sera automatique. Et si la demande est là, on sait exactement quoi automatiser.
Fixer d’avance les critères pour arrêter ou continuer
C’est l’étape qui fait la différence entre un test et un projet qui traîne. Avant de lancer, écrivez sur une page :
- La phrase du problème : qui a ce problème, et qu’est-ce que votre outil change pour lui. Si la phrase ne tient pas, l’outil non plus.
- Le comportement attendu : par exemple, « au moins la moitié des testeurs s’en servent encore la troisième semaine ». L’inscription ne compte pas, l’usage répété oui.
- Le signal de paiement : une précommande, un abonnement payé, un engagement écrit. Un « ce serait génial » ne compte pas.
- La date de décision : six ou huit semaines plus tard, par exemple, notée dans l’agenda.
Ces seuils sont des exemples, à adapter à votre marché. Ce qui compte, c’est de les écrire avant de voir les résultats. À la date prévue, trois décisions possibles :
- continuer : les seuils sont atteints, on construit la version suivante, et à terme le SaaS sur mesure ;
- changer de cap : l’usage est là mais pas sur la fonction imaginée, ou pas pour le public visé. On relance un test court sur le nouvel angle ;
- arrêter : les seuils sont loin. C’est un bon résultat, qui a coûté un test au lieu d’un développement complet.
Ce que nous pouvons faire
- Aider à couper. Lister toutes les idées, puis ne garder que ce qui sert à répondre aux deux questions du test.
- Assembler le test sans code : formulaires, base de données en ligne, automatisations, courriels, tableau de suivi de l’usage.
- Brancher l’IA quand elle porte la valeur : lire un document, rédiger un brouillon, classer des demandes. Elle se teste sur de vrais dossiers dès le départ, parce que c’est là qu’on découvre ses erreurs. Voir intégration de l’IA.
- Mesurer : comptes actifs chaque semaine, fonctions utilisées, demandes de support.
- Préparer la suite : quand le test est concluant, écrire le cahier des charges de la version solide à partir de ce que les utilisateurs ont vraiment fait.
Les limites et les obligations
- Un MVP ne garantit pas le succès. Il dit vite si l’idée prend. Trouver des clients reste votre travail ; nous ne faisons pas de marketing.
- Le RGPD s’applique dès le premier testeur si vous collectez des données personnelles, même dans un tableur. Limitez les données au strict nécessaire, informez les testeurs, choisissez des outils dont vous connaissez l’hébergement. Le guide de sécurité de la CNIL sert de liste de contrôle ; si l’outil utilise de l’IA, voir RGPD et IA.
- Les outils sans code ont des abonnements, parfois facturés à l’usage. Vérifiez leur tarif public au moment du test, et ce qui se passe si le nombre d’utilisateurs augmente.
- La propriété compte dès le début. L’article L113-9 du Code de la propriété intellectuelle attribue à l’employeur les droits sur les logiciels créés par ses salariés ; un prestataire extérieur n’en est pas un. Si une partie est codée, prévoyez une cession écrite des droits, et ouvrez tous les comptes (outils, hébergement, nom de domaine) au nom de votre entreprise.
Comment le prix est établi
Nous n’affichons pas de tarif. Le coût d’un MVP dépend surtout de la forme de test choisie : une page de précommande ou un assemblage sans code coûtent une fraction d’un logiciel réduit. Ce qui fait le budget d’un développement, quand vient le moment, est expliqué sur combien coûte un logiciel sur mesure. Pour commencer, décrivez-nous votre idée en quelques lignes : nous vous proposerons la forme de test la moins chère qui réponde à votre question.
