Vercel & Netlify : déployer son front-end

Pourquoi Vercel et Netlify changent tout

Déployer un site web statique ou une application front-end a longtemps été une tâche fastidieuse : configurer un serveur, gérer SSH, installer Nginx, écrire des scripts de déploiement, gérer les certificats SSL... Une demi-journée de travail minimum pour chaque nouveau projet.

Vercel et Netlify ont révolutionné ce flux de travail. Ces deux plateformes transforment le déploiement front-end en une opération de quelques minutes, voire de quelques secondes après la configuration initiale. Vous poussez votre code sur Git, la plateforme détecte automatiquement votre framework, build votre projet et le déploie sur un CDN mondial.

Ce que ces plateformes offrent nativement

Sans configurer quoi que ce soit, vous obtenez :

• HTTPS automatique via Let's Encrypt — certificat renouvelé automatiquement
• CDN mondial — vos fichiers statiques servis depuis le point de présence le plus proche de l'utilisateur
• Déploiement Git-based — chaque push sur une branche déclenche un build
• Preview URLs — chaque pull request obtient sa propre URL de prévisualisation
• Rollback instantané — revenir à n'importe quelle version précédente en un clic
• Variables d'environnement — gestion sécurisée des secrets sans les committer
• Domaines personnalisés — configuration DNS guidée, pas besoin d'être expert

Qui utilise ces plateformes ?

Vercel est la plateforme créée par les mêmes auteurs que Next.js. Elle est donc particulièrement optimisée pour ce framework, mais supporte tous les frameworks majeurs. Netlify, créée en 2014, a popularisé le concept de JAMstack et possède un écosystème de plugins très riche. Les deux plateformes sont utilisées par des millions de développeurs et des entreprises comme Airbnb, TikTok, ou Nike.

Vercel vs Netlify : comparaison complète

Les deux plateformes se ressemblent beaucoup en surface, mais présentent des différences importantes selon vos besoins. Voici une comparaison détaillée pour vous aider à choisir.

Quand choisir Vercel ?

• Vous utilisez Next.js (support optimal, ISR, Server Components natifs)
• Vous avez besoin de temps de build illimités sur le free tier
• Performance Edge Functions et latence ultra-faible sont prioritaires
• Vous travaillez sur des projets d'équipe avec des workflows de review complexes

Quand choisir Netlify ?

• Vous utilisez Gatsby, Hugo, Jekyll ou un SSG agnostique
• Vous avez besoin de formulaires de contact sans backend
• Votre projet utilise beaucoup de plugins (Netlify Plugin ecosystem)
• Vous voulez 300 minutes de build gratuites pour des projets légers

Déployer avec Vercel

Vercel propose trois méthodes de déploiement : via l'interface web, via la CLI, ou via l'intégration Git automatique. Voici le processus complet du premier déploiement à la configuration avancée.

Étape 1 — Créer un compte et connecter Git

Rendez-vous sur vercel.com et créez un compte en vous connectant avec GitHub, GitLab ou Bitbucket. L'autorisation OAuth donne à Vercel accès à vos dépôts pour déclencher des builds automatiquement.

Étape 2 — Installer la CLI Vercel

# Installer la CLI Vercel globalement
npm install -g vercel

# Authentification depuis le terminal
vercel login

# Déployer depuis le répertoire du projet (interactif)
vercel

# Déployer directement en production sans confirmation
vercel --prod

Étape 3 — Configurer vercel.json

Le fichier vercel.json à la racine de votre projet contrôle le comportement du déploiement : rewrites, redirects, headers, régions, et configuration du framework.

// vercel.json — configuration pour une application Angular (SPA)
{
    "version": 2,
    "builds": [
        {
            // Répertoire de sortie après ng build
            "src": "dist/mon-app/browser/**",
            "use": "@vercel/static"
        }
    ],
    "routes": [
        // Redirige toutes les routes vers index.html pour le routing Angular
        {
            "src": "/(.*)",
            "dest": "/index.html"
        }
    ],
    "headers": [
        {
            // Appliquer des headers de sécurité sur toutes les pages
            "source": "/(.*)",
            "headers": [
                {
                    "key": "X-Content-Type-Options",
                    "value": "nosniff"
                },
                {
                    "key": "X-Frame-Options",
                    "value": "DENY"
                },
                {
                    "key": "X-XSS-Protection",
                    "value": "1; mode=block"
                },
                {
                    "key": "Referrer-Policy",
                    "value": "strict-origin-when-cross-origin"
                }
            ]
        },
        {
            // Cache long sur les assets avec hash Angular (immutables)
            "source": "/assets/(.*)",
            "headers": [
                {
                    "key": "Cache-Control",
                    "value": "public, max-age=31536000, immutable"
                }
            ]
        }
    ]
}

