Un refus App Store arrive sous la forme d'un message dans App Store Connect : un numéro de guideline, quelques phrases du reviewer, souvent une capture de l'écran qui a échoué. Ce n'est pas un verdict sur votre application ni sur votre compte. L'App Review d'Apple a traité plus de 9,1 millions de soumissions en 2025, la plupart sous 24 heures, et une bonne part des premières soumissions reviennent au moins une fois. Ce qui compte, c'est ce que vous faites dans l'heure qui suit le message.
Cette décision tient en trois questions. Le reviewer a-t-il raison ? La correction demande-t-elle un nouveau build, ou seulement une modification de la fiche ? Et si vous n'êtes pas d'accord, répondez-vous, ou faites-vous appel ? Ce guide y répond dans l'ordre : comment un refus vous parvient et ce que veulent dire les statuts, les huit motifs qui couvrent la plupart des refus, les trois réponses possibles, et une checklist pour la resoumission.
Si vous êtes plus tôt dans le parcours, notre guide pour publier une app sur l'App Store couvre tout le chemin du compte développeur à la mise en ligne ; cet article commence le jour où la review revient négative.
Comment un refus vous parvient et ce que veulent dire les statuts
L'App Review combine des contrôles automatiques, qui repèrent les crashs, l'usage d'API privées et les logiciels malveillants, et un reviewer humain qui installe votre build, ouvre la fiche, lit vos notes de review et utilise l'app comme le ferait un client. Quand quelque chose échoue, le reviewer écrit un message dans le Resolution Center d'App Store Connect et la version change de statut. Trois statuts comptent :
- Rejected. Le binaire lui-même a un problème : un crash, une fonctionnalité manquante, un souci de permission. Il vous faudra presque toujours envoyer un nouveau build.
- Metadata Rejected. Le build est bon ; la fiche ne l'est pas. Captures, description, mots-clés, réponses de confidentialité ou notes de review doivent changer, ce que vous faites directement dans App Store Connect avant de resoumettre sans nouveau build.
- Developer Rejected. Vous avez retiré la version vous-même, par exemple pour remplacer un build. Rien à répondre.
Les huit motifs derrière la plupart des refus de première soumission
Les App Review Guidelines comptent cinq chapitres et des dizaines de règles, mais les refus qu'une première soumission reçoit réellement se concentrent sur une poignée d'entre elles. Les voici, avec ce que le reviewer a vu et ce qui corrige le problème.
| Guideline | Ce que le reviewer a vu | Ce qui corrige |
|---|---|---|
| 2.1 Performance | L'app a planté au lancement ou dans un parcours central sur l'appareil du reviewer | Reproduisez sur le binaire TestFlight, sur plusieurs appareils et versions d'iOS, et corrigez. Envoyez un nouveau build. |
| 2.1 App completeness | Un compte de démonstration qui ne marche pas, du contenu de remplissage, une fonctionnalité « bientôt disponible » | Fournissez un identifiant fonctionnel avec des données réalistes dans App Review Information ; retirez ou terminez les éléments provisoires. |
| 2.3 Accurate metadata | Des captures ou une description montrent des fonctionnalités absentes du build | Metadata Rejected : mettez captures et textes en accord avec l'app, resoumettez le même build. |
| 4.2 Minimum functionality | Un site web dans un cadre, ou une app qui fait trop peu pour justifier une installation native | Ajoutez de la valeur native : usage hors ligne, notifications, fonctions de l'appareil, une expérience que le site n'offre pas. |
| 4.3 Spam | Une app qui en duplique une autre, de vous ou d'un modèle, dans une catégorie saturée | Différenciez-la nettement, ou fusionnez les variantes en une seule app. |
| 5.1.1 Data collection and storage | URL de politique de confidentialité manquante, étiquettes App Privacy qui contredisent l'app, demandes de permission sans justification, invite de suivi absente | Publiez la politique, alignez les étiquettes sur ce que l'app collecte vraiment, écrivez un texte d'explication pour chaque permission, affichez l'invite App Tracking Transparency si vous suivez les utilisateurs. |
| 3.1.1 In-app purchase | Du contenu numérique ou des abonnements vendus hors de l'achat intégré d'Apple | Passez par l'achat intégré pour le numérique ; le paiement externe reste autorisé pour les biens physiques et les services consommés hors de l'app. |
| 1.5 Developer information | Une URL de support qui renvoie une erreur ou une page sans moyen de vous contacter | Metadata Rejected : faites pointer l'URL de support vers une page en ligne avec un formulaire ou un e-mail. |
Le cas particulier des sites enrobés
La guideline 4.2 est celle qui surprend les fondateurs qui ont empaqueté leur site web dans une app. La position d'Apple est constante : si l'app est le site dans une WebView sans rien que le navigateur ne saurait faire, elle n'a pas sa place sur l'App Store. La correction n'est pas une meilleure description ; c'est de la fonctionnalité. Accès hors ligne, notifications push, caméra ou géolocalisation, une navigation native que le site n'a pas. Si le projet a commencé comme une app web, la voie honnête est un vrai build natif, et c'est pourquoi notre guide pour créer une application mobile sans coder sépare les outils qui génèrent du code natif de ceux qui enrobent un site.
Comment répondre : corriger, répondre, ou faire appel
Lire le message comme une checklist
Avant de décider quoi que ce soit, extrayez du message le numéro de guideline, l'étape exacte que le reviewer décrit, l'appareil et la version d'iOS notés en haut, et toute capture jointe. Puis reproduisez vous-même sur le même build via TestFlight. La moitié du temps, le reviewer a raison et vous n'aviez pas vu ; un quart du temps, il est tombé sur un contexte que vous n'aviez pas testé, comme une installation neuve sans données ; le reste est un vrai désaccord.
Corriger et resoumettre
Pour un statut Metadata Rejected, modifiez la fiche dans App Store Connect et cliquez sur resoumettre : pas de nouveau build, et la seconde review est en général rapide. Pour un statut Rejected, envoyez un build corrigé, sélectionnez-le dans la même version et soumettez à nouveau. Dans les deux cas, écrivez une courte note dans le Resolution Center pour dire ce qui a changé. Les reviewers la lisent, et elle oriente la seconde review vers la correction au lieu de repartir de zéro.
Répondre quand le reviewer se trompe
Si vous ne parvenez pas à reproduire le problème ou si la guideline ne s'applique pas, répondez dans le Resolution Center plutôt que de resoumettre le même build en silence. Restez factuel : les étapes exactes que vous avez suivies, l'appareil et la version, un enregistrement d'écran qui montre la fonctionnalité en marche, les identifiants à utiliser. Si le reviewer a mal compris ce que fait l'app, expliquez le cas d'usage en deux phrases. Vous pouvez aussi demander un appel téléphonique de l'App Review dans le même fil ; ce n'est pas rapide, mais cela débloque les conversations que l'écrit n'arrive pas à régler.
Faire appel auprès de l'App Review Board
Un appel sert à un désaccord sur la guideline elle-même, pas sur un fait. Il passe par l'App Review Board via le formulaire lié au refus, et il prend des jours, parfois plus. Utilisez-le après l'échec de la réponse dans le Resolution Center, et rédigez-le pour quelqu'un qui n'a jamais vu votre app : ce qu'elle fait, quelle guideline a été citée, pourquoi vous pensez qu'elle ne s'applique pas. Si la guideline a changé récemment, ou si vous pensez qu'elle est appliquée de façon incohérente, dites-le et donnez des exemples.
La review accélérée
Apple accorde une review accélérée pour la correction d'un bug critique dans une app en ligne ou pour un événement daté, pas pour une première sortie en retard. En demander une pour un lancement est refusé et fait perdre une journée. Si votre échéance est réelle, le seul levier est de soumettre tôt et de répondre à tout message en quelques heures.
Une checklist pour éviter le second refus
La plupart des seconds refus répètent le premier, ou révèlent le problème suivant que le reviewer n'avait pas atteint parce que le premier avait arrêté la review. Avant de resoumettre, parcourez cette liste une fois :
- Le binaire TestFlight s'ouvre sur une installation neuve, sans données, sur la plus ancienne version d'iOS que vous supportez.
- Le compte de démonstration dans App Review Information se connecte, et les données derrière ont l'air réelles.
- Chaque demande de permission a un texte d'explication qui dit ce que la fonctionnalité fait des données.
- L'URL de la politique de confidentialité s'ouvre, et les réponses App Privacy correspondent aux SDK présents dans l'app.
- Les captures montrent des écrans qui existent dans ce build, aux bonnes tailles d'appareil.
- Tout achat numérique passe par l'achat intégré, et tout achat physique est clairement physique.
- L'URL de support et l'URL marketing se chargent et offrent un moyen de vous contacter.
- Les textes de remplissage, les boutons de test et les écrans « bientôt disponible » ont disparu.
- Les notes de review expliquent tout ce qui sort de l'ordinaire : un matériel requis, une fonctionnalité limitée à une région, une connexion via un service tiers.
Si vous construisez avec Cadrant, les parties du parcours qui causent des refus au niveau du build sont prises en charge : le binaire natif est compilé et signé sur votre compte Expo, déposé sur votre App Store Connect, et l'app est une vraie application Expo plutôt qu'un site enrobé, ce qui écarte la guideline 4.2. Ce qui reste à votre charge, c'est exactement cette checklist : la fiche, les réponses de confidentialité, le compte de démonstration et un passage par TestFlight avant de soumettre. La documentation de publication liste les étapes App Store Connect dans l'ordre.
En résumé
- Un refus est un message avec un numéro de guideline ; le statut vous dit si c'est le build ou la fiche qui est en cause.
- Huit guidelines expliquent la plupart des premiers refus : crashs, compte démo, métadonnées, fonctionnalité minimale, spam, confidentialité, achat intégré, URL de support.
- Corrigez et resoumettez quand le reviewer a raison, répondez avec des preuves quand les faits sont faux, faites appel seulement quand c'est la guideline elle-même qui est contestée.
- Répondez dans la journée, et parcourez la checklist avant chaque resoumission.
Géré ainsi, un refus coûte un jour ou deux, pas un lancement. Les apps qui restent bloquées sont celles qui resoumettent le même build en espérant tomber sur un autre reviewer.