Refus de l'App Store : les 7 motifs à éviter avant de publier votre application

Apple refuse surtout les applications sans valeur ajoutée, incomplètes ou qui plantent, opaques sur les données collectées, ou qui contournent ses achats intégrés. Ces refus sont presque toujours prévisibles, car les règles sont publiques. L'article détaille les 7 motifs les plus fréquents, une checklist de 16 points avant soumission et la marche à suivre si le refus arrive quand même.

Le refus arrive toujours au pire moment. Vous avez investi dans le développement. Le lancement est prévu vendredi, vous avez prévenu vos premiers utilisateurs, votre stratégie de communication est en marche. Lundi matin, Apple répond dans le Resolution Center : « Your app cannot be approved ». Et là, c'est la douche froide.

Ce scénario arrive plus souvent qu'on ne l'imagine. Dans son rapport de transparence 2025, Apple indique avoir examiné 9 100 620 soumissions d'applications et en avoir refusé 2 093 244. Ces chiffres comptent des soumissions, pas des applications : une même app peut être soumise plusieurs fois. Le vrai problème : pour la plupart des gens qui lancent une application, c'est leur première soumission, et ils découvrent les règles en se prenant le mur.

Bonne nouvelle : la plupart des refus sont prévisibles et évitables. Les motifs qui tombent sont presque toujours les mêmes, ils sont publiquement documentés dans les App Store Review Guidelines, et un développeur mobile expérimenté les anticipe pendant le développement, pas au moment de la soumission. Voici les 7 motifs qui sortent le plus, comment les éviter, et la checklist complète avant soumission.

Pourquoi Apple refuse autant d'apps (et c'est plutôt une bonne chose)

Apple ne refuse pas par mauvaise volonté. La revue manuelle de chaque app par un humain (en plus des contrôles automatiques) existe parce que la confiance dans l'App Store fait partie du produit Apple. Si l'App Store devenait une jungle d'apps spammy, mal codées ou douteuses, les utilisateurs cesseraient d'y acheter. Apple a un intérêt économique direct à filtrer.

Concrètement, voici comment se déroule la review d'une soumission iOS :

• Étape 1 : contrôles automatiques à la soumission (signing, format, taille, métadonnées présentes). Ça bloque en quelques minutes si quelque chose est mal configuré.
• Étape 2 : file d'attente avant l'examen. Pas de nouvelles pendant ce temps, c'est normal.
• Étape 3 : revue humaine. Un reviewer Apple télécharge votre build, le teste sur un iPhone, regarde votre fiche store, vérifie vos URLs légales, parfois compare avec d'autres apps.
• Étape 4 : décision. Approuvé, refusé avec explication dans le Resolution Center, ou parfois « metadata rejected » (juste un détail à corriger, sans nouveau build).

Côté Google Play, l'examen s'appuie davantage sur des contrôles automatiques. Un refus Google est souvent moins explicite. Et Google peut retirer une app déjà publiée, sur signalement ou après un changement de règles. On en parle plus bas.

Les 7 motifs de refus les plus fréquents

Ces sept motifs reviennent le plus souvent dans les retours publics des développeurs iOS et dans la documentation Apple. Chacun a un numéro de règle dans les guidelines Apple. Connaître la règle, c'est connaître ce que le reviewer va vérifier.

1. Guideline 4.3 : Spam et apps sans valeur ajoutée

Ce que ça vise : les apps qui ressemblent à plein d'autres, qui répliquent une fonctionnalité ultra-simple (calculatrice, lampe torche, météo basique), ou qui n'apportent qu'un wrapper d'un site web sans intégration mobile. Apple veut éviter la pollution du store.

Comment l'éviter : votre app doit faire au moins une chose qu'un site web mobile ne pourrait pas faire (notifications, capteurs, mode hors-ligne, intégration native), ou la faire d'une façon qualitativement supérieure. Si votre app est juste un site avec un logo Apple par-dessus, vous serez refusé. Une fonctionnalité native bien intégrée (Face ID, partage iOS, widget, Live Activity) règle souvent le problème.

2. Guideline 5.1.1 : Privacy et collecte de données

Ce que ça vise : toute collecte de données personnelles sans transparence. Demande de connexion email avant la moindre valeur, accès au carnet d'adresses sans contexte, tracking publicitaire sans permission.

Comment l'éviter : remplir scrupuleusement la section App Privacy dans App Store Connect (déclarer toutes les données collectées et leur usage). Justifier chaque permission demandée par une NSUsageDescription claire et précise, en français si l'app est en français. Et surtout, repousser les demandes de données après le premier moment de valeur. Pour creuser ce sujet, voir l'article sur les 60 premières secondes.

3. Guideline 2.1 : App incomplète, crash, bugs visibles

Ce que ça vise : apps qui crashent au lancement, qui plantent sur une fonctionnalité de base, qui ont des écrans vides, des liens cassés, ou des fonctionnalités annoncées mais non implémentées. Le reviewer teste l'app, il le voit immédiatement.

