Rester longtemps "En attente d'examen" sur l'App Store veut dire que votre app est dans la file d'attente d'Apple, avant qu'un examinateur ne l'ouvre. Ce n'est pas un rejet ni un blocage de votre compte, c'est simplement une position dans une file dont la longueur varie. En moyenne, l'examen prend moins de 24 heures, mais ce n'est qu'une moyenne, et en 2026 la file s'est allongée à plusieurs jours pour beaucoup de développeurs. Tant que vous restez dans une fenêtre raisonnable, attendre vaut mieux que renvoyer un build, car un nouvel envoi vous renvoie en fin de file.
Réponse rapide
"En attente d'examen" signifie que votre soumission est dans la file, en attente qu'un examinateur d'Apple la prenne en charge; elle n'est pas encore "En cours d'examen". Apple indique que "en moyenne, 90 % des soumissions sont examinées en moins de 24 heures", d'après sa page App Review, mais c'est une moyenne, pas une garantie. Quelques heures à 48 heures dans cet état sont normales. Un nouvel envoi n'accélère rien et vous fait perdre votre place. Au-delà de plusieurs jours, contactez l'assistance avec des captures et des dates.
Que veut dire "En attente d'examen" ?
"En attente d'examen" est l'étape de file d'attente: votre build a été traité et attend qu'un examinateur l'ouvre, sans que personne ne l'ait encore regardé. C'est différent de "En cours d'examen", où une personne évalue déjà votre app. La distinction compte, car une longue attente dans la file relève surtout du volume et de votre position, tandis qu'un blocage prolongé en cours d'examen tient plutôt à un point précis de votre app.
Ce n'est ni une erreur ni une sanction. Chaque soumission passe par cette file, et sa durée dépend de facteurs que vous ne contrôlez pas entièrement. Il est aussi utile de distinguer les rejets: "Rejeté" vise un problème dans l'app ou son comportement, tandis que "Métadonnées rejetées" ne concerne qu'un élément comme une capture ou une description, corrigeable sans nouveau build. Dans les deux cas, le détail apparaît dans le Centre de résolution, l'endroit où vous devez répondre, et non dans un nouvel envoi. Comprendre cette différence évite la réaction la plus courante et la plus contre-productive, qui consiste à renvoyer un build alors que la file d'attente, elle, n'a rien à voir avec le contenu de votre app.
Combien de temps dans la file est normal ?
Quelques heures à 48 heures d'attente sont normales; au-delà de trois à quatre jours sans mouvement, cela devient inhabituel. Toute valeur précise est une moyenne observée, pas une promesse d'Apple. Le tableau ci-dessous situe les états et le seuil d'alerte.
| État dans App Store Connect | Ce que cela signifie | Délai normal | Signal d'alerte |
|---|---|---|---|
| En attente d'examen | Dans la file, pas encore ouvert | Heures à 48 heures | Plus de 3 à 4 jours sans changement |
| En cours d'examen | Un examinateur évalue l'app | Minutes à 24 heures | Plus de 48 heures dans cet état |
| En attente de mise en vente | Approuvée, en attente de votre action | État final, vous décidez | (aucun) |
| Rejeté | Problème dans l'app | Action de votre part | Consultez le Centre de résolution |
| Métadonnées rejetées | Problème de métadonnées uniquement | Corrigez et répondez | (aucun, rapide) |
En février et mars 2026, la file s'est nettement allongée. Dans un fil des forums développeurs d'Apple, de nombreux développeurs ont signalé des soumissions restées en attente d'examen pendant des jours, parfois des semaines. Si vous soumettez pendant une de ces périodes, une attente longue ne signale pas forcément un problème de votre côté, mais souvent un simple engorgement.
Qu'est-ce qui détermine votre place dans la file ?
Votre position dépend surtout du type de compte et du type de soumission, pas de la qualité de votre code. Les comptes nouveaux ou signalés pour un contrôle plus approfondi sont souvent examinés plus lentement, car Apple consacre davantage de temps à certaines apps pour mieux protéger les utilisateurs. La première soumission d'une nouvelle app attend en général plus longtemps qu'une mise à jour, parce qu'Apple évalue tout pour la première fois: autorisations, confidentialité déclarée, classification par âge.
D'autres éléments pèsent aussi. Les autorisations sensibles, comme l'accès à la localisation en arrière-plan ou aux données de l'utilisateur, un formulaire de confidentialité récemment modifié, ou des changements importants dans l'app déclenchent un examen plus minutieux qui vous fait avancer plus lentement. Enfin, le moment de l'envoi joue: les périodes de fort volume, comme le lancement d'une bêta d'iOS ou les semaines proches d'un événement Apple, allongent la file pour tout le monde, indépendamment de votre app. Vous ne pouvez pas changer votre position directement, mais vous pouvez éviter de la perdre: ne renvoyez pas de build sans raison, et fournissez dès le départ des métadonnées et des notes d'examen complètes pour ne pas retomber dans la file après un aller-retour évitable.
Un nouvel envoi vous fait-il perdre votre place ?
Oui. Envoyer un nouveau build de la même version remplace celui qui attend et vous renvoie à la fin de la file. Beaucoup de développeurs renvoient par impatience et rallongent ainsi leur propre attente sans s'en rendre compte. Un nouvel envoi ne se justifie que si vous avez corrigé un vrai problème qui aurait entraîné un rejet.
La meilleure approche est de laisser la soumission en place et d'attendre dans la fourchette normale. "Pousser" la file avec des envois répétés ne fonctionne pas, car votre position se réinitialise à chaque fois. Regroupez vos modifications dans un seul build propre plutôt que de multiplier les tentatives, et vous garderez la place que vous avez déjà gagnée dans la file.
L'examen accéléré permet-il de doubler la file ?
L'examen accéléré peut faire passer votre soumission devant les autres, mais il est réservé aux urgences réelles. Apple propose un formulaire de demande, pensé pour des cas comme un bug critique en production ou une date impérative liée à un événement. Ce n'est pas un raccourci à utiliser à chaque envoi: en abuser réduit votre crédibilité pour les fois où vous en aurez vraiment besoin, et l'accélération n'est jamais garantie.
Pour un rejet, n'utilisez pas l'examen accéléré: répondez dans le Centre de résolution, le canal qu'Apple lit pour ces dossiers. Gardez aussi à l'esprit que, pendant l'engorgement de 2026, plusieurs développeurs ont indiqué que même les demandes accélérées tardaient à aboutir, donc considérez-le comme une option utile mais non fiable à 100 %.
Que faire selon la durée d'attente
Déterminez d'abord depuis combien de temps vous patientez, puis agissez sans renvoyer par réflexe. Le tableau ci-dessous donne une route claire selon votre situation.
| Votre situation | Que faire d'abord | Quand escalader |
|---|---|---|
| Moins de 48 heures | Attendre, c'est normal | Pas encore |
| Entre 2 et 7 jours | Vérifier métadonnées, notes pour l'examen et conformité à l'exportation | Préparez un dossier |
| Plus de 7 jours sans changement | Contacter l'assistance avec dates et captures | Immédiatement |
| Urgence réelle et vérifiable | Demander un examen accéléré | Tout de suite, avec justification |
| État "Rejeté" | Lire le motif dans le Centre de résolution et corriger | Seulement si c'est une erreur d'Apple |
Avant d'escalader, vérifiez que la conformité à l'exportation est complète, que la note "pour l'examen" explique comment tester l'app avec un compte de démonstration si votre app demande une connexion, et qu'aucune autre soumission de la même app ne bloque le processus. Ces trois points expliquent une bonne partie des attentes qui ressemblent à un blocage mais viennent d'une information manquante.
Avant d'envoyer, vérifiez le build
Le meilleur moyen de ne pas subir la file deux fois est de ne pas gaspiller un cycle sur une app qui allait être rejetée. Chaque rejet vous renvoie en fin de file, donc un problème évitable, comme une clé secrète intégrée au binaire, une autorisation sans justification ou une configuration réseau non sécurisée, peut vous coûter une nouvelle attente complète, surtout quand la file est déjà longue.
Un scanner de sécurité comme PTKD.com analyse le fichier .ipa avant l'envoi et renvoie un rapport classé par gravité et aligné sur OWASP MASVS, pour corriger ce qui déclencherait un rejet avant d'entrer dans la file. Soyons honnêtes sur sa limite: un scanner n'accélère pas l'examen d'Apple et ne remplace pas un audit manuel pour les apps à haut risque ou réglementées. Il évite en revanche les rejets prévisibles qui vous obligent à refaire toute l'attente, ce qui compte d'autant plus lorsque la file met déjà plusieurs jours. En clair, un scanner agit en amont, sur ce que vous contrôlez dans votre build, pendant que la durée de la file, elle, dépend uniquement d'Apple.
À retenir
- "En attente d'examen" veut dire que vous êtes dans la file, avant qu'un examinateur n'ouvre votre app; ce n'est ni un rejet ni une sanction.
- Quelques heures à 48 heures sont normales; au-delà de plusieurs jours, c'est inhabituel, et 2026 a connu de longues files.
- Votre place dépend du type de compte, de la première soumission, des autorisations sensibles et du volume, pas de la qualité du code.
- Un nouvel envoi de la même version vous renvoie en fin de file; réservez l'examen accéléré aux vraies urgences.
- Avant d'envoyer, vérifiez le build avec PTKD.com pour ne pas subir la file une seconde fois à cause d'un rejet évitable.
