D’après l’annonce officielle de GitHub publiée le 23 septembre 2026 sur le retrait de Node 20, le runtime Node 20 des JavaScript Actions a été retiré des runners GitHub Actions et remplacé par Node 24. Cette date marque un changement du runtime des Actions, pas la suppression du Node.js que votre projet installe lui-même. Pour rétablir votre Mac CI, identifiez d’abord la couche qui échoue, mettez à jour l’Action concernée vers une version compatible, puis vérifiez séparément la compatibilité de macOS et de l’architecture.

À qui s’adresse ce guide ? Aux responsables IT qui doivent mesurer l’impact sur les pipelines Mac CI et définir les priorités de reprise.
Aux ingénieurs plateforme qui maintiennent des runners auto-hébergés, des Actions réutilisées ou des modèles de workflow d’organisation.
Aux responsables des versions iOS et macOS qui doivent prouver que les compilations, tests et publications critiques fonctionnent de nouveau.

Mis à jour le 21 octobre 2026. Faits vérifiés dans le changelog et la documentation GitHub cités dans l’article.

01

Distinguez le runtime de l’Action du Node.js de votre projet

Le terme Node peut désigner deux choses différentes dans un même pipeline. Le runtime d’une JavaScript Action sert à exécuter le code de l’Action elle-même. Le Node.js du projet, lui, peut être installé ou sélectionné par une étape du workflow, puis servir à exécuter les outils de l’application. Le retrait annoncé par GitHub concerne le premier cas.

Cette distinction doit guider le premier diagnostic. Si le journal indique une erreur au démarrage ou au chargement d’une Action, examinez la version de cette Action et ses métadonnées. Si l’Action s’est initialisée correctement et que l’échec apparaît ensuite dans une commande de compilation, de test ou d’installation des dépendances, le Node.js du projet reste une piste distincte. Ne changez pas le Runner ni la version de Node du projet avant d’avoir localisé l’étape en erreur.

La documentation GitHub sur les workflows Node.js distingue l’exécution des commandes du projet des Actions appelées par le workflow. Dans le fichier YAML, une étape uses appelle une Action ; une étape run exécute une commande dans l’environnement du Runner. Cette différence ne suffit pas, à elle seule, à prouver la cause, mais elle réduit rapidement le périmètre d’investigation.

À retenir : un message mentionnant le runtime d’une Action n’est pas une preuve que le Node.js applicatif a disparu. Conservez le journal complet et relevez le nom de l’étape avant de modifier l’environnement.

Un cas fréquent en entreprise est celui d’un pipeline iOS qui utilise des Actions partagées pour préparer les certificats, installer des outils ou publier un artefact. L’étape Xcode peut rester inchangée tandis qu’une Action réutilisée échoue avant même de lancer la compilation. Dans ce scénario, remplacer le Mac ou modifier les réglages Xcode ne traite pas la cause : il faut d’abord identifier l’Action qui ne démarre plus.

02

Inventoriez les références et les métadonnées des Actions

La panne peut venir d’une Action appelée directement dans le dépôt, mais aussi d’une Action composée ou d’un modèle réutilisé par plusieurs équipes. Une recherche limitée au workflow principal risque donc de manquer la dépendance qui pose problème. Faites l’inventaire des références uses dans les workflows, les Actions composées et les modèles d’organisation effectivement utilisés par les tâches en échec.

Pour une JavaScript Action, examinez son fichier action.yml ou action.yaml. La documentation GitHub sur les métadonnées des Actions décrit le champ runs.using, qui indique le runtime de l’Action. Vérifiez ce champ dans la version réellement appelée, et non uniquement dans la branche principale du dépôt : le workflow peut épingler une ancienne version ou une référence différente de celle que vous consultez.

La documentation de création d’une JavaScript Action aide à comprendre les éléments de ce type d’Action et la déclaration de son runtime. Pour une Action maintenue par un tiers, comparez les métadonnées de la version installée avec celles d’une version candidate. Pour une Action interne, attribuez explicitement la mise à jour à son équipe propriétaire. Modifier seulement le workflow ne corrigera pas une Action interne dont le code ou les métadonnées restent incompatibles.

Tenez aussi compte de la syntaxe effective du workflow. Une référence peut être fournie par un appel réutilisable ou héritée d’un modèle commun. La référence GitHub sur la syntaxe des workflows permet de retrouver les différentes formes d’appel et les paramètres concernés. Le but n’est pas de mettre à jour indistinctement toutes les Actions, mais de relier une erreur observée à une référence, une version et un propriétaire vérifiables.

