Quand j’ai commencé à enseigner le déploiement continu à mes étudiants en BTS SIO, la plupart d’entre eux pensaient que le CI/CD était réservé aux grandes entreprises disposant de serveurs dédiés. La réalité est tout autre : avec GitHub Actions, n’importe quel développeur peut automatiser ses tests, son linting et son déploiement sans débourser un centime. Je vais vous montrer comment mettre en place un pipeline complet, étape par étape.

Comprendre GitHub Actions et le CI/CD

Le CI/CD (Continuous Integration / Continuous Deployment) désigne l’ensemble des pratiques qui automatisent le cycle de vie d’une application, de l’écriture du code jusqu’à sa mise en production. L’intégration continue (CI) consiste à fusionner régulièrement les modifications dans une branche principale tout en exécutant automatiquement des tests. Le déploiement continu (CD) prolonge ce processus en livrant automatiquement le code validé sur un environnement de production.

GitHub Actions est le service d’automatisation intégré directement dans GitHub. Lancé en 2019, il permet de déclencher des workflows automatisés en réponse à des événements sur votre dépôt : un push, l’ouverture d’une pull request, la création d’un tag ou même un planning horaire (cron). Contrairement à des outils comme Jenkins qui nécessitent un serveur dédié, GitHub Actions fonctionne sur des runners hébergés par GitHub, ce qui signifie zéro infrastructure à maintenir.

Concrètement, un workflow GitHub Actions est un fichier YAML stocké dans le dossier .github/workflows de votre dépôt. Chaque workflow se compose de jobs, eux-mêmes composés d’étapes (steps). Cette architecture modulaire permet de construire des pipelines aussi simples ou complexes que nécessaire. Si vous maîtrisez déjà les commandes Git, vous avez les bases pour commencer.

L’offre gratuite de GitHub Actions : ce qu’elle inclut vraiment

Avant de se lancer, il est essentiel de comprendre les limites et les avantages de l’offre gratuite. GitHub propose un quota généreux qui suffit largement pour des projets personnels, étudiants ou des petites équipes.

Pour les dépôts publics, GitHub Actions est entièrement gratuit : aucune limite de minutes, aucune restriction sur les fonctionnalités. C’est un avantage considérable pour les projets open source. Pour les dépôts privés, le plan gratuit (GitHub Free) inclut 2 000 minutes par mois sur les runners Linux, avec un stockage de 500 Mo pour les artefacts.

Attention, les minutes sont pondérées selon le système d’exploitation du runner. Un runner Linux consomme 1 minute par minute d’exécution, un runner Windows consomme 2 minutes, et un runner macOS consomme 10 minutes. En pratique, si vous travaillez principalement avec Linux (ce que je recommande pour débuter), vos 2 000 minutes mensuelles vous permettent de lancer facilement plusieurs centaines de builds par mois.

Si vous dépassez votre quota, les workflows sont simplement mis en pause jusqu’au mois suivant. Aucune facturation surprise. Une autre option consiste à utiliser des runners auto-hébergés (self-hosted runners) : vous installez l’agent GitHub sur votre propre machine ou sur un serveur Linux maison, et les minutes consommées ne sont plus décomptées de votre quota.

Anatomie d’un workflow YAML : structure et syntaxe

Chaque workflow GitHub Actions repose sur un fichier YAML. Avant de créer votre premier pipeline, je vais décortiquer la structure de ce fichier pour que vous compreniez chaque élément.

Voici le squelette minimal d’un workflow :

name: Mon premier workflow

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Récupérer le code
        uses: actions/checkout@v4

      - name: Installer Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Installer les dépendances
        run: npm ci

      - name: Lancer les tests
        run: npm test

Détaillons chaque section :

name : le nom affiché dans l’onglet Actions de votre dépôt GitHub. Choisissez un nom descriptif comme « CI – Tests et Lint » plutôt qu’un nom générique.

on : le déclencheur du workflow. Les événements les plus courants sont push, pull_request, schedule (cron), workflow_dispatch (déclenchement manuel) et release. Vous pouvez filtrer par branche, par tag ou même par chemin de fichier modifié.

jobs : un workflow contient un ou plusieurs jobs. Chaque job s’exécute sur un runner distinct et peut tourner en parallèle ou en séquence grâce au mot-clé needs.

runs-on : spécifie le système d’exploitation du runner. Les options gratuites sont ubuntu-latest, windows-latest et macos-latest.

steps : la liste ordonnée des étapes du job. Chaque étape utilise soit une action existante (uses), soit une commande shell (run). Cette distinction est fondamentale : uses appelle une action réutilisable du Marketplace, tandis que run exécute directement des commandes, comme vous le feriez dans un terminal avec du Bash scripting.

Créer son premier pipeline CI pas à pas

Passons à la pratique. Je vais vous guider dans la création d’un pipeline d’intégration continue complet pour un projet Node.js, mais les principes s’appliquent à n’importe quel langage.

