fastlane match : certificat synchronisé, signature en échec ? Diagnostic sur Mac distant en 2026

Synchronisation réussie, mais identité de signature introuvable

La synchronisation par fastlane match apporte des certificats et des profils à une machine ; elle ne prouve pas que le processus Xcode peut utiliser la clé privée associée, ni que le projet sélectionne les bons éléments. Le premier diagnostic consiste donc à suivre le contexte réel de la tâche de compilation, plutôt qu’à relancer aveuglément la synchronisation.

La documentation de fastlane match décrit la synchronisation des éléments de signature sur une nouvelle machine et distingue les identifiants du dépôt des certificats et profils synchronisés. En pratique, il faut séparer les faits suivants :

• Le dépôt d’identifiants est accessible et les éléments nécessaires peuvent être lus ou déchiffrés.
• Le certificat est présent sur le Mac et la clé privée correspondante est disponible pour l’utilisateur du travail.
• Le profil de provisioning est installé, mais il correspond bien à la cible, à l’identifiant de l’app et à l’usage prévu.
• La configuration Xcode de l’archive sélectionne effectivement ces éléments.

Une réussite à la première étape n’établit pas la réussite des suivantes. Les journaux doivent permettre de repérer à quelle phase la tâche s’arrête, sans contenir de mot de passe, de jeton, de clé privée, de contenu de dépôt confidentiel ni d’identifiant sensible.

Pourquoi fastlane match indique-t-il une synchronisation réussie alors qu’aucune identité n’est trouvée ?

Parce que le résultat de synchronisation et l’accès à une identité de signature utilisable sont deux contrôles différents. Une identité exploitable comprend un certificat et sa clé privée correspondante ; un certificat seul ne permet pas de signer. La documentation Apple sur les certificats de signature d’équipe précise le rôle de ces certificats et leur partage. La note technique d’Apple sur les certificats de signature de code aide à comprendre la relation entre le certificat et l’identité utilisée pour signer.

Commencez par confirmer quel compte système lance réellement la compilation. Une session graphique ouverte avec un compte administrateur ne garantit pas qu’un agent de compilation, un travail automatisé ou une session distante s’exécute sous ce même compte. Relevez le compte d’exécution, le répertoire de travail, les variables d’environnement non sensibles et la commande réellement appelée. Comparez ensuite ces éléments avec ceux d’une exécution locale réussie.

Pour isoler le point de rupture, conservez les journaux de chaque phase : accès au dépôt, récupération ou déchiffrement des éléments, installation, compilation et signature. Ne copiez pas de secrets dans un rapport partagé pour rendre ces étapes comparables. Si l’identité est introuvable pour le compte de compilation, examinez d’abord l’accès au trousseau et à la clé privée ; ne révoquez pas le certificat avant d’avoir établi qu’il est réellement inutilisable.

Sur le nouveau Mac distant, le compte d’exécution fait la différence

Une nouvelle machine introduit souvent une différence discrète : la synchronisation est lancée depuis une session interactive, tandis que l’archive est exécutée par une autre tâche, avec un autre compte ou un environnement différent. Si les certificats ont été téléchargés mais que le signeur n’est pas utilisable, comparez les contextes avant de modifier les actifs de signature.

La vérification doit rester attachée à l’exécution qui échoue :

• Confirmez le compte du processus qui lance fastlane et celui qui déclenche Xcode.
• Vérifiez que les deux phases utilisent le même environnement prévu, notamment le répertoire de travail et les paramètres non secrets nécessaires au projet.
• Établissez si le trousseau contenant la clé privée est accessible à ce compte.
• Examinez si la tâche dépend d’une session de bureau ouverte ou d’une configuration disponible uniquement pour un autre utilisateur.
• Comparez le résultat de la phase de signature avec celui d’une compilation locale, sans partager de données privées.

Que faire si la clé privée du Mac distant n’est pas dans le trousseau de session utilisé ?

Identifiez d’abord le compte et le trousseau qui devraient fournir la clé privée, puis vérifiez si l’identité correspondante y est disponible. La documentation Apple décrit la place du trousseau dans la gestion des certificats et des clés privées ; l’absence de la clé privée empêche d’utiliser le certificat comme identité de signature, même si ce certificat est visible. Consultez la présentation Apple de la signature de code pour distinguer certificat, clé privée et opérations de signature.

