App Store Connect API 4.6 : que faire de l’arrêt des rapports INSTALLS ? 2026

Votre tâche planifiée ne trouve plus de nouveau rapport INSTALLS et votre tableau de bord affiche une baisse brutale ?
La conclusion à appliquer est simple : après App Store Connect API 4.6, l’absence de nouveau rapport INSTALLS ne signifie pas nécessairement que votre CI est en panne. Vérifiez le changement de disponibilité, conservez les rapports historiques accessibles et cessez les relances automatiques destinées à obtenir un rapport qui n’est plus généré.

Dernière mise à jour : 7 novembre 2026. Les faits de version et de disponibilité ci-dessous sont vérifiés à partir des notes de version officielles d’App Store Connect API et de la documentation Apple sur la disponibilité des rapports Sales and Trends. Si Apple modifie les règles de génération ou de téléchargement, vérifiez à nouveau ces pages avant de changer votre traitement.

Cet article s’adresse à vous si vous :
- maintenez un téléchargement automatisé de rapports App Store Connect et devez distinguer une évolution du service d’un problème d’authentification, de réseau ou de script ;
- gérez une tâche planifiée sur macOS et devez adapter ses critères de réussite et d’alerte ;
- exploitez un tableau de bord de diffusion et voulez préserver les tendances sans transformer une donnée absente en zéro.

Le changement à traiter avant d’enquêter sur votre CI

Apple a publié App Store Connect API 4.6 le 4 novembre 2026, comme l’indique son annonce de version. Selon les notes de version de l’API 4.6, les nouveaux rapports INSTALLS ne sont plus générés ; les rapports historiques restent téléchargeables. Cette distinction est déterminante : votre script peut fonctionner correctement et ne recevoir aucun nouveau rapport parce que le résultat attendu n’est plus produit.

Ne concluez toutefois pas automatiquement que toute réponse vide est normale. Un jeton expiré, une signature incorrecte, un mauvais paramètre de requête ou un changement dans votre traitement peuvent coïncider avec l’évolution du rapport. Le bon diagnostic consiste donc à séparer trois éléments : la génération d’un nouveau rapport, le téléchargement d’un rapport historique et le fonctionnement technique de votre tâche.

Pour l’appel de rapport, comparez votre cible réelle à l’interface documentée par Apple, notamment la ressource GET /v1/salesReports. Ce point permet de vérifier que le script sollicite bien la ressource attendue, mais ne prouve pas qu’un nouveau rapport INSTALLS doit encore exister. Les informations de génération et de disponibilité doivent être examinées séparément.

À retenir : un téléchargement réussi d’un rapport historique confirme que le chemin d’accès aux archives fonctionne ; il ne confirme pas que de nouveaux rapports INSTALLS sont encore produits.

Le rapport INSTALLS a-t-il encore de nouveaux résultats après la version 4.6 ?

Non, la documentation de version indique l’arrêt de la génération des nouveaux rapports INSTALLS. Les données déjà produites constituent un cas différent : les rapports historiques restent téléchargeables selon les règles de disponibilité documentées par Apple. N’étiquetez donc pas un résultat historique récupéré comme un rapport courant et ne supposez pas qu’une absence de fichier après la date du changement correspond à une panne.

Cette distinction doit apparaître dans le vocabulaire de vos journaux et de votre code. « Aucun nouveau rapport attendu » décrit un état du produit ; « requête échouée » décrit un incident d’exécution. Si les deux états aboutissent au même code de retour, au même message d’alerte ou à la même valeur dans la base, vos opérateurs ne pourront pas déterminer s’il faut intervenir.

Comparaison des résultats et du diagnostic à appliquer

Le score est volontairement qualitatif : il évalue la sûreté du traitement proposé, pas la qualité d’un service Apple ni les performances de votre infrastructure. La ligne « aucune donnée » ne doit surtout pas être fusionnée avec « zéro installation ». Ces états n’expriment pas la même information et peuvent conduire à des décisions différentes en acquisition, en diffusion ou en analyse produit.

Pour les téléchargements planifiés : séparez l’état métier de l’échec technique

Une tâche qui recherche les nouveaux rapports INSTALLS ne doit pas continuer à boucler comme si chaque absence était temporaire. Commencez par relever la période demandée, le type de rapport, les paramètres envoyés et l’horodatage de l’exécution. Comparez ensuite la réponse obtenue à la documentation officielle, puis classez le résultat dans une catégorie explicite : rapport reçu, aucun nouveau rapport attendu, erreur d’accès, erreur de requête ou incident réseau.

