Apple traite 90 % des soumissions en moins d'une journée. L'examen accéléré ne règle pas les 10 % restants.

Le message arrive toujours dans la même forme. Ça fait six jours, l'app est encore en Waiting for Review, le lancement était prévu demain, et est-ce que je peux appeler quelqu'un chez Apple.

Je ne peux pas. Personne ne peut. Ce que je peux faire, en général, c'est comprendre ce que veulent dire ces six jours, et après dix-huit ans à soumettre des apps je peux vous dire que la profondeur de la file n'y est presque jamais pour rien.

Il existe un bouton pour ça. Apple permet de demander un examen accéléré, c'est gratuit, et quand la demande est acceptée l'effet se voit en quelques heures. La plupart des gens qui appuient dessus sont dans une situation où ce bouton ne peut rien.

Le chiffre publié par Apple, et celui qui se cache dessous

Apple l'écrit noir sur blanc sur sa page App Review : « En moyenne, 90 % des soumissions sont examinées en moins de 24 heures. »

Le chiffre est exact. C'est le reste qui vous concerne. En 2025, l'équipe App Review a évalué plus de 9,1 millions de soumissions, environ 25 000 par jour, ce qui met le dixième lent autour de 900 000 soumissions par an ayant pris plus d'une journée. Vous n'êtes donc pas seul, et la vraie question est de savoir ce qui vous a mis là.

Il faut aussi mesurer le peu de temps que dure un examen. L'année précédente, Apple décrivait son dispositif comme près de 500 experts dédiés examinant plus de 130 000 apps par semaine. Jeff Johnson, de Lap Cat Software, a posé la division en mai : environ 260 soumissions par examinateur et par semaine, soit moins de dix minutes chacune. Dans une déposition de l'affaire Epic, un ancien responsable d'App Review situait l'examen d'une nouvelle app autour de treize minutes.

Personne ne passe donc six jours à étudier votre app. Un examen, c'est quelques minutes d'attention. Les six jours, c'est le temps avant que quelqu'un s'en saisisse, ou le temps que votre soumission a passé sur une voie plus lente que la file principale, et les deux laissent des traces dans votre propre tableau de bord.

Pourquoi une soumission reste plantée là

Par ordre approximatif de fréquence, telle que je les rencontre.

• La première soumission depuis un compte récent est la chose la plus lente que vous enverrez jamais à Apple. En 2025, Apple a refusé plus de 138 000 inscriptions au programme développeur et fermé 193 000 comptes pour fraude, donc un compte sans historique ne présente pas le même profil de risque qu'un compte avec quarante versions publiées. Les mises à jour d'une app établie passent en quelques heures. Les premières soumissions, non.
• Certaines catégories déclenchent des contrôles supplémentaires : finance, santé, enfants, rencontres, VPN, crypto, jeux d'argent, et tout ce qui porte une allégation médicale. La page d'Apple liste les justificatifs qu'elle peut réclamer, notamment l'homologation d'un dispositif médical, une autorisation de marque ou une licence. Une soumission qui attend un document qu'Apple n'a pas n'est pas dans la file, elle est garée.
• App Review vous a peut-être déjà écrit. Apple indique que plus de 40 % des problèmes non résolus relèvent de la guideline 2.1, App Completeness, qui couvre les plantages, le contenu de remplissage et les informations incomplètes. La version ordinaire, c'est un compte de démonstration qui ne marche plus, ou un backend éteint après les tests. Ce genre d'attente s'arrête à la seconde où vous répondez.
• Le calendrier compte beaucoup. Apple publie chaque décembre un avis demandant de soumettre tôt ce qui est sensible à une date, parce que les examens prennent plus de temps du 20 au 26 décembre. Septembre amène le nouvel OS et tout le monde qui livre ses mises à jour de compatibilité en même temps. Et 2026 est de toute façon une année chargée : les sorties iOS ont augmenté de 80 % sur un an au premier trimestre, avec près de 560 000 nouvelles apps sur le seul premier semestre.
• Une partie n'a rien à voir avec App Review. Les contrats, la fiscalité et les coordonnées bancaires vivent en dehors du processus d'examen et bloquent la distribution à eux seuls. Une app payante dont le contrat Paid Apps n'est pas signé ne peut pas être mise en vente, quoi qu'en décide un examinateur, et le tableau de bord donne à ça l'allure d'un retard d'examen.
• Une partie est auto-infligée. Retirer une version de l'examen la bascule en Developer Rejected et l'examen repart de zéro, et modifier autre chose que le petit ensemble de champs qui restent ouverts pendant l'examen suppose de la retirer d'abord. Les gens font ça le quatrième jour, puis comptent l'attente depuis le premier.

