Délai validation App Store : combien de temps attendre
Par Mehdi Azizi
Mis à jour le , 9 min
Délai de validation App Store : ce qu'Apple annonce, ce qui rallonge l'attente, comment répondre dans le Resolution Center et les refus qui coûtent des jours.
Le délai de validation App Store est court sur le papier : Apple annonce examiner au moins 50 % des soumissions en moins de 24 heures, et 90 % en moins de 48 heures. Ce chiffre vient de la page officielle d'App Review. Pour une app qui passe du premier coup, tu peux donc t'attendre à une réponse en un jour environ.
Le vrai délai, lui, se compte autrement : c'est le temps entre ton premier envoi et le moment où l'app est en vente. Et ce qui le fait exploser, ce n'est presque jamais l'attente dans la file, ce sont les refus. Chaque refus relance un cycle complet : lire le motif, corriger, renvoyer, attendre de nouveau, y compris pour un refus automatique à l'envoi comme ITMS-90338. Ce guide explique ce qui allonge ce délai, comment gérer un refus sans perdre de jours, et quels motifs tombent le plus souvent sur une première app.
J'en parle depuis mes propres soumissions. Mes apps iOS, dont Solys (un réveil à mini-jeux) et TradaZen (un simulateur de trading), sont sur l'App Store, et j'ai pris plusieurs refus en chemin, sur Solys comme sur deux autres apps, Clic et Nolera. Les motifs sont détaillés plus bas.
Délai de validation App Store : ce qu'Apple annonce vraiment
Une fois ton build envoyé, sans erreur automatique comme ITMS-90725, et ta fiche complète, tu l'envoies en revue depuis App Store Connect. Ta soumission passe alors par plusieurs statuts : en attente (Waiting for Review), en cours d'examen (In Review), puis acceptée ou refusée. Apple te prévient par e-mail à chaque changement, et tu peux suivre l'état dans App Store Connect ou dans son application iPhone.
Trois précisions officielles utiles pour planifier :
- Ces chiffres sont des tendances, pas une garantie : jusqu'à une soumission sur dix attend plus de 48 heures.
- Les soumissions ne sont pas forcément examinées dans l'ordre d'envoi, précise l'aide App Store Connect.
- Une seule version de l'app peut être en cours d'examen par plateforme. Tu ne peux pas empiler plusieurs versions pour « gagner du temps ».
Une fois l'app acceptée, tu peux choisir de la publier automatiquement ou de la sortir toi‑même. Cette seconde option est précieuse : tu fais valider l'app d'abord, puis tu fixes ta date de lancement quand tu as le feu vert.
Ce qui allonge l'attente
Le délai s'allonge rarement à cause d'Apple. Il s'allonge presque toujours à cause de ce qu'on lui envoie.
La première soumission
Pour une toute première version, Apple examine tout d'un coup : la fiche, les captures, la classification par âge, la politique de confidentialité, les déclarations de collecte de données, les abonnements et l'app elle‑même. Chaque élément est une occasion de refus. Ce n'est pas la file qui est plus longue, c'est la surface qui est plus grande. Si tu n'as encore jamais publié, les étapes à préparer sont listées dans publier une application sur l'App Store.
Les abonnements et achats intégrés
Si ton app vend un abonnement, deux règles changent ton calendrier :
- Ton premier abonnement doit être soumis avec une nouvelle version de l'app. C'est écrit noir sur blanc dans l'aide sur les achats intégrés. Si l'app part sans lui, il faudra une nouvelle version pour le faire valider.
- Tous les éléments d'une soumission doivent être acceptés pour que la soumission le soit. Un abonnement refusé bloque l'ensemble.
La règle 2.1(b) demande aussi que les achats intégrés soient complets, visibles par le reviewer et fonctionnels. Si l'un d'eux n'apparaît pas dans l'app, explique pourquoi dans les notes de revue. Le montage complet d'un abonnement est détaillé dans abonnements in-app iOS.
Le compte de démonstration manquant
Si ton app demande une connexion, les App Review Guidelines exigent un compte de démonstration actif ou un mode démo complet, et des services serveur allumés pendant la revue. Sans identifiants dans la section App Review Information de ta version, le reviewer reste bloqué à l'écran de connexion, et c'est un refus. Pense aussi à ne pas couper ton serveur de test pendant la revue.
Les refus eux-mêmes
C'est le premier facteur, de loin. Apple indique que plus de 40 % des problèmes non résolus concernent la règle 2.1, celle qui couvre les plantages, le contenu provisoire et les informations incomplètes. Un refus évité, c'est au moins un cycle de gagné.
Répondre dans le Resolution Center
Quand une soumission est refusée, son statut passe à Unresolved Issues. Le message d'Apple cite la règle enfreinte, souvent avec une capture d'écran du problème. Tout se passe dans la section App Review de ton app dans App Store Connect, qu'on appelle encore souvent le Resolution Center.
La procédure officielle pour répondre à App Review :
- Dans ton app, clique sur le lien des problèmes non résolus en haut de la page.
- Clique sur Resolve à côté de la soumission.
- Clique sur Reply to App Review, écris ta réponse (4 000 caractères au maximum) et joins si besoin une capture ou un document.
Ce qui rend une réponse efficace :
- Nomme la correction, pas ton ressenti. « La demande de note apparaît désormais après la démo gagnée, capture jointe » vaut mieux qu'un long plaidoyer.
- Joins une preuve. Une capture ou une courte vidéo de l'écran corrigé évite un aller-retour de questions.
- Si le refus porte uniquement sur les métadonnées (texte de la fiche, captures, liens, comme un refus 2.3.10), Apple précise que tu peux renvoyer le même build après correction. Pas besoin de recompiler.
Faire appel, seulement si tu es sûr
Tu peux contester un refus devant l'App Review Board. Apple demande d'expliquer précisément pourquoi l'app respecte les règles, de ne faire qu'un seul appel par soumission refusée, et de répondre d'abord aux demandes d'information en attente. Un appel sur un refus mérité ne fait que rallonger l'attente.
Soumettre une correction vite
Quand le motif est clair, la vitesse vient de la discipline :
- Corrige le motif, et seulement le motif. Glisser trois nouveautés dans le build corrigé, c'est rouvrir la surface de revue.
- Teste la correction dans les conditions du reviewer. Pour un problème d'affichage, ça veut dire le plus petit iPhone pris en charge et le plus grand, pas seulement le tien.
- Attention aux éléments retirés. Dans une soumission avec des problèmes non résolus, l'aide Apple précise qu'un élément retiré ne peut pas être rajouté à la même soumission, et que chaque élément ne se modifie qu'une fois avant renvoi. Réfléchis avant de supprimer un abonnement refusé.
- Renvoie, puis réponds. Une ou deux phrases factuelles dans ta réponse pour dire ce qui a changé.
Et la revue accélérée ? Elle existe, mais Apple la réserve à deux cas : la correction d'un bug critique sur une version déjà publiée, avec les étapes pour le reproduire, et les apps liées à un événement daté. Ce n'est pas un raccourci pour une première publication en retard. La procédure et deux modèles de demande sont dans revue accélérée App Store : comment la demander.
Les refus les plus fréquents chez les débutants
J'ai déjà raconté en détail mes deux refus sur Solys dans pourquoi Apple refuse une app. Voici les motifs que j'ai réellement pris, avec leur numéro de règle, parce que ce sont exactement ceux qui guettent une première app.
2.1, l'app ne fonctionne pas (Solys). La démo d'accueil de Solys était impossible à gagner sur un petit écran d'iPhone : une étape obligatoire infranchissable, donc une app jugée incomplète. Corrigée depuis.
5.6.3, la demande de note trop tôt (Solys). La note App Store était demandée au début de l'onboarding, avant que la personne ait vécu quoi que ce soit dans l'app. Elle doit venir après un vrai moment de valeur.
5.1.1, la politique de confidentialité pas à jour (Clic). La règle 5.1.1 exige un lien vers la politique de confidentialité dans App Store Connect et dans l'app, et cette politique doit décrire précisément les données collectées, leur usage et la façon de les supprimer. Sur Clic, la version en ligne n'était pas à jour. Une politique qui ne suit pas ton produit suffit à faire refuser la soumission.
5.1.1, le bouton « Autoriser » avant la demande système (Nolera). Nolera affichait un écran d'explication avant la demande d'accès à la caméra, avec un bouton intitulé « Autoriser ». Les Human Interface Guidelines sur la confidentialité sont claires : un écran avant l'alerte système est permis, mais son bouton ne doit pas reprendre « Autoriser » ou un terme proche, puisqu'on n'autorise rien à ce stade. Apple recommande « Continuer » ou « Suivant ».
2.3.2, l'icône réutilisée comme image promotionnelle d'abonnement (Nolera). La règle 2.3.2 encadre la mise en avant des achats intégrés sur l'App Store : nom, image et description doivent être adaptés. Sur Nolera, l'image promotionnelle de l'abonnement reprenait simplement l'icône de l'app. Il faut une image propre à l'achat.
Ce qui relie ces cinq refus : aucun n'était un problème de code complexe. Tous se voyaient en relisant le dossier avec les yeux d'un reviewer. Si ton app vient d'être refusée et que le motif reste flou, la démarche complète est dans application refusée par Apple.
Prévoir le délai dans ton planning
Quelques règles simples pour que la revue ne décale pas ton lancement :
- N'annonce pas de date avant l'acceptation. Fais valider l'app, choisis la publication manuelle, puis fixe ta date.
- Garde une marge d'au moins un cycle de refus si c'est ta première soumission ou ton premier abonnement.
- Ouvre ton compte développeur tôt si tu passes par une société : le numéro D-U-N-S à lui seul peut prendre plus d'une semaine. Tout est expliqué dans le guide du compte développeur Apple.
- Relis ton dossier comme un reviewer : compte de démo, politique de confidentialité à jour, privacy manifest complet, écrans de permission, images d'abonnement, et chaque écran obligatoire sur petit et grand iPhone.
Si tu veux faire relire ton dossier avant l'envoi
Le Kit Review Apple réunit ma checklist avant l'envoi, mes refus d'Apple corrigés et des skills Claude Code qui relisent ton projet, ton paywall et ta fiche. Il ne garantit pas l'acceptation, c'est Apple qui décide, mais il t'aide à attraper les motifs listés plus haut avant qu'ils te coûtent un cycle.
Tu prépares ton premier envoi ? Le diagnostic gratuit t'envoie ma checklist anti-refus Apple et te dit ce qui reste à faire. Si ton app est déjà bloquée, réserve une heure avec moi : on lit le message d'Apple ensemble, en visio. Et si tu en es encore à la construire, l'accueil montre comment créer ton application mobile en pensant à la review dès le départ.
Questions fréquentes
Quel est le délai de validation d'une app sur l'App Store ?
Apple annonce examiner au moins 50 % des soumissions en moins de 24 heures, et 90 % en moins de 48 heures. Ce n'est pas une garantie : certaines prennent plus longtemps, et elles ne sont pas forcément examinées dans l'ordre d'envoi. Le vrai délai, c'est le temps entre ton premier envoi et la mise en vente, et il s'allonge surtout à cause des refus.
Qu'est-ce qui allonge le délai de validation d'une app ?
Les refus, de loin : chacun relance un cycle complet (lire le motif, corriger, renvoyer, attendre de nouveau). Apple indique que plus de 40 % des problèmes non résolus concernent la règle 2.1, celle des plantages, du contenu provisoire et des informations incomplètes. Une première soumission multiplie aussi les occasions de refus, car Apple examine tout d'un coup.
Comment répondre à un refus de l'App Store ?
Dans la section App Review de ton app, ouvre les problèmes non résolus, clique sur Resolve puis sur Reply to App Review. Écris ta réponse (4 000 caractères au maximum), nomme la correction plutôt que ton ressenti et joins une capture ou une courte vidéo. Si le refus ne porte que sur les métadonnées, tu peux renvoyer le même build après correction. Si le motif reste flou, lis application refusée par Apple.
Peut-on demander une validation accélérée à Apple ?
Oui, la revue accélérée existe, mais Apple la réserve à deux cas : la correction d'un bug critique sur une version déjà publiée, avec les étapes pour le reproduire, et les apps liées à un événement daté. Ce n'est pas un raccourci pour une première publication en retard.
Le premier abonnement doit-il être soumis avec l'app ?
Oui, d'après l'aide d'Apple : ton premier abonnement doit être soumis avec une nouvelle version de l'app. Si l'app part sans lui, il faudra une nouvelle version pour le faire valider. Pour que la soumission soit acceptée, tous ses éléments doivent l'être : un abonnement refusé bloque l'ensemble.
Quand annoncer la date de lancement de son app ?
Pas avant l'acceptation de l'app par Apple. Choisis la publication manuelle : tu fais valider l'app d'abord, puis tu fixes ta date de lancement quand tu as le feu vert. Si c'est ta première soumission ou ton premier abonnement, garde aussi une marge d'au moins un cycle de refus.

