Combien coûte une application mobile ?

« Il me faut une app sur l'App Store. » La phrase tombe souvent très tôt, parfois avant même que le produit existe. Et elle a un coût caché : à périmètre égal, partir sur du mobile natif double fréquemment le budget d'un MVP. Avant d'engager cet argent, il vaut la peine de comprendre pourquoi, et de vérifier que vous en avez vraiment besoin maintenant.

Une application mobile pour une startup coûte, sur le marché, de 30 000 à 50 000 € en approche hybride ou web, et de 60 000 à 150 000 € voire plus en natif pour iOS et Android. L'écart vient surtout du fait qu'en natif, vous construisez et maintenez deux applications distinctes, plus l'infrastructure de publication. Dans bien des cas, un site web mobile bien fait suffit pour valider votre idée.

Si vous cherchez d'abord à cadrer ce que doit contenir votre premier produit, c'est dans le guide du MVP au PMF. Ici, on regarde le cas particulier du mobile et sa facture.

Pourquoi le mobile double souvent la note

L'intuition trompeuse, c'est qu'une app mobile « c'est juste mon site en plus petit ». En réalité, vous n'ajoutez pas un écran, vous ouvrez plusieurs chantiers parallèles. Et chacun a un coût qui ne se voit pas dans le devis initial.

À cela s'ajoute un coût récurrent que les fondateurs sous-estiment : une app native n'est jamais « finie ». Apple et Google publient des versions d'OS, durcissent leurs règles, déprécient des API. Sans entretien régulier, votre app casse. Un site web, lui, ne vous impose pas ce calendrier subi.

Les trois approches, et ce qu'elles coûtent

Toutes les apps mobiles ne se valent pas en coût ni en compromis. Il existe un continuum entre le web pur et le natif intégral, et la bonne réponse dépend de ce que votre produit fait réellement avec le téléphone.

La ligne du milieu, le cross-platform, est celle qu'on oublie le plus souvent. Elle permet de publier sur les deux stores depuis une seule base de code, donc à un coût bien moindre que le natif, tout en offrant une vraie expérience d'application installée. Pour un MVP, c'est très souvent le bon point d'équilibre quand le web ne suffit plus mais que le natif intégral est prématuré.

Quand le web mobile suffit (c'est plus souvent qu'on croit)

Avant de financer une app native, posez-vous une question simple : votre produit a-t-il vraiment besoin du téléphone, ou seulement d'être accessible sur le téléphone ? Ce n'est pas la même chose. Un site web responsive, bien conçu, s'ouvre sur n'importe quel mobile, peut s'épingler sur l'écran d'accueil et offre l'essentiel des usages. Une PWA va plus loin : installation, fonctionnement hors-ligne partiel, notifications dans la plupart des cas.

Le web mobile suffit largement quand votre produit repose sur du contenu, des formulaires, un tableau de bord, une réservation, un paiement, bref tout ce qui ne sollicite pas en continu le matériel du téléphone. C'est le cas de la grande majorité des MVP.

Quand le natif se justifie vraiment

Soyons justes : il y a des cas où l'app native n'est pas un luxe. Si votre produit vit dans le téléphone (géolocalisation permanente, usage de la caméra ou des capteurs au cœur de la valeur, notifications push centrales au métier, performance graphique exigeante, ou une présence sur les stores qui fait partie de votre crédibilité commerciale), alors le surcoût est un investissement, pas un gaspillage.

Mais même dans ces cas, la bonne séquence est rarement de tout construire en natif dès le premier jour. On valide d'abord la valeur avec le moyen le moins cher, puis on passe au natif quand l'usage le mérite. Décider l'inverse, c'est financer la version la plus chère d'un produit dont personne n'a encore prouvé qu'il rencontrera son marché, exactement le piège que je décris pour le coût d'un MVP en général dans combien coûte un MVP.

Le vrai arbitrage : pas « web ou natif », mais « quand »

La question n'est presque jamais binaire. Elle est temporelle. Le bon réflexe n'est pas de choisir une fois pour toutes entre web et natif, c'est de choisir le moment où chaque investissement devient pertinent. Web ou cross-platform pour valider vite et à coût maîtrisé, natif quand l'usage réel et le modèle économique le justifient. Sauter directement au natif intégral pour un produit non validé, c'est le meilleur moyen de dépenser le plus, le plus tôt, sur l'hypothèse la moins sûre. Si votre budget mobile a déjà dérivé, les leviers pour le reprendre sont dans MVP qui coûte trop cher.