Les erreurs de l'API Google Play Developer expliquées, avec leurs corrections (2026)

Read in English →

Publier sur Google Play par l'API (avec fastlane supply, gradle-play-publisher, EAS Submit ou votre propre script) marche plutôt bien, jusqu'à ce que Google renvoie un 400 ou un 403 avec un message qui désigne le mauvais problème. Voici les erreurs que gère la publication Google Play de OneStore, ce qu'elles veulent vraiment dire, et la correction.

« Only releases with status draft may be created on draft app »

Sens : l'app n'a jamais été publiée. Tant que sa première release de production n'est pas déployée, Play la considère comme une app en brouillon, et l'API n'accepte que des releases au statut draft.

Correction : ouvrez Play Console, allez sur le tableau de bord de l'app et terminez chaque tâche obligatoire (politique de confidentialité, classification du contenu, audience cible, sécurité des données, déclaration publicitaire, fiche principale). Puis déployez la première release de production à la main : Production, ouvrir la release en brouillon, Examiner la release, Lancer le déploiement. Ensuite, les releases par API fonctionnent normalement.

« Only one completed release is allowed »

Sens : une piste ne peut contenir qu'une release active (statut completed ou inProgress). Le corps de votre tracks.update en contient deux.

Correction : quand vous écrivez une piste, retirez du corps la release active actuelle et n'envoyez que la nouvelle, plus les brouillons à garder. Google marque l'ancienne comme remplacée au commit.

Version code déjà utilisé

Sens : un envoi précédent sur cette app a déjà utilisé ce versionCode, même s'il n'a jamais été publié.

Correction : augmentez le version code et rebuildez. En Flutter, c'est le nombre après + dans pubspec.yaml ; dans un projet natif ou React Native, versionCode dans android/app/build.gradle ; avec EAS, autoIncrement peut s'en charger.

Version code masqué par un code plus élevé

Sens : Play indique que les appareils « will receive APKs with higher version codes ». Le version code publié est masqué : un autre artefact de la même release, ou déjà sur la piste, a un code plus élevé, donc aucun appareil ne recevra le vôtre. Play peut le signaler par un 403 PERMISSION_DENIED, ce qui fait chercher du côté des autorisations pour rien.

Correction : ne publiez que l'artefact le plus récent sur la piste, et vérifiez que son version code dépasse tout ce qui s'y trouve déjà.

« The APK or Android App Bundle was signed with the wrong key »

Sens : le .aab n'est pas signé avec la clé d'importation attendue par Play pour cette app.

Correction : signez avec la keystore d'importation d'origine. Si elle est perdue, demandez une réinitialisation de la clé d'importation dans Play Console, rubrique Intégrité de l'app ; la réinitialisation par Google prend environ deux jours.

« Changes cannot be sent for review automatically »

Sens : après une mise à jour refusée, Google n'accepte plus l'envoi automatique en review par l'API pour cette app.

Correction : validez l'edit avec changesNotSentForReview=true, puis ouvrez Play Console, Vue d'ensemble de la publication, et envoyez les changements en review à la main. Les soumissions suivantes par API refonctionnent.

« You already have changes in review »

Sens : un autre ensemble de changements est en cours de review. Valider maintenant annulerait cette review.

Correction : attendez la fin de la review en cours (Vue d'ensemble de la publication dans Play Console), puis soumettez.

Les 403 PERMISSION_DENIED qui ne parlent pas d'autorisations

Play utilise le 403 à la fois pour les autorisations Play Console manquantes du compte de service et pour d'autres refus, comme le version code masqué ci-dessus ou un blocage lié aux règles. Avant d'accorder « Administrateur (toutes les autorisations) », lisez le corps du message : s'il parle de version codes, de clés ou de l'état brouillon, la correction est là, pas dans les autorisations.

Les trous de l'API elle-même

• Publication gérée : si elle est activée, les releases approuvées attendent qu'on clique sur Publier dans Play Console. L'API ne peut ni lire ce réglage, ni voir l'état « approuvée, non publiée », ni publier la release. Désactivez la publication gérée si vous publiez par API, et utilisez des releases en brouillon pour en retenir une.
• État de la review : longtemps, le statut d'une piste disait completed avant et après la review. Les révisions récentes de l'API exposent releaseLifecycleState (comme IN_REVIEW ou NOT_APPROVED) via tracks.releases.list ; les outils plus anciens devinent encore.
• Créer l'app : aucune API ne crée une app Play. Créez-la dans Play Console.

Des erreurs lisibles

OneStore traduit chacune de ces réponses de Play en explication claire avec l'étape exacte dans Play Console pour corriger, garde le message de Google visible, et évite la plupart en amont : il n'envoie que la nouvelle release quand il écrit une piste et limite les notes de version aux 500 caractères de Play par langue.

À lire aussi : fiche Google Play sans fastlane supply, envoyer un .aab sans Android Studio, les erreurs App Store Connect.

Questions fréquentes