Publier une application sur l’App Store et Google Play : étapes et délais de revue

Publier une application sur l’App Store et Google Play demande, avant toute soumission, un compte développeur chez chacun des deux éditeurs, une fiche de présentation, des déclarations de confidentialité et une version conforme à leurs exigences techniques de l’année. Apple examine ensuite chaque version, la plupart en moins de 48 heures ; Google peut prendre jusqu’à sept jours, davantage dans certains cas. Ce guide dit au nom de qui ouvrir les comptes, ce qu’il faut préparer, les exigences de 2026 et les causes de refus les plus fréquentes.

Il s’adresse aux dirigeants et aux DSI qui font développer une application mobile et veulent savoir ce qui se passe entre la fin du développement et la mise en ligne. La soumission technique revient à l’équipe qui développe ; les décisions décrites ici reviennent à l’entreprise.

Quelles sont les étapes pour publier une application ?

Publier une application mobile se fait en six étapes, les mêmes chez Apple et chez Google : ouvrir le compte, déclarer l’application, remplir sa fiche et ses déclarations, envoyer une version, la faire tester, puis la soumettre à la revue.

• Ouvrir le compte développeur. Le programme Apple Developer pour l’App Store, la Google Play Console pour Android. Comptez la vérification de l’identité ou de l’entreprise dans le calendrier.
• Déclarer l’application. Son nom, son identifiant technique (le Bundle ID chez Apple, le nom de package chez Google), qui ne changera plus une fois une version envoyée.
• Remplir la fiche et les déclarations. Description, captures d’écran, catégorie, classification par âge, politique de confidentialité, données collectées.
• Envoyer une version. L’application compilée et signée, conforme aux exigences techniques en vigueur.
• Tester. TestFlight chez Apple ; les tests interne, fermé et ouvert chez Google, avec un test fermé obligatoire pour certains comptes.
• Soumettre à la revue, puis publier. Une fois la version acceptée, la publication peut être immédiate ou programmée.

Quel compte développeur ouvrir, et au nom de qui ?

Le compte développeur d’une application d’entreprise s’ouvre au nom de l’entreprise, en compte organisation, pas au nom du prestataire ni d’un salarié. Chez Apple, le nom de l’organisation s’affiche comme vendeur sur l’App Store, alors qu’un compte individuel affiche le nom de la personne.

Une application publiée depuis le compte d’un prestataire peut être transférée, mais l’opération est lourde. Chez Apple, le titulaire du compte cédant lance le transfert et celui du compte receveur l’accepte ; l’application garde ses avis, ses notes et son Bundle ID. Chez Google, le transfert se demande depuis le compte d’origine, est approuvé par le compte cible et examiné par le support ; certains rapports ne suivent pas l’application et les services associés, comme Firebase, sont à reconfigurer.

Que faut-il préparer avant de soumettre une application ?

Avant de soumettre une application, il faut préparer sa fiche, ses déclarations de confidentialité et de quoi permettre l’examen : la plupart des refus viennent d’une pièce manquante, pas du code.

• Une politique de confidentialité. Une adresse publique, exigée par les deux éditeurs, y compris pour une application qui ne collecte rien chez Google.
• La déclaration des données collectées. Les « App Privacy details » chez Apple, la section « Sécurité des données » chez Google. Elles couvrent aussi les SDK tiers intégrés (mesure d’audience, publicité, paiement) : demandez la liste à votre équipe de développement.
• La suppression du compte. Si l’application permet de créer un compte, elle doit permettre de le supprimer depuis l’application (règle 5.1.1(v) d’Apple) ; Google demande en plus un lien web, déclaré dans la section Sécurité des données.
• Un compte de démonstration. Si l’application demande une connexion, l’examinateur doit recevoir un compte qui fonctionne, et le serveur doit rester allumé pendant la revue (règle 2.1 d’Apple).
• Une fiche fidèle. Des captures qui montrent l’application telle qu’elle est (règle 2.3 d’Apple), une description, une catégorie et le questionnaire de classification par âge.
• Le test fermé chez Google, pour les comptes personnels concernés : douze testeurs inscrits sans interruption pendant quatorze jours, à recruter avant la date de lancement visée.

Quelles exigences techniques s’appliquent en 2026 ?

En 2026, Apple impose de construire les applications avec Xcode 26 et Google impose de cibler Android 16 pour toute nouvelle application ou mise à jour. Ces seuils montent chaque année : une application qui ne suit pas ne peut plus être mise à jour, et chez Google elle n’est plus proposée à une partie des nouveaux utilisateurs.

Ces mises à jour imposées sont à prévoir dans le budget de l’application, au même titre que les corrections. Notre guide du contrat de maintenance applicative dit comment les inclure.

Combien de temps dure la revue d’Apple et de Google ?

Apple indique examiner au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures. Google prévient que l’examen peut durer jusqu’à sept jours, ou davantage dans des cas exceptionnels, pour certains comptes et les applications soumises à un examen approfondi.

Ces délais sont ceux annoncés par les éditeurs, sans engagement : un refus relance un cycle complet. Apple accepte une demande de revue accélérée pour corriger un bug critique ou pour une application liée à un événement daté. Chez Google, le test fermé de quatorze jours, quand il s’applique, s’ajoute avant même la première soumission en production.

Pourquoi une application est-elle refusée ?

Une application est le plus souvent refusée parce qu’elle est incomplète ou mal décrite, plus rarement pour son code. Les règles de revue d’Apple, publiques, décrivent les cas suivants.

• Une application incomplète (2.1). Plantages, liens cassés, contenu provisoire, compte de démonstration absent ou serveur éteint pendant l’examen.
• Des métadonnées trompeuses (2.3). Captures ou description qui ne correspondent pas à l’application.
• Un simple site web emballé (4.2). Une application doit apporter plus qu’un site repris dans une coque mobile.
• Des applications en double (4.3). Plusieurs variantes quasi identiques de la même application.
• La confidentialité (5.1.1). Politique absente, textes de demande d’autorisation (localisation, caméra, contacts) qui ne disent pas à quoi sert l’accès, suppression du compte manquante.
• Un service réglementé soumis par le mauvais compte. Une application bancaire ou de santé doit être publiée par l’entité qui fournit le service, pas par son prestataire.

Questions fréquentes

Que se passe-t-il après la publication ?

Après la publication, chaque mise à jour repasse par la revue, et les exigences des deux éditeurs montent chaque année : une application mobile se maintient, comme un service. Le choix de la technologie compte aussi : notre comparatif Flutter, .NET MAUI ou React Native aide à le faire, et le cahier des charges reste le point de départ.

L’équipe iones développe des applications iOS et Android en nearshore depuis la Tunisie, pour des entreprises françaises et européennes, les publie sur les comptes de ses clients et les maintient dans la durée. Vous pouvez nous écrire pour un premier échange.