Mettre à jour ta fiche Play Store avec l'API Google Play Developer

L'API Google Play Developer (son nom officiel est l'Android Publisher API) permet de modifier une fiche store — titre, descriptions, captures d'écran, image de couverture — sans ouvrir la Play Console. C'est exactement ce qu'il te faut si tu pousses des textes localisés depuis un CMS, si tu synchronises des captures d'écran depuis un pipeline de build, ou si tu mets à jour des dizaines de fiches multilingues d'un coup. Voici le flux complet pour le faire correctement, y compris les détails que la documentation de référence enterre.

Un edit est une transaction, pas une série d'écritures en direct

Le modèle mental qui t'épargnera le plus de galères : tu ne modifies jamais directement la fiche en production. Tu ouvres un edit, une copie privée de préparation de l'état actuellement déployé de l'application — fiches, images, tracks, tout y est copié. Tu apportes toutes tes modifications sur cette copie. Puis tu valides le tout d'un coup, ou tu l'abandonnes et rien ne s'est jamais passé.

Google le dit sans détour : "Changes made within an edit are not live until the edit is committed." Au commit, s'il n'y a aucune erreur de validation, tous les changements de l'edit sont publiés ensemble, remplaçant l'état actuel. Si la validation échoue, l'API renvoie une erreur et la fiche en production reste intacte. Le cycle de vie tient donc en exactement quatre étapes :

• edits.insert — crée l'edit, renvoie un editId.
• modifier — edits.listings.update pour le texte par langue, edits.images.upload / deleteall pour les captures d'écran et visuels.
• edits.commit — valide tout, puis publie l'ensemble de façon atomique.
• edits.abandon — jette le brouillon, la fiche en production reste inchangée.

Une contrainte forte à intégrer dès la conception : un compte ne peut avoir qu'un seul edit ouvert à la fois, et si quelqu'un valide un edit ou modifie l'application via l'interface Play Console, tout autre edit ouvert pour cette application est invalidé. Traite un edit comme éphémère — ouvre-le, écris-le, valide-le. Ne le laisse pas ouvert pendant des heures pendant qu'un humain navigue dans la console.

Authentification : un compte de service, plus l'invitation que tout le monde oublie

Pour un outil de mise à jour automatisé, tu veux un compte de service, pas un OAuth utilisateur. Deux systèmes entrent en jeu, et ils sont réellement distincts :

1. Google Cloud. Crée un compte de service, active la Google Play Android Developer API sur le projet, et télécharge une clé JSON. Le seul scope nécessaire est https://www.googleapis.com/auth/androidpublisher.
2. Play Console. Va dans Users & permissions, clique sur Invite new users, colle l'e-mail du compte de service (l'adresse ...@...iam.gserviceaccount.com), et accorde-lui l'accès à l'application. C'est seulement à ce moment que cette clé peut toucher ta fiche.

Une condition préalable de plus : l'application doit déjà exister et avoir eu au moins une release (au moins un APK/AAB envoyé via la console). Tu ne peux pas amorcer une toute nouvelle application uniquement via l'API.

Les quatre appels, en REST

Mettre à jour le texte de la fiche

edits.listings.update est un PUT — un remplacement complet de la fiche pour cette langue. Ce que tu envoies devient la fiche ; les champs que tu omets sont effacés, pas conservés. Donc si tu veux seulement changer la description courte, tu dois tout de même envoyer le titre et la description complète avec, sinon tu les effaceras. Quand tu veux vraiment un changement partiel, il existe un edits.listings.patch séparé qui ne fusionne que les champs que tu fournis. Pour la plupart des pipelines, le PUT complet est plus propre — tu génères de toute façon la fiche complète depuis ta source de vérité, donc la remplacer entièrement est exactement ce qu'il faut.

Les trois champs de texte et leurs limites : title jusqu'à 30 caractères, shortDescription jusqu'à 80, fullDescription jusqu'à 4000. Une ressource de fiche par langue, indexée par le code de langue BCP-47 dans l'URL (en-US, de-DE, ja-JP, etc.). Pour mettre à jour dix langues, tu fais dix appels listings.update à l'intérieur du même edit — puis un seul commit les publie tous ensemble.

