Top 7 des GitHub Actions à connaître absolument en 2025 (1/2)

GitHub Actions est aujourd’hui l’outil d’automatisation le plus utilisé par les développeurs. Mais devant la masse d’actions disponibles (plus de 15 000 sur la marketplace !), difficile de savoir lesquelles sont vraiment indispensables pour tes projets.

👉 Dans cet article, je t’explique :

• Ce que sont les GitHub Actions et pourquoi elles sont essentielles.
• Quelles sont les actions les plus utilisées dans la majorité des projets modernes, et comment les utiliser
• Pour chaque action : un exemple YAML et un cas d’usage réel.

📚 Pour ceux qui aiment lire la doc officielle

• GitHub Docs – Actions
• GitHub Marketplace – Actions
• actionlint pour valider tes workflows

⚡️ Résumé express

• ✅ 1 Github Action est une brique prête à l’emploi que tu vas utiliser pour automatiser tes CI/CD, pour réaliser un checkout du projet, ou pour installer node dans ta CI par exemple
• ✅ Ces actions sont dispos sur la marketplace github
• ✅ Elles sont gratuites, open source, et maintenues par GitHub et la communauté, ce qui garantit leur fiabilité et leur mise à jour régulière
• ✅ Tu l'as compris ce sont des accélérateurs qui vont te faire gagner un temps considérable

Les actions de ce classement couvrent à elles seules 90% des besoins. Et si tu ne trouves pas ton bonheur, tu as toujours la possibilité de créer une action personnalisée.

• actions/checkout
  👉 Récupérer le code source du repo
  🔹 Typiquement : 100% des workflows
  🔗 actions/checkout

• actions/setup-*
  👉 Installer un langage/runtime (setup-node, setup-python, setup-java, setup-go, etc.)
  🔹 Typiquement : JS/TS, Python, Java, Go, .NET…
  🔗 actions/setup-*

• actions/cache
  👉 Mettre en cache les dépendances
  🔹 Typiquement : accélérer npm install, pip install, gradle build, etc.
  🔗 actions/cache

🐙 GitHub Actions, c’est quoi exactement ?

Une Action est une brique réutilisable (officielle ou communautaire) qui réalise une tâche bien précise dans un workflow CI/CD : cloner le repo, installer un langage, mettre en cache des dépendances, déployer sur un serveur…

Un workflow GitHub Actions est un enchaînement d’actions et de commandes, défini dans un fichier YAML (.github/workflows/ci.yml).

• Un workflow = le scénario global d’automatisation.
• Un job = un ensemble de steps exécutés sur un runner.
• Un step = une commande ou une action.
• Une action = une tâche prête à l’emploi que tu ajoutes dans un step.

👉 Exemple : au lieu d’écrire un script maison pour cloner ton repo, tu ajoutes simplement :

YAML
- uses: actions/checkout@v5

Sans ces Actions :

• tu devrais tout coder toi-même (checkout, install, cache, upload…),
• tes workflows seraient plus longs, plus fragiles,
• et tu perdrais la sécurité et la maintenance offertes par les actions maintenues par GitHub et la communauté.

Bref : les Actions sont aux workflows ce que les librairies npm/pip sont au code: un énorme gain de temps et de fiabilité.

🌀 1 - Récupérer le code (actions/checkout@v4)

Doc officielle : actions/checkout

Cette action clone le repo et par défaut elle se positionne sur :

• le commit de l’événement qui a déclenché le workflow (ex : dernier commit de main si l’événement est un push sur main, ou le commit d’une PR si l’événement est pull_request).
• 👉 ce n’est pas une action pour “choisir une branche” mais pour récupérer l’état du repo au moment de l’événement.

YAML
- name: Checkout repo
  uses: actions/checkout@v5
  with:
    fetch-depth: 0 # Récupère tout l’historique + tags atteignables

YAML
- name: Checkout repo
  uses: actions/checkout@v5
  with:
    fetch-depth: 0
    ref: feature/add-login-form # Pour se positionner spécifiquement sur cette branche

