Comment préparer votre fiche App Store et Google Play

Une fiche App Store et Google Play nécessite les mêmes éléments de base : une icône, des captures d'écran aux tailles acceptées par chaque store, un nom et des descriptions respectant des limites de caractères strictes, une URL de politique de confidentialité, une déclaration de confidentialité (les labels App Privacy d'Apple et le formulaire Data safety de Google) et un questionnaire de classification d'âge. L'absence de l'un de ces éléments bloque la soumission ; préparez-les donc pendant que votre application est encore en développement.

Voici les exigences actuelles pour les deux stores, ce que les réviseurs vérifient et une checklist que vous pouvez compléter en un après-midi.

Tout ce dont vous avez besoin en un coup d'œil

App icon

Apple. L'icône de l'App Store est un PNG de 1024 x 1024, carré, sans transparence et sans coins arrondis (iOS s'en charge). Dans les applications Capacitor, elle se trouve dans ios/App/App/Assets.xcassets/AppIcon.appiconset. Xcode 26 supporte aussi les icônes à calques via Icon Composer pour l'effet Liquid Glass sur iOS 26, mais une image unique de 1024 est toujours acceptée.

Google. Play nécessite un upload séparé en PNG 32 bits de 512 x 512, jusqu'à 1 Mo. Google applique lui-même le masque arrondi et l'ombre, donc envoyez un carré plein bord à bord. L'icône de lancement in-app est distincte et doit être une icône adaptative.

Generate all native icon and splash sizes from one source image:

bun add -d @capacitor/assets
mkdir -p assets
# put icon.png (1024x1024) and splash.png (2732x2732) in ./assets
bunx capacitor-assets generate

Règles appliquées par les deux stores : pas de badges comme « Gratuit » ou « #1 », pas de captures d'écran montrant les appareils ou logos d'autres marques, rien qui imite une autre application.

Captures d'écran

Les captures d'écran sont le facteur principal de l'installation. La plupart des gens ne lisent jamais la description.

Tailles des captures d'écran App Store

Le mode paysage utilise les mêmes chiffres inversés. Formats PNG ou JPEG, sans canal alpha. Vous pouvez envoyer de 1 à 10 captures par taille et de 0 à 3 aperçus d'app.

Une surprise Capacitor courante : les nouveaux projets supportent l'iPad par défaut. Si vous ne voulez pas faire de captures iPad, réglez la cible sur Destinations supportées iPhone uniquement avant votre premier upload. Si vous livrez le support iPad, les testeurs l'utiliseront et rejetteront les layouts cassés.

Tailles des captures Google Play

• 2 à 8 captures par type d'appareil (téléphone, tablette 7 pouces, tablette 10 pouces, Chromebook, Wear OS, Android XR, TV, Automotive).
• JPEG ou PNG 24 bits, sans canal alpha.
• Chaque côté doit mesurer entre 320 et 3840 pixels ; le grand côté ne doit pas dépasser deux fois le petit.
• Pour les téléphones, utilisez au moins 1080 x 1920 (portrait) ou 1920 x 1080 (paysage) et au moins quatre captures d'écran, sinon l'app n'est pas éligible à certaines mises en avant.
• Des captures d'écran pour tablette sont nécessaires si vous voulez apparaître comme optimisé pour tablette.

Comment les capturer

1. Lancez l'app sur un simulateur de la bonne taille. Sur l'iOS Simulator, utilisez un iPhone 17 Pro Max pour le 6,9” et appuyez sur Cmd+S. Sur Android, utilisez un émulateur avec un écran de 1080 x 1920 ou plus et le bouton appareil photo de la barre d'outils de l'émulateur.
2. Remplissez l'app avec des données de démo réalistes. Les états vides ne vendent rien.
3. Masquez l'UI de debug et nettoyez la barre de statut (xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100).
4. Ajoutez une courte légende au-dessus de chaque capture d'écran qui indique le bénéfice, pas le nom de la fonctionnalité.
5. Keep the first two screenshots the strongest. They show in search results.

Des outils comme les templates Figma, Fastlane snapshot/screengrab ou des générateurs de cadres de captures d'écran en ligne peuvent produire les versions encadrées dans toutes les tailles.

N'utilisez jamais de captures d'écran montrant des fonctionnalités inexistantes, et n'incluez pas de badges Google Play dans vos captures App Store (et inversement).

Nom, sous-titre et descriptions

App Store

• Nom (30 caractères): la marque suivie d'un court descripteur si possible, par exemple « Acme : Gestionnaire de dépenses ».
• Sous-titre (30 caractères): le bénéfice principal. Indexé pour la recherche.
• Mots-clés (100 octets)séparés par des virgules, sans espaces après les virgules, sans mots déjà présents dans le nom ou le sous-titre, sans noms de marques concurrentes, le singulier suffit.
• Texte promotionnel (170 caractères): affiché au-dessus de la description, modifiable sans nouvelle version. Utilisez-le pour vos offres ou actualités.
• Description (4 000 caractères): n'est pas indexé pour la recherche sur l'App Store, alors écrivez pour les utilisateurs. Commencez par une phrase expliquant ce que fait l'application.

Google Play

• Titre (30 caractères): pas d'emojis, de MAJUSCULES ou de mots comme « meilleur », « gratuit » ou « n°1 » sauf s'ils font partie de la marque.
• Description courte (80 caractères): shown on the listing above the fold.
• Description complète (4 000 caractères): est indexée pour la recherche. Mentionnez vos mots-clés principaux naturellement ; le bourrage de mots-clés entraîne le rejet des fiches.

For more on writing metadata and the mistakes that hurt ranking, see Métadonnées App Store : ce que les développeurs doivent savoir.

Politique de confidentialité

Les deux stores exigent une URL de politique de confidentialité publique. Elle doit :

• Soyez accessible sans connexion et sans être un téléchargement PDF.
• Name the developer or company as in the store listing.
• Listez les données collectées, pourquoi, avec qui vous les partagez, combien de temps vous les conservez et comment les utilisateurs peuvent demander leur suppression.
• Match what you declare in the privacy labels and Data safety form.

Ajoutez aussi un lien vers la politique dans l'application (écran paramètres ou compte). Si les utilisateurs peuvent créer un compte, les deux stores exigent une suppression de compte depuis l'app ; Google exige aussi un lien web permettant de demander la suppression sans réinstaller l'app. Notre guide de suppression de compte et guide de politique de confidentialité pour Android allez plus loin.

Étiquettes de confidentialité Apple

Dans App Store Connect, ouvrez l'application et allez dans App Privacy. Votre réponse :

1. Vous ou vos partenaires tiers collectez-vous des données via cette app ?
2. Pour chaque type de données (coordonnées, localisation, identifiants, données d’utilisation, diagnostics, informations financières…) : précisez l’usage, si elles sont liées à l’identité de l’utilisateur et si elles servent au tracking.

Le « tracking » a un sens précis : lier les données de votre app à celles d’autres apps ou sites web à des fins publicitaires, ou les partager avec des courtiers en données. Si vous faites du tracking, vous devez aussi utiliser le prompt App Tracking Transparency.

Les labels doivent correspondre à votre manifeste de confidentialité (PrivacyInfo.xcprivacy) et à ceux des SDK que vous incluez. Consultez notre guide du privacy manifest pour les apps iOS.

You can update App Privacy answers at any time without a new build.

Sécurité des données Google Play

Dans la Play Console, allez dans Règles et programmes > Contenu de l'application > Sécurité des données. Vous déclarez :

• Quels types de données l'app collecte et lesquels elle partage avec des tiers.
• Si les données sont chiffrées en transit.
• Whether users can request deletion.
• Pour chaque type : l'usage (fonctionnalités, analytics, publicités, prévention de la fraude…) et si la collecte est optionnelle.

Google peut rejeter des mises à jour si la déclaration ne correspond pas à ce que fait l'app, par exemple un SDK qui envoie l'ID publicitaire alors que vous n'avez déclaré aucun identifiant.

La plupart des erreurs de Data safety viennent des SDK. Faites un tableau de chaque SDK natif et plugin dans package.json, ios/App/Podfile ou Package.swift, et android/app/build.gradle, puis lisez les recommandations Data safety de chaque fournisseur.

Age rating

Apple. Dans Informations sur l'app > Classification d'âge vous répondez à des questions sur la violence, le contenu sexuel, la vulgarité, les jeux d'argent, le contenu généré par les utilisateurs, la messagerie, les publicités, et plus encore. Les classifications d'Apple sont 4+, 9+, 13+, 16+ et 18+. Les apps avec du contenu généré par les utilisateurs non modéré ou un accès web ouvert reçoivent des classifications plus élevées. Répondez honnêtement ; Apple vérifie. Consultez notre guide sur les classifications d'âge de l'App Store.

Google. Dans Contenu de l'app > Classification du contenu, remplissez le questionnaire IARC. Il génère simultanément des classifications pour chaque région (ESRB, PEGI, USK et autres). Vous devez également compléter Public cible et contenu; choisir une audience incluant des enfants déclenche les exigences de la politique Families.

Autres déclarations de contenu sur Google Play

Avant de pouvoir publier, la Play Console demande tout cela sous App content:

• Politique de confidentialité
• Accès à l'application (identifiants pour les testeurs si du contenu est protégé)
• Publicités (l'application contient-elle des publicités ?)
• Classification du contenu
• Public cible et contenu
• Data safety
• Déclaration d'application gouvernementale
• Déclaration de fonctionnalités financières
• Déclaration d'application de santé
• Utilisation de l'identifiant publicitaire (si votre SDK l'exige)

Accès pour la revue et notes

Si une partie de l'app nécessite une connexion, fournissez un compte de démo fonctionnel pour les deux stores. Le compte ne doit pas expirer, ne doit pas nécessiter de 2FA sur un téléphone que vous contrôlez, et doit permettre d'accéder à toutes les fonctionnalités, y compris les options payantes. Dans App Store Connect, ajoutez-le sous Informations de révision de l'app; sur Google Play, sous App access. Ajoutez une courte note expliquant les fonctionnalités peu évidentes, les prérequis matériels ou l'emplacement des achats in-app. Notre guide de révision d'app pour la première fois détaille ce que les réviseurs recherchent.

Localisation

Les deux stores vous permettent de localiser le nom, les descriptions, les mots-clés (Apple) et les captures d'écran par langue. Localiser uniquement les métadonnées, même si l'UI de l'app est en anglais, améliore souvent la conversion sur les marchés non anglophones. Apple indexe également certaines locales secondaires par pays (par exemple, les métadonnées en espagnol (Mexique) sont indexées sur le store US), ce qui vous offre de l'espace supplémentaire pour vos mots-clés.

Ce que vous pouvez modifier après la release

Sur iOS, une nouvelle version implique normalement un nouveau binaire. Avec Capgo live updates vous pouvez déployer des correctifs JS et UI sans revue du store, mais les changements de métadonnées passent toujours par App Store Connect.

Raisons courantes de blocage des fiches

1. Privacy policy URL returns 404 or requires login.
2. Les captures d'écran montrent une version différente de l'app, du contenu fictif ou l'UI d'une autre plateforme.
3. Support iPad activé mais pas de captures d'écran iPad, ou une mise en page iPad défectueuse.
4. Data safety says “no data collected” while an analytics SDK runs.
5. Compte de démo manquant ou expiré.
6. Bourrage de mots-clés dans la description Google Play.
7. Nom ou icône trop proche d'une application ou d'une marque existante.
8. URL de support ou e-mail de contact manquant.

Checklist

• Icône iOS 1024 x 1024 dans l'app, icône Play 512 x 512 envoyée
• Graphisme de présentation Play 1024 x 500
• Captures iPhone 6,9” (ou 6,5”), iPad 13” si le support iPad est activé
• Au moins quatre captures de téléphone en 1080p pour Google Play
• Nom, sous-titre et description courte respectant les limites
• Mots-clés (App Store) choisis, sans doublons avec le nom
• Description et notes de release rédigées
• URL de la politique de confidentialité active et liée à l'app
• Labels de confidentialité et manifeste de confidentialité conformes
• Formulaire de sécurité des données rempli, SDKs vérifiés
• Questionnaires de classification d'âge remplis sur les deux stores
• Déclarations de contenu Play App complétées
• Compte de démo et notes de review ajoutés
• URL de support et e-mail de contact configurés

Une fois la fiche prête, envoyez d'abord un build aux testeurs. Comment distribuer vos apps iOS et Android aux testeurs couvre TestFlight, les canaux de test Play et les alternatives.