Martial Wehrling
← Tous les articles
Par Martial Wehrling7 min de lecture

GitHub Actions : testez Node 24 avant la bascule de juin 2026

GitHub ActionsNode.jsCI/CDDevOpsJavaScript

GitHub Actions n'est pas seulement un orchestrateur de tâches. C'est aussi un environnement d'exécution pour des actions JavaScript que beaucoup d'équipes traitent comme de l'infrastructure invisible. Cette couche va changer : GitHub prépare la migration de l'environnement des actions de Node 20 vers Node 24.

Le point important n'est pas que Node 24 existe. Le point important est opérationnel : si vos processus de production utilisent des actions JavaScript, vous avez intérêt à tester maintenant leur comportement sous Node 24, avant que cet environnement devienne celui utilisé par défaut par les agents d'exécution.

D'après le journal des modifications de GitHub Actions, Node 20 est arrivé en fin de vie en avril 2026. L'agent d'exécution v2.328.0 prend en charge Node 20 et Node 24, mais Node 20 reste le choix par défaut actuellement. GitHub indique qu'à partir du 16 juin 2026, les agents d'exécution commenceront à utiliser Node 24 par défaut pour les actions JavaScript. FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true active le test ; ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true permet une désactivation temporaire.

C'est donc une fenêtre de migration classique : suffisamment tôt pour tester proprement, suffisamment proche pour ne pas repousser le sujet au prochain incident CI.

Ce qui change vraiment

Le fait suivant est vérifié : la migration concerne l'environnement d'exécution utilisé par les actions JavaScript dans GitHub Actions. Elle ne signifie pas automatiquement que votre application Node, votre serveur, votre interface ou vos scripts npm tournent en Node 24. Ces parties dépendent toujours de vos choix explicites, par exemple actions/setup-node ou l'image de conteneur utilisée.

La zone à risque est plus discrète : les actions que vous appelez avec uses:. Une action JavaScript déclare son environnement dans son fichier action.yml ou action.yaml, grâce au champ runs.using. Les responsables de maintenance doivent migrer cette valeur vers Node 24. Les utilisateurs, eux, doivent mettre à jour les actions qu'ils consomment et tester leurs processus avec la variable de compatibilité.

Analyse : c'est typiquement le genre de changement qui casse moins souvent le code métier que les intégrations autour du code. Téléversement d'artefacts, cache, publication, déploiement, commentaires de demandes de fusion, génération du journal des modifications, authentification dans le nuage : toutes ces étapes reposent souvent sur des actions tierces. Si l'une d'elles embarque des dépendances anciennes, des hypothèses sur l'API Node, ou un binaire incompatible, le symptôme apparaîtra dans la CI, pas dans votre suite de tests locale.

Pourquoi tester maintenant

Node 24.16.0 est publié comme Krypton LTS depuis le 21 mai 2026. La page des versions précédentes de Node l'indique comme dernière version LTS au 2 juin 2026. Côté cycle de vie, le site de suivi des fins de vie indique aussi que Node 24 est en support actif jusqu'au 20 octobre 2026, puis en support de sécurité jusqu'au 30 avril 2028, tandis que le support de sécurité de Node 20 s'est terminé le 30 avril 2026.

Ces dates ne disent pas que tout votre parc applicatif doit migrer aujourd'hui. Elles disent plutôt que, pour GitHub Actions, rester silencieusement sur Node 20 n'est plus une position durable. GitHub donne une compatibilité transitoire, mais la désactivation temporaire porte un nom explicite : ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. Ce n'est pas un mode ciblé.

Node 24.16.0 apporte aussi des changements de plateforme qui peuvent avoir un impact indirect sur des actions avancées : randomUUIDv7, req.signal sur IncomingMessage, randomisation dans l'outil de test, prise en charge des temporisateurs simulés pour AbortSignal.timeout, npm 11.13.0, OpenSSL 3.5.6, undici 7.25.0 et SQLite 3.53.0. Ce ne sont pas des promesses de rupture. Ce sont des surfaces à connaître quand une action dépend fortement du réseau, de TLS, du gestionnaire npm, de tests internes ou d'API expérimentales.

Plan d'action pour les utilisateurs de processus automatisés

Commencez par identifier vos actions tierces. Dressez la liste des appels identifiés par uses: et figurant dans le répertoire .github/workflows, puis séparez les actions officielles GitHub, les actions d'éditeurs connus, les actions internes et les actions peu maintenues. Le risque n'est pas identique partout.

