L’examen d’Apple

Validation App Store : délais, refus et recours

La validation App Store est l’examen qu’Apple fait de chaque application avant sa mise en ligne. Voici les délais annoncés par Apple en octobre 2026, les refus les plus fréquents règle par règle et la marche à suivre si ton app est refusée. Pour situer cette étape dans un projet complet, commence par notre guide pour créer une application mobile.

Par Yoann Guetta et David Bohbot, cofondateurs de Yodavio · Publié le · Mis à jour le

1. Validation App Store : la réponse courte

Toute application, et chacune de ses mises à jour, passe par l’examen d’Apple (App Review) avant d’apparaître sur l’App Store. En octobre 2026, Apple vise au moins 50 % des soumissions examinées en moins de 24 heures et 90 % en moins de 48 heures, sans garantie : une première app peut attendre plus longtemps. La plupart des refus viennent d’une soumission incomplète, et un refus se rattrape : tu réponds à Apple, tu renvoies une version corrigée ou tu fais appel.

Les faits cités ici viennent des pages officielles d’Apple, consultées le 26 octobre 2026.

2. Comment se déroule l’examen d’Apple

Apple examine les apps, leurs mises à jour, les achats intégrés et les événements intégrés envoyés depuis App Store Connect, l’outil en ligne où se prépare la publication. Les critères sont écrits dans les App Review Guidelines, les « directives de vérification des apps », réparties en cinq parties : sécurité, performances, business, design et aspects juridiques. L’examinateur utilise l’app comme tes futurs utilisateurs : installée sur un vrai appareil, avec une connexion réelle.

Une fois l’app soumise, son statut évolue dans App Store Connect et Apple t’envoie un e-mail à chaque changement. Voici les principaux statuts, avec leur nom dans la documentation d’Apple :

  • Waiting for Review : Apple a reçu la soumission, l’examen n’a pas commencé. Tu peux encore modifier certaines informations, mais plus les captures d’écran.
  • In Review : l’examen est en cours. Tu peux encore retirer la soumission.
  • Rejected ou Metadata Rejected : l’app, ou seulement sa fiche, n’est pas acceptée. Le message d’Apple précise les règles en cause.
  • Pending Developer Release ou Ready for Distribution : l’app est acceptée. Dans le premier cas, c’est toi qui lances la publication.

Après l’acceptation, il peut falloir jusqu’à 24 heures pour que l’app apparaisse dans tous les pays choisis, et elle n’apparaît pas avant la date de sortie si tu en as fixé une. La version envoyée à des testeurs externes passe aussi par App Review : la première build ajoutée à un groupe externe est examinée. Lis notre guide pour tester ton application iPhone avec TestFlight, et celui sur la publication sur l’App Store pour le parcours complet.

3. Délai de validation : ce qu’Apple annonce vraiment

Sur sa page App Review, Apple indique en octobre 2026 que l’équipe travaille en continu et examine en général au moins 50 % des soumissions en moins de 24 heures, et 90 % en moins de 48 heures. Méfie-toi des pages qui répètent « 90 % en 24 heures » : ce n’est plus ce qu’Apple affiche.

Apple liste aussi, dans son aide sur le suivi des soumissions, ce qui allonge l’examen :

  • une app avec peu ou pas d’historique d’examen, ce qui est le cas d’une première app ;
  • des documents à vérifier : licences, autorisations, contrats de partenariat ;
  • des sujets complexes ou nouveaux : contenu réglementé, nouvelles capacités de la plateforme, fonctions sensibles ;
  • des refus répétés pour la même règle ;
  • un code d’authentification absent des notes : un appel peut alors être nécessaire, et il a lieu en général sous trois à cinq jours ouvrés.

Tu peux demander un examen accéléré en cas de circonstances exceptionnelles : corriger un bug critique, ou sortir l’app pour un événement auquel tu es directement associé. La demande se fait par formulaire, uniquement après la soumission, en expliquant la situation dans les notes. Apple l’accorde selon ses disponibilités et demande de la réserver aux vraies urgences.

En pratique, n’annonce pas de date de lancement avant l’accord d’Apple. Garde une marge dans ton planning, et choisis une publication manuelle si tu veux décider toi-même du jour de sortie une fois l’app acceptée.

Le mail d’App Store Connect pour BOOXS : « Congratulations! Review of your submission has been completed. It is now eligible for distribution. », soumis le 4 août 2026.
Le vrai mail d’Apple pour la version 1.2 de BOOXS : envoyée le 4 août 2026, acceptée par un mail reçu le 5 août. Cette fois-là, moins d’une journée ; pour d’autres envois, il a fallu plusieurs semaines.

4. Application refusée : les motifs les plus fréquents

