Le « produit minimum viable » est l’une des idées les plus citées et les moins appliquées du logiciel. En pratique, les MVP échouent de deux façons. Soit ils sont si minimaux qu’ils ne prouvent rien, soit ils deviennent discrètement une version 1.0 chargée d’un an de fonctionnalités que personne n’a encore demandées. Dans les deux cas, on gaspille la seule ressource qu’un jeune produit ne peut pas remplacer : le temps d’apprendre.
Voici la méthode que nous utilisons avec des fondateurs et des équipes produit pour cadrer une première version petite, livrable, et qui répond quand même à une vraie question.
Nommer l’hypothèse testée
Un MVP est une expérience, et une expérience a besoin d’une hypothèse. Avant toute liste de fonctionnalités, écrivez l’hypothèse la plus risquée derrière le produit. C’est généralement l’une de celles-ci :
- La demande : les personnes visées ont ce problème suffisamment fort pour changer leur façon de travailler.
- La valeur : notre solution est nettement meilleure que ce qu’elles font aujourd’hui, y compris ne rien faire.
- La disposition à payer : elles, ou leur entreprise, paieront un prix qui rend le modèle viable.
- La faisabilité : nous savons réellement livrer le résultat, par exemple avec une précision d’IA acceptable ou des données auxquelles nous avons légalement accès.
Choisissez celle qui tuerait le produit si elle se révélait fausse, et cadrez le MVP pour la tester. Un produit dont le plus grand risque est la disposition à payer a besoin d’un paiement et d’une page de tarifs dès sa première version. Un produit dont le plus grand risque est la faisabilité n’a parfois besoin d’aucune interface, seulement d’un pipeline qui prouve que le résultat est assez bon.
Tracer le parcours qui doit fonctionner
Décrivez ensuite le parcours unique qu’un utilisateur doit pouvoir accomplir pour que le test ait un sens. Pas tout le produit : un chemin, du premier contact au moment où il obtient de la valeur.
Pour un outil B2B de planning, cela peut être : un manager crée un compte, importe son équipe, publie un planning, et les employés voient leurs créneaux sur leur téléphone. Tout ce qui se trouve sur ce chemin doit fonctionner correctement. Tout le reste peut attendre.
Écrire ce parcours comme une courte histoire, écran par écran, est aussi le moyen le plus rapide de découvrir que deux personnes de l’équipe avaient deux produits différents en tête.
Décider de ce qu’on simule
Une part étonnante d’un produit naissant peut se faire à la main ou avec des outils existants, tant que l’utilisateur ne le vit pas comme un dysfonctionnement :
- un onboarding mené par une personne en visio plutôt qu’un assistant en libre-service ;
- des rapports envoyés en tableur ou en PDF plutôt qu’un tableau de bord analytique ;
- une facturation par facture ou lien de paiement plutôt qu’un système d’abonnement complet ;
- un back-office construit sur un outil existant plutôt que développé sur mesure ;
- des intégrations par export programmé plutôt qu’une API temps réel.
Chacun de ces choix fait gagner des semaines. Chacun apprend aussi quelque chose : si les clients réclament sans cesse la version en libre-service, vous savez quoi construire ensuite.
Ce qu’on ne sacrifie jamais
Être minimal sur le périmètre n’est pas être négligent sur les fondations. Certaines choses coûtent cher à ajouter plus tard et peu à bien faire dès le départ :
- L’authentification et les droits, confiés à un fournisseur éprouvé plutôt qu’à un login maison.
- Un modèle de données fidèle au métier, surtout pour les comptes, organisations et rôles. Le multi-tenant se rajoute très douloureusement après coup.
- Une hygiène de base en sécurité et confidentialité : connexions chiffrées, secrets hors du code, données personnelles traitées en pensant au RGPD.
- De l’analytique sur le parcours, pour voir où les gens décrochent. Sans elle, l’expérience n’a pas de résultat.
- Un déploiement automatisé, pour qu’une correction parte en quelques minutes et que personne n’ait peur de livrer.
- Les bases de l’accessibilité et de la performance, peu coûteuses dans un code neuf et très coûteuses dans un vieux code.
Choisir une technologie ennuyeuse
Un MVP n’est pas l’endroit pour essayer trois nouveaux frameworks. Choisissez une stack que l’équipe maîtrise et qui restera un choix sensé si le produit réussit : pour beaucoup de SaaS, TypeScript avec React ou Next.js, une base PostgreSQL managée et un cloud grand public. Le but est qu’un MVP réussi devienne la fondation du produit, et non un prototype à jeter sous la pression.
Fixer le délai avant le périmètre
Fixez d’abord le temps, puis faites-y tenir le périmètre. Quelques semaines jusqu’aux premiers vrais utilisateurs est un objectif sain pour la plupart des MVP B2B. Si le parcours tracé ne tient pas, coupez le long du parcours, pas en travers : simplifiez des étapes, simulez davantage, restreignez la cible. Ne livrez pas la moitié de chaque fonctionnalité.
Convenez à l’avance de ce qui comptera comme un succès, comme un échec, et de ce que vous ferez dans chaque cas. Le lancement devient alors une décision, pas une impression.
Après le lancement : apprendre, puis construire
Le résultat le plus précieux d’un MVP n’est pas le code, mais ce que vous apprenez pendant les premières semaines d’usage. Parlez à tous les premiers utilisateurs possibles. Suivez l’analytique du parcours. Tenez une courte liste de ce que les gens demandent et à quelle fréquence. Puis planifiez la version deux à partir de ces faits.
Si vous préparez un nouveau produit, notre équipe SaaS et MVP peut mener avec vous un court cadrage, définir le parcours et l’expérience, puis construire la première version avec les fondations décrites ci-dessus. Nos designers UX et UI prototypent le parcours avant la première ligne de code. Parlez-nous de votre idée.