· Publishing · 6 min de lecture

Checklist de soumission d'app : chaque élément pour les deux stores (2026)

Checklist de soumission d'app : chaque élément pour les deux stores (2026)
TL;DR. Le pré-vol complet pour publier sur les deux stores. Deux comptes développeur (Apple $99/an, Google $25 une fois), puis une pile d'éléments, de textes et de réponses juridiques propre à chaque store — les deux listes ne se recoupent pas. Les captures d'écran ne sont ici qu'une ligne parmi d'autres, pas tout le travail. Les règles qui rejettent un build avant même qu'un humain ne le voie sont les exigences de SDK et d'API cible, ainsi que le sas de test fermé de Google. Les dates bougent : vérifie chacune dans la documentation Apple et Google le jour de ta soumission.

Ton app est prête. Les deux stores exigent maintenant une pile d'éléments et de réponses avant de te laisser passer, et les deux piles ne se ressemblent pas. Voici la liste complète : chaque élément et chaque champ demandés par App Store Connect et Google Play Console, classés par store, avec les règles de build 2026 qui bloquent un envoi avant même que l'examen ne commence.

Nous avons déjà une checklist consacrée aux seules captures d'écran (lien en bas de page). Celle-ci est la liste élargie — les captures d'écran n'y sont qu'un élément parmi d'autres, à côté des icônes, des feature graphics, du texte de fiche, des formulaires de confidentialité, des classifications d'âge et des exigences de build qui conditionnent l'envoi lui-même.

Les exigences et les échéances évoluent. Considère chaque règle datée ci-dessous comme un repère à vérifier dans la documentation officielle du store le jour de ta soumission, pas comme un fait figé.

Étape 0 : les deux comptes développeur

Impossible de soumettre quoi que ce soit sans un compte sur chaque store, et les modèles tarifaires diffèrent :

  • Apple Developer Program — $99 par an (en USD, facturés dans ta devise locale). C'est un abonnement récurrent. Laisse-le expirer et tes apps disparaissent de l'App Store jusqu'au renouvellement.
  • Google Play Console — $25, payés une seule fois à l'inscription. Paiement unique, non remboursable, sans renouvellement.
  • Vérification d'identité dans les deux cas. Les comptes personnels comme les comptes d'organisation passent par une vérification. Les comptes d'organisation sur Google ont besoin d'un numéro D-U-N-S ; Apple vérifie l'entité juridique pour les inscriptions d'organisation. Prévois quelques jours pour cette étape avant de planifier ta sortie.

Apple : ce que demande App Store Connect

Le build :

  • Binaire compilé avec un SDK à jour. Depuis avril 2025, les apps iOS et iPadOS doivent être compilées avec le SDK iOS 18 (Xcode 16) ou une version ultérieure pour être envoyées. Apple a annoncé qu'à partir du 28 avril 2026, les envois nécessiteront le SDK iOS 26 ou une version ultérieure — vérifie quel SDK est en vigueur le jour de ta soumission.
  • Icône de l'app intégrée au build. Apple récupère l'icône depuis le catalogue d'assets de l'app ; il n'y a pas d'envoi d'icône séparé dans App Store Connect. Une icône manquante ou mal formée fait échouer la validation à l'envoi.
  • ID de bundle unique, signature valide et réponses de conformité à l'exportation. Les questions sur le chiffrement et l'exportation apparaissent à l'envoi — la plupart des apps répondent avec une exemption standard, mais tu dois répondre.

Éléments visuels :

  • Captures d'écran pour l'iPhone 6,9 pouces. Au moins une, jusqu'à dix. Les tailles acceptées incluent 1320 × 2868, 1290 × 2796 et 1260 × 2736 (portrait). Apple redimensionne automatiquement ce jeu pour les iPhone plus petits, donc le jeu 6,5 pouces n'est nécessaire que si tu omets complètement le 6,9 pouces.
  • Captures d'écran iPad si l'app prend en charge l'iPad. Le jeu 13 pouces est en 2064 × 2752 ou 2048 × 2732 (portrait). Obligatoire si ton app fonctionne sur iPad.
  • Vidéo App Preview facultative par taille d'appareil, de 15 à 30 secondes.

Texte de fiche :

  • Nom de l'app (30 caractères maximum) et sous-titre (30 maximum).
  • Mots-clés — un seul champ de 100 caractères, séparés par des virgules, jamais affiché aux utilisateurs mais qui alimente la recherche.
  • Description (4 000 caractères maximum) et texte promotionnel (170 maximum, modifiable sans nouveau build).
  • URL d'assistance, et une URL marketing si tu le souhaites.

Juridique, confidentialité et classification :

  • URL de la politique de confidentialité. Obligatoire pour toute app.
  • Réponses App Privacy — l'« étiquette nutritionnelle ». Tu déclares quelles données ton app et ses SDK tiers collectent et comment elles sont utilisées. Ces réponses sont obligatoires pour soumettre, et elles s'affichent sous forme d'étiquette de confidentialité sur ta fiche produit.
  • Classification d'âge. Renseignée via un questionnaire. Apple est passé à un système de classification d'âge plus granulaire (avec des paliers 13+, 16+ et 18+) qui s'affiche sur les appareils sous iOS 26 et versions ultérieures, donc revérifie tes réponses si ta dernière classification date de l'ancien système.
  • Catégorie principale (et secondaire en option), plus un parcours de suppression de compte dans l'app si celle-ci permet la création de compte.

Google : ce que demande Play Console

