CI/CD avec GitHub Actions : déployer automatiquement son application web

Tu viens de terminer une fonctionnalité. Tu testes en local, tout fonctionne. Tu pousses sur GitHub. Puis tu dois te souvenir : as-tu bien lancé les tests ? Faut-il rebuild ? Le déploiement, c'est via quelle commande déjà ? Et si tu oublies une étape, l'application en production peut rester dans un état incohérent pendant des heures.

Ce scénario, tous les développeurs le vivent. Les déploiements manuels sont lents, répétitifs et sujets aux erreurs humaines. Un oubli de test, une commande mal tapée, une variable d'environnement oubliée — et c'est l'incident en production. La CI/CD et GitHub Actions existent pour résoudre ce problème. En automatisant les vérifications et le déploiement, tu garantis que chaque modification du code passe par les mêmes étapes, sans intervention manuelle. Dans cet article, tu vas comprendre ce qu'est la CI/CD, comment fonctionne GitHub Actions, et comment mettre en place un pipeline complet qui teste et déploie automatiquement une application web.

1. Qu'est-ce que la CI/CD ?

CI/CD regroupe trois pratiques complémentaires, souvent confondues.

1.1. Continuous Integration (CI) — Intégration continue

L'intégration continue consiste à automatiser les vérifications et les tests à chaque modification du code. Dès qu'un développeur pousse du code sur le dépôt, un processus se déclenche : installation des dépendances, exécution des tests, vérification du lint, compilation. L'objectif : détecter les problèmes le plus tôt possible, avant qu'ils n'atteignent la production.

1.2. Continuous Delivery — Livraison continue

La livraison continue va plus loin : elle prépare automatiquement l'application à être livrée. À la fin du pipeline, l'application est prête à être déployée — mais le déploiement lui-même reste manuel, déclenché par une décision humaine.

1.3. Continuous Deployment — Déploiement continu

Le déploiement continu pousse la logique à son terme : chaque changement validé est automatiquement déployé vers l'environnement cible (souvent la production). Aucune intervention humaine n'est nécessaire entre le merge et la mise en ligne.

1.4. Exemple concret

Une équipe de 4 développeurs travaille sur une application Next.js. Sans CI/CD : chacun déploie à la main, à sa manière. Résultat : des environnements divergents et des bugs difficiles à reproduire. Avec la CI : chaque pull request passe automatiquement les tests. Avec le CD : chaque merge sur main est automatiquement déployé après validation. L'équipe gagne en temps et en fiabilité.

2. Qu'est-ce que GitHub Actions ?

GitHub Actions est la plateforme d'automatisation intégrée à GitHub. Elle permet d'exécuter des workflows en réponse à des événements qui se produisent sur le dépôt.

2.1. Les concepts essentiels

• Workflow — Un ensemble d'étapes automatisées décrites dans un fichier YAML
• Event — L'événement qui déclenche le workflow (push, pull_request, schedule…)
• Job — Un groupe de tâches exécutées sur un même environnement
• Step — Une étape individuelle dans un job (commande ou action)
• Runner — La machine (Ubuntu, Windows, macOS) qui exécute les jobs
• Action — Un composant réutilisable qui accomplit une tâche

2.2. Comment ces éléments s'articulent

Un event (par exemple un push) déclenche un workflow. Ce workflow contient un ou plusieurs jobs, exécutés sur un runner. Chaque job est composé de steps, qui peuvent utiliser des actions réutilisables.

on: push                     # event
jobs:
  build:                     # job
    runs-on: ubuntu-latest   # runner
    steps:                   # steps
      - uses: actions/checkout@v4   # action
      - run: npm install            # commande

3. Comment fonctionne un pipeline CI/CD avec GitHub Actions ?

Voici le scénario typique, de la modification du code au déploiement.

1. Le développeur modifie le code en local
2. Il pousse ses modifications sur GitHub (git push)
3. GitHub Actions détecte l'événement configuré (push sur main, par exemple)
4. Le workflow démarre sur un runner
5. Les dépendances sont installées (npm install)
6. Les tests et vérifications sont exécutés (lint, tests unitaires, build)
7. Si une étape obligatoire échoue, le pipeline s'arrête
8. Si tout réussit, le pipeline déploie vers l'environnement cible
9. Le développeur vérifie le résultat dans l'onglet Actions

3.1. Schéma du pipeline

Modification du code
        ↓
   Push sur GitHub
        ↓
   GitHub Actions
        ↓
Installation des dépendances
        ↓
  Tests et vérifications
        ↓
  (Si succès) Déploiement
        ↓
Application mise à jour

4. Tutoriel : créer son premier pipeline CI/CD

Nous allons mettre en place un pipeline pour une application Node.js simple, avec déploiement sur Vercel (une plateforme adaptée aux applications Next.js et Node.js).

4.1. Prérequis

• Un projet Node.js fonctionnel (Next.js, Express, Vite…)
• Un dépôt GitHub
• Git installé localement
• Node.js installé (version 18 ou 20)
• Un compte Vercel (gratuit pour commencer)
• Les scripts lint, test et build dans package.json

