Comment configurer les groupes de runners macOS de GitHub Actions ? Guide entreprise 2026

Le 25 juin 2026, GitHub a annoncé la prise en charge des runners macOS dans les Runner Groups pour les offres Team et Enterprise, tout en précisant que la configuration réseau n’est pas disponible pour ces runners (annonce officielle). La décision opérationnelle est donc nette : définissez d’abord les groupes selon vos frontières de confiance, autorisez les dépôts, puis configurez le routage des workflows. Ne désactivez les étiquettes standard qu’après validation des pipelines représentatifs. Si votre besoin réel concerne l’isolation réseau, ne confondez pas cette exigence avec un Runner Group.

Qui devrait lire ce guide ?
Les administrateurs GitHub qui gèrent les groupes, les dépôts autorisés et les règles d’utilisation des runners standard.
Les ingénieurs de plateforme CI et les responsables techniques ou sécurité qui doivent vérifier le routage macOS et sa cohérence avec les frontières de confiance.

Repère temporel : la fonctionnalité et ses limites ont été vérifiées le 4 novembre 2026 dans l’annonce et la documentation officielle de GitHub, notamment les pages sur le contrôle d’accès des runners, la syntaxe des workflows et la gestion des runners. Les menus et options visibles dans votre compte peuvent évoluer : prenez l’interface actuelle comme référence avant de déployer une règle.

Avant de créer un groupe, confirmez le périmètre réellement pris en charge

Commencez par déterminer ce que votre équipe cherche à contrôler. Un Runner Group peut structurer l’accès aux ressources d’exécution et leur utilisation ; il ne remplace ni une politique réseau, ni un mécanisme de gestion des secrets, ni une séparation complète entre environnements.

L’annonce de GitHub indique que la fonction s’applique aux offres Team et Enterprise. Vérifiez néanmoins la capacité dans le compte concerné et dans la documentation à jour : le plan souscrit, le niveau d’administration et les options disponibles dans l’organisation peuvent conditionner la configuration réellement possible. N’inférez pas l’accès à une option à partir d’un autre compte ou d’une capture d’écran ancienne.

Distinguez également les GitHub-hosted macOS runners des runners autohébergés. Les étapes de gestion ne sont pas interchangeables : ce guide concerne l’usage des runners macOS hébergés par GitHub dans des groupes, et non la création d’une machine administrée par votre équipe. Si votre question porte plutôt sur le choix entre runners hébergés et autohébergés, consultez aussi notre guide sur la confidentialité des données pour cadrer les enjeux de contrôle et de traitement des informations.

Le terme « groupe » peut donner l’impression d’une frontière de sécurité plus large qu’il ne l’est. Pour une exigence de réseau, demandez-vous quelles routes, résolutions DNS, connexions sortantes ou dépendances internes doivent être accessibles. L’annonce officielle établit que la configuration réseau des runners macOS concernés n’est pas prise en charge ; un groupe ne peut donc pas être présenté comme un substitut à ces contrôles.

À retenir : séparez l’autorisation d’utiliser un runner du contrôle des ressources réseau et des secrets. Ces mécanismes répondent à des risques différents et doivent être vérifiés indépendamment.

Concevez les groupes autour des dépôts et de la confiance

Avant d’ouvrir les paramètres, rédigez une règle d’usage que les équipes pourront comprendre et auditer. Un groupe peut correspondre à une responsabilité clairement définie : par exemple, les constructions internes d’une équipe produit, ou les travaux de publication qui exigent des permissions spécifiques. Évitez de créer un groupe uniquement parce que plusieurs workflows utilisent macOS ; la proximité technique ne signifie pas que leur niveau de confiance est identique.

Pour chaque groupe envisagé, consignez son objectif, son responsable, les dépôts concernés, les types de workflows admis et la méthode de validation. Ce registre évite qu’un groupe reste accessible par défaut alors que son usage a changé, ou qu’un dépôt soit ajouté sans propriétaire clairement identifié.

Les dépôts publics, les contributions externes et les workflows de publication méritent une analyse distincte. Un travail déclenché par du code non approuvé peut présenter un risque particulier s’il dispose de secrets ou de permissions plus larges que nécessaire. Ne supposez pas qu’un dépôt est sûr parce qu’il appartient à la même organisation, ni qu’un groupe fournit une isolation complète entre les travaux qui y sont exécutés. Examinez les déclencheurs, les permissions du jeton et les secrets transmis dans le workflow.

