Combien de temps prend la revue App Store

Apple publie un chiffre : 90 % des soumissions sont examinées en moins de 24 heures.

Google publie une fourchette : de quelques heures à sept jours, voire plus dans des cas exceptionnels, et recommande de prévoir au moins une semaine de marge entre la soumission et la mise en ligne.

Cet écart explique la plupart des erreurs de planification de release. Les gens planifient sur le chiffre d'Apple et se font rattraper par celui de Google.

Ce que les statuts veulent réellement dire

Les définitions d'Apple elle-même, plus précises que l'usage qu'on en fait :

Statut	Ce qu'il signifie
Prepare for Submission	Vous avez une fiche d'app et vous êtes encore en train de la remplir
Ready for Review	Vous avez saisi les métadonnées et déclaré vouloir soumettre. Vous n'avez pas soumis.
Waiting for Review	Apple a votre soumission mais n'a pas commencé
In Review	Quelqu'un la regarde. Vous pouvez encore retirer le build
Metadata Rejected	Le build va bien. Quelque chose dans la fiche, non
Rejected	La soumission n'est pas passée
Accepted	Cet élément est passé, mais un autre de la même soumission non. Rien ne se publie tant que tout n'est pas passé
Pending Developer Release	Approuvé. En attente que vous appuyiez sur le bouton
Processing for Distribution	Approuvé et publié. En ligne sous 24 heures
Pending Apple Release	Retenu jusqu'à la sortie publique de la version d'OS correspondante
Ready for Distribution	En ligne

Deux d'entre eux causent l'essentiel de la confusion. Ready for Review ne veut pas dire soumis. Et Accepted ne veut pas dire publié : si vous avez soumis une version d'app avec d'autres éléments et que l'un d'eux a échoué, les parties acceptées patientent.

Quand ça prend plus longtemps

Apple documente exactement une cause : les soumissions incomplètes. Dans ses mots : si votre soumission est incomplète, les délais d'examen peuvent s'allonger ou la soumission peut ne pas passer. Plus de 40 % des problèmes non résolus viennent de la guideline 2.1, App Completeness.

Au-delà, Apple nomme des catégories qui reçoivent plus d'attention, pas plus de temps. Les apps médicales susceptibles de fournir des données inexactes ou d'être utilisées pour un diagnostic sont examinées de plus près. Les apps de recherche en santé exigent l'aval d'un comité d'éthique. Les apps de banque, santé, jeux d'argent, cannabis, transport aérien et échanges de cryptomonnaies doivent être soumises par l'entité juridique qui fournit le service, pas par une personne à titre individuel.

Une limite structurelle à intégrer à vos plans : vous pouvez avoir une version d'app en revue par plateforme à la fois, et deux soumissions en revue au maximum. Depuis octobre 2025, les autres éléments partent indépendamment : une correction critique n'a donc plus à attendre derrière une page produit personnalisée encore en revue.

La revue accélérée

Apple en a une. Google n'en publie aucun équivalent.

Apple accorde une revue accélérée pour circonstances atténuantes, et en nomme deux : corriger un bug critique, ou publier en coïncidence avec un événement auquel vous êtes directement associé.

Ce qu'il faut inclure, selon Apple :

• Correction de bug : les étapes pour reproduire le bug dans la version actuellement en ligne. Pas une description du correctif. La reproduction.
• Événement : l'événement, sa date, et le lien de votre app avec lui.

Apple ajoute que, pour un événement, la meilleure réponse est de programmer la publication dans App Store Connect plutôt que de courir contre la revue. Ça vaut d'être pris au sérieux : programmer ne coûte rien, accélérer dépense du crédit.

Si vous êtes refusé et que vous pensez que la personne qui a examiné a mal lu votre app, il existe une autre voie : un recours devant l'App Review Board. Un recours par soumission refusée, et répondez d'abord aux demandes d'information en suspens.

Quatre croyances qu'aucun store ne documente

Les quatre circulent comme des faits, y compris chez des gens qui devraient savoir.

"Resoumettre vous renvoie en fin de file." Vrai chez Google, qui le dit clairement : le délai se compte à partir du dernier changement soumis, et votre app peut être repoussée en fin de file d'examen. Apple ne documente rien de tel. L'énoncé Apple le plus proche est que les soumissions ne sont pas forcément examinées dans l'ordre où vous les envoyez.

"Les mises à jour de métadonnées seules vont plus vite." Apple ne publie rien de tel, et il n'y a presque rien qui puisse aller plus vite. La plupart des changements de fiche demandent une nouvelle version, donc un build. Les exceptions documentées sont le texte promotionnel, modifiable à tout moment, plus l'URL de support, l'URL marketing, les informations de revue et les notes de version. Tout le reste attend une version.

"Les nouveaux comptes et les premières soumissions sont plus lents." Nulle part documenté par Apple. C'est peut-être vrai. Apple ne l'a jamais dit.

"La revue TestFlight est plus rapide." Les builds TestFlight externes passent bien par une Beta App Review distincte, avec ses propres statuts et sa propre file. Apple n'en publie ni les délais ni de comparaison avec la revue App Store.

Si vous préparez un lancement, planifiez sur ce qui est documenté et traitez le reste comme du folklore.

La question des fêtes

Apple fermait autrefois. La dernière fermeture réelle remonte à décembre 2020.

Depuis, elle reste ouverte et publie à la place un avertissement début décembre. Le plus récent date du 2 décembre 2024 : soumissions acceptées tout du long, envoyez tôt ce qui dépend d'une date, les examens peuvent être plus longs du 20 au 26 décembre. En 2025, Apple n'a publié aucun avis de ce type.

Le conseil honnête est donc qu'il n'y a plus de fermeture à anticiper, mais que décembre reste le pire mois pour laisser une publication à la dernière semaine.

Le verrou propre à Google

Play a un délai qu'Apple n'a pas, et il frappe précisément ceux qui s'y attendent le moins.

Les comptes Play Console personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits en continu pendant 14 jours avant de demander l'accès à la production. Cette demande est examinée séparément, généralement sous sept jours.

Pour quelqu'un qui publie seul pour la première fois, cela fait deux semaines de test plus une de revue avant même que le compteur habituel ne démarre. Les vérifications préalables de Google aident à repérer les problèmes en amont et se terminent généralement en un quart d'heure : c'est la seule partie rapide du parcours Play.

Des chiffres de planification vraiment utilisables

• Apple, mise à jour de routine : comptez un jour, planifiez trois.
• Apple, première soumission : même délai d'examen, mais budgétez des jours pour ce qui échoue sur la 2.1 avant d'y arriver.
• Google, compte établi : prévoyez une semaine.
• Google, nouveau compte personnel, première app : prévoyez un mois avant que quoi que ce soit puisse être en ligne.
• Tout ce qui est lié à une date : programmez la publication plutôt que de l'accélérer, et soumettez au moins deux semaines à l'avance.

Ce qu'Uprate en fait

L'agent de soumission attrape les blocages et vous donne le champ exact et le correctif avant que vous soumettiez. La revue la plus rapide est celle que vous n'avez pas à refaire.

Rien ne passe en ligne tant que vous ne l'avez pas approuvé.