Exigences de l’App Store : que Vérifier Avant de Soumettre

Votre date de lancement est entre les mains d’un relecteur qui n’a jamais vu votre produit. Il peut renvoyer tout le build pour un mot de passe de démonstration expiré ou un formulaire de classification d’âge sans réponse. Les exigences de l’App Store sont majoritairement administratives, et ce travail est le premier à passer à la trappe quand un lancement se resserre. Les problèmes faciles sont ceux que personne ne vérifie. Les repérer avant de soumettre est à cela que servent les tests de conformité de l’App Store.

La propre page App Review d’Apple indique que plus de 40 % des problèmes non résolus remontent à la directive 2.1, App Completeness. La catégorie couvre les plantages, le contenu d’espace réservé, et tout ce qui a été laissé vide. Ainsi, votre application peut fonctionner parfaitement et échouer quand même à la revue. L’approbation commence par une courte liste qui n’a rien à voir avec la qualité de votre application.

Vous avez besoin d’une adhésion active à l’Apple Developer Program et d’une fiche complète dans App Store Connect. Le build lui-même doit être compilé avec Xcode 26 et le SDK iOS 26. Apple demande aussi un compte de démonstration fonctionnel, des réponses actuelles à la classification d’âge, et une politique de confidentialité correspondant à ce que votre application collecte.

Chaque élément de cette liste est facile à confirmer, mais chacun peut arrêter une version. Cet article couvre ce qu’il faut vérifier avant de soumettre, ce qu’un rejet coûte en temps calendaire, et qui devrait posséder chaque décision.

Exigences de l'App Store à Remplir Avant de Soumettre

Deux exigences de soumission de l’App Store d’Apple ont changé en 2026, et aucune n’a de rapport avec les tests. Pourtant, elles continuent de piéger les équipes qui soumettent leur première mise à jour de l’année. L’une a rendu obligatoires les réponses aux questions révisées de classification d’âge d’Apple le 31 janvier. L’autre exige que vous compiliez chaque binaire avec Xcode 26 et le SDK iOS 26. Elle est entrée en vigueur le 28 avril et s’applique désormais à toutes les applications.

Les deux délais figurent sur la page des exigences à venir, et en manquer un vous arrête à l’étape du téléversement, avant que la revue ne commence. Confirmer chacun prend des minutes, mais personne ne planifie de temps pour quelque chose qui n’est pas une fonctionnalité.

Le troisième élément est la conformité à l’exportation, et elle n’a rien à voir avec les tests non plus. Le droit commercial américain couvre les logiciels utilisant le chiffrement, donc Apple doit demander si le vôtre en utilise. La vérité est que presque toutes les applications le font, car toute connexion en HTTPS compte. Vous pouvez répondre à cette question manuellement à chaque soumission. L’alternative est de la régler une fois dans le fichier de configuration Info.plist de l’application, après quoi Apple arrête de demander.

Ces trois éléments font partie d’une liste plus longue. Le tableau ci-dessous montre les exigences de l’App Store qui bloquent le téléversement, ainsi que qui dans votre entreprise possède réellement chacune.

Cette dernière ligne est un arrêt total si vous vendez dans l’Union européenne. Le Digital Services Act oblige Apple à publier un nom commercial et une adresse vérifiés pour chaque développeur qui liste une application là-bas. Ainsi, tant que vous ne fournissez pas le vôtre et qu’Apple ne le vérifie pas, votre application est entièrement retirée de l’App Store de l’UE. Le juridique et la finance possèdent ceci, pas l’ingénierie, alors commencez tôt. Une telle lacune relève des tests de conformité logicielle plutôt que du cycle QA mobile.

Les exigences de l’App Store d’Apple vont au-delà de ce tableau, bien que seules les lignes ci-dessus bloquent réellement le téléversement. Si vous livrez le build Android dans la même fenêtre, notre guide pour passer la revue Google Play couvre le terrain équivalent.

Les Six Questions à Répondre Avant de Soumettre

Remplir ces exigences ne fait que vous mettre dans la file d’attente. Ensuite, tout dépend de ce qu’un relecteur peut réellement faire avec votre build. Cherchez une checklist de soumission App Store et vous en trouverez une écrite pour des ingénieurs. Elle liste tout ce sur quoi un développeur clique et ne dit rien à un chef d’entreprise sur la sécurité du lancement. Au lieu de cela, la version ci-dessous est organisée autour de ce que vous devriez pouvoir confirmer, à voix haute, lors d’une réunion de lancement.

Un Inconnu Peut-il Accéder à Votre App sans Votre Aide ?

Un relecteur doit atteindre chaque fonctionnalité que vous livrez, et commence avec rien d’autre que votre build. C’est pourquoi la directive 2.1 d’Apple demande des détails de compte de démonstration et un backend en direct chaque fois que votre application inclut une connexion. La plupart des équipes fournissent les deux, mais peu confirment que les identifiants fonctionnent encore le matin où un relecteur les ouvre.

