Pour publier application App Store Google Play, il faut créer les comptes développeur, préparer un build signé, renseigner les fiches stores, déclarer les données collectées, tester, soumettre à validation, puis gérer les mises à jour. Le point qui change tout pour votre budget et vos délais : la publication n’est pas une simple formalité de fin de projet, mais une phase de conformité à anticiper dès le cadrage.
Comment créer les comptes développeur Apple et Google ?
La première étape consiste à ouvrir les comptes officiels au nom de votre entreprise, pas au nom d’un freelance ou d’une agence. C’est un détail administratif qui devient vite stratégique : le compte détient l’application, les avis, les statistiques, les certificats et l’historique des mises à jour.
En 2026, l’Apple Developer Program coûte 99 USD par an. Il est obligatoire pour distribuer une application sur l’App Store. Pour une inscription en tant qu’organisation, Apple demande une entité légale, un nom de vendeur, un site web public et fonctionnel, un email lié au domaine de l’entreprise, un pouvoir légal de l’inscripteur et, sauf exceptions, un numéro D-U-N-S, identifiant international attribué aux sociétés.
Côté Google, l’accès à la Google Play Console coûte 25 USD en paiement unique. Google propose des comptes Personal et Organization, avec vérifications d’identité ou d’organisation. Pour une PME, le compte Organization est généralement le bon choix : il clarifie la propriété, facilite la gestion des utilisateurs et évite de dépendre du compte personnel d’un collaborateur.
Sur les projets que nous menons, nous voyons souvent un blocage très banal : le compte Apple Organisation n’est pas prêt, car le D-U-N-S ou l’email de domaine manque. À lui seul, ce sujet peut décaler une mise en ligne de plusieurs jours, parfois davantage si les pièces doivent être régularisées.
Quels fichiers, certificats et identifiants faut-il préparer ?
Une application ne se téléverse pas comme un PDF. Elle doit être identifiée, signée et associée aux bons services techniques. Le signing, ou signature, prouve que le fichier provient bien du développeur autorisé et qu’il n’a pas été modifié.
Sur iOS, l’équipe technique prépare notamment un Bundle ID, c’est-à-dire l’identifiant unique de l’application, par exemple sous une forme proche de com.entreprise.app. Elle configure aussi les capacités utilisées : notifications push, connexion Apple, achats intégrés, géolocalisation, arrière-plan, selon le périmètre réel du projet. Le build signé est ensuite archivé avec Xcode puis envoyé vers App Store Connect.
Sur Android, les nouvelles applications publiées sur Google Play utilisent l’Android App Bundle, un fichier .aab. Ce format permet à Google Play de générer des versions adaptées aux appareils des utilisateurs. Play App Signing gère ensuite la signature de distribution. C’est pratique, mais cela impose une bonne conservation des clés et des accès.
Le piège peu visible : refaire une application avec un mauvais identifiant ou une mauvaise gestion de signature peut compliquer, voire empêcher, certaines mises à jour. À ce stade, mieux vaut perdre une demi-journée à vérifier l’architecture de publication que découvrir le problème après l’acquisition de vos premiers utilisateurs.
Si le choix technique n’est pas encore arrêté, un cadrage en amont reste utile pour comparer une application native, React Native, Flutter ou une approche web. Le sujet est lié à la décision plus large entre application mobile ou site web selon les usages, car toutes les idées ne méritent pas forcément une présence sur les stores.
| Élément | App Store Apple | Google Play |
|---|---|---|
| Compte développeur en 2026 | Apple Developer Program, 99 USD par an | Google Play Console, 25 USD en paiement unique |
| Fichier de publication | Build iOS signé et archivé via Xcode / App Store Connect | Android App Bundle .aab avec Play App Signing |
| Test officiel | TestFlight, interne ou externe | Internal, Closed ou Open testing |
| Délai de review annoncé | Apple indique 90 % des soumissions examinées en moins de 24 h en moyenne | De quelques heures à 7 jours ou plus dans certains cas |
| Point de vigilance | Compte Organisation, D-U-N-S, confidentialité, review notes | Déclarations App content, tests obligatoires pour certains comptes Personal |
Comment tester l’application avant sa publication ?
Le test store n’est pas seulement un contrôle qualité. Il vérifie aussi que l’application se comporte correctement dans un environnement proche du réel : installation, permissions, connexion, paiement, notifications, mise à jour, suppression du compte si des données personnelles sont traitées.
Sur iOS, TestFlight permet d’inviter des testeurs internes et externes. Les tests externes demandent des informations de bêta et le premier build doit être approuvé par App Review. Cette étape peut surprendre : même une version de test destinée à quelques clients pilotes peut être examinée par Apple.
Sur Google Play, les pistes Internal testing, Closed testing et Open testing couvrent différents niveaux d’exposition. L’internal testing accepte jusqu’à 100 testeurs. Pour les comptes Google Play Personal créés après le 13 novembre 2023, Google impose un closed test avec au moins 12 testeurs inscrits en continu pendant 14 jours avant de demander l’accès production.
Honnêtement, publier sans vraie phase bêta est rarement rentable. Les économies apparentes se transforment vite en avis négatifs, tickets support et correctifs urgents. Pour limiter ces risques, une checklist de sécurité avant publication mobile doit couvrir les accès, le chiffrement, les permissions, les SDK tiers et les journaux d’erreurs.
Que doit contenir la fiche de présentation sur les stores ?
La fiche store influence le taux d’installation, mais aussi la validation. Apple et Google veulent comprendre ce que fait l’application, pour qui, avec quelles données et dans quelles conditions. Une fiche vague du type “gérez tout depuis votre mobile” n’aide ni l’utilisateur ni le reviewer.
Dans App Store Connect, préparez le nom, les mots-clés, la description, les captures d’écran, les éventuels app previews, la catégorie, le build, l’URL de support, l’URL de politique de confidentialité et les informations de review. Apple demande au minimum 1 capture d’écran et accepte jusqu’à 10 captures par fiche, en .jpeg, .jpg ou .png. Les app previews, des vidéos courtes, sont optionnels jusqu’à 3 par taille d’appareil et par langue.
Dans Google Play Console, le nom d’application est limité à 30 caractères. La short description va jusqu’à 80 caractères et la full description jusqu’à 4 000 caractères. Il faut aussi fournir les visuels, la catégorie, les coordonnées de contact et la politique de confidentialité selon les cas.
- Préparer les captures sur de vrais écrans représentatifs, pas seulement des maquettes marketing.
- Écrire une description claire des fonctionnalités réellement disponibles au lancement.
- Fournir un compte de test au reviewer si l’application nécessite une connexion.
- Vérifier que les permissions demandées correspondent à l’usage visible pour l’utilisateur.
- Mettre en ligne une politique de confidentialité accessible, stable et cohérente avec l’application.
Le travail éditorial de la fiche arrive souvent trop tard. Pourtant, l’ASO, ou optimisation pour les stores, demande des choix de mots, de catégories et de visuels. Si votre projet démarre encore, le guide pour créer une application mobile de A à Z aide à replacer la publication dans une trajectoire complète, de l’idée au lancement.
Comment déclarer les données personnelles collectées ?
La publication d’une application sur App Store et Google Play impose de déclarer les données collectées, y compris celles qui passent par des outils tiers. Un SDK, c’est une brique logicielle ajoutée à l’app, par exemple pour les statistiques, la publicité, le crash reporting ou la connexion sociale.
Chez Apple, les App Privacy details, souvent appelés Privacy Nutrition Labels, sont requis pour les nouvelles applications et les mises à jour. Ils couvrent les données collectées par l’application, mais aussi par ses partenaires et SDK tiers. En 2026, Apple signale aussi l’apparition d’Accessibility Nutrition Labels sur les pages produit pour les appareils sous iOS 26 et systèmes associés, avec des informations liées à l’accessibilité.
Chez Google, la section App content sert à déclarer les pratiques de confidentialité et de sécurité, les classifications de contenu, les politiques de confidentialité et d’autres informations de conformité. Le RGPD, applicable dans l’Union européenne depuis 2018, reste évidemment central si vous traitez des données personnelles : base légale, information, consentement si nécessaire, durée de conservation, droits des utilisateurs.
Un cas fréquent où la solution évidente est mauvaise : ajouter un outil d’analyse publicitaire “au cas où” avant même d’avoir une stratégie d’acquisition. Vous augmentez les déclarations, les risques de consentement et la surface de contrôle, parfois sans bénéfice mesurable. À petit budget, mieux vaut instrumenter peu, mais proprement.
Comment se déroule la validation par Apple et Google ?
Une fois le build et la fiche prêts, la soumission part en review. Apple examine l’application au regard de ses App Review Guidelines, de la stabilité, de la confidentialité, du contenu, des paiements et de l’expérience utilisateur. Apple indique que 90 % des soumissions sont examinées en moins de 24 heures en moyenne.
Google Play annonce une review pouvant prendre de quelques heures à 7 jours, ou plus dans des cas exceptionnels. Modifier des informations pendant une review peut relancer le processus. Pour une date de lancement annoncée publiquement, gardez donc une marge. Une semaine de sécurité n’est pas excessive.
Les refus les plus classiques ne sont pas toujours techniques : compte de test absent, fonctionnalité non expliquée, politique de confidentialité incohérente, permission trop large, crash au démarrage, contenu jugé incomplet. Côté agence, le réflexe est de soumettre une version stable avec des notes de review très concrètes : parcours de test, identifiants, zones sensibles, explication des permissions.
La qualité technique reste néanmoins déterminante. Temps de démarrage, mémoire, ANR sur Android, c’est-à-dire absence de réponse de l’application, et crashs iOS pèsent directement sur l’expérience et la visibilité. Pour les projets complexes, l’ingénierie mobile orientée performance iOS et Android devient un sujet de pilotage, pas seulement de développement.
Quelles obligations prévoir après la mise en ligne ?
La mise en ligne n’est pas la fin. Il faut surveiller les crashs, les ANR, les avis, les notes, les performances, les téléchargements, les erreurs de paiement et les tickets support. Il faut aussi maintenir les certificats, les signatures, les SDK, les déclarations de confidentialité, les pays de diffusion, les prix et les fiches stores.
Les règles évoluent. Google Play a par exemple annoncé en 2026 une Android developer verification entrant en vigueur à partir du 30 septembre 2026 pour l’installation sur appareils Android certifiés. Google a aussi communiqué sur des évolutions de politiques liées à certains types d’apps, comme les chats anonymes ou aléatoires avec des standards de sécurité enfant étendus.
Prévoyez un budget de maintenance. Selon les prestataires et la complexité, une enveloppe mensuelle de quelques centaines à plusieurs milliers d’euros peut être nécessaire pour corriger, mettre à jour les dépendances, suivre les stores et adapter l’app aux nouvelles versions iOS et Android. À très petit budget, mieux vaut réduire le périmètre fonctionnel initial que sacrifier cette maintenance.
Pour une entreprise, le bon arbitrage consiste à garder la propriété des comptes, tout en déléguant la préparation technique, les tests et la soumission. DualMedia a accompagné la publication de plus de 100 applications d’entreprises sur les stores ; l’expérience montre surtout une chose : les projets les plus sereins sont ceux où comptes, certificats et données restent sous contrôle du client dès le départ.
Cadrer ce type de publication en amont évite la plupart des mauvaises surprises : délais administratifs, refus de review, fiches incomplètes, déclarations de données fragiles. Un regard extérieur aide souvent à transformer une étape perçue comme finale en processus maîtrisé, avec moins d’allers-retours et moins de dépendance technique.
FAQ sur la publication App Store et Google Play
Combien coûte la publication d’une application sur App Store et Google Play ?
En 2026, le compte Apple Developer Program coûte 99 USD par an et le compte Google Play Console coûte 25 USD en paiement unique. À cela s’ajoutent le temps de préparation, de tests, de correction et de maintenance.
Combien de temps faut-il pour publier application App Store Google Play ?
Si les comptes sont prêts, une soumission peut être préparée en quelques jours. La review prend souvent moins de 24 heures chez Apple selon leurs chiffres, et de quelques heures à 7 jours ou plus chez Google Play.
Peut-on publier une application sans compte entreprise ?
Oui, des comptes individuels existent, notamment chez Google avec le type Personal. Pour une PME, un compte organisation est généralement préférable afin de sécuriser la propriété, les accès et la continuité en cas de départ d’un collaborateur.
Pourquoi une application peut-elle être refusée par Apple ou Google ?
Les causes fréquentes sont un crash, une fiche trompeuse, des données personnelles mal déclarées, des permissions excessives, un compte de test manquant ou une politique de confidentialité incohérente. La plupart de ces refus se préviennent avant la soumission.