Publier son application sur l'App Store et Google Play : le guide 2026
En résumé : publier une application demande un compte Apple Developer (99 $/an) et un compte Google Play (25 $ une fois), des fiches store complètes et une politique de confidentialité. Apple valide en 24 à 72 h via une revue humaine exigeante, Google en quelques heures à 3 jours. Le principal piège reste le refus Apple, presque toujours évitable avec un peu de préparation.
On parle beaucoup du développement d'une application, rarement de sa mise en ligne. C'est pourtant l'étape qui sépare un produit fini de vos utilisateurs — et celle où l'on perd le plus de temps quand on ne l'a pas anticipée. Comptes, certificats, fiches, validations : voici comment publier proprement sur l'App Store et Google Play en 2026.
App Store vs Google Play : les prérequis
| Critère | App Store (Apple) | Google Play |
|---|---|---|
| Coût du compte développeur | 99 $/an (renouvelable) | 25 $ une seule fois |
| Délai de validation | 24 à 72 h en moyenne | Quelques heures à 3 jours |
| Rigueur de la revue | Élevée, revue humaine systématique | Plus souple, en grande partie automatisée |
| Compte entreprise | DUNS requis pour publier au nom d'une société | Vérification d'identité / société obligatoire |
| Première mise en ligne | Souvent 2 à 5 jours avec aller-retours | Généralement 1 à 2 jours |
Dans les deux cas, prévoyez une politique de confidentialité accessible en ligne : elle est désormais obligatoire pour toute application qui collecte la moindre donnée.
Le process de publication, étape par étape
1. Créer et préparer les comptes
Ouvrez le compte Apple Developer (99 $/an) et le compte Google Play Console (25 $ une fois). Pour publier au nom d'une société, prévoyez le numéro DUNS côté Apple et la vérification d'identité côté Google — comptez quelques jours de délai administratif.
2. Préparer les éléments de la fiche store
Icône, captures d'écran pour chaque taille d'écran, description, mots-clés, catégorie, classification d'âge, et une URL de politique de confidentialité (obligatoire sur les deux stores). Apple exige aussi le formulaire « Confidentialité des données » détaillant les données collectées.
3. Générer les builds signés
Compiler l'app en version de production, signée avec les bons certificats et profils. Avec React Native et Expo, EAS Build gère cette étape et produit directement les binaires .ipa (iOS) et .aab (Android) prêts à uploader.
4. Tester avant la soumission
Distribuez une version de test via TestFlight (iOS) et les pistes de test interne / fermé (Google Play). C'est le moment de corriger les crashs et de valider le parcours sur de vrais appareils, avant que les équipes de revue ne le fassent à votre place.
5. Soumettre à la validation
Remplissez les notes pour l'équipe de revue (comptes de test, contexte des permissions sensibles) puis soumettez. Apple effectue une revue humaine ; Google combine automatisation et contrôles ciblés. Suivez le statut dans App Store Connect et la Play Console.
6. Publier et surveiller le lancement
Une fois approuvée, choisissez une mise en ligne immédiate ou programmée. Surveillez les premiers retours, les notes et les éventuels crashs remontés par les outils de monitoring dès les premières heures.
Si vous partez sur du cross-platform, ce process est mutualisé : une seule base de code alimente les deux stores. C'est l'un des arguments que nous détaillons dans notre comparatif React Native vs Flutter vs natif.
Les motifs fréquents de refus Apple (et comment les éviter)
Apple effectue une revue humaine et n'hésite pas à refuser. Bonne nouvelle : la quasi-totalité des refus relève de causes connues, faciles à anticiper.
Bugs et crashs à la revue
Apple teste réellement l'app. Un écran qui plante, un bouton mort ou un compte de démonstration qui ne fonctionne pas suffit à déclencher un refus. Fournissez toujours un identifiant de test valide.
Politique de confidentialité absente ou incohérente
URL manquante, formulaire de confidentialité incomplet ou permissions demandées sans justification claire (caméra, localisation, contacts) sont des motifs classiques. Chaque permission doit avoir une raison visible pour l'utilisateur.
Contenu jugé trop pauvre
Une app qui n'est qu'un simple site web encapsulé, sans valeur native, est souvent rejetée au titre de la directive « minimum functionality ». Apporter une vraie expérience mobile fait la différence.
Paiements hors du système Apple
Vendre du contenu numérique en contournant l'achat intégré d'Apple est interdit. Les ventes de biens physiques ou de services réels passent en revanche par un moyen de paiement classique.
Métadonnées trompeuses
Captures d'écran qui ne reflètent pas l'app, mots-clés bourrés dans le titre ou description mensongère entraînent un rejet des métadonnées, plus rapide à corriger mais qui retarde quand même la sortie.
Un refus n'est pas dramatique : vous corrigez et resoumettez, généralement avec une nouvelle revue sous 24 à 48 h. Le vrai coût, c'est le temps perdu quand on découvre ces règles le jour de la soumission plutôt que pendant la conception.
ASO : être trouvé une fois publié
Être en ligne ne suffit pas à être téléchargé. L'ASO (App Store Optimization) est le référencement des stores. Quatre leviers comptent vraiment :
- Le titre et le sous-titre. Ils pèsent lourd dans le classement. Intégrez le mot-clé principal sans le bourrer — un titre clair convertit mieux qu'un titre saturé.
- Les mots-clés. Apple propose un champ de mots-clés dédié (100 caractères) ; Google s'appuie sur la description. Choisissez les requêtes réelles de vos utilisateurs, pas le jargon interne.
- Les visuels. Icône, captures et vidéo de présentation déterminent le taux d'installation. Les premières captures doivent montrer la valeur en un coup d'œil.
- Les avis et notes. Volume et fraîcheur des avis influencent le classement et la confiance. Sollicitez un avis au bon moment dans le parcours, après une action réussie.
Une étape que nous gérons de bout en bout
Chez CNTL DIGITAL, agence de développement d'applications mobiles à Toulouse, la publication fait partie intégrante du projet : nous préparons les comptes, les fiches, les builds signés et nous pilotons les validations jusqu'à la mise en ligne. C'est exactement ce que nous avons fait pour Reezet, publiée sur les deux stores. Vous n'avez pas à apprendre les règles d'Apple dans l'urgence : c'est notre métier.
Après la publication : mises à jour et suivi
La sortie est un début, pas une fin. Chaque mise à jour repasse par une validation, ce qui impose un rythme régulier de livraisons pour corriger les bugs et enrichir l'app. Surveillez les crashs via les outils de monitoring, répondez aux avis, et suivez vos indicateurs d'installation et de rétention. Une application vivante, mise à jour et bien notée, gagne en visibilité ; une app figée recule. C'est aussi pour cela que nous proposons un suivi de maintenance, souvent entre 500 et 3 000 €/mois selon le produit.
Questions fréquentes
Combien coûte la publication d'une application sur les stores ?
Les frais des stores eux-mêmes sont modestes : 99 $/an pour le compte Apple Developer et 25 $ une seule fois pour Google Play. Le vrai coût est ailleurs : préparer les fiches, visuels, builds signés et gérer les aller-retours de validation représente généralement 1 à 3 jours de travail. C'est une étape que nous intégrons par défaut dans nos projets.
Combien de temps prend la validation Apple et Google ?
Apple revoit la plupart des soumissions en 24 à 72 heures, avec une revue humaine systématique. Google est souvent plus rapide (quelques heures à 3 jours) car la revue est en grande partie automatisée. Pour une première publication avec d'éventuels aller-retours, prévoyez plutôt 2 à 5 jours côté Apple.
Pourquoi Apple refuse-t-il une application ?
Les motifs les plus fréquents sont les crashs ou bugs détectés à la revue, une politique de confidentialité absente ou incohérente, des permissions injustifiées, un contenu jugé trop pauvre (simple site web encapsulé) et le contournement des achats intégrés. La plupart se corrigent vite une fois identifiés, mais ils retardent la sortie.
Faut-il publier sur les deux stores ?
Dans la grande majorité des cas, oui. iOS et Android se partagent le marché français et exclure l'un revient à se priver d'une large part d'utilisateurs. C'est précisément l'intérêt d'un développement cross-platform comme React Native : une seule base de code alimente les deux stores, sans doubler le budget.
Que faire après la publication ?
Le lancement n'est pas la fin. Il faut suivre les notes et avis, corriger rapidement les crashs remontés, publier des mises à jour régulières (chaque update repasse par une validation) et travailler l'ASO dans la durée. Une application laissée sans mise à jour perd en visibilité et en confiance.
Écrit par Corentin Teulet, fondateur de CNTL DIGITAL, agence de développement d'applications mobiles et d'IA à Toulouse.