GitHub Actions : le guide CI/CD pour bien démarrer

Entre le moment où vous écrivez une ligne de code et celui où elle rend service à un utilisateur, il y a une succession de gestes : tester, vérifier, emballer, livrer. Tant qu’on les fait à la main, ils sont lents, oubliés un jour sur deux, et source d’erreurs. GitHub Actions automatise toute cette chaîne, directement depuis votre dépôt : à chaque commit, une suite d’instructions s’exécute sur des machines fournies par GitHub, et votre code part en production sans que vous touchiez un terminal. Ce guide pose la carte complète du domaine — les concepts, le vocabulaire, l’anatomie d’un pipeline — et vous oriente, étape par étape, vers six tutoriels pratiques qui construisent ensemble un vrai pipeline d’intégration et de déploiement continus.

🎯 Ce que ce parcours vous permettra de faire

• Écrire des workflows GitHub Actions valides et lisibles, déclenchés par les bons événements.
• Mettre en place une intégration continue qui teste votre code à chaque commit et bloque toute régression.
• Couvrir plusieurs versions d’un langage avec une matrice, et accélérer vos pipelines avec le cache.
• Gérer des secrets sans jamais les exposer, et protéger la production par une approbation humaine.
• Construire une image Docker dans le pipeline et la publier sur un registre.
• Déployer automatiquement sur un serveur, vérifier que le service répond, et revenir en arrière en cas de problème.

🗺️ Parcours d’apprentissage

Ce parcours construit, tutoriel après tutoriel, le pipeline complet d’une petite API REST baptisée Récolte — un service qui enregistre les livraisons d’une coopérative agricole. On part de zéro et on monte la chaîne maillon par maillon. Suivez les six étapes dans l’ordre : chacune s’appuie sur la précédente.

1. Créer son premier workflow — comprendre l’anatomie d’un fichier YAML et obtenir son premier pipeline vert.
2. Automatiser ses tests — lancer la suite de tests à chaque commit et bloquer les pull requests qui cassent.
3. Matrice de tests et cache — tester sur plusieurs versions de Node et diviser le temps d’exécution.
4. Secrets et environnements — manipuler des valeurs sensibles proprement et protéger la production.
5. Construire et publier une image Docker — conteneuriser l’API et la pousser sur un registre.
6. Déploiement continu sur un VPS — livrer l’image sur un serveur, avec vérification et rollback.

Pourquoi la CI/CD est devenue incontournable

Deux sigles reviennent sans cesse : CI et CD. L’intégration continue (CI, Continuous Integration) consiste à fusionner souvent le travail de chacun dans une branche commune, en vérifiant automatiquement à chaque fois que rien ne casse. La livraison ou le déploiement continu (CD, Continuous Delivery/Deployment) prolonge l’idée : une fois le code validé, il est emballé et livré jusqu’en production de façon automatisée. L’enjeu n’est pas la mode, mais la réduction du risque. Plus on intègre par petits morceaux vérifiés, plus les bugs sont attrapés tôt, quand ils coûtent peu ; plus on attend, plus une régression peut se cacher longtemps et exploser au pire moment.

Avant la CI/CD, le scénario classique était le « ça marchait sur ma machine » : du code testé localement, fusionné à la va-vite, qui se révélait cassé pour le voisin ou en production. La CI tue ce scénario en exécutant les tests sur une machine neutre et reproductible, à chaque proposition de modification. Et le déploiement manuel — se connecter au serveur, copier des fichiers, redémarrer un service, en croisant les doigts — laisse place à un processus traçable, répétable et réversible. Pour une équipe, c’est moins de stress et plus de vélocité ; pour un développeur solo, c’est un filet de sécurité qui ne dort jamais.

Le fond du sujet est une question de boucle de rétroaction. Le coût d’un bug croît avec le temps qu’on met à le détecter : repéré à l’instant où on l’écrit, il se corrige en quelques minutes, le contexte encore frais en tête ; découvert deux semaines plus tard en production, il demande de rouvrir un code qu’on a oublié, de reproduire le problème, parfois sous la pression d’utilisateurs bloqués. La CI raccourcit cette boucle au maximum : la machine teste pendant que vous passez à autre chose, et vous prévient en quelques minutes si quelque chose casse. Ce n’est pas une contrainte de plus, c’est un gain de temps net sur la durée du projet — d’autant plus précieux pour un développeur seul, qui n’a personne pour relire à sa place.

GitHub Actions a rendu cette pratique accessible à tous parce qu’elle vit là où le code vit déjà. Pas de serveur d’intégration à installer et maintenir, pas d’outil tiers à brancher : un dossier .github/workflows/ dans votre dépôt suffit. Sur un projet open source ou public, l’exécution est même gratuite et illimitée sur les machines standard de GitHub. Cette intégration native explique pourquoi GitHub Actions s’est imposé comme la porte d’entrée la plus directe vers la CI/CD moderne.

