5 alternatives à GitHub Actions pour les équipes frontend

Les meilleures alternatives à GitHub Actions pour les équipes frontend sont CircleCI pour une CI entièrement hébergée, Buildkite pour un plan de contrôle hébergé qui pilote des agents hébergés ou auto-hébergés, Jenkins et Woodpecker CI pour une CI entièrement auto-hébergée, et Dagger pour des pipelines sous forme de code qui s’exécutent de la même façon sur un ordinateur portable et dans n’importe quelle CI.

Le déclencheur est généralement une facture gonflée par les minutes de runner, une pull request qui attend dans une file d’attente, ou un workflow qui échoue uniquement sur les runners de GitHub et jamais sur votre machine. Cet article part du principe que vous connaissez déjà le modèle de workflow de GitHub Actions. Il compare cinq options selon trois mêmes critères : à qui chacune s’adresse, où ses jobs s’exécutent, et à quoi ressemble un job d’installation, de lint, de test et de build pour un frontend Node.

Pourquoi les équipes frontend cherchent-elles des alternatives à GitHub Actions ?

Les équipes frontend quittent généralement GitHub Actions pour l’une de ces quatre raisons : les minutes de runners hébergés coûtent trop cher, les runners hébergés restent bloqués dans une file d’attente, elles ont besoin d’exécuter des agents sur leur propre matériel, ou elles ne parviennent pas à reproduire un pipeline CI/CD en local. Vérifiez la deuxième raison avant de migrer. Si l’attente des runners hébergés est votre seul problème, les runners auto-hébergés de GitHub Actions peuvent le résoudre sans changer d’outil. GitLab CI/CD ne vaut vraiment la peine d’être envisagé que si vous comptez également y migrer vos dépôts ; sa mise en place est détaillée dans GitLab CI/CD pipelines.

Pour que la comparaison soit équitable, placez la logique de build dans package.json afin que chaque outil de CI appelle les mêmes scripts :

{
  "scripts": {
    "lint": "eslint .",
    "test": "vitest run",
    "build": "vite build"
  }
}

Remplacez ces commandes par celles de votre framework. Dans chacun des exemples ci-dessous, la configuration de CI n’a qu’une seule tâche : exécuter npm ci, puis ces trois scripts.

Buildkite

Buildkite convient aux équipes qui veulent une orchestration hébergée tout en gardant la main sur les machines qui exécutent leurs jobs. Buildkite prend en charge les deux modèles : des agents que vous exécutez vous-même et des agents hébergés par Buildkite. Les agents Linux hébergés par Buildkite sont disponibles sur toutes les offres, y compris l’offre Free, limitée à la plus petite taille de machine. Les agents macOS hébergés par Buildkite nécessitent une offre Pro ou Enterprise. Les agents auto-hébergés interrogent Buildkite pour récupérer du travail, vous n’avez donc aucun port entrant à ouvrir. Buildkite propose un compte gratuit pour démarrer.

# .buildkite/pipeline.yml
steps:
  - label: "Install, lint, test, build"
    commands:
      - npm ci
      - npm run lint
      - npm test
      - npm run build
    plugins:
      - docker#v5.14.0:
          image: "node:<your-node-version>"

Le plugin Docker exécute les commandes dans une image Node, si bien que l’agent n’a besoin que de Docker. Si Node est déjà installé sur l’agent, vous pouvez supprimer le bloc plugins.

Verdict : Buildkite est le choix idéal si vous voulez maîtriser votre infrastructure de calcul sans faire tourner de serveur de CI. La contrepartie : vous gérez la flotte d’agents, sauf si vous utilisez des agents hébergés.

CircleCI

CircleCI convient aux équipes qui veulent un service entièrement hébergé avec un minimum d’infrastructure. CircleCI est avant tout un service hébergé, mais il propose aussi des runners auto-hébergés sur toutes les offres, y compris l’offre Free. Par défaut, votre code s’exécute sur l’infrastructure de CircleCI. L’introduction à la configuration de CircleCI indique que la version 2.1 est la plus récente.

# .circleci/config.yml
version: 2.1

jobs:
  build:
    docker:
      - image: cimg/node:<full.node.version>
    steps:
      - checkout
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

workflows:
  ci:
    jobs:
      - build

