Sur les flottes Mac matures, le cache de compilation quitte la restauration d’un arbre DerivedData entier pour des artefacts adressables plus fins. Avec Xcode 26, le Compilation Cache partage unités vérifiables et sorties d’index entre jobs ; le DerivedData classique reste un répertoire local vulnérable aux écritures concurrentes et aux contaminations d’arbre. Figez trois rôles : tier chaud local, NVMe nœud-cache, service gRPC distant. Les patterns pool sont dans 2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ?. Lorsque les gros binaires quittent le chemin de compilation pour symboles et archives, passez-les par la chaîne artefacts plutôt que par le compartiment « compile » — voir la FAQ sur gros artefacts, dSYM et stockage S3/MinIO proche runner. En amont, les clones froids et résolutions de dépendances restent souvent le premier mur : reliez ce sujet à la FAQ CI Mac d’entreprise sur grands dépôts, Git blobless/shallow et files CocoaPods/SwiftPM.
1. Compilation Cache et DerivedData : un seul palier de modèle de hit
La réutilisation DerivedData repose sur des chemins stables et des empreintes de répertoire : une restauration chaude paraît instantanée, mais l’invalidation reste grossière. Un bump mineur d’Xcode, une dérive du SDK, des drapeaux compilateur ou un graphe de modules modifié peut forcer un redémarrage à froid de tout le compartiment. Le Compilation Cache (à lire en parallèle de la narration produits partagés côté Apple) découpe les clés sur des sous-graphes plus petits pour ne recompiler que la partie modifiée, au prix d’une métadonnée plus riche, de hachages plus stricts et d’une exploitation qui surveille les préfixes de version. Un compromis CI fréquent conserve une couche chaude en lecture seule sur disque rapide, isole chaque job sous -derivedDataPath, et confie au cache distant uniquement les gros objets à forte répétition — caches de modules, intermédiaires stables — tout en gardant le bac DerivedData par job pour le triage.
2. Jobs parallèles et cache gRPC distant : bande passante, contre‑pression et cohérence
Avec gRPC vers un cache distant, le plafond est souvent le produit fils de compilation × lectures cache/s, pas le débit séquentiel annoncé. Auditez TLS/mTLS, pools de connexions et keepalive, et le partitionnement par build Xcode et tranche SDK. Mesurez le P95 à froid puis à chaud avant d’ajouter des runners, et gardez un repli compilation locale. Colocalisez cache et exécuteurs dans la même zone : NAT saturé ou disque rotatif rend un bon hit rate inutile en latence de queue.
3. Montée en charge NVMe : d’abord les workers, ensuite les nœuds cache
Le NVMe worker sert surtout l’aléatoire (index, link, décompression) ; le NVMe nœud-cache, l’écriture séquentielle et des lectures stables quand beaucoup de jobs relisent les mêmes clés. Évitez d’agrandir les SSD runners pendant que gRPC vit sur du NFS ou du mécanique. Ajoutez alertes espace et attente disque, des runbooks de purge nommés, et distinguez LRU temporel et flush majeur Xcode.
- Les préfixes de clé doivent inclure version majeure Xcode, tranche SDK et identité de dépôt pour éviter les hits silencieusement incorrects.
- Exploitez deux modes d’éviction : LRU borné dans le temps et purge complète sur version majeure.
- Suivez conjointement taux de miss et temps mural de compilation, pas seul un compteur de hits « vanité ».
4. FAQ de choix pour les responsables plateforme
- Quand un cache gRPC distant est-il pertinent ? Lorsque plusieurs dépôts et branches partagent des modules lourds et que les SSD runners se remplissent vite ; les petites équipes peuvent commencer par un NVMe rapide et un DerivedData compartimenté.
- Le taux de hit a chuté de moitié du jour au lendemain ? Vérifiez d’abord la dérive Xcode ou SDK, puis des drapeaux non reproductibles — horodatages embarqués, macros instables.
- Le Compilation Cache remplace-t-il les caches SwiftPM ? Non : résolution des dépendances et caches de produits de compilation méritent des compartiments séparés pour ne pas empoisonner les espaces de clés.
- Conformité et réseau privé ? Faites tourner gRPC sur un maillage interne ou des liaisons dédiées, avec authentification, journaux d’audit et barème de sécurité alignés sur votre registre d’artefacts.
Pourquoi des Mac mini Apple Silicon restent le socle de cette pile
Tout ce qui précède se comporte sur macOS en CI comme sur le poste développeur, ce qui réduit l’écart entre « ça marche chez moi » et « ça casse dans le pool ». Les Mac mini sur Apple Silicon combinent un NVMe à bande passante élevée avec une mémoire unifiée favorable aux indexations et décompressions concurrentes, sans les histoires thermiques de nombreuses tours PC génériques. Une consommation au repos de l’ordre de quelques watts rend supportables les tests de trempage nocturnes et les chauffeurs de cache, tandis que Gatekeeper, SIP et FileVault offrent aux équipes sécurité un récit plus clair pour des hôtes peu surveillés.
Si vous dimensionnez la prochaine vague de nœuds de build, alignez d’abord disque et réseau sur le ventilateur gRPC avant d’empiler des étiquettes CPU. Le Mac mini M4 reste une base 2026 pragmatique pour les équipes qui veulent une performance prévisible par unité de rack et un fonctionnement silencieux. Pour de la capacité Mac cloud sans cycle d’achat long, ouvrez la page d’accueil Macstripe pour comparer régions et modèles, puis cartographiez-les à côté de vos points de terminaison cache. C’est aussi le bon moment pour ajouter un nœud de référence dédié depuis l’accueil et figer vos lignes de base avant d’élargir le pool.
