App Store et Google Play : les 9 motifs de refus qu’on voit le plus

La partie la plus frustrante d’un projet mobile n’est pas le développement : c’est la semaine où l’application est terminée mais pas publiée. Un refus coûte trois à sept jours, et il tombe presque toujours pendant la semaine où la communication est déjà lancée.

Voici les neuf motifs que nous rencontrons le plus, et comment les éliminer avant de soumettre.

1. Confidentialité et déclaration de collecte de données

C’est devenu la première cause de rejet sur les deux plateformes. Les magasins vérifient la cohérence entre ce que vous déclarez collecter, ce que votre application collecte réellement — bibliothèques tierces comprises — et ce qu’annonce votre politique de confidentialité.

Ce qui est vérifié : la fiche de confidentialité de la fiche produit, l’existence d’une politique de confidentialité accessible publiquement, et la présence d’un moyen de supprimer son compte depuis l’application quand celle-ci permet d’en créer un.

Le piège : un outil d’analyse ou une régie publicitaire intégré par un développeur collecte des identifiants que personne n’a pensé à déclarer. Le sujet croise directement la conformité RGPD.

2. Absence de compte de test fonctionnel

Le réviseur doit pouvoir utiliser toute l’application. S’il tombe sur un écran de connexion sans identifiants, il refuse — c’est automatique et parfaitement évitable.

Fournissez un compte de démonstration avec des données réalistes, valable au moins un mois, et si l’application nécessite un code à usage unique, expliquez comment le contourner ou fournissez un numéro de test.

3. Fonctionnalité incomplète ou contenu de remplissage

Écran vide, bouton inactif, fonctionnalité « bientôt disponible », texte de remplissage oublié, lien qui ne mène nulle part. Une application en cours de finition est refusée, même si la partie principale fonctionne.

4. Paiement contournant le système de la plateforme

Sur iOS, tout achat de contenu ou de service consommé dans l’application doit passer par le paiement intégré. Rediriger l’utilisateur vers un paiement web pour un abonnement numérique est un motif de refus classique — et les exceptions sont plus étroites que ce que la plupart des équipes croient.

Les biens et services physiques, eux, se paient normalement par un moyen externe. La frontière est parfois subtile : à valider en amont, pas la veille du lancement.

5. Permissions demandées sans justification

Une application qui demande l’accès aux contacts, à la position en arrière-plan ou au micro sans que l’usage soit évident est refusée. Chaque permission doit avoir un texte d’explication clair, en français, et être demandée au moment où l’utilisateur en comprend l’utilité — pas au premier lancement, en rafale.

6. Fiche produit non conforme

Captures d’écran qui ne correspondent plus à l’application, mention d’une plateforme concurrente, promesse de fonctionnalité absente, mots-clés bourrés dans le titre, icône trompeuse. La fiche est examinée aussi sérieusement que l’application.

7. Connexion sociale sans alternative

Sur iOS, si vous proposez une connexion via un service tiers, vous devez proposer une option de connexion respectueuse de la vie privée. C’est un motif de refus fréquent et facile à corriger, mais qui impose du développement — donc à anticiper.

8. Plantages et anomalies sur des appareils réels

Le test est effectué sur du matériel physique, parfois d’une génération plus ancienne que celle de vos développeurs, dans des conditions réseau dégradées. Les causes les plus fréquentes : plantage au premier lancement sans connexion, écran figé après le retour depuis l’arrière-plan, interface illisible sur petit écran ou avec les grandes tailles de police.

9. Contenu généré par les utilisateurs sans modération

Si votre application permet de publier du contenu, elle doit proposer un moyen de signaler un contenu inapproprié, de bloquer un utilisateur, et des conditions d’utilisation. L’absence de ces trois éléments est un refus certain.

La checklist de pré-soumission

À passer en revue la veille, en une heure.

• [ ] Compte de test valide, avec données réalistes, communiqué dans les notes de révision
• [ ] Politique de confidentialité en ligne, à jour, accessible sans compte
• [ ] Déclaration de collecte de données cohérente avec les bibliothèques réellement embarquées
• [ ] Suppression de compte possible depuis l’application, si création de compte il y a
• [ ] Aucune mention « bientôt disponible », aucun écran vide, aucun texte de remplissage
• [ ] Textes de justification présents pour chaque permission, en français
• [ ] Captures d’écran conformes à la version soumise
• [ ] Test complet sur un appareil ancien, en mode avion, puis reconnexion
• [ ] Signalement et blocage disponibles si du contenu utilisateur est publié
• [ ] Notes de révision expliquant les fonctionnalités non évidentes

Un refus n’est pas un jugement sur la qualité de votre produit. C’est un contrôle de conformité. Il se prépare comme un contrôle de conformité : avec une liste, pas avec de l’espoir.

Que faire en cas de refus

Lisez le motif exact et la règle citée : la formulation est standardisée, la règle est numérotée, et elle décrit précisément ce qui pose problème.

Corrigez uniquement ce point, puis répondez dans la messagerie de révision en expliquant ce qui a été modifié et où le vérifier. Une resoumission silencieuse repart en bas de la file ; une réponse argumentée est souvent traitée en quelques heures.

Si le refus vous paraît reposer sur un malentendu — c’est fréquent quand une fonctionnalité métier est mal comprise — la procédure d’appel existe et fonctionne, à condition de rester factuel et de citer la règle concernée.