Le coût réel d'une application mobile après lancement

Un compte développeur Apple coûte 99 USD par an, un compte Google Play 25 USD une seule fois (Apple, 2026 ; Google Play Console Help, 2026). Ce sont les deux seuls chiffres simples du sujet. Tout le reste du coût d'une application arrive après la mise en ligne, ne dépend pas de votre feuille de route, et se déclenche même si personne n'ouvre l'application.

Ce que vous payez même si personne n'ouvre l'application

Deux frais existent indépendamment de l'usage. L'adhésion au Apple Developer Program est de 99 USD par an, renouvelable : elle ne s'achète pas une fois, elle se reconduit. L'inscription Google Play est de 25 USD, réglée une seule fois à la création du compte. Une application publiée sur les deux stores coûte donc 99 USD par an de manière permanente, avant la moindre ligne de code.

Ce montant n'a rien de dramatique. Ce qui l'est davantage, c'est ce qu'il implique : si l'adhésion Apple expire, l'application disparaît de l'App Store. Je remarque souvent que ce renouvellement est rattaché à la carte bancaire d'une personne qui a quitté l'entreprise depuis. C'est le genre de détail administratif qui retire un produit de la vente sans qu'aucune décision n'ait été prise.

Une distinction mérite d'être notée ici : les 25 USD de Google achètent un compte définitivement, tandis que les 99 USD d'Apple sont un abonnement au fait de rester publié. L'un est un achat, l'autre un loyer.

Le cycle annuel qui fixe votre budget de maintenance

Le vrai moteur du coût récurrent n'est pas Apple, c'est le calendrier des versions d'Android. Google impose un niveau d'API cible minimum, et il monte chaque année. Aujourd'hui, les nouvelles applications et les mises à jour doivent viser Android 16 (API 36), et les applications existantes doivent atteindre Android 15 (API 35) au 31 août 2026, avec une prolongation possible jusqu'au 1^er novembre 2026 (Google Play Console Help, 2026).

Le point le plus important est que cette échéance ne dépend pas de vous. Elle ne tient compte ni de votre budget de l'année, ni de vos priorités produit, ni du fait que l'application fonctionne parfaitement. Une application livrée en janvier a une dette de mise à jour datée avant même sa première mise en ligne.

En pratique, cela transforme la maintenance en ligne budgétaire annuelle plutôt qu'en imprévu. C'est aussi la première ligne coupée en négociation, ce qui explique une bonne part des applications qui deviennent injoignables au bout de deux ou trois ans. J'en parle plus longuement dans une application mobile s'entretient comme une voiture.

Ce qui arrive concrètement si vous ne faites rien

Les deux stores sanctionnent l'inaction, mais différemment, et la différence essentielle tient à leur visibilité. Google ne retire rien : il cesse simplement de vous montrer. Rien ne casse, aucun message n'arrive, et les installations baissent sur les appareils les plus récents — c'est-à-dire ceux que les gens achètent en ce moment.

Le texte de Google est explicite : les applications sous le niveau requis "stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level" (Google Play Console Help, 2026).

Apple procède à l'inverse, avec un préavis. Une application qui n'a pas été mise à jour depuis 3 ans et qui n'atteint pas un seuil minimal de téléchargements reçoit un avertissement, puis dispose de 90 jours pour soumettre une mise à jour avant retrait (Apple App Store Improvements, 2026). Les deux conditions sont cumulatives : une application peu mise à jour mais réellement utilisée ne tombe pas sous cette règle.

La sanction Google est donc la plus coûteuse des deux, précisément parce qu'elle est silencieuse. Personne ne vous prévient qu'une source d'installations s'est refermée.

Le coût sectoriel que personne ne chiffre au départ

Certains secteurs ajoutent une contrainte qui se décide pendant l'architecture, pas pendant le développement — et qui coûte cher lorsqu'elle est découverte tard. La santé en est l'exemple le plus net en France, parce que la règle porte sur l'endroit où vivent les données, et pas sur la façon dont l'application est écrite. Changer d'hébergeur après coup revient donc à rouvrir des choix faits au premier jour.

Toute structure hébergeant des données de santé à caractère personnel recueillies lors d'activités de prévention, de diagnostic, de soins ou de suivi médico-social doit passer par un hébergeur certifié HDS. La certification est délivrée après un audit en deux étapes, vaut 3 ans, et s'accompagne d'audits de surveillance annuels (Agence du Numérique en Santé, 2026 ; décret 2018-137 du 26 février 2018).

Le coût réel n'est pas le prix de l'hébergement. C'est que la liste d'hébergeurs éligibles est courte, donc le choix technique est contraint dès le premier jour. Une application santé conçue sans cette contrainte puis mise en conformité après coup se paie en réécriture, pas en abonnement.

Ce qui décide vraiment du budget

En résumé : les frais de compte sont négligeables, la maintenance imposée est annuelle et datée, et les contraintes sectorielles se décident au début. Aucun de ces trois postes ne dépend du nombre de fonctionnalités que vous construisez, ce qui explique pourquoi deux applications au budget de départ identique peuvent coûter du simple au double la troisième année.

Ce qui en dépend, en revanche, c'est la surface à maintenir. Chaque fonctionnalité livrée devient une chose à retester à chaque version d'iOS et d'Android. C'est l'argument le plus solide en faveur d'une V1 courte, et il est budgétaire avant d'être esthétique — le sujet du piège du cahier des charges.

Un chiffre pour situer l'enjeu : sur 2 200 applications et 1,3 milliard d'installations, 46,1 % des installations Android ont été désinstallées en moins de 30 jours, la majorité dès le premier jour (AppsFlyer, 2025). Payer pour maintenir des fonctionnalités que personne n'a gardées assez longtemps pour voir est la dépense la plus courante et la moins visible de ce métier.

Questions fréquentes

Quel est le coût minimum pour garder une application en ligne ?

99 USD par an pour l'App Store, et rien de récurrent côté Google Play après les 25 USD initiaux (Apple, 2026 ; Google Play Console Help, 2026). À cela s'ajoute au minimum une mise à jour technique par an pour suivre le niveau d'API cible d'Android. Une application sans budget de maintenance reste en ligne, mais devient progressivement invisible sur les appareils récents.

Que se passe-t-il si je ne mets jamais l'application à jour ?

Sur Google Play, elle cesse d'apparaître pour les utilisateurs dont l'appareil tourne sur une version d'Android plus récente que votre cible. Sur l'App Store, elle peut être retirée après 3 ans sans mise à jour si elle n'atteint pas non plus un seuil minimal de téléchargements, avec 90 jours de préavis pour réagir (Apple, 2026). Les utilisateurs qui l'ont déjà installée la conservent.

Un refus de l'App Store coûte-t-il du temps ?

Apple indique examiner 90 % des soumissions en moins de 24 heures (Apple App Review, 2026). Une soumission propre passe donc généralement le lendemain. Un refus renvoie en fin de file, et un cycle correction puis resoumission transforme couramment un jour d'attente en quatre ou cinq. Le coût d'un refus est un délai, rarement un montant.

Le budget d'une application ne se joue donc pas au moment du devis, mais à deux endroits qu'on regarde rarement : le calendrier imposé par les stores, et le nombre de fonctionnalités qu'il faudra retester chaque année. Le premier ne se négocie pas. Le second, si — au même titre que le choix de sortir sur une ou deux plateformes.