Optimiser les workflows GitHub Actions

Un workflow lent, c'est du temps perdu pour toute l'équipe. Entre l'attente des résultats de tests et les déploiements qui traînent, une CI mal optimisée peut coûter des heures chaque semaine. Cette section vous montre comment réduire drastiquement le temps d'exécution de vos workflows GitHub Actions, sans rien sacrifier à la sécurité. Elle s'adresse aux débutants et intermédiaires qui ont déjà un pipeline qui tourne et veulent le rendre rapide : cache, artifacts, parallélisation et techniques de debug.

Ce que vous allez apprendre

Activer le cache des dépendances pour des installations quasi instantanées
Partager un build entre jobs avec les artifacts
Distinguer cache et artifacts pour ne pas les confondre
Paralléliser les jobs indépendants et annuler les runs obsolètes
Diagnostiquer un workflow lent ou qui ne se déclenche pas

Par où commencer ?

L'optimisation suit un ordre logique : on commence par le gain le plus rapide — le cache — puis on remonte vers les techniques structurantes.

Activez le cache des dépendances

C'est le gain le plus immédiat. Une ligne suffit pour passer de 45 secondes à 3 secondes sur l'installation des dépendances.
Partagez les résultats entre jobs avec les artifacts

Un job build crée dist/, les jobs test et deploy le réutilisent. Vous ne buildez qu'une seule fois pour tout le pipeline.
Comprenez la différence cache vs artifacts

Le cache réutilise des fichiers entre les runs. Les artifacts partagent des fichiers entre les jobs d'un même run. Confondre les deux = problèmes garantis.
Apprenez à diagnostiquer les problèmes

Workflow qui ne se déclenche pas, échecs mystérieux, lenteurs inexpliquées : les techniques de debug vous feront gagner des heures.

Guides disponibles

Chaque guide de la section traite une technique d'optimisation isolée. Voici comment ils s'articulent.

Cache : accélérer les installations

Le cache réutilise les dépendances entre les runs. Vous pushez 3 commits successifs ? Les node_modules sont téléchargés une seule fois.

Cache : les bases

Comprendre les clés, restore-keys, stratégies de cache et sécurité. Le guide complet pour maîtriser le cache GitHub Actions.

Lire le guide →

Artifacts : partager entre jobs

Les artifacts transportent des fichiers entre les jobs d'un même run. Un job build crée dist/, les jobs suivants le téléchargent. Le guide couvre upload, download, optimisations et patterns pour partager builds, rapports et binaires entre les jobs.

Lire le guide →

Déboguer un workflow

Au-delà du cache et des artifacts, le debug complète la panoplie : comprendre pourquoi un workflow ne démarre pas, échoue sans message clair ou traîne. La concurrency, autre levier, est traitée dans les gains rapides ci-dessus.

Déboguer les workflows

Workflow qui ne démarre pas ? Échec sans message clair ? Techniques de détective pour comprendre ce qui se passe sur les runners distants.

Lire le guide →

Gains rapides

Cinq optimisations couvrent la grande majorité des gains. Aucune ne demande plus de quelques lignes de YAML.

1. Activer le cache intégré

Les actions setup-* intègrent le cache en une ligne. Inutile de gérer actions/cache à la main pour les cas courants :

# Node.js
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
  with:
    node-version: '20'
    cache: 'npm'

# Python
- uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
  with:
    python-version: '3.12'
    cache: 'pip'

# Java
- uses: actions/setup-java@c5195efecf7bdfc987ee8bae7a71cb8b11521c00 # v4.7.1
  with:
    java-version: '21'
    distribution: 'temurin'
    cache: 'maven'

Gain typique : installation de dépendances de 45 s à 3 s.

2. Partager le build avec artifacts

Au lieu de rebuilder dans chaque job, buildez une fois et partagez le résultat :

jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Construire l'application
        run: npm run build
      - name: Publier le build
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: dist
          path: dist/
          retention-days: 1

  test:
    needs: build
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le build
        uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4.2.1
        with:
          name: dist
      - name: Lancer les tests
        run: npm test

Gain typique : workflow de 10 min à 6 min.

3. Annuler les runs obsolètes

Quand vous poussez plusieurs commits d'affilée, chaque push relance le workflow. Le bloc concurrency annule le run précédent :

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Gain : économie de minutes de build, surtout sur les branches actives.

4. Paralléliser les jobs indépendants

Lint, tests et build ne dépendent pas les uns des autres : ils peuvent tourner en parallèle. Seul le déploiement attend la fin de tout avec needs:.