Étape 4 — Variables d'environnement

Ne jamais committer vos secrets dans le code source. Vercel offre une gestion sécurisée des variables d'environnement, accessibles pendant le build et à l'exécution des Edge Functions.

# Ajouter une variable via la CLI Vercel
# La valeur est chiffrée et stockée côté Vercel
vercel env add NEXT_PUBLIC_API_URL

# Lister toutes les variables configurées
vercel env ls

# Supprimer une variable
vercel env rm NEXT_PUBLIC_API_URL

# Les variables préfixées NEXT_PUBLIC_ sont exposées côté client (Next.js)
# Pour Angular, utilisez les variables dans environment.ts pendant le build :
# ng build --configuration=production

// Dans votre code Angular — environment.ts généré au build
// Ne jamais mettre de secrets dans environment.ts (visible dans le bundle)
export const environment = {
    production: true,
    // Variable injectée depuis Vercel lors du build
    apiUrl: process.env['NG_APP_API_URL'] || 'https://api.monapp.com'
};

Étape 5 — Domaines personnalisés

# Ajouter un domaine personnalisé via CLI
vercel domains add monsite.com

# Vercel génère automatiquement les enregistrements DNS à configurer
# chez votre registrar (Gandi, OVH, Namecheap...)
# Type A : 76.76.21.21
# ou CNAME : cname.vercel-dns.com

# Vérifier la configuration DNS
vercel domains inspect monsite.com

Déployer avec Netlify

Netlify propose une expérience de déploiement légèrement différente, avec un fichier de configuration plus expressif (netlify.toml) et des fonctionnalités supplémentaires comme les formulaires natifs et les plugins de build.

Étape 1 — Installer la CLI Netlify

# Installer la CLI Netlify
npm install -g netlify-cli

# S'authentifier avec votre compte Netlify
netlify login

# Initialiser un nouveau site Netlify depuis votre projet
netlify init

# Déployer un preview (pas en production)
netlify deploy

# Déployer en production
netlify deploy --prod

Étape 2 — Configurer netlify.toml

Le fichier netlify.toml est le fichier de configuration principal. Plus expressif que vercel.json, il supporte plusieurs contextes (production, deploy-preview, branch-deploy).

# netlify.toml — configuration complète pour une SPA Angular

[build]
  # Commande de build exécutée par Netlify
  command = "ng build --configuration=production"
  # Répertoire contenant les fichiers buildés (Angular 17+ : dist/mon-app/browser)
  publish = "dist/mon-app/browser"

# Variables d'environnement spécifiques à la production
[context.production.environment]
  NODE_ENV = "production"
  NG_APP_ENVIRONMENT = "prod"

# Variables pour les previews de PR (peut être différent)
[context.deploy-preview.environment]
  NODE_ENV = "production"
  NG_APP_ENVIRONMENT = "staging"

