GitHub Actions retire l’image macOS 14 le 2 novembre et coupe les jobs non migrés pendant les brownouts d’octobre
GitHub retirera l’image de runner macOS 14 le 2 novembre 2026 et fait déjà échouer les jobs qui l’utilisent encore pendant huit fenêtres de brownout réparties sur octobre. Migrez vos workflows vers un label arm64 — macos-15 ou macos-latest — avant la prochaine coupure du 12 octobre.
1er octobre 2026. GitHub annonce le retrait de l’image de runner macOS 14 pour le 2 novembre 2026. Du 5 au 6 octobre, le premier brownout a déjà fait échouer les jobs encore branchés sur ce label. Huit fenêtres de coupure sont programmées d’ici la fin du mois. Pour une équipe dont la CI macOS est critique — build d’application, signature, tests Xcode — la conséquence est immédiate : un workflow qui référence encore macos-14 va tomber en panne pendant ces créneaux, puis définitivement à partir du 2 novembre.
Ce que GitHub retire exactement
Le retrait couvre trois labels hébergés : macos-14, macos-14-large et macos-14-xlarge. Concrètement, toute la famille d’images macOS 14 Sonoma disparaît du parc de runners hébergés par GitHub. Un job qui déclare runs-on: macos-14 ne trouvera bientôt plus de machine pour s’exécuter.
Pour forcer la migration plutôt que de laisser les équipes découvrir la panne le jour J, GitHub a repris sa mécanique habituelle de brownout : les jobs ciblant macos-14 échouent volontairement pendant des créneaux précis, à titre d’avertissement. Les huit fenêtres s’étalent sur octobre, chacune de 14 h 00 UTC à minuit UTC le lendemain :
- du 5 au 6 octobre (déjà passé) ;
- du 12 au 13 octobre ;
- du 16 au 17 octobre ;
- du 19 au 20 octobre ;
- du 23 au 24 octobre ;
- du 26 au 27 octobre ;
- du 29 au 30 octobre ;
- du 30 au 31 octobre.
À cela s’ajoute une pression plus insidieuse : pendant la période de transition, GitHub se réserve le droit de réduire la capacité des runners macos-14. Résultat, même en dehors des brownouts, les jobs non migrés peuvent subir des files d’attente plus longues — un échec silencieux, sans message d’erreur explicite, que les équipes confondent facilement avec une simple lenteur.
Pourquoi maintenant : la bascule vers Apple Silicon
Ce retrait n’est pas un événement isolé, c’est l’étape suivante d’une transition arm64 engagée depuis plusieurs mois. GitHub a rendu macOS 26 (Tahoe) généralement disponible le 26 février 2026, avec des runners exécutés nativement sur Apple Silicon (arm64) tout en conservant une image Intel (x64). La migration recommandée pointe vers des labels arm64 : macos-latest (qui désigne désormais macOS 26), macos-15, et leurs variantes -xlarge.
Le point d’attention pour les équipes encore sur Intel tient en un label : macos-15-intel. Il s’agit de la dernière image x86_64 que GitHub Actions proposera, disponible jusqu’en août 2027. Autrement dit, une équipe qui ne peut pas encore compiler ou signer sur arm64 n’est pas laissée sans solution — mais elle doit le déclarer explicitement, car le comportement par défaut de la plateforme est désormais arm64.
Le piège est là : beaucoup de workflows ont été écrits à l’époque où macos-latest pointait encore vers une image Intel. En migrant « en aveugle » de macos-14 vers macos-latest, on change aussi d’architecture, pas seulement de version de système. Une dépendance x86_64 (un outil précompilé, une extension, un binaire maison) peut alors se casser de façon subtile — au moment du build, pas de la déclaration.
Ce qui casse si vous ne faites rien
Le scénario de dégradation se lit en trois temps. Pendant les brownouts, les jobs macos-14 échouent purement et simplement : un pipeline de build ou de signature mobile s’arrête, bloquant les livraisons. Entre les brownouts, la réduction de capacité allonge les files d’attente et ralentit tout le pipeline sans alerte explicite. Après le 2 novembre, l’image n’existe plus du tout : l’échec devient permanent.
Pour une équipe mobile, l’enjeu dépasse le simple inconvénient. Les builds iOS et macOS passent presque toujours par une machine macOS pour compiler avec Xcode, exécuter les tests sur simulateur, puis signer les artefacts. Un label retiré, c’est une chaîne de livraison entière qui s’arrête — et un correctif urgent qui ne peut plus sortir tant que le workflow n’est pas migré. Le moment de corriger n’est pas le jour du retrait, c’est maintenant.
Migrer en pratique
La première étape est un inventaire, pas une correction. Avant de toucher quoi que ce soit, listez les workflows encore branchés sur les labels condamnés :
# Lister les workflows qui référencent encore les labels retirés
grep -rn "macos-14" .github/workflows/La correction elle-même tient dans une ligne de YAML. La cible recommandée par GitHub est un label arm64 :
# .github/workflows/ci.yml — avant
jobs:
build:
runs-on: macos-14
# .github/workflows/ci.yml — après
jobs:
build:
runs-on: macos-15 # ou macos-latest (macOS 26, arm64)Deux règles d’hygiène accompagnent cette bascule. D’abord, ne migrez pas vers macos-latest sans vérifier l’architecture : si votre chaîne contient encore un binaire Intel, préférez macos-15-intel le temps de la recompilation, et planifiez la bascule arm64 avant août 2027. Ensuite, pinez vos versions au lieu de suivre macos-latest : le retrait de macos-14 est précisément le genre d’événement qui punit les workflows non pincés, comme l’a déjà montré la migration de ubuntu-latest vers Ubuntu 26.04 le mois dernier.
Pour les équipes qui utilisent des runners auto-hébergés (self-hosted), le retrait ne s’applique pas directement — vous fournissez vos propres machines. Mais l’image logicielle que vous y installez reste votre responsabilité : si vous avez figé un environnement macOS 14 Sonoma, la question de sa mise à jour se pose de la même façon, simplement à votre rythme.
Les pièges de la bascule arm64
Migrer de macos-14 vers macos-latest change l’architecture, et cette bascule a des effets concrets que la plupart des équipes découvrent au premier build cassé. Le plus fréquent tient à Homebrew : sur les runners Intel, les paquets s’installent dans /usr/local, tandis que sur Apple Silicon, le préfixe devient /opt/homebrew. Tout script qui suppose un chemin en dur — un PATH, un bundle install, un brew --prefix figé — échoue sans message évident.
Le second écueil, ce sont les binaires précompilés. Une dépendance x86_64 embarquée dans le dépôt, un outil de signature ou un SDK propriétaire ne s’exécute pas nativement sur arm64. Rosetta 2 peut faire tourner du x86_64 sur Apple Silicon, mais s’y fier pour un pipeline de production revient à masquer le problème au lieu de le résoudre : le binaire émulé fonctionne, jusqu’au jour où il devient le goulot d’étranglement ou le point de panne d’une livraison.
Deux commandes suffisent à dresser l’état des lieux avant de couper :
# Architecture de la machine du runner
uname -m
# Architecture d’un binaire suspect
file ./mon-outilLa démarche recommandée tient en une phrase : basculez d’abord sur un job canari. Dupliquez le workflow critique sur macos-15 en parallèle de macos-14, comparez les artefacts, puis supprimez l’ancien label une fois le canari vert sur plusieurs exécutions. C’est la seule façon de transformer une migration d’architecture en opération de routine plutôt qu’en pari.
Verdict
Si vos workflows utilisent encore macos-14, traitez le prochain brownout du 12 octobre comme une échéance ferme : lancez l’inventaire grep dès aujourd’hui, migrez vers macos-15 ou macos-latest, et vérifiez que le build passe sur arm64. Si votre chaîne dépend de binaires Intel, basculez sur macos-15-intel immédiatement, mais inscrivez la recompilation arm64 au backlog — ce label disparaît en août 2027. Si vous gérez un parc de dépôts, automatisez la détection : un contrôle hebdomadaire qui scanne .github/workflows/ à la recherche des labels dépréciés vaut mieux que huit brownouts subis à l’aveugle. La leçon de fond est la même que pour ubuntu-latest : sur GitHub Actions, la version par défaut d’un runner est une dette à date, pas une garantie de stabilité.