GitHub Actions : migrer vos actions vers Node 24

La migration vers Node 24 dans GitHub Actions est désormais un prérequis, pas une optimisation à remettre à plus tard. GitHub a retiré Node 20 de ses runners : les actions JavaScript s’exécutent maintenant avec Node 24, et l’option temporaire qui permettait de conserver une version non sécurisée a disparu. Pour une équipe produit, le sujet consiste à vérifier les dépendances de livraison avant qu’une mise à jour d’infrastructure ne transforme un pipeline en incident.

Ce que change Node 24 dans GitHub Actions

GitHub demande aux mainteneurs d’actions JavaScript de déclarer node24 dans runs.using, puis de publier une nouvelle version de leur action. Pour les équipes qui consomment des actions, l’action concrète est différente : mettre à jour vers une version compatible des actions utilisées dans les workflows. Les actions GitHub maintenues en interne doivent donc être examinées séparément des actions tierces référencées par version.

Cette évolution ne concerne pas le runtime de votre application déployée. Elle concerne le runtime qui exécute le code JavaScript des actions dans votre chaîne CI/CD. Cette distinction évite de modifier un produit en production alors que le vrai travail porte sur le dépôt d’automatisation, ses dépendances et ses images de runners.

Un inventaire court avant toute modification

Repérer les deux familles d’actions

Commencez par lister les fichiers .github/workflows, puis distinguez les actions appelées par uses: des actions JavaScript que votre organisation maintient. Pour une action interne, ouvrez son action.yml ou action.yaml et contrôlez la valeur de runs.using. Pour une action externe, consultez la release compatible Node 24 et mettez à jour la référence selon votre politique de versions.

1. Cartographiez les workflows critiques. Priorisez ceux qui livrent en production, signent des artefacts ou manipulent des secrets.
2. Mettez à jour dans une branche dédiée. Gardez le changement de runtime lisible et évitez de le mélanger à une évolution fonctionnelle.
3. Exécutez le parcours réel. Une validation de syntaxe YAML ne confirme ni les permissions, ni les artefacts, ni les intégrations externes.
4. Documentez les exceptions. Si une action n’est plus maintenue, choisissez explicitement entre remplacement, fork maintenu ou suppression du flux.

Ne pas oublier les runners auto-hébergés

GitHub précise que Node 24 n’est pas compatible avec macOS 13.4 et les versions antérieures, et ne prend pas officiellement en charge ARM32. Les runners auto-hébergés sur ces plateformes ne sont donc plus supportés dans ce contexte. C’est un contrôle d’infrastructure à planifier avec la même rigueur que la mise à jour des actions : système d’exploitation, architecture, capacité de remplacement et fenêtre de retour arrière.

Une équipe peut réduire le risque en testant d’abord un runner représentatif, sur un workflow non destructif et avec des artefacts faciles à vérifier. Le résultat attendu n’est pas seulement un job vert : il faut confirmer que les tests, signatures, caches, déploiements de préproduction et notifications donnent le résultat habituel.

Faire de la migration Node 24 un contrôle de livraison

Le changelog officiel de GitHub confirme le retrait de Node 20 et les adaptations attendues. Traitez cette migration comme une petite revue de fiabilité : inventaire, compatibilité, exécution représentative et décision d’infrastructure. Vous réduisez ainsi le risque de découvrir une dépendance oubliée au moment où la livraison devient urgente.