Publier une application sur l'App Store et Google Play : prix, délais, refus

Le code est fini, l’application tourne sur votre téléphone, et c’est souvent là que le calendrier dérape. Entre la fin du développement et le premier téléchargement se glissent des comptes à ouvrir, des déclarations à remplir et deux examens qui ne se négocient pas. Voici une première publication de bout en bout, selon les règles d’Apple et de Google en vigueur en octobre 2026, telle que nous la menons en développement d’application mobile.

Combien coûte la publication d’une application sur l’App Store et Google Play ?

Publier une application coûte 99 $ par an pour le programme Apple Developer et 25 $ une seule fois pour un compte Google Play Console. Le numéro D-U-N-S exigé des entreprises est gratuit. Ce sont les seuls frais obligatoires : tout le reste du budget de publication est du travail, pas un droit d’entrée.

Apple fixe son adhésion à 99 USD, affichés en devise locale à l’inscription ; Google demande 25 USD en versement unique. Soit 124 $ de frais fixes la première année, puis 99 $ par an. Le reste diffère d’un store à l’autre :

Faut-il un compte d’entreprise pour publier une application ?

Oui, dès que l’application porte une activité professionnelle. Un compte d’organisation affiche le nom de votre société comme éditeur, vous dispense du test fermé imposé aux nouveaux comptes Google personnels et reste à l’entreprise quand les personnes changent. Il demande en échange un numéro D-U-N-S, à obtenir avant toute inscription.

Le numéro D-U-N-S est un identifiant d’entreprise à neuf chiffres, attribué gratuitement par Dun & Bradstreet, qui permet à Apple et à Google de vérifier l’existence, le statut juridique et l’adresse d’une société. Beaucoup d’entreprises en ont déjà un sans le savoir : il se vérifie en ligne avant d’en demander un nouveau.

Côté Apple, l’aide officielle sur le D-U-N-S annonce jusqu’à 5 jours ouvrés pour recevoir le numéro, puis jusqu’à 2 jours ouvrés avant qu’Apple ne le reconnaisse. La personne qui inscrit la société doit pouvoir l’engager juridiquement. Google exige lui aussi le D-U-N-S pour tout compte d’organisation, et impose ce type de compte aux applications financières, de santé ou publiques.

Un compte personnel paraît plus rapide. Il coûte plus cher, pour quatre raisons :

• Votre nom remplace celui de l’entreprise comme vendeur sur l’App Store.
• Vos coordonnées deviennent publiques. Le règlement européen sur les services numériques oblige Apple à afficher celles des professionnels : en compte individuel, votre adresse, votre téléphone et votre e-mail.
• Google impose un test fermé de 14 jours avec 12 testeurs aux comptes personnels créés après le 13 novembre 2023.
• Le compte suit la personne. Ouvert par un freelance ou un salarié qui part, il rend chaque mise à jour dépendante de lui.

Et si c’est un prestataire qui développe l’application ?

Apple a prévu le cas : la société s’inscrit au programme, invite le développeur dans son équipe et apparaît comme vendeur. Dans la Play Console aussi, le titulaire du compte invite des utilisateurs et choisit leurs droits.

Chez Krafter, c’est la règle. Les comptes développeur sont ouverts au nom de votre société, nous y sommes invités pendant le projet, et en fin de projet tout est mis à votre nom, sauf la stack open source. Un compte au nom du prestataire devient un verrou le jour où vous changez d’équipe ou levez des fonds, exactement comme pour la propriété du code de votre logiciel.

Combien de temps faut-il pour publier une application sur les stores ?

Comptez 8 à 12 semaines entre le lancement d’un MVP mobile et sa présence sur les stores, dont 4 à 8 semaines de développement. Les étapes propres aux stores tiennent en quelques jours si elles sont anticipées. Les vrais risques de retard sont le numéro D-U-N-S, la vérification des comptes et le test fermé de Google.

Le parcours d’une première publication, dans l’ordre :

