API App Store Connect vs API Google Play Developer : ce qu'on peut automatiser en 2026

Publié le : 31 octobre 2026

Avant de scripter vos releases, ou de choisir un outil qui le fait, mieux vaut savoir où s'arrêtent les deux API des stores. Certaines étapes n'ont tout simplement pas d'endpoint, et aucun outil ne peut les automatiser. Cette carte vient de la construction de OneStore sur les deux API.

La carte

Tâche	API App Store Connect	API Google Play Developer
Créer l'app	Non (POST /v1/apps refusé)	Non
Modifier les textes de la fiche par langue	Oui	Oui (dans un edit)
Envoyer les captures	Oui (réserver, envoyer, valider, puis suivre le traitement)	Oui (dans un edit)
Vidéos d'aperçu / vidéo promo	Oui (vidéos d'aperçu)	URL YouTube sur la fiche
Envoyer le build	Oui, mais le binaire lui-même passe par les outils d'Apple (altool, Transporter)	Oui (.aab via edits.bundles.upload)
Soumettre à la review	Oui (review submissions)	Oui (valider une release l'envoie)
Choisir le moment de publication	Oui (manuel, après validation, programmé)	Brouillon ou terminée ; pas de mise en attente après validation par l'API
Déploiement progressif	Déploiement progressif sur 7 jours (mises à jour automatiques seulement)	Oui (fraction d'utilisateurs par release)
Lire l'état de la review	Oui (états de version)	En partie (releaseLifecycleState dans les révisions récentes)
Répondre aux avis	Oui (une nouvelle réponse remplace l'ancienne)	Oui (la réponse est mise à jour)
Ventes et installations	API des rapports de ventes + API Analytics Reports	Rapports en fichiers dans un bucket Cloud Storage
Mise en place initiale (confidentialité, classifications, sécurité des données)	En partie (classification d'âge, conformité export)	Non : Play Console uniquement

App Store Connect : ce qui surprend

Deux endroits pour une fiche. Nom, sous-titre et URL de confidentialité vivent sur appInfoLocalizations ; description, mots-clés, nouveautés et texte promotionnel sur appStoreVersionLocalizations. Lisez-en un seul et la moitié des champs semble vide.
Des fichiers traités en différé. Les envois de captures et d'aperçus répondent OK avant le traitement par Apple. Les échecs (IMAGE_ALPHA_NOT_ALLOWED, MOV_RESAVE_STEREO) apparaissent quelques secondes plus tard dans assetDeliveryState, ou seulement quand la soumission échoue.
Une soumission ouverte par app. Apple ne permet pas d'en supprimer une (DELETE répond 403) ; réutilisez celle qui est ouverte.
Refus générique, raisons précises. ENTITY_STATE_INVALID cache les vrais blocages dans errors[].meta.associatedErrors.
Deux API de rapports. Les rapports Sales and Trends donnent unités et revenus par jour ; l'API Analytics Reports donne engagement, sources et plus, mais elle est asynchrone : on demande un rapport, puis on télécharge les instances quand Apple les a produites.

Google Play : ce qui surprend

Tout passe par un edit. On l'ouvre, on modifie fiches, images, bundles et pistes, puis on valide. Rien n'est en ligne avant la validation, et une validation qui échoue n'applique rien.
Les apps en brouillon. Tant que la première release de production n'a pas été déployée à la main dans Play Console, l'API n'accepte que des releases en brouillon.
Une release active par piste. Deux releases completed ou inProgress dans une même mise à jour de piste, c'est un 400.
La publication gérée est invisible. Si elle est activée, les releases approuvées attendent un clic dans Play Console, et l'API ne peut ni les voir ni les publier.
Les rapports sont des fichiers, pas une API. Installations, notes et revenus arrivent en CSV dans un bucket Cloud Storage lié au compte développeur, mis à jour chaque jour pour la plupart des rapports, avec du retard.
Un 403 ne veut pas toujours dire autorisations. Un version code masqué ou un blocage lié aux règles peut revenir en PERMISSION_DENIED.

Ce qui reste manuel, quel que soit l'outil

La création de l'app sur les deux stores.
Les tâches de contenu de l'app dans Play Console : politique de confidentialité, questionnaire de classification, audience cible, sécurité des données, déclaration publicitaire.
La première release de production d'une nouvelle app Google Play.
Les accords, la fiscalité et les coordonnées bancaires dans App Store Connect et le profil de paiement Play.
La publication d'une release Google Play retenue par la publication gérée.

Un outil qui prétend automatiser ces étapes pilote l'interface web de la console, ou promet trop.

Utiliser les API sans écrire la plomberie

OneStore est construit sur ces deux API et gère les bizarreries ci-dessus : il écrit chaque champ Apple sur la bonne ressource, suit le traitement des fichiers, réutilise les soumissions ouvertes, lit associatedErrors, écrit les pistes Play avec une seule release active, et lit le bucket de rapports Play et les deux API de rapports Apple pour les installations et revenus. Les mêmes opérations sont disponibles pour les assistants IA via son serveur MCP. Quand une API n'a pas d'endpoint, il indique l'étape exacte dans la console au lieu d'échouer en silence.

Questions fréquentes

Peut-on créer une app sur l'App Store ou Google Play par API ?

Non. App Store Connect refuse POST /v1/apps et Google Play n'a pas d'endpoint de création d'app. Créez l'app dans chaque console, puis automatisez tout le reste.

L'API Google Play permet-elle un déploiement progressif ?

Oui. Une release sur une piste peut avoir le statut inProgress avec une fraction d'utilisateurs, que l'on peut augmenter ou terminer ensuite.

L'API App Store Connect peut-elle soumettre une app à la review ?

Oui, via les review submissions : créer ou réutiliser la soumission ouverte, y ajouter la version App Store, puis la soumettre. La version doit avoir un build traité et des métadonnées complètes.

D'où viennent les chiffres d'installations et de revenus Google Play ?

De fichiers de rapports que Google écrit dans un bucket Cloud Storage lié à votre compte développeur, pas de l'API Developer. Un compte de service ayant accès à ce bucket peut les lire.