Cette analyse complète utilement votre documentation d’aide à la configuration : définissez la responsabilité de l’équipe, mais gardez une trace distincte des autorisations effectives dans GitHub. La documentation interne explique l’intention ; le résultat de l’interface et les essais d’accès démontrent ce qui est réellement appliqué.

Créez le groupe et vérifiez les accès effectifs

Dans les paramètres de l’organisation ou de l’entreprise, repérez la gestion des runners et des groupes, puis créez le groupe selon les options disponibles dans votre compte. Ne reproduisez pas mécaniquement un parcours d’interface trouvé dans une documentation ancienne : l’annonce et la page de contrôle d’accès des runners sont les références à confronter aux réglages visibles.

Configurez une politique d’accès cohérente avec votre registre. Si l’interface permet de limiter l’accès à des dépôts sélectionnés, comparez la liste configurée à celle que votre responsable de service a approuvée. Si les choix proposés ne permettent pas de représenter précisément votre politique, arrêtez le déploiement plutôt que d’accorder une portée plus large par commodité.

Examinez aussi les groupes préexistants et les chemins d’exécution qui demeurent actifs. Créer un nouveau groupe ne signifie pas, à lui seul, que toutes les exécutions ont été transférées vers cette nouvelle règle. Inventoriez les groupes, les runners et les workflows qui pourraient continuer à utiliser une configuration antérieure. La documentation de gestion des runners peut aider à vérifier les concepts de gestion, mais les paramètres visibles pour votre compte restent déterminants.

Procédez ensuite à une vérification à deux résultats : un dépôt que vous avez autorisé doit pouvoir sélectionner le groupe ; un dépôt qui n’y est pas autorisé ne doit pas pouvoir l’utiliser. Conservez les résultats d’exécution, les paramètres observés et la personne qui a validé le test. Il s’agit d’un constat propre à votre organisation, pas d’une garantie générale sur tous les comptes.

Routez les workflows et faites correspondre le groupe aux étiquettes

Une fois les accès configurés, modifiez le workflow afin qu’il demande le groupe voulu. La syntaxe runs-on permet d’exprimer les caractéristiques de l’environnement recherché ; la référence officielle décrit les formes acceptées, notamment les cas où le groupe et les étiquettes sont utilisés ensemble (syntaxe des workflows GitHub Actions).

Exemple de structure à adapter aux noms et aux étiquettes effectivement disponibles dans votre configuration :

jobs:
  build:
    runs-on:
      group: macos-builds
      labels: macos-<label-configurée>
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -version

Ne copiez pas une valeur illustrative sans la vérifier dans votre compte. Le nom du groupe doit correspondre à celui configuré, le dépôt doit être autorisé à l’utiliser et l’étiquette doit être compatible avec le runner attendu. Si l’une de ces conditions échoue, le workflow peut ne pas suivre la route prévue. Pour une migration, changez d’abord un workflow représentatif plutôt que de modifier en bloc tous les fichiers de l’organisation.

La différence entre une étiquette et un groupe est opérationnelle : une étiquette décrit ou sélectionne un environnement, tandis que le groupe intervient dans la gestion de l’accès aux runners. Une étiquette seule ne prouve donc pas que le dépôt est soumis à la politique d’autorisation que vous avez conçue. Confirmez le comportement dans une exécution réelle et consignez le résultat.

Pour la première validation, choisissez une compilation qui n’effectue ni publication ni opération irréversible. Vérifiez la route, la version d’outil nécessaire au projet et la disponibilité des dépendances, puis répétez l’essai dans un contexte de dépôt non autorisé. Si votre pipeline produit aussi des médias, des aperçus de design ou des rendus audio/vidéo sur macOS, vérifiez ces tâches comme des charges distinctes : leur dépendance à des outils ou à des ressources spécifiques ne doit pas être déduite d’un simple test de compilation.

Migrez les étiquettes standard après validation

La désactivation ou la limitation des étiquettes standard est une mesure de migration, pas une étape initiale. Avant d’y toucher, recherchez les références à ces étiquettes dans les dépôts, les workflows planifiés, les branches de maintenance et les tâches déclenchées par des événements moins fréquents. Une recherche limitée aux pipelines principaux peut laisser de côté un travail qui ne s’exécute qu’à l’occasion d’une publication ou d’une tâche planifiée.

