Combien coûte une application mobile ?

Il n'y a pas un prix, il y a un périmètre

Deux applications qui se ressemblent à l'écran peuvent avoir un budget dans un rapport de un à dix. Ce qui les sépare n'est presque jamais la difficulté technique : c'est le nombre de parcours, le nombre de plateformes, et ce qui tourne derrière l'écran. Un prix annoncé sans périmètre écrit ne veut rien dire, et c'est exactement le genre de devis qui dérive en cours de route.

La bonne question n'est donc pas « combien coûte une app », mais « quelle est la plus petite app qui prouve que la mienne a un marché ». Le budget découle de cette réponse.

Des paliers pour situer

Les paliers que nous publions pour un produit de départ donnent le bon point de repère. Nous les détaillons dans combien coûte un MVP : un périmètre très resserré démarre à partir de 1 500 à 4 000 €, un produit standard avec plusieurs parcours et un back-office léger se situe entre 4 000 et 10 000 €, et au-delà de 10 000 € on parle de logique métier riche, de temps réel ou de multi-plateforme.

Une application mobile se place dans le haut de ces paliers plus vite qu'un site, pour trois raisons simples : il faut des comptes utilisateurs presque toujours, un serveur pour stocker les données, et un passage par les stores. À périmètre fonctionnel identique, comptez un cran de plus que pour un produit web équivalent.

Les cinq facteurs qui font le prix

À idée égale, ce sont ces cinq points qui déplacent réellement le curseur.

• Le nombre de plateformes. iOS seul, iOS et Android, avec ou sans version web. Chaque plateforme ajoutée ajoute des tests, des conventions d'interface et une publication à gérer.
• Natif ou cross-platform. Le natif offre la meilleure finition et l'accès complet aux fonctions du téléphone. Le cross-platform couvre deux plateformes avec une base de code. Le choix se fait sur le produit, pas sur un dogme, et nous l'expliquons sur notre page développement d'application mobile.
• Ce qui tourne derrière. Une app qui affiche du contenu coûte peu. Une app avec comptes, rôles, synchronisation entre appareils et tableau de bord d'administration porte l'essentiel du budget dans sa partie invisible.
• Les intégrations. Paiement, géolocalisation, notifications, capteurs, APIs externes, achats intégrés. Chacune a un coût de mise en place et un coût de test, et les achats intégrés ajoutent en plus la commission des stores sur vos revenus.
• Le niveau de finition. Les transitions, les états de chargement, le comportement hors ligne, les cas limites. C'est ce qui fait qu'une app se sent chère. C'est aussi le poste le plus élastique : on peut le doser selon l'étape du produit.

Les coûts qu'on découvre après

Le développement n'est pas la seule ligne du budget, et les suivantes sont rarement annoncées.

• Les comptes développeur Apple et Google, obligatoires pour publier.
• L'hébergement et les services tiers, proportionnels à l'usage.
• La maintenance. iOS et Android sortent une version majeure par an ; une app laissée sans mise à jour vieillit vite et finit par casser.
• Les évolutions, si le produit marche. C'est la meilleure des mauvaises nouvelles, mais elle se budgète.

Aucune de ces lignes n'est énorme prise isolément. Ensemble, elles justifient de prévoir une enveloppe annuelle plutôt que de raisonner uniquement sur le coût de lancement.

Comment payer moins sans livrer moins

Le levier le plus puissant n'est pas de négocier le taux journalier, c'est de couper le périmètre. Sortir avec un parcours qui fonctionne vraiment coûte moins cher que sortir avec six parcours à moitié finis, et cela renseigne davantage sur votre marché. C'est toute la logique de la création de MVP : valider d'abord, empiler ensuite.

Trois décisions font l'essentiel de l'économie. Lancer sur une seule plateforme quand vos utilisateurs sont majoritairement sur l'une des deux. Remplacer un back-office sur mesure par un outil existant tant que les volumes sont faibles. Repousser tout ce qui n'est pas nécessaire à la première version, en l'écrivant noir sur blanc pour ne pas le réinventer plus tard.

Demandez un prix ferme, pas une estimation

Pour une première version, préférez un forfait à prix ferme après un appel de cadrage plutôt qu'une régie ouverte. Vous savez ce que vous dépensez, le studio a intérêt à rester efficace, et le périmètre est écrit avant que la première ligne de code soit posée. Si un prestataire ne peut pas vous annoncer de prix, c'est en général que le périmètre n'est pas encore assez clair. C'est un travail à faire avant de développer, pas pendant.