Publier une application mobile suppose de franchir deux validations distinctes : celle d’Apple pour l’App Store, celle de Google pour Google Play. Chaque store impose ses propres comptes, formulaires, règles de test et délais. Cet article détaille les étapes de publication sur les deux plateformes, les délais réalistes en octobre 2026 et les motifs de refus les plus fréquents.
Il s’adresse aux dirigeants, chefs de projet et responsables produit dont l’application est prête, ou presque, et qui veulent anticiper la mise en ligne. Mieux vaut préparer la publication dès le début du projet : certaines étapes, comme les 14 jours de test imposés par Google à certains comptes, ne se rattrapent pas la veille du lancement.
Avant de commencer : créer vos comptes développeur
Créez les deux comptes développeur bien avant la fin du développement, car la vérification d’identité peut prendre plusieurs jours. Sans compte, vous ne pouvez ni tester la distribution ni préparer la fiche de l’application.
| Critère | App Store (Apple) | Google Play |
|---|---|---|
| Programme | Apple Developer Program | Google Play Console |
| Tarif | 99 $ par an | 25 $ une seule fois |
| Type de compte | Individuel ou organisation | Personnel ou organisation |
| Vérification | Identité ; numéro D-U-N-S pour une société | Identité (pièce officielle possible) ; vérification de l’entreprise pour une organisation |
| Outil de publication | App Store Connect | Play Console |
Tarifs et conditions évoluent : vérifiez-les au moment de l’inscription.
Créez ces comptes au nom de l’entreprise qui commercialise l’application, jamais au nom de votre prestataire. Le compte reste propriétaire de l’application, de ses avis, de ses statistiques et de son historique de versions. Vous pouvez inviter votre agence comme utilisateur, avec des droits limités.
Pour une application bancaire, de paiement, de cryptomonnaie ou de santé, Apple exige que l’éditeur soit l’entité légale qui fournit le service, et non un développeur individuel. Un compte organisation est alors indispensable.
Publier sur l’App Store : les étapes pas à pas
La publication sur l’App Store passe par App Store Connect et se déroule en huit étapes. Depuis le 28 avril 2026, toute application envoyée doit être compilée avec Xcode 26 ou plus récent, avec le SDK iOS 26 : un build plus ancien est refusé dès l’envoi.
- Compiler et signer l’application. Générez une version de production avec Xcode 26, signée avec vos certificats et profils de distribution.
- Créer la fiche de l’application dans App Store Connect. Renseignez le nom, l’identifiant de bundle (impossible à modifier ensuite), la langue principale et la référence interne (SKU).
- Envoyer le build. Utilisez Xcode, l’application Transporter ou votre outil d’intégration continue, puis attendez la fin du traitement par Apple.
- Tester avec TestFlight. Invitez vos testeurs internes, puis des testeurs externes si besoin. Cette étape est facultative, mais elle évite de découvrir un plantage pendant la revue.
- Compléter la fiche publique. Ajoutez titre, sous-titre, description, mots-clés, captures d’écran, catégorie, URL de la politique de confidentialité et URL de support. Répondez au questionnaire de classification d’âge et déclarez les données collectées dans la section de confidentialité.
- Remplir les informations de revue. Fournissez un compte de démonstration fonctionnel, vos coordonnées et toute instruction utile au relecteur d’Apple.
- Soumettre pour examen. Choisissez le mode de mise en ligne : automatique après validation, manuelle ou programmée à une date précise.
- Publier. Une fois l’application approuvée, elle apparaît dans l’App Store selon le mode choisi.
Le compte de démonstration est un détail qui coûte cher quand on l’oublie : Apple rappelle qu’une application dont les fonctions exigent une connexion doit être livrée avec un identifiant valide. Pour tester votre application avant cette étape, consultez notre guide sur comment tester une application mobile.
Publier sur Google Play : les étapes pas à pas
Sur Google Play, la principale différence tient aux déclarations obligatoires et, pour certains comptes, à une phase de test imposée. Depuis le 31 août 2026, toute nouvelle application et toute mise à jour doit cibler Android 16 (API 36) ou plus, sous peine de blocage à l’envoi.
- Créer le compte Play Console et valider l’identité du titulaire (voir plus haut).
- Créer l’application dans la console : nom, langue par défaut, type (application ou jeu), gratuite ou payante.
- Générer un Android App Bundle (.aab) signé, ciblant l’API 36, avec Play App Signing activé pour que Google conserve la clé de distribution.
- Remplir les déclarations du contenu de l’application. Politique de confidentialité, formulaire Sécurité des données, questionnaire de classification du contenu, public cible, présence de publicités. Si l’application permet de créer un compte, prévoyez aussi une option de suppression de compte.
- Compléter la fiche Play Store. Titre, description courte (80 caractères) et complète (4 000 caractères), icône 512 × 512 px, image de présentation 1 024 × 500 px et captures d’écran.
- Tester. Le test interne (jusqu’à 100 testeurs, sans validation préalable) sert à itérer vite. Le test fermé devient obligatoire pour les comptes personnels récents : voir le paragraphe qui suit la liste.
- Demander l’accès à la production (comptes concernés), puis créer la version de production et l’envoyer en examen.
- Publier, de préférence avec un déploiement progressif (par exemple 10 % des utilisateurs) pour limiter l’impact d’un défaut non détecté.
La règle de test est la plus souvent sous-estimée : un compte personnel créé après le 13 novembre 2023 doit mener un test fermé avec au moins 12 testeurs inscrits en continu pendant 14 jours avant de demander l’accès à la production. Recrutez davantage de testeurs que nécessaire : si l’un d’eux se désinscrit, le décompte peut être compromis. Cette obligation vise les comptes personnels ; un compte organisation n’est pas concerné, mais il suppose une vérification de l’entreprise.
Délais : combien de temps prévoir ?
À l’App Store, la validation prend en général un à deux jours ; sur Google Play, un premier lancement avec un compte personnel récent demande environ trois semaines. Apple indique examiner au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures. Côté Google, l’aide de Play Console précise que l’examen peut atteindre sept jours, voire davantage dans des cas exceptionnels, notamment pour certains comptes.
Le parcours est le même sur les deux stores, à une différence près : la phase de test fermé n’existe que pour les comptes Google personnels récents.
| Étape | App Store (Apple) | Google Play |
|---|---|---|
| Création et vérification du compte | Quelques jours en général ; plus long pour une société (numéro D-U-N-S) | De quelques heures à quelques jours |
| Phase de test obligatoire | Aucune (TestFlight recommandé) | 14 jours si compte personnel récent, avec 12 testeurs minimum |
| Examen de la première version | Environ 1 à 2 jours dans la majorité des cas | Jusqu’à 7 jours, parfois plus |
| Examen d’une mise à jour | Même circuit, généralement rapide | Même circuit, souvent plus rapide qu’une première version |
| Premier lancement, compte neuf | Quelques jours après la soumission | Environ 3 semaines avec un compte personnel |
Ces durées sont des moyennes et non des engagements. Un refus ajoute un aller-retour complet : correction, nouveau build, nouvelle attente. Prévoyez une marge de trois à quatre semaines entre la fin du développement et la date de lancement visée, surtout pour une première publication.
Au-delà des délais d’examen, deux précautions gagnent du temps. Évitez de soumettre le week-end : les soumissions du milieu de semaine sont réputées traitées plus vite, d’après les relevés de Choicely. Et pour une application liée à un événement daté, Apple propose une procédure d’examen accéléré, à réserver aux cas réels (correction d’un bug critique, lancement synchronisé avec un événement).
Les refus les plus fréquents et comment les éviter
Une grande partie des refus vient d’applications incomplètes ou mal documentées plutôt que de défauts techniques graves. Chez Apple, plus de 40 % des problèmes non résolus relèvent de la règle 2.1 (application complète) : plantages, contenus provisoires, informations de revue manquantes.
| Cause du refus | Store | Comment l’éviter |
|---|---|---|
| Plantages, bugs, contenus provisoires | Apple | Tester sur appareils réels avec le dernier système, remplacer tout texte ou image « à venir » |
| Compte de démonstration absent ou invalide | Apple | Fournir un identifiant fonctionnel et les instructions de configuration dans les informations de revue |
| Politique de confidentialité absente ou incohérente | Apple et Google | Publier une politique accessible par URL, alignée sur les données réellement collectées (nos bonnes pratiques RGPD) |
| Formulaire Sécurité des données inexact | Recenser les SDK tiers (analytics, publicité, paiement) avant de remplir la déclaration | |
| Permissions sans justification claire | Apple et Google | Rédiger des messages d’autorisation explicites ; ne demander que les permissions utiles |
| Application qui n’est qu’un site web encapsulé | Apple | Apporter des fonctions propres au mobile (notifications, appareil photo, mode hors ligne) |
| Éditeur inadapté pour une application bancaire, de paiement ou de santé | Apple | Publier depuis le compte de l’entité légale qui fournit le service |
| Captures d’écran ou description trompeuses | Apple et Google | Montrer l’application réellement utilisée, sans promettre une fonction absente |
| Création de compte sans suppression possible | Apple et Google | Prévoir la suppression du compte dans l’application |
| Niveau d’API cible trop ancien | Cibler Android 16 (API 36) avant l’envoi | |
| Test fermé non conforme (testeurs insuffisants, désinscriptions) | Recruter plus de 12 testeurs et suivre leur activité pendant les 14 jours |
En cas de refus, lisez d’abord le motif exact : Apple le détaille dans le Centre de résolution d’App Store Connect, Google dans la page d’état des règles de Play Console. Corrigez le point cité, répondez au relecteur si le motif vous semble erroné, puis renvoyez une version. Apple prévoit aussi une procédure d’appel auprès de l’App Review Board lorsque vous estimez que votre application a été mal comprise.
Si le motif vous semble erroné, répondez au store ; chez Apple, un appel reste possible quand le désaccord persiste.
Checklist avant de soumettre votre application
Cette liste regroupe les points à vérifier avant l’envoi sur les deux stores ; cochez-les un par un.
☐ Comptes développeur créés au nom de l’entreprise, vérification d’identité terminée
☐ Build de production signé : Xcode 26 pour iOS, bundle .aab ciblant l’API 36 pour Android
☐ Application testée sur appareils réels, sans plantage ni contenu provisoire
☐ Politique de confidentialité en ligne, cohérente avec les données collectées
☐ Déclarations remplies : confidentialité Apple, Sécurité des données Google, classification d’âge et de contenu
☐ Messages de demande d’autorisation clairs pour chaque permission (localisation, appareil photo, notifications)
☐ Suppression de compte disponible dans l’application si la création de compte est possible
☐ Compte de démonstration fonctionnel et instructions de revue renseignés (Apple)
☐ Captures d’écran, icône, titre et descriptions finalisés et fidèles à l’application
☐ Pour un compte personnel Google récent : test fermé de 12 testeurs sur 14 jours terminé
☐ Adresse de support et coordonnées de contact à jour
☐ Mode de mise en ligne choisi : automatique, manuel ou déploiement progressif
FAQ : publier son appli sur les stores
Combien de temps faut-il pour publier une application sur l’App Store ?
La validation prend en général un à deux jours une fois la fiche complète. Prévoyez une marge pour la création du compte, la préparation de la fiche et un éventuel refus.
Pourquoi la publication sur Google Play est-elle plus longue ?
Un compte personnel récent doit d’abord mener un test fermé de 14 jours avec 12 testeurs, puis demander l’accès à la production et attendre l’examen. Un compte organisation n’est pas visé par cette règle de test.
Faut-il un compte entreprise pour publier ?
Pas toujours, mais c’est la solution recommandée pour une application commerciale. Il est obligatoire pour les applications de services régulés (banque, paiement, cryptomonnaie, santé) sur l’App Store, et il évite les phases de test imposées aux comptes personnels récents sur Google Play.
Mon agence peut-elle publier l’application à ma place ?
Oui, à condition que l’application soit publiée sur votre compte développeur et non sur celui du prestataire. Vous restez propriétaire de l’application et vous pouvez inviter l’agence comme utilisateur, avec des droits adaptés.
Que faire si l’application est refusée ?
Lisez le motif précis indiqué par le store, corrigez le point cité, puis renvoyez une version. Si le motif vous semble erroné, répondez au relecteur ou, chez Apple, déposez un appel.
Une mise à jour doit-elle repasser en examen ?
Oui, chaque nouvelle version est examinée sur les deux stores. Les mises à jour sont généralement plus rapides qu’un premier lancement, sauf si elles ajoutent des permissions ou des fonctions sensibles.
Peut-on réserver une application à ses collaborateurs ?
Oui. Les deux écosystèmes proposent des modes de distribution privés pour les applications métier, par exemple via Apple Business Manager ou Google Play géré. Ces applications restent soumises aux règles et à la validation des stores.
Anticiper la publication dès le début du projet
Publier sur l’App Store et Google Play se prépare en parallèle du développement : comptes créés tôt, déclarations de confidentialité rédigées avec l’équipe produit, test fermé lancé à temps pour Google. Une application bien documentée passe généralement la revue sans surprise ; une application incomplète revient avec un refus.
Pour cadrer la publication de votre application, découvrez notre accompagnement en développement d’applications mobiles ou contactez notre équipe.