Mise à l’échelle automatique des runners macOS GitHub Actions : guide de déploiement 2026

Au 21 août 2026, le dépôt officiel du Runner Scale Set Client indique encore un statut Public Preview pour cette brique d’extension de GitHub Actions : consultez l’état publié par le dépôt officiel. Cela suffit pour tirer une conclusion opérationnelle : ne construisez pas une ferme de Mac constamment connectés en ajoutant simplement des machines. Pour une équipe iOS, combinez un pool chaud minimal avec des nœuds créés selon la file d’attente, puis utilisez un runner JIT ou ephemeral, un nettoyage systématique et des journaux externes.

Symptôme : la file de publication augmente, mais de nouveaux Mac ne prennent pas les tâches assez vite.
Solution la plus rapide : conserver une capacité de base immédiatement disponible et déclencher une capacité élastique lorsque la durée d’attente, la préparation de l’environnement ou le SLA de publication franchit vos seuils internes.

Cet article s’adresse aux responsables de l’efficacité de développement qui doivent réduire les files de compilation iOS, aux responsables IT et sécurité qui gouvernent les permissions et les secrets GitHub Actions, ainsi qu’aux directeurs techniques qui arbitrent achat de Mac, capacité louée ou architecture hybride.

Dernière mise à jour : 21 août 2026. Les informations relatives au statut du Runner Scale Set Client, aux API, à la sécurité et aux recommandations de GitHub ont été vérifiées dans les documentations officielles citées dans cet article.

Mise à l’échelle automatique des runners macOS GitHub Actions : le bon périmètre

La file d’attente avant le nombre de développeurs

Le nombre de personnes dans l’équipe ne constitue pas un déclencheur fiable. Une petite équipe peut produire une file importante lors d’une soumission TestFlight, d’une campagne de tests parallèles ou d’un projet audio nécessitant plusieurs variantes d’export. À l’inverse, une équipe plus nombreuse peut conserver une faible pression si les compilations sont espacées.

Mesurez plutôt quatre signaux :

• la durée pendant laquelle un travail reste en attente avant d’être attribué ;
• la nature des tâches au pic : compilation, tests, archivage, signature ou publication ;
• le délai nécessaire pour rendre un Mac prêt à recevoir un travail ;
• le délai maximal acceptable entre un commit validé et un artefact publiable.

Ces mesures doivent être séparées par type de tâche. Une compilation Xcode, un test d’interface, un rendu vidéo et une exportation de projet de design n’ont ni la même consommation CPU, ni la même durée, ni les mêmes exigences de fichiers temporaires.

Le rôle exact du Runner Scale Set Client

Le Runner Scale Set Client est un composant de contrôle et d’intégration. Il peut participer à une architecture de runners macOS qui réagit aux besoins de GitHub Actions, mais il ne fournit pas à votre place les Mac physiques, leur réseau, leur système d’exploitation, leur initialisation Xcode ou leur destruction.

La création et la récupération d’un hôte restent donc du ressort de votre automatisation existante ou d’une interface de ressources Mac. Cette séparation est essentielle pour éviter une erreur d’architecture : installer le client en pensant qu’il va acheter, démarrer, configurer et supprimer vos nœuds.

Les principes GitHub relatifs aux runners auto-hébergés doivent être lus avec cette limite en tête. Le client orchestre une partie du cycle du runner ; il ne remplace pas votre gestionnaire de parc ou votre fournisseur de capacité.

Les trois rôles de capacité

Votre architecture peut distinguer trois catégories, chacune avec une responsabilité claire :

1. Le pool chaud : quelques nœuds déjà prêts pour absorber les travaux ordinaires et les premiers travaux d’un pic.
2. Les nœuds élastiques : des Mac demandés lorsque la file, le délai de livraison ou le SLA l’exige.
3. Les nœuds fixes de signature : des machines isolées, conservées sous contrôle renforcé lorsque la publication exige des certificats, des profils ou des accès sensibles.

Le pool chaud ne doit pas devenir un espace partagé sans fin. Les nœuds élastiques ne doivent pas recevoir des secrets de production par défaut. Les nœuds de signature ne doivent pas être utilisés comme capacité générale simplement parce qu’ils sont disponibles.

Première heure : routage et frontières de confiance

Groupes, étiquettes et portée des dépôts

