Runners éphémères CI/CD : utiles hors des grands groupes ?

Pourquoi le sujet revient si fort en CI/CD

Les runners éphémères ne sont plus un sujet réservé aux très grandes organisations. Avec la généralisation des pipelines sur GitHub Actions, GitLab CI/CD, Jenkins ou des plateformes self-hosted, de plus en plus d’équipes se demandent s’il faut continuer à exécuter les jobs sur des machines persistantes, ou basculer vers des environnements créés à la demande puis détruits après usage.

La promesse est simple sur le papier : un job, un environnement propre. En pratique, la décision est moins binaire. Entre sécurité, isolation, temps de démarrage, gestion du cache, coût cloud et charge d’exploitation, les runners éphémères ne sont ni une solution miracle ni un luxe réservé aux grands groupes.

Le vrai sujet, surtout en 2026, n’est pas de suivre une tendance. Il est de savoir si ce modèle répond à des problèmes concrets dans vos pipelines : dérive d’environnement, pollution entre jobs, secrets mal maîtrisés, capacité difficile à lisser, ou incidents compliqués à diagnostiquer.

Cet article prend un angle volontairement terrain : qu’est-ce que les runners éphémères changent réellement, où ils apportent un gain net, quels sont leurs coûts cachés, et dans quels cas un runner classique reste largement suffisant.

Pourquoi les runners persistants posent encore problème en 2026

Le runner persistant reste le modèle le plus simple à comprendre et souvent le plus rapide à mettre en place. Une machine virtuelle, un serveur bare metal, un conteneur longue durée ou un nœud Kubernetes exécute les jobs au fil de l’eau. Tant que les volumes sont faibles et les usages homogènes, cela fonctionne très bien.

Le problème est que ce modèle accumule souvent des compromis invisibles au début, puis coûteux à mesure que les pipelines se multiplient.

La dérive d’environnement reste un classique

Un runner persistant finit rarement dans l’état exact prévu au départ. Des dépendances s’ajoutent, des outils changent de version, des répertoires temporaires restent sur disque, des images Docker locales s’accumulent, des caches deviennent incohérents. Même avec de la discipline, l’environnement réel diverge progressivement de l’environnement documenté.

Sur le terrain, cela produit des symptômes bien connus :

• un job passe sur un runner mais échoue sur un autre ;
• une dépendance “marche” parce qu’elle est déjà présente localement ;
• un build devient non reproductible ;
• des erreurs n’apparaissent qu’après redéploiement ou remplacement du runner.

Ce n’est pas propre à un outil. On retrouve ce problème avec GitHub Actions self-hosted, GitLab Runner, Jenkins agents ou d’autres orchestrations maison.

L’isolation entre jobs est souvent imparfaite

Même quand les jobs tournent dans des conteneurs, le runner hôte reste un point sensible. Des artefacts temporaires, des credentials, des sockets Docker, des volumes montés ou des fichiers de travail peuvent survivre plus longtemps que prévu. Le risque n’est pas seulement théorique : plus un runner est partagé entre projets, branches ou équipes, plus la séparation logique devient fragile.

Les organisations qui manipulent des secrets cloud, des accès registre, des clés de signature ou des artefacts internes ont de bonnes raisons de regarder ce point de près. Le sujet est encore plus sensible si vous avez déjà engagé une démarche autour de l’OIDC en CI/CD ou de la réduction des secrets statiques : un environnement d’exécution mal isolé peut annuler une partie du bénéfice.

Le nettoyage “automatique” n’est pas toujours fiable

Beaucoup d’équipes pensent avoir réglé le sujet avec quelques scripts de cleanup. En réalité, le nettoyage post-job est l’une des zones les plus fragiles en exploitation :

• un job interrompu ne passe pas toujours par les étapes de nettoyage ;
• un disque peut saturer avant la phase de purge ;
• des conteneurs ou volumes orphelins restent présents ;
• des processus zombies ou des locks perturbent les jobs suivants.

