Ce qu’est un MVP, et ce qu’il n’est pas
MVP signifie produit minimum viable (minimum viable product). C’est la première version de votre produit que de vraies personnes peuvent utiliser pour accomplir la chose principale qu’il promet, construite correctement et hébergée sur une vraie infrastructure. Elle est réduite, mais elle fonctionne.
Un MVP n’est pas une maquette cliquable, une présentation ou un prototype qui ne tourne que sur l’ordinateur d’un développeur. Ces outils servent à discuter d’idées, mais on ne peut pas les mettre entre les mains de clients et apprendre de leur usage. Ce n’est pas non plus une version au rabais de l’application complète. Le périmètre est minimal ; la qualité ne l’est pas.
Un bon MVP pose aussi les fondations dont les versions suivantes auront besoin : de vrais comptes et des droits d’accès, une structure claire pour les données, des sauvegardes, et un code qu’un autre développeur peut lire. Retirer des fonctionnalités, c’est normal. Retirer ces fondations, c’est se condamner à reconstruire plus tard, en général au moment où le produit commence à marcher.
Choisir l’indispensable
Partez de la seule tâche que votre produit doit bien accomplir pour un type d’utilisateur. Pour l’application d’une clinique, ce peut être prendre rendez-vous ; pour une place de marché, permettre à un acheteur de trouver et contacter un vendeur ; pour un outil interne, remplacer le tableur que tout le monde se dispute. Puis parcourez votre liste de fonctionnalités et demandez-vous pour chacune : un utilisateur peut-il accomplir la tâche principale sans elle ?
- Indispensable : sans elle, la tâche principale est impossible.
- Utile : elle facilite la tâche, mais il existe pour l’instant un moyen manuel de s’en passer.
- Plus tard : intéressante, mais elle dépend de ce que l’on apprendra de l’usage réel du produit.
Soyez strict. Tableaux de bord d’administration, rapports détaillés, rôles multiples, notifications pour chaque événement, deuxième langue de l’interface : tout cela est souvent utile, et rarement nécessaire la première semaine. Beaucoup de ces besoins peuvent être traités à la main, en coulisses, dans la première version.
Chaque fonctionnalité ajoutée à la première version retarde le jour où vous saurez si la première était la bonne.
Un court sprint de cadrage pour fixer le périmètre
Quand l’idée est nouvelle, le périmètre est un ensemble d’hypothèses : quelle fonctionnalité compte le plus, comment les utilisateurs circuleront dans le produit, quelles intégrations sont nécessaires. Un court sprint de cadrage, en général deux à trois semaines au périmètre fixe, transforme ces hypothèses en décisions. Il définit à qui s’adresse le produit, le parcours principal écran par écran, les choix techniques, et se termine par une première version fonctionnelle et un plan écrit pour la suite.
L’objectif est de répondre aux questions coûteuses au début, quand changer d’avis coûte des jours, et non à la fin, quand cela coûte des mois.
Quand une application complète se justifie dès le départ
Le MVP n’est pas toujours la bonne réponse. Construire le produit complet d’emblée peut se justifier quand :
- Vous remplacez un système existant, et les utilisateurs dépendent déjà de toutes ses fonctions.
- Le périmètre est déjà clair et documenté, par exemple un espace client aux écrans et règles connus.
- La réglementation ou des contrats imposent certaines fonctions dès le lancement, comme des droits d’accès, un historique des actions ou des mesures de sécurité précises.
- Le produit ne fonctionne que si plusieurs parties sont présentes en même temps, et une version partielle ne serait utilisable par aucune d’elles.
Même dans ce cas, la réalisation doit être découpée en étapes datées et validées, pour que vous voyiez régulièrement un logiciel qui fonctionne au lieu d’attendre une seule grande livraison.
Web ou mobile d’abord
Une application web tourne dans le navigateur sur n’importe quel appareil, peut être mise à jour à tout moment et s’ouvre par un simple lien. Elle convient aux produits utilisés au bureau, aux outils internes, aux espaces d’administration et à la plupart des premières versions. Une application mobile installée depuis l’App Store ou Google Play convient aux produits utilisés chaque jour en déplacement, ou qui ont besoin de l’appareil photo, de la localisation, d’un usage hors connexion ou des notifications. Elle ajoute aussi la validation des magasins à chaque nouvelle version.
Un parcours fréquent consiste à commencer par le web, conçu pour bien fonctionner sur téléphone, puis à ajouter des applications mobiles quand l’usage montre qu’elles en valent la peine. Les frameworks multiplateformes permettent aujourd’hui à une seule base de code de servir iOS et Android, ce qui rend l’ajout du mobile plus simple par la suite. Si vos utilisateurs vivent clairement sur leur téléphone dès le premier jour, commencez par là.
Préparer la deuxième version à partir de l’usage réel
La deuxième version doit se décider à partir de ce qui se passe après la mise en ligne de la première, pas à partir de la liste de souhaits d’origine. Avant le lancement, décidez de ce que vous mesurerez : inscriptions, nombre de personnes qui accomplissent la tâche principale, moment où elles s’arrêtent, demandes reçues au support. Parlez aux premiers utilisateurs. Puis reprenez les listes « utile » et « plus tard » avec ces éléments, et choisissez la version suivante.
Certaines fonctionnalités de la liste d’origine se révéleront essentielles. D’autres disparaîtront discrètement, parce que personne ne les demande. Les deux résultats sont utiles : c’est ainsi qu’un produit s’améliore sans effort gaspillé.
Les questions à trancher avant de commencer
- Qui est le premier utilisateur, et quelle est la tâche unique que le produit doit accomplir pour lui ?
- Qu’est-ce qui existera à la fin de la première version, écrit écran par écran ?
- Que mesurerez-vous après le lancement, et comment ?
- À qui appartiennent le code, les comptes et les données ?
- Comment la deuxième version sera-t-elle cadrée et chiffrée ?
Comment nous travaillons chez Qafza
Nous construisons des applications SaaS et des logiciels sur mesure, souvent en commençant par un Discovery Sprint de deux à trois semaines qui se termine par une première version fonctionnelle et un plan, le montant du sprint étant déduit de la réalisation complète si vous continuez. Les réalisations complètes, sur le web et en mobile multiplateforme, sont livrées par étapes datées et validées, et une fois le paiement complet, le code et les comptes vous appartiennent. Nous nous engageons sur le périmètre, les délais et la qualité ; quand les premiers utilisateurs arrivent, nous mesurons avec vous les inscriptions et l’usage.
Un MVP qui fonctionne en 2 à 3 semaines, pas des slides.Réserver un appel de cadrage de 30 min 
Vous préparez une application ou un SaaS ?Notre modèle gratuit vous guide sur le problème, la première version, les parcours clés et les décisions à prendre avant le développement.Obtenir le modèle 
L'équipe Qafza7 octobre 2026
