Votre build a passé l'examen, votre code est correct — et l'e-mail de rejet porte sur vos captures. C'est l'une des façons les plus frustrantes de perdre des jours sur une publication, car les rejets de captures sont presque toujours évitables et presque jamais expliqués clairement.
Les captures échouent à deux portes différentes, et la solution dépend de celle qui vous a attrapé :
- App Store Connect refuse le téléversement — un échec de validation technique, avant même le début de l'examen.
- App Review rejette la soumission — un examinateur humain signale vos métadonnées, en citant généralement un numéro de directive comme 2.3.3.
Ce guide couvre les deux, rejet par rejet, avec les références des directives et le chemin le plus rapide pour revenir à « En cours d'examen ».
Porte 1 : App Store Connect n'accepte pas le fichier #
Ce ne sont pas des rejets d'examen — le téléversement échoue simplement ou l'emplacement reste rouge. Trois causes couvrent presque tous les cas :
Mauvaises dimensions en pixels #
Chaque emplacement d'appareil n'accepte que des tailles exactes. Une image de 1290 × 2796 dans un emplacement qui attend 1320 × 2868 échoue en silence ou avec une erreur vague. C'est le blocage le plus courant le soir de la soumission — vérifiez vos fichiers avec la référence complète des tailles de capture, ou déposez-les dans notre validateur de captures gratuit, qui vous dit instantanément dans quel emplacement (le cas échéant) chaque image rentre.
Mauvais format ou profil colorimétrique #
Les captures doivent être en PNG ou JPEG de haute qualité, RGB (Display P3 et sRGB conviennent), sans transparence alpha dans les JPEG, sans exports CMYK des outils de design.
Mauvais nombre #
Chaque taille d'appareil accepte de 1 à 10 captures par langue. Zéro dans un emplacement requis bloque entièrement la soumission — une surprise classique quand vous ajoutez la prise en charge de watchOS ou visionOS et découvrez que ces plateformes ont besoin de leurs propres jeux.
Solution : régénérez aux tailles exactes requises. Si vous exportez à la main depuis un outil de design, toute cette porte disparaît avec un générateur de captures qui exporte les dimensions exactes de chaque emplacement depuis un seul design.
Porte 2 : rejets d'App Review, par directive #
Directive 2.3.3 — les captures ne montrent pas l'app en cours d'utilisation #
La grosse. La règle d'Apple : les captures doivent montrer l'app en cours d'utilisation — pas seulement le visuel de titre, la page de connexion ou l'écran de lancement.
Déclencheurs typiques :
- Un jeu de captures composé surtout de logo, slogan et visuels marketing avec peu d'interface visible
- Des écrans de connexion/onboarding comme captures principales
- Des mockups conceptuels de fonctionnalités qui ne ressemblent en rien à l'app publiée
- Des captures de l'interface d'une autre plateforme (l'app web, la version Android)
Solution : reconstruisez le jeu autour d'écrans réels. La bonne nouvelle : la mise en page qui passe l'examen — interface réelle dans un cadre d'appareil avec une courte légende — est aussi celle qui convertit le mieux. Les légendes superposées et les cadres d'appareil sont explicitement autorisés ; c'est l'interface fabriquée qui est signalée.
Directive 2.3.1 — montrer des fonctionnalités qui n'existent pas #
Si une capture démontre une fonctionnalité que l'examinateur ne trouve pas dans le build soumis, attendez-vous à un rejet (et, en cas de récidive, à pire). Cela arrive souvent innocemment : des captures marketing faites depuis une bêta avec des fonctionnalités supprimées.
Solution : vérifiez chaque capture par rapport au build que vous soumettez réellement. Mettez à jour les légendes qui promettent quoi que ce soit que la version actuelle ne fait pas.
Directive 2.3.8 — les métadonnées ne conviennent pas à tous les publics #
Les captures et prévisualisations doivent convenir à un public 4+ quel que soit l'âge minimum de votre app, car elles sont visibles par quiconque navigue. La violence, les thèmes pour adultes ou les grossièretés acceptables à l'intérieur d'une app 17+ ne le sont pas sur sa fiche.
Solution : choisissez des écrans plus sages ou recadrez/floutez le contenu problématique. Les jeux aux thèmes matures passent généralement avec des images d'ambiance plutôt que des moments de gameplay explicites.
Directive 2.3.10 — références à d'autres plateformes #
Les captures montrant des cadres d'appareils Android, des badges Google Play ou des légendes « aussi sur Android ! » sont rejetées. Cela mord les équipes qui réutilisent un jeu d'images marketing sur les deux stores.
Solution : gardez les ressources séparées par store. Si vous maintenez les deux fiches, un outil qui gère les jeux App Store et Google Play côte à côte rend le mélange difficile.
Directive 5.2 / 2.3.7 — la propriété intellectuelle d'autrui #
Des logos tiers, des photos de célébrités, des noms d'apps concurrentes, des personnages sous marque déposée ou des visuels produit d'un autre développeur dans vos captures invitent à la fois un rejet et, potentiellement, un litige.
Solution : ne montrez que du contenu sur lequel vous avez des droits. Remplacez le contenu tiers réel visible dans votre interface (pochettes d'album, vidéos, flux de marque) par des substituts sous licence ou génériques avant la capture.
Contenu bouche-trou et bâclé #
« Lorem ipsum », « Test test », des états vides sans données ou des mises en page manifestement cassées se lisent comme une app inachevée. Les examinateurs jugent le soin de toute la soumission en partie d'après les captures.
Solution : capturez avec des données de démo réalistes — listes remplies, noms plausibles, chiffres crédibles. (Réalistes, pas réels : ne publiez jamais de données d'utilisateurs réels dans une capture.)
Affirmations périssables : prix, promotions, classements #
« 50 % de réduction cette semaine », « App de productivité n°1 » ou un prix imprimé dans une légende devient inexact dès que les choses changent — et les examinateurs le savent. Les affirmations à durée limitée sont explicitement déconseillées pour les prévisualisations et risquées dans les captures.
Solution : que les légendes portent sur ce que fait l'app. Mettez les promotions dans le texte promotionnel (que vous pouvez modifier à tout moment sans examen).
Revenir à « Approuvé », vite #
Un rejet de capture ne nécessite pas un nouveau build :
- Lisez attentivement le message du Centre de résolution — il nomme la directive et joint généralement la capture fautive.
- Remplacez les images signalées dans App Store Connect sur la même version. Les modifications de médias et métadonnées sur une version rejetée n'ont pas besoin d'un nouveau binaire.
- Répondez dans le Centre de résolution en indiquant ce que vous avez changé, et resoumettez. Les réexamens de métadonnées seules sont généralement rapides.
- Si vous estimez le rejet erroné, vous pouvez faire appel — mais pour les captures, remplacer la ressource est presque toujours plus rapide que d'argumenter.
Une note de processus qui surprend : en dehors d'un rejet, les captures ne peuvent être modifiées qu'en soumettant une nouvelle version de l'app. Si votre jeu enfreint une directive que les examinateurs se mettent à appliquer plus strictement, il peut bloquer une publication de correctif par ailleurs triviale — une raison de plus de réussir le jeu du premier coup.
La liste de contrôle avant soumission #
Passez ceci avant chaque soumission avec de nouvelles captures :
- Dimensions en pixels exactes pour chaque emplacement — validez-les ici
- Chaque capture montre une interface réelle et actuelle de l'app (2.3.3)
- Rien que le build ne sache faire (2.3.1)
- Contenu adapté au 4+ (2.3.8)
- Aucun cadre, badge ou mention Android/autre plateforme (2.3.10)
- Aucune marque, logo ou personne tiers sans droits (5.2)
- Données de démo réalistes, pas de bouche-trous
- Aucun prix, remise ou classement incrusté dans les images
- Toutes les tailles d'appareil requises couvertes, y compris Watch/Vision Pro si vous y publiez
- Pour les vidéos de prévisualisation, consultez la spécification vidéo à part
Les textes officiels se trouvent dans les Directives d'examen de l'App Store, section 2.3 d'Apple et les spécifications de captures.
Rendez impossible toute cette catégorie de rejet #
La moitié de cette liste — dimensions, couverture, cohérence par langue — est mécanique, et c'est pour les problèmes mécaniques qu'existent les outils. Screenshot Studio capture votre interface réelle dans des cadres d'appareil actuels (compatible 2.3.3 par construction), exporte chaque taille requise avec exactitude (pas de rejets de dimensions), garde les jeux localisés synchronisés et téléverse vers App Store Connect avec chaque fichier au bon emplacement.
Les décisions de jugement — quoi montrer, quoi affirmer — restent les vôtres. Les rejets qui viennent de la mécanique des fichiers, non.
Téléchargez Screenshot Studio gratuitement et soumettez votre prochaine mise à jour sans retenir votre souffle.