GitHub Actions lent : pourquoi, et comment ne plus tout refaire

L'essentiel d'une tâche GitHub Actions lente se passe avant le premier test. Installer Node, télécharger les dépendances, construire l'image Docker : les mêmes minutes, à chaque push, pendant que quelqu'un de votre équipe attend une coche verte. Avec une facturation à la minute, vous payez aussi ces minutes-là.

Skipbox est un exécuteur GitHub Actions qui garde sa machine entre les tâches : ce qu'une tâche a installé est encore sur le disque pour la suivante. Modifiez une ligne, runs-on: skipbox, et la tâche s'exécute sur votre propre machine pour un prix fixe de $39 par mois avec des minutes illimitées.

Chaque tâche démarre sur une VM vierge

Un exécuteur hébergé par GitHub est une nouvelle machine virtuelle pour chaque tâche. Rien de ce que la tâche précédente a téléchargé ou construit n'y figure : chaque tâche reconstruit donc le même état.

Les trois premières lignes ne produisent rien de nouveau. Elles remettent la machine dans l'état où elle était la veille.

Le cache de GitHub atténue le problème sans le changer. Il contient 10 Go par dépôt, supprime les entrées qu'aucune tâche n'a lues depuis 7 jours, et une nouvelle branche de fonctionnalité ne peut pas lire le cache d'une autre branche de fonctionnalité. Même quand le cache est trouvé, chaque exécution télécharge et décompresse une archive.

Ce que l'attente vous coûte

Supposons que la préparation prenne 3 minutes par tâche et que votre équipe exécute 100 tâches par jour. Cela fait 300 minutes de temps d'exécuteur par jour passées à remettre la machine en état, et chaque pull request attend sa part. Les revues commencent plus tard, les fusions arrivent plus tard, et les développeurs passent à autre chose en attendant.

Avec une facturation à la minute, ces minutes figurent sur la facture. Un exécuteur 4 vCPU, selon les minutes mensuelles :

Les montants GitHub correspondent à la facture après l'utilisation incluse de GitHub Team. Entrez vos propres minutes dans le calculateur de la page d'accueil, sans connexion.

Et le nombre d'exécutions ne fait qu'augmenter :

• Les agents de code IA. Chaque push d'un agent lance la CI. L'attente et la facture augmentent avec les push, pas avec les effectifs.
• Plus de tests. Une suite E2E ou une matrice répète la préparation dans chaque tâche qu'elle ajoute.
• Les budgets. Plafonnez la facture avec un budget GitHub : les tâches ne démarrent plus en milieu de mois, ce qui bloque les fusions.

Accélérer soi-même, c'est un projet

Garder les exécuteurs hébergés par GitHub et les rendre rapides veut dire prendre en charge un travail comme celui-ci :

• Construire les clés de cache sur les empreintes des lockfiles et régler les restore-keys jusqu'à ce que le cache soit trouvé
• Ajouter buildx et exporter le cache de Docker avec cache-to, dans les mêmes 10 Go
• Répartir les tests en shards, où chaque shard répète la préparation et où les minutes facturées augmentent
• Ou faire tourner votre propre exécuteur auto-hébergé : provisionnement, mises à jour de l'OS, nettoyage entre les tâches, et réparation quand il tombe

Chacune de ces solutions contourne une machine qui oublie tout. Skipbox garde la machine : vous n'avez besoin d'aucune d'elles.

Ce qui change avec Skipbox

La préparation reste sur le disque. Vos tâches s'exécutent sur la machine propre à votre compte, et elle reste entre les tâches. Les images Docker, les couches et le cache de build ; les caches de paquets de npm, pip, Gradle et d'autres ; les outils qu'installent setup-node et consorts. Au moins 7× l'espace de cache de GitHub, sans expiration au bout de 7 jours et sans règle de branche.

Des machines plus grandes à prix fixe. Les compilateurs et les lanceurs de tests démarrent un worker par cœur : plus de cœurs raccourcissent les étapes limitées par le CPU.

Les minutes sont illimitées sur tous les forfaits. Les tâches Skipbox n'utilisent aucune minute GitHub : un budget GitHub ne les arrête jamais.

Aucune machine à surveiller. Skipbox provisionne la machine, met à jour l'OS et les outils, nettoie après chaque tâche, lance un contrôle d'intégrité et reconstruit une machine qui y échoue.

Le passage tient en une ligne

jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Connectez-vous à Skipbox avec GitHub.
2. Installez l'application GitHub Skipbox et choisissez les dépôts.
3. Modifiez runs-on et faites un push.

Ce que la première tâche installe est sur le disque pour la deuxième.

Sécurité

• La machine appartient à votre seul compte. Aucune tâche d'une autre entreprise n'y tourne.
• Après chaque tâche, les identifiants de l'exécuteur, ses processus et ses conteneurs sont effacés. À partir du 13 novembre 2026, votre checkout et sa sortie de build (le target/ de Cargo) restent sur votre propre machine pour vos tâches suivantes ; « Nouvelle VM pour chaque tâche » donne une nouvelle machine à chaque tâche.
• Le code des personnes sans accès en écriture (comme les pull requests venant de forks) s'exécute sur une nouvelle machine jetable.

Les détails sont dans Comment les tâches sont isolées.

Essayez-le sur votre tâche la plus lente

L'essai est gratuit pendant 7 jours ou 3 000 minutes de tâches, selon ce qui arrive en premier, et ne demande pas de carte. Passez votre tâche la plus lente sur runs-on: skipbox, exécutez-la deux fois de suite et comparez la durée des étapes avec celle de GitHub.

Mis à jour le 11 novembre 2026