La documentation Apple pour l’accès à App Store Connect API fournit le cadre de configuration de l’accès. Pour votre diagnostic, vérifiez la signature et la validité des identifiants sans exposer de secret dans les journaux. Une réponse d’authentification en échec ne doit pas être interprétée comme une conséquence de l’arrêt des rapports ; inversement, corriger l’authentification ne peut pas faire réapparaître un rapport dont la génération a cessé.

Une politique de reprise raisonnable dépend du type d’incident. Une erreur transitoire de réseau peut justifier une nouvelle tentative contrôlée selon les règles déjà utilisées par votre système. Une absence conforme à l’état documenté du rapport ne justifie pas une répétition indéfinie. Inscrivez le motif de non-reprise dans les journaux : cette information évite qu’un autre membre de l’équipe réactive plus tard des tentatives bruyantes en croyant résoudre un incident.

Pour une tâche exécutée sur macOS, examinez également le code qui transforme la réponse API en résultat de travail. Une tâche peut être déclarée « réussie » au niveau de l’ordonnanceur tout en ayant produit un fichier vide, ou être déclarée « en échec » simplement parce qu’aucun rapport récent n’a été retourné. Le statut de l’ordonnanceur doit refléter le résultat attendu du processus, et le résultat métier doit rester consultable séparément.

Pour le tableau de bord : une absence ne doit jamais devenir une valeur nulle

Un tableau de bord agrège souvent plusieurs périodes, même si certaines ne contiennent aucun fichier. Après l’arrêt de génération, cette logique peut fabriquer une chute visuelle : le système remplace une valeur manquante par zéro, calcule une variation par rapport à la période précédente et présente le résultat comme une évolution des installations. Ce n’est pas une simple question d’affichage ; les exports, alertes et calculs en aval peuvent reprendre cette donnée comme si elle avait été mesurée.

Définissez donc un état explicite pour les périodes sans nouveau rapport : « rapport non généré », « donnée indisponible » ou un libellé équivalent adapté à votre modèle. Conservez les anciennes valeurs et leur période d’origine. Si une série est interrompue, rendez la rupture visible dans le graphe et dans l’export, plutôt que de relier artificiellement deux périodes avec une valeur inventée.

Cette séparation doit être conservée jusque dans les données exportées. Une cellule vide, une valeur nulle et un zéro ne sont pas nécessairement traités de la même façon par les outils d’analyse. Documentez le choix de votre schéma, puis contrôlez les consommateurs en aval : une règle de substitution inscrite dans un rapport de synthèse peut réintroduire la confusion que l’interface principale avait évitée.

Pour l’archive : vérifiez les anciennes périodes sans les confondre avec une génération active

Les historiques sont utiles pour examiner des tendances passées, mais leur disponibilité n’implique pas qu’Apple continuera à produire de nouvelles périodes. Consultez les règles de disponibilité des rapports Sales and Trends et consignez la période que vous pouvez effectivement récupérer. Évitez d’annoncer une durée d’archive qui ne serait pas explicitement confirmée par les documents consultés ou vérifiée par vos propres requêtes.

Testez séparément la lecture historique et la recherche de nouvelles périodes. Une requête visant un ancien rapport permet de contrôler l’authentification, la construction de l’appel, le téléchargement et l’écriture du fichier. Une exécution courante sans nouveau rapport permet de vérifier le traitement d’absence. Ces deux essais répondent à des questions différentes ; l’un ne remplace pas l’autre.

Si vos rapports ont déjà été téléchargés, copiez-les dans l’archive que vous contrôlez, avec leur période, le type de rapport, la date de récupération et une indication de provenance. Conservez aussi les journaux utiles au diagnostic, mais retirez-en les secrets et les données qui ne sont pas nécessaires à la traçabilité. Votre stratégie de sauvegarde doit être définie par votre équipe : la disponibilité historique dans l’interface ou l’API ne remplace pas une politique interne de conservation.

Les téléchargements doivent également être idempotents : récupérer de nouveau un rapport existant ne devrait pas créer de doublons ni écraser silencieusement un fichier différent. Comparez les périodes et les métadonnées avant de remplacer une archive. Cette précaution est particulièrement importante lorsque les rapports historiques servent à recalculer des tableaux de bord ou à justifier une valeur présentée à l’équipe produit.

Pour les indicateurs de remplacement : comparez les définitions avant les chiffres

La demande métier est souvent formulée comme « remplacer INSTALLS », mais elle peut recouvrir plusieurs questions : combien d’installations ont eu lieu, combien de personnes ont découvert l’application, ou quel comportement a suivi l’installation ? Ces notions ne doivent pas être assimilées sur la seule base d’un nom de rapport ou d’un chiffre qui semble proche.

