Refus Google Play : les motifs et comment y répondre (2026)

Un refus Google Play signifie que votre nouvelle application ou votre mise à jour n'a pas passé l'examen et ne sera pas publiée tant que le problème de règlement cité par Google n'est pas corrigé. C'est le plus souvent réparable : Google précise qu'un refus n'a aucun impact sur l'état de votre compte de développeur et que, s'il s'agit d'une mise à jour, la version déjà publiée reste disponible. Première étape : ouvrir l'e-mail de Google Play et la page État de conformité avec les règles (Policy status) de la Play Console, puis repérer la règle citée et le statut exact.

En 2025, Google a empêché la publication de plus de 1,75 million d'applications enfreignant ses règles et banni plus de 80 000 comptes de développeur, selon son rapport de sécurité de février 2026. Ce guide couvre ce que veut dire chaque statut, les huit problèmes de règlement derrière la plupart des refus, les trois réponses possibles et une checklist avant le prochain examen.

Vous êtes plus tôt dans le parcours ? Notre guide pour publier une app sur Google Play couvre le chemin du compte de développeur à la production.

Ce que veut dire l'e-mail : refusée, supprimée ou suspendue

Google examine les applications par une évaluation à la fois automatique et humaine, avant et après la publication. En cas d'infraction, il envoie un e-mail au compte de développeur avec la mesure prise et la marche à suivre pour faire appel, et la page État de conformité avec les règles de l'application affiche la mesure en cours.

Les huit problèmes de règlement derrière la plupart des refus

Le Developer Policy Center recense des dizaines de règles, mais une première soumission bute en général sur les mêmes ; le rapport 2025 de Google cite les identifiants, les autorisations et les liens cassés vers la politique de confidentialité parmi les motifs de refus courants. Voici les huit à vérifier en premier.

Un formulaire Sécurité des données qui contredit l'app

• Ce que Google vérifie. Selon la règle Données utilisateur, la section Sécurité des données (Data safety) doit couvrir tout ce que l'application collecte et partage, SDK tiers compris ; « collecter » désigne toute donnée transmise hors de l'appareil. Les applications dont la déclaration contredit le comportement s'exposent au blocage des mises à jour ou à la suppression.
• La correction. Listez chaque SDK du build (statistiques, rapports de crash, publicité, connexion), lisez les indications Data safety de chaque fournisseur et corrigez le formulaire dans Contenu de l'application.

Une politique de confidentialité absente ou inaccessible

• Ce que Google vérifie. Toute application doit avoir un lien vers sa politique de confidentialité dans la Play Console et dans l'app, même si elle ne collecte aucune donnée, sur une URL active, publique, sans restriction géographique et qui n'est pas un PDF. Les applications qui permettent de créer un compte doivent aussi proposer sa suppression, dans l'app et par un lien web.
• La correction. Publiez la politique sur une page web classique, liez-la depuis l'écran des réglages ou d'inscription, et saisissez l'URL de suppression de compte dans la Play Console.

Des autorisations que l'app ne peut pas justifier

• Ce que Google vérifie. La règle Autorisations et API ayant accès aux informations sensibles n'admet que ce qu'exigent les fonctionnalités actuelles présentées dans la fiche. Les autorisations SMS et journal d'appels sont réservées aux applications par défaut, la localisation en arrière-plan peut être refusée sans justification solide, et l'accès à tous les fichiers passe par un examen dédié.
• La correction. Retirez toute autorisation qu'aucune fonctionnalité n'utilise, y compris celles ajoutées par des bibliothèques, et remplissez le formulaire de déclaration d'autorisations quand il est demandé.

Des identifiants qui ne laissent pas entrer l'examinateur

• Ce que Google vérifie. Si une partie de l'application se trouve derrière une connexion, une localisation ou un paywall, la Play Console exige un accès dans la section Accès aux applications (Sign-in details) de Contenu de l'application : réutilisable, valable à tout moment et depuis n'importe quel pays, en anglais, et capable de contourner la validation en deux étapes. Si le mot de passe expire, l'application peut être refusée.
• La correction. Créez un compte de démonstration permanent avec des données réalistes et ajoutez les instructions.

Une app qui plante ou qui fait trop peu

• Ce que Google vérifie. La règle Fonctionnalités, contenu et expérience utilisateur interdit les applications qui plantent, se figent, ne s'installent pas ou ne se chargent pas, et celles aux fonctionnalités limitées, comme les applications statiques de texte ou de PDF.
• La correction. Installez le bundle exact depuis un canal de test sur un appareil vierge, avec un nouveau compte, et corrigez ce qui casse. Si l'app est trop mince, ajoutez de vraies fonctionnalités.

