Soumettre une app sur l'App Store et Google Play : guide pratique

Vous avez fini votre application Flutter. Les tests passent, l'UI est soignée, le build release compile sans erreur. Maintenant vient la partie que personne ne documente vraiment bien : la soumission sur les stores. Voici le guide que j'aurais voulu avoir pour mes premières publications.

Avant de commencer : les comptes développeur

Apple Developer Program : 99 €/an, paiement annuel, accès à App Store Connect, TestFlight et toute la suite Apple. La création de compte peut prendre de 24 heures à quelques jours si Apple demande des vérifications supplémentaires. Ne laissez pas ça pour la dernière minute.

Google Play Console : 25 € une seule fois (frais d'enregistrement unique). Plus rapide à ouvrir qu'un compte Apple, mais la première application passe par une période de review initiale pouvant durer plusieurs semaines.

Checklist pré-soumission iOS

Avant d'ouvrir App Store Connect, vérifiez :

• Le CFBundleVersion et CFBundleShortVersionString dans Info.plist sont à jour
• Le build est signé avec le bon certificat Distribution (pas Debug, pas Ad Hoc)
• Tous les frameworks sont bien inclus dans le bundle (pas de références à des frameworks dev-only)
• La politique de confidentialité est accessible via une URL publique (obligatoire si l'app collecte des données)
• Les screenshots couvrent tous les appareils requis : iPhone 6,7" et iPad si votre app supporte l'iPad
• L'icône est présente dans toutes les tailles requises (1024×1024 pour l'App Store, plus les tailles réduites)

Les permissions

Chaque permission iOS déclarée dans Info.plist doit avoir un message de justification (NSLocationWhenInUseUsageDescription, etc.) et doit être réellement utilisée dans l'application. Apple rejette les applications qui déclarent des permissions non utilisées.

Checklist pré-soumission Android

• versionCode et versionName dans build.gradle (ou pubspec.yaml pour Flutter) sont incrémentés
• L'APK ou l'AAB est signé avec votre keystore de production (pas le keystore de debug)
• Le keystore de production est sauvegardé hors de votre machine (perte = impossibilité de mettre à jour l'app)
• Les permissions dans AndroidManifest.xml sont justifiées et nécessaires
• L'application cible le targetSdkVersion requis par Google (mis à jour régulièrement)

Les délais de review

App Store : en moyenne 24 à 48 heures pour les mises à jour, jusqu'à 5-7 jours pour une première soumission. Pendant les semaines de sortie de nouvelles versions iOS ou autour des fêtes, les délais peuvent doubler. Planifiez vos lancements en conséquence.

Google Play : les mises à jour peuvent passer en quelques heures. La première application soumise est en review manuelle qui peut prendre plusieurs semaines — Google l'annonce clairement. Les applications suivantes bénéficient d'un traitement plus rapide.

Les causes de rejet les plus fréquentes

Côté Apple

Métadonnées incorrectes : les screenshots ne correspondent pas à l'application, la description mentionne des fonctionnalités absentes, ou le titre contient des mots-clés considérés comme du keyword stuffing.

Politique de confidentialité manquante ou incomplète : si votre application collecte quoi que ce soit (y compris via des SDKs tiers comme RevenueCat), une politique de confidentialité accessible publiquement est obligatoire.

Guideline 4.2 — Design minimum de fonctionnalité : Apple considère que l'application n'offre pas assez de valeur ou trop peu de fonctionnalités. Les applications trop minimalistes ou trop similaires à des applications natives iOS peuvent être rejetées.

Côté Google

Politique sur les logiciels malveillants et les permissions : Google inspecte les permissions demandées et les compare aux fonctionnalités déclarées. Une application qui demande l'accès aux contacts sans raison évidente sera rejetée.

Cible d'API trop ancienne : Google impose un targetSdkVersion minimum qui augmente chaque année. Les applications qui ne le respectent pas ne peuvent plus être mises à jour.

Automatiser avec Fastlane

À partir de deux applications, l'automatisation de la soumission devient rentable. Fastlane est l'outil standard : il gère les screenshots automatiques (via Screengrab pour Android, Snapshot pour iOS), l'upload des builds et les métadonnées.

Ma configuration Flutter utilise Fastlane pour les deux stores avec une lane commune qui incrémente le numéro de version, build le release, génère les screenshots sur simulateur et uploade sur les deux stores. Ce qui prenait deux heures manuellement se fait en 20 minutes de façon reproductible.

Après la publication

La publication n'est pas la fin. Les premiers avis arrivent souvent dans les 48 heures — et certains signalent des bugs que vos tests n'avaient pas couverts. Prévoyez une période de monitoring intensive la première semaine après chaque release majeure.