Apple décrit les définitions de ses métriques App Store Connect et distingue notamment les rapports App Installs des Platform App Installs. Consultez les définitions précises et les conditions de disponibilité avant de retenir un indicateur pour votre tableau de bord. Les notes de version de l’API 4.6 ne suffisent pas, à elles seules, à démontrer qu’un autre rapport reproduit la même population, la même période ou le même sens métier qu’INSTALLS.

Vous pouvez alors établir une fiche de comparaison : nom officiel, définition Apple, événement ou population mesurée, période couverte, niveau de détail disponible, limites connues et usage métier autorisé. Si une définition ne répond pas à votre besoin, n’étiquetez pas le résultat « INSTALLS » pour préserver la continuité visuelle. Présentez-le sous son nom réel et signalez la rupture de série ; le lecteur du tableau de bord doit pouvoir distinguer une mesure différente d’une évolution de la métrique initiale.

Une série qui change de définition n’est plus directement comparable, même si son unité semble similaire. Marquez la date de transition et expliquez le changement dans les exports réutilisés par d’autres équipes.

Checklist d’adaptation de votre tâche macOS CI

Utilisez cette liste lors de votre prochaine revue du traitement ; chaque point doit être vérifié dans la configuration ou dans un résultat d’exécution, et non simplement supposé à partir d’un statut vert.

• [ ] Vérifier que le script appelle bien la ressource de rapport documentée et journalise les paramètres non sensibles de la requête.
• [ ] Distinguer explicitement l’absence de nouveau rapport INSTALLS d’une erreur d’authentification, de réseau ou de traitement.
• [ ] Confirmer qu’une absence attendue ne déclenche pas de relances automatiques sans limite.
• [ ] Tester une requête sur un rapport historique disponible et contrôler la récupération, le nommage et l’archivage du fichier.
• [ ] Tester le chemin « aucun nouveau rapport » et vérifier le statut de sortie, le journal et l’alerte produits.
• [ ] Vérifier que le tableau de bord affiche une donnée manquante plutôt qu’un zéro fabriqué.
• [ ] Examiner les calculs, exports et alertes en aval pour repérer les conversions implicites de valeurs absentes en zéros.
• [ ] Documenter les définitions Apple des indicateurs alternatifs avant d’autoriser une substitution métier.
• [ ] Revoir cette logique lorsque Apple modifie les notes de version, la disponibilité historique ou les définitions des rapports.

L’exécution de cette liste ne démontre pas qu’un nouveau rapport peut être généré ; elle démontre que votre système sait traiter correctement les résultats qui sont effectivement disponibles. C’est pourquoi un test historique et un test d’absence doivent rester deux cas de validation distincts dans votre pipeline.

Garder une tâche fiable sans surdimensionner l’environnement

L’arrêt d’un rapport est d’abord une question de cycle de vie des données, pas une raison automatique de déplacer votre pipeline. Un traitement qui utilise seulement des requêtes API et une archive peut rester sur son environnement actuel si celui-ci répond à vos besoins de planification, de sauvegarde et de surveillance. En revanche, si votre chaîne dépend d’outils ou de scripts spécifiquement liés à macOS, incluez la continuité d’accès à cet environnement dans votre décision. Le guide de choix d’un environnement Mac distant peut aider à comparer les contraintes d’exploitation ; l’API elle-même n’exige pas, à elle seule, que vous l’exécutiez sur un Mac.

Avant de modifier l’hébergement, examinez les limites concrètes de votre installation : qui renouvelle les identifiants, où sont conservés les journaux, comment les archives sont restaurées et qui reçoit les alertes. Une machine disponible en permanence ne corrige ni un mauvais classement de résultat ni une définition d’indicateur ambiguë. À l’inverse, une infrastructure qui s’éteint ou n’est pas accessible au moment de la tâche peut compliquer une automatisation dépendante de macOS.

Pour des exécutions ponctuelles de validation, d’archivage ou d’autres tâches macOS, une machine Mac locale peut convenir si vous acceptez d’en assurer l’achat, la maintenance et la disponibilité. Un environnement Linux peut être plus simple lorsque le traitement est entièrement portable, mais ne fournit pas l’environnement macOS pour les outils qui en dépendent. La location distante d’un Mac mérite d’être évaluée si vous avez besoin d’un accès Mac temporaire sans achat matériel ; elle n’est pas nécessaire pour résoudre à elle seule l’arrêt des rapports INSTALLS. Vous pouvez consulter les solutions Mac proposées par UDPMac et comparer cette option à votre charge réelle, à vos besoins d’accès et à votre politique d’exploitation.