Publier son app sur l'App Store : les 7 raisons de refus d'Apple (et comment les éviter avant de soumettre)

Le refus arrive toujours au pire moment. Vous avez investi 9 500€ ou 80 000€ dans le dev. 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 que ce que les fondateurs imaginent. Selon les données publiques d'Apple, environ 30 à 40% des apps soumises pour la première fois sont refusées au moins une fois. Sur le Play Store, le taux est plus bas, mais les motifs de retrait après publication sont eux plus nombreux. Le vrai problème : pour la majorité des fondateurs, c'est leur première soumission, et ils découvrent les règles en se prenant le mur.

Bonne nouvelle : 90% 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 dev mobile expérimenté les anticipe au moment du dev, pas au moment de la soumission. Voici les 7 motifs qui sortent le plus, comment les éviter, et la checklist complète pré-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 plante en quelques minutes si quelque chose est mal foutu.
• Étape 2 : queue de review qui dure entre 24 et 48h en moyenne. Pas de news 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. Cette étape dure 30 minutes à 2 heures selon la complexité.
• É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, le process est plus rapide (souvent 4 à 24h sur les apps neuves, parfois quelques heures pour les updates) mais s'appuie davantage sur des contrôles automatiques. Un refus Google est souvent moins explicite mais arrive aussi vite. Et Google retire des apps déjà publiées plus facilement qu'Apple, sur signalements ou changements de règles. On en parle plus bas.

Les 7 motifs de refus les plus fréquents

Ces sept motifs représentent à eux seuls plus de 80% des refus que je vois sur les projets que j'audite. 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 first value moment. 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 test l'app, il 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, refus garanti 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.5 : 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 vous utilisez Firebase Analytics, Facebook SDK, AppsFlyer, Adjust ou tout SDK marketing : 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. Vous ne pouvez pas mettre un bouton « s'abonner sur notre site » qui contourne les 15-30% de commission Apple.

Comment l'éviter : si votre app vend du contenu numérique consommé dans l'app, vous DEVEZ utiliser StoreKit / In-App Purchase. Pas de Stripe direct, pas de PayPal direct. 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 dev 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 pré-soumission iOS (15 points)

Voici la checklist exacte que je passe sur chaque app avant de cliquer sur Submit for Review. Si un seul point est manquant, je ne soumets pas. Cette discipline a des résultats mesurables : zéro refus sur les apps que j'ai livrées jusqu'à aujourd'hui.

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

• Captures d'écran aux bons formats (iPhone 6.7", 6.5", 5.5" + iPad si applicable)
• 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 tracking marketing : prompt ATT implémenté et déclenché au bon moment
• Si login : Sign in with Apple proposé en parallèle des autres options de connexion (obligatoire si vous proposez Google ou Facebook login)

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 prend 30 à 60 minutes à parcourir. Comparez-la au coût d'un refus : 24-48h d'attente perdues, le moral plombé du fondateur, le retard sur le plan de communication. Le ratio bénéfice/effort est imbattable.

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

Refus n'est pas définitif. La majorité des apps refusées sont validées au 2e ou 3e essai, à 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. Le reviewer répond en 24-48h, vous économisez 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 un 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 claire et honnête repasse en review avec une priorité légèrement améliorée. 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 APK sur une dizaine de devices virtuels et détecte crashes, performances dégradées et problèmes d'accessibilité. Si le rapport sort rouge, Google peut suspendre la publication ou la retarder. Vérifier le Pre-launch Report dans Play Console après chaque upload AAB est une bonne discipline.

Data Safety

L'équivalent du App Privacy d'Apple, mais plus exigeant. Toutes les données collectées doivent être déclarées avec leur finalité, leur durée de conservation, et si elles sont chiffrées en transit. Une déclaration incohérente avec ce que votre app fait réellement (Google le détecte automatiquement via le SDK Firebase ou autres) entraîne 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, Google relève le target API level minimum (par exemple, en 2025, target SDK 34 minimum). Si votre app cible une API trop ancienne, Google la rejette ou bloque les updates. Maintenir l'app à jour côté SDK fait partie de la maintenance post-lancement que personne ne facture mais qui est indispensable.

Comment je gère ça sur les projets ZUHD

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.
• Au milieu du dev, 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.
• Une semaine avant la soumission, on passe la checklist 15 points ensemble. Les corrections nécessaires sont faites avant de soumettre, jamais après refus.
• 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.

Résultat : sur les 3 apps livrées à ce jour, zéro refus de première soumission. Ce n'est pas magique, c'est juste de la discipline appliquée à un process documenté. C'est aussi inclus dans le forfait MVP Momentum à 9 500€, parce qu'une app pas publiée n'est pas une app livrée.

Si vous approchez de la soumission ou si vous venez d'être refusé et que vous ne savez pas comment rebondir, on peut regarder votre cas en 30 minutes. Souvent, le motif est simple à corriger une fois qu'on l'a identifié précisément.