Un rejet par Apple n’a rien d’exceptionnel. Selon le rapport de transparence 2025 de l’App Store, Apple a examiné 9 100 620 soumissions en 2025 et en a refusé 2 093 244, soit plus d’une sur cinq ; 387 087 ont été approuvées après un refus. Une même app pouvant être soumise plusieurs fois, ces chiffres comptent des soumissions, pas des apps.

Apple précise qu’en moyenne, plus de 40 % des problèmes non résolus relèvent de la règle 2.1 : plantages, contenus provisoires, informations manquantes. Voici les règles à connaître, avec leur numéro et leur contenu au 26 octobre 2026.

Les règles d’Apple à vérifier en priorité
RègleCe qu’Apple demandeÀ vérifier
2.1 Exhaustivité de l’appUne version finale, testée sur appareil, sans contenu provisoire, avec des liens qui marchent. Un compte de démonstration et un serveur actif si l’app demande une connexion. Des achats intégrés complets et visibles.Chaque écran, lien et achat fonctionne le jour de l’envoi.
2.3 Métadonnées précisesUne description, des captures et des informations de confidentialité fidèles à l’app. Des captures qui montrent l’app en usage (2.3.3). Un nom de 30 caractères maximum, sans prix ni mots-clés hors sujet (2.3.7).Aucune promesse de la fiche ne manque dans l’app.
3.1.1 Achats intégrésDébloquer une fonction ou un contenu numérique passe par l’achat intégré d’Apple, pas par une clé de licence ou un QR code. Les achats restaurables doivent pouvoir être restaurés.Les biens physiques et services consommés hors de l’app suivent l’inverse (3.1.3(e)).
4.2 Fonctionnalités minimalesPlus qu’un site web remis dans une app : une utilité durable, pas seulement de la publicité, un agrégateur ou une liste de liens.Ce que l’app apporte de plus que ton site.
4.3 SpamPas plusieurs versions de la même app (4.3(a)), pas de variante d’une catégorie déjà saturée (4.3(b)) : Apple cite les apps de rencontre, lampes torches, effets sonores, fonds d’écran, minuteurs simples et voyance.Ce qui distingue vraiment ton app.
4.8 Services de connexionSi le compte principal passe par une connexion tierce ou sociale (Google, Facebook…), proposer aussi une option équivalente : données limitées au nom et à l’e-mail, e-mail masquable, aucun suivi publicitaire sans consentement.Non exigé si l’app n’utilise que ton propre système de compte.
5.1.1 Collecte et stockage des donnéesUne politique de confidentialité liée dans App Store Connect et dans l’app, un consentement avant toute collecte, des demandes d’accès expliquées. Si l’app permet de créer un compte, sa suppression depuis l’app (5.1.1(v)).Pas de connexion obligatoire sans fonctions qui la justifient.

La page App Review d’Apple signale aussi les copies d’autres apps (4.1), les apps qui promettent ce qu’elles ne font pas (2.3), les interfaces jugées de qualité insuffisante et les apps sans valeur durable (4.2).

Deux règles concernent directement le porteur de projet. Certaines apps doivent être soumises par l’entité juridique qui fournit le service, pas par un développeur individuel : Apple cite la banque et la finance, la cryptomonnaie, la santé, les jeux d’argent et le transport aérien. Et une app créée à partir d’un modèle commercial ou d’un service de génération d’apps est refusée si elle n’est pas soumise directement par le fournisseur de son contenu (4.2.6).

5. Avant de soumettre ton app à Apple : la liste de contrôle

Cette liste reprend la rubrique « Before You Submit » des règles et l’aide App Review d’Apple. Elle ne garantit pas l’acceptation, Apple le dit lui-même, mais elle évite les refus pour oubli.

L’app elle-même

  • Les fonctions présentes sont terminées : aucun texte provisoire, aucune image temporaire, aucun écran vide.
  • L’app a été testée sur un iPhone réel avec la dernière version d’iOS. Teste-la aussi sur iPad : une app conçue pour iPhone peut y être téléchargée en mode compatibilité, et Apple demande de vérifier ce cas.
  • Le serveur et les services externes restent en ligne pendant l’examen.
  • La build est compilée avec Xcode 26 ou plus récent et le SDK d’iOS 26, une obligation d’Apple depuis le 28 avril 2026.
  • Chaque demande d’accès (appareil photo, micro, position…) explique clairement à quoi servira la donnée.
  • Si l’app permet de créer un compte, elle permet aussi de le supprimer depuis l’app, sans imposer un e-mail ou un appel au support.

