Comment configurer fastlane match sur un Mac distant ? Liste de migration CI de signature 2026

Le build fonctionne sur le Mac personnel, mais le nœud distant ne possède pas la clé privée nécessaire pour signer l’archive.

La solution la plus sûre consiste à utiliser fastlane match sur un Mac distant sans révoquer immédiatement les identités existantes : un nouveau projet peut initialiser match, tandis qu’une application déjà publiée doit d’abord importer ses certificats et conserver une double chaîne de publication. En CI, la synchronisation doit rester en mode readonly, avec un trousseau temporaire créé par setup_ci; les écritures, renouvellements et révocations doivent rester réservés à un processus d’administration contrôlé.

Cette méthode concerne les équipes qui maintiennent une automatisation iOS ou macOS et souhaitent supprimer la dépendance à un Mac personnel. Elle s’adresse aussi aux responsables des certificats, des clés privées, des profils de provisioning et des autorisations de publication, ainsi qu’aux responsables qui envisagent de louer un Mac distant comme nœud de build durable.

Commencer par qualifier la situation de signature

La première décision ne dépend pas de fastlane, mais de l’état réel des identités de signature. Une archive réussie sur un poste personnel ne prouve pas qu’un autre Mac peut reproduire le processus : Apple rappelle qu’une identité de signature associe un certificat à la clé privée correspondante, et non au seul fichier de certificat. La documentation Apple sur le partage des certificats de signature doit donc servir de référence avant toute exportation.

Avant de toucher au stockage match, établissez un inventaire pour chaque cible :

• identifiant d’application, par exemple <BUNDLE_ID_APP> ;
• équipe Apple, par exemple <TEAM_ID> ;
• certificat actuellement utilisé ;
• présence et emplacement de la clé privée ;
• profil de développement, de test, de distribution ou de publication ;
• cible principale et cibles auxiliaires ;
• responsable de l’accès au compte et de la publication ;
• dernière chaîne de publication qui a produit une archive installable.

Cette vérification doit inclure les extensions, les widgets, les applications Watch et toute autre cible intégrée. Une configuration qui signe seulement l’application principale peut encore échouer au moment de l’archivage, parce qu’un profil ou une identité différente est requis pour une cible secondaire.

Les types de signature ne doivent pas être mélangés dans une seule décision. Le développement, la distribution Ad Hoc, la distribution App Store et la distribution macOS répondent à des usages différents. Pour une application macOS, consultez aussi la procédure Apple consacrée à la création de code signé pour la distribution macOS.

Choisir entre création, import et double chaîne

Pour un projet qui ne possède encore aucune chaîne de signature administrée, l’initialisation de fastlane match peut être directe. Le dépôt de certificats doit toutefois être traité comme un coffre d’équipe : son adresse, sa branche, son secret de chiffrement et le compte autorisé à effectuer les écritures ne doivent pas être dispersés dans les fichiers de build.

Pour une application déjà publiée, l’import est le point de départ prudent. La documentation officielle de l’action fastlane match et de l’import de certificats existants décrit le principe permettant de placer des identités déjà disponibles dans le stockage match, sans faire de match nuke le premier réflexe. Une révocation peut rendre inutilisables des workflows ou des profils encore nécessaires ; elle doit donc être précédée d’un inventaire, d’une sauvegarde exploitable et d’un chemin de retour.

Le test initial doit être exécuté dans un dépôt ou une branche isolée. Il doit reproduire une archive avec le même commit que l’ancienne chaîne, puis comparer :

• la cible effectivement signée ;
• le certificat utilisé ;
• le profil intégré à l’application ;
• le résultat de l’installation sur le dispositif ou de l’envoi vers le canal de distribution ;
• les journaux produits sans intervention graphique.

Le téléchargement d’un fichier .p12 ou d’un profil ne constitue pas une validation suffisante. Le critère utile est une archive signée par le nœud distant et acceptée par le même circuit que l’ancienne chaîne.

