Erreurs et refus
Sommaire
Réponse courte
Apple refuse une application quand elle ne respecte pas une des règles de l'App Store, les App Store Review Guidelines. Le message de refus cite toujours le numéro de la règle concernée : c'est ton point de départ.
Les causes les plus fréquentes, d'après Apple et le texte des règles :
- L'app n'est pas complète ou plante (section 2.1) : à elle seule, plus de 40 % des problèmes non résolus en revue selon Apple.
- La fiche ne reflète pas l'app : captures trompeuses, nom bourré de mots-clés, informations de confidentialité fausses (section 2.3).
- L'app n'apporte pas assez : un site web emballé dans une app, une simple liste de liens (section 4.2), ou une app sortie d'un service de génération d'apps et soumise par quelqu'un d'autre que le fournisseur du contenu (section 4.2.6).
- L'app ressemble trop à d'autres (section 4.3).
- L'app contient une fonction cachée ou non documentée (section 2.5.19).
- La confidentialité est mal gérée : pas de politique de confidentialité, demandes d'autorisation floues, pas de suppression de compte (section 5.1.1).
- Le paiement ne passe pas par Apple alors qu'il le devrait (section 3.1.1).
Un refus n'est pas définitif. Tu peux répondre à Apple, corriger et renvoyer, ou faire appel si tu penses qu'il y a une erreur.
Qui est concerné, et les exceptions
Toutes les apps, nouvelles ou mises à jour
Chaque version d'app, chaque achat intégré et certains autres éléments (événements, pages produit personnalisées) passent par la revue d'Apple. Une mise à jour peut donc être refusée même si la version précédente avait été acceptée.
Les premières apps sont examinées de plus près
Apple indique que certaines revues prennent plus de temps, notamment pour les apps qui ont peu ou pas d'historique de revue, celles qui demandent des documents (licences, autorisations) et celles qui touchent des sujets réglementés ou sensibles.
Les règles qui ne concernent que certaines apps
- La suppression de compte ne concerne que les apps qui permettent de créer un compte.
- Les achats intégrés ne concernent que les apps qui vendent du contenu ou des fonctions numériques.
- Les règles de modération (section 1.2) concernent les apps où les utilisateurs publient du contenu : voir Apps de rencontres et réseaux sociaux.
- Les apps de santé, de finance, de jeux d'argent ou de cryptomonnaies doivent souvent fournir des documents (licence, autorisation réglementaire).
Une exception pour les corrections de bugs
Pour une app déjà publiée, Apple indique ne pas bloquer une correction de bug pour une autre infraction aux règles, sauf problème légal ou de sécurité. Apple peut alors te proposer d'accepter la correction et de régler le reste dans la version suivante.
Procédure pas à pas
Étape 1 : lire le message de refus
Dans App Store Connect, ouvre ton app puis la section App Review. Le statut de ta soumission est Unresolved Issues et le message détaille les problèmes, avec le numéro de chaque règle concernée. Ouvre la page des règles et lis la section citée en entier.
Étape 2 : identifier la cause parmi les refus fréquents
Voici les causes les plus courantes, avec ce que dit la règle et comment l'éviter.
| Règle | Ce qu'Apple reproche | Comment l'éviter |
|---|---|---|
| 2.1 App Completeness | Plantage, texte provisoire, lien cassé, compte de démo absent, serveur éteint | Tester sur un vrai iPhone, fournir un compte de démo valide, laisser le serveur allumé |
| 2.1(b) | Achat intégré introuvable ou qui ne fonctionne pas | Rendre chaque achat visible et fonctionnel, ou expliquer dans les notes pourquoi il n'est pas visible |
| 2.3 Accurate Metadata | Description, captures ou confidentialité qui ne reflètent pas l'app | Décrire uniquement ce que l'app fait vraiment, montrer l'app en cours d'utilisation (2.3.3) |
| 2.3.7 | Nom trop long ou rempli de mots-clés, prix dans le nom | Un nom unique de 30 caractères maximum, sans marque d'autrui |
| 4.2 Minimum Functionality | Site web reconditionné, app trop pauvre, simple collection de liens (4.2.2) | Offrir de vraies fonctions d'app, utiles et durables |
| 4.2.6 Modèles et générateurs | App issue d'un générateur, soumise par un autre que le fournisseur du contenu | Publier depuis ton propre compte Apple Developer, avec ton propre contenu |
| 2.5.19 Fonctions cachées | Fonction cachée, inactive ou non documentée | Rendre visible et documenter tout ce que fait l'app |
| 4.3 Spam | Plusieurs Bundle ID pour la même app (4.3(a)), copie de l'existant (4.3(b)) | Une seule app avec des variantes, et une vraie différence |
| 5.1.1(i) Politique de confidentialité | Lien absent dans App Store Connect ou dans l'app, contenu incomplet | Un lien accessible dans l'app et sur la fiche, qui dit quelles données, pourquoi, et comment les supprimer |
| 5.1.1(ii) Autorisations | Texte d'explication flou pour la caméra, la position, etc. | Une phrase concrète par autorisation, avec un exemple d'usage |
| 5.1.1(v) Suppression de compte | Création de compte possible, mais pas de suppression depuis l'app | Un bouton de suppression facile à trouver, qui supprime vraiment le compte |
| 4.8 Services de connexion | Connexion uniquement via Google, Facebook, etc., sans alternative équivalente | Ajouter une option de connexion qui respecte les trois critères de la règle |
| 3.1.1 Achats intégrés | Contenu numérique débloqué par un autre moyen de paiement | Utiliser les achats intégrés d'Apple pour le contenu et les fonctions numériques |
| 5.1.1(ix) Bonne entité | App d'un secteur réglementé publiée par un particulier | Publier depuis le compte de l'organisation qui fournit le service |
Quelques précisions sur les plus fréquents :
Section 2.1, l'app incomplète. Apple demande des versions finales : pas de texte provisoire, pas de site vide, toutes les adresses web fonctionnelles. Si l'app demande une connexion, il faut fournir un compte de démonstration et laisser le serveur allumé. Apple recommande aussi d'indiquer dans les notes les appareils testés et les services externes utilisés (paiement, connexion, IA…). Si l'app propose des abonnements, Apple demande un compte de démonstration avec un abonnement expiré. Pour faire tester l'app par de vraies personnes avant l'envoi, voir TestFlight : tester ton app sur iPhone et Faire tester son app avant publication. Les vérifications techniques avant envoi sont dans Préparer techniquement une app iOS avant App Review.
Section 4.2, la fonctionnalité minimale. Apple attend que l'app aille « au-delà d'un site web reconditionné ».
Section 4.2.6, les apps issues d'un générateur. Les apps créées à partir d'un modèle commercial ou d'un service de génération d'apps (« app generation service ») sont refusées, sauf si elles sont soumises directement par celui qui fournit le contenu de l'app. Ces services ne doivent pas publier pour le compte de leurs clients. Conséquence concrète : chaque créateur publie depuis son propre compte Apple Developer (s'inscrire à l'Apple Developer Program), avec une app personnalisée et utile. C'est le modèle de Briksell : tu construis l'app avec l'outil, puis tu la soumets toi-même.
Section 2.5.19, les fonctions cachées. Mise à jour par Apple le 16 octobre 2026 : pas de fonction cachée, inactive ou non documentée. Ce que fait l'app doit être clair pour l'utilisateur et pour l'équipe de revue.
Section 4.3, le spam. Ne crée pas plusieurs Bundle ID pour la même app, une par ville ou par club (4.3(a)), et ne copie pas l'existant (4.3(b)). Dans les catégories déjà saturées (Apple cite par exemple les apps de rencontre, lampes torches, effets sonores, fonds d'écran, minuteurs simples), une nouvelle app n'est acceptée que si elle est nettement différente ou meilleure. Le détail est dans Refus 4.3 Spam.
Section 5.1.1(v), la suppression de compte. Si l'app permet de créer un compte, même automatiquement (compte « invité »), elle doit permettre de lancer sa suppression depuis l'app. Désactiver temporairement le compte ne suffit pas. Voir Suppression de compte obligatoire.
Section 4.8, les services de connexion. Si ton app utilise un service de connexion tiers (Google, Facebook…) pour le compte principal, elle doit aussi proposer une autre option de connexion qui : limite la collecte au nom et à l'adresse e-mail, permet de garder son adresse e-mail privée, et ne collecte pas les interactions à des fins publicitaires sans consentement. Sign in with Apple remplit ces critères : voir Sign in with Apple. Ce n'est pas nécessaire si l'app utilise uniquement ton propre système de compte, ou dans les autres exceptions listées par la règle.
Section 2.3, les informations de confidentialité. Les réponses App Privacy font partie des métadonnées et doivent être exactes. Voir Étiquettes de confidentialité App Store.
Section 3.1.1, le paiement. Pour débloquer des fonctions ou du contenu numérique dans l'app, il faut utiliser les achats intégrés d'Apple, avec des exceptions précises, et proposer un moyen de restaurer les achats. Voir Abonnements et achats intégrés Apple.
Étape 3 : répondre, ou corriger et renvoyer
Apple distingue deux cas.
Tu réponds directement, sans renvoyer de build, quand :
- Apple demande seulement des informations complémentaires ;
- le problème se règle en modifiant la fiche ou ton serveur (par exemple réactiver le compte de démo) ;
- Apple te propose d'accepter une correction de bug.
Utilise le bouton Reply to App Review dans App Store Connect. Attention : renvoyer l'app lance une nouvelle revue, et Apple ne pourra plus répondre à ton message précédent.
Tu renvoies un nouveau build quand le refus porte sur le build lui-même et que tu l'as corrigé. Corrige tous les points cités avant de renvoyer : renvoyer avec des problèmes non réglés retarde la revue et mène au même résultat.
Étape 4 : demander de l'aide ou faire appel
- Poser une question : réponds au message dans App Store Connect en étant précis (la fonction, la règle ou l'étape à clarifier). Tu peux y demander un appel avec un représentant d'Apple ; Apple indique que ces appels ont généralement lieu sous trois à cinq jours ouvrés.
- Faire appel : si tu penses que ton app respecte les règles, tu peux saisir l'App Review Board. Réponds d'abord au message de refus pour clarifier ; si ça ne suffit pas, dépose un appel qui cite la règle et explique point par point pourquoi ton app la respecte. Un seul appel par app refusée. Un appel complet ne garantit pas que la décision soit changée.
Erreurs fréquentes
Renvoyer sans avoir tout corrigé
Le message peut citer plusieurs règles. Si tu n'en corriges qu'une, l'app sera refusée de nouveau.
Renvoyer l'app pendant un appel
Apple précise que renvoyer l'app lance une nouvelle revue et clôt l'appel en cours.
Utiliser la réponse à App Review pour faire appel
Le champ de réponse sert aux questions. Un appel ou une demande de revue accélérée passent par les formulaires « Contact Us » dédiés.
Des notes de version trop vagues
La section 2.3.1(a) demande de décrire précisément, dans les notes pour la revue, les nouvelles fonctions et les changements. Une description générique est refusée.
Corriger le symptôme au lieu de la règle
Si Apple refuse pour une capture trompeuse, changer seulement cette capture ne suffit pas toujours : relis toute la section citée et vérifie le reste de la fiche.
Vérification
Avant de renvoyer ton app, coche chaque point. La liste est enregistrée seulement dans ton navigateur.
Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.
Sources Apple et date de vérification
Vérifié le 22 octobre 2026 sur les pages officielles d'Apple :
- App Store Review Guidelines (mise à jour du 16 octobre 2026) : sections 1.2, 2.1, 2.3, 2.3.1(a), 2.3.3, 2.3.7, 2.5.19, 3.1.1, 4.2, 4.2.2, 4.2.6, 4.3(a) et (b), 4.8, 5.1.1(i), (ii), (v) et (ix), règle sur les corrections de bugs.
- App Review, Avoiding common issues : au moins 50 % des envois examinés en moins de 24 h et 90 % en moins de 48 h, plus de 40 % des problèmes non résolus liés à la section 2.1, appel, revue accélérée, rendez-vous vidéo de 30 minutes.
- Track a submission's review status : quand répondre et quand renvoyer, causes de revues plus longues.
- Contact App Review : réponse dans App Store Connect, appel sous trois à cinq jours ouvrés.
- Appeal to the App Review Board : conditions et contenu d'un appel.
- Provide information for a complete review : informations et documents à fournir.
- 5.1.1(v) Offering account deletion et 5.1.1(ii) Write clear purpose strings : précisions d'Apple sur ces deux règles.
FAQ
Combien de temps faut-il pour être revu après une correction ?
Apple ne donne pas de délai spécifique pour un nouvel envoi. Le repère général reste le même : au moins 50 % des envois examinés en moins de 24 heures et 90 % en moins de 48 heures, sans garantie. Le détail est dans Combien de temps dure la validation App Store.
Peut-on parler à quelqu'un chez Apple ?
Oui. Tu peux répondre au message dans App Store Connect et y demander un appel ; Apple indique que ces appels ont lieu en général sous trois à cinq jours ouvrés. Apple propose aussi des rendez-vous vidéo de 30 minutes avec App Review pour parler des règles, des refus fréquents et de ce qui t'attend pendant la revue.
Une app créée avec l'IA est-elle refusée d'office ?
Les règles d'Apple ne contiennent pas d'interdiction des apps conçues avec l'aide de l'IA. Elles demandent en revanche une app complète, utile et différente (sections 2.1, 4.2 et 4.3), soumise directement par celui qui fournit son contenu (section 4.2.6) : donc depuis ton propre compte Apple Developer, pas celui de l'outil qui a généré l'app. Voir aussi Créer une app avec l'IA. Si ton app intègre elle-même des fonctions d'IA, lis aussi Publier une app d'IA sur l'App Store.
Mon app a été refusée pour la section 2.1 alors qu'elle marche chez moi. Pourquoi ?
Le plus souvent, l'équipe de revue n'a pas pu accéder à une partie de l'app : compte de démo expiré, serveur éteint, fonction réservée à un pays, achat intégré absent de la soumission. Apple teste sur de vrais appareils et de vrais réseaux. Explique les conditions particulières dans les notes pour la revue.
Est-ce que je risque mon compte développeur après un refus ?
Un refus ordinaire, non. Les règles prévoient en revanche l'exclusion de l'Apple Developer Program pour les fraudes, les manipulations ou les envois répétés d'apps de faible qualité (par exemple sections 2.3.1(a) et 4.3).
Passer à l'action
La plupart des refus se jouent avant l'envoi : une app complète, une fiche honnête, une confidentialité bien déclarée. Avec Briksell, l'IA écrit le code de ton app React Native / Expo à partir de ta description, et fournit des pages légales hébergées (modèles à relire, pas un conseil juridique). Pour les abonnés, App Store Readiness contrôle le code sur les règles Apple qui concernent ton app et le fait corriger par l'agent. Ce n'est pas une validation : seule Apple décide. La publication depuis Briksell arrive bientôt ; en attendant, tu exportes le code et tu soumets l'app depuis ton propre compte Apple Developer. Pour l'ordre complet des étapes, lis Comment publier une application iOS sur l'App Store, puis crée ton app.
Sources officielles
- App Store Review Guidelines · vérifiée
- App Review (Distribute) : Avoiding common issues · vérifiée
- App Review Help : Track a submission's review status · vérifiée
- App Review Help : Contact App Review for help with a submission · vérifiée
- App Review Help : Appeal to the App Review Board · vérifiée
- App Review Help : Provide information for a complete review · vérifiée
- App Review Help : 5.1.1(v) Offering account deletion in your app · vérifiée
- App Review Help : 5.1.1(ii) Write clear purpose strings · vérifiée
