Comment changer les captures d'écran App Store sans nouvelle version
Tu veux changer les captures d'écran d'une app en direct aujourd'hui, tu ouvres App Store Connect, et les champs de capture d'écran de la version actuelle sont en lecture seule. C'est Apple qui fonctionne comme prévu, pas un bug. Les captures d'écran font partie des métadonnées d'une version, et une fois qu'une version est approuvée et publiée, ses métadonnées sont figées. Voici les voies qui changent réellement ce que voient les acheteurs, et ce que chacune te coûte en envois de build et en temps de revue.
Pourquoi les champs sont verrouillés
App Store Connect stocke les captures d'écran associées à une version d'app spécifique. Quand ton app est en direct, cette version est dans un état publié et ses captures d'écran, sa description et ses mots-clés sont tous verrouillés. Pour modifier l'un d'entre eux, tu travailles sur un enregistrement de version distinct et modifiable, celui à l'état « Prête pour soumission ». La fiche en direct continue d'afficher les anciennes captures d'écran jusqu'à ce qu'une nouvelle version soit approuvée et publiée par-dessus.
La documentation d'Apple elle-même est directe à ce sujet : une fois ton app soumise et approuvée, tu dois créer une nouvelle version pour mettre à jour les captures d'écran. La question n'est donc pas « puis-je modifier la version en direct » (tu ne peux pas). C'est « quel mécanisme produit le changement le plus petit et le plus rapide ».
Voie 1 : un nouvel enregistrement de version (la voie par défaut)
C'est le chemin que la plupart des développeurs connaissent déjà. Dans App Store Connect, tu crées une nouvelle version, ouvres l'enregistrement modifiable « Prête pour soumission », remplaces les captures d'écran et soumets pour revue. Le détail important : tu n'as pas besoin de livrer une nouvelle fonctionnalité ou un correctif, mais tu dois attacher un build à la version.
App Store Connect ne proposera pas le build actuellement en direct dans le sélecteur de build de la nouvelle version. En pratique, tu fais donc l'une de ces deux choses : choisir un autre build déjà téléversé (un reste d'un ancien upload TestFlight fonctionne), ou pousser un nouveau binaire avec le même code source et un numéro de build incrémenté. Aucun n'ajoute de fonctionnalité. Mais un build doit être présent, et toute la version, captures d'écran incluses, passe par App Review. Les nouvelles captures d'écran n'apparaissent qu'une fois cette version approuvée et publiée.
Utilise cette voie quand tu changes de toute façon plus que les captures d'écran, par exemple une nouvelle description et un nouvel ensemble de mots-clés en même temps que les visuels, puisque tout peut passer dans la même soumission.
Voie 2 : optimisation de la page produit (sans nouvelle version, sans nouveau build)
L'optimisation de la page produit (PPO) est la fonctionnalité de test A/B intégrée d'Apple, et c'est aussi le seul moyen de changer les captures d'écran et les vidéos d'aperçu sans nouvelle version ni nouveau build du tout. Tu crées un test, ajoutes une variante avec tes nouvelles captures d'écran, et soumets cette variante. Apple indique directement que ces métadonnées peuvent être soumises sans soumettre une nouvelle version de ton app.
Le point qui garde le système honnête : le nouveau visuel passe quand même par App Review avant que le test puisse démarrer. La seule exception est la réorganisation de captures d'écran déjà approuvées et en ligne, qui ne nécessite aucune nouvelle revue. Tout ce qui est réellement nouveau est d'abord examiné.
Le PPO est conçu comme une expérience, les résultats reviennent donc sous forme d'un gain estimé du taux de conversion, un pourcentage comparé à ta page actuelle avec un niveau de confiance sur les données. Si tu veux simplement que les nouvelles captures d'écran soient en direct pour tout le monde plutôt qu'un test mesuré, tu peux créer le test, le lancer, puis appliquer la variante gagnante à ta page produit par défaut. Appliquer une variante met fin au test et pousse ce visuel à chaque acheteur, toujours sans upload de binaire.
Une limite à énoncer clairement : les captures d'écran et vidéos d'aperçu sont sans build via le PPO, mais pas les icônes d'app alternatives. Une icône doit être compilée dans le binaire déjà en ligne, donc une icône véritablement nouvelle nécessite quand même un build. Garde les icônes en dehors d'un changement de capture d'écran sans build.
Voie 3 : pages produit personnalisées, pour des variantes ciblées
Si tu veux un ensemble de captures d'écran différent pour un public spécifique ou une campagne publicitaire plutôt qu'un changement de ta fiche principale, les pages produit personnalisées te permettent de publier des versions alternatives sur leurs propres URL. Chaque variante est revue séparément et est atteinte par lien, donc ta page par défaut reste intacte. C'est plus un outil de ciblage qu'un outil de « changement de la fiche en direct », mais il a sa place quand tu décides comment déplacer des captures d'écran sans publication complète de l'app.
Le seul champ modifiable à tout moment : le texte promotionnel
Le texte promotionnel est le seul champ App Store que tu peux modifier sans nouvelle version et sans App Review. C'est un bloc de 170 caractères qui se trouve en haut de ta description, et les modifications se déploient d'elles-mêmes en quelques heures (Apple autorise jusqu'à 48). Il n'est pas indexé pour le classement des mots-clés, donc il ne fera pas bouger ta position dans la recherche, mais c'est l'endroit idéal pour une ligne sensible au temps pendant qu'un changement de capture d'écran est encore en revue.
Voie par voie : build et revue en un coup d'œil
Quelle voie choisir
- Simplement remplacer les captures d'écran, le chemin le plus rapide. Optimisation de la page produit. Aucun build, une seule revue sur le nouveau visuel, puis applique la variante et c'est en direct pour tout le monde.
- Changer les captures d'écran plus le texte ou les mots-clés. Nouvel enregistrement de version, pour que toute la mise à jour parte dans une seule soumission.
- Visuels différents pour une campagne, pas pour la page principale. Page produit personnalisée.
- Une ligne à mettre en ligne dans l'heure. Texte promotionnel, pendant que le vrai changement de capture d'écran est en revue.
La place de Mokbi
Mokbi gère tout le rafraîchissement des captures d'écran de bout en bout. Il conçoit les nouvelles captures d'écran et le graphique de fonctionnalité Google Play, puis rédige la fiche complète, titre, sous-titre, description et texte promotionnel, et traduit le tout en 50 langues en une seule passe. C'est la partie qui bloque généralement un rafraîchissement de captures d'écran, et Mokbi le fait en un seul flux.
Ensuite, il publie. Mokbi pousse la fiche et les assets finis directement vers Google Play via la Play Developer API, où ils passent en direct immédiatement, et prépare tout dans App Store Connect, prêt pour ta soumission. Apple exige que ce dernier clic Submit et l'App Review se fassent sur ton propre compte, donc ce clic-là te revient, mais le visuel et le texte sont déjà en place, dans chaque langue, installés dans une nouvelle version ou un test d'optimisation de la page produit dès que tu ouvres la console.