Le scénario de décision

Cette grille évite une erreur fréquente : confondre la centralisation des certificats avec l’autorisation donnée à chaque tâche de les modifier. Le référentiel peut devenir commun, alors que les droits d’écriture doivent rester limités.

Isoler les applications, les équipes et les cibles

Un stockage match peut réutiliser un certificat dans une même équipe lorsque les règles de signature le permettent, mais les profils de provisioning restent liés aux identifiants d’application et aux capacités déclarées. La configuration doit donc faire apparaître les variables plutôt que des informations de compte réelles :

app_identifier("<BUNDLE_ID_APP>")
team_id("<TEAM_ID>")
git_branch("<SIGNING_BRANCH>")

Les valeurs ci-dessus sont des placeholders à remplacer dans l’environnement approprié. Ne placez pas l’adresse complète du dépôt, le secret de chiffrement, un jeton de publication ou une clé privée en clair dans un fichier versionné.

Pour chaque application, documentez la relation entre :

• <TEAM_ID> et l’équipe Apple concernée ;
• <BUNDLE_ID_APP> et le profil attendu ;
• <TARGET_NAME> et le certificat utilisé ;
• <SIGNING_BRANCH> et l’espace de stockage autorisé ;
• <RELEASE_CHANNEL> et le type de distribution.

La configuration d’équipe dans Appfile mérite une vérification séparée ; la documentation fastlane consacrée à Appfile explique notamment comment déclarer les éléments d’identification utilisés par les lanes. Cette déclaration ne remplace pas le contrôle d’accès au dépôt de certificats.

Pour plusieurs équipes, utilisez des espaces indépendants, ou au minimum des branches dont la séparation est explicitement contrôlée. Une branche nommée de manière ambiguë peut conduire une tâche à télécharger les identités d’une autre équipe. La règle opérationnelle est simple : une tâche doit pouvoir démontrer pourquoi elle accède à tel espace, à telle branche et à telle cible.

Préparer un Mac distant pour une CI non interactive

Une chaîne de signature distante ajoute des contraintes que le Mac personnel masque souvent. Le nœud peut être redémarré, le compte utilisateur peut changer, plusieurs tâches peuvent s’exécuter successivement et une fenêtre macOS peut demander une confirmation au moment où aucun opérateur n’est connecté.

Sur le nœud distant, appliquez cette séquence :

• créer ou vérifier le compte de service affecté à la CI ;
• installer les outils nécessaires à la version de Xcode retenue par le projet ;
• vérifier l’accès réseau au dépôt match sans copier de secret dans le script ;
• charger les variables d’environnement depuis le gestionnaire de secrets de la CI ;
• exécuter setup_ci avant la synchronisation des certificats ;
• lancer match en mode readonly ;
• seulement ensuite démarrer le build, l’archive et la publication ;
• conserver les journaux permettant de distinguer l’accès au dépôt, le déchiffrement, l’import et la signature.

setup_ci est conçu pour préparer un environnement de CI, notamment avec un trousseau temporaire ; le comportement documenté peut être vérifié dans la documentation officielle de setup_ci. L’objectif n’est pas de rendre la clé privée permanente dans le trousseau utilisateur, mais de donner au job un espace contrôlé qui sera recréé ou nettoyé selon la politique du nœud.

Le mode readonly doit être activé pour les tâches de build, de test, d’archivage et de publication qui consomment des identités déjà approuvées. La CI ne devrait pas créer spontanément un certificat ou modifier un profil simplement parce qu’une variable manque. Une modification silencieuse rend le résultat difficile à auditer et peut provoquer une divergence entre les chaînes.

Les secrets doivent rester séparés par fonction :

Cette séparation répond à un risque concret : si le dépôt, le secret de chiffrement et le jeton de publication sont tous protégés par une seule clé à privilèges élevés, une fuite transforme un problème de build en incident de publication.

Vérifier le comportement du trousseau et de la session

