Exigences de la fiche Google Play : la checklist complète des visuels
Avant de tout envoyer sur Google Play, mieux vaut avoir les specs exactes sous les yeux — car Play Console rejette les visuels dont une dimension manque ou dont le format est incorrect, et les règles diffèrent suffisamment de l'App Store pour ne pas pouvoir réutiliser les mêmes fichiers à l'aveugle. Voici la checklist complète dans un tableau, suivie d'une courte note sur chaque ligne et des deux ou trois pièges les plus fréquents. Chaque spec est vérifiée auprès de l'aide de Play Console (2026) ; les sources sont en bas de page.
La spec complète des visuels de la fiche Google Play
| Binaire de l'appli | — | AAB (Android App Bundle) | Les nouvelles applications doivent être publiées en .aab, pas en APK — obligatoire depuis août 2021. |
Ce tableau couvre toute la surface de la fiche : trois visuels graphiques, trois champs de texte, et le binaire. Le reste de cet article détaille chaque ligne.
Icône de l'appli : 512 × 512, attention aux coins
L'icône est un fichier unique de 512×512 px, envoyé en PNG 32 bits avec canal alpha, de moins de 1 Mo. Play l'affiche dans un masque arrondi, donc tout ce que tu places dans les coins extrêmes sera rogné. Conçois un carré complet, centre les éléments importants, et laisse le masque faire son travail. C'est l'un des rares visuels Play qui conserve l'alpha — le feature graphic et les captures d'écran, non.
Feature graphic : obligatoire, mais affiché seulement parfois
Le feature graphic est une bannière 1024×500 px en JPEG ou PNG 24 bits sans canal alpha. C'est un visuel obligatoire — impossible de compléter la fiche sans lui. Le piège, c'est qu'il n'apparaît sur la fiche elle-même que si tu ajoutes aussi une vidéo promotionnelle, car il sert alors d'image de couverture pour la vidéo. Même sans vidéo, Play utilise le feature graphic dans d'autres emplacements promotionnels, il n'est donc jamais facultatif. Traite-le comme un vrai travail de design, pas un remplissage : le texte doit survivre au recadrage sur différentes surfaces, et il doit rester à l'écart des mentions promotionnelles interdites par Play (section suivante).
Captures d'écran : la règle du 2:1, celle que tout le monde rate
Il faut au minimum 2 captures d'écran par type d'appareil avant que Play autorise la publication, et jusqu'à 8 par type d'appareil. Chacune est en JPEG ou PNG 24 bits sans alpha, jusqu'à 8 Mo. La règle de dimension est celle qui fait rejeter les envois : chaque côté doit être entre 320 et 3840 px, et le côté le plus long ne peut pas dépasser deux fois le plus court. Cette seconde partie est le plafond de ratio 2:1. Un panneau marketing vertical de, disons, 1080×2400 fait 2,22:1 — au-delà de la limite, et Play le rejette même si les deux côtés sont dans la plage 320–3840.
C'est le rejet de capture d'écran Play le plus fréquent, et c'est pourquoi un jeu de captures App Store ne s'importe pas tel quel dans Play. Les captures iPhone dépassent souvent le 2:1 ; Play ne les acceptera pas. Il te faut un canevas téléphone qui atteigne ou reste sous 2:1 — un portrait 9:16 en 1080×1920 est un choix sûr et courant — et si tu reprends un design de l'App Store, il doit être redimensionné pour respecter le ratio, pas simplement réexporté.
Les captures d'écran tablette (7 pouces et 10 pouces) suivent les mêmes règles de 320–3840 px et de ratio 2:1, et sont facultatives, mais si ton appli prend en charge les tablettes, ça vaut la peine de remplir les deux emplacements — Play affiche une fiche tablette distincte à ces utilisateurs. Wear OS, Android TV et Chromebook ont chacun leurs propres emplacements de captures d'écran si tu cibles ces formats.
Limites de texte — et les mots interdits
Les trois champs de texte ont des limites de caractères strictes : 30 pour le titre de l'appli, 80 pour la description courte, 4000 pour la description complète. Les espaces et symboles comptent partout. Ce sont les mêmes limites que celles que partage App Store Connect pour certains champs, mais ne présume de rien — Play compte à sa façon et tronque net à la limite.
Le piège qui n'a rien à voir avec la longueur : Google interdit les formulations promotionnelles ou de performance dans l'icône, le titre, la description courte et le nom du développeur. Des mots comme « gratuit », « meilleur », « n°1 », « top », « nouveau », « promo » ou « réduction » — tout ce qui suggère un classement dans le store, un prix, ou une promotion — fera signaler la fiche. La même règle s'étend au feature graphic et à la vidéo promo : aucune revendication de performance dans le store, aucune distinction que tu n'as pas reçue de Google, et aucun bandeau d'appel à l'action du type « Télécharger maintenant » incrusté dans le visuel. Les badges officiels « Best Of » ou Choix de la rédaction décernés par Google Play sont l'exception que tu es autorisé(e) à afficher.
Le binaire : AAB, pas APK
Depuis août 2021, toute nouvelle application sur Google Play doit être publiée sous forme d'Android App Bundle (.aab) plutôt qu'en APK autonome. Play génère les APK spécifiques à chaque appareil à partir de ton bundle. Ce n'est pas un visuel de fiche, mais ça fait partie de la même checklist « puis-je vraiment publier », et c'est une étape que les personnes ayant publié il y a des années n'attendent pas. Les applications existantes basées sur APK peuvent continuer à se mettre à jour, mais une toute nouvelle fiche exige l'AAB.
La place de Mokbi
Mokbi est conçu pour te fournir des visuels conformes à Play directement depuis l'éditeur. Les exports de captures d'écran incluent un format téléphone conforme à Play qui respecte le plafond 2:1, donc tu n'envoies jamais un jeu que Play rejette pour être trop haut. L'outil produit aussi le feature graphic 1024×500 à partir du même projet, et rédige et traduit le texte de la fiche — titre, description courte, description complète — en 50 langues, dans les limites de caractères de Play pour chaque locale, pour que rien ne soit tronqué en plein milieu d'une phrase. La conception est gratuite dans un éditeur avec filigrane ; l'export et la publication illimités passent par un abonnement — Solo à €29.99/mois ou Studio à €49.99/mois, sans achat ponctuel.
Mokbi ne s'arrête pas aux fichiers — il les publie. Une fois le design près de l'icône, le feature graphic 1024×500, les captures d'écran conformes 2:1 et le texte de fiche en 50 langues prêts, Mokbi pousse la fiche et les visuels directement vers Google Play via la Play Developer API. Pour l'App Store, il prépare la version dans App Store Connect prête à soumettre — Apple exige que la soumission finale et la revue restent manuelles. Ce que l'outil t'évite, c'est de te battre avec les dimensions et les consoles : les canevas ont déjà la bonne forme, les exports correspondent déjà aux specs du tableau ci-dessus, et l'envoi se fait pour toi.
En résumé
- Icône : 512×512, PNG 32 bits avec alpha, moins de 1 Mo, coins sécurisés.
- Feature graphic : 1024×500, JPEG ou PNG 24 bits, sans alpha, sans mention promotionnelle.
- Captures d'écran : 2 à 8, chaque côté 320–3840 px, le plus long ≤ 2× le plus court, sans alpha. Attention au plafond 2:1.
- Texte : titre ≤ 30, court ≤ 80, complet ≤ 4000. Pas de « gratuit / meilleur / n°1 / top / nouveau / promo ».
- Binaire : les nouvelles applications publient un AAB, pas un APK.
Google révise ces tableaux de temps en temps. Si tu lis ceci bien après la date de publication, vérifie les chiffres actuels dans l'aide de Play Console avant de soumettre. En 2026, les specs ci-dessus correspondent à ce que listent les sources ci-dessous :
- Ajouter des visuels d'aperçu pour présenter votre application — Aide Play Console (specs icône, feature graphic, captures d'écran).
- Bonnes pratiques pour votre fiche — Aide Play Console (limites titre/description, formulations interdites).
- FAQ Android App Bundle — Android Developers (exigence AAB pour les nouvelles applications).