Migration GitHub Actions Node 24 : checklist Mac CI 2026

Dernière mise à jour : 2 septembre 2026. Les dates et comportements mentionnés ici ont été vérifiés à partir des annonces GitHub, de la documentation des runners et des versions publiées. Les équipes doivent toutefois contrôler la page de téléchargement de leur organisation avant toute bascule, car le calendrier de déploiement peut évoluer.

N’attendez pas le retrait définitif de Node 20 : activez dès maintenant Node 24 sur un Mac isolé, validez les Actions, le self-hosted runner, macOS et toute la chaîne Xcode en parallèle, puis transférez la production par groupes. Un ancien nœud qui ne peut pas être mis à niveau doit sortir du pool de production ou être remplacé par un nouveau Mac distant, plutôt que rester dépendant d’un retour temporaire.

Cet article s’adresse aux équipes plateforme qui administrent des Mac auto-hébergés, aux responsables de l’efficacité d’ingénierie qui supervisent les publications iOS et aux responsables IT chargés de la capacité, de la continuité d’activité et du renouvellement des machines.

Le calendrier de migration

La migration de GitHub Actions vers Node 24 concerne trois composants qu’il faut suivre séparément :

• le runtime Node intégré à une JavaScript Action ;
• la version de Node utilisée directement par le projet, par exemple pour installer des dépendances ou exécuter des scripts ;
• l’application Actions Runner installée sur le Mac.

Une compilation iOS réussie ne prouve donc pas que l’environnement est prêt. Une Action JavaScript peut échouer avant l’appel à Xcode, tandis qu’un projet Node peut continuer à utiliser sa propre version sans modifier le runtime interne de l’Action. Inversement, un runner trop ancien peut empêcher l’exécution avant même que le script du projet ne démarre.

GitHub indique que les runners Actions utilisent Node 24 par défaut depuis le 16 juin 2026. Le retour temporaire vers Node 20 doit rester disponible jusqu’au 23 septembre 2026, selon le calendrier officiel de retrait de Node 20. Pour GitHub Enterprise Cloud, l’application forcée des exigences minimales de version des runners doit commencer le 25 septembre 2026 ; la version minimale exacte et le rythme d’application doivent être vérifiés dans l’annonce officielle sur l’exécution des versions minimales.

Ces échéances créent deux risques distincts :

1. une Action qui dépend encore de Node 20 peut devenir incompatible ;
2. un runner ou un système macOS ancien peut ne plus satisfaire les conditions d’exécution ou de mise à jour.

La bonne décision est donc une migration à double voie : un pool de production inchangé mais surveillé, et un pool pilote sous Node 24, sans secret de signature de production. La production ne doit basculer qu’après validation des deux voies.

Les workflows exposés après le retrait de Node 20

Les tâches les plus vulnérables sont celles qui utilisent des Actions JavaScript anciennes, des Actions tierces figées sur un commit ancien ou des composants dont le fichier de métadonnées demande explicitement un runtime Node obsolète. Les étapes run: qui invoquent directement Node ne sont pas exactement dans la même situation : elles dépendent de la version installée ou sélectionnée par le projet, et non automatiquement du runtime d’une Action.

L’inventaire doit couvrir les dépôts de production, les branches de publication, les workflows planifiés et les workflows réutilisables. Les alertes affichées dans les exécutions GitHub sont utiles, mais elles ne remplacent pas une recherche dans les fichiers YAML et dans les dépôts d’Actions internes.

Le jour du lancement : inventaire exploitable

Avant de modifier un runner, l’équipe doit créer un registre par dépôt et par workflow. Un simple tableau de suivi suffit, à condition qu’il distingue bien les responsabilités techniques.

Les colonnes minimales sont les suivantes :

