Recours Google Play
La plupart des refus Play se règlent en corrigeant le problème et en important une nouvelle version. Un recours sert dans les cas où l'examinateur s'est trompé, ou quand vous devez fournir des preuves, par exemple que le site web encapsulé vous appartient. Ce guide montre où se trouve le recours dans la Play Console, comment en rédiger un qui soit vraiment lu, et quoi faire pendant l'attente.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Chaque refus, retrait ou avertissement apparaît à deux endroits : l'e-mail envoyé à votre compte développeur et Play Console → Règles → État des règles, qui liste chaque problème avec la règle concernée, la release touchée et souvent une capture d'écran ou une brève description de ce qu'a vu l'examinateur. Lisez cette entrée avant toute chose ; l'e-mail n'est qu'un résumé. Certaines entrées comportent un bouton Faire appel ; pour les autres, l'entrée renvoie au formulaire d'assistance sur les règles dans le centre d'aide. Les deux aboutissent à la même équipe chargée des règles.
Deux voies existent. Corriger et resoumettre : modifiez l'app ou la fiche, incrémentez le code de version, déployez une nouvelle release. C'est la bonne voie pour presque tous les problèmes techniques et de fiche, et aucun recours n'est nécessaire. Faire appel : vous pensez que la décision est erronée, ou l'examinateur a besoin d'informations qu'il n'a pas pu voir, comme des justificatifs de propriété ou un identifiant qu'il n'a pas utilisé. Les recours prennent des jours, parfois plus ; les nouvelles soumissions sont généralement plus rapides. Choisissez une seule voie par problème, et ne menez pas les deux de front avec des versions contradictoires.
Court, factuel, avec des preuves. Les examinateurs en lisent des centaines par jour.
Trouvez le nom de la règle dans État des règles et lisez la page de la règle vers laquelle il renvoie. Identifiez la phrase exacte que votre app est censée enfreindre. Si vous n'en trouvez aucune, c'est votre argument.
Installez le build refusé depuis le canal de test sur un appareil vierge, utilisez les identifiants fournis dans Accès à l'app et suivez la capture d'écran. Beaucoup de refus « injustes » s'avèrent fondés du point de vue d'une installation neuve (bandeau cookies, URL de prévisualisation, lien de suppression manquant).
Si vous avez trouvé quelque chose à corriger, corrigez-le et resoumettez ; décrivez la correction là où la Play Console vous permet d'ajouter des notes pour l'examen, comme les instructions d'Accès à l'app. Ne faites appel que si l'app est déjà conforme ou si vous devez fournir une preuve.
Captures d'écran de la fonctionnalité conforme dans l'app, URL de la page de suppression de compte, site web validé dans votre profil de développeur, licence ou certificat de marque, options exactes réglées dans Config.java. Joignez ou liez ce que le formulaire permet ; décrivez le reste.
Quatre à huit phrases : nom de l'app et nom de package, le problème, ce que l'examinateur a pu manquer ou ce que vous avez changé, où le trouver dans l'app (nom de l'écran et chemin), et une demande polie de réexamen. Utilisez les modèles ci-dessous.
Un seul recours par problème. Ne renvoyez pas le même texte chaque jour ; cela n'accélère rien. Pendant l'attente, gardez l'app web stable pour qu'un réexamen voie l'état conforme.
À utiliser quand le refus indique que l'app affiche un site web dans une WebView sans autorisation, ou qu'elle manque de fonctionnalités.
Ce modèle reste en anglais, car les examinateurs d'Apple et de Google lisent l'anglais.
App: [App name], package name [com.example.app], version code [123]. The website loaded by the app, [https://app.example.com], is our own product, operated by [company or your name], the owner of this developer account. The same domain is verified in our developer profile via Search Console, is named in the privacy policy at [URL], and the developer name matches the brand. The app is not a plain website wrapper: it adds native push notifications for [purpose], a native offline screen, [native share / biometric lock / QR scanner], and an app-only layout (no cookie banner or desktop navigation inside the app). All features are available after logging in with the credentials in App access: [username], [password]. We kindly ask for a re-review of version code [123]. We are happy to provide further proof of ownership, such as [domain registration / company documents].
Excellente façon de convertir son app web en app native ! Un délai très court, et un super moyen de mettre ses apps dans les stores sans devoir développer une app native complète !
À utiliser après avoir corrigé un problème de Sécurité des données, d'autorisations, de suppression, d'annonces ou de classification du contenu, pour que l'examinateur sache ce qui a changé.
Ce modèle reste en anglais, car les examinateurs d'Apple et de Google lisent l'anglais.
App: [App name], package name [com.example.app]. Rejected version code [123], new version code [124]. The issue was [one sentence, e.g. the Data safety section did not declare device identifiers collected by our push notification provider]. What we changed: [e.g. the Data safety form now declares Device or other IDs (collected, purpose: push notifications) and Crash logs; the privacy policy at [URL] was updated accordingly; the advertising ID permission was removed from the app because we do not show ads]. Where to verify: [e.g. Settings, Delete account, in the app; the public deletion page at [URL]]. Thank you for reviewing version code [124].
Restez factuel. Indiquez exactement où l'examinateur peut voir le comportement conforme.
Ce modèle reste en anglais, car les examinateurs d'Apple et de Google lisent l'anglais.
App: [App name], package name [com.example.app], version code [123]. The issue cites [policy name]. We believe the app complies: [one or two sentences describing the feature exactly as implemented, e.g. account deletion is available under Profile, Settings, Delete account, and on the web at [URL], and it removes the account and all associated data]. The screenshot in Policy status appears to show [what the reviewer saw and why, e.g. the login screen, because the demo account listed in App access was not used]. Steps to verify: 1. [Log in with ...] 2. [Open ...] 3. [Tap ...]. We kindly request a re-review. If any part of the implementation falls short of the policy, we would appreciate a pointer to the specific requirement so we can address it.
Généralement plusieurs jours ; les cas complexes prennent plus de temps. Une version corrigée et resoumise est en général examinée plus vite qu'un recours, c'est pourquoi le conseil par défaut est de corriger d'abord.
Oui, si la nouvelle version règle le problème. Veillez à ce que le recours et la nouvelle release racontent la même histoire, ou répondez au recours en indiquant que le problème a été corrigé.
Non. La version de production actuelle reste en ligne ; seule la release refusée est bloquée. Un retrait, c'est autre chose : il est traité dans le guide sur les apps retirées ou suspendues.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.