Les concepts fondamentaux

Tout GitHub Actions tient dans une poignée de notions qui s’emboîtent. Les maîtriser, c’est lire et écrire n’importe quel workflow sans se perdre.

L’événement : ce qui déclenche tout

Rien ne se passe sans un événement. Un push de commits, l’ouverture d’une pull request, une heure programmée façon cron, la publication d’une release, ou un lancement manuel depuis l’interface : chaque workflow déclare, sous la clé on, les événements auxquels il réagit. Le choix de l’événement détermine quand votre automatisation s’exécute. Tester sur les pull requests attrape les régressions avant la fusion ; déployer sur un push vers la branche principale livre la version validée. C’est le premier réglage à penser, car il définit le rythme de toute la chaîne.

Le workflow : la recette complète

Un workflow est un fichier YAML rangé dans .github/workflows/. Il décrit, de haut en bas, ce qui doit se passer quand un événement survient. Un dépôt peut en contenir plusieurs — un pour les tests, un pour la construction d’image, un pour le déploiement — qui s’exécutent indépendamment ou s’enchaînent. Le YAML, sensible à l’indentation, demande de la rigueur : deux espaces par niveau, jamais de tabulation. C’est la principale source d’erreurs des débutants, et la première chose à vérifier quand un workflow refuse de démarrer.

Le job et le runner : où le travail s’exécute

Un workflow contient un ou plusieurs jobs. Chaque job s’exécute sur un runner : une machine virtuelle neuve, créée pour l’occasion et détruite à la fin. GitHub fournit des runners Linux, Windows et macOS ; ubuntu-latest, le plus courant, correspond aujourd’hui à Ubuntu 24.04. Point crucial à intégrer une fois pour toutes : chaque job part d’une machine vierge, qui ne connaît rien de votre projet. C’est pourquoi un job commence presque toujours par récupérer le code du dépôt. Par défaut, les jobs d’un même workflow tournent en parallèle ; on les met en séquence avec la clé needs quand l’un dépend du résultat d’un autre.

Le step et l’action : les gestes élémentaires

Dans un job, on enchaîne des steps. Un step est soit une commande shell, introduite par run, soit l’appel d’une action réutilisable, introduit par uses. Une action est une brique packagée et versionnée, publiée sur le GitHub Marketplace, que l’on compose plutôt que de la réécrire : actions/checkout pour cloner le dépôt, actions/setup-node pour installer Node, docker/build-push-action pour construire une image. On épingle toujours une version (@v6) pour la stabilité. Cette distinction run contre uses — exécuter une commande contre composer une brique — est le réflexe de lecture le plus utile pour décoder un workflow.

Secrets, permissions et environnements : le contrôle

Un pipeline manipule des valeurs sensibles : jeton de registre, clé de déploiement, URL de base de données. GitHub les stocke chiffrées sous forme de secrets, accessibles via ${{ secrets.NOM }} et masqués dans les journaux. Il fabrique aussi à chaque exécution un GITHUB_TOKEN temporaire, dont on restreint les permissions au strict nécessaire. Enfin, les environnements (comme production) ajoutent des règles de protection — approbation manuelle, délai d’attente, branches autorisées — pour qu’aucun déploiement sensible ne parte sans contrôle. Ces trois notions forment la couche de sécurité du pipeline, traitée en détail dans le tutoriel dédié.

Vue d’ensemble pratique : l’anatomie d’un pipeline

Un pipeline CI/CD complet n’est qu’un assemblage ordonné des briques ci-dessus. Voici la trajectoire type d’un commit, du clavier à la production — chaque maillon correspond à un tutoriel de cette série.

1. Le déclenchement et la vérification de base

Tout commence par un workflow déclenché sur push et pull_request. Le premier job récupère le code, installe l’environnement, et lance une vérification minimale. C’est la fondation : un pipeline qui tourne, un rond vert qui apparaît. Le tutoriel Créer son premier workflow construit cette base et explique l’anatomie du fichier YAML, les événements et la lecture des journaux d’exécution.

2. Les tests, gardiens de la qualité

Vient ensuite le cœur de la CI : exécuter la suite de tests à chaque modification. Un test qui passe en local ne suffit pas ; il doit passer sur la machine neutre du runner, à chaque commit, pour tout le monde. Et surtout, un échec doit empêcher la fusion d’une pull request — c’est la protection de branche. Le tutoriel Automatiser ses tests branche la suite de tests, met en place ce verrouillage et conserve un rapport de test en artefact téléchargeable.

3. La couverture multi-versions et la vitesse

