Application refusée par Apple : Comprendre et corriger 

Nous prévenons toujours nos clients avant de soumettre une app : la review Apple n’est jamais acquise d’avance, et une application refusée par Apple peut repousser la date de lancement.

Ce n’est pas pour autant une mauvaise nouvelle en soi : c’est le plus souvent un problème qui se corrige.

Je suis cheffe de projet chez TheCodingMachine, une agence qui conçoit des applications web et mobiles sur mesure depuis 2005. Je publie régulièrement des applications sur l’App Store pour nos clients et je gère les échanges avec l’équipe de review d’Apple. Ce que j’ai appris : un refus ne dit presque jamais « votre app est mauvaise ». Il dit « il manque quelque chose pour que nous puissions la valider ».

 Pourquoi Apple rejette-t-il autant d’applications ?

Parce qu’Apple examine chaque application et chaque mise à jour à la main avant de la publier, et applique des règles strictes de qualité, de sécurité et de respect de la vie privée.

Rien n’arrive sur l’App Store sans être passé devant un reviewer.

Voici ce que montrent les chiffres publiés par Apple dans son rapport de transparence 2025 :

9,1 M

soumissions examinées

23 %

refusées (2 093 244)

387 087

apps validées après un premier refus

166 899

apps retirées de l’App Store

Le premier motif de loin est la performance (1,35 million de refus) : apps incomplètes, bugs, liens morts, informations manquantes. Viennent ensuite les sujets juridiques (données personnelles, propriété intellectuelle), le design, le business (paiements) et la sécurité des utilisateurs.

Les exigences strictes de l’App Store

Toute application publiée sur l’App Store doit respecter deux textes :

• les App Store Review Guidelines, les règles de publication, organisées en 5 grandes parties : sécurité, performance, business, design et juridique ;
• le contrat de licence du programme Apple Developer, que vous acceptez en créant votre compte Apple Developer. Il fixe ce que vous avez le droit de faire avec les outils d’Apple, et ce qu’Apple peut faire si vous ne respectez pas les règles (jusqu’à la fermeture du compte en cas de fraude).

Apple applique ces règles à toutes les apps, qu’elles soient publiées par une startup ou par un grand groupe.

L’évolution des guidelines Apple en 2026

Les règles changent plusieurs fois par an. Voici ce qui a bougé récemment et qui provoque des refus en 2026 :

Les 10 motifs de refus les plus courants sur l’App Store

Voici les motifs que nous rencontrons le plus souvent, avec la règle Apple concernée et la correction type.

Non-respect des conditions générales d’utilisation

Apple vérifie que votre app respecte son contrat de licence et qu’elle présente ses propres règles aux utilisateurs. Concrètement, il faut :

• un lien vers votre politique de confidentialité, dans l’app et dans la fiche App Store ;
• pour une app avec abonnement, un lien vers vos conditions générales d’utilisation ou vers le contrat de licence utilisateur final standard d’Apple (EULA), dans la description et sur l’écran d’achat ;
• des présentes conditions générales accessibles avant que l’utilisateur ne paie ou ne crée un compte.

Un lien cassé ou une page « en construction » suffit à provoquer un refus.

Problèmes de confidentialité et protection des données

C’est le motif qui demande le plus de travail à corriger, car il touche souvent au parcours de l’app.

Les points contrôlés :

• l’app ne demande que les informations dont elle a besoin, et explique pourquoi (accès à la caméra, à la position, aux contacts) ;
• L’utilisateur doit pouvoir supprimer son compte directement depuis l’application, sans avoir à passer par e-mail ;
• si l’app propose « Se connecter avec Google », elle doit aussi proposer une option de connexion respectueuse de la vie privée, comme « Se connecter avec Apple » ;
• l’app ne force pas la création d’un compte si ses fonctionnalités principales n’en ont pas besoin (règle 5.1.1(v)).

Fonctionnalités incomplètes ou bugs critiques

C’est la première cause de refus (règle 2.1, « App Completeness »).

Le reviewer teste votre app comme un utilisateur. Il refuse si :

• l’app plante au lancement ou sur un parcours principal ;
• un bouton ne mène nulle part, une page affiche « bientôt disponible » ;
• il ne peut pas se connecter, faute de compte de démonstration fourni dans les notes de review ;
• le serveur de test est coupé au moment de la review.

Interface utilisateur non conforme aux standards iOS

Apple refuse les apps dont l’interface est confuse, inachevée ou qui ne ressemble pas à une app iOS.

Les motifs fréquents :

• une app qui se contente d’afficher un site web dans une fenêtre, sans fonctionnalité propre (règle 4.2, « fonctionnalités minimales ») ;
• des textes coupés, des éléments qui se chevauchent sur certains modèles d’iPhone ou sur iPad ;
• des boutons trop petits, une navigation qui ne suit pas les habitudes iOS (bouton retour, gestes).

La règle 4.2 est un piège classique pour les entreprises qui veulent « mettre leur site dans une app ». Une app doit apporter quelque chose en plus : notifications, mode hors ligne, accès à l’appareil photo, parcours pensé pour le mobile.

Contenu inapproprié ou trompeur