jobs:
  lint:
    runs-on: ubuntu-24.04
    steps:
      - run: npm run lint

  test:
    runs-on: ubuntu-24.04
    steps:
      - run: npm test

  build:
    runs-on: ubuntu-24.04
    steps:
      - run: npm run build

  deploy:
    needs: [lint, test, build]  # Attend que tout soit terminé
    runs-on: ubuntu-24.04
    steps:
      - run: ./deploy.sh

Gain typique : 3 jobs séquentiels (15 min) à 3 jobs parallèles (5 min).

5. Filtrer les déclenchements

Relancer toute la CI pour un changement de README est du gaspillage. paths-ignore filtre ces déclenchements inutiles :

on:
  push:
    paths-ignore:
      - '**.md'
      - 'docs/**'
      - '.github/**'
    branches:
      - main
      - develop

Gain : moins de runs inutiles = moins d'attente et de minutes consommées.

Métriques à surveiller

Optimiser sans mesurer revient à avancer à l'aveugle. Ces cinq métriques vous disent où se situe le problème et si vos changements portent.

Métrique	Où la trouver	Objectif
Durée du workflow	Onglet Actions	< 10 min pour un workflow standard
Taux de cache hit	Logs du job	> 80 % (cache efficace)
Minutes consommées	Settings → Actions → Usage	< 50 % du quota mensuel
Temps d'installation	Logs `setup-*`	< 5 s avec cache
Taux d'échec	Insights → Actions	< 5 % (qualité stable)

Checklist d'optimisation

Parcourez cette liste avant de considérer un workflow comme prêt pour la production : chaque point coché correspond à un gain mesurable.

Cache activé pour les dépendances (cache: 'npm', cache: 'pip', etc.)
Builds partagés via artifacts (pas de rebuild inutile)
Jobs indépendants en parallèle (lint, test, build)
concurrency configuré pour annuler les runs obsolètes
Déclenchements filtrés (paths-ignore pour MD, docs...)
Permissions minimales (permissions: {} au niveau workflow, droits par job)
Durée totale < 10 min pour un workflow standard

Exemple de workflow optimisé

Voici un workflow complet qui applique toutes les bonnes pratiques de la section — et reste conforme aux règles de sécurité : actions épinglées par SHA, permissions: {} par défaut, persist-credentials: false.

name: CI/CD Optimisé

on:
  push:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'
  pull_request:

# Annule les runs obsolètes
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

# Aucun droit par défaut : chaque job demande le minimum
permissions: {}

jobs:
  # Jobs en parallèle pour gagner du temps
  lint:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Installer Node.js
        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version: '20'
          cache: 'npm'  # Cache activé
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Installer Node.js
        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false
      - name: Installer Node.js
        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      # Partage du build via artifact
      - name: Publier le build
        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
        with:
          name: dist
          path: dist/
          retention-days: 1

  # Déploiement après validation
  deploy:
    needs: [lint, test, build]
    runs-on: ubuntu-24.04
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      id-token: write  # Pour OIDC
    steps:
      - name: Récupérer le build
        uses: actions/download-artifact@95815c38cf2ff2164869cbab79da8d1f422bc89e # v4.2.1
        with:
          name: dist
      - run: ./deploy.sh

Gains de ce workflow :

Cache : installation de 45 s à 3 s
Parallélisation : lint, test et build simultanés (5 min au lieu de 15 min)
Artifacts : pas de rebuild pour le déploiement
Concurrency : annulation automatique des runs obsolètes
Filtres : pas de run sur les changements de documentation

Durée totale : environ 5 à 6 min, au lieu de 15 à 20 min sans optimisation.

À retenir

Quatre réflexes résument toute la section. Le reste n'est que de l'ajustement.

Cache = entre runs

Pour réutiliser les dépendances entre les exécutions du workflow. Gain immédiat sur npm ci, pip install, etc.

Artifacts = entre jobs

Pour partager les résultats (builds, rapports) entre les jobs d'un même run. Évite les rebuilds inutiles.

Paralléliser

Lint, test et build peuvent souvent s'exécuter en même temps. Le déploiement attend la fin avec needs:.

Annuler l'obsolète

concurrency: cancel-in-progress pour éviter de gaspiller des runners sur des commits intermédiaires.

Les 3 optimisations prioritaires :

Cache : ajoutez cache: 'npm' (ou pip, maven...) dans setup-*
Artifacts : buildez une fois, partagez avec upload-artifact / download-artifact
Concurrency : annulez les runs obsolètes automatiquement

Ces trois actions seules peuvent diviser par 2 ou 3 le temps de vos workflows.

Prochaines étapes

Accélérer avec le cache Clés, restore-keys et stratégies de cache GitHub Actions

Partager entre jobs (Artifacts) Upload, download et patterns de partage de fichiers

Artifacts vs Cache Choisir le bon mécanisme selon le besoin

Déboguer les workflows Diagnostiquer un workflow lent ou qui ne démarre pas