Le trousseau temporaire doit être testé dans les conditions réelles du nœud, et non depuis une session graphique ouverte par un administrateur. La validation doit répondre à plusieurs questions :

• le job peut-il importer la clé privée sans boîte de dialogue ?
• le processus attend-il une confirmation d’accès au trousseau ?
• le redémarrage du nœud modifie-t-il le trousseau ou le chemin de travail ?
• une seconde tâche peut-elle voir les identités de la première ?
• les profils téléchargés correspondent-ils à la cible demandée ?
• les journaux montrent-ils l’étape qui échoue sans exposer les secrets ?

Pour un nœud partagé, séparez les comptes, les répertoires de travail et les trousseaux selon le niveau de risque. Une tâche de développement ne doit pas pouvoir lire l’identité de distribution utilisée par une publication officielle. Même si les jobs ne s’exécutent pas simultanément, les fichiers résiduels, caches et profils peuvent survivre à la tâche précédente.

Réalisez un test d’isolation avec une tâche de développement et une tâche de publication, exécutées successivement ou en parallèle selon le fonctionnement de la CI. La première doit vérifier qu’elle ne récupère pas le profil de production ; la seconde doit vérifier qu’elle retrouve uniquement les ressources autorisées. Après chaque tâche, inspectez l’état du répertoire de travail, du trousseau temporaire et des profils installés.

Cette étape est particulièrement importante pour les projets audio, vidéo ou de design qui produisent plusieurs cibles auxiliaires et des archives volumineuses : la durée du job peut augmenter, et une session graphique laissée ouverte peut masquer une demande d’autorisation. Le fait qu’un opérateur ait réussi une signature via Xcode ne prouve donc pas qu’une exécution SSH ou CI sera non interactive.

Exécuter une migration en cinq étapes contrôlées

Étape première : établir l’inventaire opposable

Exportez les informations nécessaires depuis la chaîne actuelle, sans supprimer les certificats ni les profils. Identifiez les clés privées disponibles, les cibles, les canaux de distribution et la personne responsable de chaque droit. L’inventaire doit également préciser quelle chaîne reste capable de publier si la migration échoue.

Étape seconde : créer un espace de test

Utilisez une branche ou un espace match distinct pour le premier essai. Employez les placeholders <TEAM_ID>, <BUNDLE_ID_APP> et <SIGNING_BRANCH> dans les exemples de configuration, puis injectez les valeurs réelles uniquement par l’environnement sécurisé.

Étape troisième : importer sans révoquer

Pour une application existante, importez les certificats et profils approuvés. Ne lancez pas match nuke, ne révoquez pas les certificats et ne supprimez pas le trousseau tant que la sauvegarde et le retour vers l’ancienne chaîne n’ont pas été vérifiés. Les procédures Apple concernant la modification, le téléchargement ou la suppression des profils doivent être consultées avant toute régénération.

Étape quatrième : construire avec un nœud propre

Sur le Mac distant, préparez le trousseau temporaire, synchronisez en lecture seule, puis archivez le même commit que celui utilisé pour le test de comparaison. Vérifiez la signature de l’archive, le profil intégré et l’installation ou la distribution. Une simple présence des fichiers dans le trousseau ne suffit pas.

Étape cinquième : comparer avant d’autoriser la production

Conservez les deux chaînes jusqu’à ce que le nouveau nœud reproduise le résultat attendu et que la procédure de retour soit documentée. Comparez l’archive, les journaux, le canal de distribution et le comportement après redémarrage. La conclusion doit être l’une des suivantes : migration directe, maintien temporaire d’un fonctionnement en double voie, ou report de la mise en production.

Traiter les rotations, les pannes et le retour arrière

Une expiration de certificat, une modification de profil, un changement de nœud ou une indisponibilité du dépôt match ne doit pas déclencher une réaction improvisée. Préparez une matrice de responsabilité :

