Publier une application sur l’App Store et Google Play : guide étape par étape

Publier une application sur l’App Store et Google Play demande de : 

• Créer deux comptes développeur distincts
• Préparer 5 types d’assets obligatoires
• Et de soumettre l’application à une procédure de validation propre à chaque store. 

Apple valide en 1 à 3 jours ouvrés en moyenne. Google Play valide en quelques heures à 48 heures.

La mise en ligne sur les magasins d’applications est une étape importante dans le développement mobile. D’ailleurs, c’est la dernière ligne droite de votre projet de création d’application. Pourtant, cette phase finale est fréquemment sous-estimée par les équipes produit. En effet, on la considère à tort comme une simple formalité administrative. Pourtant, une mauvaise préparation des documents juridiques ou des visuels peut décaler votre stratégie de lancement de plusieurs semaines. Alors, quelles sont les étapes à suivre dans le processus de soumission de votre app mobile ? Comment franchir avec succès les audits d’Apple et de Google ? Le point. 

Quels sont les pré-requis avant de publier une application sur l’App Store et Google Play ? 

Contrairement aux idées reçues, il ne suffit pas de publier une application sur l’App Store et Google Play. Il y a des conditions à respecter. 

Un build finalisé et signé

Un build de production est une archive binaire optimisée, épurée des outils de débogage. Ici, le code source est compilé spécifiquement pour le grand public. Il se distingue fondamentalement d’un build de développement. Ce dernier intègre des signatures temporaires et des accès à des serveurs de test locaux. 

Avant toute tentative de soumission, le fichier exécutable doit être signé numériquement à l’aide d’un certificat de production valide et sécurisé. C’est ce qu’on appelle un fichier Keystore pour l’écosystème Android ou un profil de provisionnement de distribution lié à un certificat Apple Distribution pour l’univers iOS.

Pour garantir la recevabilité de votre livrable binaire, votre équipe d’ingénierie doit valider une liste de contrôles techniques stricts :

• Le taux de plantage (crash rate) : doit être nul sur l’ensemble des cas d’usage nominaux de l’application.
• La version minimale des systèmes d’exploitation (Target SDK) : doit être déclarée en stricte conformité avec les exigences de 2026.
• Aucun kit de développement logiciel (SDK) obsolète, non mis à jour ou banni par les politiques de confidentialité des stores ne doit subsister dans le code.

Une politique de confidentialité accessible en ligne

La politique de confidentialité est un document légal obligatoire qui décrit précisément : 

• La nature des données personnelles collectées
• Les finalités de leur traitement
• Leur durée de conservation 
• Ainsi que les modalités d’exercice des droits des utilisateurs.

La présence d’une adresse URL publique menant directement vers ce document juridique est une condition bloquante imposée par les deux plateformes. Ce document doit être hébergé sur un serveur web stable. En plus, il doit accessible sans authentification préalable avant même d’initier le processus de soumission binaire. L’absence de ce lien ou une page renvoyant une erreur technique génère un refus systématique et automatique de la part des robots d’inspection des stores.

Une classification de contenu

La classification de contenu est un processus déclaratif. Il permet notamment d’attribuer une tranche d’âge minimale et des avertissements de sécurité à une application. Cela se fait en fonction de sa thématique et de ses fonctionnalités. Pour ce faire, Apple s’appuie sur son propre barème de notation interne hérité des standards PEGI. Google, de son côté, utilise le questionnaire unifié de l’IARC (International Age Rating Coalition).

Le chef de produit doit consacrer entre 3 et 5 minutes pour répondre à une série de questions factuelles. Le tout se porte sur la présence éventuelle de : 

• Violence
• Contenus à caractère sexuel
• Fonctionnalités d’échange entre utilisateurs 
• Ou d’achats intégrés. 

Une classification erronée ou minimisée pour tenter d’élargir artificiellement sa cible vous expose à un bannissement pur et simple de l’application. C’est sans compter de lourdes sanctions de visibilité sur les requêtes de recherche organiques.

Étape 1 : créer et configurer ses comptes développeur

Le compte Apple Developer Program est un abonnement annuel à 99 dollars. Il donne accès à l’écosystème App Store Connect et aux certificats de signature de production. 

Le compte Google Play Console est un accès à vie activable via un versement unique de 25 dollars.

Sources : App Store et Google Play

Notre recommandation : initier la création de ces espaces d’administration dès le lancement des premiers sprints de développement. Ne le faites pas à la veille de la mise en production. L’authentification des structures morales par Apple requiert des vérifications manuelles approfondies.

