GitHub Actions vous donne les clés du runner — mais c’est vous qui conduisez

28 octobre 2025, GitHub lance en preview publique les images de runner custom pour GitHub Actions. 26 mars 2026, la fonctionnalité passe en disponibilité générale. Avril 2026, la question n’est plus « quand ça sort » mais « qui va maintenir ces images ». GitHub vous tend les clés d’un runner sur mesure, préchauffé, zéro setup — en échange, vous héritez d’un artefact de plus à versionner, patcher et auditer. Le trade-off est clair, et il engage votre pipeline.

Le setup à chaque run, ce n’est plus tenable

Toute équipe qui fait tourner des pipelines CI/CD à l’échelle connaît la scène. Un job démarre sur un runner GitHub-hosted standard. Le workflow appelle actions/setup-node, télécharge Node.js 22, puis actions/setup-python, puis les SDKs spécifiques, puis les certificats internes, puis les binaires custom. Chaque job, chaque run, la même litanie de téléchargements. Pour un pipeline mono-langage, c’est quelques secondes. Pour un environnement polyglotte avec des dépendances lourdes — Java + Node + Python + certificats d’entreprise — le setup seul peut grignoter plusieurs minutes par exécution.

Le problème n’est pas nouveau. Les équipes qui en souffrent le plus ont déjà bricolé des solutions maison  self-hosted runners avec images préchauffées, Packer pour construire des AMI, caches agressifs de dépendances. Mais chaque bricolage ajoute de la complexité opérationnelle — un runner EC2 à maintenir, un pipeline Packer à versionner, un cache à invalider au bon moment. Ce que GitHub propose avec les images custom, c’est d’internaliser ce mécanisme dans la plateforme, sans sortir de l’écosystème Actions.

Snapshot, le mot-clé qui change tout

Le mécanisme technique tient en trois étapes.

Première étape  déployer un image-generation runner, un runner dédié dont la seule mission est de construire des images. La plateforme de ce runner doit correspondre à celle de l’image cible — Linux x64 pour du Linux x64, Linux ARM64 pour de l’ARM64, Windows x64 pour du Windows. Pas de build croisé.

Deuxième étape  exécuter un workflow contenant le mot-clé snapshot. Chaque job qui porte ce mot-clé déclenche la création d’une image distincte à partir d’une base fournie par GitHub — image curated ou OS propre. Le job installe tout ce dont les workflows suivants auront besoin  runtimes, SDKs, certificats, binaires, dépendances pré-pullées. À chaque exécution réussie, GitHub incrémente automatiquement la version mineure de l’image.

Troisième étape  créer un runner classique qui référence cette image. Deux modes de consommation coexistent  latest — le runner prend automatiquement la dernière version produite — ou pinning sur une version spécifique, pour les équipes qui veulent geler leur environnement jusqu’à validation manuelle.

# Exemple de workflow de génération d’image custom
name: Build custom runner image
on:
  schedule:
    - cron: '0 2 * * 1'   # tous les lundis à 2 h du matin
jobs:
  build-image:
    runs-on: custom-image-builder
    snapshot: true
    steps:
      - uses: actions/setup-node@v5
        with:
          node-version: '22'
      - uses: actions/setup-python@v6
        with:
          python-version: '3.12'
      - run: npm install -g pnpm@latest
      - run: apt-get update && apt-get install -y openssl ca-certificates

GitHub recommande une régénération hebdomadaire. Le rythme est sensé  une image custom qui n’est pas reconstruite accumule des dépendances obsolètes et des vulnérabilités non patchées. Une fois par semaine, le lundi à 2 h du matin, le pipeline reconstruit l’image, incrémente la version, et les runners en mode latest basculent automatiquement. Sans intervention humaine. Mais sans surveillance non plus — si le build échoue, personne ne s’en aperçoit tant qu’un pipeline métier ne casse pas.

Ce que vous gagnez  vitesse, cohérence, gouvernance

Le bénéfice immédiat est la vitesse. Un runner custom avec Node.js, Python, pnpm et les certificats d’entreprise préinstallés démarre un job sans télécharger un seul package. Sur des pipelines complexes, le gain dépasse facilement 30 à 60 secondes par job. Multiplié par des centaines d’exécutions par jour, c’est du temps CI économisé, des retours développeurs plus rapides et une facture de minutes Actions potentiellement réduite.

Le deuxième bénéfice est la cohérence. Deux développeurs qui poussent sur la même branche utilisent exactement la même image de runner — mêmes versions de Node, mêmes patches système, mêmes certificats. Plus de « ça marche sur ma machine, mais pas sur le runner GitHub ». L’environnement de CI rejoint l’environnement local dans la quête de reproductibilité.

Le troisième bénéfice est la gouvernance. Les administrateurs Enterprise Cloud peuvent gérer l’accès aux images custom et définir des politiques de rétention dans les paramètres Actions. Une image custom est un artefact auditable, versionné, dont on peut tracer l’usage projet par projet. Pour une DSI qui doit répondre à un audit de conformité, c’est un atout — les runners standard sont des boîtes noires qui changent sans préavis, les runners custom sont des artefacts maîtrisés.

Ce que vous perdez  maintenance, sécurité, lock-in

Les images custom sont exclusivement disponibles sur les larger runners — et donc réservées aux plans GitHub Team et GitHub Enterprise Cloud. Les organisations au plan Free n’y ont pas accès. C’est un premier filtre économique.

