Revue accélérée App Store : comment la demander à Apple
Par Mehdi Azizi
Publié le , 9 min
Apple cite deux cas : un bug critique sur la version en ligne, ou une sortie liée à un événement. La procédure, quoi écrire, et ce qui se passe ensuite.
La revue accélérée existe, mais Apple la réserve aux circonstances exceptionnelles, et il en cite deux : corriger un bug critique sur une version déjà publiée, ou sortir une version calée sur un événement auquel ton app est directement liée. Tu soumets d'abord ta version, tu expliques l'urgence dans les Notes du reviewer, puis tu envoies le formulaire de demande. Apple étudie chaque demande et accélère selon ses disponibilités : ce n'est jamais une garantie.
Mes apps, Solys, TradaZen et Nolera, sont faites avec Expo. Quand un bug vient du code JavaScript, le correctif part en mise à jour à distance, sans passer par App Review. La revue accélérée ne me sert donc que pour un build natif, et c'est aussi la première question à te poser avant de la demander. Ce guide suit la page d'aide d'Apple sur la revue accélérée, relue le 6 novembre 2026.
Ce qu'Apple cite, et ce qui ne passe pas
Apple parle de circonstances exceptionnelles et demande de réserver les demandes aux urgences réelles. Sa page App Review donne deux exemples et ce qu'il faut fournir pour chacun. Les trois lignes refusées du tableau sont ma lecture de ces pages, pas une liste d'Apple.
| Motif | Chez Apple | Ce qu'il faut fournir, ou comprendre |
|---|---|---|
| Bug critique sur la version en ligne | Cité en exemple | Étapes de reproduction, version actuelle |
| Sortie liée à un événement | Cité en exemple | L'événement, sa date, le lien entre ton app et lui |
| Première publication en retard | Non, à mon avis | Rien ne la rend urgente aux yeux d'Apple |
| Date marketing sans événement | Non, à mon avis | Une campagne n'est pas un événement lié à l'app |
| Attente plus longue que d'habitude | Non, à mon avis | Un délai normal n'est pas une urgence |
Apple ne définit pas le terme. En pratique, un bug critique, c'est une app qui plante, qui bloque une fonction essentielle ou qui empêche de payer, chez des utilisateurs réels, sur la version en ligne. Une coquille dans un écran ne l'est pas. Et si ton app est encore en revue à l'approche d'un événement, Apple précise que tu peux aussi demander l'accélération pour cette raison.
La procédure en trois étapes
- Soumets la version dans App Store Connect. Seule une soumission déjà envoyée peut être accélérée. Si des fonctions demandent une connexion, renseigne un compte de démonstration dans la section App Review Information.
- Remplis le champ Notes au moment de soumettre. Pour un bug critique, décris le bug corrigé et comment le reproduire sur la version actuelle. Pour un événement, donne son nom, sa date et ce qui lie ton app à lui.
- Envoie le formulaire Request an Expedited App Review, accessible depuis la page d'aide d'Apple après connexion à ton compte développeur. Tu y choisis l'app et la plateforme concernées, puis tu envoies.
Apple étudie la demande et te répond, puis tu suis la soumission dans App Store Connect. Si la demande est acceptée, la version passe en In Review plus tôt que la file ne l'aurait fait. Si elle est refusée, la revue suit son cours normal : rien n'est perdu.
Le bouton Reply to App Review, dans App Store Connect, ne sert pas à demander une revue accélérée. La page de contact d'App Review le réserve aux échanges sur une soumission en cours ; la demande accélérée et l'appel ont chacun leur formulaire.
Quoi écrire : deux modèles
App Review lit l'anglais. Voici les deux textes que je garde prêts, à adapter dans les Notes, et dans le formulaire s'il te laisse un champ libre. Ils tiennent en cinq lignes parce qu'un reviewer doit comprendre l'urgence sans ouvrir l'app.
Bug critique sur la version en ligne :
Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce : install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.
Sortie liée à un événement :
This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.
Ces deux textes sont des exemples, pas des demandes que j'ai envoyées. Deux règles pour les tiens. Des faits vérifiables : version, système, étapes, date, lien avec l'événement. Rien d'autre que l'urgence : si ton build contient aussi une nouvelle fonction, dis-le en une phrase, mais ne la défends pas.
Avant de demander, vérifie que tu en as besoin
Apple demande de la réserver aux urgences réelles. Trois questions, et un piège, avant d'envoyer le formulaire.
Le correctif passe-t-il sans revue ? Avec Expo, une mise à jour à distance remplace le code JavaScript des apps déjà installées sans nouveau build. C'est la voie que j'utilise pour mes correctifs. Elle ne couvre ni le code natif, ni les permissions, ni les dépendances natives : pour ceux-là, il faut un build et une revue. Et son contenu doit rester dans le cadre de ce qu'Apple a validé, comme le rappelle la présentation d'EAS Update : une mise à jour à distance ne change pas l'objet de l'app. Le guide sur le déploiement progressif d'une mise à jour iOS détaille ce qui passe par quoi.
L'attente est-elle anormale ? Apple dit examiner en général au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures. Si ta version est en attente de vérification depuis un jour, tu es dans la norme du délai de validation App Store. La page de suivi d'une soumission rappelle aussi ce qui allonge une revue : première app sans historique, documents à vérifier, sujet réglementé.
La soumission est-elle complète ? Une revue accélérée sur une soumission incomplète n'accélère rien. Apple prévient qu'une soumission incomplète retarde la revue ou échoue. Compte de démo, notes, documents : tout doit être là avant le formulaire.
Et surtout, ne retire pas ta version pour la renvoyer. Une version retirée sort de la file et repart de zéro. Si Apple te pose une question pendant la revue, réponds dans App Store Connect au lieu de resoumettre, comme l'explique le guide sur répondre à App Review dans le Resolution Center.
Si Apple refuse l'accélération
Tu gardes ta place dans la file : un refus d'accélération ne change rien à la revue en cours. Pour ne pas revivre la situation :
- Programme tes sorties. Pour un événement, Apple conseille de choisir la publication programmée dans App Store Connect : la version est revue à l'avance et sort à la date voulue. L'option de publication d'une version se règle sur la page de la version, dans la section App Store Version Release.
- Soumets tôt. Une version prête une semaine avant l'événement laisse le temps d'une revue normale, et même d'un refus corrigé.
- Garde un canal sans revue pour le JavaScript. Avec Expo, c'est ce qui transforme un bug critique en correctif de quelques minutes.
Mes modèles de notes pour le reviewer, ma checklist avant l'envoi et les réponses aux refus les plus fréquents sont réunis dans le Kit Review Apple. Et si tu veux savoir ce qui manque à ta soumission avant de l'envoyer, le diagnostic gratuit te le dit et t'envoie ma checklist anti-refus Apple. Toutes les étapes de la publication sont dans publier une application sur l'App Store.
Questions fréquentes
Combien de temps prend une revue accélérée App Store ?
Apple ne donne aucun délai. Il indique étudier chaque demande et accélérer la revue selon ses disponibilités et la demande du moment. Une demande acceptée fait passer la version en In Review avant son tour, sans promesse d'heure.
Peut-on demander une revue accélérée pour une première app ?
Rien ne l'interdit, mais Apple réserve l'accélération aux urgences réelles et cite deux exemples : un bug critique sur une version déjà en ligne, ou une sortie liée à un événement daté. Une première publication en retard sur ton planning n'entre, à mon avis, dans aucun des deux.
Combien de fois peut-on demander une revue accélérée ?
Apple ne publie pas de nombre. Il demande de réserver les demandes aux urgences réelles. À mon avis, chaque demande sans vrai motif rend la suivante moins crédible : garde-la pour un bug qui touche tes utilisateurs.
Faut-il retirer la soumission avant de demander l'accélération ?
Non, c'est l'inverse. Seule une soumission déjà envoyée peut être accélérée, et une version retirée perd sa place dans la file. Soumets, remplis les Notes, puis envoie le formulaire.
Où se trouve le formulaire de revue accélérée ?
Sur le site développeur d'Apple, après connexion à ton compte : la page d'aide sur la revue accélérée y mène par le lien Request an Expedited App Review. Tu y choisis l'app et la plateforme concernées.
Une revue accélérée garantit-elle que l'app sera acceptée ?
Non. Elle ne change que la position dans la file. La version doit respecter les App Review Guidelines comme n'importe quelle autre, et un refus reste possible.
Peut-on corriger un bug sans passer par App Review ?
Avec Expo ou React Native, une mise à jour à distance remplace le code JavaScript sans nouveau build ni revue. Le code natif, les permissions et les dépendances natives demandent toujours un build soumis à Apple.