Commencez par créer des groupes de runners correspondant à des périmètres de confiance, plutôt qu’à des équipes dont les frontières changeront souvent. Un groupe peut être limité à certains dépôts, tandis que les étiquettes décrivent la capacité technique : version Xcode, architecture Apple Silicon, famille de tests ou niveau de sensibilité.

Une combinaison de groupe et d’étiquette est plus précise qu’une étiquette globale. Par exemple, une tâche de test non signée peut cibler un pool général, alors qu’une tâche qui manipule un certificat de distribution doit être routée vers un groupe restreint et une machine dédiée.

La gestion officielle des accès aux runner groups doit servir de base à votre matrice d’autorisation. Documentez, pour chaque groupe, les dépôts autorisés, les propriétaires responsables et la procédure de retrait.

Jetons et identité d’enregistrement

Évitez de placer un jeton d’enregistrement permanent dans une image Mac ou dans un dépôt. Préférez une identité limitée, délivrée au moment où le nœud en a besoin, puis révoquée lorsque le runner quitte le service. Selon le flux retenu, une GitHub App à permissions restreintes ou un jeton conforme aux exigences officielles peut fournir cette identité.

L’important n’est pas seulement le type de jeton, mais la responsabilité associée :

• qui peut demander une identité de runner ;
• qui peut l’utiliser sur un hôte ;
• qui enregistre les créations et révocations ;
• qui déclenche la rotation ;
• qui enquête lorsqu’un runner reste enregistré après la fin d’une tâche.

Les API REST dédiées aux runners auto-hébergés permettent d’intégrer ces opérations à votre automatisation ; vérifiez les endpoints et les permissions dans la documentation REST officielle de GitHub Actions.

Dépôts publics et demandes non fiables

Un runner macOS qui possède une clé de signature, un jeton d’App Store Connect ou un accès réseau interne ne doit pas exécuter directement du code non fiable. Une demande de fusion provenant d’un dépôt public, ou contenant des modifications de pipeline non approuvées, peut tenter d’exfiltrer des variables, d’inspecter le trousseau ou de conserver des fichiers dans le répertoire de travail.

Séparez donc les flux :

• travaux publics ou exploratoires sur nœuds sans secrets ;
• tests internes sur un groupe réservé ;
• compilation signée sur des nœuds isolés, avec approbations adaptées.

Les recommandations de GitHub sur l’usage sécurisé des runners auto-hébergés précisent pourquoi ce type de runner ne doit pas être traité comme une machine neutre lorsqu’il exécute des workflows contrôlés par des contributeurs.

Jour du raccordement : états et idempotence

La machine à états du déploiement

Ne concevez pas l’extension comme un simple script « démarrer un Mac, installer un runner ». Utilisez une machine à états observable :

1. une demande apparaît dans la file GitHub Actions ;
2. le contrôleur détermine le groupe et les étiquettes requis ;
3. le gestionnaire demande ou réserve un Mac ;
4. l’hôte démarre et atteint la version de référence ;
5. le runner reçoit une configuration JIT ou s’enregistre comme ephemeral ;
6. le runner prend le travail ;
7. le travail se termine, puis l’hôte est nettoyé, retiré ou détruit.

Chaque transition doit avoir un identifiant corrélable : identifiant du travail, identifiant de demande, hôte, runner et événement de fin. Sans cette corrélation, une machine peut sembler « prête » alors que GitHub n’a jamais reçu son enregistrement, ou rester facturée après l’annulation du travail.

Webhook, API et client d’échelle

Le workflow_job Webhook est utile pour recevoir les événements de cycle de vie et déclencher votre logique de capacité. L’API REST convient aux opérations administratives et à la récupération de l’état. Le Runner Scale Set Client s’insère dans le contrôle de l’ensemble, mais la livraison du Mac reste une étape externe.

Cette division impose des comportements idempotents :

• une notification répétée ne doit pas créer deux hôtes pour le même besoin ;
• un démarrage échoué doit passer en état récupérable, avec une limite interne de tentatives ;
• un enregistrement expiré doit être recréé sans laisser l’ancien runner actif ;
• un travail annulé avant la livraison doit libérer la réservation ;
• un runner qui ne répond plus doit être retiré du routage avant sa récupération.

L’API ne doit pas être votre unique journal. Conservez les événements du contrôleur, les changements d’état du Mac et les logs du runner dans un stockage extérieur, afin de pouvoir enquêter après l’arrêt d’un nœud.

Le minimum de configuration à comprendre