• dépôt, équipe propriétaire et niveau de criticité ;
• nom du workflow et événement déclencheur ;
• Action utilisée, version déclarée et référence de commit éventuelle ;
• indication du runtime Node demandé par l’Action ;
• groupe, étiquette et nom du macOS Runner ;
• version de l’application Runner ;
• version de macOS et architecture Intel ou Apple Silicon ;
• présence d’un certificat, d’une clé privée, d’un trousseau ou d’un secret de publication ;
• résultat du dernier build, du dernier test et du dernier archivage ;
• responsable de la validation et action de repli.

Les données peuvent être croisées avec l’API REST des self-hosted runners, l’API REST des exécutions de workflows et les journaux d’avertissement visibles dans l’interface GitHub Actions. L’API permet notamment de rapprocher l’état d’un nœud, ses étiquettes et sa version déclarée avec les workflows qui l’utilisent.

La liste des versions publiées dans le dépôt officiel d’Actions Runner doit être comparée à la version réellement téléchargée par l’organisation. Une machine « connectée » n’est pas nécessairement conforme : elle peut accepter des tâches tout en restant incapable d’appliquer la prochaine mise à niveau.

Checklist de l’inventaire

• [ ] Chaque workflow de publication ou de distribution est recensé.
• [ ] Chaque Action JavaScript possède une version et une source identifiables.
• [ ] Les Actions internes et celles fixées par commit sont incluses.
• [ ] Les runners Intel et Apple Silicon sont différenciés.
• [ ] La version de macOS est enregistrée avec la version du runner.
• [ ] Les nœuds contenant des certificats de signature sont signalés.
• [ ] Les alertes de runtime et les échecs récents sont reliés à un propriétaire.
• [ ] Un groupe pilote et un groupe de production sont déjà distingués.

Cette étape révèle souvent un coût opérationnel discret : les équipes pensent gérer une flotte homogène alors que les workflows ciblent des étiquettes historiques, que certains nœuds ne redémarrent plus correctement ou que des Actions sont bloquées sur une référence ancienne.

La première heure : essai isolé sous Node 24

Le pilote doit utiliser un Mac qui ne possède pas les certificats de signature de production. Il doit être joignable par le même mécanisme que les autres nœuds, mais placé dans un groupe ou derrière une étiquette dédiée. Cela permet de tester l’infrastructure sans exposer les secrets de publication.

Le mécanisme de migration fourni par GitHub permet d’imposer temporairement Node 24 afin d’identifier les incompatibilités avant la bascule générale. Le nom exact de la variable ou du paramètre doit être repris dans l’annonce GitHub en vigueur et dans la configuration de l’organisation ; il ne faut pas conserver indéfiniment une variable de retour vers Node 20 comme solution d’exploitation.

La première exécution doit être une ligne de base représentative, et non un simple xcodebuild. Elle doit passer par :

• la récupération du code ;
• la restauration et l’écriture du cache ;
• l’installation des dépendances privées ;
• une Action JavaScript interne ou tierce ;
• la compilation et les tests ;
• la production d’un artefact ;
• le transfert de l’artefact vers son emplacement prévu.

Pour vérifier le contexte sans multiplier les commandes, le journal peut conserver les sorties de version du runner, de Node, de macOS et de Xcode, ainsi que les étiquettes effectivement sélectionnées. Le guide de configuration du service self-hosted runner décrit le fonctionnement du service, son enregistrement et son redémarrage.

Une exécution verte ne suffit pas. L’équipe doit conserver le journal, le nom du nœud, l’identifiant du workflow, le commit testé et la nature de l’artefact. Une incompatibilité peut ne se manifester que lors de l’écriture du cache, de la lecture du trousseau ou de la reprise d’un service après redémarrage.

Ce que le pilote doit rechercher

Un ancien script peut supposer un chemin de fichier, une variable d’environnement ou un comportement de shell qui n’est plus identique. Une Action peut aussi dépendre d’un certificat proxy installé dans le trousseau système, d’une autorité interne ou d’un outil présent uniquement sur les anciens Mac.

