API Consentement: Guide SSR pour Next.js, React & Nuxt

Les Principes Clés en Bref (TL;DR)

• La preuve est reine : Un simple cookie côté client ne suffit pas. Vous devez stocker une preuve de consentement immuable côté serveur (qui, quoi, quand).
• Pensez "Serveur d'abord" : L'état du consentement doit être lu côté serveur pour éviter les effets de clignotement (FOUC) et assurer un rendu SSR correct.
• Synchronisation Client-Serveur : Utilisez les mécanismes natifs des frameworks (Cookies, Server Actions, API routes) pour synchroniser l'état du consentement entre le serveur et le client.
• L'API est votre alliée : Une API dédiée (ou une Server Action) est indispensable pour enregistrer la preuve de consentement de manière sécurisée.

Intégration avec Next.js (App Router)

L'App Router de Next.js, avec son modèle hybride de Server et Client Components, demande une architecture de consentement réfléchie. Pour garantir la conformité RGPD tout en préservant les performances SSR, il est crucial de dissocier la lecture (côté serveur) et l'écriture (via le client) du consentement.

1. Le Hook useConsent dans un Client Component

Toute interaction avec la bannière de consentement se passe côté client. On utilise donc un Client Component (avec la directive 'use client') pour la créer. La meilleure pratique est d'encapsuler la logique dans un hook personnalisé, comme useConsent. Ce hook, basé sur useState et useContext, expose l'état du consentement et les fonctions pour le mettre à jour. Il est essentiel que ce hook soit hydraté par une source de vérité unique (un Contexte React) pour éviter toute désynchronisation au chargement.

2. Gestion SSR du Consentement via les Cookies

Pour éviter le "flicker" de la bannière et assurer un rendu côté serveur (SSR) cohérent, la lecture du consentement doit se faire sur le serveur. La source de vérité est le cookie. Dans un Server Component (comme le RootLayout), on utilise la fonction cookies() du module next/headers pour lire le cookie de consentement avant même de rendre la page. Cette valeur est ensuite passée à un ConsentProvider qui la rend disponible pour le hook useConsent, assurant une hydratation parfaite.

// app/layout.tsx (Server Component)
import { cookies } from 'next/headers';

function getConsentStatusFromCookie() {
  const consentCookie = cookies().get('user-consent')?.value;
  try {
    // On retourne l'objet de consentement ou un état par défaut
    return consentCookie ? JSON.parse(consentCookie) : { analytics: false };
  } catch (e) {
    return { analytics: false };
  }
}

3. Enregistrement via une Server Action

Pour enregistrer le choix de l'utilisateur, on utilise une Server Action. C'est une fonction asynchrone marquée par 'use server' qui s'exécute uniquement sur le serveur, même si elle est appelée depuis un Client Component. Au clic sur "Accepter", cette action reçoit les préférences, les valide, et met à jour le cookie avec cookies().set(). C'est une méthode simple, sécurisée et qui évite d'avoir à créer une route d'API dédiée.

Intégration avec Nuxt 3 (Composition API)

Dans l'écosystème Vue.js, Nuxt 3 offre des outils puissants pour une gestion de consentement universelle (SSR + client). En combinant un composable et le moteur serveur Nitro, on obtient une solution élégante et conforme.

Le Composable useConsent avec useCookie

La logique est centralisée dans un composable (ex: composables/useConsent.ts). Pour assurer la persistance de l'état entre le serveur et le client, on utilise le composable natif useCookie. Il gère de manière transparente la synchronisation de la valeur via les en-têtes HTTP, la rendant accessible de façon isomorphe. Notre composable expose ainsi un état réactif et une méthode pour le modifier.

Accès et Mise à Jour dans les Composants

Grâce à l'auto-import de Nuxt, utiliser le composable est un jeu d'enfant. Dans le composant de la bannière, on appelle simplement const { consentState, updateConsent } = useConsent();. L'interface est liée à consentState, et un clic sur un bouton appelle updateConsent. La réactivité de Vue assure que tous les composants utilisant ce hook sont mis à jour automatiquement.

Création d'un Endpoint Nitro pour la Preuve

Un cookie seul ne constitue pas une preuve de consentement. Il faut un enregistrement côté serveur. Le moteur Nitro de Nuxt permet de créer des endpoints API très facilement. On crée un fichier server/api/consent.post.ts qui recevra les détails du consentement (catégories, ID, horodatage). Le rôle de ce handler est de valider ces données et de les stocker dans une base de données. La fonction updateConsent du composable est alors modifiée pour appeler ce endpoint via $fetch en plus de mettre à jour le cookie.

Intégration avec React (Vite + SSR)

Pour les projets React sans framework full-stack, l'approche repose sur la combinaison de l'API Context de React et d'une gestion manuelle de l'hydratation pour le SSR.

Le Pattern ConsentProvider et useConsent