Le résultat, ce sont des pannes intermittentes, donc coûteuses à diagnostiquer. Or une bonne partie de la dette CI/CD vient précisément de ces incidents “bizarres” qu’on ne reproduit jamais proprement.

La capacité est simple à démarrer, moins simple à faire évoluer

Un parc de runners persistants dimensionné “à peu près” suffit tant que les pics restent prévisibles. Dès que la charge varie fortement, les problèmes apparaissent :

• files d’attente sur certaines plages horaires ;
• machines surdimensionnées et sous-utilisées hors pic ;
• équipes qui se disputent les mêmes ressources ;
• besoins hétérogènes entre jobs CPU, mémoire, Docker-in-Docker, mobile ou sécurité.

Le modèle persistant n’est pas obsolète pour autant. Il reste souvent très rentable pour des pipelines stables, à faible volumétrie, sur des stacks peu variées. Mais il montre vite ses limites dès qu’on cherche plus d’isolation, plus de reproductibilité et plus d’élasticité.

Ce que changent vraiment les runners éphémères sur le terrain

Un runner éphémère est créé pour exécuter un job ou un petit lot de jobs, puis détruit. Selon les plateformes, cela peut prendre la forme d’une machine virtuelle, d’un pod Kubernetes, d’un conteneur isolé ou d’une instance cloud provisoire. Le principe clé est le suivant : on repart d’un état neuf à chaque exécution.

C’est là que le bénéfice devient concret.

Une meilleure reproductibilité des jobs

Le premier gain est souvent moins “sécurité” que fiabilité opérationnelle. Quand chaque exécution démarre depuis une image connue, versionnée et reconstruite régulièrement, les pipelines deviennent plus prévisibles.

Concrètement, cela réduit :

• les effets de bord liés à l’historique du runner ;
• les écarts entre documentation et réalité ;
• les bugs dus à des dépendances résiduelles ;
• les surprises lors du remplacement d’un nœud.

Ce point est particulièrement utile pour les équipes qui veulent des pipelines plus déterministes, dans la continuité d’approches comme les jobs idempotents ou des chaînes de build plus standardisées.

Une isolation plus nette entre projets et équipes

Le deuxième bénéfice est l’isolation. Si le runner disparaît après exécution, la surface de contamination entre jobs baisse fortement. Cela ne supprime pas tous les risques, mais cela change la posture :

• moins de persistance involontaire de fichiers ou de credentials ;
• moins de dépendance à des scripts de nettoyage ;
• moins de cohabitation longue entre workloads hétérogènes ;
• plus de facilité à raisonner par image de base, permissions et durée de vie.

Dans les environnements multi-projets ou avec des contributeurs externes, cet avantage est très concret. Il devient encore plus pertinent si vous exécutez des builds non totalement maîtrisés, par exemple sur des branches de feature nombreuses ou des dépôts où plusieurs équipes interviennent.

Une exploitation souvent plus lisible

Un runner persistant qui vit depuis des semaines mélange souvent problèmes d’infrastructure, de disque, de version d’outil et d’historique local. Avec un runner éphémère, l’état de départ est plus explicite. Si un job casse, il est plus facile de distinguer :

• un problème dans l’image de base ;
• un problème dans le pipeline lui-même ;
• un problème d’accès réseau, registre ou cloud externe.

Cela ne rend pas le debug trivial, mais cela réduit les zones grises. Et en CI/CD, réduire les zones grises vaut souvent plus qu’ajouter des couches d’outillage.

Une élasticité plus naturelle

Le modèle éphémère s’accorde bien avec l’autoscaling. Au lieu de conserver en permanence un parc de machines prêtes à absorber les pics, on peut créer de la capacité à la demande, puis la relâcher. C’est l’un des points qui explique l’intérêt croissant pour ce modèle sur les plateformes cloud et sur Kubernetes.

Dans un contexte self-hosted, cela se traduit souvent par des architectures du type :

• GitHub Actions avec autoscaling de runners self-hosted ;
• GitLab Runner avec exécuteurs basés sur Docker Machine, Kubernetes ou VM cloud ;
• agents Jenkins créés à la demande via plugins Kubernetes ou cloud providers.

