GitHub Actions passe à macOS 26 : liste de migration (2026)

Symptôme → solution la plus rapide : le fichier YAML n’a pas changé, mais le build échoue après une nouvelle image système ; remplacez d’abord macos-latest par un libellé macOS explicite dans une tâche parallèle, puis comparez le système, l’architecture, Xcode et les dépendances avant de toucher à la publication.

Cette méthode convient si vous utilisez déjà GitHub Actions pour iOS, macOS ou un projet multiplateforme. Elle est particulièrement importante si votre pipeline dépend de CocoaPods, SwiftPM, Node.js, Ruby, de binaires natifs, d’une identité de signature persistante ou d’un cache que vous ne pouvez pas recréer à chaque exécution.

Dernière mise à jour : 23 août 2026. Les informations ont été vérifiées à partir de l’annonce GitHub, de la documentation des Runner et des dépôts officiels d’images ; la correspondance effective de macos-latest doit être contrôlée le jour de votre déploiement.

Ne déduisez pas l’environnement du seul fichier YAML

La première erreur consiste à lire macos-latest comme une version permanente. Ce libellé désigne une image maintenue par GitHub et sa correspondance peut évoluer ; il ne constitue donc pas une preuve de la version réellement utilisée par votre tâche. GitHub a annoncé la disponibilité générale de macOS 26 pour les Runner hébergés le 26 février 2026, tandis que la période de migration planifiée de macos-latest s’étendait du 15 juin au 15 juillet 2026, selon l’annonce officielle de GitHub sur macOS 26.

Avant toute modification, ajoutez une tâche de diagnostic non bloquante. Elle doit enregistrer le système, le noyau, l’architecture du processeur, la version et le chemin de Xcode, les outils en ligne de commande, ainsi que les versions de Node.js, Ruby, Python, Homebrew, Clang et OpenSSL.

name: Inspecter le Runner macOS

on:
  workflow_dispatch:

jobs:
  diagnostic:
    runs-on: macos-latest
    steps:
      - name: Identifier l’environnement
        run: |
          sw_vers
          uname -a
          uname -m
          xcode-select -p
          xcodebuild -version
          node --version || true
          ruby --version || true
          python3 --version || true
          brew --version || true
          clang --version || true
          openssl version || true

Conservez la sortie complète avec le numéro de l’exécution. La documentation officielle des libellés de Runner rappelle la distinction entre les libellés de système, d’architecture et de génération de Runner. Pour connaître les logiciels effectivement préinstallés, utilisez le dépôt officiel actions/runner-images plutôt qu’un ancien article ou une hypothèse conservée dans votre dépôt.

Les workflows peuvent être classés ainsi :

• Tests sans état : tests unitaires, lintage et vérifications qui reconstruisent entièrement leurs dépendances ; ils peuvent migrer après validation parallèle.
• Build Apple : compilation iOS, macOS, audio ou vidéo, génération d’archives et tests sur simulateur ; ils doivent d’abord valider Xcode, le SDK et l’architecture.
• Publication signée : archivage, export IPA, notarisation ou diffusion ; ne modifiez pas le Job de production avant d’avoir prouvé la reproductibilité et le retour arrière.

Les premiers échecs viennent souvent de Xcode et du SDK

Un changement d’image peut sélectionner une autre version de Xcode ou de SDK sans que votre projet ait changé. Le symptôme peut être explicite, comme une cible de simulateur absente, ou indirect : une API devient indisponible, une phase de script utilise un outil différent, ou une archive échoue uniquement pendant l’export.

Commencez par comparer quatre éléments entre l’ancien Runner et le Runner macOS 26 :

1. le résultat de xcode-select -p ;
2. la sortie de xcodebuild -version ;
3. le SDK choisi par xcrun --sdk iphoneos --show-sdk-path ;
4. la destination exacte passée à xcodebuild, notamment le type de plateforme et l’architecture.

