Ce qui se passe après avoir cliqué sur « Publier » dans Google Play et l'App Store

Vous avez un build vert. Tous les tests passent. La branche de release est propre. Quelqu'un dans l'équipe dit : « OK, il suffit de l'uploader sur le store et d'attendre la revue. » Si vous avez déjà vécu une vraie release mobile, vous savez que cette phrase cache énormément de complexité.

Uploader sur Google Play Console ou App Store Connect ne se résume pas à envoyer un fichier. C'est un processus en plusieurs étapes qui implique des métadonnées, des captures d'écran, des notes de version, des files d'attente de revue, et la possibilité bien réelle d'un rejet. Et si votre pipeline considère l'upload comme l'étape finale, vous vous préparez à une panique nocturne lorsque la revue reviendra avec un refus.

L'upload est bien plus qu'un transfert de fichier

Lorsque vous uploadez un Android App Bundle (AAB) ou un fichier IPA iOS, le store attend bien plus que le simple binaire. Vous devez également fournir :

  • Le titre et la description de l'application pour la nouvelle version
  • Ce qui a changé dans cette version (notes de version)
  • Des captures d'écran pour plusieurs tailles d'appareils
  • Les mises à jour de catégorie et de classification du contenu
  • Les pays ou régions qui recevront la mise à jour

Google Play Console et App Store Connect exposent tous deux des API qui permettent à votre pipeline de gérer tout cela de manière programmatique. Votre système CI/CD peut pousser l'artefact, remplir les métadonnées, attacher les bonnes captures d'écran et définir le circuit de distribution. Pour Android, vous pouvez uploader vers les tests internes, les tests fermés ou les tests ouverts avant même d'envisager la production. Pour iOS, vous uploadez d'abord sur TestFlight.

Le diagramme de séquence suivant illustre le flux typique du pipeline à la release :

sequenceDiagram participant CI as Pipeline CI/CD participant Store as API du Store participant Review as File de revue participant Track as Circuit de distribution CI->>Store: Upload binaire + métadonnées Store->>Review: Soumettre pour revue Review-->>Store: Approbation ou rejet alt Rejeté Store-->>CI: Notification de rejet CI->>Store: Correction et ré-upload else Approuvé Store->>Track: Définir le circuit (interne/fermé/ouvert/production) Track->>Track: Déploiement progressif ou release complète end

Par exemple, en utilisant fastlane supply sur Android, vous pouvez uploader le binaire, définir les notes de version et attacher les captures d'écran en une seule commande :

# Upload AAB vers le circuit de test interne Google Play
fastlane supply \
  --aab ./app/build/outputs/bundle/release/app-release.aab \
  --track internal \
  --metadata_path ./fastlane/metadata/android \
  --json_key ./path/to/service-account-key.json \
  --package_name com.example.myapp

# Le dossier metadata doit contenir :
#   metadata/android/en-US/title.txt
#   metadata/android/en-US/short_description.txt
#   metadata/android/en-US/full_description.txt
#   metadata/android/en-US/changelogs/1.txt (le code de version comme nom de fichier)
#   metadata/android/en-US/images/phoneScreenshots/

Le point clé ici est que l'étape d'upload ne devrait pas être la fin de votre pipeline. Elle devrait être le début d'un processus de release contrôlé.

Pourquoi ne pas uploader directement en production

Il est tentant de construire un pipeline qui va directement de « les tests passent » à « publié sur le store ». Mais les stores mobiles ajoutent une barrière qui n'existe pas dans les déploiements web ou backend : la revue humaine.

Apple examine chaque application et mise à jour selon les App Store Review Guidelines. Google examine également les soumissions, bien que le processus soit généralement plus rapide et moins strict. Si votre pipeline uploade directement en production et que la revue trouve un problème, vous devez corriger, ré-uploader et attendre à nouveau. Cela peut repousser votre release de plusieurs jours.

Une meilleure approche consiste d'abord à uploader vers un circuit de test. Sur Android, vous pouvez utiliser le circuit de test interne. Sur iOS, vous utilisez TestFlight. Cela donne à votre équipe et à un petit groupe de testeurs la possibilité d'essayer le build destiné au store avant qu'il ne passe par la revue publique. Si quelque chose ne va pas, vous le détectez tôt, corrigez et uploadez à nouveau sans la pression d'une soumission en production rejetée.

