2026 — Pool CI Mac d'entreprise : codesign concurrent, isolation Keychain et profils de provisioning

Plusieurs jobs codesign sur un même Mac provoquent des courses sur le Keychain, des profils en double ou des collisions sur DerivedData. Les pools mélangent runners longue durée et files PR : peut-on signer en parallèle sans état de confiance partagé ? Nous traitons coffres de clés, profils, workspaces, déploiement et FAQ. Pour le pool et le cache disque, voir 2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ? et, pour les volumes persistants et Actions, 2026 — Multi-runners Mac auto-hébergés & CI parallèle : cache GitHub Actions, disque persistant, concurrence, disques pleins et nettoyage d'artefacts — FAQ pool d'entreprise.

1. Modes de panne que vous ciblez réellement

Les ruptures typiques : importations dupliquées dans le trousseau login, le même UUID de profil installé deux fois, des scripts supposant un seul HOME, ou un job qui supprime des fichiers temporaires de signature pendant qu'un autre archive. Les invites interactives sont particulièrement pénibles en automatisation car elles bloquent la file jusqu'au timeout. Forme de correctif : partitionner secrets et arbres mutables par identifiant de job, désactiver les invites graphiques pour les flux sans présence lorsque la politique le permet, et effacer explicitement afin que les clés ne survivent ni aux locataires ni entre voies « PR » et « release ».

Règle pratique : si deux jobs peuvent toucher le même fichier de trousseau ou le même nom de profil sur disque, supposez qu'ils le feront — sous charge, pas sur votre portable de démonstration.

2. Stratégies de Keychain : login partagé versus coffres par job

Le trousseau login partagé suffit jusqu'aux verrous globaux. Les coffres par job (RUN_ID, déverrouillage pendant le job, suppression en finally) séparent les identités et clarifient l'audit. Compromis : un trousseau par compte de service sur hôte statique à faible concurrence. Documentez le partage GUI/SSH sur runners prod et séparez si possible hôtes humains et CI sans affichage.

3. Profils de provisioning : arborescence et collisions

Fichiers UUID : doublons d'habilitations ⇒ codesign intermittent. Préférez le workspace local et des spécificateurs explicites plutôt que ~/Library/MobileDevice/Provisioning Profiles implicite ; sinon copiez par job. Tracez profils par bundle id et capacités.

4. Isolation des espaces de travail au-delà de la signature

Isolez DerivedData, caches SwiftPM/Pods et staging notarisation sous une racine par job (/Volumes/builds/<job>), TMPDIR inclus. Nettoyage post-job des workspaces et coffres ; caches chauds par version Xcode pour éviter les fuites d'habilitations entre branches.

5. FAQ : comparaison rapide des schémas

D : Un trousseau Apple ID pour plusieurs dépôts ? Fichiers + import dans coffres par job pour borner le blast radius.

D : VM éphémères vs Mac statiques ? VM propres ; Mac chauds pour l'incrémental avec nettoyage strict — pas de trousseaux partagés entre niveaux de conformité.

D : Où déchiffrer ? Workspace + coffre jetable, pas le login partagé.

D : App Store vs entreprise ? Comptes ou hôtes séparés pour éviter le croisement des profils d'export.

D : Notarisation parallèle ? Sérialiser ou isoler les jetons comme pour la signature.

6. Étapes de déploiement qui passent l'examen sécurité

  1. Inventoriez certificats et emplacements de profils (trousseaux, chemins Library, Fastlane).
  2. Déployez en canari des coffres par job ; l'impact horloge est en général faible face à la compilation.
  3. Déplacez les profils vers le workspace local ; faites échouer la CI sur les UUID dupliqués.
  4. Attribuez des OBJROOT, SYMROOT et DSTROOT uniques par job dans les modèles d'orchestrateur.
  5. Documentez la révocation : quelle identité tient chaque pool et comment vider les hôtes sans surprise.

7. Checklist opérateur avant d'augmenter la concurrence

  • Chaque job crée-t-il et supprime-t-il son propre fichier de trousseau sur un chemin déterministe ?
  • Les profils sont-ils épinglés par version et installés sans écraser des UUID parallèles ?
  • HOME ou au moins les variables liées à la signature sont-elles bornées par job, pas par défaut machine ?
  • Les scripts de nettoyage retirent-ils les clés privées du disque même lorsque les jobs échouent en cours de route ?
  • Avez-vous testé deux archives simultanées sur la même classe de runner — pas seulement des builds séquentiels ?

Pourquoi du matériel Mac mini authentique reste pertinent pour les pools orientés signature

La pile de signature d'Apple suppose un matériel Mac pris en charge et un micrologiciel cohérent — ce que des nœuds Mac mini fournissent nativement — ainsi qu'un CPU efficace par watt pour enchaîner compilation et signature. Gatekeeper, SIP et les options de chiffrement de disque simplifient les dossiers sécurité par rapport aux fermes PC bricolées, et la consommation au repos d'Apple Silicon reste assez basse pour garder des pools « chauds » économiquement défendables.

Standardisez sur des hôtes de classe Mac mini M4 avec les règles d'isolation ci-dessus, scalez horizontalement avant de sursouscrire une session de login unique, et ouvrez la page d'accueil Macstripe pour aligner régions et modèles avec votre niveau de conformité. Si vous cherchez un point d'entrée silencieux et sobre en énergie pour industrialiser cette architecture, le Mac mini M4 reste un choix rationnel — c'est le bon moment pour l'associer à une flotte cloud dédiée et à des runbooks clairs.