Vérifiez trois choses :

• Le compte de démonstration n’expire pas et ne se verrouille pas après des tentatives échouées.
• Le backend qu’il pointe fonctionne, pas seulement déployé.
• Les notes pour la revue décrivent chaque nouvelle fonctionnalité spécifiquement, car Apple rejette les formulations génériques.

Si des règles juridiques ou de sécurité vous empêchent de remettre un compte en direct, Apple accepte à la place un mode démo intégré, avec approbation préalable. Obtenir cette validation prend du temps que vous devez budgétiser.

Le Build que Vous Soumettez Est-il le Build que Vous avez Testé ?

Dans de nombreux cas, les builds de version divergent de ce que vous avez testé de façons petites et coûteuses :

• Un feature flag laissé activé
• Un endpoint de staging codé en dur dans un fichier de configuration
• Un achat intégré pointant encore vers le bac à sable

Rien de tout cela n’apparaît dans l’usage quotidien, car votre équipe utilise un build différent. La confirmation tient en une phrase : quelqu’un a installé le binaire exact sur un appareil propre et parcouru le chemin principal de bout en bout. Obtenir cela est la raison pour laquelle les tests d’applications mobiles devraient s’exécuter sur le candidat de version plutôt que sur une branche antérieure. C’est aussi l’endroit le moins coûteux pour détecter les problèmes de stabilité.

Votre Fiche Promet-elle Quelque Chose que le Build ne Fait pas ?

Le marketing écrit la fiche du store des semaines avant que l’ingénierie ne termine le build, tirant des captures d’écran des maquettes et des descriptions de la feuille de route. Puis une fonctionnalité glisse, et personne ne met à jour le texte.

La directive 2.3 d’Apple traite ce décalage comme des métadonnées inexactes, donc relisez votre propre fiche par rapport au build que vous êtes sur le point d’envoyer. Chaque affirmation a besoin d’une fonctionnalité correspondante qu’un relecteur peut atteindre sans instructions.

Avez-vous Répondu à Toutes les Questions qu'Apple Pose Maintenant ?

Les formulaires dans App Store Connect ne sont pas une formalité, et ils changent plus souvent que les équipes ne s’y attendent. Les déclarations de confidentialité doivent en particulier correspondre à ce que votre application collecte réellement, y compris les données récupérées par des SDK tiers que vous n’avez pas écrits. Personne dans votre équipe ne sait peut-être ce que ces bibliothèques transmettent, c’est pourquoi cela nécessite une vérification plutôt qu’une mémorisation.

L’intelligence artificielle (IA) est le domaine le plus récent qu’Apple a durci. La directive 5.1.2(i) exige de divulguer toute donnée personnelle que vous envoyez à une IA tierce. Vous avez aussi besoin d’une permission explicite avant qu’elle ne circule, ce que nous avons couvert dans les directives Apple sur le partage de données IA.

Les Utilisateurs Peuvent-ils Supprimer, Restaurer, et Signaler dans Votre App ?

Certaines exigences concernent ce que fait votre application, pas ce que vous en dites. Tout produit prenant en charge l’inscription doit aussi offrir la suppression de compte dans l’application. Les achats doivent être restaurables, et chacun d’eux doit être visible par le relecteur. Les applications qui permettent aux utilisateurs de publier du contenu doivent donner à tous la possibilité de signaler une publication et de bloquer son auteur.

Un relecteur essaiera chacun de ces points, testez-les donc de la même façon sur le build en cours d’expédition. La suppression comporte le plus de cas limites, budgétisez donc du temps pour elle.

Qui Est Responsable de la Réponse si Elle Revient ?

C’est la question que les chefs d’entreprise sautent, et c’est celle qui coûte le plus de temps calendaire. Un rejet arrive dans le Resolution Center d’Apple, le fil de messages attaché à votre soumission, avec un numéro de directive et une brève explication. Ensuite quelqu’un doit le lire, décider s’il nécessite une modification de métadonnées ou un nouveau build, et répondre.

Nommez cette personne avant de soumettre, ajoutez un remplaçant, et vérifiez qu’aucun des deux n’est en congé pendant la fenêtre de revue. Chaque heure où cette réponse reste non lue repousse votre date de lancement.

Ce que Coûte à Votre Lancement une Soumission Échouée

Un rejet n’est pas un ticket d’ingénierie, mais plutôt un événement métier avec une facture jointe. La majeure partie du coût retombe sur des personnes qui ne lisent jamais les directives. Apple traite 90 % des soumissions en moins de 24 heures, donc un build propre avance vite. Cependant, la seconde revue ne commence qu’une fois votre correctif prêt, et cette attente est ce qui vous coûte des jours. Le tableau ci-dessous montre ce qui glisse et qui l’absorbe.