Votre code doit tourner sur plusieurs versions du langage et plusieurs systèmes. Plutôt que de dupliquer les jobs, on utilise une matrice qui démultiplie un même job sur une liste de valeurs. Et comme multiplier les jobs allonge l’attente, on met en cache les dépendances pour ne pas tout réinstaller à chaque fois. Le tutoriel Matrice de tests et cache couvre strategy.matrix, les options fail-fast, include et exclude, et les deux façons de mettre les dépendances en cache.

4. Les secrets et la protection de la production

Dès qu’on approche de la livraison, il faut des valeurs sensibles : un jeton pour publier, une clé pour déployer. On les range en secrets chiffrés, on bride les permissions du jeton automatique, et on protège la production derrière un environnement qui exige une approbation. Le tutoriel Secrets et environnements traite tout cela, jusqu’à l’authentification OIDC sans mot de passe pour les déploiements cloud.

5. L’emballage : construire et publier l’image

Pour livrer du code de façon reproductible, on l’emballe dans une image Docker. Le pipeline la construit à chaque version et la publie sur un registre — ici ghcr.io, intégré à GitHub. Le tutoriel Construire et publier une image Docker écrit le Dockerfile, se connecte au registre avec le jeton automatique, génère des tags propres et accélère les builds avec le cache de couches.

6. La livraison : déployer, vérifier, revenir en arrière

Dernier maillon : l’image arrive sur un serveur et y tourne. Le pipeline se connecte au VPS par SSH, tire la nouvelle image, redémarre le service — après votre approbation — puis vérifie que l’API répond. Et si quelque chose cloche, on sait revenir à la version précédente en quelques secondes. Le tutoriel Déploiement continu sur un VPS boucle la chaîne, du git push au conteneur en production.

Le pipeline assemblé, en un coup d’œil

Pris séparément, les six maillons peuvent sembler indépendants. Voici comment ils s’articulent dans un même pipeline, une fois la chaîne montée. La clé qui les relie est needs : elle force un ordre — on ne construit que si les tests passent, on ne déploie que si l’image est prête.

name: Pipeline Récolte

on:
  push:
    branches: [main]

jobs:
  tests:                 # 1. la CI : tests sur la matrice de versions
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [22, 24, 26]
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with: { node-version: "${{ matrix.node-version }}", cache: npm }
      - run: npm ci
      - run: npm test

  image:                 # 2. l'emballage : ne part que si les tests passent
    needs: tests
    runs-on: ubuntu-latest
    permissions: { contents: read, packages: write }
    steps:
      - uses: actions/checkout@v6
      - uses: docker/login-action@v4
        with: { registry: ghcr.io, username: "${{ github.actor }}", password: "${{ secrets.GITHUB_TOKEN }}" }
      - uses: docker/build-push-action@v7
        with: { context: ".", push: true, tags: "ghcr.io/${{ github.repository }}:main" }

  deploiement:           # 3. la livraison : sous approbation, après l'image
    needs: image
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: appleboy/ssh-action@v1.2.5
        with:
          host: "${{ secrets.VPS_HOST }}"
          username: "${{ secrets.VPS_USER }}"
          key: "${{ secrets.VPS_SSH_KEY }}"
          script: "cd /opt/recolte && docker compose pull && docker compose up -d"

Lisez ce fichier comme une histoire en trois actes. Le job tests vérifie le code sur trois versions de Node, avec cache. Le job image ne démarre qu’après — needs: tests — et n’emballe donc jamais du code défaillant ; il se connecte au registre avec le jeton automatique et pousse l’image. Le job deploiement attend à son tour l’image (needs: image), se rattache à l’environnement production protégé par approbation, et livre sur le serveur. Chaque détail de ces trois actes — la matrice, les permissions, les secrets, le déploiement — est déplié dans le tutoriel correspondant. Ce squelette est la carte ; les tutoriels sont le terrain.

Tutoriels de la série

Chaque tutoriel ci-dessous construit une brique du pipeline de l’API Récolte. Suivez-les dans l’ordre pour monter la chaîne complète.

• Créer son premier workflow GitHub Actions — anatomie du YAML, événements, premier pipeline vert.
• Automatiser ses tests avec GitHub Actions — tests à chaque commit, protection de branche, artefacts.
• Matrice de tests et cache — tester sur plusieurs versions, accélérer le pipeline.
• Secrets et environnements — valeurs sensibles, permissions, approbation manuelle, OIDC.
• Construire et publier une image Docker — Dockerfile, ghcr.io, tags automatiques, cache de build.
• Déploiement continu sur un VPS — déploiement SSH, vérification de santé, rollback.

Au-delà du pipeline de base : ce qui vous attend ensuite