Les journaux doivent donc être examinés sur quatre plans :

• erreur de chargement de l’Action ou du runtime ;
• échec réseau vers un registre privé ou un dépôt de dépendances ;
• refus d’accès au trousseau, au cache ou au répertoire de travail ;
• différence entre l’utilisateur interactif et le compte du service runner.

Le guide GitHub consacré à l’utilisation sécurisée des Actions doit accompagner cette revue. Le fait de disposer d’un accès root sur le Mac ne justifie pas l’ajout de permissions globales au workflow : les droits doivent rester limités au rôle du nœud.

Le premier jour : Actions, runner et macOS

La réparation commence par les Actions qui signalent encore un runtime ancien. Une mise à jour vers une version compatible est préférable à une modification locale du runner, car elle rend le correctif visible dans le dépôt et reproductible par les autres équipes.

Les Actions tierces doivent être évaluées selon leur source, leur maintenance, leurs permissions et leur capacité à fonctionner sous Node 24. Une Action ancienne peut continuer à fonctionner dans un cas simple, mais échouer lors d’une opération réseau, d’un traitement d’artefact ou d’une interaction avec une API. La réponse à la question « une ancienne GitHub Action peut-elle rester en production ? » est donc conditionnelle : uniquement après un test explicite sous Node 24, avec une version maintenue et un plan de remplacement documenté.

Les références fixées par commit méritent une attention particulière. Elles améliorent la reproductibilité, mais peuvent aussi empêcher la réception d’un correctif. Le commit doit être comparé à la version publiée, puis mis à jour selon la procédure de revue de code de l’entreprise.

Le self-hosted runner doit ensuite être traité comme un composant logiciel indépendant. La mise à niveau comprend :

• téléchargement de la version approuvée depuis la source officielle ;
• arrêt contrôlé du service ;
• remplacement des fichiers du runner ;
• redémarrage du service ;
• vérification de l’enregistrement auprès de l’organisation ;
• exécution d’un workflow de diagnostic ;
• contrôle de l’auto-mise à jour lors d’une exécution suivante.

Un runner peut apparaître en ligne après son redémarrage tout en étant mal étiqueté, affecté au mauvais groupe ou incapable de recevoir une tâche. L’état visible dans l’interface doit donc être complété par une exécution réelle et par la vérification des journaux locaux.

La décision macOS

Node 24 ne signifie pas automatiquement qu’il faut mettre à niveau chaque Mac le même jour. La décision dépend de la compatibilité du système, de Xcode, des dépendances natives et des outils de signature. Toutefois, un ancien macOS qui ne peut pas satisfaire les conditions du runner ne doit pas rester durablement dans le pool de production avec une variable de repli.

Trois sorties sont raisonnables :

• mettre à niveau macOS, puis revalider Xcode et les certificats ;
• remplacer le nœud par un Mac compatible et l’intégrer au pool pilote ;
• retirer le nœud de la production et conserver son usage limité à l’analyse ou à la récupération.

La documentation des self-hosted runners et de leurs systèmes pris en charge doit être consultée avant de choisir la première option. Les versions minimales et les conditions d’exploitation peuvent changer ; la page de téléchargement de l’organisation reste la référence opérationnelle.

La première validation de production : chaîne Xcode

La validation doit utiliser un projet réel, mais dans un environnement contrôlé. La chaîne attendue est : dépendances privées, compilation Xcode, tests, archivage, signature et dépôt de l’artefact. Chaque maillon doit laisser une preuve exploitable par l’équipe plateforme.

Le terme Xcode ne doit pas être réduit à une simple vérification de version. Il faut également contrôler :

• la sélection de l’outil actif ;
• les SDK et simulateurs nécessaires ;
• l’accès aux dépôts privés ;
• les chemins des dépendances natives ;
• la création et la lecture du trousseau ;
• la présence des profils et certificats autorisés ;
• l’écriture du cache sans partage excessif entre projets ;
• le transfert et la conservation de l’archive.

