Après des mois de conception et de développement, la publication sur les stores est souvent perçue comme une simple formalité. C’est rarement le cas. Entre la création des comptes développeurs, la préparation des fiches, les déclarations de confidentialité, les phases de test obligatoires et la revue par Apple et Google, une première publication mal préparée peut retarder un lancement de plusieurs semaines. Chez Aventique, la publication fait partie de notre périmètre sur la quasi-totalité des projets que nous réalisons : Inqom, VisioJob, WO OK, les applications médicales de Takeda (Click2Dose et ADCetris), Loox ou encore Click and Say ont toutes été publiées par nos équipes sur l’App Store et le Google Play Store. Voici la méthode que nous appliquons pour qu’une mise en ligne se passe sans mauvaise surprise.

Étape 1 : créer les bons comptes développeurs, au bon nom

Tout commence par l’ouverture des comptes développeurs, et c’est une étape à anticiper car elle peut prendre plusieurs jours, voire quelques semaines pour une entreprise.

Côté Apple, l’inscription à l’Apple Developer Program coûte 99 dollars par an. Pour publier au nom d’une société (et non d’une personne physique), Apple exige un numéro D-U-N-S, un identifiant international d’entreprise dont l’obtention peut demander plusieurs jours si votre société n’en possède pas encore.

Côté Google, l’inscription à la Google Play Console coûte 25 dollars, une seule fois. Google procède à une vérification d’identité de l’organisation (D-U-N-S également demandé pour les comptes d’organisation) et applique des règles plus strictes aux comptes personnels récents, qui doivent notamment mener un test fermé avec au moins 12 testeurs pendant 14 jours consécutifs avant de pouvoir publier en production.

Notre recommandation est constante : les comptes doivent être créés au nom de votre entreprise, et non de votre prestataire. Nous intervenons ensuite en tant que membres invités avec les droits nécessaires. Vous restez ainsi propriétaire de votre application, de ses avis et de ses statistiques, quel que soit votre prestataire dans le futur. Ce point est d’autant plus important pour les applications en marque blanche : lorsqu’un même socle est décliné pour plusieurs clients, comme le socle bancaire Push2Bank conçu pour être décliné pour différentes banques, Apple exige que chaque déclinaison soit publiée depuis le compte du client final.

Étape 2 : intégrer les règles des stores dès la conception

La plupart des rejets que nous voyons sur des projets repris proviennent de choix faits bien avant la publication. Les règles de l’App Store (App Review Guidelines) et du Google Play (Politiques du programme pour les développeurs) doivent être connues dès le cadrage. Voici les plus structurantes.

• La valeur ajoutée minimale : Apple rejette les applications qui se contentent d’encapsuler un site web sans fonctionnalité propre au mobile. Notre article application native, hybride ou web aide à choisir la bonne approche.
• Les achats intégrés : la vente de contenus ou services numériques consommés dans l’application doit en principe passer par les systèmes de paiement d’Apple et de Google, avec leur commission. Les biens et services physiques, comme la réservation d’une prestation en salon pour Loox, peuvent en revanche utiliser un prestataire comme Stripe.
• La suppression de compte : toute application qui permet de créer un compte doit permettre de le supprimer depuis l’application.
• La connexion via un tiers : si vous proposez la connexion avec Google ou Facebook, Apple impose généralement de proposer aussi une option respectueuse de la vie privée, comme « Se connecter avec Apple ».
• Les applications sensibles : santé, finance, jeux d’argent ou contenus générés par les utilisateurs font l’objet d’un examen renforcé. Pour les calculateurs de dose destinés aux médecins que nous avons développés pour Takeda, l’accès était par exemple réservé aux professionnels via un QR code remis par le laboratoire, un point qui doit être expliqué clairement aux équipes de revue.

Étape 3 : préparer les déclarations de confidentialité

Les deux stores exigent désormais une transparence détaillée sur les données collectées. Cette étape est souvent la plus chronophage pour les équipes non averties, car elle impose d’inventorier précisément les données traitées par l’application et par chaque SDK tiers embarqué (analytics, publicité, crash reporting, paiement).

