Refus Google Play
Google veut que les utilisateurs apprennent dans l'app, avant toute demande d'autorisation, quelles données vous collectez et pourquoi. Si une demande de localisation, de contacts ou de caméra apparaît sans cette explication, ou si votre explication ne figure que dans la politique de confidentialité, la version est refusée. La solution est une courte boîte de dialogue dans votre app web, affichée juste avant la demande native.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les règles de Google sur les données utilisateur (User Data policy) contiennent une exigence précise pour les usages de données auxquels un utilisateur ne s'attend pas forcément. Lorsque votre app accède à des données personnelles ou sensibles, les collecte, les utilise ou les partage d'une manière qui peut dépasser ce que l'utilisateur attend raisonnablement de la fonctionnalité qu'il a sous les yeux, vous devez d'abord afficher une information dans l'app (prominent disclosure, que Google traduit par « communiqué visible »), puis demander le consentement.
L'information doit se trouver dans l'app et faire partie de l'utilisation normale, pas cachée dans un menu de réglages, la description du store ou la politique de confidentialité. Elle doit indiquer quelles données sont concernées et comment elles sont utilisées et partagées, et ne doit pas être noyée dans un texte sans rapport comme vos conditions d'utilisation. Le consentement exige une action explicite, comme toucher un bouton clairement libellé ; toucher à côté, appuyer sur Retour ou un message qui disparaît tout seul ne compte pas. Quand une autorisation d'exécution est en jeu, l'information vient avant la demande du système. Les bonnes pratiques de Google pour l'information bien visible ajoutent des détails pratiques : commencez par le pourquoi, listez les données, écrivez simplement, proposez un moyen de refuser et n'imitez pas les boîtes de dialogue du système Android.
L'information ne remplace ni votre politique de confidentialité ni le formulaire Sécurité des données. Les trois doivent décrire la même réalité.
L'entrée dans État des règles cite les règles sur les données utilisateur et leur exigence d'information bien visible, souvent avec le type de données que l'examinateur a remarqué : localisation, contacts, images, apps installées ou identifiant d'appareil. Parmi les titres que les développeurs signalent souvent figurent Prominent disclosure not found et Missing information in prominent disclosure. Le premier signifie que l'examinateur a vu une demande d'autorisation ou un flux de données sans aucune explication préalable. Le second signifie qu'une explication existe mais qu'il lui manque quelque chose : en général le mot « localisation », la mention de l'arrière-plan pour un accès en arrière-plan, ou ce qu'il advient des données. La capture d'écran montre souvent la boîte de dialogue d'autorisation du système dès le tout premier écran de l'app.
Votre page d'accueil appelle l'API de géolocalisation au chargement, si bien qu'Android demande la localisation avant que l'utilisateur ait vu quoi que ce soit. Rien n'explique pourquoi. C'est l'infraction type.
Par défaut, WebViewGold demande l'autorisation de notifications au premier lancement (requirePush). Ce n'est pas en soi un problème de données personnelles, mais une série de demandes avant tout contexte est exactement ce que les examinateurs capturent. Placez chaque demande dans son contexte.
L'API de contacts (requestcontactpermission://, puis readcontacts://) transmet le carnet d'adresses à votre app web. L'importer pour « trouver des amis » exige une information qui nomme les contacts et leur envoi.
Un import que l'utilisateur lance depuis un champ de fichier est attendu. Importer des images en arrière-plan ou les utiliser pour autre chose que la fonctionnalité visible ne l'est pas et exige une information.
Le session replay, le fingerprinting, les widgets de chat et les balises d'analytics tournent dans la WebView et comptent comme une collecte de données de votre app. Si un script enregistre les saisies ou construit un profil d'appareil, informez-en l'utilisateur ou gardez-le hors de l'app.
Avec une bonne version optimisée de votre application Web, vous pouvez avoir une superbe application mobile en quelques minutes. De plus, le service client est très agréable et très utile! Je ne peux que recommander WebViewGold :-)
| Données | Afficher l'information | Elle doit indiquer |
|---|---|---|
| Localisation pendant que l'app est ouverte | Sur l'écran de la fonctionnalité, juste avant l'appel de géolocalisation | Que l'app collecte la localisation, pour quelle fonctionnalité, et si elle est envoyée à votre serveur ou partagée |
| Localisation en arrière-plan | Avant la demande de localisation, dans la fonctionnalité qui en a besoin | Le mot localisation, une formule comme « lorsque l'app est fermée ou non utilisée », chaque fonctionnalité qui l'utilise et si elle sert à la publicité ; voir le guide sur la localisation en arrière-plan |
| Contacts | Avant requestcontactpermission:// | Quels champs sont importés (noms, numéros, e-mails), pourquoi, combien de temps vous les conservez et qui d'autre les reçoit |
| Photos, caméra, micro | Avant la première capture ou le premier import, dès que l'usage n'est pas évident | Ce qui est capturé ou importé et où cela va |
| Données collectées par des scripts | Avant le démarrage du script, en général au premier lancement | Ce qui est collecté (par exemple des enregistrements d'écran ou des données d'appareil), par qui et pourquoi, avec une vraie possibilité de refuser |
Surtout du travail sur l'app web ; un nouveau build natif n'est nécessaire que si vous modifiez Config.java.
Installez le build de test sur une installation neuve, notez chaque demande du système et l'écran où elle apparaît, et listez ce que votre app web envoie à votre backend ou à des tiers. Comparez la liste avec vos réponses dans Sécurité des données.
Retirez les appels de géolocalisation du chargement de la page et déclenchez-les depuis un bouton sur l'écran de la fonctionnalité. Pour le push, mettez requirePush sur false dans Config.java et demandez l'autorisation plus tard avec registerpush://, comme le décrit la documentation push pour Android.
Une fenêtre modale dans votre app web avec un titre simple, les données, la raison et ce qu'il advient des données, plus deux boutons : Accepter et Plus tard. Gardez votre propre design ; n'imitez pas la boîte de dialogue d'autorisation d'Android.
Appelez alors l'API de géolocalisation, requestcontactpermission:// ou registerpush://. La demande du système qui suit est la seconde étape, l'étape officielle.
La fonctionnalité doit continuer à fonctionner sous une forme réduite, par exemple avec la saisie manuelle d'une adresse au lieu de la localisation. Si l'utilisateur veut plus tard la fonctionnalité et que l'autorisation a été refusée définitivement, ouvrez l'écran du système avec settingsapp:// (API Open App Settings).
Mettez à jour la politique de confidentialité et le formulaire Sécurité des données pour qu'ils correspondent. Si seule votre app web a changé, le build existant montre déjà le correctif ; si la Play Console demande une nouvelle version, augmentez le code de version et importez un nouveau bundle. Décrivez dans votre réponse le chemin jusqu'à l'information.
Un modèle pour toute app web qui tourne dans WebViewGold. Remplacez showModal par votre propre composant de dialogue et adaptez les textes à ce que fait réellement votre app.
// Chaque entrée : ce que vous dites à l'utilisateur, et l'étape native lancée après « Accepter ».
const DISCLOSURES = {
location: {
title: "Afficher les magasins près de chez vous ?",
body: "Pour lister les points de retrait les plus proches, cette app collecte votre position précise pendant que vous utilisez la recherche de magasins. Elle est envoyée à notre serveur uniquement pour calculer les distances et n'est jamais partagée avec des annonceurs.",
run: () => navigator.geolocation.getCurrentPosition(showNearby, showManualSearch)
},
contacts: {
title: "Retrouver vos amis parmi vos contacts ?",
body: "Cette app envoie à notre serveur les noms et numéros de téléphone de vos contacts pour montrer quels amis l'utilisent déjà. Nous n'envoyons jamais de message à vos contacts et supprimons sous 24 heures les numéros sans correspondance.",
// Après l'autorisation, naviguez vers readcontacts:// pour remplir la variable contacts.
run: () => { window.location.href = "requestcontactpermission://"; }
},
notifications: {
title: "Recevoir le suivi de vos commandes ?",
body: "Nous envoyons une notification quand votre commande est expédiée et quand elle arrive. Vous pouvez désactiver cela à tout moment.",
run: () => { window.location.href = "registerpush://"; }
}
};
function askWithDisclosure(kind) {
const d = DISCLOSURES[kind];
showModal({
title: d.title,
body: d.body,
primary: { label: "Accepter", onClick: d.run },
secondary: { label: "Plus tard", onClick: () => {} } // la fonctionnalité continue de marcher sans
});
}
// À déclencher par une action de l'utilisateur sur l'écran de la fonctionnalité, jamais au chargement de la page.
document.querySelector("#find-stores").addEventListener("click", () => askWithDisclosure("location"));L'agent trouve chaque flux de données, ajoute les boîtes de dialogue et vous fournit les phrases pour la politique de confidentialité et le formulaire Sécurité des données.
Mon app web tourne dans une app Android créée avec WebViewGold. Google Play l'a refusée pour une information bien visible (prominent disclosure) manquante. Trouve chaque endroit où l'app (a) appelle navigator.geolocation, (b) navigue vers requestcontactpermission://, readcontacts:// ou registerpush://, (c) envoie des contacts, des photos ou la localisation à notre backend ou à un tiers, (d) charge des scripts d'analytics, de session replay ou de chat. Pour chaque élément : - Supprime tout appel exécuté au chargement de la page ; déclenche-le plutôt depuis une action de l'utilisateur sur l'écran de la fonctionnalité. - Avant l'appel, affiche une fenêtre modale de notre design system avec un titre court, les données collectées, pourquoi, où elles sont envoyées, et deux boutons : Accepter et Plus tard. - N'exécute l'appel qu'après Accepter. Avec Plus tard, garde la fonctionnalité utilisable sous une forme réduite. - Ne donne pas à la fenêtre modale l'apparence d'une boîte de dialogue du système Android. Rédige ensuite un tableau de chaque type de données, de l'écran où il est annoncé et de la phrase exacte utilisée, pour que je puisse la copier dans la politique de confidentialité et le formulaire Sécurité des données.
Non. La boîte de dialogue du système demande l'autorisation, mais ne dit rien de ce que vous faites des données. Google veut votre propre explication avant elle chaque fois que l'usage n'est pas évident, et toujours pour la localisation en arrière-plan.
Oui. Une boîte de dialogue affichée par votre app web dans la WebView est une interface de l'app. Ce qui compte, c'est qu'elle apparaisse pendant l'utilisation normale, juste avant l'accès aux données, et pas seulement sur une page de réglages ou une page juridique.
Quand la demande d'autorisation d'Android suit immédiatement, les consignes de Google sur la localisation en arrière-plan considèrent cette demande comme l'étape de consentement. Pour les données qu'aucune demande du système ne protège, il vous faut votre propre consentement explicite. Une paire claire Accepter et Plus tard est le design le plus sûr dans les deux cas et correspond aux bonnes pratiques de Google.
Affichez-la avant la première demande pour chaque type de données, puis à nouveau quand l'utilisateur lance la fonctionnalité après avoir refusé. Respectez un refus ; des demandes répétées agacent autant les utilisateurs que les examinateurs.
Parce que les règles l'exigent dans l'app, avant l'accès aux données. La politique de confidentialité et la fiche sont des exigences supplémentaires, pas des substituts.
Apple procède autrement, avec des textes d'objectif (purpose strings) dans la demande du système et ses propres règles de confidentialité. La même boîte de dialogue en contexte fonctionne bien sur les deux plateformes, et le côté App Store est couvert dans le guide sur la guideline 5.1.1.
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.