Ne traitez pas automatiquement un trousseau verrouillé, inaccessible ou absent comme un certificat expiré. Ces situations n’appellent pas les mêmes corrections. Déterminez si le processus possède le bon contexte d’exécution et si la clé attendue est disponible, puis corrigez l’accès selon la politique de sécurité du projet. La saisie ou le stockage d’un secret en clair dans un script, dans les journaux ou dans le dépôt n’est pas une méthode de dépannage sûre.

Un contrôle utile consiste à comparer les conditions d’exécution, pas à recopier l’ensemble du trousseau d’un compte vers un autre sans diagnostic. Si l’équipe utilise plusieurs utilisateurs pour les tâches interactives et automatisées, documentez quel compte est autorisé à signer et comment les éléments protégés lui sont fournis.

Le profil est présent, mais le projet sélectionne un autre réglage

Un profil de provisioning installé n’est pas nécessairement celui utilisé par l’archive. Le projet peut contenir plusieurs cibles, des configurations distinctes ou des identifiants d’app différents ; le profil choisi doit être cohérent avec la cible et l’usage de distribution réellement construits.

La documentation fastlane sur l’installation des profils et certificats distingue l’emplacement des profils des éléments conservés dans le trousseau. De son côté, la référence Apple des réglages de compilation Xcode décrit les paramètres de signature du projet. Il faut donc contrôler le profil installé, puis les réglages effectifs de l’archive, plutôt que de conclure à partir de la seule sortie de match.

Comparez chaque cible concernée : application principale, extensions et autres composants ayant leurs propres exigences de signature. Pour chacune, vérifiez l’identifiant d’app, la configuration de compilation et l’usage de distribution visé. Si l’identifiant de la cible ne correspond pas au profil disponible, l’installation réussie de ce profil ne corrige pas la sélection faite par Xcode.

Le réglage observé dans l’interface du projet n’est pas toujours une preuve suffisante pour une tâche automatisée. La configuration réellement utilisée par l’archive peut dépendre du schéma, de la configuration de compilation et des paramètres passés au travail. Notez les valeurs effectives dans le contexte de la commande qui échoue, en masquant toute donnée sensible.

Comment distinguer un profil de provisioning installé du profil réellement choisi ?

Comparez l’identifiant et la cible de l’app avec la configuration employée au moment de créer l’archive, puis vérifiez les réglages de signature effectifs. La documentation Apple sur les profils de provisioning de distribution App Store présente le rôle de ces profils ; elle ne permet pas de conclure qu’un projet les sélectionne automatiquement dans toutes ses configurations.

En lecture seule, la tâche CI ne répare pas les identifiants

fastlane match peut être utilisé en mode lecture seule pour une synchronisation destinée à une tâche CI, à condition que les éléments requis existent déjà et que le travail puisse y accéder. Ce mode évite de traiter une compilation ordinaire comme une opération de création ou de modification des actifs de signature ; il ne corrige ni un certificat manquant, ni une clé privée inaccessible, ni un profil inadapté.

Le mode readonly convient-il à une publication ?

Oui, lorsqu’il s’agit d’une tâche de publication qui doit consommer des éléments de signature déjà préparés, que le dépôt est accessible et que les secrets nécessaires sont fournis selon une méthode sécurisée. Il ne convient pas à une première mise en place qui nécessite de créer ou modifier ces éléments. La documentation officielle de fastlane match sur readonly et les identifiants distingue le comportement de synchronisation et la gestion des secrets : le mode lecture seule n’est pas une réparation automatique.

Pour repérer le type d’échec, découpez le diagnostic en trois phases distinctes. Un refus d’accès au dépôt intervient avant la récupération des actifs ; une erreur de déchiffrement indique que la tâche ne peut pas lire les éléments protégés ; une erreur au moment de signer oriente plutôt vers la clé privée, le trousseau ou les réglages Xcode. Ces diagnostics sont des pistes à confirmer avec le journal complet, pas des causes certaines déduites d’un seul message.

Un exemple de lancement en lecture seule peut prendre cette forme, à adapter au type de profil et à la configuration du projet :

bundle exec fastlane match appstore --readonly

Cet exemple suppose que le projet utilise ce type de profil et que les dépendances fastlane sont configurées pour le dépôt concerné. Ne placez pas de mot de passe, de clé de déchiffrement ou de jeton directement dans la commande enregistrée. La documentation de fastlane doit rester la référence pour les paramètres de l’action et la méthode de fourniture des identifiants.

La compilation passe, mais l’archive de publication échoue

