Resolution Center Apple : répondre à un refus App Review
Par Mehdi Azizi
Publié le , 9 min
Le Resolution Center est devenu la section App Review d'App Store Connect. Réponds en anglais : motif, correctif, vérification. Fais appel au Board ensuite.
Le Resolution Center n'existe plus sous ce nom. Tu réponds à un refus dans la section App Review de ton app, avec le bouton Reply to App Review. Écris en anglais et donne trois informations : ce qui bloquait, ce qui a changé, comment le vérifier. L'App Review Board ne sert qu'après cette réponse, et seulement si tu es sûr que ton app respecte la règle citée.
J'ai écrit ces réponses pour mes propres apps en 2026 : Solys, mon réveil à mini-jeux, et TradaZen, mon simulateur de trading. Voici où répondre aujourd'hui, quoi écrire, quand joindre une vidéo, quand faire appel, et ce qui ne marche pas. Pour les motifs eux-mêmes, lis pourquoi Apple refuse une app.
Où est passé le Resolution Center ?
L'aide officielle, Reply to App Review messages, parle désormais de la section App Review. Tu y échanges avec Apple, pièces jointes comprises, jusqu'à ce que tu renvoies ta soumission. Le chemin :
- Dans Apps, ouvre ton app.
- En haut de la page, clique sur le lien des problèmes non résolus, appelé View App Review Issues & Messages dans une autre page de l'aide.
- Dans la partie In Progress, clique sur Resolve à côté de la soumission.
- Clique sur Reply to App Review et écris dans le champ Reply.
- Pour joindre une capture ou un document, clique sur Attach File, puis sur Reply.
Seuls les rôles Account Holder, Admin et App Manager peuvent répondre. La page App Review ajoute que tu suis l'état de tes soumissions dans App Store Connect ou dans son app pour iPhone et iPad.
Avant d'écrire : quel message as-tu reçu ?
La bonne réponse dépend du message, pas de ton envie de te défendre. Voici la grille que j'applique avant d'ouvrir le champ de réponse.
| Ce que dit Apple | Ce que tu fais | Nouveau build |
|---|---|---|
| Information Needed | Réponds à la question | Non |
| Bug ou écran fautif | Corrige, puis réponds | Oui |
| Fiche, liens, captures | Corrige la fiche | Non |
| App mal comprise | Explique, avec preuve | Selon le cas |
| Désaccord persistant | Appel au Board | Non |
| Offre Bug Fix Submissions | Accepte par réponse | Non |
Trois précisions changent tout :
- Un refus sur les métadonnées ne demande pas de nouveau build. L'aide d'Apple le dit : tu corriges et tu renvoies le même build. C'est souvent le cas d'un refus 2.3.10, quand la mention fautive est dans la fiche.
- Un « Information Needed » n'est pas un refus de fond. Le relecteur te pose une question. Le guide sur la guideline 2.1 explique la différence avec un vrai constat de bug.
- Les Bug Fix Submissions sont une offre. Si ton app est déjà en ligne et que le message commence par « Bug Fix Submissions : The issues we've identified below are eligible to be resolved on your next update », tu peux demander l'approbation de la mise à jour en répondant au message. Ne renvoie pas l'app à ce moment, sinon une nouvelle revue démarre. Tu règles le problème à la version suivante.
Quoi écrire : le modèle en quatre blocs
Apple a publié ses conseils pour contacter App Review. À faire : être précis sur ce que tu demandes, et donner les informations qui aident à comprendre l'app si tu penses qu'elle a été mal comprise. À éviter : utiliser le champ de réponse pour faire appel ou demander une revue accélérée, ou demander où en sont les apps d'autres développeurs.
Mon modèle tient en quatre blocs. Écris en anglais, sans adjectif. Remplace tout ce qui est entre crochets, et n'écris que ce qui est vrai dans le build envoyé.
Hello App Review team,
Thank you for your review and for the details on
Guideline [number].
What you reported: [one sentence that restates
Apple's message, in your own words].
What changed in build [version (build)]:
- [Screen or element]: [what it does now]
- [Screen or element]: [what it does now]
How to verify:
1. [Starting point, e.g. fresh install]
2. [Action]
3. [Expected result]
We tested this flow on [devices and iOS versions].
[Attached: a short screen recording of the fixed flow.]
If anything else is unclear, please tell us which
screen or wording, and we will change it.
Best regards,
[Your name]
Chaque bloc a un rôle. Le premier prouve que tu as lu. Le deuxième nomme le build, car le relecteur teste le binaire, pas tes intentions. Le troisième lui fait gagner du temps. Le dernier ouvre la porte sans plaider.
Les modèles adaptés à chaque règle sont dans mes guides dédiés, par exemple sur la guideline 3.1.2 ou la guideline 4.3. Une trame de réponse figure aussi dans mon modèle de notes App Review, à télécharger.
Ce que j'ai appris en répondant pour Solys et TradaZen
Solys, guideline 2.1. Le relecteur demandait un moyen de contourner le jeu. Ma réponse précisait l'écran bloquant, la démo jouable de l'onboarding, puis la vraie cause : en mode compatibilité sur iPad, son obstacle devenait infranchissable. Elle listait deux correctifs numérotés, dont un lien pour passer la démo après un échec, puis les simulateurs testés, de l'iPhone SE au plus grand iPhone. Elle décrivait aussi le bouton d'arrêt d'urgence de l'alarme, mais seulement après que j'ai relu le code qui le déclenche. N'écris rien sur ton app que tu n'as pas vérifié dans le build.
TradaZen, guideline 5.6. En octobre 2026, Apple a jugé que l'app poussait à des achats intégrés non voulus, sans désigner d'élément précis. J'ai cherché ce qui pouvait tromper : une croix en haut du paywall ouvrait une offre réduite au lieu de fermer l'écran. Ma réponse reconnaissait ce point en une phrase : c'était mon erreur. Elle listait ensuite chaque changement, écran par écran : la croix remplacée par un cadeau, plus d'offre qui se rouvre seule, une notification promotionnelle supprimée. Elle rappelait ce qui restait conforme : prix facturé le plus visible, restauration des achats, liens légaux. Elle finissait en proposant de modifier tout écran encore jugé ambigu. Le nouveau build est parti avec.
Ces deux réponses suivent la même logique : la cause réelle, le correctif visible, le chemin pour le voir.
Quand joindre une vidéo ou une capture
L'aide d'Apple accepte en pièce jointe des captures et des documents. Une courte vidéo de l'écran corrigé est utile dans trois cas :
- le problème dépend d'un appareil ou d'une condition, comme un iPad en mode compatibilité ou une permission refusée ;
- le chemin est long jusqu'à l'écran, par exemple au bout de l'onboarding ;
- la fonction est difficile à reproduire. La page App Review demande d'être prêt à fournir une vidéo de démonstration quand une fonction exige un environnement difficile à recréer ou un matériel précis.
Pour une app liée à un accessoire, l'aide sur la revue complète exige une vraie vidéo filmée sur un appareil Apple, pas un enregistrement d'écran. Pour un texte de paywall ou un bouton renommé, une capture suffit.
Demander un appel ou un rendez-vous
Si l'écrit ne suffit pas, Apple prévoit deux options :
- Un appel avec un représentant d'Apple. Tu le demandes dans la fenêtre Reply to App Review, après une première réponse d'App Review. Indique ton fuseau horaire et, si tu veux, la langue souhaitée. Vérifie avant tes coordonnées dans App Review Information. Apple indique que ces appels ont lieu en général sous trois à cinq jours ouvrés.
- Un rendez-vous de 30 minutes en visio avec App Review, le mardi ou le jeudi, pour parler des règles. Il est informatif : il n'accélère ni ne garantit la revue.
Faire appel à l'App Review Board
L'appel est la dernière étape. D'après la page Appeal to the App Review Board, il convient si ton app a été refusée alors que tu penses qu'elle respecte les règles, ou si tu estimes avoir été traité de façon injuste.
Avant tout, réponds au message dans App Store Connect pour clarifier. Si ça ne suffit pas, remplis le formulaire Submit an appeal to App Review. Les règles :
- un seul appel par app refusée, qui traite toutes les règles citées ;
- cite la règle et explique point par point en quoi ton app la respecte ;
- ne fais pas appel si tu as déjà corrigé et renvoyé l'app ;
- ne fais pas appel pour une simple demande d'information.
Apple donne deux exemples, que je traduis. Complet : « Mon app a été refusée au titre de la 2.1 pour information incomplète. Le compte de démo et les étapes pour tester la fonction sont dans App Review Information, avec des captures qui la montrent. » Incomplet : « Cette app est importante pour mon entreprise et n'aurait pas dû être refusée. »
Le Board répond dans App Store Connect, et peut demander des informations ou proposer un appel. Apple ne publie aucun délai pour l'appel. Des développeurs racontent sur les forums d'Apple des attentes de plus de deux semaines. Si le correctif est simple, renvoyer un build corrigé va souvent plus vite.
Ce qui marche, ce qui ne marche pas
| Ça aide | Ça dessert |
|---|---|
| Reprendre le motif d'Apple | Plaider ta cause |
| Nommer le build corrigé | Promettre un correctif futur |
| Donner le chemin à suivre | Citer une app concurrente |
| Joindre une preuve | Faire appel dans Reply |
| Une réponse complète | Renvoyer sans corriger |
« Mon écran avait déjà été accepté » ne marche pas non plus : chaque version repasse en revue, parfois devant un autre relecteur. Les App Review Guidelines préviennent aussi qu'une app refusée plusieurs fois pour la même règle met plus longtemps à être examinée. Pour les délais de revue, lis délai de validation App Store.
Faire relire ta réponse avant l'envoi
Le Kit Review Apple contient les vrais messages reçus sur mes apps, les corrections envoyées, et des skills Claude Code qui préparent ta réponse si Apple refuse. Pour un regard humain, réserve une heure avec moi : on lit le message d'Apple et on écrit la réponse ensemble. La démarche complète est sur la page application refusée par Apple.
Tu n'as pas encore envoyé ton app ? Fais ton diagnostic gratuit : il t'envoie ma checklist anti-refus Apple, pour t'éviter d'avoir à écrire cette réponse.
Questions fréquentes
Où se trouve le Resolution Center dans App Store Connect ?
Il s'appelle désormais la section App Review. Ouvre ton app, clique sur le lien des problèmes non résolus en haut de la page, puis sur Resolve à côté de la soumission. Le bouton Reply to App Review ouvre le champ de réponse et l'ajout de pièces jointes.
Combien de temps Apple met-il pour répondre ?
Apple ne publie pas de délai pour les réponses écrites. Pour la revue, Apple annonce au moins 50 % des soumissions examinées en moins de 24 heures et 90 % en moins de 48 heures. Un appel demandé à App Review a lieu en général sous trois à cinq jours ouvrés. Aucun délai n'est annoncé pour l'App Review Board.
Peut-on répondre en français à App Review ?
L'aide d'Apple ne fixe aucune langue pour la réponse écrite. J'écris en anglais, en phrases courtes, pour être compris du premier coup. Pour un appel, Apple permet d'indiquer une langue préférée, sans garantie.
Combien de fois peut-on faire appel d'un refus ?
Une fois par app refusée. Si le message cite plusieurs règles, ton appel doit toutes les traiter. Apple demande aussi de répondre d'abord dans App Store Connect, et de ne pas faire appel si tu as déjà renvoyé un build corrigé.
Faut-il renvoyer un build avant de répondre ?
Oui si le problème est dans l'app : corrige, envoie le build, puis réponds en nommant ce build. Non si le refus porte sur les métadonnées, comme la fiche ou les captures : tu corriges dans App Store Connect et tu renvoies le même build.