Les métadonnées et captures d'écran doivent correspondre au build

L'une des raisons les plus courantes de rejet est une incohérence entre ce que fait l'application et ce que dit la fiche du store. Si votre nouvelle version ajoute une fonctionnalité, mais que vos captures d'écran montrent encore l'ancienne interface, Apple ou Google peuvent la rejeter pour cause de tromperie.

Votre pipeline peut vous aider ici. Stockez les captures d'écran et les métadonnées pour chaque version avec votre code. Lorsque vous déclenchez une release, le pipeline sélectionne les bons assets en fonction du numéro de version ou du tag de release. Cela garantit que ce que vous uploadez sur le store correspond à ce que le binaire contient réellement.

Pour les notes de version, restez court et factuel. N'écrivez pas « correction de bugs et amélioration des performances » à chaque release. Les utilisateurs les lisent. Plus important encore, les relecteurs du store les lisent aussi. Si vos notes disent « ajout du mode sombre » mais que l'application n'a pas de mode sombre, c'est un problème.

Planifiez le temps de revue dans votre calendrier de release

Les revues des stores mobiles prennent du temps. Apple a généralement besoin de 24 à 48 heures pour les mises à jour d'applications, et plus pour les nouvelles applications. Google est généralement plus rapide, parfois seulement quelques heures, mais il y a toujours une file d'attente. Si vous avez une date de release fixe, vous devez uploader suffisamment tôt pour tenir compte du temps de revue plus des éventuelles re-soumissions.

Ne partez pas du principe que la première revue passera. Même les équipes expérimentées se font rejeter pour des choses comme :

  • Demander des autorisations sans expliquer pourquoi
  • Utiliser des API privées
  • Métadonnées incomplètes ou incorrectes
  • Éléments d'interface qui ne correspondent pas aux captures d'écran
  • Violations des politiques spécifiques au store (comme les règles d'Apple sur les achats in-app)

Intégrez un temps tampon dans votre plan de release. Si vous avez besoin que l'application soit en ligne vendredi, visez une soumission au plus tard mardi ou mercredi. Cela vous laisse de la marge pour corriger les problèmes et re-soumettre.

Ce qui se passe après l'approbation de la revue

Une fois que la revue approuve votre build, vous entrez dans la phase de release. Ce n'est pas une décision binaire. Les deux stores prennent en charge les déploiements progressifs.

Sur Android, vous pouvez utiliser le déploiement progressif pour publier la mise à jour à un pourcentage d'utilisateurs, par exemple 10 % ou 25 %. Sur iOS, vous pouvez utiliser la release progressive, qui déploie progressivement la mise à jour sur plusieurs jours. Cela vous permet de surveiller les taux de crash, les retours des utilisateurs et les indicateurs clés avant d'étendre à tout le monde.

Votre pipeline devrait prendre en charge cela. Après l'approbation de la revue, le pipeline peut définir le pourcentage initial de déploiement, attendre une période de surveillance, puis augmenter le pourcentage ou passer à la release complète. Si quelque chose tourne mal, vous pouvez interrompre le déploiement sans affecter tous les utilisateurs.

Liste de contrôle pratique pour les uploads sur le store

  • Uploadez d'abord vers un circuit de test interne ou fermé avant de soumettre pour revue publique
  • Stockez les métadonnées et captures d'écran dans des répertoires versionnés avec votre code
  • Utilisez les API du store pour automatiser la soumission des métadonnées, pas seulement l'upload du binaire
  • Incluez des notes de version qui décrivent précisément ce qui a changé dans cette version
  • Prévoyez au moins 48 heures de temps tampon avant votre date de release cible
  • Configurez le déploiement progressif ou la release progressive par défaut, pas la release complète
  • Ayez un plan de rollback : sachez comment dépublier ou revenir à une version précédente

Ce qu'il faut retenir

Uploader sur un store mobile n'est pas la ligne d'arrivée. C'est le début d'un processus qui comprend la revue, un éventuel rejet, un déploiement progressif et une surveillance. Si votre pipeline considère l'upload comme l'étape finale, vous serez constamment surpris par des rejets et des releases retardées. Intégrez le processus de revue dans la conception de votre pipeline, uploadez d'abord vers des circuits de test et laissez toujours de la place pour une seconde tentative. C'est ainsi que vous transformez les releases mobiles d'un événement stressant en une opération de routine.