Que faut-il sauvegarder lors de la migration d’une machine de build iOS ? Checklist Xcode 27 2026

Le projet est déjà copié, mais la nouvelle machine ne possède peut-être ni la clé privée, ni le bon profil, ni l’archive permettant de diagnostiquer une régression.

La solution la plus sûre pour une migration d’une machine de build iOS avec Xcode 27 consiste à valider séparément le code, l’outillage, l’identité de signature, les accès de publication, les archives et le service d’automatisation. L’ancienne machine ne doit être nettoyée ou résiliée qu’après un véritable Archive, un téléversement contrôlé et un test réalisé sans elle.

Cette checklist concerne :

• les développeurs indépendants qui vont résilier un Mac distant sans savoir quels fichiers et secrets conserver ;
• les responsables d’intégration continue qui déplacent des tâches Xcode 27 vers un autre Mac ;
• les petites équipes qui reprennent un projet externalisé ou reconstruisent une machine de build défaillante.

Dernière mise à jour : 8 septembre 2026. Les informations relatives à Xcode 27, à la distribution, aux certificats, aux profils, aux clés d’API et aux Runner ont été recoupées avec la documentation officielle d’Apple et de GitHub listée dans cet article.

Migration d’une machine de build iOS avec Xcode 27 : le bon indicateur n’est pas la copie

Un dossier de projet présent sur le nouveau Mac ne prouve pas que la chaîne de publication est récupérable. Un projet peut se compiler localement tout en échouant au moment de l’Archive parce que la clé privée n’a pas été exportée, que le profil de provisioning est expiré ou que le script attend une variable absente.

Un cas anonymisé illustre le risque : après le remplacement d’un Mac de build, le dépôt, les dépendances et le fichier de configuration avaient bien été restaurés. La compilation Debug fonctionnait. La publication Release échouait toutefois, car l’ancien trousseau contenait l’unique identité complète utilisable par le processus de signature. Le fichier de certificat seul ne permettait pas de signer.

La migration est réussie uniquement si le nouvel environnement peut, sans consulter les répertoires de l’ancien :

1. récupérer proprement le projet et ses dépendances ;
2. retrouver le même point d’entrée Xcode 27, le schéma et la configuration de Release ;
3. signer un Archive avec l’identité prévue ;
4. exporter ou téléverser le produit selon le circuit de publication réel ;
5. reprendre les tâches automatisées sans double exécution ;
6. permettre la restauration d’une version antérieure à partir des bons artefacts.

La page officielle consacrée aux exigences système de Xcode 27 doit servir de référence pour confirmer la compatibilité entre la version de macOS, Xcode et les composants requis. Il ne faut pas remplacer cette vérification par une simple copie de l’application Xcode.

Les six critères de décision avant de couper l’ancien environnement

Le tableau suivant sert de filtre de décision. Une ligne non validée signifie que l’ancienne machine doit rester disponible ou que le plan de retour doit être documenté.

Ce tableau distingue les éléments régénérables des éléments qui peuvent être irremplaçables. DerivedData, les caches de dépendances et les fichiers temporaires accélèrent parfois un build, mais ils ne constituent pas une preuve de restauration. À l’inverse, une clé privée perdue peut imposer une nouvelle identité de signature et perturber le circuit de livraison.

Code et outil : reconstruire plutôt que cloner l’environnement

Quels fichiers faut-il copier pour remplacer une machine de build iOS ?

Le minimum utile n’est pas « tout le dossier utilisateur ». Il faut inventorier les entrées nécessaires à une reconstruction indépendante :

• le dépôt principal et ses sous-modules ;
• les fichiers de verrouillage des dépendances ;
• les scripts de build, d’Archive, d’export et de téléversement ;
• les configurations non commitées mais indispensables, après assainissement des secrets ;
• les fichiers de description des dépendances privées et leur méthode d’accès ;
• les réglages de schéma, de configuration Release et de destination ;
• la documentation interne indiquant le Bundle ID, l’identifiant d’équipe et le mode de distribution.

