Combien de temps conserver les artefacts de build CI Mac en entreprise ? Guide 2026

Pour diagnostiquer un crash, Apple associe deux éléments qui ne sont pas interchangeables : l’archive de l’application et les symboles dSYM correspondants (documentation sur les informations de débogage). La stratégie de conservation des artefacts de build CI Mac en entreprise doit donc séparer les preuves de publication des fichiers reconstructibles : cette semaine, vérifiez d’abord la récupération d’une version déjà distribuée, puis définissez des règles différentes pour les archives, les journaux, les rapports, les caches et les espaces temporaires.

Ce guide s’adresse aux responsables de publication iOS qui doivent retrouver une archive et ses dSYM pour diagnostiquer un crash.
Il concerne aussi les ingénieurs plateforme qui gèrent le stockage, les caches et les journaux des nœuds Mac.
Les responsables IT, sécurité ou conformité y trouveront une méthode pour attribuer les responsabilités et prouver qu’une récupération est possible.

Un nettoyage uniforme transforme une économie de stockage en risque de publication

Un répertoire de travail CI rassemble souvent des fichiers aux fonctions très différentes. Les supprimer selon une règle unique peut certes libérer de l’espace, mais crée plusieurs risques opérationnels :

• Une archive Xcode ou son dSYM disparaît alors qu’une version distribuée doit encore être examinée. Le code source seul ne remplace pas nécessairement les symboles produits pour le binaire réellement livré.
• Un rapport de test ou un journal est supprimé avant que l’équipe ait pu expliquer un échec intermittent, une différence entre deux exécutions ou une anomalie signalée après publication.
• Les fichiers utiles à l’audit restent sur le disque d’un seul nœud Mac, dans un espace de travail facile à nettoyer. Une panne, une réaffectation de machine ou une modification de pipeline peut alors rompre la chaîne de récupération.
• À l’inverse, les caches de dépendances, fichiers intermédiaires et anciens espaces de travail s’accumulent. Comme ils côtoient des preuves essentielles, les équipes hésitent à nettoyer et le stockage devient difficile à gouverner.
• Les autorisations sont parfois héritées du compte d’exécution du pipeline. Une personne chargée de supprimer des données temporaires peut ainsi avoir accès à des éléments qui devraient être protégés ou conservés séparément.

La conservation doit donc répondre à quatre besoins, qui peuvent entrer en tension : reconstruire un résultat, diagnostiquer un défaut, justifier une publication et restaurer les fichiers après une perte. Vous n’avez pas besoin d’une durée identique pour ces usages. Vous avez besoin d’une règle explicite par catégorie, d’un emplacement connu et d’une personne responsable.

Les artefacts n’ont pas tous la même valeur de preuve

Avant de fixer une échéance, classez chaque fichier selon sa fonction et le coût de sa perte. La distinction entre archive et cache est particulièrement importante : la documentation CI distingue les données conservées comme artefacts de celles qui accélèrent une exécution et peuvent être reconstruites (documentation sur la différence entre caches et artefacts).

• Archive Xcode d’une version distribuée : élément de référence pour retrouver le build publié et ses informations de débogage. Apple décrit la création d’archives pour la distribution et recommande de conserver les archives nécessaires aux versions diffusées (guide de distribution et de création d’archive).
• dSYM associé : fichier de symboles à garder avec l’archive correspondante. Il permet de rendre les adresses d’un rapport de crash plus intelligibles lorsque les symboles correspondent au binaire concerné (méthode de symbolisation d’un rapport de crash).
• Binaire d’exportation et éléments de livraison : fichiers effectivement remis à un magasin d’applications, à un client ou à une équipe de validation. Ils peuvent être nécessaires pour confirmer ce qui a été envoyé, même si l’archive reste conservée ailleurs.
• Rapports de test : résultats utiles pour analyser une régression, une validation ou un échec de publication. Leur besoin de conservation dépend de la capacité à relancer les tests, des besoins de diagnostic et des règles internes.
• Journaux de compilation et de publication : éléments de diagnostic et parfois preuves de déroulement. Leur accès peut être plus sensible que celui d’un binaire, car ils peuvent contenir des chemins, des noms de tâches ou des informations qu’il faut examiner avant diffusion.
• Caches de dépendances et fichiers intermédiaires : données destinées à accélérer ou faciliter la reconstruction. Elles ne doivent pas être confondues avec une copie de l’archive publiée.
• Espaces de travail temporaires : répertoires d’exécution qui devraient avoir un propriétaire et un processus de nettoyage identifiables, et non servir de dépôt d’archives à long terme.

