Combien coûte vraiment lancer une app native sur les deux stores en 2026

On t'a dit que lancer une app coûte 25 dollars. Techniquement, ce n'est pas faux. C'est ce que Google facture, une fois, pour ouvrir un compte sur la Play Console.

Mais ce chiffre est un piège. C'est comme dire qu'ouvrir un restaurant coûte le prix de la licence municipale. La licence est réelle. Elle ne paie ni la cuisine, ni le personnel, ni le frigo qui tombe en panne au mois d'août.

Voyons ce que coûte vraiment, en 2026, poser une app native sur les deux stores et la garder en vie.

Les frais des stores sont la plus petite ligne de la liste

Apple facture 99 dollars par an pour l'Apple Developer Program. Tu ne paies pas, l'app disparaît. C'est un loyer, pas un achat.

Google facture 25 dollars, une seule fois, pour enregistrer le compte développeur sur la Play Console. Tu paies une fois dans ta vie et c'est réglé.

Au total, la première année, tu dépenses environ 124 dollars en frais officiels. Garde ce chiffre. C'est le seul coût que tout le monde connaît et le moins important de tous.

Ce sont deux apps, pas une

Voici la partie qui détruit les budgets. Quand tu dis « app native pour les deux stores », tu demandes deux produits avec deux systèmes d'exploitation, deux langages de base et deux équipes de validation aux règles différentes.

iOS, c'est Swift et Xcode. Android, c'est Kotlin et Android Studio. Des outils distincts, des cycles de build distincts, des bugs distincts. Ce que tu casses d'un côté, tu ne le casses pas de l'autre.

Des frameworks comme React Native ou Flutter promettent du code partagé. Ils aident, et on s'en sert. Mais ils n'effacent pas le problème. Il te faut toujours un Mac pour compiler vers iOS, des comptes des deux côtés et des tests sur de vrais téléphones des deux mondes. L'écran de paiement qui marche sur le Pixel plante sur l'iPhone à encoche. Toujours.

Le scénario typique est celui-ci : tu chiffres une app et tu en reçois, en pratique, une et demie. La seconde moitié apparaît quand le client ouvre la version Android et remarque que le clavier cache le champ de connexion.

Le coût qui n'apparaît sur aucune facture

Il y a des dépenses que personne ne te montre au départ parce qu'elles ne tiennent pas dans un devis propre. Ce sont elles qui séparent un projet qui vit d'un projet qui meurt au bout de trois mois.

• Validation refusée. Apple applique les App Store Review Guidelines avec une main lourde. Une permission mal justifiée, un bouton de suppression de compte manquant, et l'app repart en arrière. Chaque round, ce sont des jours à l'arrêt.
• Un Mac. Pas de build iOS sans matériel Apple. Si tu n'en as pas, c'est un achat ou un service de CI dans le cloud avec facture mensuelle.
• Notifications push. Il te faut Firebase sur Android et des certificats APNs chez Apple. Chacun casse à sa façon et se renouvelle tout seul moins souvent que tu ne le voudrais.
• Maintenance annuelle. Chaque nouvelle version d'iOS et d'Android peut casser quelque chose. Tu ne mets pas à jour, l'app se dégrade jusqu'à ne plus s'installer sur les téléphones récents.
• Conformité de la confidentialité. App Privacy chez Apple, Data Safety chez Google. Tu déclares ce que tu collectes et tu dois vraiment t'y tenir, sous le RGPD.

Alors, des chiffres honnêtes

Je ne vais pas t'inventer un montant facturé par une entreprise qui n'existe pas. Mais je peux te donner la structure de coûts qu'on voit dans des projets réels.

Frais officiels : environ 124 dollars la première année. Développement : ça dépend du périmètre, et c'est là que se trouve quatre-vingt-dix pour cent de l'argent. Maintenance : compte une fraction récurrente du coût de build, chaque année, indéfiniment.

La règle mentale que je donne aux clients est simple. Le lancement est un mariage, pas un dîner. Le coût d'entrée est la partie facile. C'est l'engagement qui pèse.

Il existe un chemin moins cher, et parfois c'est le bon

Tout n'a pas besoin d'être natif. Une Progressive Web App s'installe depuis le navigateur, tourne sur les deux systèmes avec une seule base de code et échappe aux frais et aux validations des stores. Pour beaucoup d'entreprises, ça suffit largement.

Ce que tu perds, c'est le sceau d'être dans la boutique, certains accès profonds au matériel et la confiance qu'une icône sur l'App Store inspire encore. Si ton app vend de la confiance ou a besoin de notifications push fiables sur iOS, tu voudras le natif.

La bonne question n'est pas « combien coûte un lancement sur les deux stores ». C'est « ai-je vraiment besoin des deux stores ». Réponds à ça d'abord. Tu économises plus que n'importe quelle négociation de prix.

Si quelqu'un te présente un devis d'app sans une ligne pour la maintenance, il ne cache pas le coût. Il le repousse à dans six mois, quand tu auras déjà signé.