Comment remplir la fiche de votre app sans vous faire refuser

Pour remplir une fiche d'app sans refus, importez des captures d'écran aux tailles exactes exigées par chaque boutique, respectez les limites de caractères des textes, évitez les affirmations que vous ne pouvez pas prouver, comme « n° 1 » ou « meilleure », et vérifiez si vos produits relèvent d'une catégorie réglementée avec ses propres règles. Les problèmes de fiche comptent parmi les refus les plus faciles à éviter.

Ce guide couvre le volet fiche et métadonnées : spécifications des éléments, règles de rédaction, affirmations qui déclenchent un signalement, et catégories de produits réglementées avec leurs propres règles. Connaître les règles avant de soumettre évite la plupart de ces problèmes.

Périmètre. Cette liste de contrôle couvre uniquement le risque lié à la fiche et aux métadonnées. Elle ne remplace ni un examen complet par App Review ni la revue de publication de Google Play, et elle ne couvre ni les fonctionnalités de l'app, ni les plantages, ni les déclarations de confidentialité, ni les paiements, ni la suppression de compte, ni l'accès du relecteur. Tout cela figure à la fin, sous « Ce que cette liste de contrôle ne couvre pas ». Dans tout le texte, chaque règle porte l'étiquette [Obligatoire] (une règle explicite de la boutique ou une vérification à l'envoi), [Recommandation de la plateforme] (l'orientation annoncée par la boutique, appliquée à la discrétion du relecteur) ou [Conseillé] (notre propre bonne pratique). Ceci n'est pas un avis juridique.

D'abord, pourquoi cela piège autant de monde

Apple comme Google examinent vos métadonnées, pas seulement votre app. Vos captures d'écran, le nom, le sous-titre, la description et les mots-clés font partie de ce qui est approuvé, et les règles s'appliquent à chaque localisation que vous soumettez, pas seulement à l'anglaise. Une fiche qui passe en anglais peut donc être signalée pour une affirmation restée dans les captures en allemand.

Deux boutiques, deux règlements :

• Apple publie les App Store Review Guidelines. Les règles sur les métadonnées relèvent surtout de la directive 2.3 (métadonnées exactes), les règles de contenu de la 1.1 (contenu répréhensible) et les catégories restreintes de la 1.4 (préjudice physique).
• Google publie ses règles Play Console, dont une politique sur les métadonnées spécifique et les règles par catégorie dans le règlement du programme pour les développeurs.

Les deux ensembles de règles se recoupent plus qu'ils ne diffèrent.

Les spécifications des éléments : dimensions, quantités et formats

Mettez d'abord les éléments aux spécifications, car un fichier à la mauvaise taille ou au mauvais format est intercepté par le validateur d'envoi avant qu'un humain ne le voie. Ces données sont celles de 2026, et Apple change les tailles de captures quand de nouveaux appareils sortent : confirmez donc les valeurs en vigueur dans les spécifications des captures d'écran d'Apple et dans le guide des éléments de présentation de Google avant d'exporter quoi que ce soit.

Deux pièges à l'envoi attrapent les marques le plus souvent, et ce sont tous deux des erreurs de validation au moment de l'envoi (pas des refus d'App Review) : la transparence (les deux boutiques refusent à l'envoi une capture ou une icône avec couche alpha) et les dimensions exactes en pixels (le validateur d'Apple n'accepte que les tailles de sa liste, donc un export hors format est refusé). Exportez des fichiers RVB aplatis à une taille acceptée et les deux disparaissent.

Captures : cadres iPhone, cadres Android, un jeu ou deux

[Conseillé] Si vous le pouvez, produisez des captures d'aspect natif pour chaque boutique, car le guide des éléments de Google déconseille les images d'appareils et demande que les captures représentent l'expérience réelle dans l'app. C'est l'idéal.

Si vous ne produisez qu'un seul jeu à réutiliser, faites-le avec des cadres iPhone plutôt qu'Android. L'asymétrie en est la raison : Apple n'accepte pas les captures montrant des appareils ou une interface Android (elles doivent refléter l'expérience Apple), tandis que Google est plus souple et y accepte couramment les captures encadrées dans un iPhone. Un jeu iPhone va donc plus loin qu'un jeu Android. Nous ne pouvons pas promettre que Google approuvera un cadrage particulier : traitez « un seul jeu iPhone pour les deux » comme un raccourci pratique, pas comme une garantie.

Les limites de caractères

[Obligatoire] Vos champs de texte ont des limites strictes. Les dépasser n'est pas le risque (le champ vous arrête tout simplement) ; le risque, c'est ce que vous y mettez.

Quelques règles de rédaction qui provoquent un refus à elles seules :

• [Obligatoire] Pas de prix dans le nom de l'app ni dans les champs de métadonnées. La directive 2.3.7 d'Apple précise que les noms, sous-titres et autres métadonnées ne doivent pas contenir de prix ni de termes étrangers à ce champ. Mettez les offres dans la description ou le texte promotionnel.
• [Recommandation de la plateforme] Pas d'emoji, de mots en majuscules ni de caractères spéciaux répétés dans le titre. Google est strict sur ce point ; tenez-vous-en au nom de votre marque et, au plus, à un court descriptif.
• [Obligatoire] Pas de noms d'apps concurrentes dans votre nom, vos mots-clés ou votre description (directive 2.3.7 d'Apple). Les références à l'autre plateforme relèvent d'une règle à part, traitée plus bas.

Notre guide d'optimisation App Store pour les marques Shopify explique comment utiliser ces champs pour convertir et gagner en visibilité, pas seulement pour passer l'examen.

Les affirmations qui déclenchent un signalement

C'est là que les marques se font prendre, parce que le geste marketing le plus tentant est souvent celui que les boutiques refusent.

Affirmations de classement ou de supériorité non étayées (« n° 1 », « meilleure », « la mieux notée »)

[Recommandation de la plateforme] Évitez les affirmations de classement et de supériorité que vous ne pouvez pas étayer. Apple considère les affirmations invérifiables comme des métadonnées inexactes au titre de la directive 2.3, et la politique sur les métadonnées de Google restreint les affirmations de classement et de récompense (« n° 1 », « meilleure », « app de l'année », icônes de prix) dans les titres et les éléments graphiques. C'est un signalement courant et facile à éviter.

Que faire à la place : rendez toute affirmation précise et étayée, ou supprimez-la. « La confiance de 40 000 clients » convient si c'est vrai et démontrable ; « la meilleure app de shopping » non. Dans le doute, décrivez ce que fait l'app plutôt que de la couronner.

Des captures qui montrent ce que l'app ne fait pas

[Obligatoire] La directive 2.3.3 d'Apple exige que les captures montrent l'app en usage réel. Si une capture annonce une fonctionnalité absente de la version, simule un écran qui n'existe pas, ou si sa légende promet ce que l'app ne fournit pas, elle est refusée pour métadonnées inexactes. Les habillages marketing et les légendes sont autorisés ; l'écran en dessous doit être une partie réelle de l'app, et ce qu'on en affirme doit être vrai. En pratique : ne mettez une fonctionnalité sur une capture que si un relecteur peut ouvrir l'app et la trouver.

Prix et texte promotionnel sur vos visuels

[Obligatoire chez Apple] / [Recommandation de la plateforme chez Google] La directive 2.3.7 d'Apple traite les prix et les termes promotionnels génériques dans les noms, sous-titres, captures et aperçus comme des métadonnées inexactes (en plus, ils se périment). Le guide des captures de Google déconseille fermement le texte de classement, de récompense et de prix ou promotion (« Soldes », « -50 % », « Gratuit ») sur les visuels, à titre de bonne pratique plutôt que de blocage absolu à l'envoi. Dans les deux cas, faites passer les offres par les champs prévus pour elles (le texte promotionnel d'Apple se met à jour sans nouvelle soumission) plutôt que de les graver dans les visuels.

Grossièretés et langage répréhensible

[Obligatoire] Les métadonnées de la boutique doivent convenir à tous les âges même si votre app porte une classification plus élevée : les grossièretés ou le langage cru dans le nom, le sous-titre, les captures ou la description entraînent donc un refus au titre des règles d'Apple sur le contenu répréhensible (directive 1.1) et de leur équivalent chez Google. Gardez les métadonnées propres, quel que soit le ton habituel de votre marque.

Mentions de l'autre plateforme (surtout chez Apple)

[Obligatoire] Apple ne veut pas que sa boutique renvoie vers celle d'un autre. Une référence à Google Play, à Android ou à « également disponible sur… » n'importe où dans vos métadonnées Apple, dans le texte ou sur les captures, entraîne un refus au titre de la directive 2.3.10, qui limite votre fiche aux informations pertinentes et interdit les noms et visuels d'autres plateformes mobiles. C'est facile à manquer parce que cela ressemble à une information utile, et cela nous a piégés à deux reprises. Retirez toute mention de l'autre plateforme de la fiche Apple. (Google est plus souple, même s'il n'y a pas non plus de raison d'y mentionner Apple.)

Contenu inachevé ou provisoire

[Obligatoire] Les métadonnées (et l'app) doivent être une représentation finie et fidèle. Un « lorem ipsum », un « demo » ou un « test » oubliés, ou la capture d'un écran inachevé, se lisent comme une soumission incomplète et entraînent un refus ; Apple n'héberge d'ailleurs pas d'apps en bêta sur l'App Store. Notez la nuance : une véritable précommande ou un état « bientôt disponible » est légitime lorsqu'il passe par les outils de précommande de la boutique. La règle porte en réalité sur le contenu inachevé ou trompeur : nettoyez donc les éléments provisoires et vérifiez que ce qui est montré correspond à ce qui est publié.

Bourrage de mots-clés et termes hors sujet

[Obligatoire] Entasser des termes à la mode sans rapport, des noms de marques concurrentes ou des mots-clés répétés dans vos champs est signalé au titre de la directive 2.3.7 d'Apple et des règles anti-spam de Google. Les mots-clés doivent correspondre à ce qu'est réellement votre app.

Catégories réglementées : produits pour adultes et alcool

Quelques catégories de produits ont leurs propres règles en plus de tout ce qui précède. Le cannabis, le CBD, la vape et la nicotine sont assez restreints (viables dans certains cas, pas dans d'autres) pour avoir leur propre guide : pouvez-vous vendre du CBD, du cannabis ou des vapes via une app mobile ? Les deux catégories qui surprennent le plus les marques de retail généraliste sont traitées ici. Comme toujours, ces règles évoluent et varient selon les pays : vérifiez la politique en vigueur et prenez un avis juridique ; ceci n'est pas une décision.

Les marques de bien-être sexuel peuvent tout à fait publier, mais la photographie produit et les textes doivent rester non explicites, et vous devez déclarer honnêtement le contenu pour adultes dans le questionnaire de classification (le déclarer de travers est un motif de refus en soi). Une présentation soignée, de style retail, passe ; les images explicites non. L'alcool est en général publiable avec un contrôle d'âge adapté et une classification exacte, même si les détails varient selon le marché.

La liste de contrôle avant soumission

Parcourez-la avant d'appuyer sur soumettre, pour chaque localisation. Elle réduit le risque lié à la fiche et aux métadonnées ; elle ne couvre pas l'app elle-même (voir la section suivante).

Éléments

• Captures à une taille actuellement acceptée, RVB aplati, sans transparence
• Au moins 4 captures, l'icône et (pour Google) l'image de présentation aux spécifications
• Aucun appareil ni interface Android dans les captures Apple
• Chaque capture montre un écran réel présent dans cette version

Texte et affirmations

• Aucune affirmation « n° 1 », « meilleure », « la mieux notée » ou de récompense non étayée
• Toute affirmation chiffrée (« la confiance de X clients ») est exacte et défendable
• Aucun prix ni texte promotionnel dans le nom ou sur les visuels
• Aucune grossièreté ni langage cru dans aucun champ
• Aucun nom d'app concurrente
• Aucune mention de Google Play ni d'Android dans la fiche Apple
• Aucun emoji, majuscules continues ou caractère spécial dans le titre
• Aucun contenu provisoire ou inachevé ; ce qui est montré correspond à ce qui est publié

Catégorie et localisation

• Si vous êtes dans une catégorie réglementée (cannabis, vape, adultes, alcool), politique en vigueur vérifiée pour les deux boutiques
• Tout ce qui précède vérifié dans chaque localisation, pas seulement en anglais

Ce que cette liste de contrôle ne couvre pas

Passer la revue de la fiche est nécessaire, pas suffisant. L'essentiel de ce qui fait réellement refuser les apps se situe hors des métadonnées, et ce guide ne l'aborde pas volontairement :

• Accès du relecteur : des identifiants de compte de démonstration qui fonctionnent, et toute connexion ou zone restreinte que le relecteur doit atteindre.
• Backend en service : les services et API dont dépend l'app doivent être actifs pendant l'examen, pas en préproduction.
• Confidentialité et données : étiquettes de confidentialité et formulaire de sécurité des données exacts, une politique de confidentialité et les textes d'usage des autorisations.
• Paiements : usage correct des achats intégrés par rapport aux paiements externes selon le type de contenu.
• Suppression de compte : obligatoire dans l'app dès lors que celle-ci permet d'en créer une.
• Fonctionnement et stabilité : pas de plantages, pas de liens morts, pas de fonctionnalités provisoires, de vraies fonctionnalités au-delà d'un site web réempaqueté.
• Discrétion du relecteur : les deux boutiques exercent leur jugement, donc rien de tout ceci ne garantit l'approbation.

Comment NAPPS aide

NAPPS est une plateforme de création d'apps mobiles natives pour les marques Shopify et Shopify Plus. Elle prépare les fiches App Store et Google Play au lancement, avec des éléments à la bonne taille et des textes conformes, puis les publie depuis vos propres comptes Apple et Google. L'équipe vérifie les problèmes de fiche les plus courants avant la soumission : superlatifs non étayés, affirmations de captures en avance sur la version, mentions de l'autre plateforme et éléments provisoires oubliés. Pour les produits réglementés, NAPPS peut évaluer la viabilité en boutique avant que vous ne construisiez quoi que ce soit.

L'app est gratuite jusqu'à ce que vous soyez prêt à la publier : vous pouvez donc soigner la fiche avant que la date de lancement n'approche. La liste de contrôle pour lancer une app mobile Shopify couvre le reste du travail de pré-lancement.

Directement à la source

La documentation des boutiques elles-mêmes fait foi, et elle évolue : consultez-la avant une soumission.

• Apple : les App Store Review Guidelines (métadonnées en 2.3, contenu en 1.1, catégories restreintes en 1.4) et les spécifications des captures d'écran.
• Google : la politique sur les métadonnées, le guide des éléments de présentation, le règlement du programme pour les développeurs pour les catégories restreintes et les bonnes pratiques de fiche.

En résumé

Soigner la fiche est un exercice de conformité avec une poignée de pièges : des éléments à une taille acceptée et sans transparence, pas de prix ni de grossièretés dans le texte, chaque capture montrant une fonctionnalité réelle de la version, aucune mention de l'autre plateforme chez Apple, et aucune affirmation de classement non étayée. Franchir tout cela réduit le risque d'un refus lié à la fiche dans chaque localisation, ce qui compte surtout quand un lancement ou une campagne attend derrière. Cela ne couvre pas l'app elle-même : traitez-le comme une couche de contrôle, pas comme l'ensemble.

Si vous préférez ne pas l'apprendre à vos dépens, et surtout si vos produits relèvent d'une catégorie réglementée, réservez un appel de 20 minutes avec l'équipe NAPPS et nous vous donnerons une lecture franche de votre fiche et de votre viabilité en boutique avant que vous ne construisiez.