Envoyer en masse des captures d'écran localisées vers les deux stores
deliver/supply qui s'appuient dessus). Mokbi génère chaque combinaison langue × appareil et publie l'ensemble sur les deux stores à ta place — en poussant directement vers Google Play via l'API Play Developer, et en préparant les fichiers dans App Store Connect prêts pour ta soumission finale.Tu es en pleine sortie de version. Les captures d'écran sont prêtes. Il reste à les envoyer sur les deux stores, dans chaque langue que tu prends en charge, à chaque taille d'appareil exigée par chaque store. C'est la partie dont personne ne te prévient — et celle où l'on finit discrètement par chercher « bulk upload localized screenshots app store connect / google play all languages ».
Voici d'abord la réponse honnête, pour que tu puisses arrêter de chercher : aucun store ne propose d'envoi en masse natif couvrant toutes les langues. Tu envoies langue par langue, famille de tailles par famille, dans l'interface web, un lot à la fois.
Ce que « pas d'envoi en masse » signifie vraiment
Dans App Store Connect, tu ouvres ton application, tu choisis la version, tu descends jusqu'à la section captures d'écran, et tu glisses des PNG dans un emplacement spécifique lié à un type d'affichage — 6.9", 6.5", 13" iPad, etc. Ensuite tu passes au menu déroulant de localisation suivant et tu recommences. Apple permet d'ajouter jusqu'à 10 captures d'écran par type d'appareil, par langue. Il n'y a pas de bouton « appliquer à toutes les langues » pour les images.
Google Play Console fonctionne de la même façon. Dans la fiche principale du store, tu choisis une langue, puis tu envoies des captures d'écran dans chaque section d'appareil — téléphone, tablette 7 pouces, tablette 10 pouces, et éventuellement Chromebook, Wear OS, Android TV et les nouveaux types. Jusqu'à 8 par type d'appareil. Tu changes de langue, tu recommences.
L'unité de travail n'est donc pas « un ensemble de captures ». C'est un lot = une langue × une famille de tailles d'appareil, et tu remplis chaque lot à la main.
L'ampleur du glisser-déposer, chiffrée
Compte les lots honnêtement. Chez Apple, une soumission normale remplit au minimum une famille d'affichage iPhone et une famille iPad — disons 2, plus si tu gardes un ensemble iPhone 6.5" séparé en plus du 6.9". Chez Play, une soumission normale remplit téléphone plus deux tailles de tablette — disons 3, plus si tu ajoutes Chromebook ou Wear OS.
- Une langue, les deux stores : environ 2 lots Apple + 3 lots Play = 5 envois manuels.
- Dix langues : environ 20 + 30 = 50 lots à remplir, chacun contenant jusqu'à 8 à 10 images.
- Cinquante langues : environ 100 + 150 = 250 envois par glisser-déposer séparés, avant même d'avoir vérifié que la bonne image est arrivée au bon emplacement.
Trente minutes de glisser-déposer par langue, c'est le chiffre que les gens citent, et pas sans raison. À partir d'un vrai nombre de langues, ça cesse d'être une tâche pour devenir une après-midi entière — une après-midi que tu répètes à chaque nouvelle version.
Les deux seuls chemins d'automatisation
Si tu veux éviter complètement l'interface web, il existe exactement deux portes officielles, une par store :
- API App Store Connect. La ressource screenshots permet de créer un ensemble et d'envoyer des images par programme pour une langue et un type d'affichage d'appareil donnés. Tu t'authentifies avec une clé API et tu pousses les images langue par langue, famille d'affichage par famille.
- API Google Play Developer. La méthode
edits.images.uploadenvoie une image d'une langue et d'un type d'image donnés (phoneScreenshots,sevenInchScreenshots,tenInchScreenshots, etc.) dans une modification en attente, que tu valides ensuite.
La plupart des équipes n'appellent pas ces API directement. Elles utilisent fastlane par-dessus : deliver (aussi exposé comme upload_to_app_store) pilote l'API App Store Connect, et supply (upload_to_play_store) pilote l'API Play Developer. Supply lance même plusieurs threads d'envoi pour pousser les images localisées en parallèle. C'est ça, le vrai « envoi en masse » — une boucle d'API, pas un bouton dans le tableau de bord.
Il faut être clair sur le coût : fastlane implique une chaîne d'outils Ruby, un fastfile, des identifiants API des stores, et (côté Apple) la plomberie habituelle de signature de code et de simulateur. Ça devient rentable quand tu sors des versions souvent. Pour une application soumise quelques fois par an, mettre tout ça en place juste pour envoyer des images peut demander plus de travail que le glisser-déposer qu'elle remplace. Si tu l'utilises déjà pour tes builds, ajouter l'étape des captures d'écran est presque gratuit.
L'origine des captures d'écran est le vrai goulot d'étranglement
Remarque que chaque chemin ci-dessus suppose que les fichiers existent déjà — à la bonne taille, un ensemble par famille d'appareil, traduits dans chaque langue. C'est ça, la vraie difficulté. L'API App Store Connect et l'API Play Developer déplacent des images terminées ; elles ne les conçoivent pas, ne les redimensionnent pas, ne traduisent pas les légendes. Si tu produis 50 variantes de langue sur 5 tailles d'appareil à la main dans un outil de design, l'envoi n'a jamais été ton vrai goulot d'étranglement.
C'est exactement le vide que Mokbi comble. Tu conçois un modèle une seule fois, et il génère chaque taille d'appareil et chacune des 50 langues à partir de cette source unique — légendes traduites, mise en page réajustée, chaque cadre exporté aux dimensions en pixels exactes attendues par son emplacement dans le store. Le résultat est un lot : un ensemble propre de fichiers langue × appareil, nommés et organisés, prêts à déposer dans les bons lots.
Publication en un clic sur les deux stores
Mokbi résout exactement ce problème. Tu construis un seul ensemble, et il génère chaque langue × chaque taille d'appareil et les publie sur les deux stores — en poussant directement vers Google Play via l'API Play Developer, et en préparant les ensembles dans App Store Connect prêts pour ta soumission. Apple exige la soumission finale et l'examen, donc ce dernier geste reste entre tes mains ; tout ce qui précède est pris en charge. Plus d'envoi manuel langue par langue, appareil par appareil.
Si tu utilises déjà fastlane ou les API des stores dans ta propre CI, les mêmes fichiers exportés alimentent directement deliver et supply. Dans tous les cas, la conception, le redimensionnement et la traduction en 50 langues sont faits pour toi — et maintenant la publication aussi.
Le workflow qui te fait vraiment gagner l'après-midi
- Conçois une fois. Construis le carrousel une seule fois dans l'éditeur.
- Exporte la matrice en lot. Chaque taille d'appareil × chaque langue, aux dimensions exactes du store, en un seul export.
- Publie sur les deux stores. Mokbi pousse les ensembles vers Google Play et les prépare dans App Store Connect pour ta soumission finale — ou donne les fichiers à fastlane
deliver/supplysi tu utilises ton propre CI. - À la prochaine version, réexporte et recommence. Change le design une fois, régénère toute la matrice, envoie de nouveau.
Le calcul qui compte : le nombre de lots ne change pas, mais le temps par lot s'effondre quand tu déposes un fichier terminé et déjà à la bonne taille au lieu de le concevoir et le redimensionner d'abord. C'est la différence entre une après-midi et une pause café.