2026-04-22 iOS Trousseau & hygiène de provisioning pour la CI sur Mac cloud sans tête loué

Les release managers et responsables iOS CI qui louent des Mac Apple Silicon via SSH heurtent le même mur : l’archive réussit en local, mais la branche identique échoue sur le builder distant avec errSecInternalComponent, « aucun certificat de signature », ou des UUID de provisioning obsolètes. Ce guide du 2026-04-22 explique comment aligner trousseau de session, profils de provisioning et identités codesign pour des jobs sans opérateur sur HK / JP / KR / SG / US. Vous obtiendrez deux tableaux comparatifs, un flux SSH renforcé, un budget NVMe chiffré, et des liens vers signature auto vs manuelle, export & API ASC, et xcodebuild parallèle.

Surface d’échec sur builders sans tête

Contrairement à un portable avec invites UI, un Mac cloud loué exécute souvent xcodebuild depuis un shell non interactif. Les ruptures les plus fréquentes se mappent à trois couches : état du trousseau, fraîcheur du profil, discordance d’identité.

Symptôme	Cause typique	Première instrumentation
errSecInternalComponent pendant codesign	Trousseau de session verrouillé ou clé privée interdite	security list-keychains + audit unlock utilisateur CI
Profil « n’inclut pas le certificat de signature »	UUID disque ≠ profil embarqué dans la cible	Comparer ~/Library/MobileDevice/Provisioning Profiles au rapport Xcode
OK sur branche A, échec sur B	Plusieurs identités même CN ; mauvais choix	security find-identity -v -p codesigning + CODE_SIGN_IDENTITY explicite

Modes de signature : matrice de décision

Avant de toucher au trousseau, décidez si le builder s’appuie sur la signature automatique avec profils gérés par Xcode ou la signature manuelle avec profils versionnés. La réponse dépend de la fréquence de rotation des certificats et du partage d’hôte entre applications.

Mode	Idéal quand	Coût opérationnel	Risque sur Mac SSH seul
Auto + géré Xcode	Itération rapide, peu de bundle IDs	Moins de babysitting de profils	Moyen — dépend de la session Apple ID
Manuel + profils commités	Pipelines entreprise, archives reproductibles	Discipline de rotation plus élevée	Faible — UUID et identités explicites
Trousseau éphémère par job	Hôtes multi-locataires	Automatisation la plus lourde	Fuite inter-équipes minimale si bien fait

Discipline du trousseau pour sessions SSH

Les utilisateurs CI sur Mac cloud doivent traiter login.keychain-db comme une base vivante : un seul principal d’automatisation importe, et le déverrouillage doit être explicite.

1. Pré-vol — vérifier la liste des trousseaux et le trousseau par défaut.
2. Déverrouillage — méthode non interactive approuvée (mot de passe depuis le gestionnaire de secrets, pas en clair dans le dépôt).
3. Listes partitionnées — autoriser codesign et productbuild sans élargir inutilement l’accès.
4. Post-job — supprimer les certificats temporaires et aspirer les identités orphelines.

security unlock-keychain -p "$KEYCHAIN_PASSWORD" ~/Library/Keychains/login.keychain-db

Cycle de vie des profils de provisioning

Les profils sur disque doivent refléter ce que Xcode résout pendant l’archive. Invariants :

• Nom de fichier = UUID du profil <UUID>.mobileprovision — un renommage marketing casse l’automatisation silencieusement.
• Alertes d’expiration T-30, T-14, T-7 pour les profils App Store ; les API ASC peuvent alimenter vos sondes.
• Après rafraîchissement, supprimez les UUID remplacés pour éviter les correspondances « presque justes ».

Associez cette section à options d’export & API ASC afin que l’upload ne parte pas avec une archive verte mais un profil de distribution expiré encore en cache.

Identités, embedded.mobileprovision et export

Utilisez security find-identity -v -p codesigning pour lister, puis épinglez CODE_SIGN_IDENTITY dans les matrices CI. À l’export IPA, vérifiez que le provisioning embarqué correspond au canal (TestFlight vs Ad Hoc). Si vous symbolisez les crashs, reliez l’hygiène de signature aux paquets dSYM pour aligner les UUID de bout en bout.

Agencement des secrets & budget NVMe

Les équipes multi-projets à Singapour et US Est planifient souvent des archives qui se chevauchent. Séparez :

• Racines de signature — répertoires distincts par équipe sous un préfixe contrôlé type /var/lib/ci.
• DerivedData — racines tmp par job comme dans l’article d’isolation.
• Rétention — trois .xcarchive récents pour rollback, taillez les slices plus anciennes.

Pour paralléliser, suivez xcodebuild parallèle afin que la pression CPU n’amplifie pas les retries de signature qui masquent des erreurs de trousseau.

Guides liés sur MacXCode

Combinez avec auto vs manuel pour la stratégie, l’aide pour les bases de compte, et les tarifs si vous ajoutez des hôtes de signature par région.

FAQ : trousseau & profils

Question	Réponse pratique
Partager un Apple ID entre utilisateurs CI ?	Évitez — segmentez les comptes de service par famille d’apps et auditez les connexions trimestriellement.
Faut-il du VNC ?	Seulement pour les invites de confiance initiales ; le régime de croisière doit être SSH + logs. Voir guide VNC.
Rollback le plus rapide quand la signature casse ?	Restaurez le jeu de profils d’hier depuis le contrôle de version et réimportez les identités depuis une sauvegarde hors ligne — puis un seul rebuild.

Pourquoi le Mac mini M4 nu reste roi du débit de signature

Les nœuds Mac mini M4 Apple Silicon offrent une latence codesign prévisible car crypto et I/O frappent le NVMe local sans hyperviseur qui vole le budget d’interruptions — critique quand vous enchaînez archive → export → upload sous SLA. L’empreinte HK / JP / KR / SG / US de MacXCode permet de coller les hôtes de signature aux testeurs tout en gardant le même flux SSH, avec des options 1–2 To pour les équipes qui livrent chaque semaine, et l’isolation bare metal évite la contention d’identités des VM surchargées. Si vous avez plus d’apps que de clés, louez des builders supplémentaires via tarifs plutôt que de surcharger un trousseau unique.