Comment j'ai automatisé mes screenshots ASO multilingues avec des agents IA

Pendant longtemps, les screenshots App Store faisaient partie de ces tâches que je repoussais sans arrêt.

Pas parce que c’est compliqué au sens noble du terme. Plutôt parce que c’est le genre de taf pénible qui te grignote la journée sans que tu t’en rendes compte. Tu commences en te disant “je vais juste sortir 6 screens” et une heure plus tard tu es encore en train de déplacer un texte, rerun un export, renommer des fichiers, puis refaire exactement la même chose dans une autre langue.

Au bout d’un moment, j’ai arrêté de voir ça comme une tâche design. J’ai commencé à le voir comme un problème de système.

Et là, tout a changé.

Le vrai problème n’était pas le screenshot

Ce qui me saoulait, ce n’était pas juste capturer des écrans. C’était tout ce qu’il y avait autour :

• retrouver les bons écrans
• se souvenir du bon format
• gérer plusieurs tailles
• gérer plusieurs langues
• ranger les exports au bon endroit
• remplacer les vieux fichiers sans casser Fastlane
• corriger les problèmes de layout quand le texte déborde ou se fait couper

Le screenshot en lui-même prend 2 secondes. Le process autour, lui, te vide la tête.

Quand tu as une seule app, tu peux encore bricoler. Quand tu commences à avoir plusieurs produits, plusieurs stores, plusieurs itérations, ça devient un piège à temps.

Mon objectif

Je voulais un système qui sache faire 4 choses :

1. partir du vrai produit, pas d’un mockup inventé
2. sortir les bons formats sans que j’aie à me rappeler les specs
3. réutiliser la même logique pour plusieurs langues
4. corriger la plomberie technique sans me faire replonger dedans à la main

Autrement dit, je ne voulais pas “un prompt qui génère une belle image”. Je voulais une chaîne de production.

Le déclic : traiter ça comme de l’infrastructure

La bascule mentale a été simple.

Au lieu de me dire :

il faut que je fasse des screenshots

je me suis dit :

il faut que je construise un workflow reproductible pour les screenshots

C’est une nuance, mais elle change tout.

Quand tu penses “tâche”, tu optimises pour finir vite. Quand tu penses “système”, tu optimises pour ne plus avoir à repenser la même chose deux semaines plus tard.

La stack que j’utilise aujourd’hui

J’ai séparé le sujet en plusieurs couches.

1. Le contexte produit (déjà là)

Chaque app dans mon workspace a une fiche produit : positionnement, features clés, style visuel, public cible. C’est le même fichier que tous les agents utilisent pour le marketing, le SEO, l’ASO, je ne l’ai pas écrit pour les screenshots spécifiquement.

L’agent lit ce contexte, et à partir de là il décide tout seul :

• quels écrans capturer
• quels textes marketing mettre sur les slides
• combien de slides produire
• quels formats exporter
• où ranger les fichiers

Je n’ai écrit aucun brief screenshot. L’agent a le contexte produit, il a le skill, et il se débrouille. C’est toute la différence avec un process manuel où tu dois tout spécifier à chaque fois.

2. Un skill dédié au workflow ASO

Le point le plus important, c’est ça.

Quand je demande des screenshots ASO, je veux que l’agent comprenne automatiquement :

• on utilise le workflow screenshot
• on part du renderer prévu ou de la web app
• on vise un vrai format store
• on ne part pas sur une génération d’image freestyle

Ça paraît évident après coup, mais si tu ne l’écris pas noir sur blanc, un agent peut prendre un raccourci “techniquement acceptable” mais faux par rapport à l’intention.

C’est exactement ce qui m’est arrivé sur Muse Otter au début.

Le cas Muse Otter : la bonne taille, le mauvais device

Je voulais 6 screenshots iPad.

Le premier export avait bien les dimensions iPad. Sauf que le renderer utilisait encore un mockup iPhone. Donc j’avais des fichiers qui avaient l’air corrects sur le papier, mais visuellement c’était faux.

C’est le genre de détail qui paraît petit si tu regardes juste le dossier final. En vrai, ça ruine tout.

J’aurais pu dire “bon, ça passe”. Mais justement, c’est là que l’approche agentique m’intéresse : si une brique est fausse, on corrige la brique. On ne maquille pas le résultat.

J’ai donc fait corriger le renderer pour ajouter un vrai mode iPad. Puis on a rerendu les 6 slides. Puis on a découvert un deuxième problème : le mockup était bon, mais le layout bouffait le texte.