• l’administrateur des signatures autorise les changements d’identité ;
• le responsable CI contrôle les variables et le mode readonly ;
• le responsable de publication vérifie l’archive et le canal de distribution ;
• le responsable du nœud confirme la restauration après redémarrage ;
• le propriétaire du projet valide le retour vers l’ancienne chaîne.

En cas de renouvellement, créez et testez la nouvelle identité dans un espace contrôlé, puis conservez l’ancienne jusqu’à la validation du canal de publication. En cas de nœud remplacé, ne supposez pas que le trousseau ou les profils du premier hôte seront disponibles sur le suivant : la procédure doit reconstruire l’environnement à partir des sources autorisées.

La documentation Apple sur la distribution vers des appareils enregistrés aide à distinguer les étapes de signature, de profil et de distribution. Pour une publication macOS, appliquez en plus les contrôles propres au type de code distribué, au lieu de réutiliser aveuglément le flux iOS.

Liste de validation avant admission en production

• [ ] Chaque application possède un <BUNDLE_ID_APP> explicitement documenté.
• [ ] Chaque cible auxiliaire a été archivée et vérifiée.
• [ ] Le certificat et sa clé privée ont été testés ensemble.
• [ ] Le dépôt match et le secret de déchiffrement ont des droits séparés.
• [ ] Les tâches ordinaires utilisent readonly.
• [ ] Le trousseau temporaire fonctionne sans dialogue graphique.
• [ ] Un redémarrage du nœud a été suivi d’une reconstruction complète.
• [ ] Deux tâches distinctes ne peuvent pas réutiliser les identités de manière implicite.
• [ ] L’ancienne chaîne peut encore publier.
• [ ] Le propriétaire de la publication a accepté le résultat de l’archive et de la distribution.

Décider si un Mac distant convient réellement

Un Mac distant apporte une séparation utile lorsque l’équipe doit disposer d’un environnement macOS accessible par SSH, VNC ou console distante, notamment pour des builds Xcode, des tests d’intégration, des exports vidéo ou des tâches de design qui ne peuvent pas être déplacées vers un hôte Linux. Il ne supprime toutefois pas les responsabilités liées aux certificats : l’équipe doit toujours organiser les secrets, les comptes, les profils et le retour arrière.

Un Mac personnel peut rester préférable si le besoin porte sur une utilisation interactive quotidienne, sur des périphériques physiques locaux ou sur une charge lourde et stable qui justifie l’achat d’un matériel dédié. À l’inverse, une machine personnelle utilisée comme seul serveur de signature présente souvent trois limites : elle dépend de la disponibilité d’un poste individuel, elle mélange les sessions de travail et de production, et elle rend les redémarrages ou remplacements plus difficiles à reproduire.

Pour un besoin temporaire, une équipe peut commencer par examiner les options de location de Mac distant de RUVCLOUD, puis réaliser la validation avec des certificats non productifs avant d’envisager une migration officielle. Les responsables qui veulent contrôler précisément le nœud peuvent aussi consulter les solutions de Mac distant disponibles en français.

Le choix ne devrait pas être fondé sur la seule réussite d’un premier build. Il faut vérifier l’isolement, le redémarrage, la restauration du trousseau, la présence des clés privées, la synchronisation en lecture seule, les cibles auxiliaires et la capacité à revenir vers l’ancienne chaîne.

En pratique, la méthode la moins risquée est donc la suivante : un nouveau projet peut adopter fastlane match directement ; une application déjà publiée doit importer ses identités et maintenir une double validation ; la CI distante doit synchroniser en readonly dans un trousseau temporaire ; les écritures et renouvellements doivent rester dans un flux d’administration documenté. Une station personnelle utilisée comme serveur laisse souvent les clés privées dans un environnement difficile à auditer, dépend d’une session ou d’un matériel précis et complique la reprise après panne. Un Mac distant loué par RUVCLOUD peut alors offrir un environnement séparé, administrable et remplaçable pour tester cette chaîne sans acheter immédiatement une machine dédiée, à condition de valider d’abord le processus avec des identités non productives.