Sur l’App Store, il faut renseigner les informations de confidentialité affichées sur la fiche (les « étiquettes » de confidentialité), fournir un fichier de manifeste de confidentialité lorsque l’application ou ses SDK utilisent certaines API sensibles, et demander le consentement de l’utilisateur via App Tracking Transparency avant tout suivi publicitaire entre applications. Sur Google Play, la section « Sécurité des données » joue un rôle équivalent. Dans les deux cas, une URL de politique de confidentialité est obligatoire. Ces déclarations doivent être cohérentes avec votre conformité RGPD et avec les mesures techniques décrites dans notre guide pour sécuriser une application mobile.

Étape 4 : construire des fiches store qui convertissent

La fiche store est la vitrine de votre application. Elle doit être soignée autant pour être validée que pour convaincre les utilisateurs de télécharger.

Les éléments à préparer sont les suivants : le nom de l’application (30 caractères maximum sur les deux stores), le sous-titre sur l’App Store ou la description courte sur Google Play, la description longue, les mots-clés (champ dédié de 100 caractères sur l’App Store), l’icône (1024 x 1024 pixels pour Apple, 512 x 512 pour Google), les captures d’écran aux formats exigés pour chaque taille d’appareil ciblée (y compris iPad et tablettes si l’application les supporte), l’image de présentation Google Play, et éventuellement une vidéo de démonstration.

Ces éléments conditionnent votre visibilité dans les résultats de recherche des stores. Nous détaillons la méthode pour les optimiser dans notre guide ASO : comment référencer son application mobile.

Étape 5 : tester avant de soumettre

Une application soumise avec des bugs visibles sera rejetée, ou pire, validée puis sanctionnée par les premiers avis. Les deux plateformes proposent des circuits de test officiels que nous utilisons systématiquement.

TestFlight permet de distribuer des versions de test iOS à des testeurs internes (membres de l’équipe) puis externes, jusqu’à plusieurs milliers de personnes, après une revue bêta allégée. Google Play propose des pistes de test interne, fermé et ouvert, qui permettent d’élargir progressivement le cercle des testeurs.

Nos équipes QA déroulent un plan de tests complet sur un panel d’appareils réels : parcours fonctionnels, compatibilité avec les différentes versions d’OS, comportement hors ligne, performances, permissions, notifications. Cette phase s’appuie sur des tests automatisés pour les parcours critiques et sur une chaîne de CI/CD qui compile, signe et distribue automatiquement les builds, par exemple avec Fastlane, Codemagic ou GitHub Actions associés à Firebase App Distribution.

Étape 6 : compiler, signer et soumettre

Techniquement, la soumission suppose de produire un binaire signé conforme aux exigences en vigueur. Sur Android, le format Android App Bundle (AAB) est obligatoire pour les nouvelles applications, et la signature est gérée via Play App Signing ; l’application doit cibler le niveau d’API Android récent exigé par Google, relevé chaque année. Sur iOS, l’application doit être compilée avec une version récente de Xcode et du SDK iOS, signée avec les certificats et profils de provisionnement adéquats, puis envoyée sur App Store Connect.

Lors de la soumission, fournissez aux équipes de revue tout ce dont elles ont besoin : un compte de démonstration fonctionnel si l’application nécessite une connexion, des explications sur les fonctionnalités non évidentes, et le contexte d’usage pour les applications professionnelles. Une note de revue claire évite une bonne partie des allers-retours.

Étape 7 : passer la revue et gérer un éventuel rejet

Chez Apple, la grande majorité des soumissions est examinée en moins de 48 heures. Chez Google, les délais sont variables et peuvent s’allonger à plusieurs jours pour un nouveau compte ou une première publication. Prévoyez donc une marge d’au moins une semaine avant une date de lancement annoncée publiquement.

