Avril 2027 : préparez les captures sans remplacer votre CI
Apple annonce que les applications et les jeux soumis à partir d’avril 2027 devront respecter les exigences de capture d’écran de l’iPhone Duo, selon son annonce officielle. Il faut dès maintenant inventorier les applications, les langues et les processus de production, puis ajouter un contrôle avant soumission. Cette évolution ne justifie pas, à elle seule, de changer de plateforme CI ni de nœud Mac.
Dernière mise à jour : 13 octobre 2026. Le calendrier et le périmètre ont été vérifiés dans l’annonce Apple, les spécifications de capture et les notes de publication App Store Connect.
Cet article s’adresse aux responsables de publication iOS qui coordonnent les ressources des pages produit.
Il est aussi destiné aux responsables CI qui veulent rendre les contrôles et preuves vérifiables.
Les équipes IT gérant plusieurs applications y trouveront une méthode pour intégrer cette évolution à leur gouvernance de publication.
Maintenant : distinguez la règle annoncée des tests de compatibilité
Une exigence de capture concerne les ressources visuelles associées à la fiche d’une application. Elle ne signifie pas, en elle-même, que vous devez prouver le bon fonctionnement de l’application sur un appareil en faisant produire ces images par un nouveau système de CI. Il s’agit de deux activités à planifier séparément : préparer les captures demandées et vérifier le comportement du logiciel sur les configurations ciblées.
Pour définir ce qui s’applique à votre portefeuille, commencez par l’annonce Apple, puis consignez son périmètre et sa date d’application dans votre calendrier de publication. L’annonce lie le changement aux applications ou jeux soumis à partir d’avril 2027 ; ce n’est pas une raison pour inscrire cette exigence comme déjà active dans vos contrôles actuels. Si une soumission est prévue avant l’échéance, référez-vous aux règles en vigueur à cette date et évitez d’imposer par anticipation une condition qui n’a pas encore pris effet.
Les spécifications officielles des captures sont la référence pour les caractéristiques acceptées. Les directives de conception pour iPhone Duo servent, elles, à guider l’expérience et la présentation de l’application. Ne confondez pas ces documents avec un rapport de tests de compatibilité : une image conforme ne prouve ni que les interactions fonctionnent ni que l’interface est correcte sur l’appareil visé.
Côté CI, conservez donc trois statuts distincts dans votre suivi : « capture attendue », « contrôle technique passé » et « expérience ou compatibilité vérifiée ». Le premier indique ce qu’il reste à produire, le deuxième ce que vos scripts peuvent valider et le dernier ce qui demande un examen fonctionnel ou visuel. Cette séparation limite les faux positifs dans vos tableaux de bord et évite qu’un contrôle de fichiers soit interprété comme une validation complète du produit.
Avant la production : inventoriez les ressources par application et par langue
Un simple dossier partagé de captures devient vite difficile à maintenir quand plusieurs applications, versions et langues sont publiées. Le premier livrable utile est un registre qui indique ce qui existe, ce qui manque et qui doit fournir la prochaine version. Vous pouvez le rattacher à votre système de gestion de versions ou au suivi de publication, à condition que les responsabilités et l’état de validation restent consultables.
| Élément à inventorier | Information à consigner | Décision de publication |
|---|---|---|
| Application et fiche produit | Identifiant interne, responsable produit et lien vers la fiche App Store Connect | Qui décide que les images représentent la version publiée ? |
| Langue et marché | Localisation attendue et état de révision du texte intégré à l’image | Une traduction ou une composition reste-t-elle à fournir ? |
| Version de l’application | Version concernée et lien vers le processus de publication | Les captures correspondent-elles à la version en cours de soumission ? |
| Fichiers disponibles | Emplacement, nom, format et résultat du dernier contrôle | Le contrôle automatique peut-il retrouver et lire les ressources ? |
| Appareil et périmètre | Exigence Apple applicable et règle interne de préparation | S’agit-il d’une obligation publiée ou d’une précaution décidée par l’équipe ? |
| Validation | Auteur, approbateur, date de revue et résultat | Qui peut autoriser la transmission des ressources ? |
Ne déduisez pas la couverture de la simple présence d’images dans un répertoire : une capture peut correspondre à une ancienne version, à une autre langue ou à une composition promotionnelle plutôt qu’à une représentation fidèle de l’application. Pour chaque ligne de l’inventaire, définissez un responsable de production et un approbateur distincts lorsque votre processus de publication l’exige. Si la même personne assure les deux rôles dans une petite équipe, notez-le explicitement plutôt que de laisser la responsabilité implicite.
Maintenez également deux champs séparés dans le registre : « exigence Apple » et « règle interne ». Le premier renvoie à un document officiel et à sa date de vérification ; le second permet d’indiquer, par exemple, qu’une équipe souhaite préparer des ressources avant leur date d’application. Cette distinction vous évite de communiquer une mesure anticipée comme si elle constituait déjà une condition d’acceptation.
Avant chaque série de captures : comparez le fichier au rendu réel
Avant de demander à l’équipe de créer ou de retoucher des images, ouvrez la page officielle des spécifications et relevez les valeurs applicables à la fiche concernée. Vérifiez les dimensions en pixels, l’orientation, les formats de fichiers et les emplacements de présentation attendus. Consignez la date de consultation et la version de vos règles internes : une liste copiée dans un ancien script ne devient pas fiable parce qu’elle est automatisée.
| Point de contrôle | Contrôle reproductible | Revue à conserver |
|---|---|---|
| Dimensions et orientation | Comparer les propriétés du fichier aux valeurs officielles applicables | Confirmer que le cadrage conserve les informations utiles |
| Type de fichier et lisibilité | Vérifier l’extension, l’ouverture et l’absence de fichier endommagé | Confirmer que l’image reste nette et compréhensible |
| Contenu représenté | Vérifier que l’écran correspond à une fonction réellement disponible | Repérer les données sensibles, textes provisoires ou états de test |
| Langue et fiche | Faire correspondre la ressource à la localisation attendue | Vérifier traduction, terminologie et cohérence avec la page produit |
| Règles de présentation | Comparer aux consignes de capture et de revue d’Apple | Confirmer que les éléments promotionnels n’altèrent pas la représentation du produit |
Les instructions Apple relatives à l’examen des captures sont importantes pour cette dernière vérification. Une image peut passer des contrôles élémentaires de fichier et pourtant être trompeuse, montrer une fonction indisponible ou présenter un état qui ne correspond pas au produit. Réservez donc une validation humaine à la fidélité de l’écran, au texte et à la composition.
Distinguez également une capture issue de l’application d’un visuel conçu pour la communication. Une maquette marketing peut mettre en scène un téléphone, ajouter des légendes ou intégrer une composition graphique ; elle ne doit pas être traitée automatiquement comme une preuve d’affichage réel. Les exigences de spécification déterminent les propriétés des ressources attendues, tandis que la revue vérifie leur contenu. Ne concluez pas qu’une capture obtenue dans un simulateur répond à toutes les attentes d’Apple : la documentation sur les formats ne constitue pas une garantie universelle d’acceptation de toute méthode de production.
Une image peut être techniquement lisible tout en restant inadaptée à la page produit. Gardez une étape de revue visuelle, même lorsque la validation des dimensions et du format est automatisée.
Pendant la production : attribuez la source, la version et l’approbation
Choisissez explicitement qui produit les ressources. Selon l’organisation, il peut s’agir de l’équipe produit, de QA ou d’un processus de publication. L’important est que la responsabilité ne change pas de façon tacite d’une version à l’autre. Enregistrez le fichier source, la langue, la version de l’application, la date de création et le résultat de la revue ; ces informations permettent de retrouver pourquoi une image a été acceptée ou remplacée.
Si vous produisez des captures au moyen de scripts ou d’outils Xcode, validez d’abord leur fonctionnement dans l’environnement réellement utilisé par votre équipe. La documentation de Xcode 27.1 est une référence pour les changements documentés dans cette version, mais sa présence ne prouve pas qu’un outil puisse générer, traduire, contrôler et soumettre à lui seul tous vos visuels. Testez séparément chaque étape et conservez les limites observées.
Pour des applications audio, vidéo ou de création, la revue mérite une attention particulière : les captures doivent rendre compréhensible le résultat obtenu, sans faire passer un contenu d’exemple ou une fonction de démonstration pour une capacité disponible dans l’application. Les équipes de design peuvent préparer les compositions ; QA peut confirmer l’état produit représenté ; l’équipe de publication peut, elle, attester que les fichiers sont associés à la bonne fiche et à la bonne version.
Avant soumission : ajoutez une porte de contrôle, pas une promesse d’acceptation
Une porte de contrôle CI utile répond à une question limitée : les ressources exigées par votre politique de publication sont-elles présentes et vérifiables pour cette application et cette langue ? Elle peut contrôler l’existence des fichiers attendus, leur ouverture, leurs propriétés pertinentes et leur association à une version. Elle peut ensuite générer un rapport conservé avec les éléments de preuve de la publication.
| Résultat de contrôle | Ce que la CI peut conclure | Ce qu’elle ne peut pas conclure seule |
|---|---|---|
| Fichier manquant ou illisible | La ressource attendue n’est pas prête pour la vérification | Que l’application entière est impropre à la publication |
| Format ou dimensions inattendus | Le fichier doit être corrigé ou revérifié au regard des règles actuelles | Qu’Apple rejettera nécessairement la soumission |
| Fichier présent et vérifié | Les contrôles techniques configurés ont réussi | Que le contenu visuel est fidèle ou qu’App Store Connect l’a accepté |
| Rapport lié à une version | L’équipe peut retrouver le résultat associé au candidat publié | Que l’étape de téléversement ou de revue a été achevée |
Choisissez votre conduite selon les conditions suivantes :
- Si chaque application et chaque langue ont une liste de ressources attendues, alors faites échouer le contrôle lorsqu’un fichier manque ; sinon, commencez par produire cet inventaire, sans bloquer toutes les équipes sur une règle encore indéfinie.
- Si les propriétés des fichiers peuvent être comparées aux spécifications actuelles d’Apple, alors automatisez ces vérifications et consignez la date de référence ; sinon, laissez le résultat en attente de revue et ne présentez pas le contrôle comme une conformité complète.
- Si le contrôle technique et la revue visuelle ont des responsables identifiés, alors reliez les deux états au dossier de publication ; sinon, demandez une validation manuelle avant soumission plutôt que de transformer un succès de script en autorisation implicite.
- Si les mêmes étapes fonctionnent dans votre environnement CI actuel, alors gardez-le ; sinon, isolez l’étape qui échoue et évaluez une évolution ciblée, sans attribuer automatiquement la difficulté à l’exigence de capture.
L’automatisation ne doit pas annoncer « accepté par App Store Connect » au seul motif que les fichiers passent vos règles. Le téléversement et l’affichage dans la fiche restent des opérations distinctes. Appuyez-vous sur le guide Apple consacré au téléversement des aperçus et des captures d’écran pour organiser cette étape et en vérifier le résultat dans l’interface.
Lors de l’essai : validez le parcours complet avant de le généraliser
Choisissez une application représentative, puis faites-la passer par le processus complet : inventaire, production, contrôle automatisé, revue visuelle, téléversement et prévisualisation de la fiche. Notez pour chaque étape le responsable, le fichier concerné, le résultat et les corrections nécessaires. L’objectif n’est pas de prouver que toutes les applications sont déjà prêtes, mais de découvrir où les responsabilités, les noms de fichiers ou les validations manquent.
Après l’essai, classez les échecs selon leur cause. Un fichier manquant appelle une amélioration de l’inventaire ou de l’attribution ; une propriété incorrecte appelle la mise à jour des consignes ou du validateur ; une image inexacte appelle une correction de production ou de revue. Si le téléversement est refusé ou si l’aperçu ne correspond pas à ce qui était attendu, vérifiez les consignes et le parcours App Store Connect avant de modifier votre chaîne de compilation.
Élargissez ensuite le processus aux autres applications en conservant un chemin de retour : qui retire temporairement une ressource invalide, qui autorise une soumission avec une exception interne, et où cette décision est archivée. Une exception de votre équipe ne modifie pas l’exigence Apple ; elle doit donc rester visible comme décision de gouvernance, avec son propriétaire et son suivi.
Pour les équipes qui exécutent déjà leurs builds sur macOS, commencez par mesurer le besoin réel : génération de ressources, validation, tests ou publication. Si ces opérations sont déjà prises en charge, l’annonce ne vous impose pas de changer de nœud. Si vous planifiez un environnement séparé pour des essais ou des charges de publication variables, vous pouvez comparer les options et leurs conditions sur la page de tarification VMSPIN, puis choisir en fonction du travail effectivement déplacé.
Questions fréquentes sur les captures et la CI
À partir de quand les captures de l’iPhone Duo deviennent-elles nécessaires ?
Apple indique que l’exigence s’appliquera aux applications et aux jeux soumis à partir d’avril 2027. Elle n’est donc pas à présenter comme une règle déjà active au moment de préparer votre plan. Vérifiez l’annonce et les consignes App Store Connect avant chaque échéance de publication, notamment si Apple actualise le périmètre ou les règles de dépôt.
Quelles caractéristiques faut-il contrôler pour les captures App Store Connect ?
Contrôlez les dimensions en pixels, l’orientation, le type de fichier accepté et les emplacements de présentation indiqués par Apple pour l’appareil visé. Les valeurs peuvent dépendre de la fiche et des règles en vigueur ; utilisez donc la page officielle des spécifications comme référence, plutôt qu’une ancienne liste interne ou une image créée pour le marketing.
Comment vérifier automatiquement que les captures sont complètes dans une CI iOS ?
Associez les ressources attendues à chaque application et langue, puis vérifiez que les fichiers existent, sont lisibles et respectent les règles de format que votre équipe a encodées d’après la documentation Apple. Publiez un rapport lié à la version construite. Ce contrôle confirme la présence et la conformité technique, mais ne remplace ni l’examen visuel ni l’acceptation par App Store Connect.
Faut-il modifier la CI ou les soumissions existantes dès maintenant ?
Pas uniquement à cause de cette exigence de captures. Commencez par ajouter l’inventaire, la responsabilité de production et une vérification avant soumission, puis testez le parcours complet sur une application. Une évolution de l’environnement Mac ne se justifie que si votre chaîne actuelle ne peut pas exécuter les tâches réellement nécessaires, et non par déduction à partir d’une règle de ressources visuelles.
Votre méthode actuelle peut toutefois montrer ses limites si les captures restent sur les postes individuels, si les versions et les langues sont difficiles à auditer, ou si la production entre en concurrence avec les builds sur un Mac partagé. Pour des essais ponctuels ou un environnement macOS distinct, la location d’un Mac peut éviter l’achat immédiat d’un poste dédié et sa maintenance ; elle ne convient pas automatiquement à une charge stable et continue ni aux tâches nécessitant un accès physique à des périphériques. Si vous souhaitez comparer cette option à votre CI existante, examinez les conditions de location chez VMSPIN après avoir défini les étapes à déplacer.