La liste des exigences système de Xcode publiée par Apple doit servir à vérifier la compatibilité entre votre version de Xcode et macOS 26. Elle ne remplace toutefois pas l’inspection du Runner : une version compatible avec le système peut tout de même modifier le comportement de votre projet, de vos scripts ou de vos dépendances.

Stabiliser l’outil avant de stabiliser le résultat

Si votre projet ne sélectionne pas explicitement Xcode, le comportement dépend de l’image disponible et de ses réglages par défaut. Dans un premier temps, choisissez l’outil avec une action ou une commande explicitement documentée, puis affichez la version retenue dans les journaux.

N’associez pas dans le même changement la migration du système, l’actualisation de Xcode et la réécriture de la chaîne de signature. Vous ne sauriez plus déterminer quelle modification a provoqué l’échec. Créez plutôt une matrice de validation, par exemple :

• image macOS actuellement utilisée + Xcode actuellement validé ;
• image macOS 26 + même version de Xcode, si elle est compatible ;
• image macOS 26 + version de Xcode souhaitée ;
• ancienne image conservée pour le retour arrière.

Point de contrôle : une compilation réussie ne suffit pas. Le passage est acceptable uniquement si les tests, l’archivage, l’export et la vérification de signature produisent les mêmes résultats attendus dans votre contexte.

Les informations sur Xcode 27 doivent rester séparées de la chaîne stable. Si une version ou une fonction est encore en phase de test, traitez-la comme une piste expérimentale et non comme la solution automatique au passage vers macOS 26.

Apple Silicon change la nature des dépendances

Le mot « macOS » ne décrit pas à lui seul l’environnement d’exécution. Un paquet précompilé, une extension native ou un outil téléchargé peut fonctionner sur Intel et échouer sur Apple Silicon, ou inversement. La documentation GitHub consacrée aux Runner autogérés décrit notamment les architectures prises en charge et les libellés à utiliser ; vérifiez toujours le libellé réellement demandé par votre workflow.

Examinez les dépendances selon quatre familles :

• Binaires précompilés : contrôlez qu’une version arm64, x86_64 ou universelle est disponible pour chaque outil téléchargé.
• Extensions natives : inspectez les modules compilés pour Ruby, Node.js, Python ou les bibliothèques Swift et Objective-C.
• Scripts sensibles à l’architecture : recherchez les tests qui déduisent l’architecture à partir de uname -m, d’un chemin de fichier ou d’une variable d’environnement.
• Produits croisés : vérifiez qu’un binaire produit pour Apple Silicon n’est pas ensuite exécuté sur un environnement Intel, et que l’inverse n’est pas supposé implicitement.

Pour chaque fichier binaire critique, ajoutez une vérification telle que file chemin/vers/binaire ou, sur un binaire Mach-O, lipo -info chemin/vers/binaire. L’architecture annoncée dans les logs doit être rapprochée de l’architecture d’exécution, pas seulement de l’architecture de compilation.

Un test qui compile une extension ne prouve pas qu’elle fonctionne sur toutes les cibles. Pour démontrer la compatibilité, exécutez réellement les tests sur chaque architecture que vous promettez de prendre en charge. Si vous n’avez qu’un Runner arm64, vous ne pouvez pas conclure que le comportement Intel est validé.

Les versions implicites rendent les scripts difficiles à diagnostiquer

Après la migration, un échec dans une étape Ruby ou JavaScript peut ressembler à un problème macOS alors qu’il vient d’une version de langage, d’un chemin différent ou d’un paquet installé globalement. La même confusion apparaît avec Homebrew, Clang et OpenSSL : le nom de la commande reste identique, mais son chemin et ses options peuvent changer.

Avant de corriger le script, imprimez systématiquement :

printf '%s\n' "PATH=$PATH"
command -v node ruby python3 brew clang openssl || true
node --version || true
ruby --version || true
python3 --version || true
brew --prefix || true
clang --version || true
openssl version -a || true

Vous devez ensuite répartir la correction entre trois choix :

• Verrouiller la version lorsque la reproductibilité est prioritaire et que la dépendance est encore maintenue ;
• Mettre à jour le paquet lorsque l’ancien comportement n’est plus compatible avec l’outil fourni par l’image ;
• Réparer le script lorsque celui-ci dépend d’un chemin, d’une option ou d’un format de sortie non garanti.

