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

Tout le travail sur une application se facture au temps passé, au tarif publié : 600 € HT la journée, 300 € HT la demi-journée. Ce temps se répartit entre les postes qui composent réellement un devis d’application mobile :

• Maquettes : chaque écran dessiné et validé avant d’être développé. C’est ce qui vous permet de valider le parcours avant qu’il coûte cher à changer.
• Développement : le poste principal, et le seul qui varie vraiment d’un projet à l’autre.
• Notifications push : la configuration du service d’envoi et leur intégration dans l’application.
• Configuration des espaces stores : fiches, captures et réglages sur l’App Store comme sur Google Play.
• Déploiement : la soumission et le suivi 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é.

Comment le prix est fixé

• Le cadrage : on liste les écrans et ce qui se passe derrière — comptes, paiement, synchronisation. C’est là que se voit la différence entre une application de quelques jours et un projet avec backend.
• Le nombre de jours : chaque écran et chaque fonctionnalité sont estimés, puis additionnés.
• Le devis ferme : ce nombre de jours et le périmètre sont écrits avant de commencer. Vous connaissez le montant avant de vous engager.

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 la maintenance au ticket, 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 de l’offre mobile figure sur la page création d’application mobile, et le simulateur vous donne le point de départ en une étape. 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.