Réponse rapide
Un refus Broken Functionality signifie que l’examinateur de Google a constaté que la version soumise plantait, se fermait de force, se figeait ou fonctionnait anormalement d’une autre manière; les exemples de Google sont des applications qui ne s’installent pas, qui s’installent mais ne se chargent pas, ou qui se chargent mais ne répondent pas. C’est une décision de règlement sur une version, pas un refus d’accès en production, et Google précise qu’un refus à lui seul n’affecte pas la réputation de votre compte de développeur. Reproduisez le problème sur la version distribuée par Play, vérifiez que les examinateurs peuvent se connecter grâce aux Informations de connexion (anciennement Accès à l’application), corrigez chaque canal concerné, puis envoyez la version corrigée pour examen. Ne faites appel que si vous pouvez montrer que le constat était erroné.
À jour au 16 octobre 2026. Chaque règle de cette page a été vérifiée à cette date dans les pages de règlement Google Play et l’aide Play Console, et chacune est liée là où elle est utilisée. Les témoignages de développeurs cités plus bas montrent ce que des développeurs ont vu en 2026, pas le diagnostic de Google sur leurs applications, et aucun classement des causes n’est proposé, car aucune donnée publique ne permet d’en établir un.
Cet article traite des refus de version au titre du règlement Broken Functionality. Si Google a refusé l’accès en production après votre test fermé, ou vous a indiqué que des tests supplémentaires sont nécessaires, il s’agit d’une autre décision qui se corrige autrement: lisez plutôt que faire quand Google Play exige des tests supplémentaires et pourquoi les demandes après un test fermé sont refusées.
Ce que couvre cet article
Que signifie Broken Functionality sur Google Play?
C’est l’une des deux sections du règlement Google "Fonctionnalités, contenu et expérience utilisateur". L’autre section, Limited Functionality and Content, vise les applications qui ont trop peu d’utilité. Broken Functionality vise une application qui ne fonctionne pas telle qu’elle a été soumise.
Nous n’autorisons pas les applications qui plantent, se ferment de force, se figent ou fonctionnent anormalement de toute autre manière.
Sous cette phrase, Google cite trois exemples de violations courantes: les applications qui ne s’installent pas, celles qui s’installent mais ne se chargent pas, et celles qui se chargent mais ne répondent pas. Voyez-y trois endroits où chercher. Un examinateur qui ne peut pas installer la version, qui voit un écran vide ou un chargement sans fin, ou qui touche une commande sans que rien ne se passe, peut produire le même avis.
Vous croiserez peut-être encore le nom Minimum Functionality dans d’anciens liens d’aide et fils de forum. La section actuelle du règlement s’appelle Limited Functionality and Content: elle couvre les applications de texte statique ou de PDF, les applications avec très peu de contenu et celles conçues pour ne rien faire. Un avis peut citer l’une ou l’autre section, et les corrections diffèrent, alors lisez laquelle votre avis nomme avant de modifier quoi que ce soit.
Quatre décisions que l’on confond entre elles
| Décision | Ce qu’elle concerne | Par où commencer |
|---|---|---|
| Broken Functionality | Ce qu’elle concerneLa version soumise a planté, s’est figée, ne s’est pas chargée ou n’a pas répondu pour l’examinateur. | Par où commencerReproduisez le problème sur la version distribuée par Play, corrigez-le sur chaque canal concerné, soumettez à nouveau. |
| Limited Functionality and Content | Ce qu’elle concerneL’application tourne mais offre trop peu d’utilité ou de contenu propre. | Par où commencerAjoutez de vraies fonctionnalités. Une simple correction de bug ne répondra pas à ce constat. |
| Informations de connexion absentes ou non fonctionnelles | Ce qu’elle concerneLes examinateurs n’ont pas pu franchir une connexion, un abonnement, un paywall, un code à usage unique ou un contrôle de région. | Par où commencerMettez à jour les Informations de connexion dans Contenu de l’application, puis envoyez la modification pour examen. |
| Accès en production non accordé | Ce qu’elle concerneAprès le test fermé, Google a estimé que l’application a besoin de tests supplémentaires ou n’est pas prête pour la production. | Par où commencerUn processus distinct, sans avis technique sur le code. Voir tests supplémentaires requis. |
Où Google montre-t-il ce qui ne fonctionnait pas?
Commencez par l’e-mail de mesure d’application et la page État des règles dans Play Console. Ensemble, ils nomment le règlement et la version concernée, et Google indique que l’état des règles affiche aussi toute information supplémentaire disponible. Captures d’écran, détails sur l’appareil et traces de pile ne sont pas promis: ne les attendez pas.
Ouvrez Play Console, sélectionnez l’application et ouvrez sa page État des règles. Notez quatre éléments avant de toucher au code: la section du règlement nommée, le code de version et le canal examinés, la date, et toute preuve jointe. Consultez aussi l’e-mail et vos notifications Play Console, car c’est là que Google indique quel règlement la version a enfreint.
À quoi ressemblent vraiment les avis en 2026
Il n’existe pas d’e-mail Broken Functionality unique que tout le monde reçoit, et toute page qui en publie un comme modèle exact devine. Les développeurs qui ont publié leurs avis en 2026 décrivent des niveaux de détail très différents:
- Un libellé d’avis indiquant "Broken Functionality: Unresponsive UI elements" (éléments d’interface qui ne répondent pas), publié le 2 septembre 2026 par un développeur dont l’application affichait un écran hors ligne avec bouton Réessayer pendant sa première synchronisation de données (communauté d’aide Play Console).
- Un exemple de l’examinateur indiquant "For example, your app does not open or load." (par exemple, votre application ne s’ouvre pas ou ne se charge pas), cité en juin 2026 par un développeur de jeu dont l’écran titre se chargeait bien. L’auteur a ensuite indiqué que le jeu avait été publié après avoir modifié la façon dont le bouton Retour d’Android le quittait.
- Un avis qu’un développeur a décrit en août 2026 comme deux mots seulement, "Broken functionality", sans rien d’autre.
Ce sont des extraits reproduits par des développeurs, pas des e-mails Google authentifiés, et chacun est un cas isolé. Ils montrent l’éventail de détails que vous pourriez recevoir, pas ce que dira votre avis ni pourquoi votre application a échoué.
Si votre avis est vague
Traitez le règlement cité comme un symptôme à reproduire, pas comme un diagnostic. Les cinq vérifications de la section suivante sont ordonnées pour que chacune écarte un endroit différent où la défaillance peut se cacher.
Que vérifier en premier après un refus Broken Functionality?
Faites cinq vérifications sur la version exacte examinée par Google. Elles vont de la moins coûteuse à écarter à la plus difficile, et non selon la fréquence de chaque cause, car aucune donnée publique n’indique à quelle fréquence chacune se produit.
Cinq vérifications, dans l’ordre
Installez la version distribuée par Play, pas votre version de debug
Installez depuis votre canal de test sur un appareil vierge, connecté avec un compte Google qui n’a jamais lancé l’application, puis ouvrez-la comme le ferait un examinateur. Google Play signe les versions qu’il distribue avec votre clé de signature d’application (Utiliser la signature d’application Play), donc tout service qui vérifie une empreinte de certificat, comme Google Sign-In, Maps ou une clé API restreinte par nom de package et SHA-1, peut fonctionner dans votre version de debug et échouer dans la version du Store. En 2025, un développeur a attribué une défaillance propre à la version de production à une autorisation Internet absente du manifeste de production.
Vérifiez que l’examinateur peut entrer
Si une partie de l’application se trouve derrière une connexion, un abonnement, une localisation ou une autre restriction, Google exige que vous fournissiez les informations d’accès. Vérifiez que les Informations de connexion (anciennement Accès à l’application) contiennent des identifiants qui fonctionnent aujourd’hui, depuis n’importe quel pays, sans code à usage unique. La section suivante détaille la marche à suivre.
Testez le backend depuis l’extérieur de votre réseau
Les écrans de connexion et de données échouent quand le serveur est injoignable depuis le réseau de l’examinateur. En 2026, des développeurs ont attribué des défaillances à une règle de pare-feu accidentelle qui bloquait une demande de code de connexion, et signalé une erreur de confiance de certificat affichée sur un écran de connexion. Testez en données mobiles et sur un autre réseau, et depuis un autre pays si votre serveur filtre le trafic par région.
Touchez chaque commande visible et ouvrez chaque écran vide
Chaque bouton et chaque lien doit répondre avec un contenu approprié. La checklist Broken Functionality de Google, publiée dans la communauté d’aide Play Console, indique: "Assurez-vous que votre application ne comporte aucune page vide ou blanche dépourvue d’avertissement ou de message d’erreur approprié." Retirez les fonctionnalités inachevées au lieu de livrer un bouton qui ne fait rien, et vérifiez que chaque fonctionnalité promise par votre fiche Play Store fonctionne réellement dans la version. Donnez à une liste légitimement vide, par exemple aucun élément enregistré pour l’instant, une phrase qui l’explique et une action suivante. Si votre navigation est inhabituelle, comme toucher n’importe où pour continuer, ajoutez un repère visible qu’un nouvel utilisateur ne peut pas manquer.
Vérifiez le lancement, le bouton Retour et les rapports que Play détient déjà
Ouvrez l’application à froid, faites-la pivoter, envoyez-la en arrière-plan puis ramenez-la, et appuyez sur Retour sur chaque écran. Lisez ensuite le rapport pré-lancement et Android vitals pour la version examinée. Un plantage enregistré là est la preuve la plus solide que vous obtiendrez, et un rapport sans erreur a des limites, expliquées deux sections plus loin.
Comment fournir des informations de connexion aux examinateurs de Google?
Dans Play Console, allez dans Règles et programmes, puis Contenu de l’application, puis Informations de connexion (Sign-in details). La section s’appelait auparavant Accès à l’application (App access): d’anciens articles et certaines pages d’aide traduites utilisent encore ce nom.
Si l’accès à tout ou partie de votre application est limité par des identifiants de connexion, des informations de connexion, des abonnements, la localisation ou d’autres formes d’authentification, vous devez fournir toutes les informations requises pour permettre l’accès à votre application.
Ajouter ou mettre à jour les instructions
- Ouvrez Play Console et accédez à la page Contenu de l’application (Règles et programmes > Contenu de l’application).
- Sous Informations de connexion, sélectionnez Commencer, ou Gérer si vous avez déjà ajouté des instructions.
- Sélectionnez + Ajouter des instructions et saisissez les informations d’accès. Utilisez le champ Autres instructions pour tout ce qui sort de l’ordinaire, comme un mot de passe à usage unique, une authentification multifacteur ou une connexion à plus de deux champs.
- Enregistrez vos modifications. Vous pouvez ajouter jusqu’à cinq jeux d’instructions.
- Accédez à l’Aperçu de la publication, trouvez la modification sous Modifications prêtes à être envoyées pour examen et sélectionnez Envoyer pour examen. Enregistrer seul ne soumet rien.
Ce qui compte comme un accès fonctionnel
Les exigences relatives à Play Console de Google demandent de "fournir un compte de démonstration actif, des informations de connexion et toutes les autres ressources nécessaires à Google Play pour examiner votre application". Les exigences de Google concernant les informations de connexion précisent ce que cela signifie:
- Un compte actif et réutilisable, pas une invitation à usage unique ni un essai qui expire pendant l’examen.
- Des identifiants qui contournent les codes à usage unique et la validation en deux étapes, car l’examinateur ne peut pas recevoir le code que vous envoyez sur un téléphone ou une boîte mail.
- Un accès qui fonctionne depuis n’importe quel lieu si l’application restreint par région, et un accès complet aux fonctionnalités payantes ou protégées que l’examinateur doit voir, sans être facturé.
- Des informations rédigées en anglais et tenues à jour. Si vous changez le mot de passe ou supprimez le compte de test, mettez à jour les Informations de connexion le jour même.
- Si la connexion nécessite autre chose que du texte, comme un QR code ou un code-barres, générez une URL statique pour cet élément et ajoutez-la aux Informations de connexion. Si l’application demande aux utilisateurs de définir leur propre code PIN ou utilise une connexion via un réseau social, expliquez dans les instructions comment un examinateur peut passer cette étape.
Un accès manquant n’est pas une connexion défaillante
Si l’avis cite les Informations de connexion, aucune modification du code n’aidera tant que les informations d’accès ne sont pas corrigées et envoyées pour examen. Si les identifiants étaient bons et que la connexion elle-même a échoué, c’est un problème Broken Functionality, et c’est du côté de la vérification du backend ci-dessus qu’il faut chercher.
Et si l’application fonctionne sur votre téléphone et que Google n’a envoyé aucune capture d’écran?
Alors votre téléphone n’est pas l’environnement qui a échoué. Reproduisez sur la version du Store, sur un appareil vierge et un autre réseau, et lisez les deux rapports que Play Console détient déjà pour cette version avant de décider quoi que ce soit.
Le rapport pré-lancement
Vous le trouverez sous Tester et publier > Tests > Rapport pré-lancement. Google le génère automatiquement quand vous importez un app bundle ou un APK, selon la capacité disponible, en exécutant l’application sur des appareils de test. Vérifiez quels écrans l’exploration a réellement atteints: si elle s’est arrêtée à votre écran de connexion, elle n’a jamais vu le reste de l’application. Google ajoute une limite à connaître: "Les identifiants ne peuvent être insérés automatiquement que dans les applications Android qui utilisent des widgets Android standards." (Utiliser un rapport pré-lancement pour repérer les problèmes). Un rapport sans erreur est une preuve, pas un feu vert. Google dit la même chose de ses vérifications préalables à l’examen: "Réussir toutes les vérifications préalables à l’examen ne garantit pas la réussite du processus d’examen formel de l’application".
Android vitals
Vous le trouverez sous Surveiller et améliorer > Android vitals > Plantages et ANR. Google ne collecte ces données qu’auprès des utilisateurs qui ont accepté de partager leurs données d’utilisation et de diagnostic (Surveiller la qualité technique avec Android vitals), donc une nouvelle application dans un petit test peut n’afficher absolument rien. Une page Android vitals vide ne prouve pas que l’application n’a jamais planté.
De vraies personnes sur de vrais appareils
Un test fermé sert justement à trouver ce genre de problème avant une version publique. Des testeurs sur des téléphones, des versions d’Android et des réseaux différents atteignent les écrans qu’atteint un examinateur, et leurs commentaires vous indiquent où ça casse. Cela vous aide à trouver et corriger des défauts; cela ne change pas la façon dont Google examine l’application. Pour les bases du canal lui-même, consultez comment fonctionne le test fermé Google Play.
Faut-il corriger et soumettre à nouveau, ou faire appel?
Corrigez et soumettez à nouveau quand vous pouvez reproduire une défaillance ou trouver une cause plausible. Faites appel quand vous avez des preuves que le constat cité est erroné. Ne soumettez jamais la même version sans modification: Google demande aux développeurs de ne pas republier une application refusée tant que la violation n’est pas corrigée.
Corriger, clarifier ou faire appel?
Répondez à trois questions sur votre avis et vos propres tests. Vos choix ne quittent pas cette page.
Répondez aux questions pour voir une recommandation. Si vous ne pouvez pas reproduire de défaillance, c’est la troisième question qui tranche.
Corrigez, puis soumettez à nouveau sur chaque canal
Corriger et soumettreVous avez une défaillance reproductible, ce qui est la meilleure position possible. Corrigez-la, testez la correction sur la version du Store, puis suivez les étapes de nouvelle soumission ci-dessous pour qu’aucun bundle non conforme ne reste actif sur un canal.
Testez la version du Store avant de décider
Tester d’abordUne version de debug n’est pas ce que l’examinateur a exécuté. Installez depuis votre canal de test sur un appareil vierge avec un nouveau compte, sur un réseau que vous ne contrôlez pas, et faites les cinq vérifications. Ne décidez qu’ensuite.
Corrigez les Informations de connexion, puis envoyez pour examen
Correction d’accèsMettez à jour les instructions avec des identifiants réutilisables qui contournent les codes à usage unique, enregistrez, puis envoyez la modification pour examen depuis l’Aperçu de la publication. Google indique que vous pouvez le faire sans contacter l’équipe d’assistance sur les règles ni attendre sa réponse.
Ajoutez de l’utilité, pas seulement des corrections
RetravaillerLimited Functionality and Content porte sur ce que fait l’application. Ajoutez de vraies fonctionnalités ou du vrai contenu propres à l’application avant de soumettre à nouveau; une correction de stabilité ne répond pas à ce constat.
Rendez la conception évidente, puis décidez
ClarifierSi un écran hors ligne, un état vide ou un geste inhabituel est voulu, un examinateur peut quand même le prendre pour un dysfonctionnement. Ajoutez un repère visible, une explication et une action suivante. Vous pouvez faire appel avec des preuves, mais un écran plus clair lève aussi le doute pour le prochain examinateur.
Faites appel avec des preuves
AppelVous avez testé la version du Store sur un appareil vierge et un autre réseau sans rien trouver d’anormal. Faites appel une seule fois, avec le code de version, l’appareil et la version d’Android, les étapes exactes et un enregistrement d’écran du parcours que nomme l’avis.
Soumettre à nouveau une version corrigée
Les étapes de nouvelle soumission de Google vont au-delà de l’importation d’un nouveau code de version:
- Lisez le règlement nommé dans l’e-mail et vos notifications, et vérifiez aussi l’application au regard des autres règlements; Google avertit que d’autres violations peuvent entraîner d’autres mesures.
- Mettez à jour chaque type de version qui contient la version concernée, pas seulement la production: canaux de test ouvert, fermé et interne compris.
- Importez l’app bundle corrigé et désactivez ceux qui ne sont pas conformes. Google avertit que si vous ne les désactivez pas, la nouvelle soumission échoue et les versions en ligne peuvent être supprimées.
- Dans chaque canal concerné, sélectionnez Gérer le canal puis Créer une version, ajoutez le bundle corrigé (ou supprimez un brouillon qui contient le bundle en infraction), et vérifiez que la version non conforme figure sous Non incluses.
- Enregistrez, sélectionnez Examiner la version, puis déployez-la.
Ensuite, la modification attend d’être traitée. Google indique: "Le traitement peut prendre quelques heures ou jusqu’à sept jours (voire plus dans des cas exceptionnels)" (Contrôler quand les modifications de l’application sont examinées et publiées).
Corrigée, mais l’avertissement est toujours là
Si une version corrigée est en ligne et que l’état des règles affiche toujours le problème, comparez les codes de version et les canaux nommés par l’avertissement avec ce qui est actif aujourd’hui: un bundle non conforme resté sur un canal de test est la première chose à écarter. Une version plus récente n’efface pas automatiquement chaque mesure d’application. Si tout concorde, contactez l’assistance Play Console avec les codes de version, les canaux concernés et toute référence de dossier antérieure.
Faire appel de la décision
Google rétablit les applications lorsqu’il a commis une erreur et constate que l’application n’enfreint pas ses règlements. Pour faire appel, suivez les instructions de l’e-mail de mesure d’application ou utilisez le formulaire d’appel de Google. Vous pouvez déposer un appel par mesure d’application (Gérer les violations des règles et les appels), et Google répond aux appels en chinois, anglais, japonais et coréen. Google ne publie aucun délai de réponse pour les appels, et les témoignages de développeurs mélangent réponses d’appel et examens de versions ultérieures: prévoyez donc sans date.
Rédigez l’appel comme un dossier de preuves, pas comme l’expression d’une frustration: le code de version examiné, l’appareil et la version d’Android utilisés pour vos tests, les étapes exactes, un enregistrement d’écran du parcours que nomme l’avis, et ce que vous avez modifié, le cas échéant.
Un refus Broken Functionality nuit-il à votre compte ou à votre test fermé?
Un refus à lui seul n’affecte pas la réputation de votre compte de développeur. Des refus répétés peuvent entraîner une suspension, et les suspensions comptent comme des avertissements: corrigez donc avant de soumettre à nouveau. L’effet d’un refus sur un test fermé en cours n’est pas documenté.
La page Processus d’application des règles de Google expose la différence:
- "Les refus n’ont aucun impact sur la réputation de votre compte de développeur Google Play."
- "Si une mise à jour d’une application existante a été refusée, la version de l’application publiée avant la mise à jour restera disponible sur Google Play."
- "Une suspension peut résulter de violations graves ou multiples des règles, ainsi que de refus ou de suppressions répétés d’applications."
Google ne publie aucun nombre de refus sans risque. Soumettre à nouveau la même défaillance correspond exactement au schéma que décrit la troisième ligne.
Et le test fermé de 14 jours?
L’exigence de test de Google demande aux comptes personnels créés après le 13 novembre 2023 au moins 12 testeurs inscrits sans interruption depuis au moins 14 jours avant de demander un accès en production. Elle ne dit pas si le refus d’une version d’un canal fermé au titre d’un règlement remet à zéro, suspend ou conserve cette période, et les affirmations des forums dans un sens ou dans l’autre ne sont que des suppositions. Ce que vous pouvez vérifier: si vos testeurs disposent toujours d’une version approuvée sur le canal, et ce que le tableau de bord indique sur l’accès en production. Gardez vos testeurs inscrits pendant la correction, et interrogez l’assistance Play Console sur votre cas si le tableau de bord change. La règle elle-même est expliquée dans ce que signifient 14 jours consécutifs.
Google refusera-t-il une application WebView ou TWA pour dysfonctionnement?
Pas à cause de la technologie. Google documente à la fois les Trusted Web Activities et WebView pour les applications Android, et aucun règlement n’interdit cette architecture. Les questions sont de savoir si l’application fonctionne, si elle a suffisamment d’utilité, et si vous avez le droit d’encapsuler le site Web.
Nous n’autorisons pas les applications dont l’objectif principal est de générer du trafic affilié vers un site Web ou de fournir une WebView d’un site Web sans l’autorisation de son propriétaire ou de son administrateur.
Pour une application Web, les vérifications Broken Functionality sont les mêmes que pour toute autre application: le site doit se charger dans l’application dès une installation vierge, les états hors ligne et d’erreur doivent s’expliquer d’eux-mêmes, et chaque lien doit mener quelque part. Si l’application n’est en grande partie qu’une vue mince d’un site Web, c’est la section Limited Functionality and Content qui présente le plus grand risque. Passer d’une TWA à une WebView, ou l’inverse, n’a pas été démontré comme corrigeant un refus à lui seul.
Comment PrimeTestLab vous aide-t-il avant le prochain examen?
Nous ne pouvons pas corriger votre code ni changer la décision de Google. Nous fournissons le volet test: de vraies personnes sur de vrais appareils qui utilisent votre application via votre test fermé, pour que des problèmes comme ceux décrits plus haut apparaissent dans leurs commentaires avant qu’un examinateur ne les trouve.
PrimeTestLab fournit au moins 12 vrais testeurs sur de vrais appareils couvrant Android 7 à 17, inscrits pendant les 14 jours complets, avec un démarrage des tests sous 4-6 heures. Nous avons mené des tests gérés pour 12 100+ applications avec des testeurs dans 120+ pays.
Tests par vos propres moyens ou tests gérés
| Tâche | Par vous-même | Avec PrimeTestLab |
|---|---|---|
| Trouver des testeurs | Par vous-mêmeAmis, groupes et forums, souvent avec des téléphones similaires | Avec PrimeTestLabDe vrais testeurs sur de vrais appareils, affectés à votre application |
| Diversité d’appareils et de versions d’Android | Par vous-mêmeCe que possèdent vos bénévoles | Avec PrimeTestLabDes appareils couvrant Android 7 à 17 |
| Utilisation quotidienne et commentaires | Par vous-mêmeDépend de la bonne volonté | Avec PrimeTestLabLes testeurs utilisent l’application et signalent ce qui ne fonctionne pas |
| Garder 12 testeurs inscrits pendant 14 jours | Par vous-mêmeVous relancez vous-même les abandons | Avec PrimeTestLabLes abandons sont remplacés pour maintenir le nombre |
| Corriger le code et répondre à l’avis | Par vous-mêmeVous | Avec PrimeTestLabToujours vous; nous rapportons ce que les testeurs ont trouvé |
| La décision de Google | Par vous-mêmeGoogle | Avec PrimeTestLabToujours Google; personne ne peut promettre l’approbation |
Si Google n’a pas accordé l’accès en production après votre test PrimeTestLab complet, vous choisissez entre un nouveau test gratuit et un remboursement intégral; consultez la politique de remboursement et de nouveau test gratuit. Cela couvre l’exigence de test, pas un refus de votre code au titre d’un règlement. Les plans commencent à $19.99 plus 5% de frais de service au paiement (minimum $1.50), et les frais d’inscription uniques de 25 USD de Google sont à part. Comparez les plans sur la page des tarifs.
Questions fréquentes
Qu’est-ce que le règlement Broken Functionality sur Google Play?
C’est une section du règlement Google Play "Fonctionnalités, contenu et expérience utilisateur". Google n’autorise pas les applications qui plantent, se ferment de force, se figent ou fonctionnent anormalement de toute autre manière, et cite comme violations courantes les applications qui ne s’installent pas, celles qui s’installent mais ne se chargent pas, et celles qui se chargent mais ne répondent pas.
Broken Functionality est-il la même chose que Minimum Functionality?
Non. Minimum Functionality est l’ancien nom de ce que Google appelle désormais Limited Functionality and Content, qui couvre les applications ayant trop peu d’utilité ou de contenu. Broken Functionality couvre les applications qui ne fonctionnent pas telles qu’elles ont été soumises. Les deux relèvent du même règlement, mais se corrigent différemment.
Où ajouter des identifiants de démonstration pour l’examen Google Play?
Dans Play Console, allez dans Règles et programmes, puis Contenu de l’application, puis Informations de connexion (anciennement Accès à l’application). Sélectionnez Commencer ou Gérer, ajoutez les instructions et enregistrez, puis envoyez la modification pour examen depuis la page Aperçu de la publication. Les identifiants doivent être réutilisables et ne doivent pas dépendre d’un code à usage unique envoyé sur votre téléphone.
Un refus compte-t-il comme un avertissement sur mon compte de développeur?
Google indique que les refus n’ont aucun impact sur la réputation de votre compte de développeur. Les suspensions comptent comme des avertissements, et Google cite les refus ou suppressions répétés d’applications parmi les motifs de suspension: corrigez donc le problème cité avant de soumettre à nouveau.
Combien de temps prend l’examen après une nouvelle soumission d’une application corrigée?
Google indique que le traitement des modifications d’une application peut prendre quelques heures ou jusqu’à sept jours, voire plus dans des cas exceptionnels. Il s’agit de l’examen de la version corrigée. Google ne publie aucun délai de réponse pour les appels.
Peut-on faire appel d’un refus Broken Functionality?
Oui, si vous pensez que le constat est erroné. Suivez les instructions de l’e-mail de mesure d’application ou utilisez le formulaire d’appel de Google. Vous pouvez déposer un appel par mesure d’application, alors joignez le code de version examiné, l’appareil et les étapes que vous avez testés, ainsi qu’un enregistrement du parcours que nomme l’avis.
Un refus Broken Functionality remet-il à zéro mon test fermé de 14 jours?
Google ne le documente pas. Son exigence est d’au moins 12 testeurs inscrits sans interruption depuis au moins 14 jours avant de demander un accès en production. Gardez vos testeurs inscrits pendant que vous corrigez la version, surveillez le tableau de bord et interrogez l’assistance Play Console si votre éligibilité change.
Pourquoi mon application a-t-elle été refusée si elle fonctionne sur mon téléphone?
Votre téléphone couvre une version, un compte, un jeu de données et un réseau. Installez la version distribuée par Play sur un appareil vierge avec un nouveau compte, puis testez les contenus vides et les requêtes réseau en échec. Une version du Store signée avec la clé de signature d’application peut échouer là où votre version de debug fonctionne: testez donc la version que l’examinateur a installée.
Mon application utilise Google Sign-In ou un code à usage unique. Que fournir aux examinateurs?
Google exige des informations de connexion réutilisables, qui fonctionnent depuis n’importe quel lieu et contournent les mots de passe à usage unique ou la validation en deux étapes. Donnez aux examinateurs un compte de test et des instructions qui donnent accès à chaque fonctionnalité restreinte, y compris les fonctionnalités payantes. Testez ensuite vous-même les informations exactes que vous avez fournies; expliquer comment un utilisateur normal reçoit un code ne constitue pas un accès fonctionnel.
Google n’a envoyé ni capture d’écran ni journal de plantage. Que faire?
Consultez l’état des règles et l’e-mail de mesure d’application pour connaître la version concernée et les détails éventuels ajoutés par Google. Reproduisez ensuite le parcours principal sur la version soumise et enregistrez votre propre vidéo et vos propres journaux. Une page Android vitals ou un rapport pré-lancement sans erreur ne prouve pas que chaque écran et chaque requête backend ont fonctionné pour l’examinateur.
Les applications TWA et WebView sont-elles automatiquement refusées?
Non. Google documente ces deux technologies et aucun règlement ne les interdit. Google restreint en revanche les applications qui encapsulent un site Web sans l’autorisation de son propriétaire et les applications qui offrent trop peu de fonctionnalités ou de contenu. Diagnostiquez la défaillance réelle, par exemple des erreurs de connexion, de navigation ou de réseau; passer d’une technologie d’encapsulation à l’autre n’est pas une correction documentée.
L’essentiel à retenir
L’essentiel
Un refus Broken Functionality indique que la version examinée par Google ne fonctionnait pas: elle a planté, s’est figée, ne s’est pas chargée ou n’a pas répondu. Lisez quel règlement l’avis cite, reproduisez le problème sur la version distribuée par Play, vérifiez que les examinateurs peuvent se connecter grâce aux Informations de connexion, testez le backend depuis l’extérieur de votre réseau, et faites en sorte que chaque commande et chaque écran vide s’explique. Corrigez chaque canal concerné et envoyez la version corrigée pour examen. Ne faites appel qu’avec des preuves que le constat était erroné. Un refus seul n’est pas un avertissement, mais des nouvelles soumissions répétées sans correction peuvent en entraîner un.
Si vous voulez que de vraies personnes sur de vrais appareils trouvent l’écran défaillant avant le prochain examinateur, PrimeTestLab prend en charge le volet test fermé pendant que vous corrigez l’application.
Documentation officielle de Google
Ce qui peut changer sur cette page
- Les libellés de Play Console évoluent. Informations de connexion s’appelait Accès à l’application jusqu’à récemment, et certaines pages d’aide traduites utilisent encore l’ancien nom.
- Le texte des avis n’est pas publié sous forme de modèle et varie d’un cas à l’autre; fiez-vous à votre propre e-mail et à votre page État des règles plutôt qu’à tout exemple cité ici.
- Google ne documente pas l’effet d’un refus au titre d’un règlement sur un test fermé en cours. S’il publie une règle, cette page la suivra.
Sources vérifiées le 16 octobre 2026.