# Redirect SPA : renvoyer toutes les routes vers index.html
[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

# Exemple de redirect permanent (301) pour une ancienne URL
[[redirects]]
  from = "/old-page"
  to = "/new-page"
  status = 301

# Headers de sécurité pour toutes les pages
[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-Content-Type-Options = "nosniff"
    X-XSS-Protection = "1; mode=block"
    Referrer-Policy = "strict-origin-when-cross-origin"
    # Content Security Policy — adaptez selon vos APIs
    Content-Security-Policy = "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com"

# Cache long sur les assets avec hash dans le nom de fichier
[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

Étape 3 — Formulaires Netlify (sans backend)

L'une des fonctionnalités uniques de Netlify est la gestion native des formulaires HTML. Ajoutez simplement l'attribut data-netlify="true" et Netlify capture automatiquement les soumissions sans écrire de backend.

<!-- Formulaire de contact géré nativement par Netlify (sans backend) -->
<form name="contact" method="POST" data-netlify="true" data-netlify-honeypot="bot-field">
    <!-- Champ caché requis par Netlify pour identifier le formulaire -->
    <input type="hidden" name="form-name" value="contact">

    <!-- Champ honeypot invisible pour bloquer les bots -->
    <p class="hidden">
        <label>Ne pas remplir si vous êtes humain: <input name="bot-field"></label>
    </p>

    <label for="name">Nom :</label>
    <input type="text" id="name" name="name" required>

    <label for="email">Email :</label>
    <input type="email" id="email" name="email" required>

    <label for="message">Message :</label>
    <textarea id="message" name="message" rows="5" required></textarea>

    <!-- Netlify envoie automatiquement les soumissions dans votre dashboard -->
    <button type="submit">Envoyer</button>
</form>

Étape 4 — Variables d'environnement via CLI

# Créer une variable d'environnement (chiffrée)
netlify env:set API_KEY "votre-clé-secrète"

# Lister les variables configurées
netlify env:list

# Supprimer une variable
netlify env:unset API_KEY

# Importer depuis un fichier .env local (pratique pour migrer)
netlify env:import .env

CI/CD automatique depuis Git

L'automatisation CI/CD est le coeur de ces plateformes. Une fois configurée, vous n'avez plus à penser au déploiement : chaque push déclenche automatiquement le bon pipeline selon la branche.

Architecture Git-based recommandée

Le flux de travail recommandé avec ces plateformes est le suivant :

• Branche main → déploiement automatique en production
• Branche staging → déploiement sur un environnement de staging (URL dédiée)
• Pull Requests → déploiement Preview automatique (URL unique par PR)
• Branches de feature → optionnel (preview pour chaque branche)

Preview URLs : collaboration facilitée

C'est l'une des fonctionnalités les plus puissantes. Quand vous ouvrez une Pull Request, la plateforme build automatiquement votre code et génère une URL unique comme https://mon-app-pr-42.vercel.app. Cette URL est :

• Automatiquement postée en commentaire sur la PR GitHub/GitLab
• Accessible à toute votre équipe pour review visuelle
• Mise à jour à chaque nouveau commit sur la branche
• Détruite automatiquement après merge ou fermeture de la PR

# .github/workflows/preview-check.yml
# Workflow GitHub Actions complémentaire pour Vercel/Netlify
# (les deux plateformes ont leur propre intégration GitHub, mais
# vous pouvez ajouter vos propres checks en parallèle)

name: Quality Checks

on:
  pull_request:
    branches: [main, staging]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      # Récupérer le code source
      - uses: actions/checkout@v4

      # Configurer Node.js version LTS
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      # Installer les dépendances (utilise le cache npm)
      - run: npm ci

      # Vérifier le linting TypeScript et Angular
      - run: npm run lint

      # Exécuter les tests unitaires en mode CI (pas d'interface graphique)
      - run: npm run test -- --watch=false --browsers=ChromeHeadless

      # Build de vérification (détecte les erreurs TypeScript)
      - run: npm run build -- --configuration=production

Configuration des branches dans Vercel

// vercel.json — configuration multi-branches
{
    "version": 2,
    "git": {
        // Seule la branche main déclenche un déploiement de production
        "deploymentEnabled": {
            "main": true,
            "staging": true
        }
    },
    // Les autres branches créent des previews automatiquement
    "github": {
        "autoAlias": true,
        "silent": false,
        "autoJobCancelation": true
    }
}

Configuration des branches dans Netlify

# netlify.toml — gestion des branches de déploiement
[build]
  command = "ng build --configuration=production"
  publish = "dist/mon-app/browser"

# Contexte staging : branche dédiée avec variables différentes
[context.staging]
  command = "ng build --configuration=staging"
  [context.staging.environment]
    NG_APP_API_URL = "https://api-staging.monapp.com"

# Contexte branch-deploy : toutes les autres branches (previews)
[context.branch-deploy]
  command = "ng build --configuration=development"

# Contexte deploy-preview : pull requests
[context.deploy-preview]
  command = "ng build --configuration=staging"

Notifications et webhooks

# Configurer un webhook Slack pour les déploiements (via CLI Netlify)
netlify trigger:create --event deploy-succeeded --url https://hooks.slack.com/services/xxx

# Les événements disponibles sur Netlify :
# deploy-building, deploy-succeeded, deploy-failed
# form-submission, identity-signup, identity-login

# Sur Vercel, les webhooks se configurent dans le Dashboard
# Paramètres projet > Git Integration > Webhooks

Edge Functions et Serverless

Les deux plateformes proposent deux types de fonctions sans serveur : les Serverless Functions (exécutées dans des régions précises) et les Edge Functions (exécutées au plus proche de l'utilisateur dans le monde entier).

Différence entre Serverless et Edge Functions

Vercel Serverless Function — exemple Node.js

// api/contact.js — Vercel Serverless Function
// Accessible via GET/POST sur /api/contact

import nodemailer from 'nodemailer';

export default async function handler(req, res) {
    // Vérifier la méthode HTTP — on n'accepte que POST
    if (req.method !== 'POST') {
        return res.status(405).json({ error: 'Méthode non autorisée' });
    }

    // Extraire et valider les données du formulaire
    const { name, email, message } = req.body;
    if (!name || !email || !message) {
        return res.status(400).json({ error: 'Tous les champs sont requis' });
    }

    // Configurer le transporteur email (SMTP via variable d'env)
    const transporter = nodemailer.createTransporter({
        host: process.env.SMTP_HOST,       // Configuré dans le dashboard Vercel
        port: parseInt(process.env.SMTP_PORT || '587'),
        auth: {
            user: process.env.SMTP_USER,   // Jamais dans le code source !
            pass: process.env.SMTP_PASS
        }
    });

    try {
        // Envoyer l'email de contact
        await transporter.sendMail({
            from: `"${name}" <${email}>`,
            to: process.env.CONTACT_EMAIL,
            subject: `Nouveau message de ${name}`,
            text: message,
            html: `<p><strong>De:</strong> ${name} (${email})</p><p>${message}</p>`
        });

        // Répondre avec succès
        return res.status(200).json({ success: true, message: 'Email envoyé' });
    } catch (error) {
        console.error('Erreur envoi email:', error);
        return res.status(500).json({ error: 'Erreur serveur' });
    }
}

Netlify Edge Function — exemple géolocalisation

// netlify/edge-functions/geo-redirect.js
// Edge Function Netlify : redirection basée sur la localisation
// Exécutée en <5ms au PoP le plus proche de l'utilisateur

export default async function handler(request, context) {
    // Récupérer le pays depuis le contexte géographique Netlify
    const country = context.geo?.country?.code || 'UNKNOWN';
    const url = new URL(request.url);

    // Redirection vers la version localisée selon le pays
    if (country === 'FR' && !url.pathname.startsWith('/fr')) {
        // Rediriger les utilisateurs français vers /fr/
        return Response.redirect(`${url.origin}/fr${url.pathname}`, 302);
    }

    if (country === 'DE' && !url.pathname.startsWith('/de')) {
        // Rediriger les utilisateurs allemands vers /de/
        return Response.redirect(`${url.origin}/de${url.pathname}`, 302);
    }

    // Continuer sans redirection pour les autres pays
    return context.next();
}

// Déclarer sur quelles URL cette Edge Function s'applique
export const config = {
    path: '/*',
    excludedPath: ['/api/*', '/_next/*', '/static/*']
};

Vercel Edge Function — middleware auth JWT

// middleware.js (ou middleware.ts) — Vercel Edge Middleware
// S'exécute sur CHAQUE requête avant le rendu (latence <1ms)
import { NextResponse } from 'next/server';

export function middleware(request) {
    // Récupérer le token JWT depuis le cookie
    const token = request.cookies.get('auth-token')?.value;

    // Routes protégées qui nécessitent une authentification
    const protectedRoutes = ['/dashboard', '/profile', '/settings'];
    const isProtectedRoute = protectedRoutes.some(
        route => request.nextUrl.pathname.startsWith(route)
    );

    if (isProtectedRoute && !token) {
        // Rediriger vers la page de connexion si non authentifié
        const loginUrl = new URL('/login', request.url);
        // Ajouter l'URL de retour après connexion
        loginUrl.searchParams.set('returnUrl', request.nextUrl.pathname);
        return NextResponse.redirect(loginUrl);
    }

    // Ajouter un header custom pour les metrics (sans coût supplémentaire)
    const response = NextResponse.next();
    response.headers.set('x-edge-region', process.env.VERCEL_REGION || 'unknown');
    return response;
}

// Appliquer ce middleware uniquement sur les routes définies
export const config = {
    matcher: ['/dashboard/:path*', '/profile/:path*', '/settings/:path*']
};

Configuration avancée et sécurité

Au-delà du déploiement basique, les deux plateformes offrent des options avancées pour optimiser les performances, renforcer la sécurité et gérer les coûts du free tier.

Headers de sécurité complets

Les headers HTTP de sécurité sont essentiels pour protéger vos utilisateurs contre les attaques XSS, clickjacking et injection. Configurez-les une fois dans votre fichier de config et ils s'appliquent à tout le site.

// vercel.json — headers de sécurité complets (grade A sur securityheaders.com)
{
    "headers": [
        {
            "source": "/(.*)",
            "headers": [
                {
                    // Empêche les navigateurs de deviner le type MIME
                    "key": "X-Content-Type-Options",
                    "value": "nosniff"
                },
                {
                    // Bloque le chargement dans des iframes (clickjacking)
                    "key": "X-Frame-Options",
                    "value": "SAMEORIGIN"
                },
                {
                    // Active le filtre XSS du navigateur
                    "key": "X-XSS-Protection",
                    "value": "1; mode=block"
                },
                {
                    // Force HTTPS pendant 1 an, incluant les sous-domaines
                    "key": "Strict-Transport-Security",
                    "value": "max-age=31536000; includeSubDomains; preload"
                },
                {
                    // Contrôle les informations de referrer envoyées
                    "key": "Referrer-Policy",
                    "value": "strict-origin-when-cross-origin"
                },
                {
                    // Politique CSP — adaptez selon vos CDN et APIs utilisés
                    "key": "Content-Security-Policy",
                    "value": "default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://api.monapp.com"
                },
                {
                    // Désactive les fonctionnalités sensibles du navigateur
                    "key": "Permissions-Policy",
                    "value": "camera=(), microphone=(), geolocation=(), payment=()"
                }
            ]
        }
    ]
}

Stratégie de cache optimale

# netlify.toml — stratégie de cache pour Angular
# Les fichiers Angular avec hash dans le nom peuvent être cachés indéfiniment

[[headers]]
  # HTML : jamais mis en cache (toujours fraîche)
  for = "/*.html"
  [headers.values]
    Cache-Control = "public, max-age=0, must-revalidate"

[[headers]]
  # JS/CSS avec hash Angular (ex: main.abc123.js) : cache 1 an
  for = "/assets/*.js"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

[[headers]]
  for = "/assets/*.css"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

[[headers]]
  # Images WebP/PNG/SVG : cache 30 jours
  for = "/assets/images/*"
  [headers.values]
    Cache-Control = "public, max-age=2592000"

Limites du free tier à connaître

Rewrites et proxies d'API

Un usage courant est de proxifier les appels API pour masquer l'URL réelle et éviter les problèmes CORS. Les deux plateformes supportent les rewrites côté serveur.

// vercel.json — proxy API pour masquer l'URL backend
{
    "rewrites": [
        {
            // Redirige /api/* vers votre backend sans révéler son URL réelle
            // Useful pour éviter le CORS et masquer l'infrastructure
            "source": "/api/:path*",
            "destination": "https://backend-secret.monapp.com/api/:path*"
        },
        {
            // Redirige /cdn-assets/* vers un S3 bucket privé
            "source": "/cdn-assets/:path*",
            "destination": "https://mon-bucket.s3.amazonaws.com/:path*"
        }
    ]
}

# netlify.toml — proxy API équivalent
[[redirects]]
  # Proxy vers le backend (status 200 = rewrite sans redirect visible)
  from = "/api/*"
  to = "https://backend-secret.monapp.com/api/:splat"
  status = 200
  # Forcer HTTPS côté backend
  force = true
  # Transmettre les headers d'authentification
  headers = {X-Forwarded-Proto = "https"}

Checklist de sécurité avant mise en production

Conclusion

Vercel et Netlify ont définitivement transformé le déploiement front-end en le rendant accessible à tous les développeurs, sans nécessiter d'expertise en infrastructure. Les deux plateformes offrent un free tier généreux, le CI/CD automatique depuis Git, les Preview URLs et les Edge Functions — couvrant l'immense majorité des besoins des projets modernes.

Le choix entre les deux dépend principalement de votre stack : Vercel pour les projets Next.js avec SSR avancé, Netlify pour les projets JAMstack agnostiques avec formulaires natifs ou plugin ecosystem. Dans les deux cas, le gain de productivité est immédiat : fini la gestion de serveurs, place au code et aux fonctionnalités.