2026, pics CI à court cycle : runners GitHub Actions macOS auto-hébergés — pool élastique de Mac cloud ou nœuds permanents ?

Lorsque les équipes iOS et macOS livrent sur des cadences serrées, la CI ressemble rarement à une ligne plate : des fenêtres courtes où de nombreux workflows se superposent dans la même heure. Les minutes macOS hébergées par GitHub fondent vite, et les organisations ajoutent des runners auto-hébergés sur du matériel Apple. Le prochain carrefour compte : un pool élastique de Mac cloud que l'on monte et baisse, ou des nœuds permanents toujours chauds. La réponse tient à la forme des files d'attente, à la latence acceptable et à l'emplacement des caches — pas aux slogans fournisseurs.

Modélisez le pic avant d'acheter de la capacité

Les pools élastiques gagnent quand les minutes occupées sont rares mais les pics de concurrence sont hauts : quelques jours par mois où six runners suffisent à peine, et le reste du temps deux machines suffiraient. Les nœuds permanents gagnent quand le travail arrive en continu — nightlies, matrices par PR, robots qui ne doivent jamais attendre le provisionnement. Tracez sept jours d'horodatages runners depuis vos journaux Actions : profondeur médiane de file, p95 entre queued et in_progress, et fréquence des accès concurrents aux actifs de signature sur le même hôte. Si le p95 de file dépasse déjà le budget « pouces qui tournent » acceptable, l'élasticité n'aide que si les machines supplémentaires deviennent prêtes plus vite que la file ne grossit — sinon vous payez des cold starts en plus de la queue.

Pour la pression « semaine App Store » et le cadrage finance louer/acheter, nous avons déjà publié une matrice réutilisable : Builds d'urgence et revue App Store en 2026 : acheter un Mac ou louer un Mac cloud à la journée ou à la semaine ?

La latence, ce sont trois chiffres — pas un slogan

Séparez la latence plan de contrôle (le runner prend le job), la latence données (fetch Git, restauration cache, upload d'artefacts) et la latence outil (compilation Xcode). Les pools élastiques réduisent souvent la contention côté labels, mais si chaque VM neuve refait cinq minutes d'amorçage dépendances, le mur d'horloge bouge à peine. Les runners permanents amortissent cet amorçage sur des centaines de jobs — au prix de l'énergie idle et du risque de dérive si vous n'épinglez pas les images.

Le chemin réseau compte : mesurez RTT et débit entre runner, hébergeur Git et cache distant (S3 compatible, Artifactory, cache Actions). Une poignée TLS lente vers une région lointaine apparaît comme « Xcode lent » sur une capture. Pour la persistance headless et launchd, voir aussi Déployer OpenClaw sur un Mac cloud en 2026 : validations macOS face à un VPS Linux, persistance launchd et FAQ de dépannage reproductible.

Caches : disque collant vs magasin d'objets partagé

Les builds Apple sont sensibles au cache. DerivedData, CocoaPods et artefacts SwiftPM dominent le temps de restauration. Les nœuds élastiques qui jettent le disque à l'arrêt doivent pousser les caches vers l'extérieur — compartiments versionnés ou partage réseau majoritairement en lecture — avec des clés strictes liées à la version mineure de Xcode et aux hash de lockfiles. Les nœuds permanents gardent des caches chauds en local, mais il faut évincer de façon déterministe pour qu'une branche n'empoisonne pas une autre. Dans les deux modèles, traitez les miss de cache comme partie du budget SLO, pas comme des accidents rares.

Matrice de décision en un coup d'œil

Utilisez le tableau comme premier filtre ; validez ensuite avec la liste de paramètres ci-dessous.

Liste de paramètres exécutables (à coller dans les runbooks)

Voici les leviers que nous écrivons réellement en YAML, variables Terraform ou tableaux wiki internes lorsque nous dimensionnons une flotte. Adaptez les noms à votre couche d'orchestration ; l'intention prime.

# Concurrence du workflow (sérialiser les chemins bruyants)
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

# Plafond d'éventail matrix (éviter de saturer les caches)
strategy:
  max-parallel: 4

# Flotte runners (documenter dans le dépôt ops, pas seulement l'UI)
baseline_always_on_runners: 2   # capacité chaude minimale
burst_elastic_runners_max: 8    # plafond supporté par le fournisseur
idle_shutdown_minutes: 45       # élastique uniquement ; éviter le pompage

# Clés de cache (doivent inclure toolchain + lockfiles)
cache_key_prefix: xcode-16_2-spm-${{ hashFiles('**/Package.resolved') }}

# Cibles SLO (alerter si dépassé)
queue_pickup_p95_seconds: 60
cache_restore_p95_seconds: 120

Chaque semaine, confrontez les heures runner facturées au débit de PR fusionnées. Si le coût monte sans accélération de livraison, resserrez d'abord les groupes de concurrence ou les clés de cache avant d'ajouter du métal.