La signature de production doit rester sur un nœud séparé. Le pilote Node 24 ne reçoit que les secrets nécessaires à une validation non sensible, puis la même chaîne est rejouée sur le nœud de publication avec une autorisation temporaire et traçable. Cette séparation réduit le rayon d’action d’une Action compromise ou d’un script qui exposerait accidentellement une variable.

Les conditions de réussite

• [ ] Le code privé est récupéré sans contournement manuel.
• [ ] Le cache est restauré puis écrit avec les droits attendus.
• [ ] La compilation Xcode et les tests aboutissent sur le Mac pilote.
• [ ] L’archive peut être créée et retrouvée par le workflow.
• [ ] La signature est validée séparément sur le nœud autorisé.
• [ ] L’artefact est transféré vers sa destination habituelle.
• [ ] Les Actions internes produisent les mêmes journaux fonctionnels.
• [ ] Un redémarrage du service n’efface pas l’enregistrement ni les étiquettes.

Les équipes qui produisent aussi de l’audio, de la vidéo ou des applications de design doivent ajouter leurs outils natifs au scénario. Ces chaînes utilisent souvent des caches volumineux, des licences locales ou des extensions qui ne sont pas sollicitées par un build iOS minimal ; leur validation séparée évite de déclarer la flotte compatible sur la base d’un seul projet.

La première semaine : double voie et retour arrière

Pendant la période de transition, le pool de production déjà validé et le pool Node 24 doivent rester identifiables par des groupes ou des étiquettes. Un dépôt ne doit pas passer d’un pool à l’autre par modification manuelle sur la machine : le changement doit être visible dans le workflow et réversible par une revue.

Le retour arrière ne consiste pas à maintenir éternellement Node 20. Il s’agit d’une mesure limitée permettant de terminer une livraison pendant que l’Action, le runner ou le Mac est corrigé. La durée d’utilisation doit avoir une date de fin, un propriétaire et une condition de sortie. Après le 23 septembre 2026, le retour vers Node 20 ne doit plus être considéré comme une stratégie de continuité, conformément à l’avis officiel déjà cité.

Le tableau suivant sert de décision rapide pour chaque dépôt :

La capacité doit être ajustée à partir de données réellement observées : longueur de file, nombre de dépôts transférés, taux de réussite du pilote et délai nécessaire pour remplacer un Mac. Aucune capacité ou performance ne doit être extrapolée à partir d’une seule compilation. Si le stock interne ne permet pas de conserver deux pools, une solution de Mac distant pour un environnement pilote peut fournir un nœud isolé avant l’achat ou le remplacement définitif.

Le remplacement externe doit lui aussi suivre une procédure d’acceptation : accès réseau, enregistrement du runner, redémarrage du service, étiquettes, chaîne Xcode, stockage des artefacts et retrait propre du nœud si le pilote échoue. Le coût réel ne se limite pas au tarif de la machine ; il inclut le délai d’approvisionnement, l’administration, la maintenance, la capacité de secours et la gestion des secrets.

La date limite : admission en production

Avant le début de l’application forcée des versions minimales le 25 septembre 2026, chaque équipe doit disposer d’une fiche de décision par nœud. Les informations indispensables sont :

• version du runner confirmée sur la page de téléchargement de l’organisation ;
• compatibilité macOS et architecture ;
• résultat du workflow Node 24 ;
• résultat Xcode, tests, archivage et signature ;
• état des dépendances privées et du cache ;
• séparation des secrets ;
• comportement après arrêt et redémarrage ;
• groupe de destination ;
• propriétaire technique et procédure d’escalade.

Les Actions non vérifiées doivent être gelées avant la bascule. Une exception documentée peut conserver un dépôt sur le pool de production, mais elle ne doit pas transformer un ancien Mac en dépendance permanente. Si le runner ne peut pas être mis à niveau, la décision la plus sûre est le remplacement ou la sortie du pool, avec une capacité temporaire réservée pour éviter qu’une publication urgente ne soit bloquée.