Une compilation de développement réussie ne valide pas à elle seule le parcours de distribution. Une archive destinée à la distribution peut mobiliser une autre configuration, une autre sélection de profil ou une identité différente ; il faut lire l’erreur à l’étape où elle survient, puis la confronter à l’usage demandé.

Distinguez au minimum les opérations suivantes : compilation du projet, création de l’archive, export de l’app, puis envoi à la plateforme de distribution. Une archive qui échoue n’est pas le même problème qu’un export refusé après création de l’archive, et aucun des deux ne prouve qu’un envoi a été tenté. Cette séparation évite de modifier les identifiants de signature pour une erreur qui appartient à une étape ultérieure.

La signature fonctionne en local, mais l’archive échoue sur le Mac distant : où commencer ?

Commencez par comparer le compte exécutant la tâche et l’accès à sa clé privée ; poursuivez avec le profil et les réglages de la configuration d’archive. Ensuite, repérez si l’échec apparaît pendant la signature, l’export ou l’envoi. La documentation Apple sur la distribution d’une app à des appareils enregistrés décrit les étapes de préparation et de distribution ; le parcours exact dépend toutefois de la destination choisie. Une erreur isolée n’identifie donc pas nécessairement une cause unique.

Évitez de conclure qu’une version de fastlane ou de Xcode est défectueuse à partir d’un seul cas. Gardez la commande, le schéma, la configuration visée, le compte d’exécution et le passage de journal pertinent ; retirez les secrets et identifiants privés avant de comparer les résultats ou de demander de l’aide.

Valider le parcours avec une archive reproductible

Quand les contrôles précédents ne révèlent plus de différence, relancez une archive avec le projet, le schéma et la configuration qui correspondent réellement au parcours de publication. Une compilation Debug ou un test d’une autre cible ne suffit pas à valider cette chaîne.

Consignez les éléments qui permettront de reproduire et de circonscrire le résultat :

• Le compte système qui a lancé le travail et le contexte utilisé par la tâche automatisée.
• La source des identifiants, sans en consigner le contenu secret.
• Le type de profil et l’usage de distribution attendus.
• La configuration d’archive et les cibles signées.
• La phase atteinte : compilation, archive, export ou envoi.
• Le résultat vérifiable de l’archive et les messages de signature associés, après suppression des données sensibles.

Une archive réussie établit uniquement que cette combinaison de projet, de configuration, de compte et d’actifs a fonctionné pendant cette exécution. Elle ne prouve pas que toutes les cibles, tous les profils ou tous les parcours de distribution ont été testés. Pour élargir la validation, répétez la procédure avec les autres combinaisons réellement utilisées par l’équipe, au lieu de généraliser à partir d’un seul résultat.

Choisir entre corriger la chaîne existante et changer d’environnement

Quand la signature échoue uniquement sur le Mac distant, la priorité est de distinguer un défaut de contexte d’exécution d’un défaut de configuration du projet. Le premier peut venir d’un compte différent, d’un trousseau inaccessible ou d’identifiants non fournis à la tâche ; le second peut concerner le profil, la cible ou les réglages de l’archive. Remplacer immédiatement le certificat risque de masquer la cause et de compliquer la publication.

Si le Mac actuel exécute déjà les tâches requises et que la panne vient d’un profil mal sélectionné, changer de machine n’apportera pas de correction : il faut ajuster le projet et valider l’archive. En revanche, si l’environnement actuel ne permet pas de maintenir une session de compilation cohérente, de protéger les identifiants ou de reproduire le travail de publication, un Mac distant géré peut éviter certains coûts et contraintes d’un poste dédié, tout en imposant de vérifier soigneusement l’accès réseau, le compte d’exécution, la confidentialité des secrets et la continuité d’accès.

NodeMini propose des environnements Mac distants accessibles à distance ; les modalités d’accès et les offres sont à vérifier sur la page de présentation des Mac distants. Si le blocage vient du trousseau ou du réglage Xcode, la location ne remplace pas le dépannage de signature ; si le besoin est plutôt de disposer d’un environnement macOS pour les tâches d’archive, elle peut éviter l’achat d’une machine réservée à cet usage. La page d’accueil de NodeMini permet d’examiner les informations générales avant de retenir cette option.

Le critère de décision reste le même : corrigez d’abord la cause identifiée et prouvez le parcours avec une archive réelle. Pour les équipes qui ont surtout besoin d’un environnement Mac disponible pour construire et publier à distance, comparez ensuite cette solution à un Mac local ou à une autre organisation de compilation, en tenant compte de la gestion des secrets et de la reproductibilité de la chaîne fastlane match.