Étape 1 : créer le dossier de workflows. À la racine de votre dépôt, créez le dossier .github/workflows s’il n’existe pas déjà :

mkdir -p .github/workflows

Étape 2 : écrire le fichier de workflow. Créez un fichier ci.yml dans ce dossier. Voici un pipeline CI complet avec linting, tests et vérification de build :

name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    name: Vérification du code
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint

  test:
    name: Tests unitaires
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - name: Uploader le rapport de couverture
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  build:
    name: Vérification du build
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

Dans cet exemple, j’ai structuré le pipeline en trois jobs séquentiels grâce au mot-clé needs. Le lint s’exécute en premier ; s’il échoue, les tests ne se lancent pas. Ce chaînage évite de gaspiller des minutes sur des tests voués à échouer. Notez aussi l’utilisation du paramètre cache: 'npm' dans setup-node, qui met en cache le dossier node_modules pour accélérer les builds suivants de 30 à 60 %.

Étape 3 : pousser et vérifier. Commitez et poussez votre fichier sur GitHub. Rendez-vous dans l’onglet Actions de votre dépôt pour suivre l’exécution en temps réel. Chaque étape affiche ses logs, et un badge vert ou rouge indique le statut global.

Pour un projet Python, le principe est identique : remplacez setup-node par setup-python, npm ci par pip install -r requirements.txt, et adaptez les commandes de test. Si vous développez une API REST en Python, ce type de pipeline s’intègre parfaitement.

Mettre en place un déploiement automatisé (CD)

L’intégration continue, c’est bien. Ajouter le déploiement continu, c’est encore mieux. Je vais vous montrer trois scénarios de déploiement courants, du plus simple au plus personnalisé.

Déploiement sur GitHub Pages

Pour un site statique (documentation, portfolio, blog), GitHub Pages est la solution la plus rapide. Voici un workflow complet :

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/configure-pages@v4
      - uses: actions/upload-pages-artifact@v3
        with:
          path: './dist'
      - name: Déployer
        id: deployment
        uses: actions/deploy-pages@v4

Déploiement sur un VPS via SSH

Pour un déploiement sur un serveur personnel ou un VPS, vous pouvez utiliser l’action appleboy/ssh-action. Ce scénario est idéal si vous avez configuré un serveur Linux ou si votre hébergement utilise Nginx ou Apache :

name: Deploy to VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Déployer via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/mon-app
            git pull origin main
            npm ci --production
            npm run build
            pm2 restart mon-app

Les informations sensibles (hôte, utilisateur, clé SSH) sont stockées dans les secrets du dépôt, accessibles via Settings > Secrets and variables > Actions. Ces secrets sont chiffrés et jamais exposés dans les logs.

Déploiement sur un service cloud (Vercel, Netlify)

La plupart des plateformes cloud modernes proposent des intégrations natives avec GitHub. Pour Vercel par exemple, il suffit de connecter votre dépôt depuis le tableau de bord Vercel ; chaque push déclenche automatiquement un build et un déploiement, sans même écrire de workflow. Si vous avez besoin de plus de contrôle, une action dédiée existe sur le Marketplace.

Fonctionnalités avancées : matrices, cache et secrets

Les matrices de test

Les matrices permettent de tester votre code sur plusieurs combinaisons d’OS, de versions de langage ou de bases de données en une seule définition. C’est extrêmement puissant pour garantir la compatibilité :

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Ce workflow génère 6 jobs (2 OS × 3 versions). Tous s’exécutent en parallèle, ce qui accélère considérablement la validation. Si vous comparez différentes technologies de bases de données SQL et NoSQL, vous pouvez même inclure des services conteneurisés (MySQL, PostgreSQL, MongoDB) dans votre matrice.

Le cache des dépendances

Le cache est un levier d’optimisation majeur. Au lieu de retélécharger toutes les dépendances à chaque build, GitHub stocke le cache et le restaure automatiquement :

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

La clé de cache est basée sur le hash du fichier package-lock.json. Tant que ce fichier ne change pas, le cache est réutilisé. En pratique, cela réduit le temps d’installation des dépendances de plusieurs minutes à quelques secondes.

La gestion des secrets

Les secrets sont indispensables pour stocker des clés API, des tokens d’accès ou des identifiants de déploiement. Voici les bonnes pratiques essentielles :

• Créez vos secrets dans Settings > Secrets and variables > Actions de votre dépôt
• Utilisez des environnements (production, staging) pour isoler les secrets par contexte
• Activez les règles de protection sur les environnements sensibles (approbation manuelle requise avant déploiement)
• Ne loguez jamais un secret dans vos workflows ; GitHub masque automatiquement les valeurs connues, mais restez vigilant avec les commandes echo

La cybersécurité doit rester une priorité, même dans vos pipelines d’automatisation.

Le Marketplace et les actions communautaires

