Pourquoi GitHub Runner est l'execution engine du Cloud Mac AI Stack

Nous venons de publier Cloud Mac vs Mac local : de plus en plus d’équipes déplacent Claude Code, l’index CodeGraph et parfois Ollama vers un nœud macOS toujours allumé. L’illusion qui suit : « une fois dans le cloud, chaque git push devient vert ». En réalité, l’agent célèbre la victoire en SSH pendant que GitHub Actions tourne encore sur ubuntu-latest, sans xcodebuild, ou avec des jobs macOS qui attendent trente minutes.

Ce texte n’est ni une fiche Wikipédia sur le « GitHub Runner », ni un tutoriel d’enregistrement actions/runner (réservé à L1-Q02). Il pose une méthode extensible : le Cloud Mac AI Stack, où L1 explique pourquoi une couche d’exécution doit exister seule — et pourquoi louer un Cloud Mac sans runner ne fait qu’une belle session distante.

Langage Stack : Context → Diff → Fact → Workflow

On lit partout Claude Code, Cursor, MCP, OpenHands — rarement qui produit la vérité organisationnelle après l’edit. Dans le Cloud Mac AI Stack, quatre livrables (L2 Inference à part) :

Chaîne (≠ ordre runtime · voir #stack-map)

  Context  →  Diff  →  Fact  →  Workflow
  (MCP)      (Claude Code)  (Runner)  (OpenHands)

La question n’est pas « le LLM est-il assez malin ? » mais : L1 existe-t-il comme couche ? Sans Fact, aucun PR ne devient vert, quel que soit le Context ou le Diff.

Codage vs exécution : pourquoi « Cloud Mac » ne ferme pas la CI

Dans Cloud Mac vs Mac local, nous séparons l’Inference modèle (API) de l’exécution agent (shell sur macOS). Une deuxième coupure manque souvent : la CI après le push — reproductible, auditable, indépendante de la session SSH.

La fracture : tests verts en SSH sur Cloud Mac, workflow ciblant ubuntu-latest. La vérité officielle du dépôt reste rouge. Pour l’iOS, pas de TestFlight sur Linux. L1 exige souvent la même classe macOS Apple Silicon que les postes dev.

Chez les équipes produit francophones (mobile B2B, SaaS avec app native), la conformité demande des builds reproductibles, pas des captures d’écran SSH. Le runner transforme « l’agent dit OK » en Fact — logs, artefacts, checks.

Erreur classique : « tous les tests passent » — PR rouge

Schéma récurrent dans les dépôts clients :

1. Claude Code en SSH sur Cloud Mac : « tous les tests passent ».
2. git push, réunion sereine.
3. Actions avec runs-on: ubuntu-latest.
4. Checks rouges ; log fréquent : xcodebuild: command not found — ou seuls des tests Node verts, pas de job iOS.

Claude Code n’est pas en cause — environnement session ≠ environnement CI. Le runner reproduit l’affirmation en Fact sur la même ligne GitHub Actions self-hosted runner macOS, éventuellement le même nœud que l’agent.

Le runner n’est pas « encore un Mac en location »

• Pas une fiche produit Cloud Mac — la location est L0 ; le runner est processus + labels + politique workspace sur L0.
• Pas le manuel macos-latest — modèles de file et de coût différents pour hébergé vs self-hosted.
• Pas un substitut à OpenClaw — là c’est l’orchestration Workflow ; le runner exécute xcodebuild et fastlane.

Cloud Mac fournit macOS et réseau ; runner branche cette capacité au modèle d’événements GitHub. Sans runner, Cloud Mac = bureau distant ; avec runner, infrastructure.

Cinq niveaux · Stack ≠ ordre d’appel (#stack-map)

Les articles L2–L5 pointeront ici. Le schéma montre des niveaux de responsabilité, pas « qui appelle qui au runtime ».

Cloud Mac AI Stack (responsabilité · bas → haut)

                 ┌──────────────┐
                 │  OpenHands   │  L5 · Workflow
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │     MCP      │  L4 · Context
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │ Claude Code  │  L3 · Diff
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │    Ollama    │  L2 · Inference (optionnel)
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │ GitHub Runner│  L1 · Fact  ← cet article
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │  Cloud Mac   │  L0
                 └──────────────┘

L0 porte la puissance ; L1 porte la confiance org (Fact) ; au-dessus Diff, Context, Workflow.

Pourquoi « execution engine » : rôle et chaîne iOS

En execution engine (moteur d’exécution), L1 assure trois tâches répétables :

1. Événements dépôt — push, pull_request, workflow_dispatch → jobs avec labels runner.
2. Chaîne macOS — xcodebuild, swift test, notarytool, signature — irremplaçable sur Linux.
3. Découplage IA — edit agent ≠ CI verte ; le runner livre artefacts et rapports.

Chaîne L1 (conceptuelle)

  Claude Code (L3, SSH)
           │  git push
           ▼
  GitHub Actions
           ▼
  Runner (L1 · self-hosted · macOS · ARM64)
           ├── xcodebuild
           ├── tests
           ├── archive → .ipa
           └── fastlane → TestFlight

Le codage est en L3 ; la livraison binaire en L1. Sans L1 : « agent terminé » sans build dans App Store Connect.

# .github/workflows/ios-ci.yml (extrait)
jobs:
  build-ios:
    runs-on: [self-hosted, macOS, ARM64, cloud-mac]
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 16' test

Intention de recherche : rarement « GitHub Runner », souvent CI iOS

Les requêtes réelles :

• GitHub Actions self-hosted runner macOS / Apple Silicon runner
• GitHub Runner Mac mini / iOS CI/CD self-hosted
• GitHub Actions iOS build / automatisation TestFlight

Même question d’architecture : dispatcher sur votre nœud M-series plutôt que pool Linux ou macos-latest en file. Cloud Mac ou Mac mini au bureau = matériel ; enregistrement runner + labels = L1. Comparaison matérielle : Mac mini vs Cloud Mac pour équipes iOS. Coûts : L1-Q05 à venir.

Quand Linux suffit — et quand non

Linux suffit souvent : site Next.js statique, API Node/Python/Go en Docker, petit dépôt perso. Signal runner macOS : Xcode, signature, simulateur, TestFlight dans les workflows — ou vous comparez déjà Mac mini vs Cloud Mac.

macos-latest hébergé vs self-hosted Cloud Mac

Règle empirique (non contractuelle) : >10 jobs macOS/semaine, beaucoup sign/archive → L1 sur nœud fixe. En dessous : valider d’abord avec macOS hébergé.

Déploiement : Fact avant Diff

Schéma structurel = responsabilité ; le déploiement inverse souvent l’ordre hype :

1. L0 — Cloud Mac (SSH, egress).
2. L1 — runner, push → vert/rouge reproductible (ce texte).
3. L2–L3 — Ollama Inference, Claude Code Diff sur CI stable.
4. L4–L5 — MCP Context, OpenHands Workflow.

CodeGraph + agent peut toucher 18 fichiers — sans CI macOS, l’archive peut exploser plus tard. Voir aussi Mac mini + Claude Code 2026 (L3) ; ici L1 — runner la nuit, agent le jour, responsabilités séparées.

Décision : L1 comme execution engine

Deux cases à gauche ? Exploitez L1 avant d’empiler MCP. Suite : série L1.

Série L1 : de l’execution engine à une CI macOS opérationnelle

Pierre L1-Q01 (cet article). À suivre :

Google regroupe les clusters ; L2+ suppose un Fact existant — lien retour #stack-map.

FAQ

Cloud Mac vs runner ?
L0 vs L1. Louer ≠ runner automatique.

Runner uniquement sur MacBook ?
Possible ; capot fermé, RAM partagée avec l’agent, IP mobile. CI macOS quotidienne → Cloud Mac 24/7.

Même machine pour runner et Claude Code ?
Pas obligatoire ; même nœud réduit SSH vert / Actions rouge.

OpenClaw ?
Runner = steps ; OpenClaw = déclenchement Workflow. Voir OpenClaw cloud automation.

Diff vs Fact ?
Diff = changement agent ; Fact = checks, logs, artefacts. Le merge s’appuie sur Fact. MCP = Context ; OpenHands = Workflow.

Ollama sous Claude Code sur le schéma — obligatoire ?
Non. L2 Inference optionnel ; L3 souvent API. #stack-map.