Réponses aux décisions récurrentes

Le retour temporaire vers Node 20 suffit-il ?
Non. Il peut servir à terminer une livraison pendant la correction, mais il ne remplace pas la mise à niveau. La date du 23 septembre 2026 doit être traitée comme une limite de sortie, non comme le début du projet.

Faut-il mettre à niveau macOS et le runner en même temps ?
Pas nécessairement sur chaque nœud, mais les deux dépendances doivent être testées dans le même parcours. Un runner conforme sur un macOS incompatible reste inutilisable ; un macOS récent avec une Action ancienne reste exposé.

Comment tester un self-hosted runner sous Node 24 ?
Placez-le dans un groupe isolé, retirez les secrets de production, activez le mécanisme officiel de migration, puis exécutez un workflow couvrant Actions, cache, dépendances privées, Xcode, artefact et redémarrage du service. Conservez les journaux et l’identifiant de l’exécution.

Que faire d’un ancien Mac Runner qui échoue pendant la mise à niveau ?
Ne le laissez pas recevoir les publications. Désactivez son étiquette de production, conservez-le uniquement comme élément de diagnostic si nécessaire, puis mettez en place un nœud de remplacement validé. Un Mac distant temporaire peut servir de relais si l’approvisionnement interne est trop lent.

Une Action ancienne fonctionnera-t-elle forcément avec Node 24 ?
Non. Certaines continueront à fonctionner, mais seule la version de l’Action et son comportement dans le workflow réel permettent de conclure. Les références figées par commit doivent être auditées séparément.

Les nœuds Intel doivent-ils être supprimés ?
Pas automatiquement. Ils peuvent rester utiles si le projet, Xcode et le runner sont compatibles. En revanche, un nœud Intel qui ne peut pas satisfaire les exigences de macOS ou du runner ne doit pas rester dans le pool critique uniquement pour éviter un remplacement.

Le choix de capacité pour la suite

Après l’inventaire, le pilote et la première semaine de double voie, le choix entre achat et location devient plus précis. L’achat conserve un intérêt pour une charge stable, prévisible, fortement utilisée et nécessitant des interfaces physiques ou une présence locale. Il impose toutefois l’immobilisation du capital, le remplacement du matériel, la maintenance, la capacité de secours et l’administration des nœuds.

La location d’un Mac distant est plus pertinente lorsque le besoin principal est temporaire : pilote Node 24, remplacement d’un ancien runner, lancement d’une nouvelle équipe ou absorption d’une file exceptionnelle. Elle évite de commander une machine avant de connaître le taux d’adoption réel, tout en laissant le temps de mesurer la compatibilité Xcode et la reprise après redémarrage. Les conditions de location de Mac et les périodes disponibles doivent être comparées au coût interne complet, et non au seul prix d’achat du matériel.

Dans cette migration, la solution actuelle — conserver des Mac anciens, maintenir une variable de repli et repousser le remplacement — présente au moins quatre défauts : elle concentre le risque sur une échéance connue, masque les Actions obsolètes, augmente les interventions manuelles et peut bloquer une livraison si le nœud devient non conforme. Un Mac distant RUVCLOUD utilisé comme pool pilote ou comme capacité de remplacement offre alors un chemin plus contrôlable : l’équipe valide d’abord le runner et la chaîne Xcode, puis ajuste le nombre de nœuds et la durée de location selon les résultats réels. Cette option reste moins adaptée à une charge lourde et stable nécessitant un accès physique permanent, mais elle répond bien à une migration urgente dont le périmètre doit encore être mesuré.

L’action suivante est concrète : après l’inventaire, sélectionnez un workflow représentatif, retirez ses secrets de production, affectez-le à un Mac isolé sous Node 24 et consignez la preuve de chaque étape avant de décider du remplacement ou du transfert en série.