Ce qu'est vraiment un examen accéléré

Apple nomme deux situations sur sa page App Review. La première est la correction d'un bug critique, où Apple demande d'« indiquer les étapes permettant de reproduire le bug dans la version actuelle de votre app ». La seconde est une app liée à un événement, où la demande doit porter « l'événement, sa date, et le lien de votre app avec lui ». La demande se fait par un formulaire sur le site développeur, connecté, une fois la soumission déjà dans la file.

Cela fait avancer votre soumission dans la file. L'examen, lui, reste le même examen, avec les mêmes exigences, simplement plus tôt. Une app accélérée se fait refuser le mardi matin pour exactement ce qui l'aurait fait refuser le vendredi après-midi.

Quand la demande passe, c'est rapide. La réponse à la demande arrive en général le jour même ou le lendemain, et l'examen suit dans les heures qui suivent cette réponse. Cette vitesse fait tout l'intérêt du mécanisme, et c'est la raison de faire attention à ce que vous dépensez dessus.

Lisez la formulation d'Apple sur le cas de l'événement, elle vend la mèche. Apple recommande de planifier et de programmer la sortie dans App Store Connect, et ajoute seulement ensuite que si l'app est encore en examen et que l'événement approche, vous pouvez demander l'accélération. La première réponse d'Apple à une date butoir, c'est le programmateur de sortie. Le formulaire vient en second.

Comment écrire une demande qui passe

Un paragraphe, précis, vérifiable par quelqu'un qui n'a jamais vu votre produit. Pour un bug : ce qui casse, depuis quelle version, pour quels utilisateurs, les étapes pour le reproduire, ce que change le correctif, et un chiffre qui montre l'ampleur. Un taux de crash, un nombre de tickets de support, les avis une étoile tombés depuis 48 heures. Pour un événement : la date, le lien de votre app avec lui, et pourquoi la date ne peut pas bouger.

Les demandes qui échouent sont celles dont l'urgence est réelle pour vous et invisible pour Apple. La campagne démarre lundi. On a promis vendredi au client. La démo investisseurs est jeudi. On est déjà en retard. Chacun de ces problèmes est réel et aucun n'est un bug ni un événement.

Demandez une fois, par un seul canal. Une demande dans le formulaire plus un ticket au support plus un fil sur les forums à propos du même build ne multiplient pas vos chances, et la personne qui lit la demande voit les trois.

Les limites, qu'Apple ne met pas par écrit

• Il n'y a pas de quota publié. Apple parle de circonstances exceptionnelles, et chaque demande est jugée pour elle-même. Comptez à peu près une par an et vous serez proche de la façon dont le mécanisme se comporte.
• Les demandes laissent une trace. À force d'en faire, elles cessent tranquillement d'être accordées, sans avertissement ni notification, et vous l'apprenez le jour où quelque chose est réellement cassé et où vous aviez dépensé la vôtre pour une date marketing.
• Cela ne transforme pas un refus en validation. Si l'examen accéléré trouve un problème de guideline, la demande est consommée et vous corrigez puis resoumettez comme tout le monde. Les recours passent par une autre voie, l'App Review Board, avec un seul recours par soumission refusée, et Apple demande de répondre à toute demande d'information en attente avant de le déposer.
• Cela n'atteint rien de ce qui est en dehors d'App Review. Un message 2.1 sans réponse, des contrats non signés, une fiscalité ou des coordonnées bancaires incomplètes, une inscription en cours, un build qui plante sur l'appareil de l'examinateur. Une demande acceptée ne déplace aucun de ces points.
• Google Play n'a rien d'équivalent. Play annonce qu'un examen peut prendre jusqu'à sept jours, voire plus dans des cas exceptionnels, et un compte développeur personnel créé après le 13 novembre 2023 doit en plus mener un test fermé avec au moins 12 testeurs inscrits en continu pendant 14 jours avant de pouvoir demander l'accès à la production. Aucun formulaire ne raccourcit ça, donc la seule façon de le payer au juste prix est de commencer tôt.