Toute app qui publie du contenu créé par ses utilisateurs doit pouvoir le modérer.

Apple demande :

• un filtre ou une modération des contenus ;
• un bouton pour signaler un contenu ou un utilisateur ;
• la possibilité de bloquer un utilisateur ;
• des coordonnées de contact visibles.

Depuis juin 2026, l’éditeur est explicitement responsable de retirer les contenus qui enfreignent les règles. Sans plan de modération, l’app peut être retirée.

Système de paiement non conforme

Si votre app vend du contenu numérique ou un abonnement utilisé dans l’app, vous devez passer par l’achat intégré d’Apple (règle 3.1.1). C’est l’un des refus les plus difficiles à accepter pour nos clients, car Apple prélève une commission sur ces transactions.

Les règles à connaître :

• contenu numérique (abonnement, fonctionnalités premium, crédits) : achat intégré Apple obligatoire ;
• biens et services physiques (commande de repas, réservation d’un artisan, vente de produits) : paiement classique autorisé, via Stripe par exemple ;
• en France et dans le reste de l’Union européenne, le DMA (règlement sur les marchés numériques) oblige Apple à ouvrir plusieurs voies : un lien vers un paiement externe (commission réduite, autour de 15 %), un prestataire de paiement tiers dans l’app, ou même une distribution hors App Store.
  Chaque option a ses propres règles de présentation et sa propre commission ;

Métadonnées trompeuses ou spam

La fiche App Store doit décrire fidèlement l’app.

Apple refuse :

• des captures d’écran qui ne montrent pas la vraie app (maquettes, visuels marketing seuls) ;
• une description qui promet des fonctionnalités absentes ;
• des mots clés de marques concurrentes dans le titre ou le sous-titre ;
• plusieurs apps presque identiques publiées par le même éditeur (règle 4.3, « spam »).

Ce dernier point concerne les agences et les éditeurs « marque blanche » : publier la même app pour dix clients avec seulement le logo qui change peut être refusé.

Utilisation abusive des API Apple

Une app ne doit utiliser que les API publiques d’Apple, et seulement pour ce à quoi elles servent.

Motifs fréquents :

• une permission demandée sans justification claire (« Cette app souhaite accéder à votre position » sans expliquer pourquoi) ;
• des notifications utilisées pour de la publicité sans accord de l’utilisateur ;
• l’usage d’API non documentées, souvent via une librairie tierce ;
• des Live Activities utilisées pour du spam (nouvelle règle de juin 2026).

Les librairies tierces sont un vrai sujet : une app peut être refusée à cause d’un SDK de publicité ou de statistiques que l’équipe n’a pas écrit elle-même.

Problèmes de performances et stabilité

Apple vérifie que l’app fonctionne bien sur les appareils et les versions d’iOS actuels.

Les causes de refus :

• une app lente, qui consomme trop de batterie ou chauffe l’appareil ;
• une app qui ne fonctionne pas sur iPad alors qu’elle est déclarée compatible ;
• une app compilée avec un outil trop ancien : depuis avril 2026, Xcode 26 est obligatoire.

Violations de propriété intellectuelle

Vous devez avoir le droit d’utiliser tout ce qui apparaît dans votre app : logos, marques, images, musiques, polices de caractères, données. Apple refuse une app qui :

• utilise le nom ou le logo d’une marque sans autorisation ;
• reprend le nom d’une app existante ;
• affiche des contenus (vidéos, articles, photos) sans en détenir les droits.

En cas de doute, Apple peut vous demander de fournir une preuve écrite de l’autorisation du titulaire des droits.

Comment éviter le refus de votre application par Apple ?

En préparant la review comme une étape du projet, avec son planning et sa checklist, et pas comme une simple formalité.

Lire et appliquer les App Store Review Guidelines

Les App Store Review Guidelines sont publiques et disponibles en français. Pas besoin de tout connaître par cœur, mais trois réflexes aident :

• au cadrage, vérifier les règles qui touchent au modèle économique (paiements) et aux données personnelles ;
• pendant la conception, valider les parcours sensibles : création de compte, suppression de compte, achat ;
• avant chaque soumission, relire les changements publiés par Apple depuis la dernière version.

Tester rigoureusement avant soumission

La plupart des refus pour bug auraient été évités par une recette sérieuse.

Avant de soumettre, nous faisons des tests fonctionnels sur de vrais appareils, pas seulement sur simulateur :

• un iPhone récent et un iPhone plus ancien ;
• un iPad, si l’app y est disponible ;
• la dernière version d’iOS et la précédente ;
• une connexion lente et le mode avion ;
• une installation neuve, sans données en cache.

La distribution en bêta via TestFlight permet aussi de faire tester l’app par le client et quelques utilisateurs dans les mêmes conditions que la version publiée.

Pour une app existante qui accumule les refus, un audit technique de votre application permet de repérer les causes de fond : librairies obsolètes, API dépréciées, failles de sécurité.

Préparer une documentation complète

Dans App Store Connect, la rubrique « Informations pour la review » est votre seul moyen de parler au reviewer avant qu’il teste l’app. Utilisez-la pour fournir :