L’un des plus grands atouts de GitHub Actions est son Marketplace, qui référence plus de 20 000 actions créées par la communauté et par des éditeurs officiels. Au lieu de réinventer la roue, vous pouvez intégrer des actions prêtes à l’emploi pour quasiment tous les cas d’usage.

Voici les actions les plus populaires que je recommande à mes étudiants :

• actions/checkout : récupère le code source du dépôt (indispensable dans tout workflow)
• actions/setup-node, actions/setup-python, actions/setup-java : installe l’environnement d’exécution du langage cible
• actions/cache : met en cache les dépendances pour accélérer les builds
• actions/upload-artifact / actions/download-artifact : partage des fichiers entre les jobs d’un même workflow
• docker/build-push-action : construit et pousse une image Docker vers un registre
• peaceiris/actions-gh-pages : déploie sur GitHub Pages en une étape
• sonarsource/sonarcloud-github-action : analyse la qualité du code avec SonarCloud

Pour trouver des actions, rendez-vous sur github.com/marketplace. Avant d’utiliser une action tierce, vérifiez toujours le nombre d’étoiles, la date de dernière mise à jour et la présence d’un badge « Verified creator ». Épinglez toujours vos actions sur un tag de version précis (par exemple @v4) plutôt que sur @main pour éviter les surprises.

Vous pouvez aussi créer vos propres actions réutilisables, soit en JavaScript, soit sous forme de composite actions (un fichier YAML qui encapsule plusieurs étapes). C’est un excellent moyen de factoriser la logique commune entre plusieurs dépôts.

Bonnes pratiques et optimisation des workflows

Après avoir accompagné des dizaines d’étudiants dans la mise en place de leurs pipelines, voici les erreurs les plus fréquentes et les bonnes pratiques que je recommande systématiquement.

Limiter les déclenchements inutiles. Utilisez les filtres paths pour ne lancer un workflow que lorsque des fichiers pertinents sont modifiés. Inutile de relancer tous les tests si vous n’avez modifié que le fichier README.md :

on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - 'tests/**'
      - 'package.json'

Utiliser la concurrence pour annuler les builds obsolètes. Si vous poussez plusieurs commits rapidement, le mot-clé concurrency annule automatiquement les exécutions précédentes devenues inutiles :

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

Séparer CI et CD. Ne mélangez pas les tests et le déploiement dans un même workflow. Créez un fichier ci.yml déclenché sur les pull requests et un fichier cd.yml déclenché uniquement sur les pushs vers main. Cette séparation clarifie les responsabilités et facilite le débogage.

Protéger la branche principale. Configurez des branch protection rules dans les paramètres du dépôt pour exiger que le workflow CI passe avant toute fusion. Cette pratique garantit que le code de la branche main est toujours dans un état fonctionnel.

Surveiller la consommation de minutes. Rendez-vous dans Settings > Billing > Actions pour suivre votre consommation. Si vous approchez des limites, envisagez d’utiliser un homelab comme runner auto-hébergé ; c’est une solution économique et formatrice.

Documenter vos workflows. Ajoutez des commentaires dans vos fichiers YAML et un badge de statut dans votre README.md pour que vos collaborateurs visualisent l’état du pipeline d’un coup d’œil :

![CI](https://github.com/votre-user/votre-repo/actions/workflows/ci.yml/badge.svg)

Pour gérer ces automatisations efficacement, un bon éditeur de code avec l’extension YAML appropriée fait toute la différence. VS Code avec l’extension « GitHub Actions » offre l’autocomplétion et la validation syntaxique directement dans l’éditeur.

Comparatif avec les alternatives CI/CD gratuites

GitHub Actions n’est pas la seule option gratuite. Voici un comparatif honnête avec les principales alternatives pour vous aider à choisir la solution adaptée à votre contexte.

Mon avis : si votre code est déjà sur GitHub (ce qui est le cas de la majorité des projets étudiants et open source), GitHub Actions est le choix le plus naturel. L’intégration est native, la documentation est excellente, et l’écosystème du Marketplace vous fait gagner un temps considérable. GitLab CI/CD est une excellente alternative si vous préférez un outil tout-en-un avec registre de conteneurs intégré. Jenkins reste pertinent dans les environnements d’entreprise complexes, mais sa courbe d’apprentissage le rend inadapté pour débuter.

Pour la veille technologique en BTS SIO, suivre l’évolution de ces outils est un sujet particulièrement pertinent. Les pipelines CI/CD font désormais partie des compétences attendues par les recruteurs, et une certification gratuite comme GitHub Foundations peut valoriser ces connaissances sur votre CV.

N’oubliez pas que la maîtrise des commandes Linux de base et de PowerShell facilite grandement le débogage des workflows, car les runners GitHub exécutent des commandes shell standard. Les outils essentiels pour étudiants incluent aujourd’hui GitHub Actions comme compétence incontournable.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.