Le compteur tourne. Vous avez passé six mois sur votre app, vous l'avez testée sur le téléphone de trois amis, et là, devant App Store Connect, vous bloquez. Pas sur le code. Sur l'administratif. Le certificat de distribution, le profil de provisionnement, la fameuse « build signée », le compte de démo à fournir au reviewer coréen qui va l'ouvrir à 4 h du matin.
Franchement, personne ne vous prévient : publier son application sur les stores Android et iOS prend plus de temps que les derniers 20 % de développement. Sur mon dernier projet, une app de suivi d'entraînement, j'ai mis onze jours à passer de « ça marche sur mon iPhone » à « c'est en ligne sur les deux stores ». Trois de ces journées, je les ai perdues sur un rejet Apple que j'aurais pu éviter en lisant une seule ligne de documentation.
Points clés à retenir
- Apple facture 99 $ par an (compte développeur), Google 25 $ une seule fois à vie.
- Les nouveaux comptes Google Play personnels doivent passer par 20 testeurs pendant 14 jours avant toute publication en production.
- Google Play exige un App Bundle (.aab), plus un APK classique, pour toute nouvelle app.
- Apple impose un compte de démo fonctionnel si votre app a une connexion, sinon rejet quasi systématique.
- Comptez 1 à 3 jours de review côté Google, 24 à 72 h côté Apple — plus en période de fêtes.
Publier sur Android et iOS, ce sont deux chantiers différents
Il y a un réflexe naturel qui coûte cher : croire qu'une fois votre app finie, « il ne reste qu'à la mettre en ligne ». Faux. Les deux plateformes n'ont ni la même logique, ni les mêmes pièges, ni le même rythme.
Côté Google Play Console : le parcours du testeur obligatoire
Vous créez votre compte développeur, vous payez 25 $, et vous pensez pouvoir publier dans la foulée. Raté, du moins pour un compte personnel récent. Google impose une phase de test fermé : il vous faut au minimum 12 testeurs inscrits pendant 14 jours consécutifs avant de pouvoir demander l'accès à la production (le seuil a longtemps été de 20, il a été abaissé, vérifiez l'état actuel dans la console car ça bouge).
Concrètement, ça veut dire trouver douze humains qui installent votre app via un lien, la gardent deux semaines, et ne la désinstallent pas. J'ai perdu une semaine sur ce point parce que deux testeurs avaient désinstallé après trois jours — le compteur s'est réinitialisé. Leçon : recrutez large, visez 20 personnes pour être tranquille.
Côté App Store Connect : le reviewer humain
Apple ne vous impose pas de phase de test publique, mais le contrôle est humain. Un vrai type ouvre votre app, la manipule, et décide. C'est là que 80 % des débutants se font recaler.
Les motifs de rejet que je vois le plus souvent, dans mon expérience et celle des devs avec qui j'échange :
- Guideline 2.1 — plantage ou bug : l'app crash au démarrage chez le reviewer, souvent parce qu'une API dépend d'une région géographique ou d'un compte spécifique.
- Guideline 4.3 — spam : votre app ressemble trop à une autre (template acheté, clone de jeu hyper-casual).
- Absence de compte de démo : si votre app demande une connexion, vous devez fournir des identifiants fonctionnels dans les notes de review. Un compte vide, c'est un rejet.
Détail qui tue : Apple vous envoie le motif de rejet dans Resolution Center, et vous avez le droit de répondre, argumenter, redéployer. Ce n'est pas définitif. Beaucoup abandonnent au premier refus alors qu'une simple réponse texte suffit parfois à débloquer.
Combien ça coûte vraiment ?
| Plateforme | Frais | Type | Renouvellement |
|---|---|---|---|
| Apple App Store | 99 $ | Abonnement | Chaque année |
| Google Play Store | 25 $ | Paiement unique | Aucun |
Non, il n'existe pas de contournement officiel pour publier gratuitement. Les deux stores facturent l'accès développeur, point. Les comptes « gratuits » que vous croisez sur YouTube sont soit des tutoriels pour tester en local, soit des histoires d'entreprise avec un compte organisation déjà payé.
Si vous n'avez pas les moyens, une stratégie pragmatique : commencez par Android. 25 $ une fois, pas de renouvellement, et vous validez votre concept. iOS viendra quand vous aurez vos premiers utilisateurs — et éventuellement vos premiers revenus pour payer les 99 $.
La checklist que j'aurais aimé avoir avant ma première soumission
Préparer les builds
Sur Android, oubliez l'APK pour la publication : Google exige un App Bundle (.aab), qui est essentiellement un APK découpé par architecture et densité d'écran. Votre build doit être signé avec une clé que vous conservez précieusement (Play App Signing peut gérer la clé de distribution, mais gardez votre clé d'upload en lieu sûr — si vous la perdez, c'est la galère).
Sur iOS, vous générez une archive via Xcode, vous la validez, vous l'envoyez sur App Store Connect. Comptez 10 à 30 minutes de traitement avant qu'elle apparaisse dans la section « Build » — parfois plus. J'ai déjà vu une build mettre deux heures un dimanche soir.
Soigner la fiche produit
Titre sous 30 caractères, sous-titre sous 30, description qui parle au bénéfice utilisateur et pas à la feature. Captures d'écran aux formats imposés par chaque store (Apple varie selon les tailles d'écran, Google accepte plusieurs ratios). Icône en 1024×1024 sans transparence pour Apple.
Ce qui m'a coûté le plus de temps : la politique de confidentialité. Elle est obligatoire sur les deux stores si votre app collecte quoi que ce soit — même juste une adresse email. Héberger un simple fichier HTML sur un GitHub Pages suffit, mais il faut le lien.
Combien de temps avant que ce soit en ligne ?
Les chiffres que j'ai observés sur mes dernières livraisons :
- Google Play : 1 à 3 jours en moyenne, jusqu'à 7 pour un compte tout neuf.
- App Store : 24 à 72 heures en temps normal, parfois 12 h si le reviewer est de bonne humeur.
- Périodes à éviter : fin décembre, la semaine du nouvel an lunaire, le jour d'une keynote Apple.
Si votre app est bloquée plus de 5 jours côté Apple sans réponse, vous pouvez demander une accélération via le formulaire de contact développeur. Je l'ai fait une fois, ça a débloqué en 4 h. Pas systématique, mais ça vaut le coup quand vous êtes coincé.
Les erreurs que je referais deux fois plutôt que trois
La première : publier sans compte de démo. Rejet en 6 h. La deuxième : mettre une version iOS minimale trop ancienne alors que je n'utilisais que des API récentes — l'app plantait chez le reviewer et pas chez moi. La troisième : oublier de cocher la déclaration d'usage des données de confidentialité chez Apple, ce qui a rallongé la review de deux jours.
Il y a aussi un truc bête que je vois souvent : la version « test » publiée en production par erreur. Toujours vérifier la version que vous soumettez, pas celle qui traîne dans votre IDE. Et côté RGPD, si vous visez le marché européen, votre fiche de confidentialité doit refléter ce que vous faites réellement des données — pas un copier-coller générique.
Une fois publié, le plus dur commence
Le jour où vous voyez votre app apparaître dans le store, il y a un petit vertige. Et puis le lendemain, c'est fini. Personne ne l'a téléchargée. L'algorithme des stores ne fait rien pour vous : il n'y a pas d'ascenseur magique, il y a des mises à jour régulières, une note moyenne qui compte énormément, et des avis auxquels vous répondez.
La question qui reste, et que je n'ai pas résolue moi-même après plusieurs apps : est-ce que le jeu en valait la chandelle, ou est-ce qu'une web app bien foutue vous aurait rendu le même service pour zéro dollar de frais et zéro rejet ? La réponse honnête dépend de si vos utilisateurs ont un vrai besoin d'être dans un store. Si oui, vous savez maintenant à peu près ce qui vous attend. Si non, vous venez d'économiser 124 $ et plusieurs semaines d'administratif.
