← Retour au programme
Module 09

Authentification, emails et déploiement

Sécurisez votre application avec l'authentification, communiquez avec vos utilisateurs par email, et déployez en production.

Ce module couvre les trois dernières briques essentielles avant le lancement : l'authentification pour identifier vos utilisateurs, les emails transactionnels pour communiquer avec eux, et le déploiement sur Vercel pour rendre votre application accessible au monde.

Module suivant →

Philosophie

La sécurité n'est pas une fonctionnalité optionnelle. Chaque décision — stockage de tokens, envoi d'emails, variables d'environnement — doit être prise avec la conscience qu'une erreur peut exposer les données de vos utilisateurs.

Prérequis & Outils

  • Avoir une application Next.js fonctionnelle avec l'App Router
  • Comprendre les bases de SQL et Drizzle ORM
ClerkBetter AuthResendVercel

Objectifs du module

  • Intégrer un système d'authentification complet avec Clerk ou Better Auth
  • Envoyer des emails transactionnels sécurisés avec Resend
  • Déployer une application Next.js en production sur Vercel

Ressource complémentaire

Authentification et déploiement Next.js

Ressource complémentaire pour découvrir l'authentification et le déploiement.

Contenu du module

Progression pas à pas.

Chaque leçon s'appuie sur la précédente avec un rythme pensé pour laisser de l'espace à la compréhension, à la pratique et à la révision.

Leçon 1

Fondamentaux de l'authentification

Comprendre les concepts de sécurité et intégrer un système d'authentification dans une application Next.js.

L'authentification ("qui êtes-vous ?") et l'autorisation ("avez-vous le droit ?") sont deux concepts distincts mais complémentaires. L'authentification vérifie l'identité d'un utilisateur — typiquement par email/mot de passe ou OAuth (Google, GitHub). L'autorisation détermine ensuite ce que cet utilisateur peut faire : accéder à son profil, modifier ses données, administrer le site. Confondre les deux est une source fréquente de failles de sécurité.

Les sessions et les tokens sont les mécanismes qui maintiennent l'utilisateur connecté. Un cookie de session stocke un identifiant côté navigateur que le serveur vérifie à chaque requête. Un JWT (JSON Web Token) contient les informations d'identité directement dans le token, signé cryptographiquement. Clerk gère toute cette complexité : il fournit un ClerkProvider qui enveloppe votre application, des composants prêts à l'emploi (SignIn, SignUp, UserButton) et des helpers serveur (auth(), currentUser()) pour protéger vos routes.

Better Auth est une alternative open-source à Clerk qui vous donne plus de contrôle sur la base de données et le flux d'authentification. Le choix entre Clerk (hébergé, rapide à intégrer) et Better Auth (self-hosted, plus de contrôle) dépend de vos besoins. Pour un premier projet, Clerk permet de se concentrer sur les fonctionnalités métier sans gérer l'infrastructure d'authentification.

Exemple : intégration de Clerk dans une application Next.js avec protection de route.tsx
// app/layout.tsx — Envelopper l'application avec ClerkProvider
import { ClerkProvider } from "@clerk/nextjs";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <ClerkProvider>
      <html lang="fr">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  );
}

// app/dashboard/page.tsx — Page protégée (Server Component)
import { auth } from "@clerk/nextjs/server";
import { redirect } from "next/navigation";

export default async function DashboardPage() {
  const { userId } = await auth();

  if (!userId) {
    redirect("/sign-in");
  }

  return <h1>Bienvenue sur votre tableau de bord</h1>;
}

// Composants Clerk prêts à l'emploi :
// <SignIn /> — formulaire de connexion
// <SignUp /> — formulaire d'inscription
// <UserButton /> — avatar avec menu de profil

Exercice pratique

Exercice pratique