Pour les organisations, évitez absolument l’ouverture d’un compte de type individuel. Tel est le cas par exemple des sociétés, ETI, associations, grands comptes. Le statut de compte « Organisation » est indispensable pour déléguer des accès techniques à des prestataires externes. Par exemple : une agence de développement mobile. Cela vous évite notamment de partager les identifiants maîtres. 

Il reste une question : comment valider ce statut chez Apple ? Vous devez notamment obtenir au préalable d’un numéro D-U-N-S (Data Universal Numbering System). Ce code international à 9 chiffres certifie l’existence légale de votre entreprise. Attention cependant, son attribution par l’organisme Dun & Bradstreet peut nécessiter plusieurs jours ouvrés. 

Bref, anticipez rigoureusement ce premier jalon de publication de votre application sur les stores. Il en va de la sécurité du lancement d’une application mobile sur le marché.

Étape 2 : préparer les assets de la fiche store

La fiche store représente l’unique vitrine commerciale de votre produit numérique sur les marchés applicatifs. Sa qualité graphique et textuelle conditionne directement le taux de conversion organique. C’est-à-dire le ratio entre le nombre de téléchargements effectifs et le nombre de vues de la page. Le moindre asset manquant ou non conforme aux strictes contraintes de dimensions imposées par les plateformes bloque l’enregistrement de la fiche. Ce qui suspend le déploiement.

Quels sont les assets obligatoires pour publier une application sur l’App Store et Google Play ? 

Voici 6 assets obligatoires pour publier une application sur l’App Store et Google Play : 

1. L’icône de l’application : elle doit être fournie au format carré strict sans aucune transparence (couche alpha). Ses dimensions doivent être de 1 024 × 1 024 pixels pour l’App Store et de 512 × 512 pixels au format PNG 32-bit pour Google Play. Il ne faut jamais appliquer de coins arrondis sur votre fichier source. En effet, les algorithmes d’affichage des stores appliquent automatiquement leur propre masque de découpe.
2. Les captures d’écran (Screenshots) : elles doivent être fournies à raison de 3 captures minimum (et 10 maximum) par taille d’écran requise. Sur iOS, les formats pour les écrans de 6,5 pouces et 5,5 pouces sont obligatoires. Le premier visuel de la série doit faire l’objet d’un soin graphique extrême. En effet, les études comportementales démontrent que 80 % des internautes prennent leur décision de téléchargement sur la base de cette seule image.
3. Le nom de l’application (Titre) : il est limité à un maximum de 30 caractères sur l’App Store et de 50 caractères sur Google Play. Intégrez-y le nom de votre marque associé au mot-clé principal de votre secteur. Ainsi, vous boostez l’indexation.
4. La description courte : ce champ spécifique à Google Play dispose d’une limite stricte de 30 caractères. Son équivalent textuel direct n’existe pas sous cette forme dans l’arborescence native d’Apple. Ce dernier s’appuie sur le sous-titre.
5. La description longue : elle est limitée à 4 000 caractères sur les deux consoles d’administration. D’ailleurs, elle doit détailler la proposition de valeur, les fonctionnalités clés et les bénéfices de l’outil informatique.
6. La vidéo de présentation : optionnelle mais fortement recommandée. Sa durée doit être comprise entre 15 et 30 secondes. En plus, elle doit se concentrer exclusivement sur l’expérience utilisateur réelle. Donc, évitez les mises en scène publicitaires fictives.

Quelles sont les différences à connaître entre les deux stores ? 

La gestion du référencement naturel diffère entre les deux géants de la tech : 

L’App Store d’Apple met à disposition un champ technique masqué de 100 caractères. Il est dédié exclusivement aux mots-clés (séparés par des virgules). Il est inutile et contre-productif de répéter dans ce champ les termes textuels déjà présents dans le titre ou le sous-titre de l’application. Cela ne fait que gaspiller un espace précieux.

À l’inverse, Google Play n’offre aucun champ technique pour les mots-clés. Ses robots s’appuient sur une analyse sémantique globale. Ce qui lui permet d’extraire automatiquement les expressions pertinentes présentes au sein du titre, de la description courte et de la description longue. Le tout se fait selon une logique similaire au SEO web traditionnel. C’est l’un des piliers pour optimiser sa fiche store ASO et capter un trafic qualifié dès les premières minutes de visibilité.

Étape 3 : soumettre l’application sur App Store Connect

Procédez par étape pour publier une application sur App Store. Les voici. 

Créer la fiche dans App Store Connect

Vous souhaitez publier une application sur l’App Store ? Vous devez exécuter une suite d’actions rigoureuses dans l’interface d’App Store Connect :

