Publier une application Expo sur Google Play : notre checklist

Pour publier une application Expo sur Google Play, il faut réunir quatre éléments : un Android App Bundle signé produit par EAS Build, une fiche d'application dans la Play Console vers laquelle EAS Submit peut envoyer les builds, une fiche Play Store complète (icône, image de présentation, captures d'écran, politique de confidentialité) et les déclarations exigées par Google, dont la suppression de compte dans l'application et sur le web, l'étape la plus souvent oubliée. Cette checklist suit l'ordre que nous avons suivi pour préparer l'application Android de Driveway Morocco, avec les obstacles rencontrés en chemin.

Driveway Morocco est la plateforme de location de voitures de ShipFastDev : une application web Laravel et une application mobile sous Expo SDK 57 qui consomme la même API JSON (voir l'étude de cas Driveway Morocco).

1. Fiabiliser la chaîne de build avant d'ouvrir la Play Console

EAS Build compile l'application dans le cloud d'Expo. La référence eas.json d'Expo décrit trois profils standard : development (un client de développement avec les outils de debug), preview (des builds proches de la production, installés directement sur les appareils de l'équipe) et production (les builds destinés au store). Pour Android, Expo recommande un fichier .aab pour Google Play et un .apk pour les builds preview.

Activez l'incrémentation automatique des numéros de version. Le guide de gestion des versions d'Expo rappelle qu'une cause fréquente de rejet est l'envoi d'un build avec un numéro de version déjà utilisé, et conseille de laisser EAS stocker la version à distance avec autoIncrement. Chez nous, le profil production incrémente le versionCode tout seul : personne n'a besoin d'y penser.

Nos premiers builds EAS ont échoué trois fois :

• Des fichiers ignorés par Git. assets/icon.png et les icônes adaptatives Android figuraient dans le .gitignore. Ils n'étaient donc jamais envoyés à EAS, et l'étape de prebuild plantait sur un ENOENT. Tout fichier référencé dans app.json doit être commité.
• Des dépendances natives désalignées. react-native-gesture-handler 3.1.0 avait une version majeure d'avance sur la ~2.32.0 attendue par le SDK 57, ce qui cassait le prebuild Android. npx expo install --fix a réaligné sept paquets. Lancez-le (ou npx expo-doctor) avant chaque build de release.
• Un slug différent. Le slug de app.json doit correspondre au projet EAS auquel il est lié, sinon eas build s'arrête sur une erreur de correspondance.

