Le choix entre runners hébergés (GitHub-hosted, GitLab SaaS) et runners auto-hébergés se discute souvent comme un calcul de coût pur, ce qui manque le critère qui tranche le plus souvent en pratique : l’accès réseau, pas le prix à la minute.

Ce qu’un runner hébergé ne peut structurellement pas atteindre

Un runner GitHub-hosted ou GitLab SaaS s’exécute sur une infrastructure entièrement externe, sans aucune route réseau vers votre réseau interne. Un pipeline qui doit déployer sur un cluster Kubernetes on-premise, interroger une base de données derrière un VPN, ou pousser une image vers un registre privé sans exposition publique se heurte à un mur : aucune configuration de pipeline ne contourne l’absence de connectivité réseau.

# GitHub Actions : le runner self-hosted s'inscrit comme
# n'importe quel autre, la différence est où le processus tourne
runs-on: [self-hosted, linux, internal-network]

Un runner auto-hébergé, installé sur une machine (ou un pod Kubernetes) à l’intérieur du réseau qu’il doit atteindre, résout ce problème par construction : il est déjà là où le déploiement doit avoir lieu, sans tunnel ni exposition supplémentaire à négocier.

Le coût réel, dans les deux sens

Un runner hébergé facture à la minute consommée, un modèle qui devient cher rapidement pour des builds fréquents ou longs (compilation lourde, suites de tests étendues), sans plafond naturel autre que la facture elle-même. Un runner auto-hébergé déplace ce coût vers l’infrastructure qui le fait tourner et le temps d’exploitation qui va avec : dimensionnement, mise à jour de l’image de base, gestion de la file d’attente quand plusieurs pipelines se déclenchent en même temps. Pour une équipe qui a déjà l’infrastructure et la compétence Kubernetes (un cluster autoscaler qui provisionne des runners éphémères à la demande, par exemple), ce coût marginal reste faible ; pour une équipe qui partirait de zéro, il ne l’est pas.

Le risque de sécurité inversé

Un runner auto-hébergé introduit un risque spécifique que les runners hébergés éliminent par construction : un pipeline CI qui exécute du code non fiable (une PR externe, une dépendance compromise) tourne alors à l’intérieur du réseau qu’il n’aurait jamais dû pouvoir atteindre, ce qui transforme un risque de supply chain (couvert dans l’article sur la provenance SLSA) en risque d’intrusion réseau directe. Les runners hébergés, isolés par défaut, encaissent ce risque à la place de votre infrastructure ; les runners auto-hébergés le déplacent chez vous, à charge pour l’équipe de l’isoler correctement (namespace dédié, NetworkPolicy restrictive, jamais de runner partagé entre PR de contributeurs externes et déploiement de production).

L’approche hybride, la plus fréquente en pratique

Peu d’organisations tranchent entièrement d’un côté. Un modèle courant : runners hébergés pour tout ce qui ne touche à rien d’interne (lint, tests unitaires, build d’image publique), runners auto-hébergés réservés au périmètre qui a réellement besoin d’accès réseau interne (déploiement, tests d’intégration contre une base interne). Cette segmentation limite la surface exposée par les runners auto-hébergés au strict nécessaire, plutôt que d’en faire le chemin par défaut de tout le pipeline.

À retenir

Le critère qui décide entre runners hébergés et auto-hébergés est d’abord l’accès réseau requis, pas le coût à la minute : un runner hébergé ne peut structurellement pas atteindre une infrastructure interne, quel que soit le prix payé. Le coût se déplace, il ne disparaît jamais, vers l’infrastructure et le temps d’exploitation côté auto-hébergé. Le risque de sécurité s’inverse aussi : un runner auto-hébergé mal isolé transforme un risque de supply chain en accès réseau direct, un arbitrage qui fait partie de ce qui se pose dès l’industrialisation d’une chaîne CI/CD.