Publier sur Google Play en 2026 implique bien plus que téléverser une version. Le compte doit être vérifié, l'application doit respecter les exigences techniques de cette année, la fiche doit suivre les règles relatives aux métadonnées, une douzaine de déclarations de contenu doivent être remplies avec exactitude, et les nouveaux comptes personnels doivent effectuer un test fermé de deux semaines avant de pouvoir publier. Voici la séquence complète, dans l'ordre qui évite les reprises.
1. Choisir le bon compte développeur
Un compte développeur Google Play coûte des frais d'inscription uniques de 25 USD et existe en deux types, dont le choix a des conséquences pendant des années :
| Question | Compte personnel | Compte d'organisation |
|---|---|---|
| À qui s'adresse-t-il ? | Un développeur individuel | Une entreprise enregistrée |
| Vérification de l'identité | Pièce d'identité officielle | Numéro D-U-N-S et informations sur l'organisation |
| Nom affiché sur la fiche | Le nom personnel vérifié | Le nom de l'organisation |
| Test fermé avant la première publication | Obligatoire pour les comptes créés après le 13 novembre 2023 : au moins 12 testeurs pendant 14 jours consécutifs | Non requis |
Pour une application professionnelle, ouvrez un compte d'organisation au nom propre de l'entreprise. Une application placée sur le compte personnel d'un fondateur ou sur le compte d'une agence est un problème de propriété en attente, et depuis septembre 2026 chaque application est également enregistrée auprès de l'identité vérifiée du compte qui la détient : voir Vérification des développeurs Android. L'obtention d'un numéro D-U-N-S peut prendre plusieurs semaines : demandez-le au début du projet, et non à la fin.
2. Exigences techniques en 2026
- Android App Bundle et Play App Signing. Les nouvelles applications sont téléversées sous forme d'app bundles et signées via Play App Signing. Conservez une sauvegarde de la clé de téléversement et documentez son propriétaire.
- Niveau d'API cible. À partir du 31 août 2026, les nouvelles applications et les mises à jour d'applications doivent cibler Android 16 (niveau d'API 36). Les applications Wear OS et Android Automotive OS doivent cibler l'API 35, et les applications Android TV et Android XR l'API 34. Une extension jusqu'au 1er novembre 2026 peut être demandée dans Play Console. Les applications existantes doivent cibler au moins l'API 35 pour rester disponibles aux nouveaux utilisateurs sur les appareils exécutant des versions plus récentes d'Android.
- Pages mémoire de 16 Ko. Depuis le 1er novembre 2025, les dernières extensions ayant expiré le 31 mai 2026, les nouvelles applications et les mises à jour qui ciblent Android 15 ou une version ultérieure doivent prendre en charge des tailles de page de 16 Ko sur les appareils 64 bits. Cela est important lorsque l'application ou l'une de ses bibliothèques contient du code natif : reconstruisez avec les outils actuels et vérifiez chaque bibliothèque native tierce.
- Vérification des développeurs. Chaque application doit être enregistrée auprès d'un développeur vérifié ; les applications publiées via Play Console sont normalement enregistrées automatiquement.
3. La fiche sur le Play Store
| Élément | Exigence |
|---|---|
| Nom de l'application | Jusqu'à 30 caractères |
| Description courte | Jusqu'à 80 caractères |
| Description complète | Jusqu'à 4,000 caractères |
| Icône de l'application | PNG 512 × 512, 32 bits avec alpha, jusqu'à 1 Mo |
| Illustration de présentation | 1024 × 500, JPEG ou PNG 24 bits |
| Captures d'écran | Au moins deux ; jusqu'à huit par type d'appareil ; JPEG ou PNG 24 bits ; chaque côté entre 320 et 3,840 pixels, le côté long ne dépassant pas deux fois le côté court |
La politique relative aux métadonnées est la cause de nombreux échecs des premières fiches. Le nom de l'application, l'icône et le nom du développeur ne doivent pas contenir de mots ou de badges relatifs au classement, au prix ou à la promotion (« meilleur », « #1 », « gratuit », « promotion »), et les descriptions ne doivent pas accumuler les mots-clés, citer des témoignages anonymes ni promettre des fonctionnalités que l'application ne possède pas. Les captures d'écran doivent montrer l'application réelle.
4. Déclarations relatives au contenu de l'application
Dans Play Console, la section Contenu de l'application recueille des déclarations que les évaluateurs confrontent à l'application. Celles qui s'affichent dépendent des fonctions de l'application ; voici celles que presque toutes les applications doivent remplir :
- Règles de confidentialité : une URL active, également accessible depuis l'application, qui décrit ce que l'application collecte réellement.
- Sécurité des données : les données collectées et partagées, leurs finalités et la manière dont elles sont protégées. Cette déclaration doit inclure les données collectées par les bibliothèques intégrées à l'application, et pas uniquement par votre propre code.
- Annonces : indiquez si l'application affiche des publicités.
- Public cible et contenu : les tranches d'âge visées par l'application. Le fait d'inclure des enfants entraîne l'application des exigences de la politique Familles.
- Classification du contenu : le questionnaire de classification. Les applications non classifiées ne sont pas autorisées sur Google Play.
- Suppression du compte : si les utilisateurs peuvent créer un compte dans l'application, ils doivent pouvoir demander la suppression du compte et de ses données à la fois dans l'application et via un lien web.
- Autorisations sensibles : les déclarations et justifications relatives aux autorisations telles que les SMS et le journal des appels, la localisation en arrière-plan, l'accès à tous les fichiers et les alarmes exactes, ainsi qu'aux types de services de premier plan.
- Autres déclarations le cas échéant : fonctionnalités financières, fonctionnalités de santé, actualités, applications gouvernementales, etc.
Répondez à ces questions à partir d'un inventaire écrit de ce que font l'application et ses bibliothèques, et non de mémoire. Les incohérences entre les déclarations et le comportement constituent l'un des moyens les plus fiables d'être refusé.
5. Pistes de test
| Piste | Utilisation |
|---|---|
| Test interne | Jusqu'à 100 testeurs, disponibilité rapide ; pour votre propre équipe |
| Test fermé | Testeurs invités ; piste utilisée pour l'exigence des 12 testeurs sur les nouveaux comptes personnels |
| Test ouvert | N'importe qui peut participer depuis la fiche ; utile pour les versions bêta de plus grande ampleur |
| Production | Tout le monde, avec déploiement progressif facultatif par pourcentage |
Chaque version disponible sur une piste de test reçoit également un rapport de pré-lancement issu de tests automatisés sur des appareils réels. Consultez-le avant de promouvoir une version : les plantages, problèmes d'accessibilité et avertissements de sécurité qui y sont détectés coûtent moins cher à corriger qu'un refus en production.
6. Examen et publication
Les délais d'examen varient. Les premières soumissions et les nouveaux comptes prennent souvent plus de temps que les mises à jour courantes, parfois plusieurs jours, et les applications appartenant à des catégories sensibles prennent encore plus de temps. Deux contrôles réduisent la plupart des risques liés au calendrier :
- La publication gérée permet de laisser une version approuvée en attente jusqu'à ce que vous choisissiez de la publier, afin qu'une date marketing ne dépende pas de la file d'attente de l'évaluateur.
- Le déploiement progressif diffuse d'abord une nouvelle version à un pourcentage d'utilisateurs, afin qu'un problème n'atteigne que quelques utilisateurs plutôt que la totalité.
Si l'application est refusée, la raison est indiquée dans la section État des règles de Play Console, avec la règle concernée. Corrigez la cause, répondez ou soumettez à nouveau l'application, et conservez les éléments attestant de la modification. Les motifs de refus que nous rencontrons le plus souvent, et la manière de les éviter, sont suffisamment généraux pour s'appliquer aux deux stores : les refus prévisibles.
7. La checklist complète
- Compte d'organisation au nom propre de l'entreprise ; demande de numéro D-U-N-S effectuée suffisamment tôt
- Clé de téléversement sauvegardée ; propriétaire documenté
- API cible 36 pour les nouvelles applications et les mises à jour ; prise en charge de 16 Ko pour le code natif
- Textes de la fiche conformes aux limites et exempts d'allégations de classement, de prix et de promotion
- Icône, illustration de présentation et captures d'écran aux dimensions requises, montrant l'application réelle
- Règles de confidentialité actives et liées dans l'application
- Réponses relatives à la sécurité des données fondées sur un inventaire écrit des données, bibliothèques comprises
- Suppression du compte disponible dans l'application et sur le web, si des comptes existent
- Classification du contenu, public cible, annonces et déclarations relatives aux autorisations remplis
- Test fermé effectué lorsque le type de compte l'exige
- Rapport de pré-lancement examiné ; publication gérée activée pour la première version
Services Manboo associés
- Développement d'applications Android, notamment la configuration de Play Console, les pistes de publication et les déclarations relatives aux règles.
- Développement d'applications iOS, notamment App Store Connect, TestFlight et la préparation à l'examen de l'App Store.
- Développement d'applications Flutter lorsqu'une seule base de code doit réussir les examens des deux stores.
- Maintenance logicielle pour les applications existantes nécessitant des mises à jour de l'API cible, du SDK ou des règles.
- Demander l'examen du périmètre et un devis pour le lancement sur un store ou une soumission refusée.