Les secrets ne doivent pas être ajoutés au dépôt pour rendre la migration plus simple. Ils doivent être transférés par un canal contrôlé, puis injectés au moment de la tâche. Les chemins absolus vers l’ancien Mac doivent être recherchés dans les scripts, les fichiers de configuration, les tâches planifiées et les variables du Runner.

Sur le nouveau Mac, le premier contrôle doit partir d’un répertoire de travail propre. Une commande comme celle-ci permet de repérer les dépendances Git imbriquées et de conserver une trace de l’état récupéré :

git clone --recurse-submodules <URL_DU_DEPOT> projet-ios
cd projet-ios
git submodule status
git status --short

La sortie attendue doit montrer les sous-modules à la révision prévue et aucun fichier critique absent :

 a1b2c3d4 module-prive

La résolution des dépendances doit ensuite être effectuée avec l’outil prévu par le projet. Le résultat à archiver n’est pas seulement le message « terminé », mais aussi la révision du dépôt, le fichier de verrouillage utilisé et la sortie de la commande. Cette trace permet de distinguer une reconstruction réelle d’un build qui dépend encore d’un dossier présent uniquement sur l’ancien Mac.

Il est préférable de noter la version de Xcode 27, de macOS, du SDK et des outils en ligne de commande dans un fichier de migration. La documentation Apple des exigences de Xcode 27 est la référence pour cette compatibilité ; une version future annoncée dans la presse ne doit pas servir de fondement au transfert.

Pourquoi DerivedData ne remplace-t-il pas une reconstruction ?

DerivedData peut contenir des produits compilés, des index et des résultats intermédiaires. Il ne remplace ni le code source, ni le verrouillage des dépendances, ni les certificats, ni les profils. Le copier peut masquer un problème de configuration : le nouveau Mac réussit une compilation grâce à un artefact ancien, puis échoue lors d’un nettoyage complet.

Le contrôle pertinent consiste donc à supprimer ou isoler les caches, à récupérer le projet, à résoudre les dépendances, puis à construire depuis cette base. Si cette opération échoue, le problème doit être corrigé avant la migration, pas contourné par la copie de l’ancien répertoire utilisateur.

Signature et publication : conserver l’identité complète

Comment sauvegarder un certificat et sa clé privée avant de résilier un Mac distant ?

Un certificat Apple Distribution visible dans le trousseau n’est pas suffisant. La signature dépend de l’identité complète, c’est-à-dire du certificat et de la clé privée associée. L’export doit donc porter sur l’identité depuis le trousseau, dans un format protégé comme PKCS #12, puis être importé dans le trousseau du nouveau Mac. Apple décrit cette opération dans sa documentation sur l’importation d’une identité et les fichiers PKCS #12.

Le contrôle doit couvrir quatre points distincts :

• le certificat Apple Distribution attendu ;
• la présence de sa clé privée ;
• le mot de passe et l’emplacement sécurisé du fichier d’export ;
• l’accès effectif du processus de build au trousseau lors d’une tâche non interactive.

Une capture d’écran du certificat n’est pas une sauvegarde. Un fichier de certificat sans clé privée n’est pas une identité de signature complète. De même, un trousseau copié sans procédure d’importation vérifiée ne constitue pas une preuve exploitable.

Les profils de provisioning doivent être traités séparément. Ils peuvent être téléchargés et gérés depuis le compte développeur ; la page Apple consacrée à la gestion et au téléchargement des profils de provisioning précise les opérations disponibles. Chaque profil doit être rapproché du Bundle ID, de l’équipe, du type de distribution et de la configuration utilisée.

Toute révocation, suppression ou rotation doit être précédée de trois informations écrites :

1. l’impact sur les builds déjà installés et sur les publications en cours ;
2. le lieu de sauvegarde et la personne autorisée à restaurer ;
3. la condition de retour, par exemple conserver l’ancien certificat jusqu’à la validation d’un Archive.

La nouvelle machine doit démontrer qu’elle peut signer, et non simplement afficher le certificat :

security find-identity -v -p codesigning