Quatre choses qui marchent mieux

Soumettre tôt et retenir la sortie. Apple permet de valider une version puis de la publier à la main ou à une date choisie. Play a la publication gérée, qui retient les changements approuvés jusqu'à votre feu vert. Dès lors que la validation et le lancement sont deux événements distincts, la durée d'examen sort du chemin critique. La plupart des demandes d'accélération que j'ai vues partir étaient la facture de cette étape sautée.

Construire le correctif pour qu'il n'ait pas besoin d'une soumission. Les feature flags et la configuration à distance placent l'interrupteur dans un binaire qu'Apple a déjà examiné et laissent votre serveur décider de sa position. C'est une pratique ordinaire, et c'est autre chose que ce qu'interdit la guideline 2.5.2, à savoir télécharger du code qui introduit ou modifie des fonctionnalités. Le piège, c'est qu'un coupe-circuit doit être livré dans la version 1, pas dans la mise à jour que vous attendez en ce moment.

Remplir les App Review Information comme si un inconnu devait s'en servir, parce que c'est le cas, en moins de dix minutes, sur un appareil qui n'est pas le vôtre. Un compte de démonstration qui marche aujourd'hui, le backend laissé allumé, des notes pour tout ce qu'un examinateur ne devinerait pas, une courte vidéo pour un parcours qui exige du matériel. La guideline 2.1 pèse plus de 40 % des problèmes non résolus et c'est le délai le moins cher à supprimer de cette liste. Si vous avez déjà été refusé, j'ai écrit séparément sur ce qu'Apple refuse au titre des guidelines 4.2 et 4.3, et il y a ici une page sur le rattrapage d'une app refusée.

Livrer assez souvent pour qu'aucune sortie ne porte tout le poids. Quand vos sorties sont espacées de quinze jours, deux jours d'examen sont du bruit. Quand vous livrez deux fois par an, chaque soumission emporte un quart de la feuille de route et chaque examen devient une urgence. C'est le même raisonnement de cadence que dans mon article sur la publication précoce, et il s'applique aux délais d'examen aussi directement qu'au classement.

Il y en a une cinquième qui ne raccourcit aucun examen et résout le problème de fond plus souvent qu'on ne le croit. Jusqu'à 100 personnes de votre propre équipe peuvent installer un build TestFlight quelques minutes après l'envoi, sans aucun examen. Les testeurs externes passent par la Beta App Review pour le premier build d'une version, une file distincte et plus courte. Si ce qu'il vous faut cet après-midi, ce sont de vraies personnes qui font tourner le correctif, cette route évite le store.

Le seul cas où je n'hésiterais pas

Perte de données. Plantage au lancement. Faille de sécurité. Des paiements qui prennent l'argent sans rien livrer. Tout ce dont chaque heure coûte aux utilisateurs quelque chose qu'ils ne récupéreront pas. C'est pour ça que le mécanisme a été construit, la demande s'écrit toute seule, et je l'enverrais dans l'heure.

Je partirais aussi du principe qu'elle peut être refusée et je ferais tout le reste en parallèle : une atténuation côté serveur si l'app en a la plomberie, un mot là où vos utilisateurs se plaignent déjà, et le correctif dans la file normale pour qu'il avance de toute façon.

L'attente est un problème de planification

L'examen accéléré est une faveur qui a de la mémoire. Il vaut à peu près une bonne urgence par an, et il change le moment où votre app est examinée, pas la manière.

Les équipes qui ne semblent jamais attendre après Apple ne sont pas celles qui ont un contact dans la maison. Ce sont celles qui ont soumis quinze jours avant la date qui les intéressait, et qui savent éteindre une fonctionnalité cassée depuis leur propre serveur pendant que le correctif suit la file ordinaire comme tout le monde.