Expliquez le flux complet d'authentification quand un utilisateur se connecte à votre application, étape par étape.

  1. Décrivez ce qui se passe quand l'utilisateur clique sur "Se connecter".
  2. Expliquez comment le serveur vérifie l'identité et crée une session.
  3. Décrivez comment les requêtes suivantes sont authentifiées grâce au cookie de session.
  4. Expliquez ce qui se passe quand le cookie expire ou que l'utilisateur se déconnecte.

Vous avez réussi si vous pouvez expliquer les quatre étapes du flux et si vous comprenez pourquoi le cookie est HTTP-Only (protection contre le vol de session par JavaScript malveillant).

Leçon 2

Emails transactionnels avec Resend

Envoyer des emails transactionnels sécurisés depuis votre application avec Resend et React Email.

Les emails transactionnels sont des messages envoyés automatiquement en réponse à une action de l'utilisateur : confirmation d'inscription, réinitialisation de mot de passe, notification de progression. Contrairement aux emails marketing (newsletters), ils sont attendus par le destinataire et ont un taux d'ouverture très élevé. Resend est un service moderne qui simplifie l'envoi d'emails avec une API propre et un excellent taux de délivrabilité.

RÈGLE DE SÉCURITÉ FONDAMENTALE : les emails ne doivent JAMAIS être envoyés depuis le frontend. L'envoi d'emails nécessite une clé API secrète qui, si exposée côté client, permettrait à n'importe qui d'envoyer des emails en votre nom. Utilisez toujours une Server Action ou un Route Handler pour envoyer des emails. La clé API Resend reste dans les variables d'environnement côté serveur (RESEND_API_KEY), jamais préfixée par NEXT_PUBLIC_.

React Email est une bibliothèque qui vous permet de créer des templates d'emails en JSX, comme vous créeriez des composants React. Cela uniformise votre workflow : vous utilisez le même langage pour l'interface web et les emails. Les composants React Email (Html, Head, Body, Text, Button, Link) génèrent du HTML compatible avec tous les clients email.

Exemple : envoi d'un email de bienvenue avec Resend depuis une Server Action.typescript
// lib/email.ts — Fonction d'envoi côté serveur uniquement
import { Resend } from "resend";

const resend = new Resend(process.env.RESEND_API_KEY);

export async function sendWelcomeEmail(
  to: string,
  name: string
) {
  await resend.emails.send({
    from: "Formation <noreply@votredomaine.fr>",
    to,
    subject: `Bienvenue ${name} ! Votre parcours commence`,
    html: `
      <h1>Bienvenue ${name} !</h1>
      <p>Votre compte a été créé avec succès.</p>
      <p>Commencez votre premier module dès maintenant.</p>
      <a href="https://votresite.fr/cours">
        Accéder aux cours →
      </a>
    `,
  });
}

// app/inscription/actions.ts
// "use server";
// import { sendWelcomeEmail } from "@/lib/email";
//
// export async function registerUser(formData: FormData) {
//   const name = formData.get("name") as string;
//   const email = formData.get("email") as string;
//   // ... créer l'utilisateur en base
//   await sendWelcomeEmail(email, name);
// }

Exercice pratique

Exercice pratique

Concevez un système complet de notifications email pour une plateforme de cours : quels emails envoyer, quand et avec quel contenu.

  1. Listez les 4 emails transactionnels essentiels d'une plateforme de cours (bienvenue, progression, etc.).
  2. Pour chaque email, décrivez le déclencheur (quelle action utilisateur), le contenu et le ton.
  3. Écrivez la fonction d'envoi pour l'email de complétion de module avec le score.

Vous avez réussi si vos 4 emails couvrent les moments clés du parcours et si votre fonction d'envoi utilise Resend côté serveur avec la clé API en variable d'environnement.

Leçon 3

Déploiement avec Vercel

Déployer une application Next.js en production sur Vercel avec les bonnes pratiques de configuration.

