Publier votre fiche App Store sans fastlane
deliver et supply de fastlane poussent vos métadonnées, captures d'écran et binaire vers les deux stores depuis la ligne de commande — gratuit, open source, et toujours à jour si vous les intégrez à votre CI. Le coût, c'est que quelqu'un doit construire et entretenir ce pipeline : Ruby, Xcode ou Gradle, un Fastfile, et la maintenance des tests UI. Si vous préférez ne pas gérer de pipeline, les chemins sans code sont les consoles web des stores, les API des stores directement, ou un outil qui rédige la fiche à votre place. Mokbi est le chemin sans code qui publie réellement : il conçoit vos captures d'écran et votre feature graphic, rédige et traduit toute la fiche en 50 langues, puis la pousse directement vers Google Play via la Play Developer API tout en préparant la version App Store dans App Store Connect pour que vous la soumettiez. Pas de Ruby, pas de Xcode, pas de test UI.fastlane est la réponse par défaut, et pour de bonnes raisons. C'est une boîte à outils gratuite sous licence MIT, et son action deliver (alias upload_to_app_store) envoie captures d'écran, vidéos de présentation, métadonnées et binaire vers App Store Connect en une seule commande. Côté Android, supply (alias upload_to_play_store) fait de même pour Google Play — métadonnées, captures d'écran et APK ou app bundle. Exécutez l'une ou l'autre depuis la CI et votre fiche se régénère à chaque release, sans jamais dériver de l'app.
La question honnête n'est donc pas « fastlane est-il bon » — il l'est. La question est de savoir si vous voulez posséder le pipeline qui le rend bon, ou si vous préférez mettre à jour une fiche sans en avoir un.
Ce que font vraiment deliver et supply
Les deux sont des enveloppes autour des API officielles des stores. En coulisses, fastlane fait les mêmes appels que vous pourriez faire vous-même.
deliver(iOS). Envoie le nom de l'app, la description, les mots-clés, les notes de version, les URL, les catégories et les informations de revue, plus les captures d'écran et vidéos de présentation localisées. Le binaire passe pariTMSTransporterd'Apple ; les métadonnées transitent par l'API App Store Connect. Il peut aussi soumettre en revue après l'envoi.supply(Android). Envoie les métadonnées, captures d'écran et l'APK ou l'AAB vers Google Play, en choisissant une piste et en promouvant les builds. Attention au point sensible : les captures d'écran envoyées remplacent celles déjà présentes pour une langue au lieu de s'y ajouter.
Les deux s'authentifient avec des clés d'API — une clé API App Store Connect pour Apple, un JSON de compte de service pour Google — donc une fois configurés, ils tournent en toute autonomie dans la CI. C'est tout l'intérêt : métadonnées et captures d'écran comme du code, versionnées dans votre dépôt, livrées à chaque build.
Le vrai coût de fastlane
fastlane est gratuit à installer et à exécuter. Le coût est celui de la mise en place et de l'entretien, et il se paie en temps d'ingénierie.
- Un environnement d'exécution à maintenir. fastlane est une chaîne d'outils Ruby (Ruby 3.0+), généralement gérée avec Bundler. Le travail iOS nécessite Xcode sur un Mac ; Android nécessite le côté Gradle. C'est de la vraie mécanique à installer et à garder à jour.
- Des fichiers de configuration à écrire. Un
Fastfiledéfinit vos lanes ; unDeliverfileou le dossier de métadonnées Android contient les détails de la fiche. Obtenir une première version fonctionnelle prend généralement un jour ou deux. - Une CI à mettre en place. L'automatisation ne paie que dans un pipeline, ce qui implique des clés d'API, des secrets de signature, et un runner de build configuré et maintenu vert.
- L'entretien de la capture d'écran, si vous l'utilisez.
snapshotde fastlane pilote des tests UI dans le simulateur pour capturer des captures d'écran par langue. Ces tests sont fragiles : un retour d'expérience courant est qu'une configuration fonctionne bien pendant quelques mois, puis un changement d'interface casse le flux et il faut refaire naviguer le test vers les nouveaux écrans. snapshot relance par défaut les exécutions instables, ce qui masque le non-déterminisme lié au réseau et aux données plutôt que de le corriger. Et la sortie brute n'a ni légendes ni arrière-plans — les équipes finissent souvent le design dans un outil séparé de toute façon.
Rien de tout cela n'est un reproche envers l'outil. C'est le compromis honnête : fastlane transforme une corvée manuelle récurrente en code, et en échange vous maintenez du code. Pour une équipe qui livre chaque semaine avec un ingénieur qui possède l'automatisation des releases, c'est une bonne affaire. Pour un créateur solo ou un PM qui met à jour une fiche quelques fois par an, le pipeline peut coûter plus cher à maintenir en vie qu'il ne fait économiser.
Mettre à jour une fiche sans fastlane
Si vous vous passez de fastlane, il vous reste trois façons de mettre métadonnées et captures d'écran sur les stores.
1. Les consoles web des stores
Le chemin le plus simple. Dans App Store Connect, vous modifiez chaque localisation à la main et déposez les captures d'écran dans les emplacements de taille d'affichage ; dans Google Play Console, vous modifiez la fiche du store par langue et y importez les captures d'écran. Pas de code, pas de clés, rien à maintenir — vous cliquez, c'est fait. L'inconvénient, c'est que tout est entièrement manuel, et le faire sur de nombreuses langues, un écran à la fois, est lent et source d'erreurs. Correct pour une ou deux langues ; pénible à 20.
2. Les API des stores, directement
Les deux stores exposent les mêmes API que fastlane appelle, vous pouvez donc écrire vos propres scripts sans adopter la pile Ruby de fastlane. L'API App Store Connect d'Apple est une API REST authentifiée par un JWT de courte durée (ES256, signé avec votre clé), avec des endpoints pour créer des ensembles de captures d'écran, réserver et envoyer des octets d'image, et corriger les métadonnées. L'API Play Developer de Google utilise un modèle « edits » — vous ouvrez une modification, changez fiches et images, puis la validez. Cela vous donne un contrôle total et convient à un tableau de bord interne sur mesure, mais vous écrivez et maintenez désormais cette intégration vous-même. C'est un engagement moindre qu'un pipeline fastlane complet, pas un engagement nul.
3. Un outil géré qui rédige la fiche
L'autre voie sans code est un outil qui produit la fiche à votre place, il ne reste alors qu'à la mettre sur le store. C'est là que le compromis s'inverse : au lieu qu'un ingénieur possède un pipeline, un PM ou un designer possède la fiche directement dans un navigateur. Vous échangez l'automatisation CI contre l'absence totale de besoin d'un ingénieur.
Où se situe Mokbi — en toute honnêteté
Mokbi n'essaie pas de remplacer l'histoire CI de fastlane. Si votre objectif est des captures d'écran qui se régénèrent à chaque build sans humain dans la boucle, un pipeline fastlane est le bon outil et il est gratuit. Nous sommes là pour l'autre cas : la personne qui veut publier une fiche soignée sans toucher à Ruby, Xcode, un Fastfile, ou un test UI.
Dans le navigateur, vous concevez les captures d'écran, rédigez le texte de la fiche, et traduisez toute la fiche en 50 langues — sans simulateur, sans CI, sans code. Un designer ou un PM peut posséder toute la surface marketing de bout en bout.
Voici le dernier kilomètre, et Mokbi le couvre. Il conçoit les captures d'écran et le feature graphic, rédige et traduit toute la fiche en 50 langues, puis pousse le résultat directement vers Google Play via la Play Developer API et prépare la version App Store dans App Store Connect, prête pour que vous cliquiez sur Soumettre — Apple exige que cette soumission finale et sa revue soient faites par vous, c'est une règle d'Apple, pas une lacune de notre côté. Les mêmes endpoints que fastlane appelle, sans le pipeline.
Quand choisir quoi
- Vous livrez chaque semaine, avez un ingénieur, voulez zéro dérive ? fastlane. C'est gratuit, automatisé, et ça garde captures d'écran et métadonnées en parfaite synchronisation avec l'app. Rien ici ne fait mieux.
- Vous mettez à jour une fiche quelques fois par an, sans CI à consacrer ? La console web, ou un outil qui rédige la fiche. L'entretien du pipeline n'en vaut pas la peine à ce rythme.
- Besoin d'un contrôle programmatique mais pas de la pile de fastlane ? Appelez directement les API App Store Connect et Play Developer.
- Vous voulez qu'un designer ou un PM possède la fiche dans de nombreuses langues ? Rédigez, traduisez et publiez depuis le navigateur — Mokbi pousse vers Google Play et prépare la version App Store, prête à être soumise.
fastlane mérite sa place en tant qu'acteur historique gratuit et automatisé. Le chemin sans code n'est pas « meilleur » — c'est un compromis différent : vous renoncez à l'automatisation CI, et en échange personne n'a besoin de construire ou de surveiller un pipeline pour mettre à jour une fiche.