Rejets de métadonnées sur l'App Store : corriger 2.3.x, 2.3.7, 4.3 et 5.2.1
Tu viens de recevoir l'e-mail. Le statut est passé à Metadata Rejected, et la note du centre de résolution cite un numéro de directive que tu as dû aller chercher. La bonne nouvelle, c'est qu'un rejet de métadonnées se résout généralement plus vite : tu ne renvoies pas de build, tu modifies la fiche de version et tu resoumets.
La première chose à vérifier, c'est le numéro de directive dans le message du centre de résolution, car il indique exactement quel champ corriger. Cet article couvre les quatre que tu es le plus susceptible de voir sur un rejet de fiche. Les numéros de directives sont parfois renumérotés au fil du temps, donc ceux mentionnés ici correspondent aux App Store Review Guidelines actuelles.
D'abord, le mécanisme : ce que signifie vraiment « Metadata Rejected »
Un statut Metadata Rejected vise ta fiche sur le store — nom de l'app, sous-titre, mots-clés, description, captures d'écran, aperçus, URL — pas l'app compilée. Comme le signalement porte sur les métadonnées, tu n'as pas besoin d'un nouveau binaire. Tu modifies le champ cité dans App Store Connect, tu gardes le build existant rattaché à la version, et tu resoumets.
Deux précisions s'imposent. D'abord, resoumettre te remet quand même dans la file de revue : tu évites un nouveau build, mais pas une nouvelle revue — un humain ou un passage automatisé y regarde de nouveau. Ensuite, corriger le seul champ cité par Apple n'immunise pas le reste de ta fiche. Les évaluateurs peuvent signaler une autre directive au prochain passage. Nettoie toute la fiche pendant que tu y es, pas seulement la phrase qui t'a été citée.
Directive 2.3.3 — les captures d'écran doivent montrer l'app en action
Ce qui la déclenche. Tes captures d'écran ne montrent pas l'app en train de faire son travail. Le cas classique : un premier emplacement occupé par un écran de démarrage, une page de connexion, ou un visuel avec une accroche mais aucune interface réelle. Ça se déclenche aussi quand une capture montre une fonctionnalité que l'app n'a pas, ou fait référence à un appareil ou une interface d'une autre plateforme.
Avant : le premier emplacement est ton logo centré sur un dégradé avec la phrase « la façon la plus intelligente de planifier ta semaine », sans la moindre interface de l'app visible.
Après : le premier emplacement est un vrai écran issu d'un parcours central — une vue de semaine avec de vraies entrées remplies — accompagné d'une légende courte nommant le bénéfice au-dessus de l'appareil. Les évaluateurs (et les utilisateurs) voient ce que fait l'app dès la miniature. Garde les légendes marketing et les cadres d'appareil, mais assure-toi que l'interface en dessous est réelle et à jour.
C'est un changement de métadonnées : remplace les images dans la fiche de version, resoumets, aucun nouveau build.
Directive 2.3.7 — les mots-clés doivent décrire ton app, pas à tromper la recherche
Ce qui la déclenche. C'est la directive sur le mésusage des mots-clés. Elle se déclenche quand tes métadonnées sont gonflées de termes qui ne décrivent pas ton app : des marques déposées qui ne t'appartiennent pas, les noms d'apps plus grandes ou plus populaires, un langage de prix dans le mauvais champ, des noms de célébrités ou de personnalités publiques glissés pour la portée, ou des expressions génériques bourrées pour capter des recherches. Le champ de mots-clés de 100 caractères est le principal fautif, mais le sous-titre et le nom sont aussi signalés. Les noms d'app sont plafonnés à 30 caractères, et le langage de prix ou promotionnel n'a rien à faire dans le nom, le sous-titre ou les captures d'écran.
Avant (champ mots-clés) : une liste qui inclut les noms de trois apps plus grosses de ta catégorie, le nom d'un créateur connu, et quelques mots tendance sans rapport, dont aucun ne décrit une fonctionnalité que tu as livrée.
Après : des mots-clés qui correspondent à ce qu'un utilisateur chercherait réellement pour trouver ta fonction — les tâches qu'elle accomplit, le problème qu'elle résout, les mots issus de tes propres écrans. Chaque terme doit pointer vers quelque chose que l'app fait réellement.
Avant (sous-titre) : une phrase de comparaison qui te positionne face à une app rivale nommée.
Après : un sous-titre qui énonce en termes simples le résultat que ton app apporte, sans le nom d'une autre marque. Le sous-titre sert de contexte pour ton app, pas à emprunter le trafic de quelqu'un d'autre.
Directive 4.3 — spam et applications quasi identiques
Ce qui la déclenche. La 4.3 concerne la ressemblance. Elle se déclenche quand tu publies plusieurs apps quasi identiques sous des bundle IDs séparés (un build distinct par ville, par équipe, par client, au lieu d'une seule app avec ces variations à l'intérieur), ou quand une soumission est difficile à distinguer d'un produit déjà largement disponible. C'est souvent un problème de concept, mais c'est la fiche qui rend la duplication visible — des descriptions et captures d'écran identiques entre tes propres apps sont un signe fort.
Avant : cinq apps sur ton compte avec la même mise en page, la même liste de fonctionnalités, et un texte qui ne varie qu'en remplaçant un nom de ville ou d'équipe.
Après : une seule app qui porte ces variations comme options ou achats intégrés, avec une fiche qui décrit ce qui la distingue réellement. Si tu as vraiment des produits distincts, fais en sorte que chaque fiche montre ce qui est réellement différent, dans les captures d'écran et la description, pas seulement un remplacement de nom propre.
La 4.3 peut exiger plus qu'une simple modification des métadonnées si l'app sous-jacente est vraiment un clone superficiel. Mais quand le problème est que tes fiches se lisent comme des clones les unes des autres, différencier le texte et les captures d'écran est une correction de métadonnées.
Directive 5.2.1 — la propriété intellectuelle d'autrui dans tes métadonnées
Ce qui la déclenche. Utiliser un contenu tiers protégé sur lequel tu n'as pas de droits — marques déposées, œuvres protégées, noms copiés — n'importe où dans ton bundle, ton nom de développeur ou tes métadonnées. Une variante fréquente est un décalage entre l'app ou la marque de la fiche et l'entité qui l'a réellement soumise, ce qui amène Apple à se demander qui possède le nom.
Avant : un nom de marque ou de plateforme que tu ne possèdes pas placé dans le titre, le sous-titre ou le champ de mots-clés de ton app pour capter son trafic de recherche.
Après : le nom de ton propre produit dans le titre, le sous-titre et les mots-clés. Si tu t'intègres réellement à une plateforme tierce et dois le mentionner, garde toute mention factuelle de compatibilité dans la description, là où c'est autorisé, et hors du nom et du sous-titre. Si tu as développé l'app pour un client propriétaire de la marque, soumets-la depuis le compte de l'entité qui la possède, ou fais-toi ajouter à son équipe, pour que le nom du vendeur et la marque correspondent.
L'aspect sans nouveau build, résumé
Dans les quatre cas, si la correction se situe dans la fiche de version — texte et images — tu la corriges dans App Store Connect et tu resoumets le même binaire. Tu n'incrémentes pas de numéro de build et tu n'attends pas de traitement. C'est la voie rapide qu'un rejet de métadonnées t'offre. En contrepartie, tu repasses par la revue : mieux vaut donc relire toute la fiche à la lumière de ces quatre directives avant de resoumettre, plutôt que de les corriger une par une à chaque rejet.
Où Mokbi aide (et où il n'aide pas)
La plupart des problèmes 2.3.7 démarrent à l'étape de rédaction, quand un champ de mots-clés ou un sous-titre est gonflé pour capter de la portée. L'IA de Mokbi rédige le texte de ta fiche — nom, sous-titre, mots-clés, description — à partir de ce que ton app fait réellement, ce qui t'écarte des réflexes de bourrage et d'emprunt de marque qui provoquent un rejet de mots-clés en premier lieu. Elle localise ensuite ce texte en 50 langues, pour que tu n'aies pas à réécrire un champ de mots-clés à la main pour chaque marché en réintroduisant le même piège à chaque fois.
Restons lucides sur la limite. Ça réduit tes risques de signalement 2.3.x ou 5.2.1 sur la formulation ; ça ne peut pas promettre l'approbation, et ça ne décide pas de ce qu'il y a dans ton build. La revue reste la décision d'Apple. Un texte conforme et fidèle à l'app supprime les raisons faciles et auto-infligées de se faire rejeter. Mokbi ne publie pas automatiquement ta fiche — il produit le texte et les captures d'écran ; tu les valides et les soumets.