Pour comparer vos règles, attribuez à chaque catégorie une appréciation qualitative : forte si une perte compromet le diagnostic ou la preuve de livraison, moyenne si elle retarde une investigation mais reste récupérable, faible si une reconstruction documentée suffit. Ce score de priorité est un outil de tri interne, pas une norme de conservation. Une archive publiée et son dSYM devraient être traités comme un ensemble à forte priorité ; un cache dont la reconstruction a été testée peut relever d’une priorité plus faible.

Archives et dSYM : préserver la correspondance, pas seulement les fichiers

Quelle durée prévoir pour une archive Xcode et son dSYM ?

Il n’existe pas de durée universelle qui convienne à toutes les entreprises. Conservez l’archive et le dSYM associés tant que vous devez pouvoir diagnostiquer les incidents affectant la version distribuée ou produire les éléments demandés par vos procédures de publication et d’audit. La limite doit venir de votre politique de diagnostic, de vos engagements contractuels et de votre gouvernance des données, non d’une valeur présentée comme valable pour tous.

Le lien entre les fichiers compte autant que leur présence. Un dossier contenant des archives anonymes et des dSYM sans identifiant vérifiable ne garantit pas que l’équipe pourra analyser un crash. Pour chaque version publiée, associez au minimum les informations qui permettent de retrouver le bon ensemble :

• l’identifiant de version et le numéro de build utilisés dans votre processus ;
• l’identifiant du pipeline ou de l’exécution qui a produit l’archive ;
• le nom du binaire livré et la date de publication, selon vos conventions internes ;
• les dSYM associés, avec une vérification de leur correspondance au binaire ;
• l’emplacement durable de conservation et la personne ou l’équipe responsable.

N’utilisez pas le seul nom de branche ou de commit comme preuve de correspondance. Deux exécutions issues d’un code source identique ne garantissent pas à elles seules que les symboles et le binaire conservés sont ceux de la version distribuée. Au moment de l’archivage, générez un manifeste ou un enregistrement de livraison qui relie les identifiants utiles et indique les emplacements des fichiers. Gardez cet enregistrement avec les artefacts, ou dans un système de suivi auquel les équipes concernées ont accès.

Peut-on encore symboliser un crash après la suppression de l’archive ?

La conservation du dSYM correspondant peut permettre de symboliser un rapport de crash, mais supprimer l’archive retire une partie importante du contexte de publication. Apple explique le rôle des symboles pour interpréter les rapports de crash ; cela ne rend pas pour autant un dSYM isolé équivalent à l’ensemble des éléments de livraison (documentation de symbolisation). Si l’archive est perdue, vous pouvez donc vous retrouver avec des symboles sans moyen suffisamment fiable de reconstituer ou de vérifier le build livré.

La règle la plus robuste consiste à conserver archive et dSYM dans un même dossier logique, même s’ils sont stockés sur un support distinct de celui du nœud de compilation. Si votre organisation décide de supprimer l’archive après une période définie, consignez cette décision, les éléments conservés en remplacement et la justification opérationnelle. Ne supposez pas que le dépôt de code, un build relançable ou une copie locale permettra de recréer exactement l’archive distribuée.

Avant d’appliquer une suppression automatique, choisissez une version déjà publiée et vérifiez que vous pouvez retrouver ensemble son archive, ses symboles, son binaire de livraison et l’enregistrement qui les relie. Une règle qui n’a jamais été testée ne constitue pas encore un processus de récupération démontré.

Journaux, rapports et caches : des règles distinctes par usage

Les journaux et rapports doivent-ils expirer comme les caches ?

