Comment Générer des Captures d’Écran App Store avec Cursor : Guide Étape par Étape

Si vous faites partie des nombreux développeurs qui ont déplacé une partie de leur workflow dans Cursor — l’assistant de codage IA/éditeur pour hackers qui fait fureur sur la scène indie de Twitter — vous avez probablement votre code, vos commits et vos tests qui tournent tous dans cette fenêtre. Mais publier une app, c’est plus que du code. À un moment donné, il faut des captures d’écran à fort taux de conversion pour l’App Store ou Google Play, et celles-ci freinent votre élan comme aucun docstring ne saurait le faire.

Voici comment je construis un ensemble de captures d’écran prêtes pour le store, iOS et Android, directement depuis mon Mac — principalement dans Cursor, avec un bref passage par le navigateur pour la génération et l’export. C’est un workflow rapide et itératif. Si vous voulez transmettre à un designer ou qu’il peaufine sur Figma, vous vous êtes trompé de page. Si vous détestez perdre une journée à exporter dix fois les PNG du simulateur et à refaire le même layout, poursuivez votre lecture.

Étape 1 : Capturez vos captures du simulateur

Lancez votre app dans le simulateur Xcode ou sur un appareil connecté. Pour App Store Connect, vous aurez besoin d’images dans plusieurs tailles. Sur iOS, privilégiez absolument des captures du 6,7" (iPhone 14/15 Pro Max, 1284x2778) et 6,5" (iPhone 12/13 Pro Max, 1242x2688). Pour Android, Google Play liste toutes les tailles d’appareils possibles, mais 1080x1920 est la taille médiane pour les téléphones. Les docs Apple détaillent les dimensions requises, mais ils déprécient régulièrement des appareils, vérifiez donc les exigences d’App Store Connect avant de perdre du temps.

Pour faire une capture dans le simulateur, Command+S enregistre un PNG sur votre bureau. (Si vous êtes à l’ère iOS 17 et que le raccourci ne marche plus, essayez Fichier > Enregistrer la capture d’écran.) Pour Android, lancez votre app dans l’émulateur Android Studio et appuyez sur le bouton caméra ou Control+S. Synchronisez-les dans le dossier /screenshots de votre projet si vous voulez tout garder versionné — Cursor facilite grandement la gestion des dossiers, alors aucun doute à avoir.

Étape 2 : Sélectionnez les écrans à utiliser

Ne balancez pas tous les écrans dans la fiche app. Vous voulez un maximum de 5, qui présentent les flux les plus soignés : onboarding, fonctionnalité principale, paywall, et (si votre app est B2B ou heavy workflow) tout écran qui montre rapidement la valeur. Si les captures nécessitent des données utilisateurs, utilisez un contenu démo réaliste — des états trop vides tuent la conversion. Je me réfère à l’ordre d’écrans sur les apps les mieux classées dans votre catégorie (ex : Duolingo, Sudoku.com). Évitez les espaces vides longs ou tout ce qui pourrait ressembler à un bug.

Étape 3 : Vérifiez les directives du store et les limites de texte

Apple rejette à la validation pour débordements de texte, logos sous copyright ou artefacts UI. Google est un peu plus souple sur la finition, mais veut quand même des captures qui représentent la vraie fonction de l’app. Si vous comptez superposer du texte, limitez les callouts à une phrase (20–30 caractères, comprend une accroche, soit environ la moitié de la largeur d’écran iPhone en 14pt). Pour la localisation, prévoyez des phrases plus longues en allemand ou en russe que le simple anglais.

J’ai vu des apps de productivité de niche perdre des semaines à ajouter des traductions. Sauf si vous êtes déjà dans le top 100 de votre pays d’origine, zappez la localisation au lancement et revenez-y plus tard, quand vous aurez du trafic international réel.

Étape 4 : Générer des captures prêtes pour le store avec ScreenshotWhale