Épinglez cimg/node sur la version complète de Node utilisée par votre projet. CircleCI prend également en charge la mise en cache des dépendances, mais celle-ci a été omise ici pour garder l’exemple concis. Les erreurs de YAML sont une cause fréquente d’échec lors d’un premier push sur CircleCI ; il est donc utile de passer le fichier dans le validateur YAML d’OpenReplay pour repérer les erreurs de syntaxe avant de commiter.

Verdict : CircleCI est le remplaçant le plus direct de GitHub Actions. Il est pertinent si les minutes et les files d’attente posent problème, mais que vous ne souhaitez toujours pas gérer de serveurs.

Jenkins

Jenkins convient aux équipes soumises à des exigences strictes d’hébergement sur site (on-premises) et disposant de quelqu’un qui a le temps de le maintenir. Jenkins est exclusivement auto-hébergé. Le logiciel est libre et gratuit, mais le coût se déplace de la facturation à la minute vers les serveurs, les plugins et les mises à jour que votre équipe doit maintenir. Les pipelines sont définis dans un Jenkinsfile écrit avec la syntaxe déclarative de Pipeline :

pipeline {
    agent any
    stages {
        stage('Install') { steps { sh 'npm ci' } }
        stage('Lint')    { steps { sh 'npm run lint' } }
        stage('Test')    { steps { sh 'npm test' } }
        stage('Build')   { steps { sh 'npm run build' } }
    }
}

agent any suppose que Node est installé sur l’agent, quel qu’il soit, qui prend en charge le job.

Verdict : ne choisissez Jenkins que si l’auto-hébergement est une exigence incontournable. Pour la plupart des équipes frontend, la maintenance coûte plus cher que les minutes économisées.

Woodpecker CI

Woodpecker CI convient aux petites équipes qui veulent une CI auto-hébergée et légère, avec un YAML familier. Woodpecker CI est auto-hébergé, et chaque étape exécute ses commandes dans le conteneur spécifié pour cette étape, comme le décrit la syntaxe des workflows. Les workflows peuvent être placés dans un répertoire .woodpecker/, à raison d’un workflow par fichier.

# .woodpecker/ci.yaml
steps:
  - name: install
    image: node:<your-node-version>
    commands:
      - npm ci
  - name: lint
    image: node:<your-node-version>
    commands:
      - npm run lint
  - name: test
    image: node:<your-node-version>
    commands:
      - npm test
  - name: build
    image: node:<your-node-version>
    commands:
      - npm run build

Répartir le travail en quatre étapes ne signifie pas installer quatre fois les dépendances. Les étapes s’exécutent séquentiellement par défaut, et l’espace de travail récupéré (checkout) est monté dans chaque étape : le dossier node_modules créé par install est donc toujours présent dans build. Avec woodpecker-cli et un backend compatible installés, vous pouvez exécuter un workflow en local avec woodpecker-cli exec avant de le pousser.

Verdict : pour l’auto-hébergement, Woodpecker CI est une option plus simple que Jenkins. L’inconvénient : vous devez faire tourner vous-même le serveur et les agents.

Dagger : des pipelines sous forme de code, pas un service de CI

Dagger n’est pas un service de CI hébergé et n’en remplace pas un. Vous écrivez le pipeline sous forme de code avec un SDK Dagger, et ce même code s’exécute sur un ordinateur portable comme dans n’importe quel système de CI, GitHub Actions compris. La documentation des SDK couvre Go, Python, TypeScript, Java, PHP et Elixir, ainsi que Dang, le langage de script propre à Dagger. Voici le même job en TypeScript, à l’aide d’un module créé avec dagger init --sdk=typescript --name=frontend-ci :

import { dag, Directory, object, func } from "@dagger.io/dagger"

@object()
class FrontendCi {
  @func()
  async check(source: Directory, nodeVersion: string): Promise<string> {
    return await dag
      .container()
      .from(`node:${nodeVersion}`)
      .withMountedDirectory("/src", source)
      .withWorkdir("/src")
      .withExec(["npm", "ci"])
      .withExec(["npm", "run", "lint"])
      .withExec(["npm", "test"])
      .withExec(["npm", "run", "build"])
      .stdout()
  }
}

