Dans ce guide
Le rapport de pré-lancement est une série de tests automatisés que Google Play exécute sur ton build avant publication. Il ne demande aucune configuration de ta part, il vaut donc la peine d'être lu à chaque fois. Il est aussi facile à mal interpréter : c'est un robot, pas un utilisateur.
Ce qu'il fait
Selon la page d'aide de la Play Console de Google, le rapport recherche les problèmes de stabilité, de compatibilité Android, de performance et d'accessibilité. Il se lance quand tu envoies un bundle d'application ou un APK, et quand tu enregistres une version en production. L'appli est lancée sur des appareils du laboratoire de test de Google. Un robot d'exploration tape, saisit et balaie pendant plusieurs minutes. Ensuite, les résultats sont compilés.
Détails de la même page qui influencent ta lecture :
- Les résultats arrivent en général dans l'heure qui suit l'envoi. Si un rapport n'est pas complet après deux jours, renvoie le build.
- Les appareils de test tournent sous Android 9 ou plus récent, et incluent des téléphones, des tablettes, Wear OS et des appareils de type ordinateur. Android Automotive OS et Android TV ne peuvent pas être testés.
- Les appareils sont situés aux États-Unis et fonctionnent en portrait par défaut.
- Tu peux ajouter jusqu'à trois liens profonds comme points d'entrée supplémentaires, des identifiants de compte de test, un script Robo ou une boucle de jeu, et choisir jusqu'à cinq langues.
- Les applis sans activité de lancement principale ne peuvent pas être testées (Google cite les lanceurs, widgets, claviers et cadrans de montre).
Le périmètre évolue avec le temps. Ouvre la page actuelle avant de te fier à ces informations.
Ce qu'il ne voit pas
Le robot d'exploration ne connaît pas ton produit. Il ne peut pas juger si l'onboarding a du sens, si un prix est clair ou si le texte se lit bien. Il ne passe pas un écran de connexion sans identifiants. Tout ce qui se trouve derrière un paiement, un état rare ou une action dans le monde réel (une livraison, un appareil Bluetooth) est hors de sa portée.
Comment trier les constatations
Le résumé du rapport regroupe les problèmes en erreurs, avertissements et problèmes mineurs, et donne une recommandation de lancement. Utilise-le comme point de départ, pas comme verdict.
| Constatation | Quoi faire |
|---|---|
| Plantage avec une trace de pile dans ton code | Reproduis-le à la main. Si possible, corrige avant publication. |
| Plantage dans une bibliothèque tierce | Vérifie s'il touche un parcours réel ; mets la bibliothèque à jour si possible. |
| Plantage seulement après une action anormale du robot | Priorité plus basse, mais vérifie que l'appli gère les entrées bizarres sans perte de données. |
| Avertissement d'accessibilité (zone tactile, contraste, libellé manquant) | Généralement peu coûteux à corriger et utile. Vérifie sur ton propre appareil. |
| Avertissement de performance | Compare avec un téléphone milieu de gamme réel avant d'agir. |
| Mur de connexion, rien testé | Ajoute des identifiants de test et relance. |
Une règle simple : corrige ce que tu peux reproduire, note ce que tu ne peux pas reproduire, et n'ignore rien sans raison écrite.
À utiliser avec de vrais testeurs
Le rapport trouve vite les plantages et les défauts évidents sur un ensemble fixe d'appareils. Les gens, eux, trouvent les parcours confus, les formulations inexactes et les problèmes sur leurs propres téléphones. Utilise les deux. Pour l'aspect données terrain, voir les bases d'Android vitals ; pour la comparaison, voir tests sur appareils cloud et testeurs réels.
Fait partie du guide de test d'applis Android.
Besoin de vraies personnes pour essayer ton build ? Commence ici et obtiens des retours privés et structurés.