Chapitre 13.5 — Publication & review
Où on en est : test fermé validé, accès production accordé. Le dernier guichet : la release de production, la review Google, et — statistiquement probable un jour — le rejet et sa gestion.
⏱️ TL;DR — Promouvoir la release vers Production → review Google : mélange d’automatique et d’humain, quelques heures à 7 jours (comptez 2-3 j la première fois). Les motifs de rejet fréquents sont ÉVITABLES : Data Safety incohérent, politique de confidentialité manquante, permissions non justifiées, métadonnées trompeuses. Un rejet n’est pas un drame : lire le motif exact, corriger, resoumettre. Publier en staged rollout même à 100 % ? Non — le rollout progressif sert les MISES À JOUR (ch. 13.6) ; la v1 part entière.
🎯 Objectifs
- Dérouler la promotion vers la production (et les derniers réglages : pays, rollout).
- Savoir ce que la review vérifie réellement (et ses délais honnêtes).
- Connaître le top des motifs de rejet et leur prévention.
- Gérer un rejet : lecture, correction, resoumission, escalade.
La release de production
Console → Production → créer la release : le même AAB (promouvoir depuis la piste fermée — pas de re-build), les notes de version (« Nouveautés » — visibles sur la fiche, 500 c., soignez-les), puis les réglages de diffusion :
- Pays : tous, ou une liste. Pour Drill : tous (l’app est en français — le store filtre peu par langue, et un dev anglophone curieux ne gêne personne). Une app aux contraintes légales (paris, santé…) choisirait.
- Rollout : 100 % pour une v1 (personne n’a l’app — le progressif n’a de sens qu’en mise à jour, ch. 13.6).
« Envoyer pour examen » — et l’attente commence.
Ce que la review vérifie
Un pipeline mixte : analyse automatique (le binaire : malware, APIs interdites, permissions vs déclarations, SDK connus) + revue humaine par échantillonnage (la fiche, le contenu, la cohérence des déclarations — renforcée pour les nouvelles apps et les catégories sensibles).
Délais honnêtes (2026) : quelques heures à 7 jours ; première app d’un compte neuf : comptez 2-3 jours, parfois plus. Chaque MISE À JOUR repasse en review (généralement plus vite). On ne planifie donc JAMAIS une sortie « ce soir » — le buffer d’une semaine est la règle professionnelle.
Le top des rejets évitables
| Motif | Prévention (déjà faite si vous avez suivi) |
|---|---|
| Data Safety incohérent (le binaire contacte des tiers non déclarés) | Drill ne contacte que GitHub — formulaire vide cohérent (ch. 13.3) |
| Politique de confidentialité manquante/inaccessible | L’URL GitHub Pages (ch. 13.3) |
| Permissions non justifiées (demandées « au cas où ») | Le rituel du ch. 9.1 — Drill n’a que les notifications |
| Métadonnées trompeuses (mots-clés bourrés, screenshots mensongers) | La fiche honnête du ch. 13.3 |
| App cassée au premier lancement (crash, écran blanc) | Le test interne + fermé — et l’offline-first (7.4) qui évite le classique « crash sans réseau » |
| Contenu (droits, marques) | « Drill » générique, vos propres questions — attention seulement aux logos de technos dans les assets (les wordmarks Symfony/PHP dans des SCREENSHOTS d’usage sont tolérés ; dans l’ICÔNE, non) |
La ligne de fond : les rejets frappent l’à-peu-près (déclarations bâclées, fiche approximative) — la rigueur des chapitres précédents EST la prévention.
Gérer un rejet
- Lire le mail réel (et la section « État de la publication » de la Console) : le motif cite la politique précise violée — pas de panique interprétative, la référence est là.
- Corriger exactement ça (binaire, fiche ou déclaration selon le cas).
- Resoumettre — la re-review est généralement plus rapide.
- Si le motif semble erroné (ça arrive) : le formulaire d’appel (lien dans le mail), factuel et poli — les appels documentés aboutissent.
- Ce qu’on ne fait JAMAIS : resoumettre sans changement « pour voir » (les récidives s’aggravent), ou créer une nouvelle app pour contourner (suspension).
Et le jour J : l’app apparaît dans la recherche quelques heures après l’approbation
(l’indexation prend son temps — le lien direct play.google.com/store/apps/details?id=com.alex.drill
fonctionne immédiatement, lui). Partagez le lien, encaissez le moment — c’est mérité.
⚠️ Piège — La review teste l’app SANS votre contexte : un compte de test si l’app exige un login (champ dédié dans la Console — Drill n’en a pas), et surtout une app qui fonctionne SANS instructions. Si un reviewer ouvre Drill dans un labo sans WiFi stable… notre offline-first (ch. 7.4) répond présent. Les apps qui affichent un spinner infini au premier lancement sans réseau sont un classique du rejet « broken functionality ».
💡 Pour un dev Next.js — Psychologiquement, la review est un déploiement dont le « CI » appartient à quelqu’un d’autre et dure des jours. Intégrez-la au rythme : les fixs urgents entre deux reviews passent… par OTA (ch. 12.5 — les mises à jour JS ne repassent PAS par la review, l’un des super-pouvoirs d’Expo sur le Store, dans les limites des politiques Google : pas de changement « trompeur » du comportement déclaré).
✏️ Exercices
1. Faites l’audit pré-soumission de Drill contre le tableau des rejets : pour chaque ligne, OÙ est la preuve de conformité (chapitre + artefact) ?
✅ Solution
Data Safety : formulaire « aucune collecte » (13.3) + le code (seul fetch = GitHub, 7.2). Privacy : URL GitHub Pages en ligne (13.3). Permissions : POST_NOTIFICATIONS seule, flux 9.1/9.2. Métadonnées : fiche 13.3 sans superlatifs mensongers. Robustesse : matrice offline 7.4 + rituel 12.2. Contenu : icône sans wordmark tiers (12.1). Un tableau de conformité de 6 lignes — à recopier pour chaque app.
2. Écrivez les « Nouveautés » (notes de version) de la v1.0 ET d’une future v1.1 — deux registres différents.
✅ Solution
v1.0 : présentation, pas « bug fixes » (« Première version ! Quiz chronométrés sur Symfony, PHP, Next.js et Bootstrap · records et stats · défi quotidien · 100 % hors ligne »). v1.1 : concret et daté (« Nouveau : mode révision des questions ratées · timer configurable jusqu’à 60 s · corrections de stabilité »). Les notes sont lues par les utilisateurs ET la review — « minor fixes » à chaque version est un anti-pattern (et un signal de fiche négligée).
3. Simulation de rejet : « Votre app demande la permission CAMERA sans fonctionnalité correspondante visible. » Vous n’utilisez pas la caméra. D’où ça sort, et le fix ?
✅ Solution
Une dépendance a déclaré la permission dans SON manifest (fusion des manifests au build) —
le suspect : une lib installée « pour plus tard » ou une transitive. Diagnostic : lire le
manifest fusionné (prebuild → AndroidManifest.xml, ch. 11.4) et npx expo config --type introspect. Fix : retirer la lib inutilisée, ou bloquer la permission explicitement
(android.blockedPermissions dans app.config.ts — l’outil Expo dédié à ce cas exact).
Resoumettre avec la note « permission retirée ».
🧠 Quiz
1. Quels sont les délais de review réalistes ?
Réponse
De quelques heures à 7 jours — 2-3 jours typiques pour une première app. Chaque mise à jour binaire repasse en review. Corollaire : buffer d’une semaine, jamais de sortie « ce soir ».
2. Citez quatre motifs de rejet évitables et leur prévention.
Réponse
Data Safety incohérent (déclarer juste), privacy policy manquante (URL statique), permissions injustifiées (n’avoir que le nécessaire + blockedPermissions), métadonnées trompeuses (fiche honnête), app cassée sans réseau (offline-first).
3. Que fait-on à réception d’un rejet ?
Réponse
Lire le motif EXACT (mail + Console, la politique est citée), corriger précisément, resoumettre ; appel documenté si le motif est erroné. Jamais de resoumission à l’identique ni de nouvelle app de contournement.
4. Les OTA EAS Update repassent-elles par la review ?
Réponse
Non — les mises à jour JS ne transitent pas par le Store (dans le respect des politiques : pas de bascule de comportement trompeuse). C’est l’arme des fixs urgents entre deux reviews.
5. Pourquoi le rollout progressif ne sert-il pas pour une v1 ?
Réponse
Il limite la casse d’une mise à jour sur une base INSTALLÉE — une v1 n’a pas d’utilisateurs à protéger : elle part à 100 %. Le staged rollout entre en scène au ch. 13.6.
👉 Chapitre suivant : 13.6 — Après la publication — la vie d’une app publiée : updates, rollouts, avis, vitals.