Comment l'éviter : tester sur 2 iPhones différents (un récent, un d'il y a 3 ans), parcourir tous les écrans manuellement, vérifier qu'aucun bouton ne renvoie sur un écran vide. Si votre app a un login, fournir des identifiants de démo dans les notes du reviewer (champ App Review Information). Sans ça, le refus est presque assuré, car il ne peut pas tester.

4. Guideline 4.0 : Design et UI non native

Ce que ça vise : apps qui ressemblent à des sites web, qui n'utilisent pas les composants iOS natifs, qui ont des interactions étranges, ou qui ne respectent pas les Human Interface Guidelines. Le reviewer remarque immédiatement une UI qui sent le React Native mal calibré ou le Flutter avec des Material widgets en mode iOS.

Comment l'éviter : utiliser des composants natifs ou des packages Flutter qui rendent du cupertino style sur iOS. Tester la navigation : sur iOS, on swipe pour revenir en arrière, on a des barres de navigation en bas avec icônes claires, des animations de transition naturelles. Ce n'est pas du superficiel, c'est ce qui fait la différence entre une app validée et une app refusée.

5. Guideline 5.1.2 : Tracking sans permission ATT

Ce que ça vise : depuis iOS 14.5, toute app qui veut suivre l'utilisateur entre apps ou sites doit afficher le prompt App Tracking Transparency et obtenir le consentement explicite. Ne pas l'afficher quand vous trackez, c'est un refus immédiat.

Comment l'éviter : si votre app suit l'utilisateur entre applications ou sites d'autres entreprises (SDK publicitaires, attribution) : intégrer le prompt ATT, le déclencher au bon moment (pas juste avant la première valeur), et ne pas insister par notification ou pop-up custom « merci de cliquer Allow » (c'est interdit aussi).

6. Guideline 3.1.1 : Achats hors In-App Purchase pour du contenu numérique

Ce que ça vise : vendre des fonctionnalités, du contenu, des abonnements ou des crédits dans l'app sans passer par le système Apple. Hors exceptions prévues dans certains pays, vous ne pouvez pas mettre un bouton « s'abonner sur notre site » qui contourne la commission d'Apple.

Comment l'éviter : si votre app vend du contenu numérique consommé dans l'app, vous devez en règle générale passer par l'achat intégré d'Apple (StoreKit, In-App Purchase) ; des exceptions existent selon les pays, à vérifier avec votre développeur avant de coder. Autre exception : les apps qui vendent du physique (e-commerce) ou des services consommés hors app (Uber, Airbnb) peuvent utiliser des paiements externes. Si vous êtes dans la zone grise, demandez confirmation à un développeur mobile expérimenté avant de coder.

7. Guideline 1.1 et 1.2 : Contenu offensant ou inapproprié

Ce que ça vise : contenu généré par utilisateur sans modération, mention dégradante, deepfakes, contenu violent gratuit, exploitation de catastrophes récentes, etc.

Comment l'éviter : si votre app permet le UGC (publication par les utilisateurs), vous devez avoir : (1) un système de signalement intégré, (2) la possibilité de bloquer un utilisateur, (3) des conditions d'utilisation accessibles, (4) une équipe ou un process de modération. Pas de système de modération = refus, peu importe la qualité du reste.

La checklist avant soumission iOS (16 points)

Voici la checklist exacte que j'applique sur chaque app avant de cliquer sur Submit for Review. Si un seul point est manquant, je ne soumets pas : c'est la meilleure façon d'éviter un refus évitable.

Build et tests

• L'app a été testée sur au moins 2 modèles d'iPhone (récent + 3 ans) sans crash
• Tous les écrans sont accessibles depuis l'arborescence, aucun n'est mort
• Le mode hors-ligne ne fait pas crasher l'app (au minimum un message clair)
• Le build est uploadé sur TestFlight et testé en interne avant la soumission App Store

Métadonnées App Store Connect

• Le compte Apple Developer est ouvert au nom de votre entreprise, pas de votre prestataire
• Captures d'écran aux formats exigés par App Store Connect au moment de la soumission (page « Screenshot specifications » d'Apple), iPad compris si l'app tourne sur iPad
• Description claire, sans mention "App Store", "Apple", concurrent direct, ni promesse non tenue
• Mots-clés pertinents (100 caractères max), pas de noms de marques que vous ne possédez pas
• URL d'assistance et URL marketing fonctionnelles (testées en navigation privée)
• URL politique de confidentialité fonctionnelle et conforme RGPD

Privacy et permissions

• Section App Privacy remplie : tous les types de données collectées sont déclarés
• Toutes les permissions iOS ont une description claire (NSUsageDescription) en français
• Si l'app suit l'utilisateur entre applications ou sites d'autres entreprises : prompt ATT implémenté et déclenché au bon moment
• Si connexion avec Google ou Facebook : une option de connexion équivalente qui protège la vie privée est proposée, par exemple Sign in with Apple (règle 4.8)

Informations pour le reviewer

• Compte de démo fourni si l'app a un login (identifiants dans App Review Information)
• Note de contexte si une fonctionnalité particulière nécessite une explication

