Pourquoi Google Play rejette des apps

L'application des règles sur Google Play est de plus en plus automatisée. La plupart des rejets et suspensions proviennent d'une courte liste de problèmes techniques et de politique que vous pouvez vérifier avant d'importer.

1. Target API level trop bas

Google Play exige que les nouvelles apps et les mises à jour ciblent un Android API level récent (actuellement API 35 / Android 15). Si votre targetSdkVersion est sous le seuil, la Play Console bloque purement et simplement l'upload. Relevez la target, puis re-testez les changements de comportement.

2. Build release debuggable

Publier un build avec android:debuggable="true" est rejeté. Assurez-vous que votre type de build release n'active pas le débogage.

3. Autorisations sensibles et restreintes

Les autorisations comme la localisation en arrière-plan, les SMS / journal d'appels et l'accès à tous les fichiers (MANAGE_EXTERNAL_STORAGE) exigent un cas d'usage solide et souvent un Permissions Declaration Form. Les demander sans justification est un motif de retrait majeur.

  • Ne demandez que les autorisations dont vos fonctionnalités actuelles ont besoin.
  • Ajoutez une divulgation contextuelle bien visible avant de les demander.
  • Remplissez le formulaire de déclaration là où il est requis.

4. Incohérence du formulaire Data safety

Votre section Data safety dans la Play Console doit correspondre à ce que l'app et ses SDK collectent et partagent réellement. Les écarts — souvent introduits par un SDK d'analytics ou de pub — déclenchent rejets et suspensions. Auditez chaque dépendance.

5. Broken Functionality contre Limited Functionality

Ce sont deux sections distinctes de la même page de règles, et tout le monde les confond. Broken Functionality vise les apps qui plantent, gèlent ou ne se chargent jamais : votre app a échoué. Limited Functionality and Content vise les coquilles vides et les wrappers webview : votre app fonctionne, elle ne vaut simplement pas l'installation. Les correctifs sont opposés. Si votre rejet dit Broken Functionality, n'ajoutez surtout pas de fonctionnalités.

Guide complet : décoder un rejet Broken Functionality →

6. Comportement trompeur et usurpation

  • Faux avertissements système ou imitation de l'UI Android.
  • Fiche store trompeuse, bourrage de mots-clés ou faux badges.
  • Copie du nom, de l'icône ou de la marque d'une autre app.

7. Paiements et suppression de compte

Les biens numériques doivent généralement utiliser Google Play Billing. Et si les utilisateurs peuvent créer un compte, vous devez proposer la suppression du compte et des données à la fois dans l'app et via une URL accessible en externe.

Comment App Review Checker vous aide

Importez votre .apk et nous lisons le manifest pour vérifier votre target API level, le flag debuggable, le trafic en clair, les autorisations restreintes, le versioning et le format de publication — puis nous vous guidons sur les points de politique (Data safety, facturation, fiche store, suppression de compte) qui demandent une réponse humaine.

Checklist de soumission Android : tout le parcours Play Store →

Vérifiez votre build avant de soumettre

Passez votre .ipa ou .apk dans App Review Checker et détectez ces problèmes en quelques secondes.

Analyser une app