La question qu’on nous pose le plus souvent est « combien coûte mon application ». La bonne question, celle qui décide vraiment du sort d’un projet, c’est le coût total d’une application mobile sur la durée. Un devis de développement chiffre la construction d’un produit. Il ne chiffre pas sa vie. Et une application, contrairement à un site vitrine qu’on peut laisser dormir deux ans, vit dans un environnement qui bouge tout seul, sans vous demander votre avis.
Nous créons des applications depuis 2014, et nous en maintenons certaines depuis presque aussi longtemps. Ce recul nous a appris une chose simple : une app budgétée uniquement pour sa V1 est une app qui meurt en dix-huit mois. Pas parce qu’elle était mal conçue, mais parce que plus personne n’avait prévu la ligne budgétaire de l’année deux. Cet article ne vous donnera pas de prix inventés. Il vous donnera la liste des postes réels et une méthode pour construire votre budget sur trois ans.
Pourquoi le coût total d’une application mobile dépasse largement le budget de build
Le budget de build, c’est ce que vous payez pour concevoir, développer, tester et publier la première version. C’est la partie visible, celle qui apparaît sur le devis, celle que tout le monde compare d’une agence à l’autre. Elle est légitime et nécessaire. Elle est aussi incomplète.
Ce qu’un devis de développement ne couvre jamais
Un devis de création couvre un périmètre fonctionnel défini, à une date donnée, sur les versions d’OS du moment. Il ne couvre pas les frais de compte développeur, ni l’infrastructure qui fera tourner votre back-office pendant trois ans, ni les abonnements aux services tiers, ni le travail imposé par les mises à jour d’iOS et d’Android, ni les évolutions réclamées dès le troisième mois, ni le support, ni l’acquisition. Ce ne sont pas des omissions commerciales, ce sont d’autres natures de dépenses, avec d’autres rythmes.
Le problème apparaît quand le porteur de projet débloque exactement le montant du build, à l’euro près. Le produit sort, il fonctionne, et six mois plus tard la moindre correction devient un arbitrage douloureux. Nous voyons régulièrement arriver des applications orphelines, développées ailleurs, dont le propriétaire découvre qu’il faut repayer pour continuer à exister sur les stores.
La règle des dix-huit mois
Dix-huit mois, c’est à peu près le délai au bout duquel une application non maintenue commence à se voir. Une version majeure d’iOS et une d’Android sont passées, un service tiers a changé son API, un écran s’affiche de travers sur les nouveaux modèles, les avis se dégradent, et le produit glisse vers l’abandon. La remise à niveau coûte alors plus cher que ne l’aurait fait un entretien régulier. C’est le scénario que nous cherchons à éviter dès la phase de cadrage, en posant le coût total de l’application sur la table avant la signature.
Les postes récurrents, année après année
Les comptes développeurs Apple et Google
Ce sont les seuls montants que nous citons ici en valeur absolue, parce qu’ils sont publics et officiels. L’Apple Developer Program est une adhésion annuelle facturée 99 dollars par an, à renouveler tous les ans sous peine de voir votre application retirée de l’App Store. Côté Google, l’ouverture d’un compte développeur Google Play coûte 25 dollars en frais d’inscription, une seule fois, sans renouvellement annuel. Les tarifs sont affichés en devise locale au moment de l’inscription (chiffres consultés le 6 août 2026).
Ces comptes doivent être ouverts au nom de votre entreprise, pas au nom de l’agence. Nous détaillons la procédure dans nos guides pour créer un compte Apple Developer et pour créer un compte développeur Google Play.
L’hébergement, l’API et le back-office
Presque aucune application ne se suffit à elle-même. Dès qu’il y a des comptes utilisateurs, du contenu à administrer ou des données à synchroniser, il y a un serveur, une base de données, des sauvegardes et un back-office. Ce poste est mensuel, il démarre bas et il grandit avec votre audience. Une architecture sobre coûte peu longtemps, une architecture bavarde vous facture chaque utilisateur supplémentaire. Cela se décide au moment de concevoir le back-office et l’API, pas au moment de recevoir la facture.
Les services tiers
Notifications push, cartographie, paiement, authentification, envoi d’e-mails et de SMS, analytics, suivi des plantages : une application moderne s’appuie sur une pile de briques externes. Certaines sont gratuites jusqu’à un seuil, puis payantes. D’autres sont facturées à la transaction. La cartographie et le paiement surprennent le plus, parce qu’ils augmentent proportionnellement au succès de l’application. Le bon réflexe n’est pas de les éviter, c’est de connaître le modèle de facturation de chacune avant de l’intégrer, et de savoir laquelle est remplaçable si les tarifs bougent.
La maintenance imposée par iOS et Android
C’est le poste le plus mal compris, parce qu’il n’est déclenché par aucune demande de votre part. Apple et Google publient une version majeure de leur système par an, et ils imposent des dates couperet aux applications qui veulent rester publiables.
Des dates couperet, pas des recommandations
Chez Apple, les applications envoyées à l’App Store doivent être compilées avec un environnement récent : depuis le 28 avril 2026, la soumission exige Xcode 26 et le SDK iOS 26. Chez Google, la règle est équivalente et connue à l’avance : depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (API 36) au minimum, et une application qui reste sur un niveau d’API trop ancien voit sa visibilité restreinte sur les appareils récents. Google a par ailleurs resserré son rythme, avec une version majeure au deuxième trimestre et une version mineure au quatrième, ce qui avance les campagnes de tests de compatibilité de plusieurs mois par rapport aux années précédentes.
Traduction budgétaire : même si vous ne demandez strictement aucune nouveauté, votre application consomme du temps de développement chaque année. Ce n’est pas négociable, c’est la condition pour rester en ligne.
Corrective, adaptative, évolutive : trois lignes différentes
Mélanger ces trois natures de travail est la source d’incompréhension numéro un entre un client et son prestataire. La corrective répare ce qui est cassé. L’adaptative absorbe les changements d’environnement dont nous venons de parler. Les évolutions fonctionnelles, elles, ajoutent de la valeur : un nouveau parcours, un module réclamé par les utilisateurs, une intégration à un outil interne. Les deux premières se subissent, la troisième se décide. Elles doivent apparaître séparément dans votre budget, sans quoi les corrections mangent l’enveloppe des évolutions et le produit stagne. Nous détaillons ce découpage dans notre article sur la TMA et la maintenance d’application mobile.
Concrètement pour nos clients : sur des produits que nous suivons dans la durée, comme Noula (covoiturage) ou SmiileCard (bons plans géolocalisés), la vie de l’application est rythmée par des sujets que personne n’avait inscrits au cahier des charges : une brique de cartographie qui change de conditions, une règle de store qui évolue, un nouveau format d’écran à absorber. D’expérience, nous conseillons de prévoir un budget annuel de maintenance de l’ordre de 15 à 20 % du coût de build. Ce n’est pas une donnée officielle, c’est notre ordre de grandeur d’agence, calibré sur des projets réels. Il monte si l’application dépend de beaucoup de services tiers, il descend si elle est simple et autonome.
Les deux postes que personne ne budgète
Le support utilisateur
Dès que votre application a des utilisateurs, elle a des questions. Un mot de passe oublié, un paiement qui n’aboutit pas, un avis à une étoile posté un dimanche soir. Quelqu’un doit répondre, et ce quelqu’un coûte du temps, en interne ou en prestation. Une application grand public génère bien plus de sollicitations qu’un outil métier utilisé par des collaborateurs formés.
Le marketing, sans lequel personne ne télécharge
Une application ne se découvre pas toute seule. Publier sur les stores n’est pas une stratégie d’acquisition, c’est une formalité de distribution. Entre le travail de la fiche store, l’acquisition payante, le contenu et l’animation de la base d’utilisateurs, le marketing pèse souvent autant que le développement sur l’année un. Sur les projets grand public que nous accompagnons, c’est la ligne dont l’absence tue le plus sûrement un bon produit, et celle qui manque le plus souvent quand on calcule le coût total d’une application mobile.
Construire un budget sur 3 ans : la méthode
Plutôt que des montants sortis de nulle part, nous raisonnons en pourcentage du budget de build, poste par poste. Chaque projet ajuste ces curseurs, mais la structure, elle, ne change pas.
| Poste | Année 1 | Années 2 et 3 | Logique de calcul |
|---|---|---|---|
| Build de la V1 | 100 % du budget de référence | Néant | Le devis de développement, périmètre figé |
| Comptes développeurs | Apple 99 $/an + Google 25 $ une fois | Apple 99 $/an | Montants officiels publics |
| Hébergement, API, back-office | Abonnement mensuel, faible au démarrage | Croît avec le nombre d’utilisateurs | Modéliser deux scénarios d’audience |
| Services tiers | Souvent sous les seuils gratuits | Facturation à l’usage ou à la transaction | Un tarif à vérifier par brique intégrée |
| Maintenance corrective et adaptative | Partiellement couverte par la garantie | Ordre de grandeur : 15 à 20 % du build par an | Imposée par les montées de version |
| Évolutions fonctionnelles | À arbitrer après les premiers retours | Enveloppe décidée, pas subie | Priorisée par la valeur d’usage |
| Support utilisateur | Montée en charge progressive | Proportionnel au nombre d’utilisateurs actifs | Temps homme, interne ou externalisé |
| Marketing et acquisition | Le pic, au lancement | Entretien et réactivation | Dépend du modèle : grand public ou métier |
La méthode tient en quatre gestes. Chiffrer le build avec un périmètre écrit, ce que notre simulateur de devis d’application mobile permet de dégrossir. Lister les briques externes une par une, avec en face le modèle de facturation de chacune. Appliquer un pourcentage annuel de maintenance à ce build, multiplié par trois. Ajouter enfin les deux lignes humaines, support et marketing, avec un chiffre assumé même modeste. Un budget à trois ans qui ne comporte que la première ligne n’est pas un budget, c’est un espoir.
Questions fréquentes sur le coût total d’une application mobile
Quel est le coût total d’une application mobile sur 3 ans ?
Il n’existe pas de réponse universelle, et méfiez-vous de qui vous en donne une sans avoir vu votre périmètre. Le raisonnement est additif : le build, puis les comptes stores, l’infrastructure, les services tiers, la maintenance annuelle, les évolutions, le support et le marketing. Une application simple et autonome coûte peu à entretenir. Une application branchée sur des services facturés à l’usage coûte davantage, et cette différence se joue à la conception.
La maintenance est-elle vraiment obligatoire ?
Oui, dans les faits. Apple impose de compiler avec un SDK récent pour soumettre une mise à jour, et Google impose de cibler un niveau d’API récent sous peine de restreindre la visibilité de l’application sur les appareils modernes. Une application figée reste installée chez ceux qui l’ont déjà, mais elle se dégrade et finit par disparaître des radars.
Comment estimer le budget de départ avant de parler des trois ans ?
En posant d’abord le périmètre fonctionnel, puis en le chiffrant fonctionnalité par fonctionnalité. Notre article sur combien coûte une application et comment estimer son prix explique la logique poste par poste. Le budget pluriannuel se construit ensuite par-dessus, en pourcentage de ce premier chiffre.
Peut-on réduire le coût de possession d’une application ?
Oui, et cela se décide avant la première ligne de code. Limiter le nombre de briques tierces payantes, choisir une architecture sobre, mutualiser le code entre iOS et Android, éviter les fonctionnalités décoratives qu’il faudra maintenir pendant trois ans : chacune de ces décisions allège la facture des années suivantes. Un cadrage sérieux coûte quelques jours et fait économiser des mois.
Vous voulez un budget qui tient sur trois ans, pas seulement sur trois mois ? Nous chiffrons le build et la vie de votre application dans le même document, avec les hypothèses écrites noir sur blanc.
Parler de mon projet Estimer mon budget