Votre automatisation envoie encore les captures via les anciennes ressources, alors que la documentation indique qu’elles sont dépréciées. La migration des interfaces de capture d’écran d’App Store Connect API 4.5.1 consiste à adopter App Asset Library pour les nouveaux développements et à déplacer progressivement l’existant vers des ressources liées à des placements, sans interpréter la dépréciation comme un arrêt immédiat.

Ce guide s’adresse aux développeurs indépendants qui automatisent l’envoi de captures ou d’aperçus vidéo. Il convient aussi aux petites équipes qui gèrent plusieurs apps, des pages produit personnalisées ou des médias d’événements intégrés. Si votre automatisation ne touche pas aux ressources concernées, vous pouvez laisser ce périmètre intact et le vérifier lors de votre prochain audit.

Dernière mise à jour : 15 octobre 2026, après vérification des notes de version et des documents officiels Apple sur la migration, les ressources et leur état. Notes de publication d’App Store Connect API 4.5.1 · Guide officiel de migration vers App Asset Library

Décider d’abord si vous devez migrer maintenant

La note de publication d’App Store Connect API 4.5.1, publiée le 6 octobre 2026, marque comme dépréciées plusieurs ressources utilisées pour les captures, les aperçus et certains médias d’événements intégrés à l’app. Elle oriente les développeurs vers App Asset Library. Apple ne présente pas cette dépréciation comme la preuve que les anciennes interfaces sont déjà hors service, et n’annonce pas de date limite de migration dans la note citée. Consultez la note de version officielle et son statut de dépréciation.

Prenez la décision en fonction de vos appels réels, des types de médias concernés et de votre calendrier de publication. Une migration précipitée juste avant une livraison peut introduire des erreurs de correspondance ou d’ordre ; conserver indéfiniment un nouveau développement sur l’ancien modèle crée, de son côté, une dépendance évitable à des ressources dépréciées.

  • Si vous créez une nouvelle automatisation, adoptez directement App Asset Library et les placements disponibles pour votre app.
  • Si votre intégration utilise déjà les anciennes ressources, planifiez la migration par type de média et validez chaque parcours avant de retirer les anciens appels.
  • Si votre code ne lit, ne crée ni ne modifie ces ressources, ne changez pas votre flux par réflexe ; consignez le périmètre vérifié et réévaluez-le quand votre besoin évolue.
Ces branches évitent deux erreurs symétriques : assimiler « déprécié » à « inutilisable dès maintenant », ou considérer l’absence d’échec actuel comme une garantie de compatibilité future.

Mesurer le changement de modèle avant de modifier le code

Le changement essentiel ne se limite pas au remplacement d’une interface de téléversement. Dans l’ancien modèle, votre code manipulait des ensembles organisés autour d’une destination de présentation. Avec App Asset Library, il faut distinguer le média enregistré dans la bibliothèque de la relation qui le place dans un contexte de présentation et de localisation.

<
Critère de migrationAncien modèle par ensemblesApp Asset LibraryPriorité de contrôle
Objet manipuléEnsemble et médias associés à une destinationRessource image ou vidéo, puis placementÉlevée si le code suppose qu’un fichier équivaut à une page
RéutilisationSouvent structurée autour de l’ensemble cibléUne ressource peut être associée à plusieurs placements compatiblesÉlevée pour les pages localisées
Lecture de l’étatLecture de l’ensemble et de ses médiasLecture de la ressource, de son traitement et de ses placementsÉlevée pour les tableaux de bord et reprises
Ordre affichéLogique liée à l’ensemble historiqueOrdre à vérifier au niveau des placementsÉlevée avant publication
NettoyageSuppression pensée autour de l’ancien ensembleSuppression à coordonner entre ressource et associationsÉlevée pour éviter les références orphelines
Cette séparation est documentée par les ressources de gestion des éléments de l’App Store et par la procédure de migration. [Le guide Apple décrit la gestion des éléments et leur utilisation dans App Store Connect](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets?utm_source=openai). Une ressource stockée n’est pas, à elle seule, la preuve qu’elle est sélectionnée sur une page ; inversement, la suppression d’une association de placement ne signifie pas nécessairement que le média source doit être supprimé.

Traitez donc les identifiants de bibliothèque et de placement comme deux entités distinctes dans votre base de suivi. Si votre script ne conserve qu’un identifiant d’ancien ensemble, vous risquez de ne plus savoir quelle ressource réutiliser, quelle relation corriger ou quelle association retirer lors d’une nouvelle publication.

Cartographier tous les appels, pas seulement l’envoi

Avant de modifier une ligne de code, inventoriez les actions qui interviennent dans votre chaîne : lecture, création, téléversement, modification, suppression et réordonnancement. Le remplacement du seul appel d’envoi laisse souvent intactes les hypothèses héritées dans les scripts de reprise, les outils internes ou le nettoyage après publication.

Parcourez vos flux par destination et par type de média :

  • captures d’écran et aperçus associés à une version de l’app ;
  • médias de pages produit personnalisées ;
  • variantes utilisées pour les tests de page produit ;
  • images et vidéos liées aux événements intégrés à l’app.