1. Vérifiez ou demandez le numéro D-U-N-S le premier jour. Sans lui, aucun compte d’entreprise ne s’ouvre.
2. Ouvrez les deux comptes au nom de la société. Apple vérifie l’organisation avant de faire payer l’adhésion ; Google valide l’e-mail et le téléphone par code à usage unique.
3. Testez sur de vrais appareils pendant le développement. TestFlight est l’outil d’Apple qui distribue une version de test à des testeurs invités par e-mail ou par lien public, sans passer par l’App Store. Le test interne de Google joue le même rôle.
4. Lancez le test fermé si votre compte Google est personnel et récent. Le test fermé est un canal de la Play Console qui distribue l’application à un groupe de testeurs choisis et contrôlés par le développeur, avant sa mise en ligne publique. L’aide de la Play Console exige 12 testeurs inscrits sans interruption pendant 14 jours, puis une demande d’accès en production, examinée en général en une semaine ou moins. Soit jusqu’à trois semaines incompressibles.
5. Préparez les fiches et les déclarations. Captures de l’application en usage, politique de confidentialité, fiche de confidentialité, questionnaire d’âge, statut de professionnel européen et compte de démonstration pour l’examinateur.
6. Soumettez à l’examen. Selon la page App Review d’Apple, au moins 50 % des soumissions sont examinées en moins de 24 heures et 90 % en moins de 48 heures. Google prévient que l’examen peut durer plus longtemps pour certains comptes.
7. Publiez tout de suite ou à la date choisie. Apple permet de programmer la sortie, Google propose la publication gérée.

Sur Melimelo, notre application Flutter d’organisation du foyer, plus de 50 versions sont passées par ce circuit, avec une review Apple en 1 à 2 jours en général. Flutter, le framework de Google, produit iOS et Android depuis une seule base de code, mais chaque version passe deux examens distincts.

Pourquoi une application est-elle refusée par Apple ou Google ?

Une application est d’abord refusée parce qu’elle est incomplète. Selon Apple, plus de 40 % des problèmes non résolus en review relèvent de la règle 2.1, qui couvre les plantages, les contenus provisoires et les informations manquantes. Viennent ensuite la confidentialité, les comptes et les paiements. Presque tous ces refus s’évitent avant l’envoi.

Attention au chiffre qui circule : Apple n’écrit pas que 40 % des applications sont refusées, mais que plus de 40 % des problèmes non résolus touchent à l’exhaustivité. Le refus sanctionne un dossier incomplet, pas une idée.

Deux fiches reviennent dans les refus liés aux données. Les informations de confidentialité d’Apple sont un questionnaire d’App Store Connect qui décrit les données collectées par l’application et par ses SDK tiers, ces briques fournies par d’autres éditeurs, exigé pour toute nouvelle application et toute mise à jour. La section Sécurité des données de Google Play est son équivalent, obligatoire même pour une application qui ne collecte rien.

Les causes de refus qui reviennent d’un projet à l’autre, et la parade :

• Un plantage ou du contenu provisoire. Textes de remplissage, liens morts, écran vide : seules les versions finales, testées sur appareil, passent.
• Un examinateur bloqué à la connexion. Fournissez des identifiants de démonstration valides et laissez le serveur allumé pendant l’examen.
• Une politique de confidentialité absente ou vague. Accessible dans l’application et sur la fiche, elle dit quelles données sont collectées, avec qui elles sont partagées et comment en demander la suppression.
• Une permission sans explication. Chaque accès à l’appareil photo, à la position ou aux contacts doit dire à quoi servira la donnée.
• Aucune suppression de compte. Une application qui permet de créer un compte doit permettre de le supprimer depuis l’application, avec en plus un lien web chez Google. Chez Apple, une désactivation ne suffit pas.
• Une connexion Google ou Facebook sans alternative. Apple exige alors une option équivalente qui limite la collecte au nom et à l’e-mail et permet de masquer l’adresse.
• Un site web dans une coquille. Afficher un site existant ne suffit pas : c’est un refus pour fonctionnalité insuffisante, au titre de la règle 4.2.
• Un contenu numérique vendu hors achat intégré. L’achat intégré est le système de paiement d’Apple intégré à l’application, obligatoire pour débloquer un contenu ou une fonctionnalité numérique comme un abonnement. Un service physique se paie au contraire par carte ou Apple Pay.
• Une fiche fausse ou la mauvaise entité. Captures qui ne montrent pas l’application en usage, déclaration qui contredit son comportement, application bancaire ou de santé soumise par une autre entité que celle qui fournit le service, ou application issue d’un service de génération que le propriétaire du contenu ne soumet pas lui-même (règle 4.2.6).

Si votre application a été développée ailleurs et bute sur un refus, un audit de reprise dit ce qui bloque et chiffre la correction avant d’y toucher.

