Le symptôme : vos captures changent selon la langue ou la session de test. Le correctif : configurez fastlane snapshot avec des tests d’interface, puis fixez les langues, les simulateurs et les données de test avant de contrôler les images une par une.
Cette méthode convient aux développeurs indépendants qui veulent éviter les captures manuelles répétées, aux équipes qui localisent une app destinée à plusieurs marchés et aux petites équipes qui exécutent leurs tests sur un Mac distant. La génération, le contrôle des spécifications et le téléversement restent des opérations distinctes.
SECTION 01Développeur solo : sécuriser d’abord le parcours de capture
Si vous maintenez une app dans une seule langue, ne commencez pas par multiplier les appareils et les langues. Vérifiez d’abord qu’un test d’interface Xcode atteint de façon reproductible l’écran à capturer, puis ajoutez la génération d’images. Vous éviterez ainsi de confondre un échec de navigation avec un problème de configuration de fastlane snapshot.
Une capture dépend de l’état réel de l’app au moment où le test arrive sur l’écran : session déjà ouverte ou non, contenu présent, permissions accordées, chargement terminé et fenêtre de dialogue éventuelle. Si ces conditions varient entre deux exécutions, deux images issues du même scénario peuvent présenter des différences qui n’ont rien à voir avec la langue.
Procédez dans cet ordre :
- Choisissez un écran représentatif et écrivez un test qui l’ouvre sans intervention manuelle.
- Préparez des données de test prévisibles. Écartez, pour ce parcours, les contenus personnalisés qui varient selon l’utilisateur ou l’heure.
- Attendez un état visible et déterminé plutôt qu’un délai choisi au hasard. Si le contenu arrive de manière asynchrone, vérifiez dans le test que l’élément attendu est présent.
- Lancez le test sans demander immédiatement toutes les langues et toutes les tailles d’écran.
- Ouvrez les images créées et comparez leur contenu avec l’écran attendu. Une exécution réussie ne garantit pas que l’image est exploitable pour une fiche de boutique.
La documentation de fastlane consacrée au flux de génération des captures décrit l’usage de tests automatisés et la configuration de langues et d’appareils. Dans votre projet, vérifiez aussi le schéma utilisé par le test et les conditions de lancement : une cible de test différente ou un état initial incomplet peut produire des captures manquantes ou trompeuses.
À retenir : une image vide n’est pas nécessairement un défaut de l’outil de capture. Le test peut avoir échoué avant d’atteindre l’écran, ou avoir enregistré l’image pendant son chargement.
SECTION 02Développeur d’une app localisée : distinguer langue et état de l’app
Pour une app distribuée dans plusieurs langues, la liste des locales ne suffit pas. Il faut également confirmer que le test démarre dans la langue voulue et que l’écran affiche effectivement les traductions attendues. Une image enregistrée dans un dossier au nom correct ne prouve pas, à elle seule, que son interface est localisée.
Dans la configuration documentée par fastlane, les paramètres languages et devices servent à déclarer les langues et les appareils visés ; output_directory permet de préciser le dossier de sortie. Ce sont des clés de configuration à contrôler dans votre projet, et non une garantie que chaque locale ou chaque destination sera disponible dans l’environnement d’exécution. Consultez la documentation des paramètres de l’action snapshot et comparez ses indications à votre version de la chaîne d’outils.
Une configuration lisible peut, par exemple, déclarer les locales fr-FR et en-US, choisir des destinations adaptées à votre app et définir un dossier de sortie explicite. Ces valeurs sont des exemples de configuration, pas une recommandation universelle : retenez les locales réellement prises en charge et les destinations installées dans votre environnement. Le nom du schéma de test doit également correspondre à celui du projet.
Pour chaque langue, validez ces éléments :
- Texte traduit : vérifiez les titres, boutons, libellés et messages d’erreur visibles. Une chaîne de remplacement ou une valeur manquante peut passer inaperçue si vous ne relisez que le nom du fichier.
- Mise en page : contrôlez les libellés longs, les retours à la ligne, les boutons rapprochés et les éléments qui risquent de sortir de l’écran.
- Données localisées : observez les dates, les nombres et les contenus affichés par l’app. Leur forme peut changer sans que la traduction des chaînes soit en cause.
- État du scénario : assurez-vous que chaque test montre le même écran, avec les mêmes données utiles, plutôt qu’une page d’accueil différente selon la langue.
Apple explique comment tester les localisations lors de l’exécution de l’app. Utilisez cette documentation pour distinguer la langue réellement appliquée à l’exécution de la langue supposée par votre configuration. Apple décrit aussi la création de captures destinées aux équipes de localisation : ce processus aide à examiner les chaînes dans leur contexte, mais ne remplace pas le contrôle des visuels préparés pour la boutique.
Comment vérifier que fastlane snapshot a utilisé la bonne langue ? Relisez l’interface de l’image produite, pas seulement le nom du répertoire. Contrôlez au minimum les libellés déterminants et les données visibles, puis comparez le résultat avec la locale demandée et les réglages du test.
SECTION 03Équipe de localisation : choisir les simulateurs pour une vraie différence d’interface
La taille de la matrice ne constitue pas une preuve de couverture. Sélectionnez les simulateurs en fonction des appareils pris en charge par votre app et des différences d’affichage qui peuvent affecter les écrans retenus. Si deux destinations ne révèlent aucune variation utile pour votre parcours, les ajouter augmente le travail de contrôle sans nécessairement améliorer vos visuels.
La documentation Apple sur l’exécution d’une app sur des appareils simulés ou physiques permet de vérifier les principes de sélection des destinations. Dans votre projet, distinguez les deux objectifs suivants :
- La couverture des appareils sert à repérer les écarts d’interface et les problèmes propres aux destinations testées.
- La validation des éléments de boutique consiste à vérifier que les images finales respectent les exigences applicables aux emplacements où vous souhaitez les publier.
Un test réussi sur un simulateur ne confirme donc pas automatiquement que la capture convient à toutes les fiches de boutique. De même, produire une image destinée à une taille d’écran donnée ne démontre pas que votre app a été testée sur toutes les configurations pertinentes. Les exigences de soumission sont définies séparément dans les spécifications de captures d’écran d’App Store Connect ; vérifiez celles qui correspondent à vos appareils et aux emplacements visés avant la livraison.
Si vous utilisez des plans de test, répartissez les configurations en fonction de leur rôle : parcours principal, langues nécessaires et destinations qui révèlent une variation d’interface. La documentation Apple sur l’organisation des tests pour améliorer les retours peut vous aider à structurer ces tests. Évitez de créer des variantes uniquement parce qu’elles sont faciles à ajouter : chaque combinaison supplémentaire doit avoir une raison de contrôle et un résultat attendu.
Le simulateur peut-il produire des captures pour plusieurs tailles d’appareil ? Oui, fastlane snapshot peut être configuré pour traiter plusieurs destinations déclarées. Toutefois, la disponibilité dépend de l’environnement et de la configuration du projet ; vérifiez les simulateurs effectivement installés et examinez séparément les fichiers obtenus. La couverture des destinations ne remplace pas l’acceptation des spécifications de soumission.
SECTION 04Équipe qui maintient les tests : isoler les causes d’instabilité
Une capture instable a souvent plusieurs causes possibles : chargement réseau, animation encore visible, fenêtre système, contenu variable ou chemin de test qui ne revient pas au même écran. Traitez ces causes dans le test avant d’ajouter des mécanismes de relance ; autrement, vous risquez de masquer un défaut de reproductibilité au lieu de le corriger.
Pour les animations, définissez un état d’écran contrôlable ou choisissez un point du parcours où l’interface est stabilisée. Pour les données dynamiques, utilisez un jeu de données de test maîtrisé. Si l’app dépend d’un service extérieur, prévoyez une réponse connue pour les tests concernés ou identifiez clairement les cas où la disponibilité de ce service peut interrompre la capture.
Lorsqu’une exécution échoue, conservez les éléments qui permettent de comprendre où elle s’est arrêtée : résultat du test, journaux disponibles et images créées. Classez ensuite l’incident dans une catégorie précise :
- Test interrompu avant l’écran : l’automatisation ne prouve pas que le parcours de capture a été terminé.
- Test terminé, image absente : contrôlez la configuration de capture, le dossier déclaré et les résultats produits par l’action.
- Image présente, contenu incorrect : examinez la langue, l’état des données et le moment où l’image a été prise.
- Image visuellement correcte, format à valider : passez au contrôle des exigences de la boutique, sans déduire la conformité du seul succès du test.
Ce tri évite de modifier simultanément les locales, les simulateurs et le test, ce qui rendrait la recherche de cause plus difficile. Après un changement, relancez le parcours concerné et comparez le résultat avec les images conservées comme référence.
SECTION 05Petite équipe sur Mac distant : rendre l’exécution vérifiable
Un Mac distant permet de lancer les tests d’interface dans un environnement macOS, mais il ne rend pas automatiquement la tâche déterministe. Avant l’exécution, fixez la révision du projet, le schéma, la configuration de test, les locales, les destinations et le chemin de sortie. Contrôlez ensuite que les outils et les simulateurs nécessaires sont présents dans la session utilisée.
Le fait qu’un simulateur puisse être lancé ne signifie pas que toutes les destinations demandées sont installées. Ne déduisez pas non plus de la disponibilité de la session que les tests seront stables : les conditions de lancement, l’état du projet et les dépendances restent à vérifier. Dans un flux distant, prévoyez un emplacement où les journaux et les captures resteront accessibles après la fermeture de la session, puis consignez la révision testée et les options utilisées.
Les contrôles opérationnels à intégrer au travail de l’équipe sont simples :
- confirmer le projet et le schéma effectivement testés ;
- vérifier les locales et les simulateurs configurés par rapport aux ressources disponibles ;
- exécuter le parcours et conserver le résultat du test ;
- inventorier les images présentes dans le dossier prévu ;
- relire les captures avant de les transmettre à la personne chargée de la publication.
Où retrouver les captures, et comment repérer un lot incomplet ? Le paramètre output_directory permet d’indiquer le dossier où fastlane doit déposer les images. Choisissez un chemin explicite, puis comparez le contenu obtenu aux langues, destinations et écrans prévus dans votre lot. Un dossier créé ne prouve pas que toutes les combinaisons attendues ont abouti ; consultez également les résultats des tests et les journaux de l’exécution.
SECTION 06Responsable de la livraison : séparer génération, contrôle et téléversement
Une capture générée n’est pas encore une capture prête à publier. Faites du contrôle éditorial et technique une étape distincte : vérifiez que l’écran raconte bien ce que vous souhaitez montrer, que les chaînes sont correctes et que l’image ne contient ni donnée personnelle ni contenu temporaire. Passez ensuite aux exigences de taille et de format applicables à l’emplacement de destination.
Pour chaque lot, consignez les langues demandées, les destinations choisies, les écrans attendus et le dossier effectivement contrôlé. Si une image manque ou ne convient pas, gardez le lot en attente au lieu de téléverser les autres fichiers en supposant que l’ensemble est complet. Les instructions Apple pour téléverser les aperçus et les captures décrivent l’étape de dépôt dans App Store Connect ; le référentiel de l’API App Store Connect sur les captures d’écran documente également les ressources associées. Ni l’une ni l’autre ne transforme une exécution locale réussie en confirmation automatique d’acceptation ou de publication.
| Approche | Atout principal | Limite à anticiper | À choisir si… |
|---|---|---|---|
| Captures manuelles | Contrôle visuel immédiat de chaque écran | Les manipulations et les conditions de prise doivent être répétées pour chaque langue et destination | Vous préparez ponctuellement quelques visuels et pouvez vérifier chaque fichier à la main |
| fastlane snapshot avec tests d’interface | Répétition du parcours et génération organisée à partir de la configuration du projet | La qualité dépend de la stabilité du test, des simulateurs disponibles et de la relecture des images | Vous devez régénérer un ensemble de captures dans un flux de développement suivi |
| Téléversement dans App Store Connect | Dépôt des éléments contrôlés dans l’espace de gestion de l’app | Cette opération intervient après la génération et la validation ; elle ne vérifie pas votre scénario de test | Les fichiers sont déjà sélectionnés et conformes aux exigences applicables |
SECTION 07Environnement de travail : arbitrer entre poste local et Mac distant
Un poste local convient si vous disposez déjà d’un Mac disponible, si les exécutions sont ponctuelles et si l’espace de travail nécessaire ne perturbe pas vos autres tâches. En revanche, un projet qui conserve de nombreux simulateurs et répète régulièrement les tests peut mobiliser le stockage et la disponibilité de cette machine ; une exécution liée à une session ouverte est aussi moins adaptée à un traitement que vous voulez reprendre ou surveiller à distance.
Un environnement distant peut être pertinent si vous souhaitez isoler les tests de votre poste principal ou laisser une tâche tourner dans une session accessible à l’équipe. Il faut néanmoins accepter de préparer le projet et les simulateurs sur cette machine, de vérifier la persistance des journaux et des fichiers, et de valider concrètement les accès nécessaires. Si vous comparez cette option à un achat ou à une autre organisation de travail, consultez les tarifs de MACNOX et confrontez-les à votre fréquence d’exécution, à la durée d’usage prévue et aux contraintes d’accès physique.
Avant d’adopter un Mac distant pour vos captures, vérifiez le parcours complet : lancement des tests, disponibilité des destinations, récupération des images et accès aux résultats après la session. Une tâche qui se lance n’est pas encore un processus de livraison fiable tant que l’équipe ne peut pas examiner ses preuves et reprendre le travail en cas d’échec.
Si les captures sont occasionnelles, votre Mac actuel restera probablement le choix le plus direct. Si le travail doit être répété sans immobiliser votre poste, un Mac loué peut éviter l’achat d’une machine dédiée, tout en demandant un contrôle explicite de l’environnement et des sorties. Dans ce cas, vous pouvez examiner les options de commande MACNOX après avoir défini la matrice réelle de langues et de simulateurs ; pour une charge durable et constamment élevée ou un besoin d’interfaces physiques, évaluez d’abord si la location correspond réellement à votre usage.