MVP d'application mobile : lancer une première version

Un MVP d’application mobile est la plus petite version de votre application qui rend un vrai service à de vrais utilisateurs. Il sert à vérifier vite, et avec un budget contenu, que votre idée répond à un besoin, avant d’investir dans toutes les fonctions imaginées. Il reste une application complète et soignée sur ce qu’elle fait : les stores refusent les brouillons, et les utilisateurs aussi.

Qu’est-ce qu’un MVP d’application mobile ?

MVP vient de l’anglais minimum viable product, que l’on traduit par « produit minimum viable ». Les deux mots comptent autant l’un que l’autre :

• minimum : on ne garde que ce qui est nécessaire pour résoudre le problème principal ;
• viable : ce qui est gardé fonctionne bien, du premier écran au dernier, sur iPhone comme sur Android.

Prenons l’exemple d’une salle d’escalade qui veut une application. La version complète imaginée compte la réservation des créneaux, la carte d’abonnement, le suivi des voies réussies, un classement entre grimpeurs et une boutique. Le MVP peut se limiter à la réservation et à la carte d’abonnement : c’est ce qui fait gagner du temps à l’accueil et aux clients dès le premier jour. Le reste attendra de savoir comment l’application est utilisée.

Une première version réussie fait peu de choses, mais les fait mieux que la solution actuelle de vos utilisateurs, qu’il s’agisse d’un coup de téléphone, d’un tableur ou d’un carnet papier.

Pourquoi commencer par une première version ?

Parce que les idées les plus sûres sur le papier se révèlent souvent différentes une fois entre les mains des utilisateurs. Une fonction jugée essentielle n’est jamais ouverte ; une autre, ajoutée presque par hasard, devient la raison pour laquelle on garde l’application.

Lancer un MVP permet :

• d’apprendre sur des faits plutôt que sur des suppositions ;
• de sortir plus tôt, et donc de commencer plus tôt à rendre service, à recueillir des avis et, le cas échéant, à vendre ;
• de dépenser au bon endroit : les versions suivantes financent ce que les utilisateurs demandent vraiment ;
• de limiter le risque : si l’idée doit être revue, elle l’est avant d’avoir tout construit.

Comment choisir les fonctions de la première version ?

Partez d’une phrase : « Mon application permet à [qui] de [faire quoi], plus simplement qu’aujourd’hui. » Toute fonction qui ne sert pas directement cette phrase est candidate au report.

Ensuite, décrivez le parcours principal de bout en bout, de l’ouverture de l’application jusqu’au moment où l’utilisateur a obtenu ce qu’il voulait. Tout ce qui est sur ce chemin entre dans le MVP. Le reste se range dans un tableau comme celui-ci :

Garder dans le MVP	Reporter à plus tard
Le parcours principal, complet	Les parcours secondaires
Création de compte et suppression du compte	Connexion par plusieurs réseaux sociaux
Un moyen de vous contacter	Messagerie intégrée entre utilisateurs
Un back-office simple pour gérer les contenus	Tableaux de bord et statistiques détaillés
Les notifications indispensables	Les notifications de relance et de promotion
Une seule langue, si votre public la parle	Les traductions

Si vous avez rédigé un cahier des charges avec des priorités, ce tri est déjà à moitié fait : notre article sur le cahier des charges d’une application mobile explique comment classer les fonctions.

Minimum, mais publiable : ce qu’exigent les stores

Un MVP destiné au public doit passer la validation d’Apple et de Google, qui ne font aucune différence entre une première version et une application mûre.

Les règles de l’App Store sont explicites sur plusieurs points :

• les démos, versions bêta et versions d’essai n’ont pas leur place sur l’App Store (section 2.2) : pour les tests, Apple renvoie vers TestFlight ;
• l’application soumise doit être une version finale (section 2.1) : pas de texte provisoire, pas de liens vides ;
• elle doit apporter une utilité réelle (section 4.2) : une simple page web emballée dans une application risque le refus ;
• si elle permet de créer un compte, elle doit permettre de le supprimer depuis l’application (section 5.1.1).