Le gain n’est pas seulement financier. Il peut aussi améliorer le temps d’attente des jobs si l’orchestration est bien réglée.

GitHub Actions, GitLab et self-hosted : où en est le terrain

Le sujet n’avance pas partout de la même manière. Il faut distinguer les plateformes managées, les runners hébergés par l’éditeur et les runners self-hosted opérés par l’équipe.

GitHub Actions

Avec GitHub Actions, beaucoup d’équipes utilisent les runners hébergés par GitHub sans se poser la question des runners persistants. Mais dès qu’il faut accéder à un réseau privé, à des ressources internes, à des environnements réglementés ou à des besoins matériels spécifiques, le self-hosted revient vite dans la discussion.

Dans ce contexte, le modèle éphémère intéresse pour une raison simple : il limite les risques classiques des runners self-hosted longue durée. GitHub documente d’ailleurs les approches autour des runners auto-hébergés et de leur cycle de vie. Sur le terrain, on voit souvent des déploiements sur VM cloud ou sur Kubernetes, avec destruction après job ou après une courte fenêtre de service.

GitLab CI/CD

GitLab Runner propose depuis longtemps plusieurs exécuteurs qui permettent d’aller vers des modèles plus ou moins éphémères. Le sujet est donc moins “nouveau” techniquement que dans les usages. Ce qui change, c’est la pression croissante sur la sécurité de la supply chain, l’isolation des jobs et la maîtrise des accès cloud.

Dans GitLab, les équipes qui s’orientent vers Kubernetes ou vers des instances cloud créées à la demande cherchent souvent à résoudre trois problèmes à la fois : capacité, standardisation des environnements et réduction des runners “sales”.

Plateformes self-hosted et orchestrations maison

Hors plateformes intégrées, beaucoup d’équipes ont déjà une forme d’éphémère sans l’appeler ainsi : agents Jenkins lancés sur Kubernetes, jobs Tekton, workers créés dynamiquement sur Nomad, ou scripts Terraform qui provisionnent des machines temporaires pour certains workloads sensibles.

Autrement dit, le sujet dépasse largement l’effet de mode. Il s’inscrit dans une logique plus large : rendre l’exécution CI/CD plus jetable, plus traçable et plus facile à reconstruire.

Les coûts cachés : cache, latence, capacité et exploitation

C’est la partie que les discours trop enthousiastes oublient souvent. Oui, l’éphémère apporte de vrais gains. Mais il déplace aussi des coûts. Et si vous ne les regardez pas en face, vous risquez de dégrader l’expérience développeur tout en pensant avoir modernisé vos pipelines.

Le cache devient un sujet central

Sur un runner persistant, beaucoup de choses “vont vite” parce qu’elles sont déjà là : dépendances npm, packages Maven, couches Docker, modules Python, cache Gradle, images de build, artefacts temporaires. Avec un runner éphémère, tout cela disparaît entre deux exécutions, sauf si vous reconstruisez une stratégie de cache explicite.

Les solutions existent, mais elles demandent du travail :

• cache natif de la plateforme CI ;
• stockage objet comme Amazon S3, Google Cloud Storage ou Azure Blob Storage ;
• registry d’images comme GitHub Container Registry, GitLab Container Registry ou Harbor ;
• images de base préchauffées et versionnées ;
• cache distribué sur volumes ou services dédiés selon l’architecture.

Sans ce travail, le temps de build peut se dégrader nettement, surtout sur les projets lourds.

La latence de démarrage n’est pas neutre

Créer une VM, lancer un pod, récupérer une image, enregistrer un runner, attendre sa disponibilité, puis détruire l’ensemble a un coût temporel. Sur des jobs longs, ce coût est souvent acceptable. Sur une multitude de petits jobs, il peut devenir pénalisant.

En pratique, il faut mesurer :

• le temps de provisioning ;
• le temps de pull des images ;
• le temps de warm-up des caches ;
• la variabilité selon les heures de charge.