Envoyer les captures d'écran et l'image de couverture

Les images sont rattachées par langue et par type d'image. Le type d'image est une énumération, et chaque emplacement d'asset dans la fiche correspond à l'une de ces valeurs :

• phoneScreenshots, sevenInchScreenshots, tenInchScreenshots — les jeux de captures pour téléphone et tablette.
• tvScreenshots, wearScreenshots — Android TV et Wear OS.
• featureGraphic — la bannière 1024×500 affichée en haut de la fiche.
• icon, tvBanner — l'icône de l'application et la bannière TV.

edits.images.upload ajoute une image d'une langue et d'un type donnés à l'edit. Il n'existe pas d'appel « remplacer tout le tableau », donc le pattern fiable pour remplacer des captures d'écran est edits.images.deleteall pour cette langue et ce type d'image d'abord, puis l'envoi du nouveau jeu dans l'ordre où tu veux qu'il apparaisse. edits.images.list lit ce qui se trouve actuellement dans l'edit, et edits.images.delete supprime une seule image par id si tu as besoin de changements chirurgicaux. Tout reste dans l'edit jusqu'au commit.

Valider — et ce que « en ligne » veut vraiment dire

Quelques points à préciser, car ils surprennent souvent :

• Aucun nouveau build nécessaire. Valider un edit qui ne touche que la fiche ne nécessite pas de nouvel APK/AAB. Le texte et les images sont des métadonnées ; tu peux les mettre à jour autant de fois que tu veux sur la release existante. (L'application a juste besoin que cette release préalable existe.)
• Le commit valide, puis publie. Si une capture d'écran a une mauvaise dimension ou qu'un champ est trop long, le commit échoue et la fiche en production ne change jamais — tu corriges et tu relances le commit.
• Ce n'est pas instantané. Après un commit réussi, les changements peuvent mettre jusqu'à plusieurs heures à apparaître, comme pour les modifications faites à la main dans la Play Console. Ne considère pas un 200 sur le commit comme « déjà visible pour les utilisateurs ».
• Abandonner ne coûte rien. Si un essai à blanc semble incorrect, edits.abandon jette le brouillon sans aucun effet sur la fiche en production. Utile pour valider un pipeline sans risque.

La voie sans code : concevoir, traduire, publier

L'API décrite ci-dessus est le bon outil si tu as du temps d'ingénierie à y consacrer et une source de vérité à synchroniser. Ce qu'elle ne fait pas, c'est créer les assets. Tu dois toujours concevoir les captures d'écran, écrire le titre et les deux descriptions, et produire tout cela par langue — l'API se contente d'envoyer ce que tu lui donnes.

C'est exactement ce dont Mokbi s'occupe. Tu conçois les captures d'écran dans le navigateur, tu rédiges le titre, la description courte et la description complète en même temps, et tu traduis toute la fiche en 50 langues en une seule passe — pour que les dix appels listings.update ci-dessus aient un vrai texte localisé à envoyer plutôt qu'un texte de remplissage.

Et la publication elle-même ? Mokbi s'en charge aussi. Pour Google Play, elle exécute exactement ce flux en coulisses (edits.insert → listings.update → upload d'images → commit), donc ta fiche localisée et tes visuels passent en ligne sans que tu écrives une seule ligne du code ci-dessus. Pour l'App Store, elle prépare la version dans App Store Connect, remplie et prête à soumettre, puisqu'Apple exige que tu appuies toi-même sur le bouton final Submit et passes la revue. Concevoir les captures d'écran et l'image de couverture, rédiger la fiche, la traduire en 50 langues, et la publier ne font qu'une seule passe continue.

À lire ensuite

• Mettre à jour une fiche Play sans publier un nouveau build
• Exigences de fiche Play et checklist des assets
• L'équivalent App Store Connect API, pour iOS

Ouvrir l'éditeur →