Que mettre dans le MVP d'une application mobile

Le conseil habituel sur le MVP — livrer quelque chose de brut, apprendre vite, itérer chaque semaine — a été écrit pour le web, où une mauvaise mise en production vit dix minutes et où personne ne s'en souvient.

Sur mobile, trois éléments brisent ce modèle :

1. L'itération est lente. Chaque changement passe par la validation du store, puis attend que les utilisateurs mettent à jour. La boucle de retour se compte en semaines, pas en heures.
2. Les notes sont quasi permanentes. Les avis à une étoile issus d'un lancement bâclé continuent d'affecter votre classement et votre conversion longtemps après la correction des bugs.
3. Installer est un véritable engagement. Visiter un site ne coûte rien. Installer une application coûte du stockage, une décision de permission et de la confiance — la barre est donc plus haute avant que quiconque essaie.

La conclusion n'est pas « ne faites pas de MVP ». C'est qu'un MVP mobile doit être plus restreint en périmètre mais plus abouti en exécution que son équivalent web. Moins de choses, faites correctement.

D'abord : faut-il vraiment une application ?

La question qu'un développeur d'applications est censé éviter. Nous préférons la poser.

Faites d'abord un site mobile si votre produit relève surtout du contenu, de la navigation, de formulaires ou de transactions ponctuelles. C'est moins cher, plus rapide à livrer, itérable chaque jour, sans validation de store, et partageable par lien — ce qui compte énormément pour la façon dont les gens découvrent réellement les choses.

Une application se justifie quand vous avez besoin de ce qu'elle seule offre :

• Des notifications push qui alimentent réellement la boucle centrale du produit.
• Un vrai usage hors ligne, pas seulement de la mise en cache.
• L'accès au matériel — la caméra comme fonction centrale, le Bluetooth, la localisation en arrière-plan.
• Un usage répété et habituel. Une icône sur l'écran d'accueil bat un favori pour ce qu'on ouvre chaque jour. Elle perd largement pour ce qu'on utilise deux fois par an.

Si votre réponse honnête est « nos clients s'attendent à ce que nous ayons une application », c'est une raison marketing, et elle est légitime — mais elle change la finalité du MVP, et il vaut mieux savoir lequel des deux vous construisez.

Le piège des notes

C'est le risque proprement mobile qui reconfigure le plus le périmètre d'un MVP.

Le classement dans les stores dépend fortement de la note et du volume d'avis, et les premiers avis pèsent de façon disproportionnée : ils arrivent quand vous avez peu de notes pour les diluer, et restent en tête de votre fiche longtemps. Un lancement bâclé ne fait pas qu'agacer vos premiers utilisateurs : il taxe votre visibilité pendant des mois.

Deux conséquences pratiques :

• Ne sollicitez pas d'avis tant que l'expérience n'est pas bonne. Demander trop tôt transforme une première impression brute en impression permanente.
• Faites un lancement discret sur un petit marché. Publiez d'abord sur une zone limitée, récoltez les données de plantage et les retours là où les avis comptent le moins, puis lancez pour de bon. C'est une pratique standard, et pour de bonnes raisons.

Ce qui a sa place dans le MVP

Une boucle centrale, terminée. Choisissez la seule chose pour laquelle l'application existe et rendez ce parcours vraiment bon — y compris les états ingrats : chargement, vide, hors ligne, erreur. Sur mobile, ce ne sont pas des finitions : c'est là que les utilisateurs passent du temps réel.

Un onboarding qui mène vite à la valeur. Vous disposez de très peu de patience. N'ouvrez pas sur un mur d'inscription si le produit peut d'abord démontrer sa valeur.

Les bases du hors ligne. Pas une synchronisation complète — simplement ne pas s'effondrer dans le métro. Un écran blanc sans explication passe pour une application cassée, et sera noté comme telle.

Rapport de plantages et analytics dès le premier jour. On ne débogue pas depuis les avis. Il faut savoir ce qui a cassé et où les gens abandonnent, sinon toute la logique d'apprentissage s'effondre.

Les obligations des stores. Déclarations de confidentialité, et suppression de compte si vous avez des comptes. Non facultatif, et lent à rajouter — voir combien de temps prend réellement une application.

Ce qu'on peut couper sans grand regret

• La seconde plateforme. Lancez sur une seule, financée par ce que vous apprendrez. La plus grosse réduction de périmètre disponible.
• Les comptes, si la boucle centrale fonctionne sans. L'inscription est le premier lieu d'abandon en début de session.
• Les écrans de réglages. Des valeurs par défaut sensées, et des préférences quand quelqu'un les demande.
• Les fonctions sociales. Partage, abonnements, commentaires — presque jamais la raison pour laquelle quelqu'un reste en v1.
• L'outillage d'administration sur mesure. Pilotez les opérations depuis des outils de base de données les premiers mois.

Validez avant de construire

Tout ce que dit comment valider une idée de SaaS s'applique, et compte davantage ici puisque le développement est plus long et le lancement plus difficile à défaire. Deux approches particulièrement efficaces sur mobile :

• Livrez d'abord la version web mobile. De vraies données d'usage sur de vrais utilisateurs, à une fraction du coût, sans validation de store. Si personne ne l'utilise dans un navigateur, une icône d'application n'y changera rien.
• Assurez le service manuellement. Faites-le en mode concierge par messagerie avant d'automatiser. Vous découvrirez la véritable boucle centrale au lieu de la deviner.

En résumé

Un MVP web peut être brut parce qu'on le corrige demain. Un MVP mobile ne le peut pas : il doit donc être plus petit et meilleur — une boucle, réellement finie, sur une plateforme, instrumentée, lancée discrètement avant d'affronter votre vrai marché.

Ce n'est pas un chemin plus lent. C'est la même quantité de travail dirigée vers moins de choses — ce qui, sur mobile, est précisément ce qui vous mène à une deuxième version qui vaille la peine d'être livrée.

Si vous voulez de l'aide pour décider ce qui entre dans la v1 — y compris s'il faut déjà une application — c'est une conversation que nous avons souvent. Découvrez notre approche du développement mobile et SaaS, ou contactez-nous.