Options

Option	Valeur par défaut	Description
fetch-depth	1	Nombre de commits récupérés. 1 = dernier commit uniquement (rapide, sans tags). 0 = tout l’historique + tags atteignables.
fetch-tags	false	Récupère aussi les tags. ⚠️ Ne fonctionne que si fetch-depth ≠ 1.
ref	(événement)	Branche, tag ou SHA à checkout. Par défaut : commit de l’événement déclencheur (push, PR, dispatch…).
persist-credentials	true	Laisse le token GitHub dans .git/config. À mettre sur false si tu veux éviter les push involontaires.
sparse-checkout	(vide)	Liste de dossiers à cloner (utile en monorepo).
submodules	false	Récupère aussi les submodules (true ou recursive).
lfs	false	Télécharge aussi les fichiers Git LFS.

Cas d'utilisation

Release avec changelog (tags + historique complet).

Indispensable pour semantic-release, git describe, changelogs basés sur l’historique.

YAML
- uses: actions/checkout@v5
  with:
    fetch-depth: 0 # Historique complet
    fetch-tags: true # Récupérer tous les tags

Workflow manuel sur une branche spécifique

Utile avec workflow_dispatch (run manuel) pour tester une branche précise sans risquer de push.

YAML
- uses: actions/checkout@v5
  with:
    ref: feature/add-login-form # Forcer la branche
    persist-credentials: false # Sécurité : évite les push involontaires

Monorepo : Monorepo avec clone partiel

Clone rapide, uniquement les dossiers nécessaires à la CI (idéal en monorepo Nx/Turborepo).

YAML
- uses: actions/checkout@v5
  with:
    fetch-depth: 1
    sparse-checkout: |
      apps/web
      packages/shared
    sparse-checkout-cone: true

Bonnes pratiques

• ✅ fetch-depth: 0 si un outil lit l’historique (changelog, releases, Sonar)
• ✅ git fetch --tags si ton workflow dépend des tags
• ✅ ref: pour forcer une branche/commit précis (utile en manuel ou PR)
• ✅ persist-credentials: false pour éviter les push involontaires
• ✅ sparse-checkout pour monorepos (cloner seulement les dossiers utiles)

Bref, sans checkout, aucun workflow ne démarre. C’est LE point d’entrée de tous tes jobs.

📦 2 - Préparer ton environnement (actions/setup-*)

Doc officielle : setup-node, setup-python, setup-java,...

Avant de lancer un build, ton runner GitHub Actions est une machine “vide”. Il ne sait pas quelle version de Node, Python ou Java utiliser. Les actions setup-\* sont là pour préparer ton environnement : elles installent le bon langage, la bonne version.

Astuce : active toujours l’option cache, tes builds passent de plusieurs minutes à quelques secondes. La clé de cache est calée sur le package-lock.json ou le requirements.txt ou le pom.xml ou le go.mod... Ainsi tout changement dans les dépendances réinitialise le cache.

YAML
- name: Setup Node.js
  uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm

Options utiles

Option	Description
node-version / python-version / java-version…	Choisir précisément la version
cache (ex. npm, pip, maven)	Accélérer les builds en réutilisant le cache du gestionnaire de paquets
distribution (Java)	Choisir une distribution JDK (Temurin, Zulu…)

Cas d'utilisation

JS/TS : Installer Node.js et npm

YAML
- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: npm
- run: npm ci && npm test

Python : Installer Python et pip

YAML
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: pip
- run: pip install -r requirements.txt

Java : Installer Java et Maven

YAML
- uses: actions/setup-java@v4
  with:
    java-version: '21'
    distribution: 'temurin'
    cache: maven

Go : Installer Go

YAML
- uses: actions/setup-go@v5
  with:
    go-version: '1.22'
    cache: go

.NET : Installer .NET SDK et restaurer les dépendances

