Coût GitHub Actions : comparer les runners par job
Découvrez pourquoi le prix à la minute ne suffit pas pour comparer les runners GitHub Actions et comment évaluer leur coût réel par job.
Runners GitHub Actions : combien coûte réellement un job CI ?
Comparer des runners « au tarif à la minute » a l'air simple. En réalité, ça ne dit pas grand-chose du coût d'une compilation, d'un test, ni d'une suite d'intégration complète. La durée varie selon la machine, et les règles de facturation peuvent aussi arrondir le temps consommé de façons différentes. Du coup, un runner plus cher à la minute peut finir par coûter moins par job s'il termine assez vite... ou pas du tout.
Le benchmark CI Bench v1 aborde justement ce point : il mesure douze jobs open source réels sur neuf configurations de runners, puis estime le coût de chaque exécution. Avec un volume de référence de 100 000 jobs par mois, plusieurs options ressortent avec un coût par job inférieur à celui d'un runner GitHub hébergé de 2 vCPU. Mais les pourcentages ne suffisent pas. La comparaison dépend aussi du modèle de facturation, des coûts fixes et du travail d'exploitation.
Voici comment interpréter ces résultats, ce qu'il faut en tirer (et ce qu'il ne faut pas), puis les précautions à prendre avant de changer votre CI.
Pourquoi le tarif à la minute ne suffit-il pas ?
Le tarif affiché est un prix unitaire, pas le coût d'un résultat livré. Pour comparer des runners, il faut regarder le coût d'une exécution complète d'un job représentatif : sa durée réelle et les règles de facturation qui s'appliquent. Cette nuance compte surtout pour les workflows courts, fréquents, ou soumis à des arrondis.
La durée d'exécution change tout
À qualité de job identique, la vitesse d'exécution n'est pas forcément la même. Une configuration plus puissante peut réduire le temps de compilation ou de test. Elle peut aussi ne rien changer si le job attend surtout le réseau, n'exploite qu'un seul cœur, ou passe une partie de son temps sur des étapes séquentielles.
La comparaison utile, c'est donc le coût par exécution, pas le prix isolé d'une minute. Un runner deux fois plus cher à la minute peut devenir intéressant s'il termine trois fois plus vite. Mais ce gain dépend de la nature du travail : améliorer une compilation ne garantit pas le même effet sur une suite de tests ou sur un déploiement.
Les règles d'arrondi pèsent sur les petits jobs
Les règles de facturation peuvent déplacer le coût des jobs courts. D'après les données de CI Bench, GitHub arrondit chaque job à la minute entière, tandis que Vitko Runners facture à la seconde. Résultat : une exécution qui ne consomme qu'une fraction de minute peut être facturée comme une minute complète chez l'un, et rester plus proche du temps réel chez l'autre.
Et cet effet se répète à chaque lancement. Sur une équipe qui exécute des milliers de petits jobs, quelques secondes d'écart peuvent vite compter plus que prévu. À l'inverse, sur des jobs qui durent déjà des dizaines de minutes, l'arrondi à la minute a souvent un impact proportionnellement plus faible.
Le « coût minute » doit être rattaché à votre activité
Un benchmark mesure des charges précises, dans des conditions précises. Votre facture dépendra de votre volume, de la répartition des jobs, et de leurs durées. Le bon réflexe est de raisonner en trois questions : combien coûte un job typique, combien ça représente par mois, et quel travail il faut pour faire tourner la solution. Le prix à la minute ne répond qu'à une partie de la première.
Que montre le benchmark sur le coût par job ?
CI Bench v1 compare douze jobs open source sur neuf configurations, puis calcule le coût de chaque exécution à partir des durées et des tarifs choisis. Les résultats sont présentés par rapport à une configuration de référence : un runner GitHub hébergé de 2 vCPU, sur un volume hypothétique de 100 000 jobs par mois.
Les économies annoncées face au runner de référence
Dans ce scénario, le benchmark affiche des écarts par rapport au runner GitHub hébergé de 2 vCPU :
- RunsOn : 88 % de coût en moins par job. Solution auto-hébergée dans le compte AWS de l'utilisateur. Le calcul annoncé exclut donc le coût de mise en place et le travail d'exploitation.
- Vitko Runners : 84 % de coût en moins. L'outil indiqué est en bêta privée, et son fondateur maintient CI Bench.
- Ubicloud : 83 % de coût en moins.
- Blacksmith : 52 % de coût en moins.
Ces chiffres ne sont pas des garanties d'économies pour toutes les équipes. Ils décrivent un coût mesuré sur un corpus de jobs, avec des tarifs et des configurations donnés. À prendre comme un signal : ce que ça vaut pour votre CI, vous le verrez en testant.
Plus puissant ne veut pas dire moins cher
Le benchmark montre aussi l'envers du décor. Un runner GitHub hébergé de 4 vCPU aurait coûté 39 % de plus par job que la configuration de référence à 2 vCPU, tout en exécutant les charges 1,6 fois plus rapidement. Autrement dit : on gagne du temps d'attente et on « revient plus vite », mais on paie davantage par exécution dans ce cadre de comparaison.
Il n'existe pas de réponse universelle. Si votre priorité est le coût direct, le runner 2 vCPU peut rester le meilleur choix. Si des pipelines plus rapides réduisent les blocages, accélèrent les corrections ou permettent davantage de déploiements, le surcoût peut être justifié - à condition de le chiffrer côté valeur métier, pas de le supposer.
100 000 jobs : utile, mais pas votre « vraie moyenne »
Le volume sert à donner une base de comparaison. Ça ne veut pas dire qu'une entreprise « type » fait exactement ce nombre, ni que tous les profils de CI se ressemblent. Le plus raisonnable est de relier ce scénario à votre historique : nombre d'exécutions mensuelles, durée médiane, part des jobs courts, et type de charges qui dominent.
Comment comparer les offres sans fausser le calcul ?
Une comparaison utile aligne des charges comparables, des règles de facturation documentées, et un périmètre de coût cohérent. Sinon, on finit vite par comparer une facture « cloud calculée » à une solution qui, elle, inclut davantage de services - ou une compilation optimisée à une suite de tests qui n'en profite pas.
Commencez par vos propres jobs
Prenez vos workflows qui représentent le cœur de votre CI. Pour chaque job, notez la durée, la fréquence, le type de charge, et les besoins particuliers : mémoire, accès réseau, dépendances système, matériel spécifique. Pas besoin de tout mesurer au millimètre dès le départ : ceux qui consomment le plus de temps et d'argent sont les meilleurs candidats.
Ensuite, comparez les mêmes versions et les mêmes étapes sur chaque configuration. Si vous changez le cache, les dépendances ou la concurrence pendant le test, il devient difficile d'attribuer le résultat au runner lui-même.
Pensez aussi à distinguer le temps du job de l'attente avant démarrage : selon la capacité disponible, l'expérience peut changer sans que le coût d'exécution mesuré soit directement différent.
Reconstituez le coût facturé
Pour chaque fournisseur, documentez au minimum :
- le tarif applicable à la configuration testée ;
- l'unité de facturation et les règles d'arrondi ;
- la durée mesurée par type de job ;
- les coûts fixes ou les prérequis de l'offre ;
- les coûts d'infrastructure qui ne figurent pas dans le tarif du runner.
Le calcul « de base » consiste à appliquer les règles de facturation à chaque durée, puis à multiplier par le nombre d'exécutions. Évitez de faire un calcul mensuel en prenant une durée moyenne unique multipliée par le prix à la minute : dès qu'il y a des arrondis job par job, ce raccourci peut sous-estimer les petits jobs.
Ajoutez les coûts absents du prix affiché
Une offre auto-hébergée peut réduire la dépense de calcul... en ajoutant du travail : configuration, mises à jour, surveillance, sécurité, gestion de la capacité, et résolution des incidents. Dans le cas de RunsOn, le benchmark précise que les frais de mise en place et d'exploitation ne sont pas inclus dans le résultat annoncé. Donc, la baisse affichée n'est pas un « coût total de possession ».
À l'inverse, une offre gérée peut coûter plus par job, mais éviter à l'équipe de maintenir des machines. Ce temps « n'apparaît » pas toujours sur la ligne de facture du runner, mais il a un coût réel. Pour comparer correctement, fixez un périmètre commun et rendez visibles les éléments exclus. C'est ce périmètre - pas la sophistication du tableur - qui détermine la qualité de la décision.
Quelle configuration choisir selon votre contexte ?
Les écarts du benchmark sont assez marqués pour justifier une évaluation, mais pas au point de forcer un basculement immédiat. Le choix dépend du volume, de la variabilité de vos charges, des compétences d'exploitation disponibles et de la valeur que vous accordez à la vitesse de livraison. Une petite équipe n'a pas forcément intérêt à gérer une flotte juste pour gratter sur la facture de calcul.
Si votre priorité est de réduire la facture
Commencez par identifier les jobs les plus fréquents et les plus longs. Le gain par job devient intéressant quand il s'applique souvent, mais il faut ensuite le confronter aux coûts fixes. Les offres avec une part fixe (ou des coûts mensuels fixes) répartissent cette dépense sur davantage de jobs : le coût moyen dépend alors du volume, comme CI Bench le souligne.
Avec 100 000 jobs par mois, un coût fixe se dilue bien. À l'inverse, sur une activité nettement plus faible, le coût par job peut monter. Autrement dit : utilisez votre volume réel plutôt que de recopier le scénario du benchmark.
Si le temps de retour développeur compte plus
L'évaluation ne devrait pas se limiter au coût par job : regardez aussi ce que vous gagnez en délai. Le benchmark illustre bien l'arbitrage avec le runner GitHub de 4 vCPU : 1,6 fois plus rapide mais 39 % plus cher par job. Pour une équipe qui attend régulièrement la fin de tests bloquants, des pipelines plus courts peuvent changer le rythme de développement. Pour un workflow nocturne ou rarement consulté, le même gain aura peut-être peu de valeur.
En pratique, mesurez ce qui compte pour l'équipe : durée du job, attente en file, et fréquence des retours. Et attention : un gain de cache ou un changement de workflow peut expliquer une partie du résultat - il ne faut pas l'attribuer automatiquement au runner.
Si vous envisagez l'auto-hébergement
L'auto-hébergement devient intéressant quand les économies potentielles sont récurrentes et que l'équipe peut réellement assumer l'exploitation. Il faut aussi clarifier la responsabilité : qui corrige les images, gère les secrets, surveille la capacité et intervient en cas de panne ? Sans propriétaire explicite, la charge opérationnelle retombe souvent sur les développeurs.
Un pilote limité aide à vérifier à la fois la facture et la charge d'exploitation avant de migrer toute la CI. Comparez le coût mesuré à la solution actuelle, puis ajoutez le temps réellement consacré à l'infrastructure. Si le gain s'évapore une fois tout comptabilisé, la solution gérée redevient souvent le choix le plus logique.
Conclusion
Le coût d'un runner GitHub Actions ne se résume pas au tarif par minute. La durée réelle, les règles d'arrondi, le volume mensuel et le travail d'exploitation déterminent ensemble le coût par job - et, au final, le coût total pour l'équipe.
CI Bench v1 met en évidence des économies potentielles face au runner GitHub hébergé de 2 vCPU, tout en montrant qu'une configuration plus rapide peut coûter davantage par exécution. Utilisez ces résultats pour lancer un test, puis mesurez vos workflows représentatifs et ajoutez explicitement les coûts exclus. C'est le seul moyen de choisir entre facture plus faible, retours développeur plus rapides et charge opérationnelle moindre.