Côté Google Play, une contrainte concerne directement le calendrier : les comptes développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits pendant au moins 14 jours sans interruption avant de pouvoir publier en production. Cette exigence vise les comptes personnels : pour une entreprise, un compte d’organisation à son nom reste de toute façon le bon choix. Nous détaillons ces étapes dans notre article sur la publication sur Google Play.

Tester avant d’ouvrir au grand public

Avant la sortie officielle, faites utiliser l’application par un petit groupe : quelques clients fidèles, vos équipes, des proches qui correspondent à votre public.

• Sur iPhone, TestFlight permet d’inviter jusqu’à 10 000 testeurs externes, qui installent l’application de test par un simple lien ou une invitation.
• Sur Android, la Play Console propose des canaux de test interne, fermé et ouvert, qui distribuent l’application à une liste de testeurs avant la production.

Demandez aux testeurs d’accomplir le parcours principal sans explication. Là où ils hésitent, l’application doit être corrigée. Leurs retours valent bien plus que vos propres essais, parce que vous connaissez déjà le chemin.

Que mesurer après le lancement ?

Un MVP n’a de valeur que si l’on en tire des enseignements. Décidez avant la sortie de ce que vous allez observer :

• l’usage réel du parcours principal : combien de réservations, de commandes, de rapports envoyés ;
• le retour des utilisateurs : ceux qui reviennent la semaine suivante disent plus que ceux qui installent ;
• les avis sur les stores et les messages reçus : ils signalent les manques et les incompréhensions ;
• les demandes répétées : une fonction réclamée par beaucoup d’utilisateurs entre dans la prochaine version.

Ces mesures peuvent se faire en respectant la vie privée : des compteurs globaux, sans profil individuel, suffisent souvent pour répondre à ces questions. Ce que vous collectez doit figurer dans votre politique de confidentialité et dans les déclarations demandées par les stores.

Après le MVP : construire la suite sans tout refaire

Le piège classique est le MVP bricolé qu’il faut jeter dès qu’il marche. Une première version doit être petite en fonctions, mais propre dans sa construction : un code organisé, une base de données bien pensée, un back-office qui pourra grandir.

Le choix de la technologie compte aussi. Avec Flutter, une seule base de code sert l’iPhone et Android : chaque nouvelle fonction est écrite une fois et arrive sur les deux plateformes en même temps, ce qui accélère les versions suivantes. Nous comparons cette approche avec le développement natif dans Application native ou hybride.

Enfin, prévoyez dès le départ le rythme des mises à jour : corrections, adaptations aux nouvelles versions d’iOS et d’Android, puis nouvelles fonctions choisies d’après ce que vous avez mesuré.

Questions fréquentes

Combien de temps faut-il pour développer un MVP d’application ?

Cela dépend du nombre d’écrans et de ce qu’il y a derrière : comptes, paiements, échanges avec d’autres logiciels. Un MVP bien délimité se développe bien plus vite que la version complète, et il faut ajouter le temps de test et de validation par les stores, notamment les 14 jours de test fermé exigés pour certains comptes Google Play.

Un MVP peut-il être payant ?

Oui. Faire payer dès la première version est même une bonne façon de vérifier que le besoin est réel. Il faut alors respecter les règles de paiement des stores, qui diffèrent selon que vous vendez un contenu numérique ou un bien ou service consommé hors de l’application.

Faut-il sortir sur iPhone et Android en même temps ?

C’est préférable dès que votre public se partage entre les deux plateformes, ce qu’il vaut mieux vérifier avant de choisir. Avec une technologie multiplateforme comme Flutter, cela ne double pas le travail.

Que faire si le MVP ne trouve pas son public ?

C’est précisément ce que le MVP permettait de découvrir à moindre coût. Les retours recueillis indiquent souvent ce qu’il faut changer : la cible, le parcours principal ou la façon de présenter l’application.

Une première version bien choisie vous met vite entre les mains de vrais utilisateurs. Notre page Applications mobiles décrit comment nous menons un projet jusqu’aux stores, et vous pouvez nous présenter votre idée sur la page Parler de votre projet.