1. Se connecter au portail Apple Developer pour créer un identifiant d’application unique appelé Bundle ID (par exemple : com.entreprise.application).
2. Naviguer vers l’interface App Store Connect, ouvrir l’onglet « Mes Apps », cliquer sur le symbole « + » et sélectionner « Nouvelle app ».
3. Renseigner les informations générales requises : le nom de l’application, la langue principale par défaut, la catégorie sectorielle principale et la classification d’âge.
4. Compiler et uploader le build binaire de production directement depuis l’environnement de développement Xcode ou en utilisant l’utilitaire d’importation automatisé Transporter.
5. Associer le build binaire téléversé à la version de la fiche store en cours de rédaction, puis compléter intégralement le volet relatif à la confidentialité des données (App Privacy).

La section App Privacy : le point de blocage le plus fréquent

Désormais, vous devez respecter les directives strictes liées à iOS 14. En effet, depuis son déploiement, Apple exige une transparence absolue de la part des éditeurs de logiciels. Ainsi, vous devez cartographier et déclarer précisément chaque type d’information collectée par l’application : 

• Des données de localisation
• Des identifiants publicitaires
• Des coordonnées de contact
• Ou un historique de navigation

En plus, spécifiez sa finalité commerciale ou technique et indiquez si ces informations sont techniquement liées ou non à l’identité réelle de l’utilisateur.

Ces déclarations génèrent automatiquement un encadré synthétique public appelé « Nutritional Label ». Il est notamment visible par tous les internautes sur la fiche publique de l’App Store. Toute discordance entre les déclarations effectuées dans ce formulaire et le comportement technique réel des scripts ou des SDK tiers intégrés au code source entraîne un rejet immédiat de la part de l’équipe de modération d’Apple.

Soumettre à la review Apple

Vous avez saisi l’ensemble des métadonnées éditoriales ? De même pour le livrable binaire associé ? Il ne vous reste plus qu’à cliquer sur le bouton « Soumettre pour vérification ». Comptez en moyenne entre 1 à 3 jours de délai moyen de traitement des équipes de l’App Store. 

À noter que : Apple met à disposition des éditeurs une procédure exceptionnelle appelée Expedite Review. Cette demande d’accélération manuelle est exclusivement réservée à la résolution de vulnérabilités de sécurité critiques. Idem à la correction d’un bug bloquant totalement l’usage d’une application déjà présente en production. D’ailleurs, la demande doit être dument justifiée. 

Étape 4 : soumettre l’application sur Google Play Console

Publier une application sur Android présente de fortes similitudes structurelles avec la méthode Apple. Néanmoins, il adopte une terminologie logicielle propre. À cela s’ajoute une organisation ergonomique spécifique au sein de la Google Play Console.

Créer l’application et la fiche store

Voici les étapes à suivre : 

1. Se connecter à l’interface Google Play Console puis cliquer sur le bouton d’action « Créer une application ».
2. Définir la nature par défaut du produit (s’agit-il d’une application utilitaire ou d’un jeu vidéo), préciser son modèle économique (gratuit ou payant) et choisir la langue de référence.
3. Remplir la section dédiée à la fiche de la boutique principale en important l’icône, la description courte, le texte de présentation détaillé et la suite de captures d’écran.
4. Renseigner l’ensemble des formulaires de conformité obligatoires du tableau de bord : lien vers la politique de confidentialité, notation IARC, et configuration de la section de sécurité des données (Data Safety Section).

Uploader le bundle et configurer les tracks

Depuis le mois d’août 2021, Google a rendu obligatoire le format de publication binaire standardisé AAB (Android App Bundle). Celui-ci vient remplacer l’ancien format historique APK pour les nouvelles soumissions. Ce qui permet à Google Play de générer des fichiers d’installation allégés et optimisés pour chaque modèle de smartphone utilisateur. Cela réduit ainsi la bande passante nécessaire au téléchargement.

La console d’administration de Google organise le déploiement binaire autour de 4 niveaux de canaux de diffusion distincts (tracks) :

[ Internal Testing ] ➔ [ Closed Testing ] ➔ [ Open Testing ] ➔ [ Production ]

Il est formellement conseillé d’exploiter la piste Internal Testing (Test interne) en amont de toute mise en ligne officielle. Ce canal permet de diffuser instantanément le build de production à un panel de 100 testeurs désignés au sein de votre organisation. Plus besoin de subir les délais d’attente liés aux examens de conformité globaux de Google.

La Data Safety Section : l’équivalent Android de l’App Privacy

La Data Safety Section est la déclaration obligatoire sur Google Play. Elle décrit justement de manière exhaustive les types de données collectées et partagées par l’application. Il en sera de même des pratiques de sécurité mises en œuvre. Par exemple : le chiffrement des flux en transit. 

