« Construisez juste un MVP. »
C'est devenu le conseil par défaut pour quiconque construit du logiciel. Lancez vite, apprenez des utilisateurs, itérez. Le playbook lean startup. Et c'est un bon conseil — parfois. D'autres fois, c'est le moyen le plus rapide de gaspiller de l'argent et de la crédibilité.
L'approche MVP fonctionne dans des conditions spécifiques. En dehors de ces conditions, elle se retourne contre vous. Voici comment on aborde la décision.
Ce qu'est réellement un MVP
Un MVP — Minimum Viable Product — est la version la plus réduite de votre logiciel qui délivre assez de valeur pour que de vrais utilisateurs l'adoptent. Ce n'est pas un prototype. Ce n'est pas une démo. Ce n'est pas une version cassée du produit complet. C'est un produit complet avec un périmètre étroit.
Le « minimum » concerne les fonctionnalités, pas la qualité. Un MVP devrait être bien conçu, bien construit, et fiable. Il fait juste moins de choses.
Quand lancer petit fonctionne
Vous testez une hypothèse de marché. Vous pensez qu'il y a une demande, mais vous n'êtes pas sûr. Un MVP permet de valider l'idée avec de vrais utilisateurs avant d'engager le budget complet.
Votre budget est limité et phasé. Vous avez assez pour le cœur mais pas pour la vision complète. Un MVP met quelque chose en production qui commence à délivrer de la valeur.
Le feedback utilisateur va changer le produit. Vous vous attendez à ce que les besoins réels diffèrent de vos hypothèses. Un MVP vous donne des données réelles.
La vitesse de mise en marché compte. Un concurrent avance, une fenêtre réglementaire se ferme, ou une opportunité saisonnière existe.
Quand lancer petit se retourne contre vous
Vos utilisateurs sont des entreprises. Si vous vendez à des corporations ou des administrations, elles ne testeront pas un produit incomplet. Elles attendent une solution complète. Un MVP auquel il manque des fonctionnalités essentielles sera rejeté — et vous n'aurez pas de seconde chance.
La valeur nécessite un workflow complet. Certains produits ne délivrent de la valeur que quand le workflow entier est couvert. Si couper des fonctionnalités casse le cas d'usage principal, vous ne pouvez pas contourner ça avec un MVP.
La confiance est la barrière principale. Si votre produit gère de l'argent, des données de santé, ou des documents juridiques, un produit visiblement incomplet détruit la confiance avant que vous puissiez la construire.
Vous savez déjà quoi construire. Si vous avez fait une recherche client approfondie et validé les wireframes, un MVP ajoute un délai dont vous n'avez pas besoin. Vous n'êtes pas en train de tester une hypothèse — vous exécutez un plan.
Le terrain du milieu : la livraison par phases
La plupart de nos projets ne tombent pas nettement dans « MVP » ou « produit complet ». Ils tombent dans la livraison par phases — qui prend le meilleur des deux approches.
La Phase 1 est un produit complet et soigné avec un périmètre défini. Elle couvre le workflow principal de bout en bout. Mais elle reporte délibérément les fonctionnalités « nice to have » en Phase 2.
On a écrit sur comment fonctionne notre processus de livraison — la livraison par phases en fait partie intégrante.
Comment décider ce qui va en Phase 1
Commencez par le workflow principal. Quelle est la chose la plus importante que l'utilisateur doit faire ? Construisez-la de bout en bout, sans lacunes.
Coupez des fonctionnalités, pas la qualité. La Phase 1 devrait avoir moins de fonctionnalités, pas de pires fonctionnalités. Un produit soigné avec 5 fonctionnalités bat un produit bâclé avec 15.
Reportez ce qui peut être fait manuellement. Si une fonctionnalité peut être gérée avec un export tableur ou un email manuel pendant les 3 premiers mois, reportez-la.
Incluez ce qui bloque l'adoption. Si une fonctionnalité manquante empêchera les utilisateurs d'utiliser le produit du tout, elle doit être en Phase 1.
La différence de coût
Un MVP ou une Phase 1 coûte typiquement 40-60 % du produit complet. Pas 10 %, pas 20 % — le workflow principal nécessite quand même une architecture correcte, du design, des tests et du déploiement.
Si quelqu'un vous propose un MVP à 10 % du coût du produit complet, il coupe sur la qualité ou n'a pas compris le périmètre. Dans les deux cas, vous paierez la différence plus tard.
On a couvert combien de temps prennent les projets et comment fonctionnent les modèles de tarification. La décision MVP affecte directement le calendrier et le budget.
Ce que ça signifie pour vous
« Construisez juste un MVP » n'est pas toujours un bon conseil. « Construisez tout avant de lancer » non plus. La bonne réponse dépend de votre marché, vos utilisateurs, votre budget et votre confiance dans les besoins.
On a rassemblé un ensemble complet de ressources : comment écrire un brief, quand construire vs. acheter, quoi demander à votre agence, et ce qui se passe après le lancement. La décision MVP est une pièce — mais elle façonne tout ce qui suit.
Vous planifiez un produit et ne savez pas où tracer la ligne de la Phase 1 ? On le détermine ensemble →