Pour chaque flux, notez les ressources historiques réellement utilisées, les opérations effectuées et le système qui consomme le résultat. Une tâche nocturne peut, par exemple, envoyer un fichier puis s’appuyer sur un autre processus pour lire les médias existants et supprimer les versions remplacées. Si vous ne recensez que la première étape, le nouveau téléversement peut réussir alors que le contrôle qualité continue de lire l’ancien emplacement ou que le nettoyage échoue.

Apple distingue plusieurs états d’éléments. Comparez donc l’état retourné par l’API à celui présenté dans App Store Connect, au lieu de supposer qu’un fichier envoyé est déjà disponible pour la sélection. La documentation Apple sur les états des éléments de l’App Store décrit les états à interpréter.

Identifier les capacités avant de choisir un placement

Ne transformez pas les groupes de placements, les catégories d’appareils, les dimensions ou les restrictions en constantes permanentes dans votre code. Les options pertinentes peuvent dépendre du contexte de l’app et du type de présentation. Pour établir ce qui est disponible, lisez les données de référence de l’API et exploitez les réponses obtenues pour l’app concernée.

La catégorie IPHONE_DUO est à prendre en compte dans la découverte des capacités : ne l’ignorez pas dans un analyseur de types de présentation qui suppose une liste fermée de catégories plus anciennes. Sa présence dans les données de référence ne prouve toutefois pas que chaque média peut être placé dans chaque contexte. Fiez-vous aux groupes et aux spécifications retournés, puis vérifiez la réponse de création du placement.

Attention : la prise en charge d’une catégorie par l’API ne vaut pas confirmation que votre fichier est accepté pour une destination donnée. Vérifiez ensemble le type de placement disponible, les contraintes retournées et le résultat de traitement de la ressource.

Lorsque vous adaptez un importateur ou un outil de préparation des médias — par exemple un flux de création visuelle ou de montage vidéo — séparez la validation locale du fichier de la validation côté App Store Connect. La conformité de format ne garantit pas que le placement demandé soit disponible pour la page, la localisation ou le contexte visé.

Migrer en étapes et conserver une correspondance traçable

Procédez par périmètre contrôlé plutôt que par remplacement global. La procédure officielle d’envoi de ressources vers App Store Connect doit être lue avec les références des ressources et les règles de placement ; ne déduisez pas une relation un-à-un entre chaque ancien ensemble et une nouvelle ressource.

Première étape : établir l’inventaire. Recherchez dans le dépôt les opérations liées aux ensembles, captures, aperçus et médias d’événements. Ajoutez aussi les consommateurs indirects : tâches de contrôle, tableaux de bord, rapports de publication et scripts de suppression.

Deuxième étape : définir la correspondance. Pour chaque ancien objet, indiquez si le nouveau flux doit créer une ressource image, une ressource vidéo ou un placement, et dans quel contexte. Consignez l’app, le média source, son identifiant App Asset Library, les identifiants de placement et la localisation visée. Ne déduisez pas les correspondances uniquement du nom de fichier.

Troisième étape : adapter la découverte. Faites lire à votre client les données de référence utiles avant de choisir un groupe ou une catégorie. Traitez les valeurs inconnues comme une situation à signaler et à examiner, plutôt que comme une erreur à contourner silencieusement ou une raison d’envoyer un placement choisi par défaut.

Quatrième étape : créer et suivre la ressource. Envoyez le média, conservez son identifiant et attendez un état exploitable avant d’enchaîner. La réponse positive au téléversement confirme une étape de la requête, pas nécessairement la fin du traitement, la création d’un placement ou l’apparition du média sur une page.

Cinquième étape : associer les placements requis. Créez les relations correspondant aux destinations et localisations voulues. Une même image peut être réutilisée lorsque les données de référence et les réponses de l’API autorisent les placements concernés ; ne présumez ni que tous les contextes l’acceptent ni que la réutilisation se fait automatiquement.

Sixième étape : valider ordre et nettoyage. Vérifiez l’ordre des médias affichés et adaptez le processus de suppression à la séparation entre ressource et placement. Si une relation doit disparaître, vérifiez d’abord que vous ciblez le placement voulu. Ne reprenez pas à l’identique une suppression d’ancien ensemble : elle peut laisser une association inutilisée ou viser un objet qui n’existe plus dans le nouveau modèle.

Septième étape : déployer progressivement. Commencez par un périmètre modifiable et facile à contrôler. Conservez les résultats des requêtes, les identifiants créés et les états visibles dans App Store Connect. Élargissez ensuite le traitement aux autres catégories seulement lorsque les étapes de lecture, d’envoi, de placement, d’ordre et de retrait sont toutes vérifiées.

Cette séquence limite le risque qu’une automatisation donne un résultat trompeur : un téléversement peut être réussi alors que la ressource est encore en traitement, que le placement n’a pas été créé ou que la page continue d’utiliser un autre média.

