LaunchLint Academy
La réponse courte
- Une mise en production Google Play ne se résume pas au téléversement d’un Android App Bundle. La fiche, App content, Data safety, les tests, la signature et le déploiement doivent tous décrire le même build et résoudre les alertes bloquantes.
- Ce guide mène les équipes Expo et React Native d’une version candidate figée à un lancement contrôlé, avec preuves, responsabilités, critères d’arrêt et suivi opérationnel.
- Juste avant la production, organisez une répétition avec des rôles explicites. Une personne utilise la Play Console, une autre installe uniquement l’artefact du track prévu et une troisième surveille backend et monitoring. Partez d’un compte neuf, testez mise à jour et installation propre, provoquez au moins une erreur contrôlée et ouvrez support et confidentialité. Comparez ensuite l’app avec fiche, captures, Data safety et notes. Consignez heure, build, appareils, résultats et exceptions. Le candidat ne passe en production que si chaque écart possède un responsable et une décision explicite.
- Archivez uniquement des résultats vérifiables : statut de console, identifiant d’artefact, rapport de test, matrice approuvée et décision de rollout. N’ajoutez jamais clés, secrets de signature ou données personnelles. Vérifiez aussi qui peut modifier la production et retirez les droits temporaires après la sortie ; une release correcte reste fragile si trop de comptes peuvent la changer sans validation.
Figer le candidat et ses versions
Désignez un commit comme candidat, puis empêchez les changements silencieux de code, configuration ou dépendances natives. Code de version, nom, package et profil Expo EAS doivent identifier sans ambiguïté l’AAB généré.
Consignez somme de contrôle, lien, commit, heure et responsable. Les testeurs, la Play Console et l’équipe travaillent ainsi sur le même artefact reproductible.
Dossier de release
- Commit et versions enregistrés
- Profil et package vérifiés
- Somme et emplacement de l’AAB conservés
- Aucun changement tardif
- Responsable nommé
Vérifier le bundle et la signature
Google Play reçoit des Android App Bundles et crée des APK optimisés. Vérifiez le fichier choisi et la configuration de Play App Signing. Un problème de clé ou de package n’est pas une petite correction de métadonnées.
Avec Expo, contrôlez profil de production, identifiants et application ID avant le build. Ne changez jamais une clé dans l’urgence pour contourner une erreur de téléversement.
Bundle et signature
- Publier un AAB
- Contrôler Play App Signing
- Confirmer le package
- Inspecter l’artefact
- Protéger les identifiants
Réconcilier toute la fiche Play
Titre, descriptions, icône, feature graphic, captures, contact et confidentialité doivent être complets. Chaque promesse doit correspondre au candidat ; les images de prototype et fonctions retirées créent un risque de revue et de confiance.
Examinez chaque langue séparément. Une fiche par défaut complète peut masquer des ressources localisées anciennes. Suivez locale, ressource, responsable et date dans une matrice.
Fiche Play
- Textes fidèles
- Visuels actuels
- Liens valides
- Langues contrôlées
- Contact suivi
Terminer App content et Data safety
App content couvre politique de confidentialité, publicités, accès, audience, permissions, classification, Data safety et autres déclarations. Ce sont des affirmations publiques et importantes pour la revue.
Dérivez les réponses du code, de l’inventaire des SDK et des flux backend. Si un SDK traite des données, le formulaire doit le refléter. Le questionnaire ne remplace pas les preuves techniques.
App content
- Publicités et audience exactes
- Accès reviewer prêt
- Permissions expliquées
- Data safety vérifié
- Classification complète
Exploiter les tests internes et fermés
Le test interne permet des contrôles rapides ; un test fermé élargit appareils et usages. Installez la version distribuée par Play pour exercer signature, splits, mises à jour et contexte du store, pas seulement un debug local.
Fixez des critères pour premier démarrage, connexion, parcours principal, achats, permissions, liens profonds, hors-ligne et erreurs. Chaque bug mentionne build et appareil.
Couverture de test
- Installer via Play
- Tester installation et mise à jour
- Couvrir parcours et erreurs
- Vérifier achats et deep links
- Joindre build et appareil
Trier le rapport de pré-lancement
Le rapport de pré-lancement exécute le bundle sur des appareils et peut révéler stabilité, performance, accessibilité et sécurité. Il complète les tests métier sans les remplacer.
Classez chaque résultat : blocage reproductible, risque, limite connue ou faux positif. Documentez la décision, sinon les alertes ignorées se répètent et perdent leur valeur.
Triage
- Reproduire crash et ANR
- Évaluer performance et accessibilité
- Assigner la sécurité
- Expliquer les faux positifs
- Fermer les blocages
Contrôler la production
Créez la release lorsque fiche et App content sont complets et qu’aucune erreur bloquante ne subsiste. Les notes doivent décrire le changement réel.
Un déploiement progressif réduit l’impact d’un défaut inconnu. Définissez pourcentage initial, fenêtre, responsable et seuils d’arrêt avant d’avancer ; sans portes, il ne fait que ralentir une sortie totale.
Porte de production
- Aucune erreur bloquante
- Notes exactes
- Pourcentage et fenêtre définis
- Seuils d’arrêt fixés
- Owner autorisé à suspendre
Surveiller et documenter
Après publication, observez crashes, ANR, avis, support, erreurs backend et funnels critiques. Comparez à une référence connue pour séparer la variation normale d’une vraie régression.
Clôturez avec version, horaires, étapes, anomalies et actions. Cet historique accélère les sorties suivantes et met en évidence les incidents récurrents.
Exploitation
- Comparer aux références
- Suivre support et avis
- Contrôler backend et funnels
- Avancer après validation
- Capitaliser les leçons
Questions fréquentes
Faut-il un AAB ?
L’Android App Bundle est l’artefact standard ; Google Play génère ensuite des APK optimisés.
Un téléversement réussi suffit-il ?
Non. Fiche, App content, politiques, tests et erreurs bloquantes doivent aussi être traités.
Faut-il sortir immédiatement à 100 % ?
Pour une évolution importante, un déploiement progressif avec seuils définis limite le risque.
Le rapport remplace-t-il la QA manuelle ?
Non. Il ajoute des signaux appareils mais ne couvre pas tous les parcours métier.
Quel build les testeurs installent-ils ?
De préférence celui d’un track Play afin de tester la vraie signature, livraison et mise à jour.