À l’instar de la politique d’Apple, ce module impose une rigueur d’analyse totale. Les robots d’inspection de Google effectuent des analyses statiques du code. De quoi vérifier que les bibliothèques logicielles embarquées ne collectent pas d’informations à l’insu de l’éditeur ou de l’utilisateur final.

Quels sont les motifs de refus les plus fréquents et comment les éviter ? 

Publier une application sur l’App Store et Google Play ne garantit pas toujours votre réussite. Certains éditeurs essuient des refus. Voici quelques exemples et des conseils. 

Une politique de confidentialité absente ou inaccessible :

l’adresse URL configurée renvoie vers une erreur de serveur (code 404), la page n’est pas optimisée pour les terminaux mobiles ou le texte légal omet de mentionner explicitement le nom exact de l’application concernée.

Des achats in-app qui contournent le système natif du store :

toute vente de biens numériques ou d’abonnements débloquant des fonctionnalités au sein de l’application doit transiter obligatoirement par les infrastructures de paiement d’Apple (StoreKit) ou de Google (Billing Library). L’intégration masquée d’une passerelle de paiement tierce (comme un formulaire Stripe web direct) pour éviter les commissions des stores est passible d’un rejet immédiat.

Une application trop limitée fonctionnellement :

Apple rejette systématiquement les projets logiciels qui ne sont que de simples répliques visuelles d’un site web existant dénuées de valeur ajoutée. C’est ce qu’on appelle : technologie de type wrapper web pur. Idem des applications n’exploitant aucune fonctionnalité native du système. Exemple : des notifications push, des capteurs, ou un mode hors ligne. 

Des métadonnées trompeuses :

les visuels d’illustration affichent des fonctionnalités ou des interfaces graphiques qui n’existent pas ou ne sont pas encore codées au sein du binaire soumis à l’examen.

Un crash lors de la phase de review :

l’équipe de modération humaine d’Apple teste manuellement l’application sur de vrais terminaux. L’application se ferme de manière inopinée lors de l’authentification initial ? Ou sur l’écran d’accueil ? Le verdict de refus est immédiat.

Alors, comment prémunir votre entreprise contre ces risques financiers et opérationnels ? Notre conseil : utilisez des outils de distribution contrôlés. Tel est le cas de TestFlight sur iOS et les pistes de tests internes sur Android. Ils permettent de confronter l’application à une diversité de configurations matérielles réelles avant la soumission finale aux modérateurs.

Comment publier les mises à jour de votre application : ce qui change et ce qui reste identique

Le cycle de vie d’un actif logiciel implique la publication régulière de correctifs techniques et de nouvelles fonctionnalités. Le processus de mise à jour s’appuie sur la même méthodologie que la soumission initiale. La différence ? il requiert un incrément mathématique strict du numéro de version. Exemple : passer de la version 1.0.0 à 1.0.1. Le tout se fait au sein des fichiers de configuration du code source. Les identifiants uniques de l’application (Bundle ID sur iOS et Package Name sur Android) doivent rester rigoureusement identiques. Sinon, vous créerez un nouveau produit distinct sur le store au lieu d’écraser l’ancien.

La question est : comment minimiser le risque de régression technique lors du déploiement d’une mise à jour majeure ? Google Play intègre un mécanisme de publication progressive appelé Staged Rollout. Cet outil permet de diffuser le nouveau build de manière segmentée et contrôlée. Par exemple : cibler d’abord 10 % des utilisateurs, puis 50 %, pour atteindre 100 % après quelques jours. Vous avez détecté un bug imprévu via vos outils de monitoring ? Le déploiement peut être suspendu instantanément. De quoi protéger le reste de votre parc d’utilisateurs. 

De son côté, Apple propose un dispositif similaire baptisé Phased Release. Il est accessible directement depuis l’interface d’App Store Connect. D’ailleurs, il étale la mise à jour sur une période fixe de 7 jours. C’est une sécurité industrielle majeure pour promouvoir son application mobile après le lancement en toute sérénité.

Conclusion

Publier une application sur l’App Store et Google Play ne doit pas être traitée comme une simple tâche technique de fin de projet. Elle exige un alignement parfait entre vos ingénieurs, vos graphistes et vos responsables juridiques. Donc, anticipez la création de vos comptes institutionnels. En plus, verrouillez la conformité de vos politiques de traitement des données. Ainsi, vous supprimez les frictions administratives qui retardent la mise sur le marché de votre innovation informatique.

Vous planifiez le déploiement d’un produit numérique stratégique ? Et, vous souhaitez sécuriser cette phase critique ? Les architectes logiciels et directeurs techniques de notre agence sur mesure vous accompagnent de la signature de vos builds jusqu’à la mise en ligne opérationnelle sur les stores.

Discutez de la publication de votre application avec nos experts.