YAML
- uses: actions/setup-dotnet@v4
  with:
    dotnet-version: '8.0.x' # ou '6.0.x' si LTS
    cache: true # active le cache NuGet
- run: dotnet restore
- run: dotnet build --configuration Release --no-restore
- run: dotnet test --no-build --verbosity normal

Bonnes pratiques

• ✅ Toujours épingler une version précise (20, 3.12, 21) pour éviter qu’une mise à jour mineure ne casse ton workflow.
• ✅ Activer le cache pour gagner en rapidité (npm, pip, maven, gradle…) et diminuer le temps de CI.

💾 3 - Le cache sur mesure (actions/cache)

Doc officielle : actions/cache

À la différence du cache intégré aux actions setup-\*, ici c’est toi qui décides quoi mettre en cache et comment. Avec actions/cache, tu as un contrôle total :

• tu choisis les dossiers ou fichiers à conserver entre deux runs (dépendances, artefacts de build, caches applicatifs…),
• et tu définis tes propres clés pour gérer leur durée de vie.

YAML
- uses: actions/cache@v4
with:
  path: ~/.npm
  key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
  restore-keys: |
    ${{ runner.os }}-node-
    ${{ runner.os }}-

🎯 Rôle de restore-keys

Quand tu définis un cache avec actions/cache, tu fournis une clé: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} dans l'exemple ci-dessous

• Si la clé correspond à un cache existant, il est restauré automatiquement depuis l’infrastructure de GitHub (et extrait dans le runner)
• Si la clé ne correspond pas, GitHub essaie les restore-keys dans l’ordre (si définis). Cela permet de réutiliser un cache partiel au lieu de repartir de zéro.
• Si rien ne correspond, aucun cache n’est restauré

YAML
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Restore npm cache
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
            ${{ runner.os }}-

      - name: Install deps (rebuild si miss)
        run: npm ci

      - name: Tests
        run: npm test

Généralement, la step de cache est suivie d'une step d'installation des dépendances qui va installer les dépendances si elles ne sont pas déjà présentes dans le cache.

YAML
- name: Restore npm cache
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-
      ${{ runner.os }}-

- name: Install deps (rebuild si miss)
  run: npm ci

Et à la fin du job, une fois touts les étapes exécutées, comme par magie actions/cache se relance et sauvegarde le cache.

✅ Cette approche à 2 avantages :

• Gain de temps même si tes dépendances évoluent.
• Tu réutilises un cache “proche” plutôt que de tout réinstaller.

Quelle différence entre actions/cache et l'option de cache dans setup-\* ?

En 2 mots: actions/cache te permet de cacher ce que tu veux, alors que setup-\* te permet de cacher uniquement les dépendances du langage.

Fonctionnalité	actions/setup-*	actions/cache
Dépendances du langage (npm, pip, maven…)	✅ Automatique	✅ Possible, mais à configurer
Génération des clés de cache	✅ Automatique (basé sur lockfile)	❌ À définir manuellement
Mise en place	✅ Ultra simple (1 option cache)	❌ Plus complexe (paths, clés, restore-keys)
Cacher d'autres dossiers/fichiers	❌ Non	✅ Oui, libre choix
Contrôle sur la stratégie de cache	❌ Minimal	✅ Total (clé, granularité, durée)
Granularité (OS, version, hash, etc.)	❌ Non	✅ Oui (tu définis la clé)

Exemple d’utilisation avec Next.js / React

Documentation officielle Next.js sur le cache CI

YAML
uses: actions/cache@v4
with:
  # See here for caching with `yarn`, `bun` or other package managers https://github.com/actions/cache/blob/main/examples.md or you can leverage caching with actions/setup-node https://github.com/actions/setup-node
  path: |
    ~/.npm
    ${{ github.workspace }}/.next/cache
  # Generate a new cache whenever packages or source files change.
  key:
    ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts',
    '**/*.tsx') }}
  # If source files changed but packages didn't, rebuild from a prior cache.
  restore-keys: |
    ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-

Bonnes pratiques