Une équipe qui exécute quelques gros jobs de build ou d’intégration supportera souvent bien ce surcoût. Une équipe qui lance des dizaines de jobs très courts sur chaque commit le ressentira beaucoup plus vite.

L’autoscaling ne supprime pas les problèmes de capacité

Le modèle éphémère améliore l’élasticité, mais il ne crée pas des ressources infinies. Les limites existent toujours :

• quotas cloud ;
• capacité du cluster Kubernetes ;
• débit réseau vers les registres et stockages ;
• concurrence sur les images et volumes ;
• coût des pics si le scaling est trop agressif.

Autrement dit, vous remplacez une partie du capacity planning statique par du capacity planning dynamique. C’est souvent préférable, mais ce n’est pas gratuit intellectuellement.

L’exploitation change de nature

On entend parfois que l’éphémère “réduit l’exploitation”. C’est vrai sur certains incidents de dérive locale, mais faux si l’on parle du système global. Vous gérez moins de machines sales, mais davantage de mécanismes :

• templates d’images ;
• bootstrapping ;
• inscription des runners ;
• politiques IAM ;
• observabilité du provisioning ;
• coûts d’infrastructure variables.

Le centre de gravité se déplace. Il passe du “maintenir des serveurs de CI” à “maintenir une plateforme d’exécution jetable”. Pour certaines équipes, c’est un progrès net. Pour d’autres, c’est une sophistication inutile.

Les cas où les runners éphémères apportent un vrai gain

La meilleure façon de décider est de partir des problèmes réels. Les runners éphémères ont un fort intérêt dans plusieurs situations récurrentes.

Vous avez déjà des incidents liés à la pollution des runners

Si vous passez du temps à nettoyer des disques, redémarrer des runners, comprendre pourquoi “ça marchait hier”, ou expliquer des builds qui dépendent d’un état local caché, le modèle éphémère mérite clairement d’être évalué.

Vous exécutez des jobs sensibles ou peu fiables par nature

Builds avec accès cloud, signatures, publication d’artefacts, scans de sécurité, jobs de déploiement, ou exécution de code provenant de branches nombreuses : plus l’impact d’un mauvais isolement est élevé, plus l’éphémère devient pertinent.

Ce point s’aligne bien avec les démarches autour de la supply chain logicielle, de la traçabilité et de la réduction des privilèges.

Votre charge est très variable

Si vos pipelines connaissent de gros pics suivis de longues périodes calmes, l’autoscaling associé à des runners éphémères peut améliorer à la fois l’attente des jobs et l’utilisation des ressources. C’est fréquent dans les équipes qui concentrent beaucoup d’activité sur certaines plages horaires ou lors de fenêtres de release.

Vous voulez standardiser plusieurs stacks sans multiplier les exceptions

Quand une organisation supporte plusieurs langages, plusieurs versions d’outils, des builds conteneurisés et des workflows différents, le runner persistant devient vite un compromis permanent. Des images éphémères spécialisées par type de job permettent souvent une meilleure séparation des besoins.

Quand un runner classique reste largement suffisant

Il ne faut pas transformer un bon vieux runner persistant en anti-pattern universel. Dans beaucoup de contextes, il reste le choix le plus rationnel.

Votre volumétrie est faible et stable

Si vous avez peu de projets, peu de jobs concurrents et des pipelines simples, un ou quelques runners persistants bien maintenus peuvent suffire très longtemps. Le gain marginal de l’éphémère ne compensera pas forcément la complexité ajoutée.

Vos jobs sont très dépendants du cache local

Certains builds lourds tirent un bénéfice majeur d’un cache local chaud. Si vous n’avez pas de stratégie de cache distante solide, basculer vers l’éphémère peut dégrader fortement les temps d’exécution. Dans ce cas, il vaut mieux d’abord travailler le cache, les images de base et la structure du pipeline.

Vous n’avez pas encore stabilisé les fondamentaux CI/CD