Vérifiez aussi le niveau d'API cible : selon la page de Google sur le niveau d'API cible, depuis le 31 août 2026, nouvelles applications et mises à jour doivent cibler Android 16 (niveau d'API 36) ou plus. Un projet Expo resté longtemps sans mise à niveau sera refusé.

2. Configurer EAS Submit et le canal de test interne

D'après le guide de soumission Google Play d'Expo, EAS Submit demande un compte développeur Play, une application créée dans la Play Console, le nom de paquet android.package dans app.json et une clé de compte de service Google enregistrée chez EAS. En intégration continue, la variable EXPO_TOKEN remplace la connexion interactive.

Deux choix que nous referions à l'identique :

• Donner au compte de service le strict nécessaire. Dans la Play Console, il a reçu les droits de publication (publier en production, exclure des appareils, utiliser la signature d'application Play) et non le rôle Admin, ce qui limite les dégâts possibles si la clé fuit.
• Soumettre d'abord sur le canal interne. Notre eas.json contient un profil de soumission avec track: internal. La page de Google sur les canaux de test indique que le test interne accepte jusqu'à 100 testeurs par application, que les versions leur parviennent en quelques minutes et que ces tests ne passent pas forcément par les examens habituels de règles et de sécurité. C'est le moyen le plus rapide de vérifier qu'un vrai build du store s'installe et dialogue avec l'API de production.

Si vous publiez depuis un nouveau compte développeur personnel, prévoyez une étape de plus. Les comptes créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits sans interruption pendant au moins 14 jours avant de pouvoir demander l'accès à la production, selon les exigences de test de Google. Ces deux semaines sont incompressibles : recrutez vos testeurs tôt.

Une fois le parcours manuel validé, nous l'avons automatisé. Un workflow GitHub Actions lance le build AAB de production sur EAS à chaque mise à jour de master (en ignorant les commits qui ne touchent qu'à la documentation ou aux captures), puis exécute eas submit --profile internal --latest. Le jeton Expo et le JSON du compte de service sont stockés dans les GitHub Secrets, jamais dans le dépôt.

3. Préparer les visuels de la fiche Play Store

Le guide des éléments graphiques de Google fixe les formats :

• Icône : 512 x 512 px, PNG 32 bits avec transparence, 1 024 Ko maximum. Nous l'avons redimensionnée à partir de l'icône de l'application.
• Image de présentation : 1 024 x 500 px, JPEG ou PNG 24 bits sans transparence.
• Captures d'écran : au moins deux, tous types d'appareils confondus, et jusqu'à huit par type d'appareil, entre 320 et 3 840 px, le grand côté ne dépassant pas le double du petit. Les nôtres font 1 080 x 1 920.
• Description courte : 80 caractères maximum. La nôtre en compte 77.

Montrez de vrais écrans, pas des maquettes. Nous avons capturé les nôtres sur un émulateur Android connecté à l'API de production, et il a fallu refaire le premier jeu : les écrans de détail et de paiement avaient été pris avant la fin du chargement. Les nouvelles prises passent par des scénarios Maestro qui vérifient d'abord que le contenu est visible, le même réflexe que dans nos tests Playwright en CI.

4. Publier une page de politique de confidentialité

Les règles de Google sur les données utilisateur exigent un lien vers la politique de confidentialité dans la Play Console et un lien ou le texte dans l'application. La page doit être accessible publiquement, sans restriction géographique, à une URL active (pas de PDF), et préciser qui vous êtes et comment vous joindre, quelles données l'application collecte et partage et avec qui, comment vous les protégez, et votre politique de conservation et de suppression. L'entité affichée sur la fiche Play Store, ou le nom de l'application, doit y figurer.

Nous avons ajouté une page /privacy au site Laravel, liée depuis le pied de page : une seule URL pour la fiche Play Store, l'application et le site. Rédigez-la à partir de ce que fait réellement l'application ; pour Driveway Morocco, les informations de compte et de réservation, les paiements traités par Stripe et les informations sur l'appareil utilisées pour les notifications.

5. Remplir honnêtement la section Sécurité des données

Toute application présente sur un canal fermé, ouvert ou de production doit remplir ce formulaire ; seules les applications cantonnées au test interne en sont dispensées, d'après le guide de la section Sécurité des données. Même une application qui ne collecte rien doit le compléter et fournir un lien vers sa politique de confidentialité. Le guide précise que le code tiers compte : il faut déclarer les données envoyées hors de l'appareil par les bibliothèques et SDK intégrés à l'application.

Passez en revue vos dépendances, pas seulement votre code : paiement, analytics, remontée de crashs, push. Nous avons déclaré les informations de paiement (gérées par Stripe) et l'adresse e-mail. Le formulaire demande aussi si l'utilisateur peut demander la suppression de ses données, ce qui nous amène à l'exigence qui piège la plupart des équipes.

6. La suppression de compte, dans l'application et sur le web

Si vos utilisateurs peuvent créer un compte depuis l'application, les exigences de Google sur la suppression de compte imposent un parcours dans l'application pour supprimer le compte et les données associées, ainsi qu'une page web où l'utilisateur peut en faire la demande. Le parcours doit être facile à trouver, par exemple dans les paramètres du compte. Supprimer un compte veut dire supprimer les données associées ; une conservation limitée reste permise pour la sécurité, la prévention de la fraude ou les obligations réglementaires, à condition de l'indiquer.

Sur Driveway Morocco, cela a représenté trois commits côté backend et un côté application :

• Une page publique /delete-account sur le site, liée depuis le pied de page : c'est la ressource web à renseigner dans la Play Console.
• Un endpoint DELETE /api/account, authentifié par jeton, qui redemande le mot de passe, révoque tous les jetons d'API de l'utilisateur et le supprime dans une transaction.
• Des clés étrangères qui font le ménage : avis, vérifications de permis, notifications, jetons push et rapports de dommages disparaissent avec l'utilisateur ; les réservations sont conservées avec une référence utilisateur mise à null, de sorte que la trace comptable reste sans être liée à une personne. Quatre tests couvrent le tout : authentification obligatoire, mauvais mot de passe, suppression avec révocation des jetons et anonymisation des réservations.
• Dans l'application, une action « Supprimer le compte » sur l'écran de profil ouvre une boîte de confirmation par mot de passe. En cas de succès, l'application efface la session locale et désinscrit l'appareil des notifications push. Les textes existent en français, en anglais et en arabe, comme le reste de l'application.

Fixez les règles de conservation avant d'écrire l'endpoint : listez les tables supprimées et celles qui sont anonymisées.

La checklist

1. Profils EAS development, preview et production ; la production génère un AAB avec un versionCode incrémenté automatiquement.
2. npx expo install --fix et expo-doctor passent ; tous les fichiers cités dans app.json sont commités.
3. Le niveau d'API cible respecte l'exigence actuelle de Google Play.
4. Application créée dans la Play Console ; compte de service limité aux droits de publication ; clé rangée dans les secrets de la CI.
5. Premier build sur le canal interne, installé et testé contre la production.
6. Nouveau compte personnel : test fermé de 12 testeurs pendant 14 jours planifié.
7. Icône 512 x 512, image de présentation 1 024 x 500, vraies captures prises après chargement des données, description courte sous 80 caractères.
8. Politique de confidentialité à une URL publique, liée dans la Play Console et dans l'application.
9. Section Sécurité des données qui couvre vos SDK autant que votre code.
10. Suppression de compte dans l'application et page web dédiée, règles de conservation écrites.

Vous hésitez encore sur la technologie mobile ? Lisez notre comparatif React Native ou Flutter.

Questions fréquentes

EAS Submit peut-il envoyer le tout premier build d'une nouvelle application ?

Le guide actuel d'Expo indique que la commande eas submit par défaut fonctionne pour une première soumission, dès que l'application existe dans la Play Console et que la clé du compte de service est configurée. Une voie manuelle est aussi documentée.

Faut-il une suppression de compte si les utilisateurs se connectent seulement avec Google ou Apple ?

La règle de Google s'applique dès que l'utilisateur peut créer un compte depuis l'application. Si la connexion Google ou Apple crée un utilisateur dans votre backend, considérez-le comme un compte et prévoyez le parcours dans l'application et la page web.

Combien de temps faut-il pour publier une application Expo sur Google Play ?

Une version en test interne arrive chez les testeurs en quelques minutes. Un nouveau compte personnel ajoute un test fermé d'au moins 12 testeurs pendant 14 jours avant l'accès à la production : comptez au moins deux semaines.

Le canal de test interne exige-t-il la section Sécurité des données ?

Non. Les applications présentes uniquement en test interne en sont dispensées ; le formulaire devient obligatoire dès le passage sur un canal fermé, ouvert ou de production.

Sources

1. Understanding Google Play's app account deletion requirements, Aide Google Play Console, consulté en octobre 2026
2. Provide information for Google Play's Data safety section, Aide Google Play Console, consulté en octobre 2026
3. User Data policy, Aide Google Play Console, consulté en octobre 2026
4. Set up an open, closed, or internal test, Aide Google Play Console, consulté en octobre 2026
5. App testing requirements for new personal developer accounts, Aide Google Play Console, consulté en octobre 2026
6. Add preview assets to showcase your app, Aide Google Play Console, consulté en octobre 2026
7. Meet Google Play's target API level requirement, Android Developers, consulté en octobre 2026
8. Submit to the Google Play Store, documentation Expo, consulté en octobre 2026
9. Configure EAS Build with eas.json, documentation Expo, consulté en octobre 2026
10. App version management, documentation Expo, consulté en octobre 2026