Non : les besoins diffèrent. Les journaux et rapports servent à expliquer une exécution passée ; un cache sert principalement à préparer ou accélérer une exécution future. Un rapport associé à un échec en cours d’investigation peut être nécessaire même si un rapport plus ancien n’a plus d’utilité opérationnelle. À l’inverse, conserver indéfiniment tous les journaux peut compliquer les recherches, élargir l’accès à des données techniques et accroître le coût de stockage.

Fixez une politique à partir de questions concrètes :

• Une équipe doit-elle encore consulter le journal pour analyser les échecs récurrents ou les plaintes reçues après livraison ?
• Le rapport permet-il de confirmer un contrôle exigé par le processus interne de publication ?
• Les journaux contiennent-ils des informations sensibles qui imposent une restriction d’accès ou une suppression contrôlée ?
• Les tests peuvent-ils être relancés dans un environnement suffisamment comparable, ou l’exécution enregistrée est-elle la seule preuve disponible ?
• Qui peut prolonger la conservation lorsqu’un incident est ouvert, et qui autorise ensuite la suppression ?

La documentation officielle d’une plateforme CI peut prévoir plusieurs niveaux de réglage. Pour les journaux et artefacts, les paramètres peuvent concerner l’organisation ; la durée d’un artefact individuel peut également être définie lors de son dépôt. Vérifiez les règles effectivement applicables à votre dépôt et à votre compte avant de les adopter (paramètres de conservation au niveau de l’organisation et paramètres des artefacts de workflow). Ces fonctions propres à une plateforme ne définissent pas une durée de conservation universelle pour votre entreprise.

Des fonctions analogues ont leurs propres conditions sur d’autres plateformes : la documentation de l’une d’elles décrit l’expiration des artefacts et le traitement particulier des artefacts de la dernière exécution réussie (règles d’expiration des artefacts). Une autre distingue notamment la conservation des exécutions de pipeline et des données de test (règles de conservation des pipelines). Si votre organisation utilise l’une de ces fonctions, vérifiez son périmètre et ses exceptions dans la documentation applicable ; ne transposez pas ses valeurs par défaut aux autres dépôts ou aux archives Xcode.

Pour les caches, exigez d’abord une reconstruction vérifiée. Identifiez le répertoire, son propriétaire, les dépendances qu’il contient et la procédure permettant de le régénérer. La documentation sur les caches précise qu’ils servent à réutiliser des dépendances et qu’ils ne remplacent pas les artefacts destinés à être conservés (mécanismes de cache et de restauration). Vous pouvez alors définir un nettoyage selon l’usage observé, le coût de reconstruction et les exigences de stockage, sans fixer une échéance copiée d’une règle de publication.

Une chaîne de conservation utile à l’audit et à la reprise

Une archive enregistrée n’est utile que si les équipes savent où la trouver, peuvent y accéder et ont une méthode pour la récupérer. Reliez donc chaque classe d’artefact à un lieu de conservation, une autorité d’accès, un responsable et une méthode de vérification. Votre architecture peut utiliser un dépôt de fichiers, un stockage d’objets ou un autre système contrôlé : le choix dépend de vos outils et de vos exigences, et non d’une hypothèse selon laquelle toutes les entreprises devraient adopter le même produit.

Documentez la chaîne de transfert depuis le nœud Mac jusqu’au stockage durable. Précisez le moment où l’archive et le dSYM sont copiés, la vérification effectuée après transfert, le lien vers l’exécution CI et le comportement attendu en cas d’échec de copie. Si les fichiers sont conservés sur un espace de travail local, définissez explicitement comment ils sont récupérés avant le nettoyage ou le remplacement du nœud. Un environnement de compilation temporaire ne devrait pas constituer l’unique lieu de conservation d’une preuve de publication.

La conservation implique aussi le contrôle d’accès. Distinguez les personnes autorisées à lire, exporter, prolonger la durée et supprimer les éléments. Vérifiez si les journaux comportent des données qui doivent être masquées ou accessibles à un groupe plus restreint. Gardez une trace des suppressions planifiées et des exceptions liées à une investigation ouverte. L’objectif n’est pas de multiplier les formalités, mais de pouvoir répondre précisément à ces questions : quel build a été conservé, où, par qui, selon quelle règle et avec quelle possibilité de récupération ?