Une fois la chaîne en place, GitHub Actions offre des leviers pour aller plus loin sans tout réécrire. Les workflows réutilisables (déclenchés par workflow_call) permettent de factoriser un pipeline commun à plusieurs dépôts, appelé comme une fonction. Les actions composites regroupent plusieurs steps récurrents en une brique maison, que vous publiez et réutilisez. La clé concurrency annule automatiquement une exécution devenue obsolète quand un nouveau commit arrive, ce qui économise des minutes et évite les déploiements qui se chevauchent. Et les environnements peuvent porter des règles de plus en plus fines à mesure que l’équipe grandit. Ces sujets ne sont pas indispensables pour démarrer, mais ils deviennent précieux dès que plusieurs projets ou plusieurs personnes partagent les mêmes pipelines.

Adaptation au contexte ouest-africain

GitHub Actions est l’un des rares outils de niveau professionnel dont le coût d’entrée est nul si l’on s’y prend bien. Sur un dépôt public, les minutes d’exécution sont illimitées et gratuites sur les runners standard : on peut faire tourner une CI complète depuis Dakar, Cotonou, Bamako ou Niamey sans dépenser un franc. Pour un dépôt privé, le plan gratuit inclut 2 000 minutes par mois, largement suffisant pour un projet personnel ou un petit collectif — et le cache des dépendances permet d’en consommer bien moins.

L’autre atout décisif, quand la machine de travail est modeste ou la connexion capricieuse, c’est que le gros œuvre se passe sur les serveurs de GitHub, pas chez vous. Installer un environnement, lancer des tests, construire une image Docker : tout s’exécute sur un runner distant, à pleine bande passante. Vous ne poussez que votre code source — quelques kilo-octets — et le pipeline fabrique des artefacts de dizaines de méga-octets sans toucher à votre forfait Internet. Un vieux portable suffit pour piloter une chaîne CI/CD complète.

Côté déploiement, la combinaison registre d’images + VPS reste la plus accessible : pour le prix d’un petit serveur mensuel, on obtient un déploiement continu de qualité professionnelle, sans cloud managé facturé à la fonction ni verrou propriétaire. Et l’approbation manuelle d’environnement laisse au responsable la main sur le moment exact de la mise en production, depuis son téléphone si besoin — précieux quand on n’est pas toujours devant un poste fixe.

Erreurs fréquentes à éviter

FAQ

Quelle différence entre CI et CD ?
La CI (intégration continue) vérifie automatiquement chaque modification : tests, qualité, compilation. La CD (livraison/déploiement continu) prolonge la chaîne jusqu’à la mise à disposition du code — emballage et déploiement automatisés. La CI protège la qualité ; la CD accélère la livraison.

GitHub Actions est-il gratuit ?
Oui sur les dépôts publics : minutes illimitées sur les runners standard. Sur les dépôts privés, le plan gratuit offre 2 000 minutes par mois, avec des multiplicateurs selon le système (Windows et macOS consomment plus vite que Linux).

Faut-il connaître Docker pour utiliser GitHub Actions ?
Non pour la CI (tests, vérifications) : Docker n’est pas requis. Il le devient pour les deux derniers maillons — construire une image et la déployer. Notre guide Docker pour débutants couvre les bases nécessaires.

Par quel tutoriel commencer ?
Par Créer son premier workflow. Les six tutoriels forment une progression : chacun suppose le précédent. Sauter directement au déploiement sans avoir posé les tests et les secrets mène à la confusion.

GitHub Actions remplace-t-il Jenkins ou GitLab CI ?
Il joue le même rôle, avec l’avantage d’être intégré à GitHub : rien à héberger. Jenkins reste pertinent pour des besoins très spécifiques ou auto-hébergés ; GitLab CI est l’équivalent pour qui héberge son code sur GitLab. Les concepts (jobs, étapes, runners) se transposent d’un outil à l’autre.

Peut-on utiliser GitHub Actions pour autre chose que du déploiement ?
Oui. On automatise aussi l’étiquetage des issues, l’envoi de notifications, la génération de documentation, des tâches programmées façon cron, la publication de paquets. Tout événement sur un dépôt peut déclencher une automatisation.

Pour aller plus loin

• Maîtriser les fondations : notre série Git & GitHub — la CI/CD repose sur un usage solide des branches et des pull requests.
• Comprendre les conteneurs : notre guide Docker pour débutants, indispensable pour les tutoriels d’image et de déploiement.
• Angle PME et projets web : nos tutoriels complémentaires GitHub Actions pour une PME et CI/CD pour projets web.
• Documentation officielle : docs.github.com/actions — la référence sur la syntaxe et les fonctionnalités.

Mots-clés : GitHub Actions, CI/CD, intégration continue, déploiement continu, workflow YAML, runner, secrets, image Docker ghcr.io, pipeline DevOps.