Développement de MVP mobile pour startup

MVP, prototype ou preuve de concept : trois objets différents

Les trois mots circulent comme des synonymes dans les échanges avec les prestataires, alors qu’ils désignent trois livrables distincts, à trois budgets distincts. La confusion coûte cher : elle amène à payer le prix d’une application pour obtenir une maquette, ou l’inverse.

Le prototype ne contient aucun code. C’est un enchaînement de maquettes cliquables qui simule le parcours, utile pour aligner une équipe ou tester la compréhension d’un écran, incapable en revanche de produire la moindre donnée d’usage. La preuve de concept, ou POC, valide une faisabilité technique précise et souvent unique : une synchronisation hors ligne, un traitement d’image, une intégration à un logiciel de gestion existant. Elle ne s’adresse pas à des utilisateurs.

Le MVP, lui, est une application réelle, publiée, installée par de vrais utilisateurs, réduite au parcours qui démontre votre valeur. C’est le seul des trois qui répond à une question de marché plutôt qu’à une question technique. Si votre objectif est de convaincre un comité sur une faisabilité, demandez un POC. Si c’est d’aligner une équipe sur une vision, un prototype suffit et coûte bien moins cher. Si c’est de savoir si des gens utilisent votre produit, c’est un MVP, et le cahier des charges se rédige alors autour d’une hypothèse, pas d’une liste de fonctionnalités.

Ce qui entre dans le périmètre, et ce qui attend

Le cadrage consiste à écrire en une phrase l’hypothèse à valider, puis à ne garder que ce qui sert à la vérifier. Une hypothèse, un parcours, une mesure. Tout ce qui ne se rattache pas à ces trois éléments passe en version suivante, quelle que soit sa légitimité par ailleurs.

• Ce qui reste : l’entrée dans l’application, le parcours principal de bout en bout, et l’écran où se matérialise la valeur promise.
• Ce qui reste aussi : la mesure des usages. Un MVP sans instrumentation ne prouve rien et vous laisse avec des impressions au lieu de chiffres.
• Ce qui attend : le back-office complet, la gestion fine des rôles et des permissions, les notifications personnalisées, le multilingue, l’écran de paramètres, l’export de données.
• Ce qui attend toujours : les fonctionnalités ajoutées « pendant qu’on y est ». Elles allongent le délai et brouillent la lecture du résultat.
• Ce qu’on ne coupe jamais : la solidité de la base technique. C’est le périmètre que l’on réduit, jamais la qualité du socle sur lequel la suite se construira.

La partie difficile n’est pas de développer, c’est de renoncer. Sur la plupart des projets, l’atelier de cadrage retire entre la moitié et les deux tiers de la liste initiale. C’est ce qui permet de sortir en quelques semaines plutôt qu’en six mois, et donc d’apprendre quelque chose pendant que le marché est encore là.

Ce qui fait varier le budget et le délai

Un MVP démarre à 4 500 € et sort en trois à six semaines. Ce qui déplace ce curseur tient à quelques facteurs seulement : le nombre d’écrans du parcours, la présence de comptes utilisateurs, la connexion à un outil que vous utilisez déjà, le paiement intégré, et les contraintes réglementaires quand vous touchez à des données sensibles.

Les deux postes les plus sous-estimés sont l’intégration à l’existant et la validation. Brancher l’application sur un logiciel métier dépourvu d’API coûte souvent plus cher que le reste du développement, et un circuit de décision à quatre personnes ajoute des semaines qui ne se voient pas dans un devis. Le guide des prix détaille chaque poste, et le guide des délais montre où passe réellement le temps d’un projet.

Ce que regardent les investisseurs dans un MVP

Beaucoup de fondateurs commandent un MVP pour lever des fonds. Un business angel ou un fonds d’amorçage ne regarde presque jamais le code : il regarde le signal que l’application a produit. Trois écrans utilisés chaque semaine par deux cents personnes pèsent davantage qu’une application complète que personne n’ouvre.

En pratique, un dossier tient sur trois éléments : une version installable que l’interlocuteur peut essayer lui-même, en test fermé sur TestFlight ou sur le Play Store, un tableau de bord d’usage lisible en trente secondes, et une trajectoire qui montre ce que vous avez appris et ce que vous en déduisez. C’est aussi le format attendu par les incubateurs et par les dispositifs d’aide à l’innovation, qui financent une étape franchie plutôt qu’une intention.

No-code ou développement : l’arbitrage au démarrage

Nous le disons franchement quand c’est le cas : pour une toute première validation, une plateforme no-code comme Bubble, Glide ou FlutterFlow fait parfois le travail en quelques jours, pour quelques centaines d’euros. Si votre produit tient dans les capacités de l’outil et que vous visez une poignée d’utilisateurs, commencez par là et gardez votre budget pour la suite.

Le no-code devient un problème sur quatre points précis : le fonctionnement hors ligne, la fluidité dès que les écrans se chargent, l’intégration à un système existant, et le coût par utilisateur qui grimpe avec le volume. S’ajoute la question de la propriété : vous louez une plateforme, vous ne possédez pas votre application. Le passage au sur-mesure devient alors une reprise complète, et il vaut mieux l’avoir anticipé. Nos choix techniques visent précisément ce moment : un MVP construit en Flutter ou en React Native supporte la montée en charge sans réécriture.

Après le MVP : mesurer avant d’ajouter

Le réflexe le plus coûteux après la mise en ligne consiste à enchaîner les fonctionnalités. Le MVP a été construit pour produire une réponse : la lire d’abord. Trois indicateurs suffisent au démarrage, l’activation, la rétention à sept et trente jours, et le taux d’achèvement du parcours principal. Ils disent si le produit tient, et sur quel segment.

La suite se joue ensuite sur deux fronts. Le produit, avec des évolutions priorisées par ce que montrent les chiffres, dans le cadre d’un contrat de maintenance et d’évolution. Et l’acquisition, car une application invisible dans les magasins ne prouve rien non plus : notre guide sur l’ASO explique comment se rendre trouvable une fois la publication faite.