Le CI/CD (intégration et déploiement continus), c’est l’automatisation qui vérifie et met en production votre code à chaque modification, sans étape manuelle. Le pipeline GitHub Actions qu’on réutilise sur chaque projet, du lint à la mise en ligne.
- Quatre étapes systématiques : TypeScript, ESLint, tests, build, sur chaque PR comme sur main.
- Lighthouse CI bloque tout PR qui dégrade le score performance ou SEO sous nos seuils.
- Les secrets vivent dans GitHub Secrets, jamais dans le code.
- La protection de branche interdit le push direct sur main, admins compris.
Notre pipeline en 4 jobs#
PR ouverte → CI (lint + types + tests) → Preview deploy
Main mergée → CI → Production deploy
Simple, rapide et fiable. Le job qualité fait tourner le type-check TypeScript strict, le lint, les tests et le build, dans le workflow ci-dessous.
Le fichier .github/workflows/ci.yml#
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
quality:
name: Quality checks
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: TypeScript
run: npx tsc --noEmit
- name: ESLint
run: npm run lint
- name: Tests
run: npm run test -- --passWithNoTests
- name: Build
run: npm run build
env:
NEXT_PUBLIC_SITE_URL: https://seodev.fr
# Secrets via GitHub Secrets
RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
lighthouse:
name: Lighthouse CI
runs-on: ubuntu-latest
needs: quality
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Run Lighthouse CI
uses: treosh/lighthouse-ci-action@v11
with:
configPath: '.lighthouserc.json'
uploadArtifacts: true.lighthouserc.json#
{
"ci": {
"collect": {
"startServerCommand": "npm run start",
"url": ["http://localhost:3000", "http://localhost:3000/blog"],
"numberOfRuns": 3
},
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.95 }],
"categories:accessibility": ["error", { "minScore": 0.95 }],
"categories:best-practices": ["error", { "minScore": 0.95 }],
"categories:seo": ["error", { "minScore": 0.98 }]
}
}
}
}Un PR qui fait descendre le score SEO sous 98 ne merge pas. C’est le garde-fou qui maintient les Core Web Vitals au vert dans la durée, pas seulement le jour de la mise en ligne.
Gestion des secrets#
# GitHub CLI
gh secret set RESEND_API_KEY --body "re_xxxx"
gh secret set CONTACT_TO_EMAIL --body "hello@seodev.fr"Jamais de secrets dans le code, même dans des fichiers .env non gitignorés.
Optimisation de la vitesse#
Le cache npm est critique. Avec actions/setup-node@v4 et cache: 'npm', les runs subsequents passent de 3-4 min à 90 secondes.
Pour les mono-repos ou projets avec plusieurs workspaces :
- uses: actions/cache@v4
with:
path: |
~/.npm
${{ github.workspace }}/.next/cache
key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts', '**/*.tsx') }}
restore-keys: |
${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-Ce qu’on active en protection de branche#
Dans GitHub → Settings → Branches → main :
- Require status checks to pass (
quality) - Require branches to be up to date
- Require linear history
- Restrict force pushes
- Restrict deletions
Aucun push direct sur main, même pour les admins.
Ce pipeline fait partie du socle qu’on installe sur chaque projet de développement web : le code livré part avec son usine de qualité, pas seulement avec ses fonctionnalités.
Questions fréquentes
Qu’est-ce qu’un pipeline CI/CD ?
Un pipeline CI/CD automatise la vérification et la mise en production du code : à chaque modification, les tests, le lint et le build s’exécutent automatiquement, puis le déploiement se fait sans intervention manuelle si tout passe.
GitHub Actions est-il gratuit pour un projet privé ?
GitHub offre un quota de minutes gratuites par mois sur les dépôts privés, largement suffisant pour un pipeline standard avec cache npm. Les dépôts publics bénéficient de minutes illimitées.
Combien de temps doit durer un pipeline CI ?
Avec le cache npm et le cache de build Next.js bien configurés, un pipeline complet (types, lint, tests, build) tient en 1 à 2 minutes. Au-delà de 5 minutes, les développeurs contournent le pipeline, ce qui annule son intérêt.
Pourquoi bloquer les pushs directs sur la branche main ?
Pour garantir que tout code en production est passé par le pipeline : revue, tests, type-check et build. La protection de branche rend ce passage obligatoire, y compris pour les administrateurs du dépôt.