Réponse rapide
D’après le Rapport annuel de transparence 2025 de Google, le ratio de refus des envois sur Google Play s’établit à environ 7,89 % : 1 692 467 envois refusés divisés par 21 461 250 envois examinés. C’est un calcul effectué sur les décomptes publiés par Google, pas un taux portant sur l’année complète 2026, ni la probabilité qu’une nouvelle application échoue à sa première tentative. Les chiffres distincts de Google sur l’application des règles mesurent d’autres résultats.
Source : Rapport annuel de transparence Google Play 2025 (PDF), publié le 31 mars 2026, périmètre mondial. Le rapport 2024 donne 10,13 % sur la même base.
Ce guide explique les chiffres récents de Google sur les envois et l’application des règles, leurs limites, et les contrôles pratiques qui vous aident à réagir à un refus. Le jeu de données annuel de transparence, les bilans de sécurité et chaque page de règles citée à l’endroit où elle sert ont été vérifiés le 12 septembre 2026.
Comment lire les étiquettes de ce guide
- Rapport GoogleChiffre publié dans un rapport de transparence de Google ou dans un bilan annuel de sécurité, cité à côté du nombre.
- CalculOpération que ce guide effectue sur les décomptes publiés par Google. Google n’en publie pas le résultat.
- Règle GoogleExigence ou processus décrit dans l’aide Play Console ou dans le Règlement du programme pour les développeurs.
- Contrôle pratiqueTest que nous recommandons, issu des envois que nous accompagnons. Ni une règle de Google, ni une fréquence de refus mesurée.
- ExempleIllustration construite pour montrer la forme d’un compte rendu. Ni un cas client, ni une statistique de la plateforme.
Sur cette page
Quel est le taux de refus des applications Google Play en 2026 ?
Google ne publie aucun pourcentage intitulé « taux de refus ». En revanche, il publie une fois par an les deux décomptes nécessaires pour en calculer un : le nombre d’envois d’applications qu’il a examinés et le nombre de ceux qu’il a refusés. La dernière année complète est 2025, dont les chiffres ont été publiés le 31 mars 2026 : un guide 2026 travaille donc sur l’activité de 2025.
Les dernières données annuelles complètes sur les envois
Rapport Google| Année d’activité | Envois examinés | Envois refusés | Refusés ÷ examinés | Publication du rapport |
|---|---|---|---|---|
| 2024 | 19 292 647 | 1 955 305 | 10,13 % | 31 mars 2025 · rapport |
| 2025 | 21 461 250 | 1 692 467 | 7,89 % | 31 mars 2026 · rapport |
Emplacement des sources : rapport 2025, page 3 de la version imprimée ; rapport 2024, pages 3 et 4. Les pourcentages sont calculés à partir des décomptes publiés (refusés ÷ examinés × 100) et arrondis à deux décimales. Les deux rapports décrivent leur couverture comme mondiale. Données vérifiées le 12 septembre 2026.
Voir le calcul par année
Part des envois refusés sur l’ensemble des envois examinés
Environ 8 envois examinés sur 100 ont été refusés en 2025.
Comment le ratio est calculé et ce qu’il ne peut pas prédire
Le ratio compare les décomptes annuels mondiaux d’envois d’applications examinés et refusés que Google publie. Les rapports ne définissent ni cohorte de premières tentatives ni ventilation détaillée par tentative d’envoi : cet agrégat ne doit donc pas servir à prédire le sort d’une nouvelle application donnée.
Ce que le ratio n’établit pas
- Les chances de votre application. Le complément (environ 92 %) n’est pas une probabilité d’approbation dès la première tentative pour une nouvelle application.
- Un chiffre 2026. Les données portant sur l’année 2026 complète ne sont pas encore disponibles. Présentez ce nombre comme les données 2025 disponibles en 2026.
- Un taux d’approbation final. Le rapport 2025 recense aussi les approbations obtenues après un refus, mais pas la comptabilité par cohorte qu’exigerait un taux d’approbation après correction : ce guide n’en calcule donc aucun.
- Un taux d’approbation du test fermé ou de l’accès en production. Les décisions d’accès concernant les nouveaux comptes personnels relèvent d’un autre processus et ne figurent pas dans ces tableaux.
- Une tendance en matière de sévérité. Le recul de 10,13 % à 7,89 % est une variation du ratio, et non la preuve que les règles se sont assouplies, que la qualité de l’examen a changé ou que le risque d’un développeur donné a baissé.
Pourquoi les sites citent des chiffres différents
Certaines pages affirment que Google ne publie aucun dénominateur : c’était vrai de la série des bilans de sécurité, pas des rapports de transparence. D’autres divisent le décompte des « applications empêchées » d’un bilan de sécurité par un dénominateur issu d’un rapport de transparence, ce qui mélange deux séries.
Les statistiques de Google sur les refus et l’application des règles
Google rend compte de la sécurité de sa plateforme à deux endroits faciles à confondre : le Rapport annuel de transparence, un tableau de décomptes d’envois et de mesures d’application des règles, et le bilan annuel de sécurité publié sur les blogs de Google, un récit assorti de chiffres clés arrondis.
Envois examinés et envois refusés
Rapport GoogleAu-delà des décomptes d’envois examinés et refusés du tableau ci-dessus, le rapport de transparence 2025 recense 2 012 981 suppressions et 125 550 comptes de développeur résiliés. Une suppression vise une application déjà disponible ; un refus est une décision portant sur un envoi, avant sa mise en ligne.
Source : Rapport annuel de transparence 2025, page 3 de la version imprimée.
Applications dont la publication a été empêchée, de 2023 à 2025
Rapport Google| Année d’activité | Applications non conformes dont la publication a été empêchée | Comptes de développeur malveillants bannis | Source |
|---|---|---|---|
| 2023 | 2,28 millions | 333 000 | Bilan de sécurité 2023 (29 avril 2024) |
| 2024 | 2,36 millions | Plus de 158 000 | Bilan de sécurité 2024 (29 janvier 2025) |
| 2025 | Plus de 1,75 million | Plus de 80 000 | Bilan de sécurité 2025 (19 février 2026) |
Ces mêmes bilans apportent un contexte qui n’est pas un décompte de refus. En 2023, près de 200 000 envois ont été refusés ou régularisés pour des autorisations sensibles telles que la localisation en arrière-plan et les SMS. En 2024, 1,3 million d’applications ont été empêchées d’obtenir un accès inutile ou excessif à des données utilisateur sensibles ; en 2025, ce chiffre dépassait 255 000, auxquels s’ajoutent 160 millions de notes et d’avis indésirables bloqués. Ces mesures ne s’additionnent ni entre elles ni avec le tableau.
Google indique par ailleurs effectuer plus de 10 000 contrôles de sécurité sur les applications, avant et après leur mise en ligne. Ce décompte ne signifie pas que le moindre défaut entraîne un refus automatique, ni que tous ces contrôles sont des barrières préalables à la publication.
Pourquoi les décomptes de refus, de suppressions et de publications empêchées diffèrent
| Source | Indicateur | Unité | Période | Ce qu’elle ne couvre pas |
|---|---|---|---|---|
| Rapport annuel de transparence | Envois refusés | Des envois, et non une cohorte annoncée d’applications uniques | Année civile | Le fait que la même application ait été approuvée par la suite |
| Rapport annuel de transparence | Suppressions | Applications supprimées après leur publication | Année civile | Les envois qui n’ont jamais été mis en ligne |
| Bilan annuel de sécurité | Applications dont la publication a été empêchée | Des applications, en chiffres arrondis | Année civile | Un dénominateur ; ce chiffre ne peut pas être converti en taux |
| Bilan annuel de sécurité | Comptes de développeur bannis | Des comptes | Année civile | Les refus d’applications pris individuellement |
Le rapport annuel de transparence et le bilan annuel de sécurité de Google emploient des libellés d’indicateurs différents et publient des totaux différents. Gardez chaque nombre attaché à sa source et à sa définition. Les rapports examinés n’expliquent aucune conversion directe entre les deux séries : ils ne doivent donc pas être combinés pour calculer un taux de refus unique.
Un agrégat de plateforme et le résultat mesuré d’un prestataire peuvent être vrais tous les deux. Le taux d’achèvement des tests gérés par PrimeTestLab décrit les tests fermés qu’il conduit et maintient pourvus en testeurs jusqu’à leur date de fin ; le ratio de Google décrit les décomptes d’envois d’applications qu’il publie. Aucun des deux ne prédit l’autre.
Quel type de décision Google Play avez-vous reçu ?
Avant de corriger quoi que ce soit, identifiez la décision que vous avez sous les yeux. Le terme « refusée » est employé de manière large pour au moins cinq situations, et l’étape suivante diffère dans chaque cas. Le statut affiché dans Play Console et l’e-mail adressé au propriétaire du compte la nomment précisément.
Règle GoogleSélectionnez l’avis que vous avez reçu
| Décision ou blocage | Votre situation | Étape suivante |
|---|---|---|
| Application ou mise à jour refusée | Les modifications envoyées n’ont pas été acceptées. Le refus d’une mise à jour ordinaire laisse la version publiée précédemment disponible pendant que vous la corrigez. | Lisez l’avis, corrigez l’envoi concerné, puis renvoyez-le. Voir après un refus. |
| Accès en production refusé, ou « Tests supplémentaires requis » | Votre demande de passage en production, pour l’application d’un nouveau compte personnel, doit être retravaillée ; c’est une décision de préparation qui porte sur le test fermé. | Suivez les étapes de test et de préparation, puis corrigez un refus d’accès en production lié aux tests. |
| Application supprimée | La fiche n’est plus disponible. L’application avait été publiée, et une mesure d’application des règles l’a visée après coup. | Suivez l’avis reçu et envoyez une mise à jour conforme par la voie qu’il indique. |
| Application suspendue, ou compte résilié | Mesure plus lourde, au niveau de l’application ou du compte, chacune avec son propre avis et ses propres conséquences. | Utilisez la procédure de recours indiquée dans l’avis. N’ouvrez pas un autre compte pour republier : c’est considéré comme une infraction. |
| Blocage d’import ou de compatibilité | L’envoi ne peut pas aboutir en l’état : par exemple un niveau d’API cible inférieur au seuil en vigueur, ou un bundle que la Console refuse. | Réglez l’exigence technique signalée, puis renvoyez l’application. Aucun examen n’a encore eu lieu. |
Signification des statuts : aide Play Console, Publier votre application et Procédure d’application des règles.
Ce qu’un statut ne vous dit pas
Une application indisponible n’a pas forcément été refusée pour non-respect des règles : vous l’avez peut-être dépubliée vous-même, ou une règle de compatibilité la retient. Et un refus d’accès en production peut avoir plusieurs causes : la ligne ci-dessus est un aiguillage, pas un diagnostic. Une version déployée sur un canal fermé peut elle-même faire l’objet d’un examen au regard des règles ; la demande d’accès en production, elle, est la décision distincte qui porte sur la préparation des tests.
Risques de refus documentés et correctifs pratiques
Google ne publie aucune liste classée des motifs de refus, et ce guide n’en invente pas. Les huit contrôles ci-dessous se suivent dans l’ordre où vous pouvez les mener, en partant du build puis en allant vers l’extérieur, chacun avec sa source réglementaire. Les points liés au test fermé figurent dans la section consacrée aux tests : ce sont des conditions d’éligibilité pour les nouveaux comptes personnels, pas des refus pour non-respect des règles.
Stabilité et fonctionnalités utiles
Plantages, blocages et échecs d’installation
- Le problème
- Les règles de Google sur les fonctionnalités interdisent les applications qui plantent, se ferment de force, se figent ou fonctionnent anormalement d’une autre manière, y compris celles qui ne s’installent pas, qui s’installent sans se lancer, ou qui se lancent sans répondre.
- Un test observable
- Installation propre de la version candidate exacte sur deux appareils physiques : ouverture, connexion, parcours principal complet, mise en arrière-plan puis reprise. Consultez ensuite le rapport pré-lancement pour y relever les plantages et les ANR (application qui ne répond pas).
- La correction
- Corrigez les plantages au démarrage et les ANR avant l’envoi, puis refaites le même parcours sur le build reconstruit.
Contenu statique sans fonctionnalité propre à l’application
- Le problème
- Les mêmes règles couvrent les fonctionnalités ou les contenus limités : contenu statique sans utilité propre à l’application, contenu très pauvre, ou application conçue pour ne rien faire. Le format à lui seul ne détermine pas la conformité ; l’application doit malgré tout offrir une utilité et un contenu suffisants.
- Un test observable
- Démontrez la fonction principale de l’application et expliquez le bénéfice concret qu’elle apporte. Vérifiez qu’elle offre un contenu suffisant et de vraies fonctionnalités, et pas seulement l’affichage d’éléments statiques.
- La correction
- Ajoutez la fonctionnalité ou le contenu qui donne à l’application une utilité suffisante pour l’usage auquel elle est destinée.
Accès de l’examinateur
L’examinateur n’atteint pas les fonctionnalités restreintes ou principales
- Le problème
- Google demande des identifiants de connexion fonctionnels et des instructions pour toute fonctionnalité placée derrière une connexion, une restriction géographique ou une authentification inhabituelle. Sans cela, l’examinateur se heurte à un mur, et une application qui ne peut pas être examinée n’est pas approuvée.
- Un test observable
- Installez la version que vous envoyez sur un appareil vierge, et n’utilisez que les identifiants et les instructions figurant dans la page Contenu de l’application. S’il vous a fallu autre chose pour entrer, il en ira de même pour l’examinateur.
- La correction
- Fournissez un compte d’examen dédié qui n’expire pas, ainsi que des instructions pas à pas pour chaque fonctionnalité protégée. Toutes les applications n’ont pas besoin d’une connexion ; et un compte fonctionnel est une condition préalable à l’examen, pas une garantie d’approbation.
Autorisations, confidentialité et Sécurité des données
Portée des autorisations et déclarations
- Le problème
- Les autorisations sensibles comme la localisation en arrière-plan et les SMS exigent un cas d’usage que l’application assure visiblement, et lorsqu’un formulaire de déclaration existe, il doit correspondre à ce que fait l’application. Le bilan de sécurité 2023 de Google faisait état de près de 200 000 envois refusés ou régularisés pour exactement ce motif.
- Un test observable
- Listez chaque autorisation dangereuse du fichier manifeste et, pour chacune, nommez l’écran où l’utilisateur comprend pourquoi elle est nécessaire.
- La correction
- Retirez tout ce qui n’a pas de cas d’usage visible, et faites en sorte que les déclarations dans la Console décrivent le comportement que l’examinateur observera. Un motif lié à une fonctionnalité ne suffit pas à lui seul : vérifiez les restrictions d’autorisation applicables, ainsi que toute divulgation bien visible et tout consentement exigés avant l’accès.
Source Règles relatives aux données utilisateur · Bilan de sécurité 2023
Politique de confidentialité et suppression de compte
- Le problème
- Indiquez l’URL de la politique de confidentialité dans Play Console, ainsi qu’un lien ou le texte de la politique à l’intérieur de l’application. La page doit être publique, accessible depuis tous les pays, ne pas être un PDF et ne pas être modifiable par les visiteurs ; elle doit identifier l’application ou le développeur et décrire les données réellement collectées. Si les utilisateurs peuvent créer un compte depuis l’application, proposez des moyens repérables de demander la suppression depuis l’application et en dehors, et indiquez les durées de conservation nécessaires.
- Un test observable
- Ouvrez l’URL depuis un appareil déconnecté, depuis un autre pays si vous le pouvez, et relisez-la en regard du formulaire Sécurité des données.
- La correction
- Publiez une page de politique que vous maîtrisez, indiquez-la dans Play Console et dans l’application, et ajoutez les parcours de demande de suppression là où l’application crée des comptes.
Sécurité des données et cohérence des SDK
- Le problème
- La déclaration Sécurité des données doit refléter ce que l’application et chacun des SDK tiers qu’elle embarque collectent et partagent. Les SDK publicitaires, d’analyse et de remontée de plantages peuvent collecter ou partager des données sans autorisation à l’exécution : une application « sans autorisations » n’est donc pas automatiquement une application « sans données », et une page de confidentialité en ligne ne prouve pas que le formulaire est exact. Vérifiez la version précise du SDK, sa configuration et son comportement réel.
- Un test observable
- Exportez la liste des dépendances de la version, consultez la déclaration de données de chaque SDK et comparez-la à chaque réponse du formulaire. Observez le réseau au premier lancement pour voir ce qui quitte l’appareil avant la moindre action de l’utilisateur.
- La correction
- Corrigez le formulaire pour qu’il corresponde au comportement observé, ou retirez le SDK. La déclaration relève de votre responsabilité, y compris pour du code que vous n’avez pas écrit.
Source Fournir des informations pour la section Sécurité des données
Fiche Play Store, déclarations et paiements
Fiche Play Store, publicités, audience et déclarations de contenu
- Le problème
- La section Contenu de l’application demande si l’application contient des publicités, quelle audience elle vise, puis réclame le questionnaire de classification du contenu et les autres déclarations applicables. Une fiche qui met en avant des fonctionnalités absentes du build, ou une déclaration en contradiction avec l’application, suffit à elle seule à provoquer un refus.
- Un test observable
- Reprenez chaque réponse de la section Contenu de l’application avec la version ouverte à côté de vous, et confrontez chaque capture d’écran à l’interface actuelle.
- La correction
- Mettez les déclarations et les visuels de la fiche en accord avec le build qu’ils décrivent ; une correction de la fiche peut ne demander aucun nouveau binaire.
Paiements et conditions des programmes applicables
- Le problème
- Le système de facturation de Google Play est obligatoire pour certains achats intégrés de biens et de services numériques. Les biens physiques, les services du monde réel et quelques autres catégories en sont exclus, et les programmes de facturation alternative ou d’offres externes s’appliquent dans des régions précises, selon leurs propres conditions.
- Un test observable
- Pour chaque parcours d’achat, déterminez s’il vend du contenu numérique consommé dans l’application ; si c’est le cas, vérifiez qu’il passe par Play Billing ou par un programme auquel vous êtes réellement inscrit.
- La correction
- Basculez les achats numériques vers Play Billing, ou documentez votre inscription au programme. Ne traitez pas un programme régional comme une exemption mondiale.
Les contrôles préalables à l’examen ne sont pas l’examen
Les contrôles préalables à l’examen de Play Console signalent certains de ces points avant l’envoi (identifiants manquants, déclarations d’autorisations, lien de confidentialité rompu), et le rapport pré-lancement met l’application à l’épreuve sur des appareils de test. Les deux valent la peine d’être utilisés ; les réussir ne garantit pas l’approbation lors de l’examen formel de l’application, et ni l’un ni l’autre ne mesure la façon dont les participants d’un test fermé ont utilisé l’application.
Sources : Détecter rapidement les problèmes grâce aux contrôles préalables à l’examen · Utiliser un rapport pré-lancement pour identifier les problèmes
Comment le test fermé conditionne l’accès en production
Qui doit remplir l’exigence de test ?
Règle GoogleLes comptes de développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits sans interruption pendant les 14 derniers jours avant de pouvoir demander l’accès en production. Atteindre ce minimum vous rend éligible à la demande ; cela n’approuve pas l’application. Les comptes d’organisation et les comptes personnels créés avant cette date ne sont pas soumis à cette exigence.
Le test interne ne remplace pas le test fermé, quelle que soit sa durée : les 12 testeurs doivent être inscrits sur un canal de test fermé. Le détail de la configuration figure dans le guide des exigences de test fermé de Google Play.
Source : Exigences de test des applications pour les nouveaux comptes de développeur personnels.
Preuves, préparation et étape suivante
Du test qualifiant à la version de production
- 1Terminez le test fermé qualifiant. Au moins 12 testeurs, inscrits sans interruption pendant les 14 derniers jours.
- 2Demandez l’accès en production. Le formulaire demande comment les testeurs ont utilisé l’application, quels commentaires vous avez reçus et ce que vous avez changé en conséquence.
- 3Google examine la demande, généralement en 7 jours ou moins, parfois davantage, puis accorde l’accès ou réclame des tests supplémentaires. Cette estimation porte sur cet examen, pas sur l’ensemble du calendrier de votre lancement.
- 4Une fois l’accès accordé, préparez la version de production. Son examen et son déploiement sont des étapes distinctes de cette décision : l’accès est une éligibilité, pas une publication.
Si un testeur se désinscrit, sa propre période qualifiante est interrompue et ses jours cessent de compter. Les autres testeurs ne sont pas touchés. Ce qui compte au moment de la demande, c’est d’avoir encore 12 testeurs qualifiés, pas de savoir si quelqu’un est parti en cours de route.
Google demande ce que vous avez appris ; il ne fixe aucun nombre minimal de mises à jour. La déclaration de préparation que vous devez pouvoir faire honnêtement est la suivante : J’ai examiné les commentaires des testeurs, corrigé les problèmes lorsque c’était nécessaire, et je peux expliquer ce que j’ai appris et pourquoi l’application est prête. Si la réponse honnête est que personne n’a utilisé l’application, l’examen aboutira probablement à la même conclusion.
Quelques testeurs au-delà de 12 vous donnent une marge contre les désistements et des commentaires plus variés ; nous n’affirmons pas que cela améliore l’approbation de façon mesurable. Couvrez des appareils physiques représentatifs, comme choix d’assurance qualité. Les critères publiés ne disent rien de la façon dont les émulateurs sont comptabilisés : ce guide n’avance donc aucune affirmation dans un sens ou dans l’autre. À lire aussi : prévoir une marge de testeurs, les questions du formulaire d’accès en production et ce qu’il faut vérifier après un refus.
Que faire après le refus d’une application ou d’une mise à jour
L’avis nomme la décision, l’envoi concerné, ainsi que la règle ou l’exigence en cause. Partez de là, dans cet ordre.
Règle Google- 1Lisez la décision exacte et repérez l’envoi concerné. Quelle version, quel canal, quelle règle ou quelle exigence.
- 2Reproduisez ou inspectez le problème cité sur le build qui a été examiné, pas sur celui que vous avez sous la main.
- 3Corrigez le problème et vérifiez les exigences voisines dans le même domaine, pour que l’examen suivant ne tombe pas sur celle d’à côté.
- 4Validez le build ou la déclaration concernés : refaites le test observable du contrôle correspondant ci-dessus.
- 5Envoyez la correction appropriée, ou empruntez la voie du recours si vous estimez la décision erronée. Lorsque c’est nécessaire, ouvrez Aperçu de la publication et sélectionnez Envoyer pour examen : enregistrer une correction ne l’envoie pas toujours automatiquement.
- 6Conservez les preuves et suivez le résultat. Avis, version, problème, correction, validation, décision.
Corriger et renvoyer, ou faire appel
Si le constat est fondé, corrigez-le et renvoyez l’application. Les consignes de Google sur l’application des règles sont explicites : renvoyer sans corriger l’infraction constitue en soi un problème. Ne renvoyez rien tant que l’infraction citée n’est pas résolue ; certaines corrections modifient la fiche ou les déclarations sans toucher au binaire. Si vous estimez la décision erronée, suivez les instructions de recours figurant dans l’avis et joignez le nom du package, la version concernée, la règle citée, les raisons pour lesquelles vous jugez la décision erronée, ainsi que des captures d’écran ou des étapes reproductibles qui démontrent la conformité. N’essayez pas de republier via un autre compte.
Sources : Procédure d’application des règles · Contrôler le moment où les modifications d’une application sont examinées et publiées.
Correction du binaire ou correction d’une déclaration ?
Une correction de la fiche ou d’une déclaration peut ne demander aucun nouveau binaire. Un nouveau build devient nécessaire lorsque la correction modifie le code empaqueté, les ressources, les autorisations ou la configuration. Des corrections côté site web ou côté serveur suffisent parfois à résoudre le problème sans recompiler. Suivez l’avis et validez l’envoi concerné.
Google décrit le traitement des modifications d’application, de façon générale, comme prenant de quelques heures à sept jours, parfois davantage. Ce n’est pas un délai de résolution garanti pour votre refus ou votre recours, et l’examen de l’accès en production relève d’un processus distinct ; voir les délais d’examen de Google Play. Aucun nombre de refus tolérés ni aucune probabilité de succès d’un recours n’est publié, et rien de tel n’est promis ici.
À quoi ressemble un compte rendu de refus utile
ExempleDeux comptes rendus illustratifs, construits pour montrer la forme des éléments qu’il vaut la peine de conserver : l’un pour le refus d’une mise à jour, l’autre pour une éligibilité aux tests incomplète. Ce ne sont ni des cas clients, ni des statistiques. Conservez l’ID d’envoi issu de l’activité d’envoi de Play Console, avec l’avis et la version concernée, afin que l’assistance puisse identifier l’envoi exact.
| Avis | Mise à jour refusée, Règles relatives aux données utilisateur |
|---|---|
| Version concernée | 2.4.1 (build 241), canal de production |
| Problème | Le lien de la politique de confidentialité dans la fiche renvoyait une erreur 404 |
| Correction | Page de politique de confidentialité rétablie à l’URL existante, celle déjà utilisée dans Play Console et dans l’application. Aucune URL intégrée n’a changé, donc aucun nouveau binaire n’était nécessaire. |
| Validation | URL ouverte depuis un appareil déconnecté, dans deux pays ; formulaire Sécurité des données relu en regard de la page |
| Décision | Renvoyée ; mise à jour approuvée |
| Avis | Éligibilité aux tests incomplète |
|---|---|
| Version concernée | 1.0.3, canal de test fermé |
| Problème | 12 testeurs ajoutés ; seuls 9 sont restés inscrits pendant les 14 jours |
| Correction | Trois testeurs de remplacement recrutés ; chacun a démarré sa propre période de 14 jours |
| Validation | Le tableau de bord affichait 12 testeurs inscrits depuis les 14 derniers jours |
| Décision | Éligible à la demande une fois terminées les périodes requises des testeurs de remplacement |
Liste de contrôle avant envoi
Passez-la sur la version exacte que vous vous apprêtez à envoyer, pas sur celle que vous avez testée la semaine dernière. Les points marqués selon les cas dépendent de ce que fait l’application.
Build et comportement
Accès de l’examinateur et déclarations
Confidentialité et données
Paiements
Exigence de test, nouveaux comptes personnels uniquement
Questions et réponses
Le ratio annuel prédit-il le résultat du premier examen de mon application ?
Non. Le ratio de 7,89 % compare les décomptes mondiaux publiés par Google d’envois d’applications examinés et refusés pour 2025. Les rapports ne définissent aucune cohorte de premières tentatives : ni le ratio ni son complément ne constituent donc une probabilité pour une nouvelle application donnée.
Pourquoi le décompte du bilan de sécurité diffère-t-il de celui du rapport de transparence ?
Ils mesurent des choses différentes. Le bilan annuel de sécurité publie des décomptes arrondis d’applications non conformes dont la publication a été empêchée ; le rapport de transparence, lui, compte les envois refusés et les suppressions. Google ne publie aucune réconciliation entre les deux séries : elles ne peuvent donc pas être combinées en un taux unique.
Le refus d’une mise à jour affecte-t-il la version déjà publiée ?
Le refus d’une mise à jour ordinaire ne retire pas la version publiée : la version précédente reste disponible pendant que vous corrigez la mise à jour. La suppression, la suspension et la résiliation du compte sont des statuts d’application des règles distincts, avec leurs propres avis, et ceux-là touchent bien l’application en ligne.
Un refus d’accès en production est-il un refus pour non-respect des règles ?
Non. Pour un nouveau compte personnel, une décision d’accès en production porte sur le test fermé que vous avez mené et sur les réponses que vous avez données. « Tests supplémentaires requis » signifie que la demande doit être retravaillée : ce n’est pas une sanction visant l’application au titre des règles, et ajouter des testeurs ne lève pas un véritable refus pour non-respect des règles.
Dois-je faire appel ou envoyer une correction ?
Ne renvoyez rien tant que l’infraction citée n’est pas résolue. Certaines corrections modifient la fiche ou les déclarations sans toucher au binaire. Si vous estimez la décision erronée, suivez les instructions de recours figurant dans l’avis et fournissez des preuves de conformité. Ne créez pas un autre compte pour republier : c’est considéré comme une infraction.
Sources et notes sur les données
La suite dépend de ce que vous cherchez. Pour citer le taux, citez 7,89 % avec son année (activité 2025) et son dénominateur (les envois examinés). Pour agir sur un avis, trouvez sa ligne dans le tableau des décisions et suivez ce parcours. Si l’exigence de test est ce qui vous bloque, le guide des exigences de test fermé couvre la configuration de bout en bout.
En résumé
Le ratio de refus des envois sur Google Play pour 2025 est d’environ 7,89 %, calculé à partir de 1 692 467 envois refusés et de 21 461 250 envois examinés dans le Rapport annuel de transparence 2025 de Google. C’est un chiffre historique à l’échelle de la plateforme, pas la probabilité qui pèse sur votre application. Un avis de refus nomme une décision précise : corrigez ce qu’il nomme, renvoyez ou faites appel, et traitez l’exigence de test des nouveaux comptes personnels comme une étape de préparation distincte.
Rapports annuels de transparence
Bilans annuels de sécurité
Règles et aide Play Console
Historique des mises à jour
28 février 2026 : publication, avec la seule série des bilans annuels de sécurité. 12 septembre 2026 : ajout du calcul issu du rapport de transparence et de ses limites, séparation des deux séries Google, ajout du tableau des décisions et des sections sur l’accès de l’examinateur, la Sécurité des données et l’après-refus, et suppression de la présentation par motifs classés ; une seconde relecture le même jour a corrigé les formulations sur le renvoi, les fonctionnalités et les délais d’examen. Prochaine actualisation annuelle lorsque Google publiera le rapport 2026, attendu en 2027.