Combien coûte la publication d'une app sur App Store et Google Play ?

Ce que couvrent les frais officiels

Les frais officiels donnent accès aux plateformes. Apple demande une adhésion annuelle à son programme développeur et Google Play demande une inscription unique à la console. Ces frais permettent de distribuer une app, mais ils ne créent pas les captures, ne rédigent pas la fiche, ne testent pas les paiements, ne remplissent pas les formulaires de confidentialité et ne répondent pas à une review négative.

C'est pour cela qu'un devis doit préciser le périmètre. Un simple upload de fichiers prêts n'a pas la même valeur qu'un accompagnement de lancement avec audit de build, préparation de la fiche, accès de test, suivi de review, correction et nouvelle soumission si nécessaire.

Ce qu'un vrai service de publication inclut

Pour une MVP simple, le travail couvre souvent le compte développeur, l'identifiant d'app, l'icône, les captures, le nom, la description, la catégorie, la classification d'âge, l'URL de support, l'URL de confidentialité, les notes de version et les instructions données au reviewer.

Pour une application commerciale, il faut aussi gérer TestFlight ou les pistes de test Google Play, vérifier les crashes, les événements d'analytique, les notifications, les abonnements, les paiements, les données d'exemple et l'environnement de production. Si l'app contient réservations, cours, commandes, messagerie privée, admin-panel ou plusieurs rôles, le parcours de test doit être préparé.

Pourquoi le prix varie

Le coût dépend surtout du niveau de préparation. Une build stable, avec un scénario principal clair, coûte moins cher à publier. Une app qui dépend encore d'un serveur de test, de captures obsolètes, d'un login fragile ou de textes de store trop ambitieux demandera plus d'efforts.

Quand publier soi-même

Vous pouvez gérer la publication en interne si l'app est simple, si les comptes appartiennent déjà à l'entreprise, si la build a été testée, si les scénarios sensibles sont absents et si quelqu'un peut répondre rapidement aux stores. Dans ce cas, une revue finale de checklist peut suffire.

Le risque augmente quand la personne qui envoie l'app ne connaît pas vraiment le produit. Le reviewer peut avoir besoin d'une réservation exemple, d'un panier, d'un itinéraire de livreur, d'un accès premium, d'un module de cours ou d'un rôle administrateur. Sans ce contexte, une app fonctionnelle peut sembler vide.

Quand l'accompagnement vaut le coût

Un accompagnement est utile si le lancement conditionne des ventes, une campagne, un partenariat, une levée de fonds, une franchise ou un engagement client. Il est aussi pertinent avec abonnements, marketplace, géolocalisation, données privées, santé, modération, paiements ou intégrations CRM et ERP.

Chez Appfyl, nous considérons la publication comme une partie du lancement produit. Quand nous développons l'app, la première version publique doit correspondre au périmètre, au plan de test et à la fiche store. Quand nous auditons une app existante, nous vérifions build, comptes, confidentialité, analytique et assets avant d'annoncer une date réaliste.

Ce qu'il faut préparer pour un devis

Préparez l'état de la build, les plateformes prévues, le propriétaire des comptes, la politique de confidentialité, l'URL de support, les captures, le texte de la fiche, les identifiants de test et une description courte du parcours principal. Pour les paiements, indiquez s'il s'agit de contenu numérique, de biens physiques, de services, de réservations ou de transactions entre utilisateurs.

Décidez aussi des pays et langues du premier lancement. Une localisation de fiche peut être une simple adaptation ou un vrai chantier de conversion avec captures locales, devise, moyens de paiement, preuves de confiance, support et textes juridiques.

Ajoutez aussi ce qui n'est pas encore prêt. C'est souvent le point le plus utile du brief. Si les captures sont provisoires, si la politique de confidentialité doit être relue, si les produits d'abonnement ne sont pas créés ou si le backend tourne encore sur un environnement de test, dites-le dès le départ. Le devis sera plus fiable, et l'équipe pourra séparer ce qui bloque la review de ce qui peut attendre une version suivante.

Si l'application a déjà été refusée, envoyez le message complet de review, la build concernée, les identifiants utilisés et la liste des corrections déjà faites. Une capture isolée ne suffit pas toujours. Il faut comprendre si le problème vient de la fiche, du parcours de test, d'une règle de paiement, d'un crash ou d'une vraie fonctionnalité manquante.

Le travail caché

Les retards viennent souvent d'incohérences. La fiche promet une fonction absente. Les captures montrent une ancienne interface. Le formulaire de confidentialité oublie un SDK. Le login empêche le reviewer d'entrer. Un abonnement fonctionne en test mais pas en production. L'URL de support mène à une page vide.

Le lancement continue après l'approbation. Il faut suivre crashes, événements, paiements, avis et messages de support. Une publication est réellement terminée quand les premiers utilisateurs accomplissent l'action principale sans intervention manuelle.

Pensez aussi à la responsabilité après le premier release. Qui peut envoyer une nouvelle build ? Qui met à jour les captures et les notes de version ? Qui répond aux avis ? Qui vérifie qu'une nouvelle version d'iOS ou d'Android ne casse pas le login, les notifications ou les paiements ? Ces décisions semblent secondaires, mais elles évitent qu'une app publiée devienne difficile à maintenir.

Questions fréquentes