Les gestionnaires de paquets méritent une attention distincte. Pour SwiftPM, conservez les fichiers de résolution et observez les changements de compilation. Pour CocoaPods, vérifiez la version de Ruby, les extensions natives et le contenu du cache. Pour Node.js, contrôlez le gestionnaire utilisé, le fichier de verrouillage et les modules natifs. Pour Homebrew, ne supposez pas qu’un paquet déjà présent sera identique dans une image fraîche.

Le cache ajoute une deuxième variable. La documentation GitHub sur la mise en cache des dépendances recommande de construire les clés à partir des fichiers de verrouillage et des paramètres pertinents. Ajoutez aussi l’image, l’architecture et, lorsque cela a un effet, la version de Xcode à la clé. Un cache réutilisé par erreur peut masquer un défaut de migration ; faites donc au moins un essai à froid.

Expérience de diagnostic : si l’échec disparaît après suppression du cache, ne classez pas le problème comme résolu. Comparez l’exécution froide et l’exécution chaude, puis invalidez volontairement la clé afin de vérifier que le projet peut être reconstruit sans artefact hérité.

La signature et les simulateurs exigent une validation séparée

Une archive réussie n’est pas encore une livraison utilisable. Vérifiez l’identité de signature, le profil de provisionnement, les entitlements, le trousseau utilisé en mode non interactif et la validation de l’archive. Les erreurs de permission peuvent aussi provenir d’un secret absent ou d’un trousseau créé dans un autre emplacement, sans relation directe avec macOS 26.

Votre séquence de contrôle devrait être la suivante :

1. afficher la destination et l’architecture avant le build ;
2. créer ou déverrouiller le trousseau dans une étape isolée ;
3. importer les certificats avec des permissions minimales ;
4. produire l’archive dans un répertoire propre ;
5. vérifier l’identité de signature et les entitlements ;
6. exporter le produit avec une méthode explicitement choisie ;
7. exécuter la vérification finale sans exposer les secrets dans les journaux.

Pour les tests de simulateur, ne vous contentez pas d’un nom générique. Listez les destinations disponibles avec xcrun simctl list devices et échouez avec un message clair si la cible attendue n’est pas présente. La disparition d’un simulateur, un runtime différent ou une incompatibilité d’architecture peut expliquer un échec que le message de compilation rend peu lisible.

La migration GitHub Actions vers macOS 26 se valide en cinq étapes

1. Cartographier les workflows

Recherchez macos-latest, les libellés explicites, les actions de sélection de Xcode, les gestionnaires de dépendances, les scripts d’architecture et les Jobs de publication. Classez chaque workflow selon son niveau de risque au lieu de modifier tout le dépôt en une seule fois.

2. Capturer l’état de référence

Relancez le dernier commit connu comme stable et archivez les journaux, l’archive, les sommes de contrôle des produits et les informations de signature. Notez aussi si l’exécution était froide ou si elle bénéficiait d’un cache.

3. Construire un Job parallèle

Utilisez un libellé macOS explicite pour le nouveau Job, sans remplacer immédiatement la production. Gardez le même commit, les mêmes secrets de test et la même destination. La comparaison n’est valable que si les entrées sont identiques.

4. Corriger une variable à la fois

Commencez par Xcode et la destination, puis les dépendances, l’architecture, le cache et enfin la signature. Pour chaque correction, conservez un journal lisible indiquant le symptôme, la preuve observée, l’action réalisée et le critère de réussite.

5. Tester le retour arrière

L’ancien libellé ou l’ancien environnement doit rester exécutable pendant la période de transition. Faites échouer volontairement le nouveau Job ou désactivez-le temporairement afin de prouver que le pipeline de publication peut revenir à l’environnement précédent sans modifier le code source.

6. Comparer les produits, pas seulement les statuts