Une mise à jour candidate doit ensuite être éprouvée hors du chemin de publication principal. Vérifiez que l’Action accepte les mêmes entrées, produit les sorties attendues et traite les erreurs de la même façon. Une mise à jour qui démarre mais change le format d’un artefact ou ignore une erreur n’est pas une réparation suffisante.

03

Séparez les contraintes du runtime, de macOS et de l’architecture

La compatibilité du Runner constitue une deuxième branche du diagnostic. GitHub précise que Node 24 n’est pas compatible avec macOS 13.4 et les versions antérieures, et qu’il ne prend pas officiellement en charge ARM32. Ces limites concernent le runtime Node 24 employé par les JavaScript Actions. Elles ne permettent pas de conclure que tous les runners Mac, ni tous les Mac Apple Silicon, sont affectés. Consultez l’annonce GitHub sur Node 24, macOS et ARM32 pour rapprocher le message d’erreur des limites publiées.

Relevez la version exacte de macOS et l’architecture du Runner. Comparez-les à la configuration du job en échec, pas à celle d’une autre machine du parc. Un Runner auto-hébergé peut être en ligne et accepter des tâches tout en étant inadapté au runtime demandé par une Action. La documentation sur le choix du Runner d’un job permet de vérifier comment les étiquettes et les critères du workflow dirigent le travail vers un Runner donné. Les instructions relatives aux runners auto-hébergés complètent ce contrôle côté exploitation.

Indice observé Vérification à effectuer Orientation de diagnostic
Échec au chargement d’une JavaScript Action Version réellement appelée et champ runs.using Compatibilité de l’Action ou de son runtime
Échec après une commande run du projet Commande, installation et version de Node.js applicative Environnement ou dépendances du projet
Action en échec sur un Runner ancien Version exacte de macOS, puis comparaison avec la limite publiée par GitHub Compatibilité du système d’exploitation
Échec associé à une architecture particulière Architecture déclarée et architecture effective du Runner Vérification de la prise en charge de l’architecture
Job dirigé vers un autre hôte que prévu Étiquettes, règles de sélection et Runner réellement utilisé Routage ou configuration du workflow

Cette matrice sert à sélectionner le prochain contrôle, pas à déclarer la cause sans preuve. Un message runtime et un Runner ancien peuvent coexister. Il faut alors tester les deux pistes séparément, en gardant les mêmes références d’Action et le même travail de compilation pour comparer les résultats.

Attention : la limite relative à macOS 13.4 ou à une version antérieure ne signifie pas que tout Mac ancien est la cause d’un échec. Établissez d’abord un lien entre le Runner précis, l’Action précise et l’erreur observée.

04

Appliquez une branche de décision avant de modifier le parc

Utilisez les conditions suivantes pour éviter une migration matérielle prématurée.

  • Si le journal désigne explicitement l’initialisation ou le runtime d’une JavaScript Action, vérifiez runs.using et la version appelée. Si une version maintenue compatible avec Node 24 existe, mettez-la à l’essai dans un workflow isolé. Sinon, demandez au propriétaire de l’Action interne de mettre à jour son code et ses métadonnées, puis de publier une version contrôlée.
  • Si le journal échoue dans une commande du projet après le démarrage de l’Action, vérifiez l’installation, le chemin et la version de Node.js utilisés par cette commande. Ne remplacez pas le Runner sur la seule base de l’annonce de retrait du runtime.
  • Si l’Action candidate est compatible mais que le Runner utilise macOS 13.4 ou une version antérieure, évaluez un environnement macOS pris en charge, puis répétez le même test. Si les éléments recueillis ne montrent pas cette limite, ne généralisez pas le diagnostic à tous les hôtes Mac.
  • Si l’architecture ne correspond pas aux limites officielles, choisissez un Runner dont le système et l’architecture conviennent au job. Si aucune preuve n’indique un problème d’architecture, gardez cette piste distincte au lieu de la traiter comme une cause acquise.
  • Si les résultats restent différents entre deux runners, conservez les deux environnements en validation isolée et comparez les journaux, les références d’Action et les étapes réellement exécutées avant toute bascule générale.

Le choix entre mise à jour d’Action et ajustement du Runner dépend donc des preuves. Mettre à niveau une Action est prioritaire lorsque l’échec est rattaché à son runtime. Adapter le système ou l’architecture ne devient pertinent que si les informations recueillies montrent une incompatibilité de l’environnement. Remplacer un hôte sans cette vérification peut déplacer le problème sans le résoudre.

05

Validez la réparation avec le travail de publication réel

