Developpeurs comparant les metriques CI entre GitHub Actions et des noeuds Mac auto-heberges

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 ».

Perimetre : chiffres issus d'equipes anonymes (8–35 personnes) entre Q4 2025 et Q2 2026, repos Swift / KMP / RN, materiel M4 16 Go et M4 Pro 24 Go. Adaptez les formules a votre depot. Donnees a jour au 2026-07-20.

Quick Answer : combien gagne-t-on ?

Ce qui compteRunner macOS heberge (avant)Mac auto-heberge (apres)Gain typique
PR push → checks verts42–68 min9–16 min~70–80 % plus court
File d'attente (queue time)15–45 min/job0–2 minQuasi zero
Archive unique11–14 min8–11 min~15–25 % (cache chaud)
Builds TestFlight / nuit release1–23–5Debit x2–3
Attente passive / dev / semaine3–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 queued et job 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_atcreated_at, ou step custom ecrivant les secondes de queue dans un artifact. Sans baseline, le ROI reste indefendable.

MetriqueCommentSignal succes
Queue P95API Actions / step customDe >20 min a <3 min
PR feedback P50Timestamps PRBaisse >50 %
Taux cacheTaille DerivedData + logs buildDe <20 % a >60 %
Echecs concurrenceJobs 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.

MetriqueAvantApresDelta
PR feedback P5052 min11 min−79 %
Queue P9538 min0,8 min−98 %
Archive12,4 min9,1 min−27 %
TestFlight / nuit1,54+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).

MetriqueAvantApresDelta
PR bi-plateforme P5071 min24 min−66 %
Queue totale / jour (release)6,2 h0,4 h−94 %
Attente / dev / semaine4,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 ».

Lecture des tableaux : chez A/B, 60–75 % viennent de la file eliminee, 15–25 % du cache DerivedData / SwiftPM, le reste du parallelisme. Changer de runner sans cache divise le gain par deux.

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.

PhaseRunner hebergeApres auto-heberge
File45–70 %<5 %
Deps / index15–25 %5–10 % (cache persistant)
Compile / test20–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/DerivedData et 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.