Vérifications avant d’activer le nettoyage automatique

Utilisez cette liste pour valider votre politique sur un cas réel avant de l’étendre à l’ensemble des nœuds :

• [ ] Sélectionnez une version iOS déjà distribuée et retrouvez son archive Xcode ainsi que le dSYM correspondant.
• [ ] Vérifiez que les identifiants de version, de build et d’exécution relient sans ambiguïté le binaire livré aux fichiers conservés.
• [ ] Confirmez que l’archive et les symboles sont copiés hors de l’espace de travail éphémère du nœud Mac.
• [ ] Identifiez le lieu de conservation, les rôles autorisés à lire ou supprimer les fichiers et le responsable de la politique.
• [ ] Ouvrez un rapport de test et un journal représentatifs ; confirmez leur date d’expiration et la procédure de prolongation lorsqu’un incident est en cours.
• [ ] Reconstituez un cache supprimé dans un environnement de test et consignez les limites éventuelles de cette reconstruction.
• [ ] Vérifiez les réglages de la plateforme CI à la fois au niveau global applicable et au niveau de l’artefact, sans supposer qu’une valeur par défaut s’applique partout.
• [ ] Restaurez depuis un emplacement indépendant les fichiers nécessaires à l’analyse d’une publication ; consignez le résultat et corrigez les étapes qui échouent.
• [ ] Faites approuver les durées et les exceptions par les responsables de publication, de plateforme et de gouvernance des données concernés.

Après l’exercice, attribuez un statut qualitatif à chaque point : validé, à corriger ou non applicable, avec une justification. Ce suivi rend les lacunes visibles sans transformer une politique interne en promesse de conformité générale. Répétez la vérification après une modification du pipeline, du lieu de stockage ou des règles de conservation de la plateforme.

Choisir une capacité Mac sans confondre calcul et conservation

Conserver des archives ne règle pas, à lui seul, la disponibilité des machines de build. Un nœud dédié et acheté peut convenir si vous disposez d’un site, d’une équipe chargée de l’exploitation et d’une capacité prévisible sur la durée. En contrepartie, vous devez gérer l’approvisionnement, la maintenance matérielle et les procédures de remplacement. Un environnement partagé ou hébergé évite de dépendre d’un Mac de développeur laissé accessible, mais demande de vérifier les droits, les modalités d’accès, la remise des données et la reprise après la fin de la période d’utilisation. Quel que soit le modèle, les archives importantes doivent être transférées vers un emplacement conçu pour leur conservation, et non rester uniquement sur le disque de compilation.

Si vos équipes ont besoin d’un nœud Mac supplémentaire pour les builds, le test d’une chaîne de livraison ou une montée en charge temporaire, examinez les options de nœuds Mac accessibles à distance en fonction de vos contraintes d’accès et de transfert. Une capacité distante ne remplace ni une politique d’archivage ni un dépôt durable ; elle peut en revanche éviter que le pipeline dépende d’un poste local indisponible. Si vous comparez aussi le périmètre général des environnements proposés, consultez la présentation des solutions Mac à distance.

Avant de décider, confrontez votre solution actuelle à une capacité Mac louée pour les périodes où un nœud supplémentaire est nécessaire. Le matériel acheté mobilise du budget avant même d’être sollicité, exige une organisation pour la maintenance et peut devenir une contrainte lorsque la charge varie ; un Mac de développeur utilisé comme serveur ajoute une dépendance à son poste, à son réseau et à ses plages de disponibilité. La location peut apporter un environnement distinct et modulable pour un besoin temporaire, mais elle ne convient pas forcément à une charge permanente prévisible, à des exigences d’accès physique ou à une politique imposant un contrôle matériel sur site. Dans tous les cas, gardez la décision de conservation indépendante du choix du nœud : archive, dSYM, preuves de livraison et procédure de récupération doivent rester accessibles même lorsque la machine CI change.