Comparez l’archive, les métadonnées, les entitlements, la signature et les tests. Pour un projet audio, vidéo ou de design, ajoutez une vérification des ressources exportées et des outils de traitement utilisés : un changement d’outil peut produire un fichier lisible mais différent, ce qui est parfois plus grave qu’un échec immédiat.

Quand conserver un Runner hébergé et quand autogérer un Mac

Voici une règle de décision directement applicable :

• Si votre tâche est stateless, reconstruit toutes ses dépendances et accepte une validation périodique, choisissez macOS 26 après comparaison complète ; conservez macos-latest uniquement pour les tâches qui tolèrent explicitement l’évolution d’image.
• Si votre build dépend d’une version précise de Xcode ou d’un SDK déterminé, utilisez un libellé système explicite, verrouillez l’outil et gardez un Job de repli.
• Si la publication exige une identité de signature contrôlée, un trousseau persistant ou une validation reproductible, séparez-la des tâches générales et imposez une procédure de retour arrière.
• Si le pipeline nécessite un cache durable, une configuration installée une seule fois ou une présence continue, évaluez un Mac distant autogéré comme canal de construction indépendant.
• Si vous ne pouvez pas isoler les secrets, limiter l’accès au dépôt privé ou mettre à jour le Runner, ne choisissez pas l’autogestion uniquement pour éviter la dérive d’image.

Un Runner autogéré ne supprime pas l’exploitation. Il ajoute la gestion des mises à jour, la surveillance, l’effacement des secrets, l’isolation des Jobs et la politique d’accès au dépôt. Les règles d’enregistrement et de sécurité doivent être définies avant l’installation, conformément aux instructions GitHub pour ajouter un Runner autogéré. Pour approfondir l’accès distant graphique pendant un diagnostic, consultez aussi le guide SSHMac sur l’accès VNC à un Mac distant.

Comparatif de migration et score de choix

Le score ci-dessous n’est pas une mesure de performance : il sert à pondérer le risque opérationnel selon votre type de tâche. Les valeurs sont des critères de décision, non des caractéristiques promises d’un fournisseur.

Ces scores ne doivent pas être lus comme une recommandation universelle. Une équipe qui publie rarement et accepte de reconstruire l’environnement peut rester sur un Runner hébergé explicite. Une équipe qui signe chaque jour, conserve des outils spécialisés ou traite des flux audio et vidéo bénéficiera davantage d’un environnement durable, à condition d’assumer sa sécurité et sa maintenance.

Le choix final dépend de votre degré de contrôle nécessaire

Le Runner hébergé reste pertinent pour les tests sans état, les branches de revue et les matrices temporaires. Son principal défaut est la dérive de l’image : vous devez surveiller les libellés, les versions préinstallées, la disponibilité des simulateurs et la compatibilité des dépendances à chaque changement documenté.

À l’inverse, un Mac local ou un serveur Mac acheté vous impose le coût initial du matériel, son remplacement, sa disponibilité réseau, sa consommation électrique et la maintenance d’un poste qui doit rester accessible. Il est peu adapté si vous avez seulement besoin d’un environnement Apple pendant une phase de migration ou pour quelques cycles de publication.

La location d’un Mac distant auprès de SSHMac est à examiner lorsque vous avez besoin d’un vrai macOS accessible par SSH, VNC ou console distante, sans immobiliser immédiatement un budget matériel. Elle ne remplace pas une architecture sécurisée : vous devez toujours isoler les secrets, restreindre les dépôts et contrôler les mises à jour du Runner. Pour vérifier les modalités générales avant décision, consultez le centre d’aide SSHMac.

Si votre pipeline accepte une machine neuve à chaque exécution, poursuivez avec un Runner hébergé après validation de macOS 26. Si vous devez conserver Xcode, une identité de signature et un cache maîtrisés, ajoutez plutôt un nœud Mac distant indépendant, puis faites passer un projet réel dans les deux environnements avant de déplacer la publication. C’est cette comparaison — journaux, archive, signature, reprise après échec et retour arrière — qui permet de savoir si vous corrigez une dérive d’image ou un défaut latent du projet.