Pour choisir les fonctionnalités d’un MVP, gardez le plus petit parcours qui permet à un utilisateur précis d’obtenir le résultat promis et à votre équipe de délivrer réellement le service. Ajoutez ce qui mesure l’hypothèse, protège les utilisateurs et permet le lancement. Testez autrement les fonctions encore incertaines ; reportez le confort, les variantes et les automatisations dont l’usage n’est pas prouvé.
Méthode et exigences externes vérifiées le 8 septembre 2026. Les obligations de sécurité, de protection des données et de distribution restent à examiner selon le produit, le secteur et les pays visés.
Un MVP sert à prendre une décision, pas à montrer une petite application
Un produit minimum viable doit produire un apprentissage qui change la suite du projet. Eric Ries le définit par l’apprentissage validé obtenu avec le moins d’effort, pas par un nombre minimal d’écrans (Lean Startup Co.).
Une application peut être courte à développer mais incapable de répondre à la question commerciale. Elle peut aussi proposer un bel écran principal sans permettre à l’équipe de traiter la demande. Dans les deux cas, le produit est incomplet pour le test prévu.
Commencez donc par écrire la décision que le lancement doit éclairer. Par exemple : « après quatre semaines d’usage par des gestionnaires de sites invités, décider si le suivi d’incidents dans l’application remplace une partie des échanges par e-mail ». Cette phrase fixe une cible, un usage, une période d’observation et une décision. Elle évite de transformer « lancer un MVP » en objectif autonome.
Définissez la preuve avant de classer les fonctionnalités
Une fonctionnalité mérite sa place lorsqu’elle contribue au résultat attendu, rend ce résultat observable, permet de délivrer le service ou couvre un risque de lancement. Sans preuve définie, presque toutes les idées paraissent importantes.
Complétez cette phrase avant d’ouvrir le backlog :
Pour [utilisateur ciblé], dans [situation précise], nous pensons que [parcours ou service] permettra [résultat observable]. Nous poursuivrons si [signaux définis avant le test] ; sinon, nous changerons [cible, promesse, parcours ou solution].
Les signaux peuvent porter sur la fin du parcours, le délai pour atteindre le résultat, les retours au produit, les erreurs ou le travail manuel de l’équipe. Fixez leur calcul et votre règle de décision avant le pilote : aucun seuil n’est universel.
Dessinez une boucle d’usage complète
Le périmètre d’un MVP se comprend mieux comme une boucle que comme une liste de pages. Suivez un cas réel de bout en bout :
- L’utilisateur entre dans l’application et comprend ce qu’il peut faire.
- Il fournit les informations strictement nécessaires.
- Le produit ou l’équipe réalise le service promis.
- L’utilisateur sait si sa demande a abouti, échoué ou attend une action.
- L’équipe peut corriger une erreur, aider la personne et observer le résultat du test.
Cette boucle révèle les fonctions peu visibles. Si un client peut commander mais que personne ne peut corriger une adresse, traiter un échec de paiement ou informer le client, le parcours n’est pas viable. Un outil interne simple, une alerte et une procédure manuelle peuvent compter davantage qu’un écran de personnalisation.
Faites passer chaque fonction par quatre portes
Une matrice impact/effort aide à ordonner des options comparables, mais elle ne suffit pas à décider si le produit peut être lancé. Passez d’abord chaque fonction par ces quatre portes.
| Porte | Question à poser | Conséquence pour le MVP |
|---|---|---|
| Résultat utilisateur | Sans cette fonction, l’utilisateur peut-il atteindre le résultat promis ? | Si non, garder ou réduire la promesse. |
| Preuve | Sans elle, saurez-vous si l’hypothèse est confirmée ou infirmée ? | Garder une mesure minimale ou une observation manuelle fiable. |
| Exploitation | L’équipe peut-elle délivrer, corriger et assister le service ? | Garder un outil minimal ou une procédure soutenable. |
| Lancement et risque | Répond-elle à une exigence de sécurité, de données, de paiement, de secteur ou de distribution ? | La traiter avant le lancement concerné ou changer le périmètre du test. |
La quatrième porte ne doit pas devenir une rubrique « conformité plus tard ». La CNIL demande d’intégrer la protection des données et la sécurité dès la conception, jusque dans les choix d’architecture, de fonctions et de réglages par défaut (CNIL). Un MVP peut rester simple, mais pas ignorer un risque créé par son propre fonctionnement.
Le canal de distribution ajoute aussi des contraintes. Si une application mobile permet la création d’un compte, Apple demande que l’utilisateur puisse initier sa suppression dans l’application ; Google Play demande un chemin dans l’application et une ressource web pour cette demande (Apple Developer, Google Play Console). Selon votre choix d’authentification et de distribution, la gestion du compte peut donc faire partie du lancement, même si elle ne différencie pas le produit.
Classez en trois destinations, pas en deux camps
Une fonction qui ne rejoint pas immédiatement le MVP n’est pas forcément rejetée. Donnez-lui une destination et une condition de retour.
| Destination | Quand l’utiliser | Ce qu’il faut documenter |
|---|---|---|
| Indispensable dans le produit | Elle ferme la boucle, produit la preuve, permet l’exploitation ou couvre un risque. | Version acceptable, cas d’erreur et critère de fin. |
| À tester autrement | L’hypothèse peut être observée sans automatisation complète. | Prototype, opération manuelle ou outil existant ; responsable, charge et durée du test. |
| À reporter | Elle améliore le confort, étend la cible ou automatise un usage non prouvé. | Signal de réexamen et conséquence assumée de son absence. |
Tester autrement n’autorise pas un service improvisé. Si une personne remplace temporairement un algorithme, chiffrez le nombre de dossiers qu’elle peut traiter, définissez les accès aux données et prévoyez l’arrêt du test. La solution manuelle sert à apprendre ; elle ne doit pas cacher un coût d’exploitation impossible à tenir.
Exemple rempli : une application fictive de suivi d’incidents
Prenons une entreprise fictive qui entretient plusieurs immeubles. Les occupants signalent une panne par téléphone ou e-mail. Les gestionnaires ignorent parfois si la demande a été reçue, tandis que l’équipe ressaisit les informations.
L’hypothèse est la suivante : des gestionnaires invités utiliseront une application mobile pour déclarer un incident s’ils obtiennent immédiatement un accusé de réception et peuvent voir son statut. Le pilote concerne cinq sites déjà clients. Il ne cherche pas encore à vendre un nouveau service ni à optimiser automatiquement les tournées.
| Fonction envisagée | Décision | Raisonnement et conséquence |
|---|---|---|
| Accès par invitation et lien temporaire | Garder | Limite le pilote aux gestionnaires prévus et évite un formulaire d’inscription public. L’équipe doit toutefois pouvoir retirer un accès. |
| Choix du site, description et photo facultative | Garder | Constitue la déclaration minimale. La photo reste facultative pour ne pas bloquer une personne ni collecter plus de données que nécessaire. |
| Confirmation et statut de la demande | Garder | Ferme la boucle pour l’utilisateur et permet de mesurer si le suivi remplace des relances. |
| Tableau interne pour qualifier et changer le statut | Garder, version simple | Sans traitement côté équipe, la promesse est fausse. L’affectation avancée et les droits fins restent hors du pilote si un seul groupe traite les demandes. |
| Notification push | Tester autrement | Un e-mail de changement de statut suffit pour observer si la notification est utile. La fonction native sera réexaminée si les messages sont manqués ou trop lents. |
| Détection automatique des doublons | Tester autrement | L’équipe marque les doublons pendant le pilote et mesure leur fréquence avant de concevoir une règle. |
| Chat en temps réel avec le technicien | Reporter | Le statut et un contact de support couvrent le besoin initial. Reprendre le chat seulement si les échanges nécessaires restent nombreux et traçables. |
| Position du technicien sur une carte | Reporter | Ne contribue ni au signalement ni à la confirmation du traitement et introduit une collecte de localisation à justifier. |
| Tableau de bord client personnalisé | Reporter | Un export hebdomadaire préparé par l’équipe permet d’identifier les informations réellement demandées avant de construire des graphiques. |
Ce MVP contient un parcours utilisateur, un outil opérationnel, des états compréhensibles et des observations. L’équipe accepte temporairement de qualifier les demandes et de préparer un export à la main. Elle mesure ce travail, car une hypothèse commerciale confirmée avec une exploitation intenable ne justifie pas la même V2.
Vérifiez le MVP avec des scénarios, pas avec des intitulés
Une fonction nommée « gestion des incidents » est trop large pour être estimée ou validée. Écrivez des scénarios qui traversent l’ensemble du produit :
- un gestionnaire invité déclare une panne avec une photo et reçoit une confirmation ;
- l’équipe détecte une demande incomplète, contacte la personne et corrige l’information sans perdre l’historique ;
- un utilisateur sans accès tente d’ouvrir le dossier d’un autre site ;
- une demande échoue à l’envoi et l’utilisateur sait quoi faire ;
- l’équipe exporte les observations nécessaires à la décision de poursuivre.
Chaque scénario doit préciser le résultat attendu, les données concernées, le responsable en cas d’erreur et la preuve conservée. Vous découvrirez souvent qu’une fonction peut être simplifiée, mais qu’un cas d’échec ou un rôle interne ne peut pas disparaître.
Quand faut-il arrêter de réduire le périmètre ?
Arrêtez de retirer des fonctions lorsque la version permet de tester la promesse sans tromper l’utilisateur ni rendre le service incontrôlable. Avant le lancement, vérifiez ces six points :
- un utilisateur et une situation sont nommés ;
- un parcours complet aboutit à un résultat visible ;
- l’équipe sait traiter et corriger ce parcours ;
- les cas d’échec graves ont une réponse ;
- les exigences du canal, des données et du secteur ont été examinées ;
- les signaux et la décision suivant le test sont écrits.
Si un point manque, la réponse n’est pas toujours « développer davantage ». Vous pouvez réduire la cible, fermer les inscriptions, choisir un test accompagné, utiliser un prototype ou vous appuyer sur un outil existant. Le MVP est un moyen de réduire une incertitude, pas l’obligation de mettre immédiatement une application publique dans les stores.
Préparer le cadrage de la première version
Conservez une page avec l’hypothèse, la boucle d’usage, les quatre portes, les fonctions reportées et leurs signaux de retour. Le modèle de cahier des charges d’application aide à documenter les utilisateurs, les règles et les inconnues sans figer la solution. L’article sur le prix d’une application mobile permet ensuite de relier ce périmètre aux interfaces, intégrations, tests et charges après lancement.
Klaapp accompagne le cadrage et la création d’applications, de logiciels et de sites web. Un premier échange peut servir à écrire la preuve recherchée, parcourir un cas réel et classer les fonctions entre produit, test alternatif et report. La conclusion peut être un prototype, un outil existant ou une opération manuelle avant tout développement.
Questions fréquentes
Combien de fonctionnalités doit contenir un MVP ?
Il n’existe pas de nombre valable pour tous les produits. Comptez les fonctions nécessaires à une boucle d’usage complète, à son exploitation, à sa mesure et aux risques du lancement. Un parcours peut nécessiter plusieurs petites fonctions ; une seule fonction très large peut déjà cacher plusieurs projets.
Quelle différence entre un prototype et un MVP ?
Un prototype sert surtout à examiner une idée, une interface ou une faisabilité sans délivrer forcément le service en conditions réelles. Un MVP est utilisé par la cible prévue pour obtenir un résultat et produire une observation qui guide la suite. Un prototype peut donc précéder le MVP ou remplacer temporairement une fonction incertaine.
Faut-il intégrer un back-office dans la première version ?
Oui si l’équipe doit recevoir, vérifier, corriger ou faire avancer ce que l’utilisateur déclenche. Ce back-office peut être très simple ou reposer temporairement sur un outil existant. Il faut toutefois définir les droits, l’historique utile et la manière de gérer les erreurs.
Comment décider qu’une fonctionnalité reportée entre en V2 ?
Associez-lui un signal avant le lancement : volume d’opérations manuelles, fréquence d’une demande, erreurs observées, délai devenu incompatible avec le service ou extension confirmée de la cible. Réexaminez la fonction lorsque ce signal apparaît, avec les données du pilote plutôt qu’avec l’enthousiasme initial.
Sources
- Lean Startup Co. — What Is an MVP? Eric Ries Explains
- CNIL — Préparer son développement
- Apple Developer — Offering account deletion in your app
- Google Play Console Help — App account deletion requirements
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.