Comment orchestrer un double déploiement automatique sur Vercel & GitHub Pages avec GitHub Actions

Introduction

Dans le cadre de mon apprentissage des pratiques DevOps modernes, j’ai conçu et implémenté un pipeline CI/CD (Continuous Integration / Continuous Deployment) capable de déployer automatiquement une application web frontend sur deux environnements de production distincts : Vercel et GitHub Pages.

Cette mission constitue une application concrète des concepts fondamentaux du DevOps, notamment l’automatisation des processus, la réduction des interventions manuelles et la mise en place d’une chaîne de livraison logicielle fiable et reproductible.

Tableau comparatif des plateformes

Dans ce projet, le déploiement sur les deux plateformes n’est pas un doublon mais une démarche pédagogique et technique délibérée permettant de tester la flexibilité de l'orchestrateur. Voici comment elles se comparent :

Critère	GitHub Pages	Vercel
Hébergement	Statique uniquement	Statique + SSR + Serverless
Domaine gratuit	username.github.io	projet.vercel.app
CI/CD intégré	Via GitHub Actions	Natif + GitHub Actions
Performance	Bonne	Excellente (Edge Network)
Previews PR	Non	Oui (automatique)
Gratuit	Oui (illimité)	Oui (avec limites)
Cas d’usage	Portfolios, docs	Apps React/Next.js, SaaS

⚠️ Le problème du double déploiement : Laisser Vercel en mode automatique génère un conflit critique avec GitHub Actions. Pour éviter que deux builds s'exécutent en parallèle, j'ai désactivé le déploiement natif de Vercel en ajoutant un fichier vercel.json à la racine contenant "git": { "deploymentEnabled": false }.

---

Le pipeline complet — deploy.yml

Voici le code source du fichier de configuration de l'orchestrateur GitHub Actions (.github/workflows/deploy.yml). Ce script gère séquentiellement l'installation, le build et la publication vers nos deux cibles :

name: CI/CD -- Deploy to Vercel & GitHub Pages

# Declenchement : uniquement sur push vers main
on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      # Etape 1 : Recuperer le code source
      - name: Checkout repository
        uses: actions/checkout@v6

      # Etape 2 : Configurer Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'

      # Etape 3 : Installer les dependances (mode CI)
      - name: Install dependencies
        run: npm ci

      # Etape 4a : Build pour Vercel (base "/")
      - name: Build application
        run: npm run build

      # Etape 5 : Deployer sur Vercel
      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v42
        with:
          vercel-token: \${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: \${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: \${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

      # Etape 4b : Build pour GitHub Pages
      - name: Build for GitHub Pages
        run: npm run build:gh

      # Etape 6 : Deployer sur GitHub Pages
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: \${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

Bonnes pratiques à retenir

• npm ci au lieu de npm install : En environnement CI, cette commande force la lecture stricte du fichier package-lock.json afin de garantir un build déterministe.
• Sécurité : Ne commitez jamais vos identifiants ! Les tokens Vercel sont injectés dynamiquement via les GitHub Secrets.
• Orchestration unique : Centraliser la logique de build évite les race conditions et assure la traçabilité complète de vos livraisons logicielles.