La documentation GitHub sur la désactivation ou la limitation de GitHub Actions dans une organisation traite des réglages organisationnels concernés. Vérifiez que l’option envisagée correspond bien à votre objectif : limiter l’usage d’un runner standard n’est pas la même chose que désactiver l’ensemble de GitHub Actions.

Utilisez les branches de décision suivantes avant de changer une politique :

• Si tous les workflows concernés ont été identifiés, transférés et exécutés avec succès dans le groupe cible, alors planifiez la modification des étiquettes standard avec un responsable et une procédure de retour arrière.
• Si des workflows n’ont pas encore été examinés ou si leur propriétaire est inconnu, alors reportez la restriction et attribuez d’abord la responsabilité de ces dépôts.
• Si l’objectif est de plafonner l’utilisation ou de gérer la concurrence, alors vérifiez les réglages de groupe disponibles dans votre compte et construisez la politique à partir du besoin réel de l’équipe ; ne présumez pas d’une capacité ou d’un quota non confirmé.
• Si le besoin porte sur la segmentation réseau, alors ne poursuivez pas en considérant le groupe comme une solution : l’annonce officielle indique que les runners macOS concernés ne prennent pas en charge la configuration réseau.
• Si une modification provoque un refus ou une attente inattendue, alors appliquez la procédure de retour arrière documentée et conservez l’exécution en échec comme élément de diagnostic.

Le changement doit être traçable : notez la règle modifiée, les dépôts touchés, le responsable, les résultats d’essai et la condition de retour arrière. Cette discipline aide à distinguer une erreur de routage d’un refus d’accès ou d’une limite liée à l’environnement.

FAQ sur les groupes de runners macOS

Comment limiter les dépôts autorisés à utiliser un groupe de runners macOS ?

Ouvrez la configuration du groupe dans les paramètres de l’organisation ou de l’entreprise, puis vérifiez la politique d’accès aux dépôts proposée pour votre compte. Si l’interface permet une sélection explicite, autorisez uniquement les dépôts qui ont un besoin documenté. Validez ensuite le résultat avec un dépôt autorisé et un dépôt qui ne l’est pas ; les possibilités exactes dépendent de la configuration actuelle de GitHub.

Comment forcer un workflow macOS à utiliser un groupe précis ?

Dans le workflow, indiquez le groupe dans la configuration runs-on, avec l’étiquette correspondant au runner attendu lorsque la syntaxe et le type de runner l’exigent. Le nom du groupe doit correspondre à celui configuré et le dépôt doit être autorisé à l’utiliser. Testez la route avec un travail de construction peu risqué, puis contrôlez le runner réellement affecté dans l’exécution.

Que vérifier avant de désactiver les étiquettes standard des runners hébergés ?

Inventoriez les workflows et dépôts qui s’appuient encore sur les étiquettes standard, y compris les tâches planifiées et les branches moins utilisées. Migrez-les, confirmez qu’ils arrivent dans le groupe prévu et préparez une procédure de retour arrière. Ne modifiez la politique qu’après cette validation ; sinon, des travaux peuvent être refusés ou rester en attente.

Un groupe de runners macOS fournit-il une isolation réseau ?

Non. Les groupes servent à gérer l’accès et l’utilisation des runners, mais l’annonce officielle précise que la configuration réseau n’est pas prise en charge pour les runners macOS concernés. Si votre exigence porte sur des routes réseau, des règles de sortie ou une segmentation, traitez-la comme un besoin d’infrastructure distinct et vérifiez qu’un autre environnement d’exécution peut le satisfaire.

Pour une équipe dont les besoins se limitent aux constructions et tests couverts par les runners actuels, GitHub Actions peut rester la solution la plus simple à administrer. En revanche, si l’audit révèle un environnement d’exécution insuffisant, des contraintes de réseau non satisfaites ou une dépendance trop forte aux étiquettes standard, comparez les options sans attribuer au Runner Group des capacités qu’il n’offre pas. Une machine Mac achetée en propre implique immobilisation du matériel, préparation et maintenance locales ; un environnement distant reste dépendant de ses conditions d’accès et ne remplace pas une exigence d’interface physique. Pour un besoin temporaire de tests ou une capacité Mac à évaluer avant un achat, vous pouvez consulter la page Mac de VPSMerge et confronter les informations réellement publiées à vos exigences internes. N’adoptez cette voie qu’après vérification de la configuration, de la disponibilité et du mode d’accès correspondant à votre cas ; aucune intégration avec GitHub Actions ne doit être présumée sans validation.

Questions fréquentes