Les informations pour l’examinateur

  • Un compte de démonstration valide au moment de l’envoi, pour chaque type de compte. Si l’app propose un abonnement, Apple demande un compte dont l’abonnement a expiré, pour tester tout le parcours d’achat.
  • Des notes d’examen qui présentent le concept, le modèle économique, le public, les appareils et versions d’iOS testés, les services externes utilisés (paiement, authentification, IA) et les éventuelles différences entre pays.
  • L’explication des fonctions peu visibles et des achats intégrés, avec les documents exigés pour un secteur réglementé ou l’usage de contenus appartenant à d’autres.
  • Tes coordonnées à jour, pour qu’Apple puisse te joindre.

La fiche et les achats

  • Des captures qui montrent l’app en cours d’utilisation, pas seulement le logo, l’écran de connexion ou l’écran de lancement.
  • Une description fidèle, un nom de 30 caractères maximum, un sous-titre sans prix ni référence à d’autres apps.
  • Un lien vers l’assistance, avec un contact à jour, et un lien vers la politique de confidentialité, tous deux fonctionnels.
  • Les questions de classification par âge remplies honnêtement.
  • Les achats intégrés configurés et testés dans l’environnement de test d’Apple (sandbox), avec le contrat des apps payantes accepté et en vigueur. Le premier achat intégré de chaque type part avec une version de l’app.
Deux cadres du canevas Figma des aperçus de FixScan : « Scanne un problème » avec l’écran de scan, et « L’IA identifie la panne » avec l’écran d’analyse.
Les aperçus de FixScan montés sur Figma, le 28 avril 2026 : chaque cadre montre un écran de l’app en cours d’utilisation.

Pour les textes et les captures de la fiche, notre guide sur la fiche App Store et l’ASO va plus loin.

6. Après un refus : que faire, dans l’ordre

Une application refusée par Apple n’est pas bloquée pour autant. Voici l’ordre à suivre.

  1. Lis le message d’Apple. Il arrive dans la section App Review de la page de ton app, dans App Store Connect, et cite les règles non respectées. Un statut « Metadata Rejected » concerne la fiche : tu la corriges et tu réponds au message, sans nouvelle build.
  2. Pose une question précise si le motif n’est pas clair. La réponse à App Review depuis App Store Connect est le bon canal, et un spécialiste qui connaît ton app te répond. Indique la fonction, la règle ou l’étape à clarifier. Après sa réponse, tu peux demander un appel en précisant ton fuseau horaire et ta langue ; compte en général trois à cinq jours ouvrés.
  3. Réponds sans renvoyer l’app quand c’est possible. Si Apple demande seulement des informations, ou si la correction porte sur la fiche ou le serveur (un compte de démonstration réactivé, par exemple), réponds au message. Renvoyer l’app lance un nouvel examen, et Apple ne peut plus répondre au message précédent.
  4. Renvoie une build corrigée quand le problème est dans l’app. Corrige tous les points cités avant l’envoi : renvoyer avec un problème non résolu retarde l’examen et mène au même résultat.
  5. Fais appel si tu penses que l’app respecte les règles. Réponds d’abord au message pour clarifier. Si cela ne suffit pas, le formulaire d’appel auprès de l’App Review Board permet de contester. Cite la règle, explique point par point en quoi l’app la respecte, et ne dépose qu’un appel par soumission refusée.

Pour une mise à jour d’une app déjà publiée, regarde le haut du message. S’il indique que les problèmes peuvent être traités dans la prochaine mise à jour (« Bug Fix Submissions »), tu peux faire approuver la correction maintenant et régler le reste dans la version suivante, sauf problème juridique ou de sécurité. Et si tu as un doute avant même d’envoyer, Apple propose des rendez-vous vidéo de 30 minutes avec App Review, le mardi et le jeudi. Ils sont informatifs : ils ne valident pas l’app à l’avance.

7. App Review Guidelines : la révision d’octobre 2026

Apple a publié le 16 octobre 2026 une révision des App Review Guidelines. Voici ce qu’elle annonce :

  • 1.2, contenus créés par les utilisateurs : les apps concernées sont précisées, et ne pas mettre en place les protections nécessaires, ou ne pas corriger après signalement, peut constituer une violation du code de conduite des développeurs. Le texte cite les réseaux sociaux, les plateformes de contenus et les apps de création de contenus par IA.
  • 2.3.14, nouvelle règle sur les visuels de promotion (« creative assets ») affichés sur l’App Store, en tête de fiche ou dans les résultats de recherche. Ils doivent concerner l’app, suivre les règles des métadonnées et ne pas afficher de prix précis ou réduit.
  • 2.5.19, nouvelle règle issue de l’ancienne 2.3.1 : aucune fonction cachée, dormante ou non documentée.
  • 3.1.1(a) : la mention des services de streaming musical rejoint celle des liens d’achat externes, et les liens peuvent mener vers une « destination autorisée ».
  • Section 5 : les apps qui facilitent la traite d’êtres humains ou l’exploitation d’enfants sont retirées de l’App Store et bloquées en distribution alternative.
  • « Before You Submit » et « After You Submit » : des liens vers de la documentation ont été ajoutés.

