App Store Connect vs Google Play Console : le workflow de publication
Si tu publies sur un seul store, tu apprends une console et tu avances. Si tu publies sur les deux, tu jongles avec deux modèles mentaux qui utilisent les mêmes mots pour des choses différentes. « Release », « review » et « rollout » veulent tous dire quelque chose de légèrement différent dans App Store Connect et dans Google Play Console. Cet article aligne les deux workflows étape par étape, pour que tu puisses planifier un lancement qui atterrit sur les deux stores sans surprise.
Le workflow, côte à côte
Commence ici. Chaque ligne est une étape de la mise en ligne d'une mise à jour ; les deux colonnes montrent ce qui se passe réellement dans chaque console.
| Modification des métadonnées seules | La plupart des changements de fiche passent par une nouvelle version soumise à review ; seuls quelques champs se modifient en direct. | Une modification de fiche store, soumise et examinée sans envoyer de nouveau build. |
Comment Apple publie une version
Dans App Store Connect, l'unité de travail est une version. Tu rattaches un build, tu remplis les métadonnées et les captures d'écran, puis tu soumets le tout à l'App Review. Apple examine ça comme un seul ensemble — c'est pourquoi changer une capture d'écran ou retoucher une description implique généralement, à elle seule, une nouvelle version et un nouveau passage en review.
Une fois l'App Review approuvée, ton option de publication détermine la suite. Choisis automatique et elle est mise en ligne immédiatement. Choisis manuelle et elle attend en « Pending Developer Release » — Apple l'a approuvée, mais rien n'est public tant que tu n'appuies pas sur le bouton (compte jusqu'à 24 heures pour qu'elle apparaisse ensuite). Choisis programmée et elle se publie automatiquement à une date et une heure que tu définis. Ce choix se fait par version, donc chaque mise à jour est une décision à part entière.
Pour un lancement progressif, active le déploiement progressif (phased release). Il s'applique aux mises à jour automatiques des utilisateurs existants et les étale sur 7 jours par paliers de pourcentage croissants ; tu peux le mettre en pause si les métriques montrent un problème. Il ne s'applique pas à une toute nouvelle application, ni aux publications manuelles — c'est l'équivalent, côté App Store, du déploiement progressif de Google, pas une retenue sur la publication entière.
Comment Google publie vers une piste
Google répartit le même travail sur des pistes (tracks). Un build démarre sur une piste de test — interne, fermée ou ouverte — et est promu vers la production quand tu es prêt. Le test interne vise un petit groupe de confiance (jusqu'à 100 personnes). Le test fermé s'élargit à des listes sur invitation (jusqu'à 2 000 par liste). Le test ouvert est public, sur inscription volontaire, sans plafond. La production, c'est tout le monde dans les pays choisis.
Quand tu envoies une release, la publication gérée (managed publishing) équivaut à la retenue manuelle d'Apple. Activée, les modifications approuvées s'accumulent dans l'aperçu de publication sous « changements prêts à envoyer » et ne sont mises en ligne que lorsque tu publies — pratique pour caler une release sur une date marketing. Désactivée, les modifications approuvées se publient dès que la review est validée.
Pour un lancement progressif, utilise un déploiement progressif (staged rollout) : publie auprès d'un pourcentage d'utilisateurs et augmente-le toi-même dans le temps, en stoppant si les taux de crash grimpent. Comme le déploiement progressif d'Apple, il concerne les mises à jour, pas les premiers lancements — une toute nouvelle release de production part chez tout le monde en une fois.
La divergence qui piège tout le monde
Voici la distinction à retenir : Apple couple les métadonnées à la version ; Google sépare la fiche store de la publication.
Chez Apple, tes captures d'écran, ta description et tes mots-clés font partie de la version en review. Envie de rafraîchir les captures d'écran entre deux builds ? Pour la plupart des champs, cela signifie une nouvelle version et un nouveau passage en review. Chez Google, la fiche store est un objet à part — tu peux mettre à jour le texte et les visuels et les envoyer seuls en review, pendant que le bundle de l'application publiée reste exactement là où il est. Deux stores, deux réponses très différentes à la question « puis-je changer ça sans une release complète ? »
Ça compte surtout quand un lancement a beaucoup d'éléments en mouvement : un build, un set de captures d'écran, du texte localisé sur des dizaines de marchés. Chez Apple, tu as tendance à tout regrouper dans une seule version pour que ça passe en review ensemble. Chez Google, tu peux faire évoluer la fiche et la release indépendamment, et les publier dans l'ordre qui convient à ton plan.
Délais de review, et le piège des nouveaux comptes
L'App Review d'Apple tourne autour de 24 à 48 heures pour une mise à jour classique en 2026, plus long pour une première soumission d'un nouveau développeur ou tout ce qui est signalé pour un examen plus poussé. La review de Google est souvent plus rapide — quelques heures à quelques jours pour un compte établi — mais il existe un filtre pour les nouveaux venus.
Un compte développeur Google Play personnel créé après mi-novembre 2023 doit faire tourner un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs avant de pouvoir demander l'accès à la production. Descendre sous 12 testeurs peut réinitialiser le compteur. Les comptes d'organisation et les comptes personnels plus anciens échappent à cette règle. Apple n'a pas d'équivalent direct, donc si tu lances une première application sur les deux stores, prévois la fenêtre de test de Google en amont — c'est souvent le facteur le plus long.
Où Mokbi s'intègre
Les deux consoles veulent les mêmes assets finis : des captures d'écran encadrées et un texte propre, localisé, à chaque taille requise. Mokbi construit ça une seule fois. Tu conçois les captures d'écran et tu rédiges le texte de la fiche store dans un seul projet, puis tu traduis les deux en 50 langues, et tu exportes un set qui correspond aux dimensions d'App Store Connect et de Google Play Console en un seul passage — le même travail nourrit ainsi deux fiches au lieu de deux corvées séparées.
Mokbi les publie aussi. Il envoie directement la fiche et les assets vers Google Play via la Play Developer API, et il prépare la version dans App Store Connect, prête pour ta soumission. Apple exige la validation finale du Submit et son passage en review, donc ce dernier geste te revient (une règle d'Apple, pas une limite de Mokbi). Dans les deux cas, tu pilotes les mises à jour de fiche des deux consoles depuis un seul endroit, sur un seul abonnement : l'éditeur est gratuit avec filigrane, et Solo (€29.99/mois) ou Studio (€49.99/mois) débloquent l'export et la publication illimités tant que tu restes abonné.