Que coûte une publication réussie, au-delà des frais de compte ?

Au-delà des 124 $ de la première année, une publication réussie coûte du travail : fiches et captures, déclarations de confidentialité, suppression de compte, compte de démonstration, tests sur appareils et suivi de l’examen. Chez Krafter, ce travail est compris dans le prix d’un MVP mobile, entre 6 000 et 25 000 € HT.

Le bas de la fourchette suppose un besoin défini : processus, règles métier et écrans posés avant le premier jour. Il tient à un socle open source qui évite de tout réécrire à chaque projet, à deux associés seniors qui s’appuient sur l’IA puis relisent et testent chaque ligne, et à l’absence de couche commerciale entre vous et eux. S’il faut construire le besoin avec vous, le cadrage ajoute 3 000 à 6 000 € HT.

Scénario type : une PME de services veut une application de prise de rendez-vous pour ses clients ; le besoin est défini, le MVP mobile est chiffré à 15 000 € HT. Le premier jour, le dirigeant vérifie le numéro D-U-N-S de sa société, ouvre les deux comptes au nom de la société et y invite le studio. Pendant le développement, les comptes sont vérifiés et l’application intègre suppression de compte, politique de confidentialité et compte de démonstration. Les deux examens passent sans test fermé : l’application est en ligne dans la fenêtre des 8 à 12 semaines, pour 15 000 € HT, 124 $ de comptes et 1 200 à 1 800 € HT de maintien par an. Avec un compte Google personnel ouvert à la dernière minute, le même projet aurait perdu jusqu’à trois semaines et affiché le nom du dirigeant.

Pour le prix de l’application elle-même, poste par poste, voyez combien coûte une application mobile pour son entreprise.

Quelles obligations reviennent chaque année après la publication ?

Trois obligations reviennent chaque année : renouveler l’adhésion Apple à 99 $, compiler l’application avec la version d’Xcode exigée chaque printemps, et cibler le niveau d’API Android imposé par Google chaque 31 août. Sans elles, l’application reste installée chez ses utilisateurs, mais plus aucune mise à jour ne passe.

L’adhésion Apple est la ligne la plus bête à rater : si elle expire, l’application n’est plus téléchargeable et aucune mise à jour ne peut être envoyée. Seul le titulaire du compte peut la renouveler, une raison de plus pour que ce soit votre société.

Depuis le 28 avril 2026, Apple exige Xcode 26 et le SDK d’iOS 26 pour tout envoi. Depuis le 31 août 2026, Google Play refuse toute nouvelle application et toute mise à jour qui ne cible pas Android 16. Nous détaillons les conséquences et la marche à suivre dans l’article sur l’obligation Android 16.

Les déclarations vivent aussi avec l’application : Apple et Google demandent de les tenir exactes, et un nouveau SDK de statistiques ou de paiement suffit à rendre une fiche fausse.

Ce suivi a un prix connu d’avance : le maintien en conditions, budgété à 8 à 12 % du développement par an, puis les évolutions au temps passé, entre 700 et 1 100 € HT par jour.

Faut-il toujours publier son application sur les stores ?

Non. Une application interne, utilisée par vos équipes, n’a souvent rien à gagner aux stores : une PWA s’installe depuis le navigateur, sans compte développeur, sans examen et sans test fermé. Les stores s’imposent quand l’application vise le grand public, vend un service ou dépend de notifications fiables et d’un accès complet au téléphone.

Une PWA, ou application web progressive, est une application web installable sur l’écran d’accueil du téléphone, qui se met à jour sans passer par un store et fonctionne sur iPhone comme sur Android. Trottr, notre SaaS de gestion d’interventions terrain utilisé notamment par Engie, est une PWA : pas de fiche, pas d’examen. Pour un outil interne réservé à quelques utilisateurs, ne nous demandez pas une application sur les stores : nous vous orienterons vers le développement d’une PWA.

Si votre application doit aller sur les stores, trois gestes cette semaine lancent le chantier. Vérifiez si votre société a déjà un numéro D-U-N-S. Décidez qui sera titulaire des comptes : votre société, pas votre prestataire. Listez les données que votre application collecte. Pour un chiffrage et un calendrier réalistes, parlez-nous de votre application : un des deux associés vous répond, avec un avis franc sur ce qui doit passer par les stores et ce qui peut s’en passer.