Une sortie acceptable doit présenter une identité utilisable, sans révéler de secret :

1) <empreinte masquée> "Apple Distribution: <équipe masquée>"
     1 valid identities found

Cette commande n’est qu’un contrôle initial. La preuve finale reste un Archive réalisé avec le schéma et la méthode de distribution réellement employés.

Quelles données App Store Connect faut-il transférer ?

Les clés d’API App Store Connect ne sont pas interchangeables avec les certificats de signature. Il faut inventorier le rôle associé, l’identifiant de clé, l’identifiant d’équipe, le fichier de clé privé et le logiciel qui les consomme. Les valeurs doivent rester masquées dans les journaux, les captures et les exemples.

Apple documente la gestion des clés d’API App Store Connect. Avant de désactiver l’ancien Mac, la nouvelle machine doit exécuter une opération limitée et contrôlée : validation, téléversement d’un produit destiné au circuit de test ou étape équivalente prévue par l’équipe. Le choix dépend du processus de publication, mais l’objectif est identique : confirmer les droits réels et non la seule présence du fichier de clé.

Archives et symboles : conserver ce qui permet encore d’enquêter

Faut-il conserver les xcarchive et les dSYM à long terme ?

Oui, lorsqu’ils correspondent à des versions distribuées ou à des builds susceptibles d’être analysés. Une IPA seule ne suffit pas toujours pour diagnostiquer un crash : la symbolication dépend du dSYM correspondant au binaire. Apple explique comment localiser un fichier de symboles de débogage manquant, notamment en rapprochant les identifiants de l’archive et du binaire.

La conservation doit distinguer :

• xcarchive : archive Xcode permettant de retrouver le produit, ses métadonnées et le contexte d’export ;
• dSYM : symboles nécessaires à l’analyse lisible des crashes ;
• xcresult : résultats de tests, diagnostics et informations de compilation ;
• IPA : produit effectivement exporté ou distribué ;
• configuration d’export : paramètres nécessaires pour reproduire le mode de distribution ;
• journal de publication : version, numéro de build, date interne, destination et résultat.

Un cache de compilation peut être supprimé et régénéré. Une archive associée à une version publiée ne doit pas être confondue avec ce cache. Chaque ensemble doit être identifié par son UUID, sa version et son numéro de build, sans inscrire de secret dans le nom ou le journal.

Le contrôle ne s’arrête pas à la copie. L’archive doit être ouverte ou exportée sur le nouveau Mac, les dSYM doivent être vérifiés et la correspondance avec le produit doit être documentée. Apple indique également la procédure générale de distribution d’une application depuis un Archive. Cette étape permet de repérer une sauvegarde corrompue avant la résiliation de l’environnement source.

Attention : ne supprimez pas une archive parce que l’IPA est déjà disponible dans le circuit de test. L’IPA répond à un besoin de distribution ; le dSYM et l’xcarchive répondent à des besoins d’analyse, de vérification et parfois de nouvel export.

Runner et tâches automatisées : transférer la capacité de prise en charge

Comment reprendre un Runner auto-hébergé sur un nouveau Mac ?

Le transfert d’un Runner n’est pas une simple copie de dossier. Il faut inventorier le dépôt autorisé, l’étiquette de machine, les variables, les secrets, le compte système, les services en arrière-plan, les chemins de travail et les alertes. Les journaux doivent être inspectés pour repérer les dépendances implicites à l’ancien nom d’hôte ou à un répertoire local.

La séquence la plus sûre est la suivante :

1. installer et préparer le Runner sur le nouveau Mac ;
2. enregistrer la nouvelle machine avec des droits limités et une étiquette distincte ;
3. lancer une tâche isolée qui ne publie rien ;
4. vérifier la récupération du dépôt, la résolution des dépendances et l’accès au trousseau ;
5. exécuter un Archive contrôlé et vérifier les artefacts ;
6. suspendre l’ancien Runner ;
7. relancer une tâche représentative sur le nouveau ;
8. seulement ensuite retirer l’ancien Runner.

