Mettre à jour une fiche Google Play sans fastlane supply en 2026
fastlane supply pousse une fiche Google Play depuis des fichiers de votre dépôt : titre, description courte et longue, images, captures et notes de version, plus le .aab lui-même. Comme son cousin App Store deliver, il marche bien une fois configuré, au prix d'un environnement Ruby, d'un compte de service et d'une arborescence de métadonnées à garder alignée.
Voici ce que fait supply, ce que fait l'API Google Play Developer en dessous, et les autres options.
Ce que fait supply
D'après la documentation de fastlane : supply (alias de upload_to_play_store) envoie métadonnées, captures, APK et AAB vers Google Play, et peut choisir la piste et promouvoir les builds.
fastlane supply init # télécharge la fiche actuelle dans ./fastlane/metadata/android
fastlane supply # envoie fiche, images, captures, notes de version et buildL'arborescence : un dossier par langue, par exemple metadata/android/fr-FR/, avec title.txt, short_description.txt et le fichier de description, un dossier images/ (featureGraphic, icon, phoneScreenshots/, sevenInchScreenshots/, tenInchScreenshots/…) et changelogs/ nommé d'après le version code (100100.txt), avec default.txt en secours.
Les options utiles : track (production par défaut), rollout, release_status (completed, draft, halted, inProgress), skip_upload_aab, skip_upload_metadata, skip_upload_images, skip_upload_screenshots, skip_upload_changelogs et validate_only. Deux comportements à connaître : les captures remplacent celles en place au lieu de s'ajouter, et la doc de fastlane indique qu'il faut envoyer au moins un build à la main avant que supply puisse se connecter à l'app.
Les limites
| Champ | Limite |
|---|---|
| Titre | 30 caractères |
| Description courte | 80 caractères |
| Description complète | 4 000 caractères |
| Notes de version (par langue) | 500 caractères |
| Captures par type d'appareil | 2 à 8 |
La limite des notes de version piège les équipes qui reprennent leurs nouveautés App Store : Apple autorise 4 000 caractères, Google 500.
Ce qui se passe en dessous : les edits
Toute écriture sur Google Play passe par un edit, une transaction sur l'app :
edits.insertouvre un edit.edits.listings.updateécrit le titre et les descriptions d'une langue ;edits.images.uploadenvoie une capture ou un visuel.- Pour une release,
edits.bundles.uploadenvoie le .aab etedits.tracks.updatele place sur une piste avec un statut et une fraction de déploiement. edits.commitapplique tout d'un coup. Rien n'est visible avant le commit.
Deux erreurs que vous croiserez au commit, gérées par les versions récentes de fastlane :
- « Changes cannot be sent for review automatically » : après une mise à jour refusée, Google demande de valider avec
changesNotSentForReview=truepuis d'envoyer les changements en review depuis Play Console. L'optionrescue_changes_not_sent_for_reviewde supply réessaie de cette façon. - « You already have changes in review » : une autre soumission de l'app est en review ; valider maintenant l'annulerait. Attendez la fin de la review.
Le compte de service doit avoir les bonnes autorisations Play Console sur l'app. La doc de fastlane suggère « Administrateur (toutes les autorisations) » ; un droit plus restreint suffit s'il couvre la fiche et les releases sur les pistes utilisées.
Les autres façons de pousser la fiche
1. Play Console, à la main
Très bien pour une langue. Ça devient lent quand vous traduisez en dix, et la fiche App Store vit dans une autre console.
2. L'API Google Play Developer directement
Le circuit d'edits ci-dessus, depuis votre propre script avec un compte de service. Pas compliqué, mais la gestion des erreurs, l'ordre des images et la fusion par langue sont pour vous.
3. Un outil avec une interface
OneStore modifie les fiches Google Play et App Store dans un seul formulaire, vérifie les limites 30/80/4 000 et 500 caractères pendant la saisie, redimensionne une capture HD aux tailles demandées par Play, et pousse par le même circuit d'edits. Il envoie aussi le .aab, le place sur une piste, règle le pourcentage de déploiement progressif et fait passer une version d'une piste à l'autre. Quand Google refuse un commit, il affiche la raison donnée par Google et la correction, au lieu d'un 403 brut.
Quand garder supply
Si votre fiche Play est versionnée dans Git et que vos releases tournent en CI, supply reste un bon choix. Si ceux qui modifient la fiche n'utilisent pas de terminal, ou si vous voulez les fiches App Store et Google Play côte à côte, une interface fait gagner du temps.
À lire aussi : les erreurs de l'API Google Play Developer expliquées, envoyer un .aab sans Android Studio, les alternatives à fastlane.
Questions fréquentes
Qu'est-ce que fastlane supply envoie ?
Métadonnées, images, captures, notes de version, APK et AAB vers Google Play. Il peut aussi choisir la piste, régler la fraction de déploiement et promouvoir les builds d'une piste à l'autre.
Faut-il envoyer le premier build à la main ?
La documentation de fastlane indique qu'il faut envoyer au moins un build manuellement avant que supply puisse se connecter à l'app. Une app Play neuve reste aussi en brouillon jusqu'au déploiement de sa première release de production depuis Play Console, et l'API n'accepte que des releases en brouillon d'ici là.
Pourquoi supply remplace-t-il mes captures ?
Parce que les captures envoyées par supply remplacent le jeu existant pour ce type d'appareil au lieu de s'y ajouter, dans l'ordre alphanumérique des noms de fichiers. Gardez le jeu complet dans le dossier, pas seulement les nouvelles images.
Quelle est la limite des notes de version sur Google Play ?
500 caractères par langue. L'App Store autorise 4 000 caractères pour les nouveautés, donc des notes reprises d'Apple doivent souvent être raccourcies.