Le build :

  • Un Android App Bundle (.aab), pas un APK, pour les nouvelles apps.
  • Niveau d'API cible. Les nouvelles apps et mises à jour doivent actuellement cibler Android 15 (niveau d'API 35) ou supérieur. Google a annoncé qu'à partir du 31 août 2026, les nouvelles apps et mises à jour devront cibler Android 16 (niveau d'API 36) — vérifie le niveau en vigueur au moment de ta soumission.
  • Build de release signé, généralement via Play App Signing.

Éléments visuels :

  • Icône de l'app — 512 × 512 px, PNG 32 bits, moins de 1 Mo.
  • Feature graphic — 1024 × 500 px, JPEG ou PNG 24 bits sans alpha. C'est un élément de fiche obligatoire sur Play, sans équivalent chez Apple, et c'est la bannière affichée en haut de ta fiche.
  • Au moins 2 captures d'écran téléphone (jusqu'à 8). JPEG ou PNG 24 bits, chaque côté entre 320 et 3 840 px, format 16:9 ou 9:16. Les captures d'écran tablette et autres formats sont optionnelles sauf si tu cibles ces appareils.
  • Vidéo promo facultative sous forme d'URL YouTube.

Texte de fiche :

  • Nom de l'app (30 caractères maximum).
  • Description courte (80 maximum) — la première ligne que lisent les utilisateurs.
  • Description complète (4 000 maximum).

Juridique, confidentialité et classification :

  • URL de la politique de confidentialité. Obligatoire.
  • Formulaire Data safety. L'équivalent chez Google de l'étiquette de confidentialité d'Apple — tu déclares quelles données tu collectes, partages, et comment elles sont traitées. Obligatoire avant de pouvoir publier, et doit correspondre au comportement réel de ton app.
  • Questionnaire de classification de contenu (IARC). Génère des classifications d'âge par région à partir de tes réponses.
  • Catégorie de l'app, plus déclarations de public cible et de publicités. Si une partie du public est composée d'enfants, des exigences supplémentaires s'appliquent.

Les règles 2026 qui rejettent un build avant l'examen

Il ne s'agit pas de finitions — elles bloquent purement et simplement l'envoi ou la publication, donc mieux vaut les vérifier en premier :

  • Le SDK minimum d'Apple. Les envois nécessitent le SDK iOS 18 (Xcode 16) depuis avril 2025, le SDK iOS 26 devenant le plancher aux alentours du 28 avril 2026 selon l'annonce d'Apple. Compile avec un vieux SDK et App Store Connect rejette le binaire à l'envoi.
  • Le niveau d'API cible de Google. Les nouvelles apps et mises à jour ciblent aujourd'hui Android 15 (API 35), avec un passage à Android 16 (API 36) à partir du 31 août 2026 selon le calendrier annoncé par Google. Un niveau cible trop bas bloque la publication.
  • Le sas de test fermé de Google pour les comptes personnels. Les comptes développeur personnels créés après le 13 novembre 2023 doivent faire tourner un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs avant de pouvoir demander l'accès en production. (Google a abaissé ce seuil depuis 20 testeurs fin 2024.) Les comptes d'organisation vérifiés en sont exemptés. C'est celle qui surprend le plus les développeurs solo — elle ajoute deux semaines minimum entre « l'app est prête » et « l'app est en ligne », donc lance le test fermé tôt.

Le pré-vol commun (les deux stores)

Quelques vérifications s'appliquent des deux côtés et sont faciles à oublier dans la précipitation de la sortie :

  • Légendes de captures d'écran dans la langue de chaque locale. Des légendes en anglais dans une fiche allemande ou japonaise sont signalées. La langue des légendes doit correspondre à la locale de la fiche.
  • Les éléments et les textes correspondent à l'app. Si une capture d'écran ou une description montre une fonctionnalité, l'app publiée doit réellement la posséder. Les deux stores rejettent les métadonnées qui exagèrent les capacités de l'app.
  • Aucun prix ni URL externe intégré aux captures d'écran. Les prix ont leur place sur la fiche du store, pas dans le visuel ; les incrustations du type « visite notre site » entraînent des rejets.
  • Les déclarations de confidentialité reflètent la réalité. L'étiquette de confidentialité d'Apple et le formulaire Data safety de Google doivent tous deux refléter ce que ton code et tes SDK font réellement.
  • Un compte de test fonctionnel, si l'app est protégée par une connexion, à transmettre à l'examinateur dans les notes d'examen.

Où Mokbi intervient

La majeure partie de cette checklist reste de ton ressort — le compte, le build, les réponses de confidentialité, les classifications. Mokbi se charge des éléments visuels et textuels, la partie qui dévore le plus d'heures quand tu la fais à la main pour deux stores et de nombreuses langues.

  • Les éléments visuels. Il produit les captures d'écran pour les deux stores aux tailles requises, ainsi que le feature graphic pour Play, à partir d'un seul projet — tu ne recadres donc pas le même visuel pour chaque classe d'appareil.
  • Le texte de fiche. Il rédige ton nom, ton sous-titre, ta description et ta description courte, puis traduit toute la fiche en 50 langues pour que chaque locale parte avec des légendes et des textes cohérents.
  • La publication de la fiche finalisée. Mokbi envoie les éléments et les textes finalisés à ta place : directement sur Google Play via la Play Developer API, et préparés dans App Store Connect sous forme de version prête à soumettre. Apple exige que ce dernier clic sur Submit et l'examen viennent de toi — c'est une règle d'Apple, pas une limite de Mokbi.

L'objectif n'est pas de remplacer la checklist — c'est d'en retirer les colonnes éléments et traduction pour que le reste tienne en une après-midi plus courte.

À lire ensuite

Ouvrir l'éditeur →