Valider le résultat dans l’API et dans App Store Connect

Choisissez un scénario réellement modifiable, par exemple une page de présentation dont vous pouvez contrôler les médias sans perturber une publication imminente. Suivez la chaîne complète et consignez les deux vues : les réponses de l’API et l’état visible dans App Store Connect.

Votre vérification doit distinguer les résultats suivants :

  • la ressource image ou vidéo a été créée et son traitement est terminé ;
  • le placement a été associé à la destination et à la localisation prévues ;
  • l’ordre des médias correspond à la séquence attendue ;
  • la page d’App Store Connect permet de sélectionner ou affiche la ressource attendue ;
  • l’état de révision ou de publication est vérifié séparément, sans le déduire du téléversement.
Ne confondez pas disponibilité du média, sélection sur une page et approbation éditoriale. Ce sont des résultats différents, observés à des endroits différents. Si l’automatisation prépare aussi des visuels, des aperçus audio ou vidéo, conservez les validations de production créative en amont ; elles ne remplacent pas l’acceptation du placement par l’API.

La grille ci-dessous permet de décider si le périmètre est prêt à être étendu :

  • Si la ressource, son traitement, ses placements et son ordre sont vérifiés, vous pouvez étendre la migration au prochain type de média.
  • Si le téléversement réussit, mais que le placement ou la page n’est pas confirmé, arrêtez l’extension et examinez les identifiants, la localisation, les données de référence et les réponses API.
  • Si la page est correcte, mais que le nettoyage ou la lecture échoue, maintenez l’ancien flux sous contrôle pendant que vous corrigez les opérations de suivi ; ne concluez pas que la migration est complète.
  • Si votre automatisation ne manipule pas ces ressources, laissez-la inchangée, mais gardez une trace du périmètre examiné et de la version des documents vérifiés.
Le résultat recherché n’est pas seulement un nouvel appel qui renvoie une réponse positive. C’est une chaîne traçable qui permet de retrouver le média, ses placements, leur ordre et leur état réel, puis de corriger l’étape fautive sans supprimer la mauvaise ressource.

FAQ : points à éclaircir

Quelles ressources de capture et d’aperçu sont concernées par la dépréciation ?

Les notes d’App Store Connect API 4.5.1 signalent comme dépréciées les anciennes ressources liées aux ensembles de captures, aux captures, aux ensembles d’aperçus, aux aperçus et à certaines ressources multimédias d’événements intégrés à l’app. Cette indication ne signifie pas que ces interfaces ont cessé de fonctionner. Vérifiez précisément les ressources utilisées par votre automatisation avant de planifier leur remplacement.

En quoi App Asset Library diffère-t-elle des anciens ensembles de captures ?

L’ancien modèle organisait les fichiers au sein d’ensembles associés à une destination de présentation. Avec App Asset Library, l’image ou la vidéo est enregistrée comme ressource, puis une relation de placement indique où l’afficher et dans quelle localisation. Cette séparation permet de réutiliser une ressource, mais impose de suivre séparément le fichier, ses placements et leur ordre.

Comment réutiliser une capture dans plusieurs pages localisées ?

Conservez la ressource dans la bibliothèque, puis créez les placements correspondant aux destinations et aux localisations réellement disponibles pour votre app. Ne supposez pas qu’un fichier peut être associé à toute page ou à tout groupe : interrogez les données de référence de l’API, puis vérifiez le résultat de chaque association. Documentez les identifiants de ressource et de placement pour pouvoir corriger ou supprimer la bonne relation.

Comment vérifier et ordonner les placements App Asset Library ?

Contrôlez séparément la création de la ressource, son état de traitement, la création de chaque placement et l’ordre retourné ou affiché dans App Store Connect. Une réponse réussie à l’envoi ne prouve ni que le traitement est terminé ni que la page utilise la ressource attendue. Comparez les réponses de l’API avec l’écran de gestion des ressources et consignez les deux états.

Choisir l’environnement d’exécution sans le confondre avec l’API

La migration des ressources App Store Connect ne rend pas, à elle seule, un Mac indispensable : les appels à l’API peuvent être exécutés depuis l’environnement adapté à votre architecture. La question du Mac se pose plutôt si votre chaîne génère ou contrôle les médias avec des outils macOS, ou si elle réunit ces opérations avec la préparation et la publication d’une app iOS.

Dans ce cas, un environnement Mac distant peut éviter de réserver une machine locale à une tâche de publication, tout en laissant votre service d’automatisation appeler l’API selon votre propre conception. À l’inverse, pour un traitement ponctuel ou une chaîne déjà stable sur un autre environnement, ajouter un Mac ne résout pas un problème de placement ou de suivi des états. Vous pouvez d’abord consulter les environnements Mac à distance proposés par MACGPU, puis vérifier si un Mac M4 distant convient à vos outils de génération et de publication. Le bon choix dépend du rôle réel de macOS dans votre chaîne, et non du seul fait que vos médias apparaissent dans App Store Connect.