GitHub Actions pour PME : CI/CD complet en partant de zéro

01Le minimum vital : lint + type-check + tests

Un job qui tourne à chaque pull request : install des deps, lint ESLint, type-check TypeScript, tests unitaires (Vitest ou Jest). Si une de ces 4 étapes échoue, la PR est bloquée (status check obligatoire dans GitHub branch protection). Cela coûte 0 effort à mettre en place et évite 90% des régressions évidentes. Variables critiques : caching de npm (gain ~30s par run), version Node.js explicite (jamais 'latest', toujours pinné).

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm test

02Build & deploy par environnement

Sur push vers main → déploiement en production. Sur push vers develop → déploiement en staging. Sur chaque PR → preview deployment automatique. Si vous êtes sur Vercel, la plateforme gère TOUT cela nativement (preview deployments par PR, prod sur main, alias staging configurable) — pas besoin d'écrire de workflow GitHub Actions pour le déploiement, juste connecter le repo dans le dashboard Vercel. Pour Netlify : pareil. Pour AWS/OVH/serveur custom : il faut écrire le workflow GitHub Actions de déploiement (rsync + ssh, ou Docker push, etc.).

03Cache et performance des workflows

Cacher node_modules, le cache Next.js (.next/cache), les artefacts Playwright/Cypress peut diviser le temps de CI par 3. Sur un workflow de 10 minutes, cela compte vite (et économise du quota GitHub Actions sur les plans payants). Stratégies : cache npm via setup-node action (built-in), cache custom pour .next/cache avec actions/cache@v4 keyé sur package-lock + sources. Pour les tests e2e Playwright, utiliser l'action officielle qui cache les browsers téléchargés (~80 MB économisés par run).

# Cache Next.js build
- uses: actions/cache@v4
  with:
    path: |
      .next/cache
      ~/.npm
    key: ${{ runner.os }}-nextjs-${{ hashFiles('package-lock.json') }}-${{ hashFiles('**.[jt]s', '**.[jt]sx') }}
    restore-keys: |
      ${{ runner.os }}-nextjs-${{ hashFiles('package-lock.json') }}-

04Sécurité : Dependabot et scans automatiques

Activer Dependabot dans GitHub repo settings → security & analysis. Il crée automatiquement des PRs pour mettre à jour les dépendances avec failles de sécurité connues. Configurer dependabot.yml pour grouper les updates par catégorie (eviter 50 PRs séparées). Compléter avec : npm audit en CI (mais attention aux faux positifs), Snyk gratuit pour le scan de vulnérabilités, CodeQL natif GitHub pour l'analyse statique du code. Sur les projets clients, on configure tout ça dès le jour 1 — coût zéro, gain de sécurité massif.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule: { interval: weekly }
    groups:
      next:
        patterns: ["next", "@next/*", "react", "react-dom"]
      dev:
        dependency-type: development
    open-pull-requests-limit: 5

05Migrations DB en preview deployments

Sur les projets avec Prisma + Neon (notre stack DB par défaut), on configure les preview deployments Vercel avec branche DB Neon dédiée par PR. Workflow : 1) PR ouverte → Vercel crée preview + branche DB Neon copiée de prod. 2) GitHub Action lance prisma migrate deploy sur la branche DB. 3) Tests e2e en preview. 4) PR mergée → Vercel deploy prod + GitHub Action lance migrate deploy sur DB prod. Avantage : chaque PR a une vraie DB à elle, on peut tester les migrations en isolation. Aucun risque de polluer la prod.

06Tests e2e Playwright dans la CI

Pour les tests end-to-end (Playwright), on les lance UNIQUEMENT sur les PRs vers main (pas sur chaque commit) car ils sont lents. Setup : action officielle microsoft/playwright-github-action qui gère le download des browsers. Variables d'env : BASE_URL pointant vers le preview deployment Vercel. Strategy : lancer e2e sur 3 navigateurs (Chromium, Firefox, WebKit) en parallèle via matrix. Upload des artefacts (screenshots, vidéos) en cas d'échec pour debugger ensuite. Compter 3-8 minutes de test e2e selon le scope.

07Notifications et reporting

Intégrer Slack ou Discord pour recevoir les notifications de build : action 8398a7/action-slack ou native Slack pour GitHub. Sur les fails, notification immédiate dans un channel #dev. Sur les déploiements prod réussis, notification dans #releases avec le diff. Reporting des PRs : utiliser GitHub Actions pour poster un commentaire automatique sur chaque PR avec le link preview Vercel + lighthouse score + couverture tests. Pratique pour l'équipe et le client qui suit l'avancement.

08Patterns avancés : monorepo, matrix, environments

Pour les monorepos (Turborepo, Nx), configurer le `paths` filter pour ne lancer les checks que sur les packages affectés (gain massif de temps CI). Pour les matrix builds (tester sur plusieurs versions Node 20/22 ou OS Ubuntu/macOS) : la syntaxe matrix de GitHub Actions est élégante. Pour les déploiements multi-environnements (prod, staging, preview, demo), utiliser les GitHub Environments avec secrets séparés et required reviewers pour la prod (sécurité). Sur les projets sérieux, on protège la prod avec required reviewers : 2 personnes doivent approuver la PR avant deploy.