• un compte de démonstration avec des données réalistes (et pas un compte vide) ;
• les étapes pour accéder aux fonctionnalités cachées derrière un rôle ou un abonnement ;
• une explication des fonctionnalités qui ne sont pas visibles tout de suite (appareil connecté, zone géographique, code d’invitation) ;
• une courte vidéo si une fonctionnalité dépend d’un objet physique ou d’un lieu.

Anticiper les questions de l’équipe de review

Mettez-vous à la place du reviewer : il découvre l’app sans contexte, en quelques minutes.

Posez-vous les questions qu’il se posera :

• Pourquoi cette app demande-t-elle l’accès à ma position ?
• Où est le paiement et qu’est-ce qu’on achète ?
• Puis-je utiliser l’app sans créer de compte ?
• À quoi sert cette app de plus que le site web ?

Si la réponse n’est pas évidente dans l’app, écrivez-la dans les notes de review.

Que faire si votre application est refusée par Apple ?

Garder son calme, lire précisément le motif et choisir entre corriger, expliquer ou faire appel.

Dans la grande majorité des cas, une application refusée par Apple se débloque avec une simple correction.

Analyser le motif de refus communiqué par Apple

Quand votre application est refusée par Apple, le message de refus arrive dans App Store Connect. Il indique :

• le numéro de la règle concernée (par exemple 2.1 ou 5.1.1(v)) ;
• une explication, parfois accompagnée de captures d’écran ;
• souvent, une piste de correction.

Lisez la règle complète dans les guidelines, pas seulement le résumé. Et vérifiez si le refus porte sur l’app elle-même ou seulement sur sa fiche (métadonnées). Dans ce second cas, la correction peut se faire sans nouveau build.

Corriger les points bloquants identifiés

Classez les corrections en deux catégories :

• les corrections rapides : un lien à ajouter, une capture à remplacer, un compte de test à fournir ;
• les corrections de fond : un parcours à revoir (accès sans compte, suppression de compte), un modèle de paiement à changer.

Pour les secondes, prenez le temps d’en parler avec votre client ou votre équipe. Une correction faite à la hâte pour « passer » la review peut provoquer un nouveau refus, ou dégrader l’expérience utilisateur.

Faire appel de la décision si nécessaire

Si vous pensez que le reviewer a mal compris l’app, vous pouvez :

• répondre directement au message dans App Store Connect pour apporter des précisions ;
• faire appel auprès de l’App Review Board, l’instance d’Apple qui réexamine les décisions contestées.

L’appel est utile quand le refus repose sur un malentendu (fonctionnalité non trouvée, contexte métier mal compris). Il l’est beaucoup moins quand la règle est claire : mieux vaut alors corriger.

Re-soumettre l’application avec les modifications

Une fois les corrections faites :

1. incrémentez le numéro de build ;
2. mettez à jour les notes de review en expliquant ce qui a changé et où le voir ;
3. répondez au message de refus pour signaler la nouvelle version ;
4. re-soumettez.

Les bonnes pratiques pour une validation rapide

Respecter les délais de review Apple

Apple indique qu’en moyenne, quatre-vingt-dix pour cent des soumissions sont examinées en moins de 24 heures. Dans la pratique, prévoyez :

• vingt-quatre à quarante-huit heures pour une première review ;
• une semaine de marge avant toute date de lancement, pour absorber un refus et une seconde soumission ;
• plus de marge en fin d’année : les délais peuvent s’allonger autour des fêtes.

En cas d’urgence réelle (bug critique en production), vous pouvez demander une review accélérée. Apple l’accorde au cas par cas : ce n’est pas un outil de planning.

Maintenir une communication claire avec l’équipe de review

Les échanges avec Apple se font par écrit, dans App Store Connect. Quelques règles simples :

• répondre en anglais, de façon courte et factuelle ;
• citer le numéro de la règle et décrire précisément la correction ;
• joindre une capture ou une vidéo si cela aide ;
• rester courtois, même si le refus semble injuste.

Apple propose aussi des sessions d’échange avec l’équipe de review pour poser des questions générales sur les guidelines.

Documenter les fonctionnalités sensibles

Certaines fonctionnalités attirent toujours l’attention du reviewer : santé, finance, contenus pour enfants, géolocalisation en arrière-plan, IA générative.

Pour chacune, préparez à l’avance :

• une explication de l’usage des données et de leur protection ;
• les autorisations ou agréments éventuels (par exemple pour un service financier) ;
• l’écran de consentement si des données partent vers une IA tierce.

 S’entourer d’experts du développement iOS

Une équipe qui publie régulièrement sur l’App Store connaît les pièges, suit les changements de règles et sait formuler une réponse à Apple. C’est souvent ce qui fait la différence entre une validation en deux jours et une application refusée par Apple pendant un mois d’allers-retours.

Chez TheCodingMachine, nous sommes une agence de développement d’application mobile. Nous prenons en charge la publication sur l’App Store et le Play Store, de la préparation de la fiche jusqu’à la gestion des refus.

Questions fréquentes sur les refus d’applications Apple

Publié le 15 octobre 2026

---