Un rejet n’est pas un échec : il est accompagné d’un motif et de la règle concernée. Dans la plupart des cas, il se règle par une correction ciblée ou une explication complémentaire dans le centre de résolution d’App Store Connect ou dans la Play Console. Notre expérience des règles des deux stores nous permet d’anticiper la grande majorité des motifs de rejet dès la phase de développement.

Étape 8 : lancer progressivement et suivre les premiers jours

Une fois l’application validée, vous pouvez choisir de la publier immédiatement, à une date précise, ou manuellement. Pour les mises à jour, les deux stores permettent un déploiement progressif : sur l’App Store, la publication échelonnée étale la mise à jour automatique sur sept jours ; sur Google Play, le déploiement par paliers permet de cibler un pourcentage d’utilisateurs et de suspendre la diffusion en cas de problème.

Les premiers jours, nous surveillons de près le taux de crash (Firebase Crashlytics), les indicateurs de performance, les avis et les statistiques des consoles. C’est aussi le moment de configurer les notifications push et les liens profonds (voir notre article sur le deeplinking) qui soutiendront l’engagement.

Et pour une application interne ?

Toutes les applications n’ont pas vocation à être publiques. L’application SOS que nous avons développée pour l’APEC a par exemple été déployée en interne sur les smartphones des salariés, sans passer par l’App Store public. Plusieurs solutions existent pour ce type de diffusion : applications personnalisées distribuées via Apple Business Manager, applications privées gérées sur Google Play, ou déploiement par une solution de gestion de flotte (MDM). Pour les tablettes installées dans les chambres de la Clinique du Val ou utilisées par les commerciaux de Thales sur les salons, le mode de déploiement a été pensé dès le cadrage, en fonction du parc d’appareils et des contraintes de mise à jour.

Confier la publication à votre agence

La publication concentre des compétences techniques, réglementaires et marketing rarement réunies en interne lors d’un premier lancement. Au sein de notre agence de développement d’applications mobiles, elle fait partie intégrante du projet : préparation des comptes, conformité, fiches, tests, soumission et suivi post-lancement, puis maintenance pour garder l’application conforme aux exigences qui évoluent chaque année. Pour cadrer ces éléments dès le départ, notre guide du cahier des charges d’application mobile liste les informations à réunir.

FAQ sur la publication d’une application sur les stores

Combien coûte la publication d’une application sur les stores ?

Les frais d’inscription sont de 99 dollars par an pour l’Apple Developer Program et de 25 dollars en paiement unique pour Google Play. S’y ajoute le temps de préparation (fiches, visuels, conformité, tests), généralement inclus dans l’accompagnement de votre agence.

Combien de temps faut-il pour être publié ?

Comptez quelques jours pour la création des comptes d’entreprise, puis en général 24 à 48 heures pour une revue Apple et de quelques heures à plusieurs jours pour Google. Les nouveaux comptes personnels Google doivent en plus mener un test fermé de 14 jours.

Pourquoi mon application a-t-elle été rejetée par Apple ?

Les motifs les plus fréquents sont des bugs ou crashs pendant la revue, des informations de connexion manquantes, une fonctionnalité jugée insuffisante (site web encapsulé), des déclarations de confidentialité incomplètes ou un contournement des achats intégrés. Le motif précis est toujours indiqué dans App Store Connect.

Peut-on publier la même application sur l’App Store et Google Play en même temps ?

Oui, et c’est ce que nous faisons le plus souvent, en particulier avec Flutter ou React Native qui produisent les deux versions à partir d’un même code source. Il faut simplement anticiper des délais de revue différents pour synchroniser le lancement.

Qui doit être propriétaire du compte développeur ?

Votre entreprise. Le prestataire intervient comme membre invité. Vous conservez ainsi la maîtrise de l’application, de ses avis et de ses données, même en cas de changement de prestataire.

Faut-il repasser la revue à chaque mise à jour ?

Oui, chaque nouvelle version est examinée par Apple et Google, généralement plus rapidement qu’une première soumission. D’où l’intérêt d’une chaîne de publication automatisée et d’une qualité constante des livraisons.