Attention à la version française : en octobre 2026, la traduction des directives affiche une dernière mise à jour au 8 juin 2026. Apple annonce les traductions de cette révision sous un mois. D’ici là, lis la version anglaise, qui est la plus récente.

8. Chez Yodavio : le jour 21, puis le délai d’Apple

Dans notre méthode de développement en 4 étapes, la dernière regroupe la fiche App Store, les tests sur TestFlight puis la soumission à Apple. Le jour 21 correspond à l’envoi à Apple. La validation dépend ensuite d’Apple : c’est pourquoi nous annonçons une date d’envoi, pas une date de mise en ligne.

Les applications du studio publiées sur l’App Store sont passées par cet examen : AudiCheck, consacrée au bien-être auditif, depuis le 10 avril 2026 ; FixScan, qui diagnostique une panne à partir d’une photo grâce à l’IA, depuis le 8 mai 2026, en français et en anglais ; BOOXS, consacrée à la lecture, depuis le 23 juillet 2026. Ce sont des projets du studio, pas des missions de clients.

Pour ton planning, deux conséquences. La liste de contrôle ci-dessus se boucle avant l’envoi, pas après un refus. Et la date de lancement s’annonce une fois l’app acceptée par Apple.

Notre expérience : sur nos propres apps, le temps entre l’envoi à Apple et la mise en ligne a beaucoup varié : parfois 3 jours, parfois 2 à 3 semaines, et même davantage, allers-retours compris. Au moins une de nos apps a été refusée une première fois parce qu’il manquait des éléments ; on les a ajoutés, puis on l’a renvoyée. Pour FixScan, c’est Apple qui nous a demandé de permettre la suppression du compte depuis l’app. C’est pour ça qu’on annonce une date d’envoi, jamais une date de mise en ligne.

9. Questions fréquentes

Ma première app est « en attente d’examen » depuis une semaine : est-ce normal ?

C’est au-delà de l’objectif d’Apple, mais Apple reconnaît qu’une app sans historique d’examen peut demander plus de temps. Des développeurs décrivent ce cas en octobre 2026 sur les forums d’Apple. Vérifie que ta soumission est complète : compte de démonstration, notes, documents. Retirer la soumission pour la renvoyer en crée une nouvelle, et rien dans la documentation d’Apple n’indique que cela accélère l’examen.

Une demande d’examen accéléré fait-elle passer devant ?

Seulement si Apple l’accepte, et elle est réservée aux bugs critiques et aux sorties liées à un événement. En cas d’abus, Apple peut refuser les demandes suivantes.

J’ai fait appel après un refus et je n’ai pas de nouvelles : faut-il renvoyer l’app ?

C’est la question posée en août 2026 sur les forums d’Apple après un refus au titre de la règle 4.3(b). Non : renvoyer l’app lance un nouvel examen et clôt l’appel. L’App Review Board répond dans App Store Connect à la fin de son enquête, et peut te demander des informations ou proposer un appel.

Apple répète le même refus sans détail : comment obtenir une explication ?

Réponds au message dans App Store Connect avec une question précise : quelle fonction, quelle règle, quel écran. Si la réponse ne suffit pas, demande un appel depuis la même fenêtre. Dans un fil public de juillet 2026 sur des refus répétés au titre de la règle 4.2, l’équipe App Review a indiqué avoir transmis l’appel du développeur pour examen.

Faut-il repasser l’examen à chaque mise à jour ?

Oui, chaque mise à jour est examinée. Selon Apple, les mises à jour mineures et les corrections de bugs passent en général rapidement. Décris précisément les nouveautés dans les notes d’examen : la règle 2.3.1 précise que les descriptions génériques sont refusées.

« Validation nécessaire » sur l’App Store : est-ce lié à l’examen ?

Non. Ce type de message apparaît chez la personne qui télécharge une app et concerne son compte Apple. Selon l’assistance Apple, le message « vérification requise » signale un solde impayé, qui peut bloquer jusqu’au téléchargement d’apps gratuites. Il n’a rien à voir avec l’examen de ton application.

À lire aussi

On parle de ton projet ?

Raconte-nous ton idée, ce que tu as déjà préparé et ta date idéale. L’appel découverte est gratuit.

Réserver un appel

Réserver un appel

Le formulaire ne s’affiche pas ? Ouvrir dans un onglet