La durée dépend de ce qui a cassé. Une correction de capture d’écran ou de description est un après-midi de travail, puis une nouvelle revue. Les changements de code nécessitent d’abord des tests de régression, ce qui transforme un petit bug en une semaine de retard.

La façon la moins chère de raccourcir cette boucle est de savoir ce qui la déclenche habituellement. Nous listons les causes courantes dans les raisons de rejet sur l’App Store, l’article à ouvrir si votre soumission est déjà revenue.

Où les Vérifications Préalables Échouent Généralement

Les équipes se trompent de deux façons opposées :

• La première consiste à traiter la checklist de soumission d’app iOS comme un événement unique. Elles l’exécutent à fond avant le lancement initial, puis la sautent pour les mises à jour, exactement quand la plateforme a bougé sous eux. Les règles d’Apple ont changé deux fois rien que dans les 4 premiers mois de 2026.
• La seconde est de surtester la mauvaise couche. L’accessibilité en est l’exemple le plus clair, car elle bloque rarement une revue App Store. Les équipes l’ignorent donc ou la traitent comme une porte de soumission, et les deux lectures ratent le point. La vraie pression vient de l’European Accessibility Act et des utilisateurs que vous perdez silencieusement. Cela place les tests d’accessibilité d’applications mobiles dans le plan de version plutôt que dans le formulaire de soumission.

Vérifier les exigences de l’App Store tôt prend une heure, plus un rappel calendaire pour les plus lentes. Trouver les mêmes lacunes pendant la revue peut vous coûter la date de lancement.

Comment QAwerk Vérifie un Build iOS Avant Soumission

Nous testons votre véritable candidat de version, pas une description de celui-ci. Cela signifie exécuter la checklist de revue App Store sur le binaire exact, installé sur de vrais appareils. Nos ingénieurs complètent les parcours d’inscription, d’achat, de restauration, et de suppression, puis comparent votre fiche à ce que le build fait réellement.

Vous recevez un rapport écrit de ce qui pourrait échouer et pourquoi, chaque élément étant lié à la directive qu’il touche. Nous avons fait exactement cela pour BeFamily, exécutant plus de 500 cas de test sur 9 appareils avant le lancement. L’application n’a eu aucun problème majeur en production depuis. Faites appel à nous pendant que la date de soumission peut encore bouger, et il y a de la place pour corriger ce que nous trouvons sans sprint d’urgence.

QAwerk teste des versions mobiles depuis 2015, et nous nous connectons à quelle que soit l’étape où se trouve votre projet. Votre date de lancement est la seule chose que vous ne pouvez pas récupérer, alors parlez-nous et trouvons ensemble ce qu’Apple pourrait signaler.

FAQ

Combien de temps faut-il pour corriger une soumission rejetée sur l'App Store ?

Cela dépend des exigences de l’App Store que vous avez manquées. Les problèmes de métadonnées comme une capture d’écran ou une description prennent quelques heures, puis une nouvelle revue qu’Apple renvoie généralement en une journée. Les corrections de code prennent plus de temps, car l’application reconstruite a d’abord besoin de tests de régression. Prévoyez le cas le plus lent, car vous ne saurez pas lequel vous affrontez avant d’avoir une réponse.

Combien de temps dure la revue de l'App Store ?

Apple examine 90 % de ce qu’il reçoit en moins de 24 heures. Les premières soumissions d’un nouveau compte développeur traînent souvent plus longtemps, tout comme les applications dans des catégories sensibles. Prévoyez 1 à 3 jours plutôt qu’une approbation le jour même, et ne programmez jamais un événement de lancement autour d’un délai de 24 heures.

Avez-vous besoin d'un compte de démonstration si votre app n'a pas de connexion ?

Vous n’en avez pas besoin, car Apple ne demande des identifiants de démonstration que lorsque votre application inclut une connexion. Le champ Notes pour la révision compte quand même, en décrivant toute fonctionnalité qui n’est pas évidente depuis l’interface, car un libellé générique est rejeté. Sans identifiants, quiconque prend en charge votre soumission ouvre simplement le produit et le parcourt sans assistance.

Pouvez-vous demander à Apple d'examiner votre app plus vite ?

Vous le pouvez, bien que seules deux situations soient éligibles à une demande de revue accélérée. La première est un bug critique affectant des utilisateurs en production, et la seconde est une application liée à une date publique fixe. Fournissez les étapes de reproduction du défaut, ou le nom et la date de l’événement. L’approbation est décidée au cas par cas et n’est jamais garantie, donc ne planifiez pas autour.

Devriez-vous faire appel d'un rejet ou corriger et resoumettre ?

Corrigez et resoumettez quand Apple a raison, ce qui est la plupart du temps. Contestez auprès de l’App Review Board quand vous pensez que la directive a été mal appliquée. Apple autorise un appel par soumission non validée, et attend que vous répondiez d’abord à toute demande d’informations supplémentaires. Contester une violation réelle ne vous coûte que des jours.