La documentation de GitHub sur la suppression d’un Runner auto-hébergé doit être suivie au moment du retrait. Le jeton d’enregistrement, l’identifiant de dépôt, le nom du Runner et les secrets ne doivent jamais apparaître en clair dans une capture ou un exemple.

Le risque principal est la concurrence : deux machines peuvent prendre la même tâche, générer deux produits ou téléverser deux fois un même numéro de build. La reprise doit donc être observée dans les journaux, avec un seul environnement autorisé à traiter les tâches de publication.

Nettoyage et résiliation : le dernier test doit fonctionner sans l’ancien Mac

Quand l’ancienne machine peut-elle être nettoyée sans risque ?

Elle peut être nettoyée uniquement lorsque le nouveau Mac a terminé un cycle représentatif : récupération propre, compilation, Archive, signature, export ou téléversement, conservation de l’artefact et exécution automatisée. Le test doit ensuite être répété avec l’ancien environnement hors ligne.

Cette dernière simulation révèle les dépendances oubliées :

• script qui pointe vers un chemin local ;
• clé d’API encore présente uniquement sur l’ancien trousseau ;
• profil téléchargé automatiquement par l’ancien compte ;
• variable fournie par un service d’arrière-plan ;
• Runner toujours actif ;
• archive ou dSYM stocké dans un partage non sauvegardé.

Le nettoyage doit ensuite suivre une liste ordonnée. Il faut arrêter les services, retirer l’ancien Runner selon la procédure officielle, supprimer les tâches planifiées, révoquer ou faire tourner les secrets qui ne doivent plus exister, puis effacer les fichiers temporaires et les historiques contenant des paramètres sensibles. Les dossiers partagés, les journaux et l’historique du shell doivent être contrôlés séparément.

La décision finale peut prendre trois formes :

• résiliation immédiate : toutes les preuves sont disponibles et le test hors ligne réussit ;
• courte période parallèle : le nouveau Mac publie, mais un élément de récupération reste à vérifier ;
• retour à l’ancien environnement : l’Archive, la signature, le téléversement ou la reprise automatisée échoue.

Pour préparer le nouvel environnement, les conditions d’un Mac distant adapté à Xcode 27 peuvent être comparées avant l’échéance de l’ancien contrat. L’enjeu n’est pas seulement d’obtenir une machine accessible : il faut confirmer l’accès administrateur, le mode d’accès distant, la persistance des services et la possibilité de reconstruire le processus sans dépendance cachée.

Le choix final : migrer proprement ou prolonger l’environnement actuel

Une machine de build existante semble plus simple à conserver, mais elle peut concentrer les risques : clé privée unique, sauvegardes locales, Runner non documenté et dépendance à un compte humain. La prolonger repousse le problème sans améliorer la récupération.

À l’inverse, un Mac acheté localement donne un contrôle physique, mais impose l’immobilisation du matériel, la maintenance, la disponibilité électrique et la gestion du réseau. Pour un projet audio ou vidéo qui nécessite des périphériques physiques, ce contrôle peut être déterminant. Pour une chaîne iOS qui a surtout besoin de Xcode, de signature, d’Archive et d’un service disponible à distance, un Mac distant correctement préparé peut être plus souple.

Les offres et modes de fonctionnement doivent être examinés selon le besoin réel, notamment à travers les conditions de location d’un Mac mini. Cette option n’est pas automatiquement préférable à un achat pour une charge lourde et stable sur plusieurs années, ni pour un projet exigeant des interfaces physiques locales. Elle devient pertinente lorsque l’environnement actuel arrive à échéance, qu’une équipe doit reconstruire rapidement sa chaîne ou qu’un serveur de publication doit rester accessible sans acheter une machine dédiée.

La règle opérationnelle reste simple : sauvegarder ne signifie pas déplacer des fichiers. Il faut prouver que le nouvel environnement peut reconstruire, signer, publier, retrouver les symboles, reprendre les tâches automatisées et fonctionner lorsque l’ancien Mac est réellement hors ligne. Ce n’est qu’après cette preuve que la résiliation ou le nettoyage cesse d’être un pari.