Publier une app Android et iOS : la checklist complète (Play Store, App Store)

La checklist pour une soumission acceptée du premier coup, côté Android et côté iOS.

Publier une app, ce n'est pas juste appuyer sur un bouton. Entre les comptes développeur, les tests obligatoires, la signature des builds et les questionnaires de confidentialité, un premier envoi refusé fait facilement perdre une à deux semaines. Cette checklist découpe la mise en ligne en deux parcours, Android (Google Play Store) et iOS (App Store Apple), plus le socle commun (fiche store, RGPD).

Deux points piègent presque tout le monde : côté Android, un compte développeur récent doit passer par un test fermé de 12 testeurs pendant 14 jours avant d'accéder à la production ; côté iOS, tout le pipeline de publication passe par Xcode, donc par un Mac. Coche au fur et à mesure, ta progression est enregistrée automatiquement dans ton navigateur.

1. Avant de commencer, les comptes

À régler en tout premier : la validation d'un compte développeur peut prendre plusieurs jours.

Compte Google Play Console (frais unique de 25 dollars) Vérification d'identité obligatoire. Pour un compte perso, Google peut demander une pièce d'identité et un délai de vérification.

Play Console

Compte Apple Developer (99 dollars par an) Abonnement annuel, sans lui pas d'envoi sur l'App Store ni de TestFlight. Prévois le renouvellement dans ton calendrier.

Apple Developer

Sauvegarder ta clé de signature Android (keystore) Si tu perds ce fichier et son mot de passe, tu ne peux plus jamais mettre à jour l'app sous le même identifiant. Range-le dans un gestionnaire de mots de passe et une sauvegarde hors ligne.

2. Version Android (Play Store)

La grosse contrainte côté Google : le test fermé imposé aux nouveaux comptes. C'est du temps, pas de la technique, donc à lancer tôt.

Générer un App Bundle signé (.aab) Le Play Store n'accepte plus les APK pour les nouvelles apps : c'est le format Android App Bundle qui est attendu.

Recruter au moins 12 testeurs pour le test fermé Obligatoire pour les comptes développeur perso récents : 12 testeurs inscrits et restés opt-in pendant 14 jours consécutifs avant de pouvoir demander la production. Prépare une liste d'e-mails (Google) fiables et préviens-les à l'avance.

La règle Google

Lancer le test fermé et tenir les 14 jours Le délai de 14 jours est incompressible : c'est souvent lui qui décale une sortie. Vérifie que les testeurs ont bien accepté l'invitation et gardé l'app installée, sinon le compteur ne valide pas.

Configurer la connexion Google (OAuth 2.0) Dans Google Cloud Console, crée un identifiant OAuth de type Android avec le nom du package et le SHA-1 de ta clé de signature. Renseigne aussi l'écran de consentement OAuth.

Google Cloud

Ajouter le SHA-1 de la clé de signature du Play Store Piège classique : avec Play App Signing, c'est Google qui re-signe ton app. Récupère le SHA-1 de la clé de signature d'app fournie dans la Play Console et ajoute-le à ton client OAuth, sinon le login Google marche en test mais casse en production.

Remplir le formulaire « Sécurité des données » Le « Data safety » doit correspondre exactement à ce que collecte réellement l'app. Une déclaration incohérente entraîne un rejet.

3. Version iOS (App Store)

Ici tout tourne autour de l'écosystème Apple : un Mac, Xcode, et surtout des guidelines de review plus strictes que chez Google.

Disposer d'un Mac et de Xcode à jour Compilation, signature et envoi passent par Xcode, qui ne tourne que sur macOS. Sans Mac (ou service de build macOS en cloud), pas de publication iOS possible.

Certificats, App ID et profils de provisionnement Gérés dans Xcode ou sur le portail Apple Developer. La signature de code est indispensable pour installer sur un vrai iPhone et pour l'envoi.

Tester via TestFlight avant soumission Envoie un build sur TestFlight pour le tester sur de vrais appareils et le partager à tes bêta-testeurs avant la review officielle.

TestFlight

App complète et sans bug (guideline 2.1) Apple refuse toute app qui plante, contient des liens morts, des fonctions inachevées ou du contenu de remplissage. Teste chaque parcours avant d'envoyer.

Assez de fonctionnalités natives (guideline 4.2) Un simple site web emballé dans une app se fait refuser. Apporte une vraie valeur d'app (fonctions natives, hors-ligne, notifications).

Proposer « Sign in with Apple » si besoin (guideline 4.8) Si ton app offre une connexion via un service tiers (Google, Facebook), Apple impose généralement d'offrir aussi Sign in with Apple comme alternative.

Achats intégrés pour tout bien numérique (guideline 3.1.1) Le contenu numérique consommé dans l'app (abonnements, options) doit passer par les achats intégrés Apple, pas par un paiement externe.

4. Fiche store et référencement (ASO)

Commun aux deux stores : c'est ce qui décide si ton app est trouvée et téléchargée.

5. Conformité et légal

Politique de confidentialité en ligne (URL publique) Obligatoire pour Apple et Google, avec le détail des données collectées (RGPD).

Questionnaires de confidentialité renseignés « App Privacy » (Apple) et « Sécurité des données » (Google) doivent correspondre à la réalité de l'app.

Compte de démonstration pour la review Si l'app demande une connexion, fournis des identifiants de test valides aux équipes de validation, sinon elles ne peuvent pas tester et refusent.

Questions fréquentes

Combien de temps faut-il tester une app avant de la publier sur le Play Store ?

Pour un compte développeur Google Play personnel créé récemment, Google impose un test fermé avec au moins 12 testeurs restés inscrits pendant 14 jours consécutifs avant de pouvoir demander l'accès à la production. Anticipe : ces 14 jours sont incompressibles, recrute tes testeurs bien avant la date de sortie visée.

Peut-on publier une app iOS sans Mac ?

Non, pas de manière fiable. La compilation, la signature et l'envoi d'une app iOS vers l'App Store passent par Xcode, qui ne tourne que sur macOS. Il te faut donc un Mac (ou un service de build cloud sous macOS) et un compte Apple Developer à 99 dollars par an.

Comment bien configurer la connexion Google (OAuth) dans une app Android ?

Il faut déclarer dans la console Google Cloud un identifiant OAuth 2.0 de type Android en renseignant le nom du package et l'empreinte SHA-1 de la clé de signature. Le point clé : sur le Play Store, c'est Google qui signe ton app (Play App Signing). Tu dois donc enregistrer aussi le SHA-1 de la clé de signature de l'app fournie par la console Play, sinon la connexion Google échouera en production alors qu'elle marchait en test.

Quelles sont les principales guidelines Apple à respecter pour être accepté ?

Les motifs de refus les plus fréquents : app incomplète ou avec des bugs (guideline 2.1), fonctionnalité trop pauvre ou site web emballé (4.2 Minimum Functionality), absence de politique de confidentialité, réponses inexactes au questionnaire App Privacy, connexion Sign in with Apple manquante quand un autre login social est proposé (4.8), et paiements de biens numériques hors achats intégrés (3.1.1). Fournis aussi un compte de démonstration si l'app demande une connexion.

Publier une application mobile