Rapport de pré-lancement Google Play : quoi corriger avant le test fermé et la production

Le rapport de pré-lancement est l’un des contrôles les plus utiles de Play Console et l’un des moins exploités par les nouveaux développeurs. Après l’import d’un bundle, Google peut installer l’application sur un ensemble d’appareils de laboratoire, l’ouvrir et effectuer automatiquement des actions comme toucher, saisir du texte et faire défiler les écrans.

Le résultat ne remplace ni vos tests techniques ni les 12 testeurs humains. Il complète le test fermé en cherchant des problèmes sur des appareils, versions Android et configurations que votre petit groupe ne possède peut-être pas.

Où trouver le rapport

Dans Play Console, ouvrez Tester et publier > Tests > Rapport de pré-lancement. La page d’ensemble affiche les erreurs, avertissements et problèmes mineurs, puis les détails par appareil.

Google teste notamment quatre familles de problèmes :

• stabilité ;
• compatibilité Android ;
• performance ;
• accessibilité.

Le rapport est généré automatiquement selon la capacité du laboratoire. Il arrive souvent après l’import d’un nouvel App Bundle, mais ce n’est pas une promesse d’exécution immédiate sur chaque artefact.

Priorité 1 : crashes et ANR

Un crash ferme l’application. Un ANR correspond à une interface qui ne répond plus, souvent parce qu’un travail trop lourd bloque le thread principal. Dans le rapport, ouvrez la trace, notez l’appareil, la version Android, l’ABI et l’étape visible sur la vidéo ou la capture.

Corrigez d’abord les problèmes reproductibles sur le lancement, la connexion et la fonction principale. Si une erreur n’apparaît que sur un modèle, recherchez la différence de version Android, mémoire ou architecture avant de l’ignorer.

Priorité 2 : blocage de connexion ou du robot

Le crawler ne peut pas tester ce qu’il ne peut pas atteindre. Si votre app exige un compte, fournissez des identifiants de test dans les paramètres du rapport. Créez un compte dédié avec des données fictives et les droits strictement nécessaires.

Google précise que les identifiants ne peuvent pas toujours être saisis automatiquement dans les contrôles personnalisés, les interfaces OpenGL ou certains flux WebView. Dans ce cas, le rapport peut signaler un problème de crawl alors que l’application fonctionne pour un humain. Ajoutez un test personnalisé ou complétez avec une vérification manuelle.

Priorité 3 : performance et compatibilité

Les avertissements peuvent révéler un démarrage lent, des temps de chargement, des problèmes de mémoire ou l’utilisation d’API non prises en charge. Comparez les appareils concernés : un comportement acceptable sur un téléphone haut de gamme peut devenir bloquant avec moins de RAM ou une version Android différente.

Les consignes de qualité Android recommandent aussi de tester la dernière version publique d’Android, les changements de réseau, le passage en arrière-plan, le verrouillage de l’écran et les interruptions comme les appels ou notifications.

Priorité 4 : accessibilité

Les problèmes mineurs ne sont pas toujours mineurs pour l’utilisateur. Le rapport peut détecter des libellés manquants, un contraste insuffisant ou des zones tactiles trop petites. Corrigez en priorité les contrôles du parcours principal, puis demandez à un testeur humain d’utiliser TalkBack et une taille de police agrandie.

Lire les couleurs sans suivre aveuglément la recommandation

Le rouge indique une erreur, le jaune un avertissement et le vert l’absence de problème détecté dans le scénario exécuté. Vert ne signifie pas que l’application est exempte de bugs : Google indique clairement que le rapport ne peut pas garantir de trouver tous les problèmes.

Pour chaque alerte, classez-la ainsi :

1. reproductible et bloquante ;
2. reproductible mais contournable ;
3. liée au robot ou à l’environnement de laboratoire ;
4. non reproduite, à surveiller sur les appareils humains.

Intégrer le rapport aux 14 jours

Lancez une première analyse avant de recruter largement afin d’éviter d’envoyer une version qui plante dès l’ouverture. Publiez ensuite les correctifs sur la même piste fermée et utilisez les 12 testeurs pour vérifier les parcours réels, la compréhension et les cas que le robot ne sait pas juger.

Conservez dans votre tableau : numéro de version, problème du rapport, correction, appareil de validation et retour humain associé. Cette combinaison fournit une réponse solide à la question « comment avez-vous déterminé que l’application était prête pour la production ? »

Le rapport automatique trouve les symptômes techniques ; les testeurs expliquent leur impact. Utilisez les deux avant de suivre notre guide après les 12 testeurs : demander l’accès production.