Ensuite, créez une exécution de test avec l'activation de Node 24. Le plus simple est d'ajouter temporairement la variable d'environnement au niveau du processus ou de la tâche concernée : env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true L'objectif n'est pas de changer toute votre stratégie Node en une fois. L'objectif est de faire tourner les mêmes processus avec l'environnement ciblé des actions JavaScript, puis d'observer les échecs. En cas de casse, notez précisément l'action, sa version, l'étape, le message d'erreur et le système d'exploitation de l'agent d'exécution.

Mettez ensuite à jour les actions. Si vous êtes bloqué par une action tierce, vérifiez s'il existe une publication récente, une branche compatible avec Node 24, ou une alternative maintenue. Pour les actions critiques en production, évitez les références flottantes si votre politique de chaîne d'approvisionnement demande de la reproductibilité ; épinglez au moins une version explicite selon vos normes internes.

Point de vigilance vérifié par GitHub : Node 24 n'est pas compatible avec macOS 13.4 ou une version antérieure dans ce contexte, et Node 24 n'a pas de support officiel ARM32. Si vos workflows couvrent ces environnements, traitez ce sujet comme une contrainte de plateforme, pas comme une simple mise à jour de dépendance.

Plan d'action pour les responsables de maintenance d'actions

Si vous maintenez une action JavaScript, le premier fichier à regarder est action.yml. La migration attendue consiste à déclarer runs.using sur Node 24. Mais ne faites pas uniquement ce changement déclaratif.

Testez l'action sur les systèmes d'exploitation que vous annoncez prendre en charge. Vérifiez les dépendances natives, les appels réseau, la gestion TLS, les usages des API fetch et undici, les scripts npm et les tests. Si votre action lance elle-même des commandes Node, distinguez bien l'environnement de l'action et la version de Node installée pour l'utilisateur.

Publiez ensuite une version claire. Mentionnez la prise en charge de Node 24, les éventuelles plateformes exclues et les changements minimaux requis. Pour une action largement utilisée, une version majeure peut être pertinente si vous abandonnez explicitement des plateformes ou comportements anciens. Si la migration est transparente, une version mineure ou corrective peut suffire selon votre versionnage sémantique et votre contrat utilisateur.

Hypothèse raisonnable : beaucoup de problèmes viendront moins de Node 24 lui-même que de dépendances vieillissantes, d'actions non republiées, ou de processus qui combinent des contraintes anciennes de système d'exploitation avec des actions JavaScript modernes. C'est pour cela qu'un test CI réel vaut mieux qu'une lecture rapide du journal des modifications.

Liste de contrôle pour la production

Pour une équipe qui livre régulièrement, cette migration doit être traitée comme un petit chantier de fiabilité CI/CD.

Le dernier point est important. Une désactivation peut sauver une livraison, mais elle ne doit pas devenir un tapis sous lequel on range la dette CI. Si elle est utilisée, ajoutez une date de retrait, un propriétaire et un ticket de suivi.

Sources

FAQ

Est-ce que mon application Node va automatiquement tourner en Node 24 dans GitHub Actions ?

Non. La migration annoncée vise l'environnement des actions JavaScript. Votre configuration détermine la version de Node utilisée par votre application, vos tests ou vos scripts, par exemple avec actions/setup-node, votre conteneur ou votre image d'agent d'exécution.

Comment tester la compatibilité avant le 16 juin 2026 ?

Ajoutez FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true dans l'environnement du processus ou de la tâche à tester, puis relancez vos processus critiques. Lisez les échecs par action appelée, pas seulement par tâche globale.

Que faire si une action tierce casse sous Node 24 ?

Cherchez une version plus récente, ouvrez un ticket avec le journal minimal, ou remplacez l'action si elle n'est plus maintenue. Pour une étape critique de publication ou de déploiement, ne découvrez pas ce problème le jour de la bascule.

Peut-on rester sur Node 20 temporairement ?

GitHub documente une désactivation temporaire avec ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true. C'est utile comme filet de secours, mais Node 20 est déjà en fin de support de sécurité selon les sources citées. Il faut donc la traiter comme une exception courte et suivie.

Les anciens agents d'exécution macOS sont-ils concernés ?

Oui, si vos workflows dépendent de macOS 13.4 ou une version antérieure. GitHub signale que Node 24 est incompatible avec macOS 13.4 ou une version antérieure dans ce contexte. Ces workflows doivent être testés et éventuellement migrés vers un environnement pris en charge.