En revue de migration, le manager pose une seule question : « En passant de GitHub Actions a des Mac auto-heberges, combien gagne-t-on vraiment en efficacite ? » — Repondre « un peu plus rapide a compiler » ne suffit pas. En 2026, nous avons accompagne plusieurs equipes iOS / Flutter / React Native : apres migration vers des noeuds Mac auto-heberges (Mac mini au bureau, bare metal, ou Cloud Mac avec runner), le gain principal n'est souvent pas la compilation, mais la fin de l'attente en file. Quatre metriques reproductibles, trois tableaux reels, une checklist sur deux semaines et un calcul ROI grossier repondent a « combien ».
Quick Answer : combien gagne-t-on ?
| Ce qui compte | Runner macOS heberge (avant) | Mac auto-heberge (apres) | Gain typique |
|---|---|---|---|
| PR push → checks verts | 42–68 min | 9–16 min | ~70–80 % plus court |
| File d'attente (queue time) | 15–45 min/job | 0–2 min | Quasi zero |
| Archive unique | 11–14 min | 8–11 min | ~15–25 % (cache chaud) |
| Builds TestFlight / nuit release | 1–2 | 3–5 | Debit x2–3 |
| Attente passive / dev / semaine | 3–6 h-pers. | 0,5–1,2 h-pers. | ~75 % en moins |
En bref : l'efficacite vient surtout de l'attente eliminee, pas d'un compilateur magique. Sortir macOS du pool partage, puis persister DerivedData, produit ces ordres de grandeur.
Mesurer quoi avant de parler de « gain »
Beaucoup d'equipes disent « pas si vite » parce qu'elles ne regardent que Job duration dans Actions, pas queue time ni le temps perdu sur Slack. Echantillonnez deux semaines avant et apres, quatre familles minimum :
- File d'attente : secondes entre
job queuedetjob started, P50 / P95 - Boucle PR : dernier push jusqu'aux required checks verts
- Debit release : uploads TestFlight reussis dans une fenetre fixe de 4 h
- Heures d'attente passive : sondage devs ou timestamps de commentaires PR
Export : API GitHub run_started_at − created_at, ou step custom ecrivant les secondes de queue dans un artifact. Sans baseline, le ROI reste indefendable.
| Metrique | Comment | Signal succes |
|---|---|---|
| Queue P95 | API Actions / step custom | De >20 min a <3 min |
| PR feedback P50 | Timestamps PR | Baisse >50 % |
| Taux cache | Taille DerivedData + logs build | De <20 % a >60 % |
| Echecs concurrence | Jobs paralleles sur meme machine | <2 % avec repertoires isoles |
Trois equipes : avant vs apres migration
Donnees reelles anonymisees, meme depot, meme majeure Xcode, deux semaines ouvrables.
Cas A : 12 devs iOS, une app + extensions
Avant : tout sur macos-14 heberge. Apres : 2 Cloud Mac M4 16 Go auto-heberges, DerivedData sur NVMe local. ~18 PR/jour.
| Metrique | Avant | Apres | Delta |
|---|---|---|---|
| PR feedback P50 | 52 min | 11 min | −79 % |
| Queue P95 | 38 min | 0,8 min | −98 % |
| Archive | 12,4 min | 9,1 min | −27 % |
| TestFlight / nuit | 1,5 | 4 | +167 % |
Citation tech lead : « Avant, push a 17 h, merge possible vers 18 h 30. Maintenant je reviens avec un cafe et c'est vert. »
Cas B : 28 devs KMP, Mac pour coque iOS seulement
Jobs macOS et Android se disputaient la fenetre release. Apres : 1 M4 Pro resident + 2 Cloud Mac burst en semaine release (playbook burst).
| Metrique | Avant | Apres | Delta |
|---|---|---|---|
| PR bi-plateforme P50 | 71 min | 24 min | −66 % |
| Queue totale / jour (release) | 6,2 h | 0,4 h | −94 % |
| Attente / dev / semaine | 4,8 h-pers. | 1,1 h-pers. | −77 % |
Cas C : 8 devs indie, 2 releases / mois
Contre-exemple : quasi aucun gain — peu de PR, pas de file, plus de maintenance keychain. Archive 10,2 → 9,4 min (−8 %), queue deja ~0. Le gain depend fortement de la charge ; ne copiez pas les chiffres « enterprise ».
D'ou vient le gain : file, cache, parallelisme
Temps PR ≈ file + prep env + compile/test + upload artefacts
1. File (le plus gros) : pool macOS partage ; P95 >30 min en semaine release ou apres une maj Xcode. Noeud dedie → queue quasi nulle.
2. Demarrage a froid et cache : job heberge detruit l'environnement ; DerivedData, Pods, SwiftPM repartent de zero. Volume persistant → ~20 % sur rebuilds ; voir FAQ cache et disque runners auto-heberges.
3. Parallelisme : 2–3 Mac en matrice ; isolez les repertoires par job sinon les echecs aleatoires mangent le gain.
| Phase | Runner heberge | Apres auto-heberge |
|---|---|---|
| File | 45–70 % | <5 % |
| Deps / index | 15–25 % | 5–10 % (cache persistant) |
| Compile / test | 20–35 % | 15–30 % |
Deux semaines : mesurer, puis basculer le trafic
- J1–2 : baseline queue/duration sur 2 semaines ; 1 Cloud Mac (~5 min), runner
runs-on: [self-hosted, macos, canary], declenchement manuel - J3–5 : persister
~/ci/DerivedDataet cache SwiftPM ; A/B sur meme commit main, 5 runs, P50 - J6–8 : 50 % des workflows release/nightly sur label auto-heberge ; fallback heberge conserve
- J9–10 : required checks PR sur auto-heberge ; alerte disque 80 % et cron nettoyage
- J11–14 : tableau comparatif, ROI management ; 1 machine residente ou burst a la journee
GitHub Actions reste l'orchestrateur — YAML, permissions, environnements inchanges, seul runs-on change. Meme logique que pool ressources CI Mac entreprise : orchestration vs execution separees.
Changement workflow minimal
jobs:
ios-build:
# Avant : runs-on: macos-14
ios-build:
runs-on: [self-hosted, macos, ios-pool]
steps:
- uses: actions/checkout@v4
- name: Log queue metrics
run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARY
Pas encore pret a acheter ? Louez un M4 Cloud Mac a la journee deux semaines — souvent moins cher qu'une heure d'attente collective.
ROI grossier : le temps humain couvre-t-il les machines ?
Avec le cas A (taux horaire blended $55, illustration) :
- 12 devs × 3,7 h-pers./semaine gagnees ≈ 44 h-pers./mois ≈ $2 420/mois (ou moins de conflits merge)
- 2 Cloud Mac M4 16 Go ≈ $206/mois ($103 × 2, voir tarifs)
- Ops plateforme ≈ 4–8 h-pers./mois (disque, certs, upgrade runner)
Gain mensuel ≈ devs × h gagnees/semaine × 4 × taux − loyer machines − h ops × taux
Semaine release : 3e machine burst, basse saison sans surcout annuel. Achat vs location : acheter ou louer des runners Mac.
Quand ne pas migrer
- <30 jobs macOS / mois et Queue P95 <5 min — plafond bas (cas C)
- Personne pour maintenir les runners — disque plein pire que la file
- Conformite VPC propre — reseau et secrets d'abord
- Croire qu'on quitte GitHub Actions — orchestration et audit restent la
Si deux semaines d'AB ne montrent pas >30 % sur le feedback PR, optimisez le workflow (decouper jobs, moins d'archives) avant d'acheter trois Mac.
FAQ
Quel gain typique apres migration ?
Equipes iOS actives : ~70 % sur feedback PR, file quasi zero ; compile seule +15–25 %. Faible volume : parfois quelques pourcents — mesurez d'abord.
Une seule machine suffit ?
Souvent oui pour <10 devs et release serialisee ; matrice ou multi-apps → 2 machines minimum, plafond de concurrence.
Facture Actions baisse de combien ?
Minutes macOS : −60–90 % selon jobs migres ; contrebalancez loyer et ops dans la formule ROI.
Cloud Mac vs Mac mini bureau ?
Meme puce / RAM → perf compile proche ; RTT reseau et NVMe local font la difference. Proximite git et artefacts.
Impact signature / notarisation ?
Pas de miracle, mais environnement stable → moins de derive keychain et profils, moins d'incidents « only CI ».
Delai pour voir le gain ?
Premier jour ouvrable sur queue si runner + cache OK ; boucle PR : deux semaines de mesure avant reporting.
Conclusion et lectures
Migrer de GitHub Actions vers des Mac auto-heberges n'est pas un « beaucoup plus rapide » flou : sur des equipes iOS typiques, ~70 % sur le feedback PR et debit release x2 sont courants — surtout file eliminee, puis cache persistant. Deux semaines d'AB, quatre metriques, une formule ROI : des chiffres que le management comprend. Si l'AB est faible, optimisez le workflow avant d'acheter des machines.