Ici, le workflow quitte Cursor quelques minutes. Les captures brutes de simulateur ont un look trop "dev" : barres vides, fonds durs et mauvais recadrages. Pour convertir, à la manière des pros derrière Headspace ou Calm, il faut des cadres brandés, des bordures d’appareils et des textes concis. Les modèles Figma font le taf (en partie), mais pour la rapidité et la cohérence, je génère les miennes avec ScreenshotWhale. Ils proposent des templates éditables avec cadres d'appareils modernes et tailles App Store/Google Play. Téléchargez vos PNG, glissez les captures dans les templates, écrivez vos légendes et choisissez les accents de couleur. Tout s’exporte aux dimensions pixels exactes demandées par chaque store. Vous pouvez faire quelques retouches (recadrage ou type d’appareil) directement dans le navigateur, bien plus simple que d’ouvrir Sketch ou Affinity Designer pour chaque petit ajustement.

Si vous avez une couleur de marque, appliquez-la en fond avant l’export. (Il y a toujours un fondateur qui aime les dégradés pastel comme en 2021. Évitez le texte pâle sur fond clair — la lisibilité prime toujours.) Si l’interface de votre app est en mode sombre, choisissez un style de template assorti pour une continuité optimale ; ne forcez pas un cadre de téléphone blanc sur une UI majoritairement noire.

Étape 5 : Exporte et organisez les ensembles finaux

Exportez les tailles individuelles demandées par chaque store (App Store Connect : 6,7", 6,5" ; Google Play : 1080x1920 ou ce que demande le formulaire pour tablettes ou téléphones). Certains devs sautent les anciens iPhones ou iPads au lancement — Apple va redimensionner les captures 6,7", mais vérifiez bien la mise en page sur ces écrans ou vous aurez du UI coupé et des soucis de support. Sauvegardez vos fichiers avec des noms clairs : 01-onboarding-iphone15pro.png au lieu de IMG_8432.png. Je garde un historique des versions des captures dans le repo, surtout pour les apps qui itèrent chaque semaine ou font de l’A/B testing visuel.

Bonus : Automatiser les rounds de captures

Si vous scriptiez des builds ou visez un processus de release piloté Markdown dans Cursor, vous pouvez connecter des scripts shell (outils en ligne de commande Simulator, adb pour Android) pour sortir des captures à chaque build. Envoyez les images brutes vers un dossier cloud, puis importez dans ScreenshotWhale pour générer les visuels. Je n’ai pas encore automatisé complètement cette étape avec les API de publication, mais je connais des testeurs qui tournent des pipelines de captures end-to-end automatisées. Plus vous publiez, plus votre temps vaut cher — ne le perdez pas en tâches répétitives.

Quid du UI généré par IA ?

Si votre app est basée sur l’IA ou orientée UI (pensez à Arc, Lensa AI ou n’importe quelle appli de retouche photo), vos captures doivent montrer à la fois le produit et la magie. Les complétions de chat ou bouts de code dans Cursor ne suffisent pas. Il vous faut des visuels qui suscitent le désir, pas juste qui documentent la fonctionnalité. Parfois, j’utilise Midjourney ou DALL-E pour créer un fond aspirational, mais dans 99% des cas, les superpositions sur UI réelle battent les rendus fantaisistes. Trop de polish artificiel vous fera blacklister si votre app ne peut pas réellement afficher ces visuels.

Soumission et mises à jour

Une fois que vous avez vos captures, chargez-les directement dans App Store Connect ou Play Console. Vérifiez bien les uploads sur fonds clairs et foncés ; l’App Store montrera surtout vos visuels sur fond blanc, tandis que Play les affichera parfois sur fond noir. Une légère erreur d’alignement plombe rapidement votre taux de conversion. Si vous voyez des bugs de rendu en aperçu store, régénérez et exportez à nouveau — ne vous contentez pas du premier essai, les reviewers ne le feront pas.

Je teste les fiches finales sur appareils réels via le beta public TestFlight ou les tracks internes Google Play — faites appel aux retours users via DMs ou un tweet pour avoir des yeux frais. C’est là que la plupart des bugs et mauvais recadrages sont détectés, pas dans l’éditeur.

Dernier conseil : vitesse plutôt que perfection

Cursor est conçu pour la rapidité dev, pas le design. Privilégiez des rounds rapides et reproductibles de captures plutôt que du pixel perfect une fois pour toutes. La plupart des indies surinvestissent dans leur premier set de captures et finissent par le remplacer après lancement. Livrez quelque chose de propre et ciblé, mettez à jour au fil des retours, et gardez vos cycles pour livrer des fonctionnalités, pas pour chipoter des pixels de capture pendant des jours.