• ✅ Clé de cache unique et stable : combine l’OS + la version du langage + un hash de fichier de lock.
• ✅ restore-keys : toujours prévoir une clé partielle pour réutiliser un cache proche (ex : même OS mais fichier lock modifié).
• ✅ Vérifie que tu ne caches pas des dossiers trop volumineux au risque de ralentir au lieu d’accélérer.

Résumé :

• Utilise le cache intégré à setup-* si tu veux un gain rapide et simple.
• Utilise actions/cache si tu as besoin de contrôle précis (ex. cacher .next/cache, venv, target/), ou pour des écosystèmes non couverts par setup-*.

Conclusion

On a vu ensemble les 3 premières briques incontournables :

• ✅ actions/checkout pour récupérer ton code,
• ✅ actions/setup-* pour préparer ton environnement,
• ✅ actions/cache pour accélérer tes builds.

👉 Ces trois-là couvrent déjà une grosse partie des besoins CI/CD de base (cloner, installer, optimiser). Sans elles, impossible d’avoir une pipeline moderne et performante.

Dans la partie 2, on verra les Actions qui font passer tes workflows au niveau supérieur :

• partage d’artefacts entre jobs,
• build et déploiement (Docker, GitHub Pages…),
• intégrations tierces (Slack, Codecov, Terraform…),
• et même du code JavaScript embarqué directement dans tes workflows.

⚡️ Bref, la suite va t’apprendre à livrer, déployer et monitorer ton code comme les pros.

❓ FAQ Express

Faut-il toujours épingler une version d’action (@v4, @v5) ?

Oui car ces actions sont en constante évolution et une mise à jour peut casser ton workflow.
👉 Bonne pratique : toujours pointer vers une version stable.

Est-ce que les GitHub Actions sont gratuites ?

• Oui, sur les dépôts publics (minutes illimitées).
• Sur les dépôts privés, tu as un quota selon ton plan GitHub, puis facturation à l’usage.

Puis-je créer ma propre Action si elle n’existe pas ?

Oui. Tu peux créer :

• une JavaScript Action (rapide, portable),
• ou une Docker Action (si tu as besoin d’un environnement complet).

Comment trouver la bonne Action dans la marketplace ?

Vérifie :

• le nombre de téléchargements et d’étoiles,
• la date de la dernière mise à jour,
• si elle est maintenue par GitHub ou par un éditeur reconnu.

Quelle est la différence entre un step et une action ?

• Un step = une instruction dans ton job (peut être une commande run ou une action).
• Une action = une tâche réutilisable, appelée dans un step via uses:.

Quelle est la durée de vie d’un runner GitHub Actions ?

• Chaque job s’exécute dans un runner éphémère (machine virtuelle ou conteneur).
• À la fin du job, le runner est détruit : tous les fichiers sont perdus (sauf ceux mis en cache ou uploadés en artefacts).
• 👉 Si tu veux partager des données entre jobs, utilise actions/cache ou upload-artifact.

Comment déboguer un workflow qui échoue ?

• Active le mode debug : ACTIONS_STEP_DEBUG: true.
• Ajoute run: env pour inspecter les variables.
• Teste localement avec act si besoin.

Où est stocké le cache ?

Sur les serveurs GitHub Actions, lié à ton dépôt (pas sur le runner, qui est éphémère).

Combien de temps dure un cache ?

7 jours après sa dernière utilisation. Chaque restauration ou mise à jour prolonge la durée de vie.

Quelle taille maximale ?

10 Go par cache. Le total par dépôt est aussi limité à 10 Go : les plus anciens sont supprimés automatiquement.

Peut-on partager un cache entre dépôts ?

Non. Le cache est strictement lié à un dépôt.

Quelle différence avec le cache de setup-_ ?

setup-\_ gère uniquement les dépendances d’un langage avec un cache automatique. actions/cache te donne un contrôle total : tu décides quoi cacher (dossiers, artefacts, binaires…) et comment gérer les clés.