4.2. Étape 1 — Préparer le projet

Vérifie que le projet fonctionne en local, puis envoie le code sur GitHub.

npm install
npm run lint
npm run test
npm run build

git add .
git commit -m "feat: préparation du pipeline CI/CD"
git push origin main

4.3. Étape 2 — Créer le workflow GitHub Actions

Crée le fichier à cet emplacement exact : .github/workflows/ci-cd.yml

name: CI/CD Pipeline

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

permissions:
  contents: read

jobs:
  build-and-test:
    name: Build & Test
    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"
          cache: "npm"

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

      - name: Vérifier le lint
        run: npm run lint

      - name: Exécuter les tests
        run: npm run test

      - name: Construire l'application
        run: npm run build

4.4. Explication des lignes principales

• on: push/pull_request — Déclenche le workflow sur push et pull request vers main
• permissions: contents: read — Restreint les droits au strict nécessaire
• runs-on: ubuntu-latest — Utilise un runner Ubuntu à jour
• actions/checkout@v4 — Récupère le code du dépôt
• actions/setup-node@v4 — Installe Node.js 20 avec cache npm
• npm ci — Installe les dépendances de manière reproductible

4.5. Étape 3 — Ajouter les tests et vérifications

Les scripts lint, test et build sont exécutés séquentiellement. Si l'un échoue, les suivants ne sont pas exécutés — c'est le comportement attendu. GitHub Actions affiche un ❌ rouge dans l'onglet Actions et empêche le merge de la pull request si tu as activé les branch protection rules.

4.6. Étape 4 — Automatiser le déploiement sur Vercel

Configuration côté Vercel : crée un projet sur vercel.com, connecte ton dépôt GitHub, puis récupère les identifiants dans Settings → Tokens (VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID). Configuration côté GitHub : va dans Settings → Secrets and variables → Actions, puis ajoute les 3 secrets.

Ajoute ensuite le job de déploiement à la fin de ton fichier ci-cd.yml :

  deploy:
    name: Deploy to Vercel
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

    steps:
      - name: Récupérer le code
        uses: actions/checkout@v4

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

      - name: Installer Vercel CLI
        run: npm install --global vercel@latest

      - name: Déployer en production
        run: vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

• needs: build-and-test — le déploiement ne démarre que si les tests passent
• if: github.ref == 'refs/heads/main' — déploiement uniquement depuis main
• if: github.event_name == 'push' — pas de déploiement sur les pull requests
• secrets.VERCEL_TOKEN — jamais de token en clair dans le code

4.7. Étape 5 — Vérifier le résultat

1. Va sur ton dépôt GitHub → onglet Actions
2. Clique sur le dernier workflow exécuté
3. Tu vois les jobs build-and-test et deploy avec leur statut
4. Clique sur un job pour lire les logs étape par étape
5. En cas d'échec, corrige et pousse à nouveau — le pipeline se relance automatiquement

5. Bonnes pratiques pour sécuriser son pipeline

• Permissions minimales — Dans le YAML, restreins les droits avec permissions:
• Secrets GitHub — Ne mets jamais de mot de passe ou clé API dans le code. Utilise secrets.NOM_DU_SECRET
• Environnements protégés — Utilise les Environments GitHub pour ajouter des approbations manuelles avant la production
• Branch protection — Interdis le merge direct sur main sans passer par une PR validée
• Actions vérifiées — Utilise des actions officielles ou vérifiées, épinglées à une version stable (@v4, pas @latest)
• Journaux sans secrets — Ne logue jamais de token ou d'information sensible dans les workflows
• Plan de rollback — Prévois toujours un moyen de revenir à une version stable

6. Avantages et limites de GitHub Actions

6.1. Les avantages

• Gain de temps considérable sur les tâches répétitives
• Tests systématiques avant chaque déploiement
• Processus reproductible et identique pour tous les développeurs
• Meilleure collaboration en équipe
• Intégration native avec GitHub (pas d'outil externe à gérer)
• Gratuit pour les dépôts publics et avec un quota généreux pour les dépôts privés

6.2. Les limites

• Temps d'apprentissage et de configuration initiale
• Dépendance à l'environnement GitHub
• Consommation de minutes selon l'offre (attention aux workflows intensifs)
• Maintenance nécessaire quand les actions évoluent
• Risques de configuration et de sécurité si mal utilisés
• Ne supprime pas les erreurs : ça les détecte plus tôt

7. Conclusion

La CI/CD n'est pas un luxe réservé aux grandes entreprises. Avec GitHub Actions, tout développeur peut automatiser les tests et le déploiement de son application en quelques heures.

Mais attention : l'automatisation ne remplace pas la rigueur. Un pipeline mal configuré peut faire plus de dégâts qu'un déploiement manuel. Les tests doivent être pertinents, les permissions maîtrisées, et la stratégie de déploiement adaptée à ton projet.