Une app par ville ou par agence
« Acme Paris », « Acme Lyon » et « Acme Marseille », avec les mêmes fonctionnalités et seulement une URL de départ différente.
Ce que dit la règle sur le contenu répétitif
Le contenu répétitif (Repetitive Content) est une section des règles de Google Play relatives au spam. Son idée centrale est simple : une app ne doit pas se contenter d'offrir la même expérience que des apps déjà présentes sur Google Play. Les exemples de Google sont la copie de contenu d'autres apps sans ajout de contenu original ni de valeur, et la publication de plusieurs apps aux fonctionnalités, contenus et expériences utilisateur très similaires. Lorsque chacune de ces apps n'a que peu de contenu, Google suggère de créer une seule app qui le regroupe.
Les modèles ont un passé dans ces règles. Quand Google a durci ses règles anti-spam en 2018, il a ajouté une formulation visant les apps générées par un outil automatisé, un service d'assistant ou un modèle, et soumises par l'opérateur de ce service pour le compte d'autres personnes. Une entreprise qui publie sa propre app basée sur un modèle dans son propre compte n'était pas la cible. Le texte actuel du Centre de règles se concentre sur la similarité plutôt que sur la manière dont une app a été construite, vérifiez-le donc avant de faire appel, mais la leçon pratique n'a pas changé : le problème n'est pas le modèle, c'est la ressemblance, tout comme un seul compte qui publie des apps quasi identiques pour de nombreux propriétaires.
Comment la notification est généralement formulée
L'e-mail de refus ou de retrait fait référence aux règles relatives au spam et nomme le contenu répétitif (Repetitive Content), parfois avec d'autres apps de votre compte, ou d'ailleurs sur Google Play, que l'examinateur a jugées trop semblables. Il peut bloquer une nouvelle app à l'examen, ou arriver plus tard sous forme de notification de retrait pour des apps déjà en ligne, souvent pour plusieurs d'entre elles à la fois.
Les infractions liées au spam comptent pour l'état de votre compte. Répétées, elles peuvent passer des refus aux retraits d'apps et, au pire, à la résiliation du compte développeur. Prenez la première notification comme une raison de nettoyer tout le compte, pas seulement l'app citée. Si une app a déjà été retirée, le guide sur les apps retirées ou suspendues explique les étapes suivantes.
Les schémas qui le déclenchent
Un compte d'agence rempli d'apps clients
Vingt apps de restaurants ou de salles de sport issues d'un même modèle, publiées sous le compte développeur de l'agence, avec la même mise en page et le même style de captures d'écran.
Des jumelles Free et Pro
Deux fiches au contenu identique, l'une avec publicité, l'autre sans. Cela relève d'une seule app avec un achat in-app.
La republication
Une app refusée ou retirée, republiée sous un nouveau nom de package avec des changements minimes. Les examinateurs font le lien.
Des restes du modèle
Menus de démonstration, photos de banque d'images, espaces réservés « Votre entreprise » ou les mêmes articles de blog d'exemple dans chaque app construite à partir du même projet de départ.
Des fiches copiées-collées
La même description et les mêmes captures d'écran d'une app à l'autre, seul le nom changeant. Des fiches semblables font paraître les apps identiques, même quand le contenu diffère.
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 :-)
Une app ou plusieurs ?
| Situation | Configuration recommandée | Pourquoi |
|---|---|---|
| Une marque, plusieurs sites | Une app avec un choix de site ou une sélection automatique selon la position | Même propriétaire, même produit : des apps séparées sont le cas d'école du contenu répétitif |
| Franchise avec des propriétaires indépendants | Une app gérée par le franchiseur, ou des apps séparées uniquement là où un propriétaire a un contenu propre substantiel et publie dans son propre compte | C'est la propriété et le contenu qui comptent, pas le logo |
| Agence qui crée des apps pour des clients sans lien entre eux | Chaque client a son propre compte développeur et sa propre app, qui charge son propre domaine | Propriétaire, produit et public différents pour chaque app, et le compte correspond à l'entreprise |
| Plateforme SaaS qui donne « une app » à chaque client | Une seule app conteneur où les utilisateurs se connectent à leur organisation, sauf si un client a un produit entièrement à sa marque | Des centaines de coquilles quasi identiques, c'est exactement ce que décrivent les règles |
| Version gratuite et version payante | Une app avec un achat in-app ou un abonnement | Deux fiches au même contenu comptent comme des doublons |
| Langues ou pays différents | Une app avec des fiches du store traduites ; WebViewGold peut transmettre la langue du système à votre app web avec APPEND_LANG_CODE | Les traductions et la disponibilité par pays se gèrent dans une seule fiche |
Nettoyer et se différencier avant de soumettre à nouveau
Commencez par le compte, puis travaillez sur chaque app.
Listez chaque app du compte
Ouvrez Toutes les applications dans la Play Console et regroupez les apps qui partagent fonctionnalités et mise en page. Dépubliez les apps de test, les expériences abandonnées et tout ce qui n'existe que parce qu'une version antérieure a été refusée.
Regroupez quand un propriétaire a plusieurs apps semblables
Fusionnez les variantes par ville, par agence ou gratuite et Pro en une seule app. Gardez le nom de package qui a le plus d'utilisateurs, indiquez aux utilisateurs des autres apps où aller dans une dernière mise à jour, puis dépubliez ces apps.
Déplacez les apps clients vers les comptes des clients
Pour le travail en marque blanche, l'entreprise du client doit être propriétaire du compte développeur, validé avec ses propres informations. La Play Console dispose d'une procédure de transfert d'apps pour déplacer les apps existantes, et vous pouvez être invité comme utilisateur dans le compte du client. Le guide sur la validation du compte couvre ce dont le client a besoin.
Rendez chaque app restante clairement unique
Nom propre, icône propre, captures d'écran du vrai contenu de cette entreprise, description rédigée pour son public, et le domaine du client dans Config.java. Utilisez des fonctionnalités natives pour le cas d'usage réel du client : suivi des commandes par push, QR code de fidélité, écran hors ligne avec les horaires d'ouverture.
Supprimez les restes du modèle
Cherchez dans l'app web les textes de démonstration, les produits d'exemple, les images de banque d'images et les pages juridiques provisoires. Un examinateur qui trouve le même contenu d'exemple dans deux apps n'a pas besoin de chercher plus loin.
Soumettez à nouveau, ou faites appel avec des faits précis
Si l'app a été refusée alors qu'elle est vraiment différente, faites appel et expliquez ce qui la distingue : propriétaire, public, contenu et fonctionnalités. Une déclaration générale affirmant que l'app est unique n'aide pas.
La marque blanche avec WebViewGold : la configuration qui tient
WebViewGold est en marque blanche : l'app finale porte le nom et l'icône de votre client, pas les nôtres, et charge le domaine que vous indiquez dans Config.java. Cela la rend idéale pour les agences, et cela signifie aussi que la différenciation doit venir du produit du client. Trois règles évitent les ennuis aux agences :
- Un propriétaire par app. Chaque app publiée appartient à une vraie entreprise avec son propre contenu et ses propres utilisateurs. Chaque app personnalisée a aussi besoin de sa propre licence WebViewGold, comme l'indique la documentation d'installation.
- Le propriétaire publie. Publiez depuis le compte développeur du client, dans lequel vous travaillez comme utilisateur invité avec les autorisations dont vous avez besoin.
- Une vraie valeur native par client. Notifications push, scan de QR codes, écran hors ligne ou App Links configurés pour ce client, pas une liste de fonctionnalités copiée du dernier projet.
Si vous gérez de nombreux projets clients et préférez ne pas construire chacun vous-même, l'équipe Full Service configure et compile chaque app individuellement. Apple applique une règle similaire sous un autre nom ; le guide sur la guideline 4.3 couvre le côté iOS.
Modèle d'appel : pourquoi l'app n'est pas du contenu répétitif
Donnez des faits, pas des adjectifs. L'examinateur doit voir en une minute un propriétaire, un public et un contenu différents. Le modèle reste en anglais, car les examinateurs de Google lisent l'anglais.
À coller dans le formulaire d'appel, puis à adapter
Hello Google Play team, [App name] ([package name]) was rejected under the Repetitive Content section of the Spam policy. We believe the app provides a distinct experience and would like to explain why. Owner: The app belongs to [business name], which runs [domain] and publishes from its own developer account ([account name]). Audience: [who uses it, for example the members of our gym in (city)]. Content unique to this app: [own catalogue, member accounts, bookings, community posts, ...]. Native features used for this product: [push notifications for booking reminders, QR check-in at the front desk, ...]. Difference from [app named in the notice, if any]: [owner, content and features that differ]. [If you consolidated or changed something: We have also (unpublished X, merged Y into this app, replaced the template content).] A demo account is available under App access: [username] / [password]. Kind regards, [name]
Checklist de nettoyage du compte
- Aucune paire d'apps du compte ne partage les mêmes fonctionnalités, la même mise en page et le même contenu.
- Les variantes par ville, par agence et gratuite ou Pro sont fusionnées en une seule app.
- Chaque app client est publiée depuis le compte développeur du client.
- Chaque app a son propre nom, sa propre icône, ses propres captures d'écran et sa propre description, rédigée pour son public.
- Aucun contenu de démonstration, espace réservé de banque d'images ou page juridique d'exemple ne reste du modèle.
- Chaque app utilise au moins une fonctionnalité native pour quelque chose de propre à cette entreprise.
Questions fréquentes
Est-ce un problème que beaucoup d'apps sur Google Play soient construites avec WebViewGold ?
Non. Les règles portent sur les apps qui offrent la même expérience, pas sur la technologie sous-jacente. Beaucoup d'apps sans lien entre elles construites avec la même boîte à outils ne sont pas du contenu répétitif ; deux apps du même propriétaire avec le même contenu, si.
Puis-je publier la même app pour deux pays sous forme de deux fiches ?
Utilisez une seule app. Google Play vous permet de traduire la fiche et de choisir les pays pour chaque app, et votre app web peut changer de langue et de contenu selon la région.
Mon agence peut-elle publier les apps de ses clients dans son propre compte développeur ?
C'est possible, mais c'est la configuration qui ressemble le plus à du spam de modèles, et elle lie chaque app client à l'état de votre compte. Publier depuis le compte de chaque client est plus sûr et laisse le client maître de son app.
Un nouveau nom de package fera-t-il passer mon app refusée ?
En général non, et cela aggrave la situation. Republier une app refusée avec des changements minimes est l'un des schémas que visent les règles. Corrigez la cause, puis soumettez à nouveau la même app.
Une autre palette de couleurs rend-elle une app unique ?
Non. La couleur, le logo et le nom sont le strict minimum. Ce qui compte, c'est un contenu différent, un propriétaire et un public différents, et des fonctionnalités natives utilisées pour ce produit précis.
Trois façons de mettre votre app dans les stores
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.
Faites-le vous-même
$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 principaleCloud Builder
$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 gratuiteFull Service
$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.