Le deuxième filtre est opérationnel. Une image custom n’est pas un fichier qu’on crée une fois et qu’on oublie. C’est un artefact vivant qui exige 

• Un pipeline de build dédié  le workflow de génération d’image consomme lui-même des minutes Actions. Son exécution hebdomadaire, ses échecs et ses logs font partie du coût opérationnel.
• Une stratégie de versioning  latest est pratique, mais dangereux — une image régénérée avec une version mineure de runtime peut casser des builds sans que l’origine soit évidente. Le pinning sur version fixe est plus sûr, mais impose un processus manuel de promotion.
• Une veille de sécurité  les dépendances installées dans l’image — Node.js, Python, packages npm globaux, binaires système — ne se mettent pas à jour toutes seules. Si personne ne suit les CVE affectant ces composants, l’image custom devient un vecteur d’attaque figé, pire qu’un runner standard qui télécharge la dernière version à chaque job.

Le troisième filtre est la portabilité. Les images custom restent confinées à l’écosystème GitHub — vous ne pouvez pas importer une AMI AWS ou une image GCP existante, ni exporter votre image custom pour l’utiliser chez un autre fournisseur CI. La base est obligatoirement une image curated par GitHub ou un OS propre fourni par GitHub. Les images sont stockées dans les paramètres Actions de l’organisation, pas dans votre container registry. Pour une équipe multi-cloud ou multi-CI, c’est un point de friction.

La concurrence n’a pas attendu

Le problème du préchauffage d’environnement est vieux comme le CI. Chaque plateforme y répond différemment.

GitLab CI adopte l’approche la plus ouverte  le fichier .gitlab-ci.yml référence n’importe quelle image conteneur, qu’elle soit hébergée sur le registre GitLab ou ailleurs. L’image est tirée au démarrage du job — pas de pipeline de génération préalable, pas de snapshot. La contrepartie, c’est que la responsabilité de l’image — construction, mise à jour, sécurité — incombe entièrement à l’équipe, sans l’intégration de gouvernance que GitHub propose. GitLab Runner supporte plusieurs types d’exécuteurs — Docker, Kubernetes, shell — et la configuration se fait dans config.toml avec un contrôle fin des politiques de pull et des credentials de registre.

CircleCI fonctionne sur deux rails. Les machine executors donnent un accès complet au système, mais les images VM custom sur le cloud de CircleCI restent une demande ancienne jamais comblée. Les Docker executors, eux, acceptent des images custom que l’équipe publie elle-même — un modèle proche de GitLab, sans la couche de gouvernance intégrée de GitHub. Pour le contrôle au niveau OS, CircleCI renvoie historiquement vers les self-hosted runners.

Jenkins reste le vétéran  tout est self-hosted, tout est customisable, rien n’est managé. Le contraste est maximal avec l’approche GitHub — Jenkins vous donne les clés depuis vingt ans, mais vous construisez aussi la serrure, la porte et l’immeuble.

Le positionnement de GitHub est donc un milieu de gamme assumé  plus intégré que GitLab, plus managé que CircleCI, infiniment plus clé en main que Jenkins. Le prix à payer est la perte de flexibilité sur la source des images et l’obligation de passer par le plan payant.

Le verdict

Si vous êtes sur GitHub Team ou Enterprise Cloud et que vos pipelines souffrent d’un setup chronique — plus de 30 secondes de setup-* par job — les images custom sont un levier immédiat de productivité. Commencez par une image mono-langage (Node.js uniquement, Python uniquement), validez la chaîne de génération, puis élargissez. Activez la régénération hebdomadaire, pinnez sur une version fixe en production et utilisez latest uniquement en staging. Une image custom sans stratégie de rollback est pire qu’un runner standard avec setup lent.

Si vous êtes sur GitHub Free, cette fonctionnalité n’existe pas pour vous. Restez sur les runners standard, investissez dans le caching (actions/cache), et évaluez les self-hosted runners si le temps de setup devient rédhibitoire.

Si vous êtes multi-CI (GitHub Actions + GitLab CI + CircleCI), les images custom GitHub sont un silo — elles ne sortent pas de l’écosystème. Privilégiez une approche Packer ou Docker multi-plateforme pour vos images de build, et consommez-les là où chaque CI le permet. N’investissez dans les images custom GitHub que si Actions est votre plateforme principale et que le gain de temps compense la duplication d’effort.

GitHub a livré la fonctionnalité que les équipes enterprise réclamaient depuis des années. Mais une image custom, c’est comme un runner self-hosted sans le métal  vous ne gérez plus la machine, mais vous gérez le logiciel qui tourne dessus. La promesse est belle — des pipelines plus rapides, des environnements reproductibles, une gouvernance centralisée. La contrepartie est honnête  un artefact de plus dans votre supply chain, avec son cycle de vie, ses vulnérabilités et son propriétaire. Ce propriétaire, c’est vous.

Références

• Custom images for GitHub-hosted runners are now generally available, GitHub Changelog, 26 mars 2026.
• Custom images for GitHub-hosted runners are now available in public preview, GitHub Changelog, 28 octobre 2025.
• GitHub Actions Custom Runner Images Reach General Availability, InfoQ, 8 avril 2026.
• GitHub Actions Runner Images, GitHub, consulté en avril 2026.
• Managing larger runners — GitHub Docs, GitHub.
• Using custom images — GitHub Docs, GitHub.
• GitHub Actions Custom Runner Images Reach General Availability: Technical Analysis, LavX News, 8 avril 2026.