On crée un contexte React (ConsentContext) et un composant ConsentProvider qui encapsule l'état (via useState) et les fonctions de mise à jour. Un hook personnalisé useConsent simplifie l'accès à ce contexte depuis n'importe quel composant. L'application est ensuite enveloppée dans ce ConsentProvider pour distribuer l'état de consentement globalement sans "prop drilling".

Stratégie d'Hydratation SSR Manuelle

Pour éviter les erreurs d'hydratation et le clignotement de l'interface, l'état initial doit être synchronisé. Côté serveur (ex: avec Express.js), le middleware de rendu lit le cookie de consentement. Cet état est sérialisé en JSON et injecté dans le HTML via une balise <script> : window.__INITIAL_CONSENT_STATE__ = { ... }. Côté client, le ConsentProvider utilise cette variable globale pour initialiser son état. Cette technique garantit que le rendu serveur et le premier rendu client sont identiques.

Endpoint API pour la Persistance

Lorsque l'utilisateur modifie ses préférences, l'état React est mis à jour. Pour rendre ce changement persistant, la fonction updateConsent du provider doit déclencher un appel fetch vers un endpoint dédié (ex: POST /api/consent). Ce point de terminaison, côté serveur, valide les données reçues et met à jour le cookie HTTP. Cette boucle assure la persistance de la session à l'autre.

Générer et Stocker la Preuve de Consentement (Conformité CNIL)

Quelle que soit la technique, la conformité RGPD exige de pouvoir prouver la validité du consentement à tout moment. Cette preuve est votre principale ligne de défense lors d'un contrôle.

Les Éléments d'une Preuve Valide

Selon la CNIL, une preuve de consentement recevable doit obligatoirement contenir :

• Un identifiant unique liant la preuve à un individu (ID de cookie, ID utilisateur).
• Un horodatage précis (timestamp) au format ISO 8601, marquant la date et l'heure.
• La nature exacte du consentement : quelles finalités spécifiques ont été acceptées ou refusées.
• Le contexte de la collecte : les informations fournies à l'utilisateur (ex: version de la politique de confidentialité, URL de la page).

Structure de la Charge Utile (Payload) de l'API

La requête POST envoyée à votre API pour enregistrer le consentement doit contenir ces informations. Voici un exemple de payload robuste :

{
  "userId": "a1b2c3d4-e5f6-7890-1234-567890abcdef", // Identifiant anonymisé
  "timestamp": "2024-05-21T14:30:15Z", // Horodatage ISO 8601
  "sourceContext": {
    "url": "https://exemple.com/inscription", // Page de collecte
    "cmpVersion": "3.1.0" // Version de la bannière de consentement
  },
  "consentRecord": {
    "privacyPolicyVersion": "v4.2", // Version de la politique de confidentialité
    "purposes": {
      "analytics": true,
      "retargeting": false,
      "newsletter": true
    }
  }
}

L'Importance d'un Enregistrement Immuable

Une fois capturée, cette preuve doit être stockée dans un système garantissant son immuabilité. Un enregistrement immuable ne peut être ni altéré, ni supprimé. Cette caractéristique est cruciale pour assurer l'intégrité de la preuve lors d'un audit. Des solutions comme les bases de données WORM (Write-Once, Read-Many) ou des journaux d'événements signés sont des options techniques pour créer une piste d'audit infalsifiable.

Comparaison des Approches par Framework

Chaque framework propose des outils idiomatiques pour atteindre le même objectif. Voici un résumé des briques techniques essentielles pour chaque écosystème :

Foire Aux Questions : API Consentement: Guide SSR pour

Comment éviter le 'flicker' de la bannière de cookies en SSR ?

Le 'flicker' (ou FOUC) est évité en lisant l'état du consentement depuis un cookie côté serveur. Cet état est ensuite transmis au client (via les props d'un composant ou injecté dans le HTML). Ainsi, le rendu initial du serveur et du client sont synchronisés, éliminant tout clignotement.

Comment stocker la preuve de consentement conformément au RGPD ?

La preuve doit être stockée de manière sécurisée et immuable côté serveur. Chaque enregistrement doit contenir un ID unique, un horodatage, les finalités acceptées/refusées, et le contexte de la collecte. Utilisez une API dédiée pour envoyer ces informations et les stocker dans une base de données ou un système de logs approprié.

Une solution purement client-side est-elle suffisante ?

Non. Une solution purement client (ex: localStorage) est insuffisante car elle ne permet pas de conserver une preuve de consentement auditable et sécurisée côté serveur, comme l'exige le RGPD. L'approche recommandée est hybride : une interface client qui communique avec une API (ou Server Action) côté serveur pour enregistrer la preuve.

Comment passer l'état de consentement du serveur au client ?

Dans Next.js (App Router), lisez le cookie dans un Server Component et passez-le en prop à un Provider. Dans une application React SSR classique, lisez le cookie sur le serveur, sérialisez l'état en JSON et injectez-le dans une balise <script> du HTML (ex: window.__INITIAL_STATE__) pour que le client puisse le lire à l'initialisation.