Donc deuxième passe :

• safe zones plus larges
• taille de headline réduite
• meilleure position du mockup
• moins d’espace mort en bas
• rerender complet
• remplacement des fichiers dans Fastlane

C’est exactement ce que je cherchais : un système qui n’essaie pas de me faire plaisir avec une sortie moyenne, mais qui permet d’itérer jusqu’à obtenir le bon rendu.

Ce que les agents font vraiment dans ce process

Je pense qu’on fantasme souvent les agents comme des espèces de remplaçants humains magiques.

Moi, je les utilise plutôt comme une équipe qui prend en charge la partie répétitive et fragile.

Concrètement, après avoir setup le système (le contexte produit + le skill + le repo open-source du renderer), je n’ai plus rien fait manuellement. L’agent :

• ouvre l’app web déployée dans un navigateur headless
• navigue dans les écrans et prend les captures lui-même
• corrige les ratios (le rendu Flutter web n’est pas en ratio iPhone)
• génère les mockups via le renderer (ParthJadhav/app-store-screenshots), cadre device, headline marketing, couleurs de la brand extraites du code source
• exporte aux tailles requises
• copie dans Fastlane

Et quand il faut une vraie modif technique (ajouter le mode iPad au renderer par exemple), je la délègue à un agent d’ingénierie.

Moi, je ne me tape pas le tunnel de 25 petites actions sans intérêt. Je valide le résultat final, c’est tout.

Pourquoi le multilingue est la vraie raison de faire ça

Honnêtement, si tu fais un seul set en une seule langue, tu peux encore te débrouiller à la main.

Le vrai cauchemar commence quand tu veux faire :

• anglais
• français
• plusieurs devices
• plusieurs apps
• et plusieurs itérations dans le mois

Là, refaire les choses à la main devient absurde.

Avec une chaîne bien construite, le multilingue n’est plus un deuxième projet. C’est juste une autre entrée dans le système.

Tu changes les strings. Tu vérifies le layout. Tu exportes.

Si un texte FR casse la mise en page, ce n’est pas un drame artisanal. C’est un bug de compo qu’on corrige une fois.

Et ça, c’est la différence entre produire du contenu et construire de l’infrastructure marketing.

Ce que ça m’a réellement fait gagner

Le gain n’est pas juste “du temps”. C’est trop vague de dire ça.

Le vrai gain, c’est surtout :

• moins de friction au moment de lancer une itération
• moins d’erreurs bêtes
• moins de charge mentale
• moins de micro-décisions sans valeur

Je n’ai plus besoin de me souvenir :

• où mettre les exports
• quel format utiliser
• quelle source capture pour quel slide
• si je dois passer par la web app ou par un projet screenshot
• comment renommer les fichiers pour Fastlane

Le système absorbe ça à ma place.

Et franchement, c’est ça qui me plaît dans l’automatisation agentique. Pas le côté “wow IA”. Le côté “je peux enfin garder mon cerveau pour les décisions qui comptent”.

Le plus intéressant : ce n’est pas limité aux screenshots

Le plus fort dans cette histoire, ce n’est pas juste que j’ai automatisé mes screenshots ASO.

C’est que le pattern se réutilise partout.

Quand tu as :

• de la mémoire projet
• des skills clairs
• des agents avec des rôles précis
• des dossiers bien rangés

alors plein de tâches marketing pénibles commencent à devenir automatisables proprement :

• screenshots
• metadata ASO
• exports multilingues
• pages SEO
• contenu social
• variantes créa

À partir du moment où un process est répétitif, documentable et relou, il devient une bonne cible.

Ma conclusion

Automatiser mes screenshots ASO, ce n’était pas juste une petite optimisation d’indie hacker.

C’était une manière de me prouver un truc plus large : beaucoup de tâches qu’on traite encore comme des corvées ponctuelles méritent en réalité d’être traitées comme des systèmes.

Et quand tu fais ça, tu bosses différemment.

Tu ne pars plus d’un canvas vide à chaque demande. Tu pars d’une machine qui sait déjà presque quoi faire.

Et toi, tu reviens au bon niveau : choisir, arbitrer, corriger, diriger.

C’est probablement ça, au fond, la partie la plus intéressante de l’IA agentique pour un builder solo.

Pas remplacer le travail. Structurer tout ce qui te ralentit.