Commençons par quantifier l'angoisse. Volume de commits : Kyle Daigle (COO) et Vlad Fedorov (CTO) ont confirmé en avril que les agents IA poussent environ 275 millions de commits par semaine, en route vers 14 milliards pour 2026, soit quatorze fois le total de 2025. Volume de requêtes : les pull requests générées par des agents passent de 4 millions par mois en septembre 2025 à 17 millions par mois en mars 2026. Calcul : les minutes hebdomadaires de GitHub Actions bondissent de 500 millions (2023) à 2,1 milliards sur une seule semaine en avril 2026. Disponibilité : rien qu'en février, 37 incidents de plateforme ; du 9 au 13 avril, les sessions d'agent atteignent 54 minutes d'attente au lieu des 15 à 40 secondes habituelles avec un pic d'échec à 97,5 % ; le 6 mai, l'incident Copilot Cloud Agents porte le taux d'échec des runners à environ 17,1 %.

GitHub assume le constat. Fedorov a remplacé le plan capacitaire 10x par un objectif 30x, migre les chemins critiques de Ruby vers Go, isole Git et Actions, déploie les Stacked PRs pour découper les soumissions massives d'agents et envisage même de laisser les mainteneurs désactiver les pull requests. Les remèdes structurels prennent du temps. Pour toute équipe iOS adossée aux runners macOS hébergés, la queue tail et les échecs sporadiques deviennent l'état normal du second semestre 2026 – il n'y a plus de fenêtre « ça va se calmer ».

Conclusion : amarrer la stabilité de la pipeline à un unique pool central de runners coûte de plus en plus cher dans l'ère des agents. Les deux sections suivantes resserrent la focale sur macOS, puis sur la dualité humain / agent.

Les runners Linux hébergés tournent sur de vastes pools x86_64 largement fongibles. Les runners macOS sont contraints par la disponibilité physique d'Apple Silicon et par les licences logicielles : le pool est très inférieur en taille et le tarif à la minute environ dix fois supérieur à Linux. Jusqu'en 2025, l'awareness de file et les retries absorbaient la variance. L'ère des agents brise cette hypothèse : un seul refactoring nocturne par un agent peut ouvrir des dizaines de PR en quelques heures, et chaque PR déclenche à la chaîne lint, unit, intégration, archive et notary. Le taux d'utilisation ρ du pool macOS frôle 1 ; la théorie des files d'attente dit que l'attente explose bien avant que ρ n'atteigne 1. Le P50 passe des secondes aux minutes ; le P95 dépasse facilement la dizaine.

Il faut y ajouter le cumul retry storm et démarrage à froid. Un test « flaky » échoue une fois, l'agent renvoie automatiquement la demande, plusieurs agents s'enroulent dans la boucle « demander – échouer – redemander » et le service d'allocation voit un thundering herd. Le démarrage à froid des runners macOS hébergés est de 60 à 120 secondes : insurmontable pour les jobs courts (lint, vérifications PR) et brutal pour les jobs longs (archive, dépose TestFlight, notarisation) qui attendent déjà en file. Le tableau ci-dessous compare Linux, macOS hébergé et macOS self-hosted dédié sous la charge des agents – à copier directement dans un cahier des charges.

Si votre dépôt iOS a déjà appliqué le guide runner self-hosted avec runners au niveau organisation et concurrency groups, l'étape suivante consiste à séparer par étiquette les runners destinés aux PR d'agents et ceux destinés aux PR humaines. Si vous êtes encore 100 % hébergé, voyez les seuils en §4.

Mai 2026 a vu deux campagnes de chaîne d'approvisionnement détruire l'hypothèse implicite que les commits automatiques étaient exemptés de revue. Mini Shai-Hulud, un ver npm, a volé des jetons OIDC GitHub Actions pour fabriquer une provenance SLSA / Sigstore valide ; pour persister, il a écrit des hooks malveillants dans ~/.claude/settings.json et .vscode/tasks.json – les fichiers de configuration que les outils IA traitent comme des instructions de confiance. Sur Linux il a installé gh-token-monitor.service, un piège qui détruit le répertoire personnel lors d'une rotation de jeton GitHub. Megalodon a été plus direct : le 18 mai, entre 11:36 et 17:48 UTC – six heures – un attaquant a poussé 5 718 commits dans 5 561 dépôts à l'aide d'identités forgées telles que build-bot, auto-ci, ci-bot et pipeline-bot. Les commits injectaient des workflows GitHub Actions pour exfiltrer jetons OIDC, clés SSH, identifiants Docker et secrets cloud vers 216.126.225.129:8443. Le point commun : les messages de commit et le champ author imitent la maintenance automatique normale et les fenêtres choisies sont volontairement à faible attention.