Un Runner affiché comme disponible ne prouve pas qu’un pipeline est rétabli. De même, une étape d’initialisation réparée ne démontre pas que l’installation des dépendances, la compilation Xcode, les tests et la publication aboutissent. Rejouez le travail concerné avec les mêmes entrées et les mêmes références, dans un environnement de validation avant de réorienter les tâches critiques.

Procédez de manière vérifiable :

  1. Conservez le journal complet de l’échec initial et relevez l’étape, l’Action et la référence précises.
  2. Enregistrez la version de macOS et l’architecture du Runner ayant exécuté le job.
  3. Testez une seule modification à la fois : version d’Action, Action interne ou environnement du Runner.
  4. Réexécutez le workflow représentatif, depuis l’initialisation des Actions jusqu’aux étapes de build et de test réellement requises.
  5. Comparez les entrées, sorties, artefacts et comportements d’échec attendus, et documentez le résultat avant l’autorisation de publication.

Pour une équipe iOS, le cas d’essai doit inclure le chemin de publication réellement utilisé, et non un workflow réduit qui s’arrête après le démarrage d’une Action. Pour une équipe macOS, vérifiez de la même manière les étapes propres à son produit. Si votre chaîne comprend des tâches de création audio ou vidéo, ou des outils de design exécutés sur macOS, ajoutez ces opérations au périmètre de validation : le succès d’une compilation iOS ne démontre pas la compatibilité de ces autres outils.

Associez ensuite une décision à l’état des preuves : autorisez la reprise si le travail critique passe et si les éléments utiles sont consignés ; suspendez l’élargissement si un contrôle clé n’a pas été exécuté ; gardez une voie isolée si la mise à jour reste en cours d’évaluation. Cette distinction évite de confondre une réparation technique probable avec une validation opérationnelle suffisante.

06

Questions fréquentes

Node 20 a-t-il été retiré de tous les usages Node.js du workflow ?

Non. Le changement annoncé par GitHub vise le runtime employé pour les JavaScript Actions sur les runners. Il ne supprime pas automatiquement le Node.js installé par une étape du workflow pour les commandes du projet. Examinez la séquence du journal et la nature de l’étape en échec avant de modifier la version de Node.js applicative.

Comment repérer une Action qui utilise encore l’ancien runtime ?

Retrouvez la référence et la version exactes appelées par le workflow, puis inspectez les métadonnées de cette version, notamment le champ runs.using. Incluez les Actions composées et les appels réutilisés depuis les modèles d’organisation. Une recherche dans le seul fichier de workflow principal ne garantit pas que toutes les dépendances effectives ont été examinées.

Faut-il migrer immédiatement tous les runners Mac ?

Non. Relevez macOS et l’architecture sur le Runner ayant exécuté le travail, puis confrontez ces données à la limite publiée pour Node 24. Si l’environnement n’est pas concerné et que l’erreur désigne une Action ancienne, traitez d’abord cette Action. Une migration de parc sans diagnostic peut accroître la charge d’exploitation tout en laissant intacte la cause.

Qu’est-ce qui permet de déclarer le pipeline rétabli ?

Le test doit atteindre les étapes qui comptent pour votre livraison : initialisation des Actions, dépendances, compilation ou tâche métier, tests et traitement des erreurs attendues. Consignez la référence d’Action, le système, l’architecture et le résultat. Un Runner simplement en ligne, ou un job qui s’arrête avant la compilation et les tests, ne constitue pas une preuve suffisante.

Pour votre parc existant, comparez le coût opérationnel de maintenir des hôtes dont le système doit rester compatible, le travail de suivi des Actions partagées et le risque de ne valider qu’une étape superficielle. Remplacer un Mac ne corrige pas une référence d’Action obsolète ; un Runner générique qui n’exécute pas vos tâches macOS ne remplace pas un environnement de build adapté. Si vous devez encore fournir un environnement macOS pris en charge à des compilations iOS critiques, évaluez une solution Mac distante après avoir défini vos besoins d’accès, de sécurité et de validation. Vous pouvez consulter les informations sur la location et les tarifs Mac, puis vérifier les conditions concrètes avant de retenir un environnement.

Si la charge est durable, intensive ou dépend d’interfaces physiques particulières, un Mac détenu et administré par votre équipe peut rester plus approprié. Si vous avez plutôt besoin d’un environnement temporaire pour valider une migration ou absorber une phase de test, examinez les options Mac proposées par VpsMesh en fonction des informations de livraison réellement disponibles. Décidez après un essai représentatif, pas sur la seule promesse qu’un changement de machine résoudra l’incident.