Une app WebView, d'affiliation ou copiée

• Ce que Google vérifie. La règle Spam interdit les applications dont l'objectif principal est d'afficher un site dans une WebView sans l'autorisation de son propriétaire ou de générer du trafic d'affiliation, et celles qui se contentent de reproduire l'expérience d'autres applications, y compris des applications quasi identiques d'un même développeur.
• La correction. N'enrobez qu'un site que vous possédez ou administrez, donnez à l'app des fonctionnalités propres, et fusionnez les applications quasi identiques en une seule.

Une fiche trompeuse ou une marque empruntée

• Ce que Google vérifie. La règle Métadonnées limite le titre à 30 caractères et interdit les emojis, les MAJUSCULES hors nom de marque, les mentions comme « #1 » et les témoignages anonymes. Les règles Usurpation d'identité et Propriété intellectuelle interdisent les titres, icônes ou logos qui suggèrent un lien avec une entreprise que vous ne représentez pas.
• La correction. Réécrivez le titre, la description et les captures pour qu'ils correspondent à l'app, et retirez les noms et logos de tiers, sauf autorisation écrite.

Des achats numériques hors du système de facturation de Google Play

• Ce que Google vérifie. La règle Paiements impose le système de facturation de Google Play pour les contenus numériques, les abonnements et les fonctionnalités de l'app, et interdit de diriger les utilisateurs vers un autre moyen de paiement. Les biens et services physiques ne doivent pas l'utiliser ; la facturation alternative et les liens externes n'existent que via des programmes, dans les pays éligibles.
• La correction. Faites passer les achats numériques par le système de facturation de Google Play, ou inscrivez-vous au programme qui s'applique à votre région.

Comment répondre : corriger la déclaration, corriger l'app, ou faire appel

Corriger une déclaration dans la Play Console

Quand le problème se situe dans un formulaire ou dans la fiche (Sécurité des données, URL de la politique de confidentialité, identifiants, titre, captures), corrigez-le dans la Play Console. Rien n'est examiné tant que vous n'avez pas cliqué sur Envoyer pour examen dans la page Vue d'ensemble de la publication. Aucun nouveau build n'est nécessaire.

Corriger l'app et la renvoyer

Quand le build est en cause, importez un app bundle conforme. Un piège dans la procédure de Google : le bundle corrigé doit remplacer le bundle non conforme sur chaque canal où il est actif, canaux de test compris, et les anciens bundles doivent être désactivés. Sinon le renvoi échoue, et les versions en ligne peuvent être supprimées.

Faire appel quand vous pensez que Google se trompe

Suivez les instructions de l'e-mail, ou utilisez le bouton Faire appel de la page État de conformité avec les règles ; la page d'aide de la Play Console sur les applications supprimées mène au même formulaire. Vous n'avez droit qu'à un appel par mesure : indiquez la règle citée, pourquoi elle ne s'applique pas, et joignez des preuves. Google ne répond aux appels qu'en anglais, chinois, coréen ou japonais, et ne publie aucun délai de réponse pour les appels concernant une application.

Ce qu'il ne faut pas faire

Ne renvoyez rien avant d'avoir corrigé toutes les infractions, et ne republiez pas la même application sous un nouveau nom de package ou depuis un autre compte. Google indique qu'après un avertissement, une seconde application qui fait la même chose entraînera presque certainement une suspension ou la clôture du compte, et que tout compte ouvert après une clôture est clôturé à son tour, sans remboursement des frais d'inscription.

Une checklist avant de renvoyer pour examen

La plupart des seconds refus répètent le premier, ou révèlent le problème suivant. Parcourez cette liste avant chaque envoi :

Si vous construisez avec le créateur d'application mobile de Cadrant, le build et la livraison sont pris en charge : le build Android tourne sur votre propre compte Expo, il est signé avec une clé d'upload que Cadrant génère et conserve, et Expo dépose l'app bundle dans votre propre Play Console, en release brouillon sur le canal de test interne. La conformité au règlement reste à votre charge d'éditeur : la fiche, la politique de confidentialité, le formulaire Sécurité des données, la classification du contenu, les autorisations et le contenu lui-même.

Ce qui change par rapport à l'App Review d'Apple

Si vous publiez sur les deux stores, les réflexes de l'un ne se transposent pas entièrement :

Notre guide sur le refus App Store couvre le côté Apple dans le même ordre. Sur les deux stores : lisez la règle citée, corrigez la cause plutôt que le symptôme, et n'envoyez qu'une fois.