Exécutez-le en local avec dagger call check --source=. --node-version=<your-node-version>. Votre job de CI existant se contente alors d’exécuter cette même commande, et rien d’autre. Si une exécution locale réussit, l’exécution en CI enchaîne exactement les mêmes étapes de conteneur. Le prix à payer : un SDK et un moteur supplémentaires à maîtriser pour l’équipe.

Ces commandes concernent Dagger 0.x. Dagger 1.0, annoncé en bêta en octobre 2026, les renomme : dagger module init crée un module, et dagger call devient dagger api call. Le code TypeScript, lui, reste identique.

Comment choisir une alternative à GitHub Actions ?

La bonne alternative à GitHub Actions dépend de l’endroit où vous souhaitez exécuter vos jobs :

• Si vous voulez une CI entièrement hébergée, sans rien à exploiter, optez pour CircleCI. Sa configuration est très proche de ce que vous avez déjà.
• Si vous voulez une orchestration hébergée sur vos propres machines ou sur celles du fournisseur, optez pour Buildkite, surtout si vous avez besoin de builds macOS.
• Si l’auto-hébergement est obligatoire et que vous disposez des ressources humaines pour le maintenir, optez pour Jenkins.
• Si l’auto-hébergement est obligatoire et que vous voulez une solution légère, optez pour Woodpecker CI.
• Si le vrai problème est « ça marche en local, mais ça échoue en CI », ajoutez Dagger, en conservant l’un des outils ci-dessus, ou GitHub Actions lui-même, comme exécuteur.
• Si le seul problème est le temps d’attente, essayez d’abord les runners auto-hébergés de GitHub Actions.

Le backend Docker de Woodpecker et Dagger nécessitent tous deux un runtime de conteneurs. Si Docker Desktop ne convient pas à vos machines, Dagger fonctionne aussi avec Podman et nerdctl, et Woodpecker peut s’exécuter sur Kubernetes ou directement sur l’hôte grâce à son backend local.

Quel que soit l’outil choisi, commencez par déplacer toute la logique de build dans des scripts npm. Testez ensuite le remplaçant sur une seule branche, en parallèle de GitHub Actions, et comparez les résultats pendant une semaine avant de basculer.

FAQ

GitHub facture-t-il à la minute l'utilisation des runners auto-hébergés dans GitHub Actions ?

Non. GitHub ne facture pas de frais à la minute pour l'utilisation des runners auto-hébergés : le coût se limite aux machines sur lesquelles vous les exécutez. En décembre 2025, GitHub a annoncé des frais de plateforme de 0,002 dollar US par minute pour les runners auto-hébergés à compter du 1er mars 2026, avant de reporter cette mesure afin de réévaluer son approche. Consultez la documentation de facturation de GitHub Actions avant de fonder une comparaison de coûts sur l'un ou l'autre de ces chiffres.

Puis-je exécuter un job CircleCI en local avant de le pousser ?

Oui, un job à la fois. La CLI CircleCI exécute un seul job dans Docker sur votre machine avec circleci local execute. Les workflows ne s'exécutent pas en local, et l'exécuteur machine n'est pas pris en charge. Pour une configuration en version 2.1, exportez d'abord la configuration traitée avec circleci config process, puis passez ce fichier à circleci local execute à l'aide de l'option -c et du nom du job.

Woodpecker CI fonctionne-t-il avec des dépôts hébergés sur GitHub ?

Oui. Woodpecker prend en charge GitHub, y compris GitHub Enterprise, ainsi que GitLab, Gitea, Forgejo et Bitbucket Cloud. Vous enregistrez une application OAuth sur la forge, puis transmettez son client ID et son secret au serveur Woodpecker via des variables d'environnement telles que WOODPECKER_GITHUB_CLIENT et WOODPECKER_GITHUB_SECRET. Les dépôts restent sur GitHub, Woodpecker y remonte le statut des pipelines, et seuls le serveur et les agents s'exécutent sur votre infrastructure.

Comment exécuter une fonction Dagger depuis un workflow GitHub Actions existant ?

Ajoutez, après actions/checkout, une étape qui utilise l'action officielle dagger/dagger-for-github. Cette action installe la CLI Dagger, démarre un Dagger Engine sur le runner et appelle votre fonction. Définissez verb sur call et passez les mêmes arguments qu'en local, par exemple check avec votre répertoire source et votre version de Node. La logique du pipeline reste dans le module : quitter GitHub Actions plus tard ne modifiera donc que cette fine surcouche.