Règles Google Play en 2026 : checklist avant publication

Le calendrier vient avant la fiche du store

Les problèmes les plus pénibles sur Google Play ne ressemblent pas toujours à une infraction flagrante. La version est prête, les captures sont validées, puis on découvre qu'un SDK contredit la rubrique Sécurité des données ou que le compte de démonstration attend un code inaccessible à l'équipe de contrôle. Un détail suffit alors à rouvrir plusieurs chantiers.

Voilà pourquoi les règles du store ne sont pas une formalité de fin de projet. Elles touchent au produit : suppression du compte, localisation, paiement d'un service numérique, modération ou accès à une zone réservée. Les découvrir au moment de téléverser le fichier oblige souvent à reprendre le développement, les textes et la fiche en même temps.

Cette checklist a été vérifiée le 8 septembre 2026. Les échéances évoluent : le responsable de publication doit donc consulter les sources à la fin de l'article avant chaque version. Le principe de fond reste le même : partir du comportement réel du paquet signé, puis aligner tous les documents et toutes les réponses de Play Console.

Un compte personnel récent n'accède pas forcément immédiatement à la production. Pour les comptes créés après le 13 novembre 2023, Google demande en général un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs, puis une demande d'accès à la production. Un groupe recruté uniquement pour cocher la case apporte peu. Donnez-lui des parcours à réaliser, un moyen de signaler un problème et une nouvelle version à vérifier.

Le 31 août 2026 marque l'autre échéance majeure. À partir de cette date, les nouvelles applications et mises à jour pour téléphone et tablette doivent normalement cibler Android 16, niveau d'API 36 ou supérieur. Wear OS et Android Automotive utilisent le niveau 35 ; Android TV et Android XR le niveau 34. Les anciennes apps sont soumises à une condition distincte pour rester visibles auprès de nouveaux utilisateurs. La page officielle de l'API cible fait foi.

La prochaine étape de vérification des développeurs Android commence le 30 septembre 2026, sans constituer une échéance universelle. Le déploiement régional concerne d'abord le Brésil, l'Indonésie, Singapour et la Thaïlande, pour les boutiques participantes sur les appareils certifiés à partir d'Android 7. L'extension mondiale est prévue en 2027. Vérifiez l'état du package dans Play Console sans présumer que l'enregistrement automatique a tout réglé.

Construire un dossier de preuve unique

Les incohérences apparaissent lorsque chaque métier conserve sa propre image du produit. Les développeurs connaissent les autorisations, le marketing rédige la description, un conseil prépare la politique et le propriétaire du compte remplit Sécurité des données de mémoire. Tout peut sembler juste séparément et raconter une autre histoire une fois réuni.

Nous préférons un dossier de sortie très simple, vérifié sur la version signée et confié à une personne identifiée. Il suffit de réunir les faits suivants :

Associez ce dossier à un numéro de version. L'ajout tardif d'un outil d'attribution ou de publicité oblige à revoir les réponses. Le retrait d'une fonctionnalité implique aussi le retrait des visuels qui la présentent.

Remplir Sécurité des données à partir des flux réels

La politique de confidentialité est une explication publique. Sécurité des données est une déclaration structurée affichée sur Google Play. Ces deux contenus doivent s'accorder, mais aucun ne peut être rédigé sérieusement sans examiner l'application.

Listez les données d'inscription, les événements analytiques, les rapports de plantage, les identifiants d'appareil, la position, les fichiers, le support et l'état des paiements. Ajoutez chaque SDK : mesure d'audience, attribution, publicité, cartographie, chat ou diagnostic. L'éditeur reste responsable de ce que ces composants collectent dans sa version.

Précisez la finalité. Une adresse utilisée pour se connecter n'est pas équivalente à une adresse envoyée à un outil de prospection. Notez si la donnée quitte l'appareil, si elle est facultative, comment elle est transmise et comment elle sera supprimée. Conserver cet inventaire avec la version évite de tout redécouvrir à la mise à jour suivante.

Notre article sur la politique de confidentialité d'une application détaille cette mise en cohérence. Une app de santé, de finance, destinée aux enfants ou liée à l'identité nécessite en plus une analyse juridique adaptée aux pays de diffusion.

La suppression du compte n'est pas un simple lien

Lorsqu'un utilisateur peut créer son compte dans l'app, Google Play exige un chemin de suppression dans l'application et une ressource web accessible depuis l'extérieur. L'adresse générale du support ne suffit pas si elle ne conduit pas clairement à la demande.

Créez un compte puis supprimez-le réellement. Le réglage est-il facile à trouver ? La page web nomme-t-elle l'application et l'éditeur ? Explique-t-elle les données effacées, les éventuelles données conservées et leur durée ? Le backend traite-t-il aussi l'authentification, les fichiers, le CRM, le support et les outils marketing ?

Une facture, une commande en cours ou un litige peuvent justifier une conservation partielle. Ce cas doit être décrit par le produit et validé par la personne compétente, puis traduit techniquement dans tous les systèmes concernés.

Limiter les autorisations au besoin immédiat

Comparez le manifeste Android, les demandes affichées à l'écran et les déclarations de Play Console. Supprimez les accès hérités d'un ancien SDK ou d'une fonction abandonnée. Pour chaque autorisation sensible, l'équipe doit pouvoir dire quelle action concrète ne fonctionnerait pas sans elle.

Choisissez l'outil le plus ciblé. Le sélecteur de photos convient souvent mieux qu'un accès général aux médias. Sélectionner une personne pour une invitation ne justifie pas forcément la lecture de tout le carnet d'adresses. Le suivi continu d'un livreur peut exiger une position persistante ; trouver un commerce proche à un instant donné, non.

