Votre pipeline teste une application PHP et utilise une action JavaScript pour récupérer son code. Un matin, vous voyez passer l'annonce « GitHub Actions passe à Node 24 ». Faut-il migrer l'application PHP, changer le Node du build front-end, ou mettre à jour l'action ? La réponse dépend du Node qui exécute l'action, distinct des outils installés par vos étapes. Cette distinction évite une migration générale qui laisserait l'action réellement concernée intacte.
Deux environnements Node dans un même workflow
Le 23 septembre 2026, GitHub a annoncé que Node 20 n'était plus disponible sur les runners GitHub Actions pour les actions JavaScript. Ces actions utilisent désormais Node 24. La variable temporaire ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION, qui permettait auparavant une dérogation, ne fonctionne plus. GitHub demande aux auteurs d'actions JavaScript de mettre runs.using à node24 et de publier une version adaptée ; il demande aux utilisateurs de passer aux versions des actions compatibles avec Node 24.
Une action JavaScript est un composant réutilisable exécuté par le runner. Son fichier action.yml ou action.yaml indique notamment le runtime dans runs.using. Le runner est la machine qui exécute le workflow. À côté de cette action, vos étapes run: lancent leurs propres commandes : composer install, npm ci, tests, build, etc. Si une étape installe Node pour compiler vos fichiers front-end, la version choisie pour ce build appartient au projet. La bascule annoncée par GitHub ne modifie pas automatiquement votre code applicatif ni les exigences de votre hébergement.
Prenons un workflow pédagogique : une étape uses: récupère le code, une autre installe PHP, une troisième exécute les tests et une dernière installe Node pour construire des assets. La première et la deuxième peuvent appeler des actions maintenues par des tiers ; leur runtime interne relève de la migration GitHub. La dernière suit la version déclarée et testée pour le projet. Le même mot « Node » désigne donc deux décisions et parfois deux responsables.
Inventorier ce qui s'exécute réellement
Lisez tous les fichiers de .github/workflows/ et relevez les références uses:. Ajoutez les actions locales, les actions composites et les workflows réutilisables appelés depuis un autre dépôt. Une action composite peut elle-même appeler une action JavaScript ; une ligne principale apparemment simple ne suffit pas à comprendre toute la chaîne. Pour chaque référence, notez sa version ou son commit épinglé, son mainteneur, la présence d'une version compatible Node 24 et le workflow qui l'utilise.
| Élément à relever | Question utile | Preuve à garder |
|---|---|---|
| Action directe | Le mainteneur a-t-il publié une version compatible ? | Référence utilisée et métadonnée de la version cible. |
| Action indirecte | Un composant appelé par une action composite ou un workflow réutilisable dépend-il de Node ? | Arbre des appels et référence effectivement résolue. |
| Runner | Quel système et quelle architecture exécutent le job ? | Étiquette du runner, inventaire machine et exécution de qualification. |
| Commandes du projet | Quel Node le build front-end exige-t-il ? | Fichier de configuration du projet et résultat du build. |
Pour les runners auto-hébergés, vérifiez aussi la plateforme. GitHub précise dans l'annonce du 23 septembre que Node 24 est incompatible avec macOS 13.4 et les versions antérieures et ne prend pas officiellement en charge ARM32. L'avis indique que les runners auto-hébergés sur ces systèmes ou architectures ne sont plus pris en charge pour ce changement. Confrontez donc l'inventaire des machines à la documentation courante de GitHub et à un essai sur chaque famille réellement employée ; une réussite sur un runner Linux hébergé ne valide pas un parc macOS ou ARM différent.
Deux plans d'action selon votre responsabilité
Si vous maintenez l'action
Inspectez le fichier de métadonnées et ses dépendances, puis adaptez runs.using à node24 selon la syntaxe documentée par GitHub. Recréez le paquet JavaScript distribué si l'action embarque un bundle ; changer une seule ligne de métadonnée ne garantit pas que ce bundle fonctionne sous le nouveau runtime. Exécutez les tests sur les plateformes annoncées comme prises en charge, puis publiez une version identifiée avec des notes de changement. Vérifiez le comportement des entrées, sorties, téléchargements et erreurs : ce sont souvent ces contrats que les utilisateurs verront d'abord.
Si l'action n'est plus maintenue, l'équipe qui la consomme doit choisir : reprise de maintenance, alternative vérifiable, ou retrait de la fonctionnalité. Elle ne peut pas recréer la dérogation supprimée par GitHub. Le bon choix dépend du rôle de l'action et des permissions qu'elle reçoit dans le workflow.
Si vous utilisez l'action
Ouvrez une branche de qualification et mettez à jour les références concernées vers des versions annoncées compatibles. Si vous épinglez des commits pour contrôler la provenance, relevez le nouveau commit exact, vérifiez à quelle version il correspond et faites-le relire comme une dépendance. Pour une action tierce, ne concluez pas à la compatibilité à partir d'un numéro de version plus élevé seulement : regardez la métadonnée et les notes du mainteneur, puis exécutez le workflow.
Ne changez le Node des étapes run: que si le projet lui-même a une raison de migrer et des tests correspondants. Un build front-end qui tourne sous la version du projet peut continuer à l'utiliser pendant que l'action JavaScript du runner passe à Node 24. Inversement, mettre à jour le Node du build ne répare pas une action abandonnée. Pour les règles de secrets et de permissions au sein du pipeline, voir le guide Partitech sur la séparation des droits CI et npm.
Une qualification qui couvre le parcours complet
Choisissez un workflow représentatif par famille de runners et faites-lui traverser les étapes utiles : récupération du code, installation des dépendances, cache, téléchargement d'artefacts, tests, build et préparation de la livraison. Examinez les avertissements et les sorties, pas seulement le statut vert du job. Une action peut démarrer sous Node 24 et échouer plus tard sur une API, un paquet natif ou un chemin de fichier propre à un système.
Pour la partie publication, utilisez un registre ou un environnement de démonstration et des identifiants factices. Contrôlez que les secrets restent absents des journaux et que les permissions du workflow correspondent à l'opération prévue. Conservez la référence de l'exécution, le runner, les versions d'actions et le résultat de chaque étape. Si un chemin est impossible à tester, documentez cette limite et désignez la personne qui la lèvera avant généralisation. Aucun résultat de compatibilité n'est présumé ici.
La bascule est en vigueur au 1er octobre 2026 selon l'annonce GitHub. Le travail immédiat consiste à distinguer les actions JavaScript des commandes du projet, à identifier les références et plateformes réellement utilisées, puis à qualifier les mises à jour sur ces plateformes. Le passage réussi d'un workflow ne couvre que sa configuration et son runner : gardez cette portée explicite lorsque vous validez le parc.