MVP application mobile : validez un parcours avant de développer le reste
Un MVP d’application mobile n’est pas une version médiocre de votre vision. C’est la plus petite version qui permet à une personne précise de terminer un parcours utile et à votre équipe de vérifier une hypothèse risquée. Commencez par l’utilisateur, le problème et le résultat. Choisissez ensuite une plateforme, un parcours principal et les fonctions indispensables à ce parcours.
Le sigle signifie « minimum viable product ». Minimum limite le périmètre. Viable impose que le produit fonctionne assez bien pour être utilisé et évalué. Product signifie que vous livrez une expérience complète, pas une collection d’écrans statiques.
La réponse courte
Votre MVP mobile doit répondre à cinq questions : qui l’utilise, quel problème il résout, quel parcours cette personne doit terminer, quelle hypothèse vous testez et quel signal vous aidera à décider de la suite. Si une fonction ne soutient ni le parcours ni le test, placez-la après la première version.
1. Écrivez le problème sans décrire l’interface
Évitez « nous voulons une app comme X ». Décrivez ce qui échoue aujourd’hui : un technicien ressaisit un rapport papier, un client ne peut pas réserver sans appeler, ou une équipe perd l’état d’une intervention hors connexion.
Ajoutez un résultat observable. Par exemple : « le technicien termine le rapport sur place et le dossier se synchronise sans doublon quand le réseau revient ». Cette phrase filtre le périmètre mieux qu’une liste de fonctionnalités.
2. Choisissez un seul parcours principal
Cartographiez le déclencheur, les étapes, les états d’erreur et la fin du parcours. Une application de réservation peut commencer par rechercher un créneau, choisir, confirmer et recevoir la preuve de réservation. Les avis, le programme de fidélité, la messagerie et les recommandations peuvent attendre.
Le parcours doit fonctionner de bout en bout. Trois fonctionnalités inachevées apprennent moins qu’un chemin complet que de vrais utilisateurs peuvent essayer.
3. Séparez le nécessaire, le test et la suite
| Groupe | Question | Exemple |
|---|---|---|
| Nécessaire | Le parcours échoue-t-il sans cette fonction ? | Compte, réservation, confirmation |
| Test | Quelle inconnue peut invalider le produit ? | Synchronisation hors ligne |
| Suite | Peut-on apprendre avant de la construire ? | Recommandations personnalisées |
Marquez aussi ce qui reste explicitement hors périmètre. Cette liste protège les délais et les devis contre les suppositions.
4. Testez les risques avant de polir
Un prototype cliquable peut tester la compréhension du parcours. Un prototype technique peut tester la caméra, le Bluetooth, un paiement, une API ou le travail hors connexion. Utilisez le livrable le moins coûteux qui répond à la question.
Ne confondez pas un test de désirabilité avec une preuve technique. Une maquette convaincante ne prouve pas que la synchronisation fonctionne. Un prototype technique ne prouve pas que la personne comprend l’interface.
5. Définissez les critères d’acceptation
Écrivez ce que votre équipe doit observer. « Mode hors ligne » reste vague. Préférez : « après avoir ouvert une intervention, le technicien peut ajouter des photos sans réseau ; l’app envoie une seule version quand la connexion revient ».
Ajoutez les appareils, versions système, langues, permissions refusées, accessibilité et volumes de données. Apple maintient les App Review Guidelines, et Google publie son Policy Center. Vérifiez les règles actuelles avant la mise en ligne.
6. Mesurez pour décider, pas pour décorer
Choisissez un signal lié à l’hypothèse : la personne termine-t-elle le parcours, où abandonne-t-elle, comprend-elle le résultat, revient-elle quand le problème réapparaît ? N’inventez pas un objectif chiffré sans historique. Définissez d’abord la décision que le signal doit éclairer.
Les erreurs qui gonflent un MVP
- viser iPhone, Android, tablette et web sans raison de lancement ;
- ajouter plusieurs rôles avant de valider le parcours principal ;
- construire une administration complète alors qu’une opération manuelle suffit au pilote ;
- polir chaque écran avant de tester l’intégration la plus risquée ;
- traiter la sécurité, les données et la publication à la fin.
Votre brief en dix lignes
- Utilisateur principal.
- Problème actuel.
- Résultat observable.
- Parcours de bout en bout.
- Plateforme de lancement.
- Données nécessaires.
- Intégrations et permissions.
- Hypothèse la plus risquée.
- Critères d’acceptation.
- Fonctions reportées.
Un bon MVP ne cherche pas à paraître complet. Il cherche à produire une décision crédible avec le moins de produit inutile possible.
