Un MVP (Minimum Viable Product), ce n’est ni une version bâclée à vendre au public, ni un PowerPoint. C’est le plus petit livrable qui permet de vérifier une hypothèse business : quelqu’un utilise le produit de façon répétée, et idéalement paie (ou s’engage à payer).
En B2B, la tentation est toujours la même : trois promesses sur la landing, cinq rôles utilisateurs, facturation multi-devises — avant d’avoir dix utilisateurs actifs. Ce guide recentre sur une promesse, un flux, une mesure.
Une seule promesse sur la page d’accueil
Si votre hero dit trois choses en même temps, vous n’avez pas encore de MVP — vous avez une roadmap affichée comme si c’était déjà livré.
Exemples de promesses uniques (une seule par produit) :
| Promesse | Ce que le MVP fait vraiment |
|---|---|
| « Relances factures automatiques » | Connexion factures + règles d’envoi + suivi ouvert/clic |
| « Un fil par client pour le support » | Boîte partagée + statuts + historique |
| « Voir l’avancement du dossier » | Portail client + 3 statuts + notifications email |
Tout le reste (reporting avancé, SSO entreprise, API publique) peut attendre après la première dizaine de comptes qui reviennent chaque semaine.
Les cinq questions avant la première ligne de code (ou le premier écran no-code)
- Qui paie — et à combien — si le problème est vraiment résolu ?
- Quelle action l’utilisateur fait-il au moins une fois par semaine sans qu’on le force ?
- Qu’est-ce que vous coupez si le délai double ? (Sinon le scope gonfle indéfiniment.)
- Comment vous recrutez les 5–10 premiers testeurs ? (Réseau, partenaire, un seul vertical.)
- Quel chiffre décide du « go » ou du « pivot » ? (Ex. 3 clients qui paient 50 €/mois après 60 jours.)
Sans réponses honnêtes, vous construisez un produit pour vous-même, pas pour le marché.
No-code d’abord : oui, souvent
Pour tester le flux (formulaires, bases, automatisations) avec quelques utilisateurs, Bubble, Airtable + Make, Notion + outils peuvent suffire. Le mur arrive quand vous voulez :
- droits fins par rôle et par donnée ;
- performance sous charge ;
- intégrations lourdes ou conformité stricte ;
- une expérience qui ne ressemble pas à « un outil interne ».
J’ai détaillé le basculement dans No-Code vs Code : le mur de la scalabilité. À ce stade, un MVP code (souvent front moderne + API + auth) peut coûter moins cher que six mois de bricolage no-code instable.
MVP code ne veut pas dire « tout refaire en microservices ». Souvent : une base de données, quelques écrans, un flux critique — livré en semaines, pas en trimestres.
Ce qui tue un MVP B2B (checklist anti-patterns)
- Trop de rôles dès le J1 (admin, manager, viewer, invité, auditeur…).
- Facturation complexe (plans, sièges, add-ons) avant le premier virement client.
- Design pixel-perfect avant le premier entretien utilisateur en conditions réelles.
- Roadmap publique de 24 mois affichée comme si c’était déjà en prod.
- Pas de désinscription / export — les premiers testeurs doivent faire confiance pour revenir.
Après le lancement : quoi mesurer
- Rétention : ils reviennent la semaine 2 ? La semaine 4 ?
- Tâche centrale : la promesse du MVP est-elle complétée sans appel au support ?
- Temps jusqu’à la valeur : combien de minutes pour le premier « aha » ?
Les likes LinkedIn ne paient pas les serveurs. La rétention et le paiement (même symbolique) oui.
Ressource côté Websual
Offre cadrée MVP en 4 semaines : page Startups.
Si vous avez déjà un cahier brouillon : contact — on peut le challenger en un échange.
Résumé : une promesse, un flux, des testeurs, une mesure — le reste est de la scope à gagner après preuve.