Cette checklist se parcourt vite. Comparez-la au coût d'un refus : des jours d'attente perdus, le moral plombé, le retard sur le plan de communication. Le calcul est vite fait. Et tant qu'on parle de la fiche store, autant la rendre vraiment performante : voir la méthode ASO complète pour faire trouver votre app par les bonnes personnes dès la publication.

Le guide gratuit applique la même logique bien avant la soumission : ses 8 étapes se terminent par un plan d'action à cocher, avec par exemple « Mes comptes Apple et Google sont ouverts à mon nom ».

Si vous êtes refusé : la procédure pour rebondir vite

Un refus n'est pas définitif. Beaucoup d'apps refusées sont validées à l'essai suivant, à condition de bien réagir. Voici le bon réflexe.

Étape 1 : lire attentivement le motif

Le Resolution Center vous donne le numéro de la guideline violée et un commentaire du reviewer. Lisez les deux, plusieurs fois. Le commentaire est souvent court mais précis. Allez ensuite lire la guideline complète sur le site Apple. La cause exacte du refus est presque toujours dans ces deux sources combinées.

Étape 2 : répondre dans le Resolution Center, pas re-soumettre

L'erreur la plus coûteuse : corriger ce que vous croyez être le problème, recompiler, re-soumettre. Vous risquez d'être refusé à nouveau pour la même raison parce que vous n'aviez pas compris le motif réel. Avant de re-soumettre, répondez d'abord au reviewer dans le Resolution Center : posez une question si vous ne comprenez pas, demandez confirmation que votre interprétation est la bonne. Vous pouvez économiser un cycle entier.

Étape 3 : argumenter si le refus est ambigu

Certains refus sont des erreurs ou des malentendus. Si vous pensez que c'est le cas, expliquez-le clairement dans le Resolution Center, avec captures d'écran à l'appui si nécessaire. Apple revient parfois sur sa décision quand le contexte est explicité. Cela arrive notamment sur la guideline 4.3 (spam) : si vous démontrez la valeur ajoutée unique de votre app, le refus peut être levé.

Étape 4 : demander une App Review Board en cas de blocage

Si après deux ou trois échanges vous n'avancez plus, vous pouvez demander un appel à l'App Review Board. C'est une escalade officielle. À utiliser avec parcimonie (on ne demande pas de board pour chaque refus), mais c'est utile quand vous avez un cas particulier que le premier reviewer ne saisit pas.

Étape 5 : re-soumettre avec un changelog clair

Une fois la correction faite, dans la nouvelle soumission, indiquez explicitement dans App Review Information ce que vous avez corrigé par rapport à la précédente. Le reviewer va d'abord vérifier ces points. Une re-soumission avec le même build sans explication est presque sûre de tomber sur le même refus.

Le cas du Play Store : les pièges spécifiques Google

Google Play est plus rapide à valider mais a ses propres règles, parfois piégeuses. Trois points sortent souvent.

Le Pre-launch Report

Avant publication, Google fait tourner automatiquement votre application sur plusieurs appareils de test et signale plantages, lenteurs et problèmes d'accessibilité. Ce que le rapport trouve, vos utilisateurs le trouveront aussi. Le vérifier dans la Play Console après chaque envoi est une bonne habitude.

Data Safety

L'équivalent du App Privacy d'Apple. Toutes les données collectées ou partagées doivent être déclarées avec leur finalité, en précisant si elles sont chiffrées pendant le transfert et si l'utilisateur peut demander leur suppression. Une déclaration incohérente avec ce que votre app fait réellement peut entraîner un refus ou une suspension. Mettez du temps sur cet écran, ne le bâclez pas.

App Bundle obligatoire et target API à jour

Depuis 2021, le format AAB (Android App Bundle) est obligatoire pour les nouvelles apps. Et chaque année, en général fin août, Google relève le niveau d'API minimum exigé pour publier une nouvelle application ou une mise à jour. Si votre app cible un niveau trop ancien, Google bloque ses mises à jour. La tenir à jour fait partie de la maintenance après le lancement.

Comment je prépare la soumission sur les projets Zuhd Studio

La soumission stores n'est pas un événement de fin de projet. C'est un livrable préparé dès le cadrage. Concrètement, voici ce que ça change :

• Au cadrage, on identifie les fonctionnalités qui touchent les guidelines sensibles (login, paiement, UGC, tracking) et on les conçoit pour passer la review du premier coup.
• Pendant le développement, je remplis déjà la fiche App Store Connect en parallèle (textes, captures partielles, déclarations privacy). Ce n'est pas un travail de la dernière semaine.
• Pendant la semaine de tests qui précède la mise en ligne (tests fonctionnels, relecture du code, tests d'intrusion), je passe aussi cette checklist. Ce qui doit être corrigé l'est avant la soumission.
• La soumission est faite avec compte démo, notes au reviewer, changelog explicite. Le projet est prêt à être testé sans friction par le reviewer.

C'est inclus dans MVP Momentum à 9 500 €, parce qu'une application qui n'est pas publiée n'est pas une application livrée. Et si Apple ou Google refusent pour un motif technique, je corrige et je soumets à nouveau, sans frais.

Si votre application est encore une idée, c'est le bon moment pour prévoir ces règles : au cadrage, pas la veille de la soumission.