GitHub Actions commence à durcir les règles pour les runners self-hosted qui ne sont plus suffisamment à jour. Le premier brownout pour GitHub Enterprise Cloud intervient le 24 août 2026, avec une conséquence très concrète : certains runners obsolètes peuvent ne plus s’enregistrer ou exécuter leurs jobs correctement. Pour les équipes qui reposent sur GitHub Actions en CI/CD, une mise à jour oubliée peut donc finir par bloquer toute une chaîne.
Les runners self-hosted doivent désormais respecter une version minimale
GitHub impose maintenant une version minimale à ses runners self-hosted.
Pour enregistrer ou réenregistrer un runner, il faut utiliser au minimum la version 2.329.0. Mais cette exigence ne s’arrête pas là.
Les runners doivent également rester à jour dans les 30 jours suivant la publication de chaque nouvelle version.
Le changement est important.
GitHub ne se contente plus d’afficher un avertissement lorsqu’un runner prend du retard. Une version trop ancienne peut désormais empêcher le runner de fonctionner normalement.
Un runner obsolète peut laisser les workflows en attente
Les conséquences peuvent rapidement devenir visibles dans une chaîne CI/CD.
Un runner trop ancien peut échouer lors de son enregistrement, ne plus récupérer de nouveaux jobs ou laisser certains workflows bloqués dans la file d’attente.
Dans certains cas, les exécutions peuvent tout simplement échouer.
C’est particulièrement sensible dans les entreprises qui utilisent des runners self-hosted pour compiler, tester ou déployer leurs applications sur leur propre infrastructure.
Un seul composant oublié peut alors ralentir tout le pipeline.
Les images de VM et les scripts d’installation sont aussi à vérifier
Mettre à jour le runner installé sur une machine ne suffit pas toujours.
Les équipes doivent également contrôler les images de machines virtuelles, les conteneurs et les scripts utilisés pour créer automatiquement de nouveaux runners.
Un script qui télécharge encore une version figée et trop ancienne peut recréer le problème à chaque nouveau déploiement.
Même chose pour les images de VM préparées plusieurs semaines ou plusieurs mois auparavant.
Trois points méritent donc une attention immédiate : la version du runner, les images servant à le déployer et les mécanismes d’installation automatisée.
Le calendrier de blocage s’étend jusqu’au 25 septembre
Le premier brownout pour GitHub Enterprise Cloud est programmé le 24 août 2026.
D’autres périodes de blocage doivent ensuite avoir lieu les 31 août, 2 septembre, 7 septembre, 9 septembre, 11 septembre, 14 septembre, 16 septembre et 18 septembre.
L’application complète de cette nouvelle politique est prévue pour le 25 septembre 2026.
Il reste donc peu de marge.
Pour les équipes qui utilisent GitHub Actions avec leur propre infrastructure, vérifier maintenant la version des runners peut éviter de découvrir le problème au moment où un build ou un déploiement critique refuse soudainement de démarrer.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
