# Revue accélérée App Store : comment la demander à Apple > 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. Page originale : [Revue accélérée App Store : comment la demander à Apple](https://devoria.fr/blog/revue-acceleree-app-store-demande) Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi) Publication : 2026-11-06 Dernière révision du contenu : 2026-11-06 **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](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/), 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](https://developer.apple.com/distribute/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 1. **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. 2. **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. 3. **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](https://developer.apple.com/help/app-review/after-submitting-for-review/contact-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](https://docs.expo.dev/eas-update/introduction/) : une mise à jour à distance ne change pas l'objet de l'app. Le guide sur le [déploiement progressif d'une mise à jour iOS](https://devoria.fr/blog/mise-a-jour-app-ios-deploiement-progressif) 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](https://devoria.fr/blog/app-store-connect-en-attente-de-verification) depuis un jour, tu es dans la norme du [délai de validation App Store](https://devoria.fr/blog/delai-validation-app-store). La [page de suivi d'une soumission](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/) 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](https://devoria.fr/blog/repondre-app-review-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](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) 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](https://devoria.fr/kits/review-apple). Et si tu veux savoir ce qui manque à ta soumission avant de l'envoyer, le [diagnostic gratuit](https://devoria.fr/diagnostic) 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](https://devoria.fr/expertise/publier-une-application-sur-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. ## Ton projet [Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement. [Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement. [Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio. [Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.