Si vos pipelines sont déjà difficiles à comprendre, peu observables ou trop couplés à des scripts fragiles, introduire des runners éphémères ne corrigera pas le fond du problème. Il vaut souvent mieux commencer par :

• clarifier les responsabilités des jobs ;
• rendre les scripts plus robustes ;
• réduire les pannes silencieuses ;
• standardiser les images et dépendances ;
• mesurer les temps d’attente, d’exécution et d’échec.

L’éphémère fonctionne bien quand le pipeline a déjà un minimum de maturité.

Votre équipe n’a pas la bande passante d’exploitation

Mettre en place un modèle éphémère sérieux demande du temps : images, sécurité, cache, observabilité, autoscaling, IAM, gouvernance. Si personne ne peut vraiment porter ce chantier, mieux vaut un runner persistant propre et surveillé qu’une pseudo-plateforme éphémère instable.

Comment décider sans effet de mode

La bonne approche n’est pas de migrer tout le parc d’un coup. Elle consiste à traiter le sujet comme une décision d’architecture opérationnelle, avec des critères simples.

Commencez par mesurer vos irritants réels

Avant toute décision, regardez les signaux suivants sur les trois à six derniers mois :

• combien d’incidents viennent de l’état des runners ;
• combien de temps d’attente subissent les jobs ;
• combien de jobs échouent pour des causes non reproductibles ;
• combien de projets partagent les mêmes runners ;
• quels jobs manipulent des accès sensibles.

Si vous n’avez pas ces données, commencez par les collecter. Sans cela, vous déciderez au ressenti.

Testez sur un périmètre ciblé

Un bon pilote concerne rarement l’ensemble des pipelines. Choisissez plutôt un cas où le bénéfice peut être visible :

• jobs de déploiement ;
• builds d’images conteneur ;
• projets multi-équipes ;
• pipelines avec incidents récurrents de pollution ;
• workloads à forte variabilité de charge.

Comparez ensuite runner persistant et runner éphémère sur quelques métriques simples : temps total, taux d’échec, effort d’exploitation, coût infra, qualité du debug.

Travaillez d’abord les images et le cache

Le succès d’un runner éphémère dépend beaucoup moins du mot “éphémère” que de la qualité de l’environnement de départ. Une image de base bien maintenue, un cache explicite et une politique de versionnement claire feront plus pour la fiabilité qu’un autoscaler spectaculaire.

Ne mélangez pas tous les objectifs

Beaucoup d’équipes veulent adopter l’éphémère pour tout résoudre à la fois : sécurité, performance, coûts, standardisation, compliance. C’est rarement réaliste. Définissez d’abord votre objectif principal :

• mieux isoler ;
• mieux scaler ;
• mieux reproduire ;
• mieux segmenter les workloads.

Le design ne sera pas le même selon la priorité.

Conclusion : utiles, oui, mais pas automatiquement

Les runners éphémères CI/CD ne sont pas un gadget réservé aux grands groupes. Ils répondent à des problèmes très concrets que beaucoup d’équipes rencontrent dès qu’elles dépassent quelques pipelines simples : dérive d’environnement, nettoyage imparfait, isolement fragile, capacité difficile à lisser et exploitation brouillée par l’historique des machines.

Pour autant, les adopter en 2026 n’a de sens que si le gain attendu est clair. Si vos runners persistants sont stables, peu partagés, bien maintenus et adaptés à votre charge, ils peuvent rester un excellent choix. À l’inverse, si vos pipelines souffrent d’incidents intermittents, de besoins de sécurité plus stricts ou de fortes variations de capacité, le modèle éphémère mérite une évaluation sérieuse.

Le plus pragmatique reste souvent une approche hybride : garder du persistant là où il est simple et rentable, introduire de l’éphémère là où l’isolation et la reproductibilité apportent un vrai retour.

Si vous êtes en train de revoir votre chaîne CI/CD sur ce point, prenez le temps de mesurer avant de migrer. Chez Pipeline Brut, c’est souvent là que se joue la différence entre une évolution utile et une couche de complexité de plus.