Eramis →
Beaucoup de projets de logiciel échouent non parce qu’ils sont mal construits, mais parce qu’ils construisent trop, trop tôt. Le MVP est le remède : lancer vite une version réduite, apprendre avec de vrais utilisateurs, puis étendre ce qui marche.
Ce qu’un MVP n’est pas
Ni une maquette, ni un prototype qu’on jette : c’est un produit en ligne, avec des comptes, un paiement et des conditions d’utilisation. Un client peut s’y inscrire et payer. Ce qui manque, c’est tout ce qui n’a pas encore prouvé son utilité.
Choisir les trois fonctionnalités
Posez la question : « Sans laquelle personne ne paierait ? » Ce qui reste après ce tri tient généralement en trois fonctionnalités. Le reste — les rapports, les options, les réglages fins — va dans la liste de la version 2, sans regret.
Ce qu’on garde pour plus tard
- Les rôles complexes : au début, deux rôles suffisent
- Les intégrations « au cas où » : on branche les trois qui servent tous les jours
- Les réglages personnalisables : on décide à la place de l’utilisateur, on ajuste ensuite
- L’application mobile : un site bien fait sur téléphone suffit pour apprendre
Mesurer dès le premier jour
Un MVP sans mesure est une intuition de plus. Quelles pages sont vues, où les gens s’arrêtent, quelles fonctions sont utilisées : ces chiffres décident de la version 2, pas les avis en réunion.
Et le prix ?
Un MVP bien cadré se chiffre avant d’être construit : chez nous, dès 6 900.– pour trois fonctionnalités et trois intégrations, prix fixé à la fin de la semaine de cadrage. Comment ça se passe →