Les variables d'environnement séparent la configuration du code. En local, elles vivent dans un fichier .env.local (jamais commité dans Git). En production, elles sont configurées dans le dashboard Vercel. La règle : les variables préfixées NEXT_PUBLIC_ sont accessibles côté client (affichées dans le navigateur), toutes les autres restent côté serveur. Les clés API, mots de passe de base de données et secrets d'authentification ne doivent JAMAIS avoir le préfixe NEXT_PUBLIC_.

Le workflow de déploiement Vercel est élégant : vous connectez votre dépôt GitHub, et chaque push sur la branche principale déclenche un déploiement en production. Chaque pull request génère un « preview deployment » avec sa propre URL, permettant de tester les changements avant de les fusionner. Cette approche encourage les petits déploiements fréquents plutôt que les gros déploiements risqués.

La checklist de production avant le lancement vérifie que tout est en place : les variables d'environnement de production sont configurées (base de données, clé Clerk, clé Resend), les URLs de callback d'authentification pointent vers le domaine de production, le domaine personnalisé est configuré et le certificat SSL est actif. Un oubli dans cette checklist est la cause la plus fréquente de bugs en production.

Checklist de déploiement : vérifications essentielles avant la mise en production.text
=== CHECKLIST DE DÉPLOIEMENT PRODUCTION ===

□ Variables d'environnement configurées sur Vercel :
  - DATABASE_URL (Supabase PostgreSQL)
  - CLERK_SECRET_KEY (authentification serveur)
  - NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY (auth client)
  - RESEND_API_KEY (envoi d'emails)

□ Fichier .env.local dans .gitignore (JAMAIS commité)

□ URLs de callback Clerk mises à jour :
  - Sign-in redirect : https://votredomaine.fr/dashboard
  - Sign-up redirect : https://votredomaine.fr/onboarding
  - Allowed origins : https://votredomaine.fr

□ Base de données Supabase :
  - Migrations appliquées en production
  - Données de seed retirées (pas de données de test)

□ Domaine et SSL :
  - Domaine personnalisé ajouté dans Vercel
  - DNS configuré (CNAME ou A record)
  - HTTPS automatique via Vercel

□ Tests finaux :
  - Inscription + connexion fonctionnelles
  - Emails de bienvenue envoyés
  - Navigation complète sans erreur 404/500

Exercice pratique

Exercice pratique

Préparez un plan de déploiement complet pour votre application, en listant chaque étape et chaque variable d'environnement nécessaire.

  1. Listez toutes les variables d'environnement nécessaires et classez-les en publiques (NEXT_PUBLIC_) et secrètes.
  2. Décrivez les étapes de déploiement dans l'ordre : connexion GitHub, configuration Vercel, domaine.
  3. Rédigez une checklist de vérification post-déploiement avec les tests à effectuer.

Vous avez réussi si votre plan couvre les trois aspects (variables, étapes, vérification) et si aucune clé secrète n'est préfixée par NEXT_PUBLIC_.

Projet final

Plan de lancement

Rédigez un plan de lancement complet pour votre application : intégration de l'authentification, configuration des emails transactionnels, et déploiement en production avec une checklist exhaustive.

Critères de réussite

  • L'authentification Clerk est intégrée avec au moins une page protégée nécessitant la connexion.
  • Au moins un email transactionnel est configuré et envoyé via Resend depuis une Server Action.
  • L'application est déployée sur Vercel avec les variables d'environnement correctement configurées.
  • Un document de plan de lancement liste chaque étape de mise en production avec les vérifications.

Guide de réalisation

  • 1Commencez par l'authentification : configurez Clerk, protégez une route, vérifiez que la connexion fonctionne en local.
  • 2Ajoutez ensuite l'envoi d'email : créez un compte Resend, envoyez un email de test depuis une Server Action.
  • 3Déployez tôt, même en version minimale, pour identifier les problèmes de configuration en production.
  • 4Documentez chaque variable d'environnement nécessaire et sa valeur attendue (sans les secrets réels).

Consolidez vos acquis avant de poursuivre.

Prenez le temps de revoir les concepts difficiles et de refaire les exercices qui méritent une seconde passe.