Google a annoncé pour fin octobre 2026 de nouvelles règles relatives aux contacts et à la localisation précise, ainsi que des contrôles préalables supplémentaires. Les apps visant Android 17 doivent étudier en amont Contact Picker et le bouton de localisation. Pour le stockage sécurisé, les droits côté serveur et les secrets, consultez la checklist de sécurité Android.

Donner à Google un accès stable, sans intervention humaine

Toute fonction cachée derrière une connexion, un abonnement, une zone géographique ou un rôle doit rester accessible pendant l'examen. Les identifiants fournis doivent être réutilisables, fonctionner depuis n'importe quel pays et ne pas expirer. Un code SMS ponctuel, une offre d'essai terminée ou un serveur limité à une adresse IP interne bloquent le contrôle.

Ajoutez un parcours en anglais : connexion, sélection du bon profil, ouverture de la fonction principale, accès au contenu payant et action de test. Si l'interface est en français, indiquez le libellé exact des boutons entre parenthèses.

La meilleure vérification consiste à confier ce parcours à une personne extérieure au projet sur un appareil propre. Si elle doit appeler le développeur, les instructions ne sont pas autonomes.

Une fiche fidèle vaut mieux qu'une promesse spectaculaire

La règle sur les métadonnées concerne chaque langue publiée. Nom, descriptions, icône, visuel de présentation, captures et vidéo doivent montrer les fonctions de la version disponible. Évitez les récompenses invérifiables, les formulations absolues et l'accumulation artificielle de mots-clés.

Les captures peuvent être mises en scène, mais l'écran et le résultat présentés doivent exister. Localisez le texte intégré aux images et contrôlez devise, dates et conditions d'achat. Les formats de captures Google Play et la checklist de localisation permettent de préparer ce travail en amont.

Pour relire la fiche, cherchez à démontrer chaque affirmation dans l'app. Le prix et la durée d'un abonnement sont-ils visibles avant l'achat ? Une opération manuelle n'est-elle pas présentée comme instantanée ? Une capture ne montre-t-elle pas une fonction prévue seulement pour la prochaine phase ?

Les déclarations particulières suivent le produit

Play Console adapte les questions à l'activité : publicité, audience, classement par âge, actualités, santé, services financiers, lien avec un organisme public ou autre domaine sensible. Choisir une catégorie plus pratique n'efface pas les obligations ; cela crée une mauvaise déclaration.

Le contenu publié par les utilisateurs demande des règles, un signalement, un blocage et une modération effectivement prise en charge. Une audience enfant déclenche les règles Families. Les apps de santé et de finance doivent contrôler précisément leurs affirmations. Pour la vente de fonctionnalités ou contenus numériques, la politique de paiement et ses exceptions applicables doivent être étudiées avant de concevoir le parcours de règlement.

Ce travail compte dans le périmètre. Un chat privé implique signalement, blocage, visibilité pour le support et règles de conservation. Un abonnement exige restauration, résiliation, états d'accès et tests d'achat. Le questionnaire d'estimation Appfyl permet de faire apparaître ces dépendances avant le devis.

Tester le paquet signé qui sera envoyé

La version de développement ne suffit pas. Installez le bundle signé, relié à une infrastructure proche de la production. Parcourez première installation, mise à jour, inscription, récupération, suppression, refus des autorisations, réseau faible, achat ou réservation, liens profonds et chaque rôle donné à Google. Vérifiez qu'un paiement de test ne peut pas produire un débit réel.

Les contrôles préalables de Play Console sont utiles, mais ils ne couvrent qu'une partie des règles. Pour les plantages, blocages, appareils et parcours, complétez avec la checklist qualité Google Play et la checklist de tests mobiles.

Organiser les dernières 48 heures

Deux jours avant l'envoi, arrêtez d'ajouter des SDK facultatifs et de nouvelles promesses commerciales. Le premier jour, la technique valide package, signature, API cible, autorisations, SDK, suppression et compte de test. Le produit contrôle paiements, rôles, modération et déclarations spécifiques. Le marketing compare chaque texte et image avec la version installée.

Le second jour, une personne indépendante exécute le parcours destiné à Google. Le responsable ouvre chaque lien public, rapproche Sécurité des données de l'inventaire des SDK, archive les déclarations et confirme la maîtrise du compte éditeur.

Gardez une marge dans la date de lancement : la durée d'examen n'est pas garantie. La checklist de lancement mobile ajoute l'analytique, le support et la surveillance des premiers jours. En cas de refus déjà reçu, utilisez le guide de correction des rejets avant toute nouvelle soumission.

Un exemple de preuve de préparation

Pour une application fictive de réservation, notez le numéro de version technique, le package et la date du test. Consignez un constat précis : « La suppression du compte est accessible dans les réglages, mais le lien public mène à la connexion ». Attribuez la correction au responsable du site. Le point reste ouvert tant que les informations requises ne sont pas accessibles sans compte. Une simple case « confidentialité terminée » masquerait le problème.

Appliquez la même méthode à l'accès de l'équipe de vérification. Notez qu'une installation neuve ouvre un cours payant de démonstration avec le compte prévu, sans code à usage unique ni débit réel. Si une modification du serveur invalide ce compte, l'ancien test ne prouve plus la préparation. Rejouez le scénario concerné et gardez le résultat.

Cette liste aide à décider de l'envoi, sans garantir l'approbation. Conservez l'identifiant de la version testée avec les points ouverts. Lors d'un échange avec Appfyl, précisez aussi qui tiendra ces preuves à jour après les modifications.

Questions fréquentes