Un squelette de workflow doit exprimer le routage, sans prétendre constituer une configuration de production complète :

jobs:
  build:
    runs-on:
      - self-hosted
      - macos
      - Apple-Silicon
    steps:
      - uses: actions/checkout@v4
      - name: Vérifier l’environnement
        run: xcodebuild -version
      - name: Construire et tester
        run: xcodebuild test -scheme App

Les versions d’actions, de Xcode et du runner doivent être fixées selon votre propre matrice de compatibilité. Les exigences système d’Xcode évoluent ; vérifiez la page Apple consacrée aux versions de Xcode et à leurs systèmes requis avant de publier une image de référence.

Première pipeline : boucle éphémère et nettoyage

JIT ou runner éphémère

Pour une tâche qui doit disparaître après son exécution, privilégiez une configuration JIT ou un runner ephemeral. GitHub recommande l’usage de runners éphémères pour les environnements auto-hébergés mis à l’échelle automatiquement, car un hôte ne doit pas conserver l’état d’un travail précédent.

Un runner permanent peut rester pertinent pour certains nœuds de signature fortement contrôlés, mais il augmente la surface d’audit : espace de travail résiduel, caches non maîtrisés, secrets mémorisés et dérive de version. Dans votre conception, « disponible » ne doit donc pas signifier « réutilisable par n’importe quel dépôt ».

Baseline macOS et cache

Avant d’autoriser une vraie compilation, comparez l’hôte livré avec une baseline vérifiable :

• version macOS et version Xcode ;
• SDK installés et outils de ligne de commande ;
• architecture Apple Silicon attendue ;
• dépendances Swift Package Manager, CocoaPods ou autres ;
• état du trousseau et présence de certificats ;
• accès réseau autorisés ;
• espace de travail vide.

Les caches peuvent être conservés lorsqu’ils ne contiennent ni secret ni résultat dépendant d’un dépôt non fiable. Les certificats, profils de provisioning, jetons et fichiers de signature doivent suivre une politique inverse : durée courte, emplacement contrôlé et destruction explicite.

Les usages audio, vidéo et design exigent une attention supplémentaire. Un projet peut produire des fichiers lourds, des bibliothèques locales ou des caches de rendu que le nettoyage standard ne supprime pas. Définissez les répertoires temporaires à effacer et vérifiez le nettoyage avec un fichier sentinelle, plutôt que de supposer que la fermeture du processus suffit.

Validation de la première exécution

Utilisez un dépôt de test contrôlé, sans signature de production. La première exécution doit prouver toute la boucle :

• l’étiquette Apple Silicon est correctement routée ;
• le runner JIT ou ephemeral ne reçoit qu’un travail ;
• le travail peut compiler et produire un artefact ;
• l’enregistrement disparaît après la fin ;
• l’espace de travail est vide ;
• les logs restent accessibles après la disparition du Mac.

Ne validez pas seulement la ligne « runner en ligne ». Une machine peut être visible tout en étant incapable de recevoir le bon travail, de résoudre les dépendances ou de transmettre ses journaux.

Première semaine : capacité, coût variable et reprise

Table de décision des capacités

Le nombre de Mac du pool chaud ne peut pas être déduit d’une règle universelle. Il doit provenir de vos historiques de file, du temps de livraison et du SLA. Utilisez cette grille pour choisir la trajectoire avant de fixer un nombre :

Comparez ensuite quatre postes de coût : capacité inactive, attente de livraison, temps d’exploitation et retard de publication. Une location de Mac à la demande peut déplacer une partie de ces coûts vers une dépense variable, mais elle ne supprime ni la gouvernance des secrets ni la nécessité de mesurer le délai réel d’accès.

Seuils et refroidissement

Définissez un seuil d’expansion à partir d’une durée d’attente acceptable, puis ajoutez un délai de refroidissement pour éviter les oscillations. Si le contrôleur lance et détruit des hôtes à chaque variation mineure, vous paierez des livraisons inutiles et compliquerez les investigations.

Le plafond de capacité doit être explicite. Il protège le budget, le réseau, les licences et les systèmes en aval. Lorsque le plafond est atteint, le pipeline doit produire un état visible — attente, échec contrôlé ou nouvelle tentative — plutôt que de continuer à demander des machines sans limite.

Pour calculer le pool chaud, utilisez vos propres mesures : nombre de tâches simultanées au percentile de charge choisi, durée médiane de compilation, temps de préparation et marge de publication. Ne remplacez pas ces données par un nombre recommandé trouvé dans un exemple général.

