Combien coûte une application mobile ? Le détail, ligne par ligne

« Combien coûte une application mobile ? » est une question à laquelle on répond souvent par « ça dépend ». C’est vrai, et c’est inutile. Voici plutôt de quoi ça dépend, avec les prix réels de chaque poste, pour que vous puissiez estimer votre projet vous-même avant même de m’en parler.

Ce qui fait vraiment le prix

Le prix d’une application ne dépend presque jamais du « design » ou du nombre de plateformes. Il dépend de deux choses : le nombre d’écrans, et ce qui se passe derrière.

Une application qui affiche des contenus et un formulaire de contact peut être maquettée, développée et publiée en une poignée de jours. La même application, dès lors qu’elle doit gérer des comptes utilisateurs, un paiement, une messagerie ou une synchronisation avec un logiciel existant, change de catégorie : il faut alors développer un backend, c’est-à-dire un serveur, une base de données et une API. C’est ce backend, invisible dans les maquettes, qui fait basculer un budget de quelques milliers à quelques dizaines de milliers d’euros.

Le nombre de plateformes, lui, ne double plus le prix. Avec une technologie multiplateforme comme Flutter, une seule base de code alimente iOS et Android — c’est l’approche que j’utilise, par exemple, sur BudgeTracker.

Le budget, poste par poste

Voici les postes qui composent réellement un devis d’application mobile, aux tarifs publiés sur ma grille tarifaire (prix HT) :

• Maquettes : 90 € par écran, ou 350 € pour 4 écrans et 600 € pour 10 écrans. C’est ce qui vous permet de valider le parcours avant qu’il coûte cher à changer.
• Développement : 550 € par jour. C’est le poste principal, et le seul qui varie vraiment d’un projet à l’autre.
• Notifications push : 180 €, configuration Firebase Messaging comprise.
• Configuration des espaces stores : 90 € par plateforme, pour l’Apple Store comme pour Google Play.
• Déploiement : 90 € par plateforme, jusqu’à la publication effective.

Le poste « développement » est celui qu’il faut estimer sérieusement, et c’est précisément l’objet du cadrage : lister les écrans, décrire ce que fait chacun, et en déduire un nombre de jours défendable plutôt qu’un forfait au doigt mouillé.

Trois ordres de grandeur

Pour situer votre projet, voici les trois formats que je propose en packs :

• Valider une idée — 440 € : 4 écrans maquettés et un espace store configuré. Vous n’avez pas d’application, mais vous avez de quoi montrer le produit à un associé, un investisseur ou un premier client.
• Publier une première version — 6 300 € : 10 écrans maquettés, un forfait indicatif de 10 jours de développement, les notifications push, les deux comptes stores et la publication sur iOS et Android.
• Application sur-mesure — 550 € par jour : dès qu’il y a un backend, de la logique métier ou des intégrations tierces, on chiffre après cadrage technique. C’est la seule façon honnête de traiter ces projets-là.

Ces montants ne sont pas soumis à TVA (article 293 B du Code général des impôts) : le prix affiché est le prix payé.

Les trois lignes que personne ne chiffre

Ce sont rarement les postes du devis qui font déraper un budget d’application, mais ceux qui n’y figurent pas.

• Les comptes développeurs. Apple facture son programme développeur environ 99 $ par an, Google Play environ 25 $ une seule fois. Ce n’est pas une prestation, c’est un abonnement à votre nom — et sans lui, votre application n’existe sur aucun store.
• Le backend. Si votre application a des comptes utilisateurs, elle a un serveur. Ce serveur tourne toute l’année, qu’il y ait 10 ou 10 000 utilisateurs, et il doit être hébergé, sauvegardé et mis à jour.
• Les mises à jour imposées. iOS et Android évoluent chaque année, et Apple comme Google retirent des stores les applications qui ne suivent plus leurs exigences. Une application qu’on ne touche plus pendant deux ans n’est pas « stable » : elle est en sursis.

Comment faire baisser la facture sans saborder le projet

Il existe de bonnes et de mauvaises façons de réduire un budget d’application. La mauvaise consiste à rogner sur les maquettes ou les tests : on paie ensuite chaque correction au prix fort. Les bonnes sont plus ennuyeuses, et bien plus efficaces :

• Réduire le périmètre de la première version, pas la qualité. Une application qui fait bien trois choses se publie ; celle qui devait en faire quinze ne sort jamais.
• Retirer des écrans. C’est le levier le plus direct : chaque écran se maquette, se développe, se teste et se maintient.
• Vérifier qu’il vous faut bien une application. Si le besoin se résume à être consultable sur téléphone, un site bien conçu coûte nettement moins cher et se référence, lui, sur Google. L’application se justifie par les notifications, l’usage récurrent, le hors-ligne ou les capteurs du téléphone.

Et une fois l’application en ligne ?

Une application publiée n’est pas un projet terminé, c’est un projet qui commence à vivre. Corrections, montées de version, évolutions du store, retours des premiers utilisateurs : il faut prévoir un budget récurrent dès le départ, au même titre que pour un site. C’est le rôle de mes offres de maintenance, et la raison pour laquelle je préfère l’annoncer au devis plutôt que six mois plus tard.

Estimer votre projet

Le détail complet des prestations mobiles figure sur la page développement d’application mobile et dans la grille tarifaire. Si votre projet a un backend, la même logique s’applique côté web : j’en détaille les mécanismes dans combien coûte un site internet.

Le plus rapide reste encore d’en parler : décrivez votre idée en quelques lignes et vous repartez du premier échange de cadrage avec une liste d’écrans, un nombre de jours estimé et un devis détaillé — sans engagement.