Vous avez une application qui fonctionne sur votre téléphone, et il reste à la mettre entre les mains du public. Publier une application sur l'App Store et Google Play demande autant de préparation administrative que de technique : comptes, déclarations, visuels, tests et revue humaine. Ce guide suit l'ordre réel des opérations pour une première publication, avec ce que nous constatons chez Ship Studio sur des applications React Native mises en ligne sur les deux stores.
Publier une application sur l'App Store et Google Play : préparer l'application et créer les comptes développeur
Avant d'ouvrir la moindre console, vérifiez que l'application est dans un état « publiable ». Une version de démonstration avec des textes provisoires ou des boutons inactifs sera rejetée, surtout par Apple.
Les prérequis techniques
Quelques éléments doivent être arrêtés dès le départ, car ils sont difficiles à changer après la première publication :
- L'identifiant de l'application (bundle identifier chez Apple, nom de package chez Google) : il est unique et définitif.
- Le nom commercial : vérifiez sa disponibilité sur chaque store avant de produire vos visuels.
- Les permissions demandées (localisation, caméra, notifications) : ne conservez que celles dont l'application a réellement besoin.
- Les versions minimales supportées d'iOS et d'Android, qui conditionnent la taille de votre audience.
- Un compte de démonstration si l'accès à l'application nécessite une connexion.
Si votre application est encore en construction, notre ressource sur le développement d'une application React Native détaille les étapes qui précèdent la publication.
Créer les deux comptes développeur
Chaque store exige son propre compte. Les coûts et contraintes diffèrent sensiblement.
| Critère | Apple Developer Program | Google Play Console |
|---|---|---|
| Coût | 99 $ par an | 25 $ une seule fois |
| Outil de publication | App Store Connect | Play Console |
| Format du fichier à envoyer | Archive iOS générée avec Xcode | Android App Bundle (.aab) |
| Compte entreprise | Numéro D-U-N-S demandé | Vérification de l'organisation demandée |
| Test avant production | TestFlight | Pistes de test interne, fermé et ouvert |
Pour une société, créez le compte au nom de l'entreprise plutôt qu'à titre personnel. L'application sera affichée sous le nom de la structure, et vous évitez qu'elle reste liée à un individu si l'équipe change. Comptez quelques jours pour les vérifications d'identité ou d'organisation, notamment pour obtenir un numéro D-U-N-S si votre entreprise n'en a pas.
Gardez aussi à l'esprit une contrainte récente côté Google : les comptes personnels récents doivent passer par une phase de test fermé avec un nombre minimal de testeurs avant d'accéder à la production. Vérifiez les seuils en vigueur dans la Play Console, car ils évoluent.
Préparer les fiches App Store et Google Play
La fiche store est votre vitrine, mais aussi un document de conformité. Les relecteurs la comparent au comportement réel de l'application.
Textes, visuels et mots-clés
Rédigez en français pour le marché français, puis ajoutez d'autres langues si votre public le justifie. Les éléments à prévoir :
- Un titre court et un sous-titre ou une description courte qui disent clairement ce que fait l'application.
- Une description longue factuelle, sans promesse que l'application ne tient pas.
- Une icône lisible en petit format, sans texte superflu.
- Des captures d'écran réelles, aux dimensions exigées par chaque store. Les formats requis changent selon les appareils, consultez la documentation à jour avant de produire vos images.
- Une image de présentation pour la fiche Google Play (graphique de fonctionnalité).
- Une catégorie et, côté Apple, un champ de mots-clés limité en nombre de caractères.
Les captures doivent montrer l'application telle qu'elle est. Une capture contenant une fonctionnalité absente, ou une marque tierce sans autorisation, est un motif de rejet classique.
Politique de confidentialité et RGPD
Une politique de confidentialité accessible par une URL publique est exigée par les deux stores dès que l'application traite des données personnelles, ce qui est presque toujours le cas (compte utilisateur, e-mail, identifiant publicitaire, statistiques d'usage). Pour un public français, elle doit s'aligner sur le RGPD :
- l'identité du responsable de traitement et un contact ;
- les données collectées et la finalité de chaque collecte ;
- la base légale et la durée de conservation ;
- les droits des utilisateurs (accès, rectification, suppression) et la manière de les exercer ;
- les sous-traitants et services tiers intégrés (analytique, notifications, paiement).
Les stores demandent en plus leur propre déclaration. Apple affiche des « étiquettes de confidentialité » renseignées dans App Store Connect, Google exige le formulaire de sécurité des données. Ces déclarations doivent correspondre exactement à ce que le code fait réellement, y compris via les SDK tiers. Un écart entre la déclaration et le trafic réseau de l'application est une cause de rejet et de retrait.
Si l'application permet de créer un compte, prévoyez aussi une fonction de suppression de compte accessible depuis l'application. Les deux plateformes l'attendent.
Classification, tarification et paiements
Remplissez le questionnaire de classification par âge de manière honnête. Définissez ensuite le prix (gratuit ou payant) et les pays de distribution. Si vous vendez des contenus ou services numériques consommés dans l'application, les stores imposent en principe leur propre système d'achat intégré et prélèvent une commission. La vente de biens physiques ou de services rendus hors de l'application suit des règles différentes. Lisez ces règles avant de bâtir votre modèle économique, pas après le premier refus.
Tester l'application avant de la soumettre
Le test de pré-soumission ne remplace pas vos tests de développement : il vérifie l'application telle qu'elle sera installée depuis le store, avec la configuration de production.
TestFlight côté iOS
TestFlight permet de distribuer une version à des testeurs avant la revue publique. Vous importez le build depuis Xcode ou votre chaîne d'intégration continue, puis invitez deux types de testeurs :
- Les testeurs internes : membres de votre équipe ajoutés dans App Store Connect, qui accèdent rapidement aux builds.
- Les testeurs externes : invités par e-mail ou lien public, avec une première revue allégée de la version.
C'est le bon moment pour faire installer l'application à des personnes extérieures au projet, avec des appareils et versions d'iOS variés.
Pistes de test côté Android
La Play Console propose trois niveaux : test interne (diffusion rapide à un petit groupe), test fermé (testeurs invités) et test ouvert (accessible à qui rejoint le programme). Le test interne sert à valider que le bundle s'installe et démarre. Le test fermé reproduit un lancement restreint et, selon le type de compte, peut être obligatoire avant la production.
Ce qu'il faut vérifier systématiquement
- Le parcours complet : installation, inscription, usage principal, déconnexion, suppression de compte.
- Les cas dégradés : pas de réseau, réseau lent, permission refusée, notification désactivée.
- Les liens : politique de confidentialité, conditions d'utilisation, support, tous accessibles et sans erreur.
- Les paiements, s'il y en a, en environnement de test.
- La stabilité sur des appareils anciens et récents, en petit et grand écran.
- Les textes : aucun contenu provisoire, aucune faute évidente, aucune mention « test ».
Relevez les plantages avec un outil de suivi d'erreurs, puis corrigez avant de soumettre. Un crash au lancement pendant la revue est l'un des refus les plus rapides.
Soumettre l'application et anticiper la revue des stores
La procédure de soumission pas à pas
Côté Apple, la séquence est la suivante :
- Créez la fiche de l'application dans App Store Connect avec son identifiant.
- Envoyez le build depuis Xcode et attendez qu'il soit traité.
- Renseignez textes, captures, étiquettes de confidentialité, classification et URL de politique de confidentialité.
- Ajoutez dans les notes de revue un compte de démonstration et les explications utiles sur les fonctions non évidentes.
- Sélectionnez le build et soumettez la version pour revue.
Côté Google, la logique est proche :
- Créez l'application dans la Play Console et complétez les déclarations obligatoires (contenu, sécurité des données, public cible).
- Importez l'Android App Bundle sur la piste de production, ou d'abord sur une piste de test.
- Renseignez la fiche principale et les visuels.
- Vérifiez que l'application cible un niveau d'API Android suffisamment récent, une exigence que Google relève régulièrement.
- Envoyez la version pour examen.
Choisissez aussi le mode de mise en ligne : publication automatique après approbation ou déclenchement manuel. Pour un lancement coordonné avec une communication, le déclenchement manuel évite les surprises.
Les délais de revue
Les délais varient selon la période, le type d'application et l'historique du compte. La revue d'une première version est souvent plus longue que celle des mises à jour, et un refus relance un cycle complet. Ne fixez jamais une date de lancement publique sans marge : prévoyez de quoi absorber au moins un aller-retour avec chaque store, plus la création des comptes, qui peut elle aussi prendre plusieurs jours.
Les motifs de rejet fréquents et comment les éviter
- Plantage ou fonction inopérante pendant la revue : testez la version exacte soumise, sur un appareil réel et avec la configuration de production.
- Accès impossible au contenu : fournissez un compte de démonstration valide, avec des données exploitables.
- Métadonnées incomplètes ou trompeuses : captures conformes, description exacte, aucune mention de plateforme concurrente.
- Politique de confidentialité manquante ou incohérente : l'URL doit fonctionner et refléter les vraies collectes de données.
- Permissions non justifiées : rédigez des messages d'explication clairs et supprimez les permissions superflues.
- Fonctionnalités minimales : une application qui se limite à afficher un site web ou n'apporte aucune valeur propre risque le refus.
- Achats numériques hors système du store : respectez les règles de facturation de chaque plateforme.
- Absence de suppression de compte quand la création de compte est possible.
En cas de refus, lisez attentivement le message : il cite la règle concernée. Corrigez le point précis, répondez dans la console si une clarification suffit, ou envoyez un nouveau build. Un refus n'est pas une sanction, c'est un retour de conformité.
Après la publication : gérer les mises à jour
Le jour de la mise en ligne n'est qu'une étape. Les deux stores attendent des applications suivies, et vos premiers utilisateurs vont révéler ce que les tests n'ont pas montré.
Surveiller les premiers jours
Suivez dès le lancement les indicateurs suivants :
- les plantages et erreurs remontés par votre outil de suivi et par les consoles des stores ;
- les avis et notes, auxquels il est utile de répondre rapidement ;
- les installations, désinstallations et taux de rétention ;
- les parcours où les utilisateurs abandonnent (inscription, paiement).
Publier une mise à jour
Chaque nouvelle version suit le même circuit : incrémentez le numéro de version et de build, testez, soumettez, puis attendez la validation. Les mises à jour sont généralement plus rapides à valider que la première soumission, mais restent soumises à la revue. Rédigez des notes de version honnêtes et lisibles par vos utilisateurs.
Pour les corrections urgentes, ayez un plan : certaines équipes utilisent la mise à jour à distance du code JavaScript sur React Native pour des correctifs limités, dans le respect des règles de chaque store. Pour des changements plus profonds, une nouvelle version passe par la revue. Côté Google, la publication progressive par pourcentage d'utilisateurs permet de détecter un problème avant un déploiement général.
Rester en conformité dans la durée
Apple et Google font évoluer leurs exigences : niveau d'API Android minimal, déclarations de confidentialité, versions des outils de compilation. Une application non mise à jour peut perdre en visibilité, voire être retirée. La maintenance d'une application mobile après son lancement couvre ce suivi : surveillance des pannes, mises à jour des dépendances et adaptation aux nouvelles versions des systèmes.
Pensez enfin à renouveler le compte Apple chaque année, sous peine de voir l'application retirée de la vente.
Conclusion : un lancement qui se prépare comme un projet
Publier une application sur l'App Store et Google Play n'est pas une formalité de dernière minute. Les comptes, la conformité RGPD, les fiches, les tests et la revue forment un enchaînement où chaque oubli coûte des jours. En traitant ces étapes dès le début du projet, vous réduisez le risque de refus et gardez la maîtrise de votre calendrier.
Si vous préférez ne pas gérer seul ces démarches, Ship Studio publie des applications React Native sur les deux stores. Vous pouvez découvrir notre accompagnement pour lancer une application mobile et prendre rendez-vous avec Ship Studio pour être accompagné jusqu'à la publication.
FAQ
Peut-on publier une application gratuitement sur Google Play ?
Le téléchargement gratuit de l’application par les utilisateurs ne signifie pas nécessairement que sa publication ne coûte rien. Les conditions d’inscription au compte développeur et les éventuels frais associés peuvent évoluer. Vérifiez les modalités officielles de Google Play avant de préparer votre budget. Pensez aussi aux coûts distincts de conception, de développement, de maintenance et de mise à jour, qui ne sont pas des frais de publication du store.
Peut-on publier la même application sur l’App Store et Google Play ?
Oui, une application destinée à iOS et Android peut être distribuée sur les deux stores. Il faut toutefois préparer et soumettre une version adaptée à chaque plateforme, avec ses propres éléments de fiche et ses paramètres de distribution. Les deux stores appliquent également leurs propres règles d’examen. Un code partagé peut faciliter le développement multiplateforme, mais ne dispense pas de vérifier séparément le fonctionnement et la conformité de chaque version.
Faut-il une entreprise pour publier une application sur l’App Store et Google Play ?
Pas nécessairement. Les stores proposent des modalités de compte qui peuvent dépendre du statut du développeur, par exemple une personne ou une organisation. Le choix influe notamment sur les informations associées au compte et sur la manière dont l’éditeur est présenté. Vérifiez les critères officiels de chaque plateforme avant l’inscription, puis choisissez un compte dont le titulaire pourra durablement gérer l’application et ses accès.
Vaut-il mieux publier l’application depuis le compte du client ou celui de l’agence qui la développe ?
Pour garder la maîtrise de la présence de l’application dans les stores, le client peut généralement être titulaire de ses comptes et donner à l’agence les accès nécessaires au projet. Cela facilite la continuité si le prestataire change. Définissez clairement qui gère les soumissions, les accès et les mises à jour, puis attribuez uniquement les autorisations utiles. Les options exactes de partage dépendent des outils et règles de chaque plateforme.
Une application publiée doit-elle avoir une politique de confidentialité ?
Cela dépend notamment des données collectées, de leur usage et des exigences propres à chaque store. Même lorsqu’une politique de confidentialité n’est pas requise dans tous les cas, il faut décrire honnêtement les pratiques de l’application et renseigner les déclarations de confidentialité demandées par les plateformes. Examinez les règles officielles applicables à votre produit et assurez-vous que les informations affichées dans la fiche correspondent au fonctionnement réel de l’application.
Faut-il un site web pour publier une application sur les stores ?
Un site web complet n’est pas systématiquement indispensable pour distribuer une application, mais les stores peuvent demander des liens vers des informations comme l’assistance ou la politique de confidentialité, selon le projet et leurs règles. Prévoyez des pages accessibles et à jour si elles sont nécessaires à votre fiche ou à vos obligations. Vérifiez les champs exigés dans les consoles développeur avant de finaliser les informations publiques de l’application.