Pour les équipes iOS / macOS, l'enjeu est explicite : le trousseau Match, l'API Key d'App Store Connect, les identifiants de notarisation, profiles et provisioning vivent précisément là où l'injection OIDC et workflow veut atterrir. « Le relecteur regardera la PR » n'est plus une ligne de défense crédible. Le relecteur fait face à des centaines de PR d'agent chaque semaine ; les agents légitimes éditent eux-mêmes .github/workflows/*.yml (mise à jour d'actions, ajustement de clés de cache), ce qui rend l'activité légitime visuellement indiscernable de l'activité malveillante. Les six contrôles ci-dessous descendent la défense dans la pipeline. À inscrire dans la feuille de route trimestrielle de la plateforme.

Aucun de ces contrôles n'est nouveau isolément. Ce qui est nouveau, c'est qu'ils sont passés à l'ère de l'IA du statut « bonne pratique » à celui de « ne pas le faire = encaisser un incident ». En 100 % hébergé, on ne descend pas à la profondeur requise ; sur un nœud dédié self-hosted, chaque ligne se traduit concrètement en trousseau macOS, jobs launchd, règles pf et étiquettes de runner Actions.

Tous les projets n'ont pas à quitter immédiatement les runners macOS hébergés. Évaluez quatre seuils quantitatifs : (1) la facture mensuelle hébergée dépasse-t-elle un Mac Mini dédié équivalent ? (2) le P95 d'attente dépasse-t-il 10 minutes aux heures de pointe et bloque-t-il les fusions ? (3) la concentration de secrets reste-t-elle élevée (plusieurs workflows partagent le même trousseau et un scope OIDC large) ? (4) la part des PR d'agent a-t-elle franchi 30 % ? Deux « oui » ou plus : inscrivez les runners macOS self-hosted dédiés à la feuille de route du trimestre suivant. L'arbre ci-dessous est conçu pour être copié tel quel.

name: ios-ci
on: [pull_request]
permissions: {}
jobs:
  lint-and-unit:
    runs-on: [self-hosted, macos, agent]
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/lint.sh
      - run: ./scripts/test-unit.sh
  archive-and-notary:
    if: github.event.pull_request.user.type != 'Bot'
    runs-on: [self-hosted, macos, human]
    permissions:
      id-token: write
      contents: read
    environment: prod-signing
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/archive.sh
      - run: ./scripts/notarize.sh

Le squelette ci-dessus illustre trois politiques en une vingtaine de lignes : top-level permissions: {} pour le deny-by-default, ségrégation par étiquette entre lint / unit et archive / notary, et garde if refusant la signature en production pour les PR créées par des bots. Le YAML peut s'écrire sur des runners hébergés, mais ce n'est que sur un nœud dédié qu'il s'aligne réellement avec le trousseau macOS, l'isolation launchd et l'allowlist pf. Combinez avec les conventions de sièges et files de la gouvernance SSH multi-sièges pour faire cohabiter humains, agents et plusieurs développeurs sur un même nœud.

Concernant le dimensionnement : pour des dépôts iOS de taille moyenne avec quelques développeurs humains et un trafic d'agent intermittent, M4 16 Go·256 ou 24 Go·512, baseline mensuelle et spike journalier conviennent. Pour les charges mixtes – matrice de simulateurs, régression nocturne d'agent et OpenClaw Gateway co-résident – visez directement M4 Pro 64 Go·2 To. En contexte international, suivez les règles RTT et même-région dans latences six régions et conditions de location ; si le budget le permet, gardez un second nœud dans une autre région en bascule pour absorber un incident régional.

Condensez les sections précédentes en trois règles à insérer dans le cahier des charges. (1) Les runners d'agent ont leurs propres étiquettes, comptes et trousseaux, jamais partagés avec les développeurs humains. (2) Les scopes OIDC et les PAT sont à durée courte, restreints et rotés, et les jobs de signing en production passent par un environment protégé. (3) Les commits d'agent exigent une identité d'auteur vérifiée et .github/workflows/*.yml est protégé par branche et double relecture. Sans l'une de ces trois règles, la probabilité d'un incident de classe Mini Shai-Hulud ou Megalodon augmente géométriquement.

Comparez les alternatives honnêtement. Rester 100 % sur les runners hébergés : facture et queue tail croissent avec le trafic d'agent, l'isolation des secrets plafonne au niveau workflow, en cas d'attaque type Megalodon il ne reste qu'à attendre l'annonce officielle. Mac mini fermé dans un local : stabilité physique faible, pas de launchd ni de gestion à distance industrielle, un week-end de coupure réseau stoppe la livraison. macOS sur VM cloud générique (matériel non Apple) : viole la licence Apple et dégrade la performance. Pour une pipeline iOS / macOS qui doit cohabiter avec des agents IA en production, la location Mac Mini cloud KVMNODE est en général la meilleure réponse : Apple Silicon dédié, 7×24, six régions, élasticité jour / semaine / mois, et marge pour rassembler files jumelles, bac à sable des secrets et durcissement OIDC dans une même demande de changement. Tarifs sur la page tarifs, procédures dans le centre d'aide, commande via la page de commande.