Exercices de reprise

Pendant la première semaine, simulez au moins les scénarios qui rompent habituellement la chaîne :

• interruption du plan de contrôle ;
• Mac livré mais inaccessible ;
• mise à jour du runner échouée ;
• étiquette incompatible avec le workflow ;
• annulation pendant le démarrage ;
• fin de tâche sans nettoyage ;
• suppression du runner réussie, mais hôte toujours actif.

Pour chaque incident, vérifiez quatre résultats : le travail est-il routé ailleurs, l’hôte est-il arrêté ou isolé, le secret est-il révoqué et les journaux permettent-ils d’expliquer la séquence ? La documentation GitHub de surveillance et de dépannage fournit les points de contrôle utiles côté runner ; vos journaux d’infrastructure doivent compléter cette vue.

Admission en production et déploiement progressif

Checklist de préproduction

• [ ] Les groupes de runners limitent les dépôts autorisés.
• [ ] Les étiquettes distinguent Xcode, architecture et niveau de confiance.
• [ ] Le Runner Scale Set Client est traité comme composant de contrôle, non comme fournisseur de Mac.
• [ ] Le flux de livraison du Mac possède un identifiant idempotent.
• [ ] Le runner reçoit une configuration JIT ou ephemeral lorsque la tâche le permet.
• [ ] Les travaux provenant de sources non fiables n’atteignent aucun nœud contenant un secret de production.
• [ ] Les certificats, profils et jetons ont une durée et une procédure de révocation documentées.
• [ ] Le nettoyage supprime l’espace de travail, les caches sensibles et les fichiers temporaires.
• [ ] Les logs du runner, du contrôleur et de l’hôte sont conservés hors du Mac.
• [ ] Le plafond de capacité et le refroidissement sont testés avec une file artificielle.
• [ ] Les pannes de livraison, d’enregistrement, de réseau et de mise à jour ont un chemin de récupération.
• [ ] La version de Xcode est validée contre les exigences Apple avant chaque nouvelle image.
• [ ] Aucun travail de signature réelle n’est activé avant la validation des contrôles précédents.

Mise en production par paliers

Commencez par les tests sans signature et les dépôts les mieux contrôlés. Ensuite, autorisez les compilations fiables, puis décidez séparément si les publications doivent rester sur des nœuds fixes de signature. Cette progression limite le rayon d’impact d’une erreur de routage.

À chaque palier, conservez les preuves : durée d’attente, délai de livraison du Mac, état du runner, résultat du nettoyage, journaux disponibles et coût de capacité. Ne passez pas au palier suivant parce que le premier pipeline est vert ; passez-y lorsque la récupération d’un échec est également démontrée.

Après cette validation, votre choix peut rester hybride. Une capacité fixe convient aux tâches sensibles et prévisibles ; une capacité distante louée peut absorber les pics sans immobiliser un parc permanent ; un parc acheté garde son intérêt lorsque la charge est stable, que les interfaces physiques sont indispensables ou que votre politique impose une possession matérielle.

La décision d’infrastructure après le pilote

Une fois le pool chaud et les pics mesurés, préparez un tableau interne indiquant le nombre de nœuds nécessaires, le délai maximal de livraison, la durée de location acceptable et les exigences de région ou de réseau. Cette grille vous permettra d’évaluer objectivement une capacité Mac distante, au lieu de comparer des promesses générales.

Votre solution actuelle n’est pas forcément mauvaise, mais un parc de Mac achetés et constamment allumés présente souvent trois défauts réels : une capacité inactive entre les pics, une charge d’entretien et de remplacement portée par votre équipe, et une montée en charge lente lorsque plusieurs publications se chevauchent. Si votre architecture exige en plus une séparation fine des environnements, chaque nœud supplémentaire ajoute une tâche d’inventaire, de correctif et d’audit.

Dans ce cas, KVMFLUX peut servir de capacité Mac élastique à intégrer à votre processus, sans vous obliger à remplacer immédiatement les nœuds fixes. Vous pouvez commencer par confronter votre tableau de volume, de délai de livraison et de durée de location aux cas d’usage Mac distants de KVMFLUX, puis examiner les options et cycles de location disponibles. La bonne décision est celle qui laisse les tâches sensibles sur leur périmètre contrôlé tout en évitant d’acheter de la capacité qui reste inactive hors des périodes de publication.