Balisage côté serveur et consentement : ce qui change, ce qui reste

Le balisage côté serveur (server-side tagging) déplace les balises des fournisseurs du navigateur du visiteur vers un serveur que vous contrôlez : la page envoie des événements à votre point de terminaison, et votre serveur les transmet aux plateformes de mesure d’audience et de publicité. Cela peut améliorer les performances et la maîtrise des données, mais ne supprime pas les exigences de consentement. Les cookies et les identifiants restent sur le terminal du visiteur, et des données personnelles parviennent toujours aux fournisseurs.

Qu’est-ce que le balisage côté serveur ?

C’est une configuration dans laquelle la page envoie un flux unique d’événements à un serveur de balisage, et c’est ce serveur, et non le navigateur, qui appelle chaque fournisseur. Le serveur fonctionne généralement sur un sous-domaine de votre site, comme metrics.example.com.

Les conteneurs côté serveur de Google Tag Manager en sont un exemple bien connu, mais le même schéma fonctionne avec une fonction edge ou une petite API que vous écrivez vous-même. Dans une configuration classique côté client, le script de chaque fournisseur s’exécute dans le navigateur du visiteur et décide de ce qu’il collecte. Dans une configuration côté serveur, le navigateur charge moins de code de fournisseurs, et les fournisseurs reçoivent ce que votre serveur choisit de leur envoyer.

Qu’est-ce qui change lorsque vous déplacez les balises sur le serveur ?

Principalement les performances et le contrôle. Les avantages habituels :

• Moins de code dans le navigateur. Moins de scripts de fournisseurs, c’est moins de JavaScript à télécharger et à exécuter, ce qui améliore le chargement et la réactivité.
• Un endroit pour nettoyer les données. Votre serveur peut inspecter chaque événement avant de le transmettre : supprimer ou tronquer les adresses IP, retirer les paramètres d’URL susceptibles de contenir des adresses e-mail et supprimer les champs dont un fournisseur n’a pas besoin.
• Une mécanique des cookies différente. Votre serveur peut déposer des cookies propriétaires via des en-têtes HTTP Set-Cookie plutôt qu’en JavaScript. Les navigateurs traitent dans certains cas différemment les cookies déposés par script et ceux déposés par le serveur, et ces règles évoluent sans cesse : ne misez donc pas sur une durée de vie de cookie précise.
• Moins de connexions directes avec des tiers. Le navigateur du visiteur communique avec votre domaine plutôt qu’avec chaque fournisseur.

Qu’est-ce qui ne change pas ?

L’analyse juridique. La directive ePrivacy et le RGPD s’intéressent à ce qui se passe sur le terminal et à ce qu’il advient des données personnelles, pas au serveur qui se trouve au milieu.

Question	Balisage côté client	Balisage côté serveur
Des identifiants sont-ils stockés sur le terminal du visiteur ?	Oui, déposés par les scripts des fournisseurs	En général oui, déposés par votre domaine
Le consentement ePrivacy s’applique-t-il au stockage et à l’accès non essentiels ?	Oui	Oui
Des données personnelles parviennent-elles aux fournisseurs ?	Oui, depuis le navigateur	Oui, depuis votre serveur
Chaque finalité nécessite-t-elle une base légale au titre du RGPD ?	Oui	Oui
Les destinataires doivent-ils être portés à la connaissance des visiteurs ?	Oui	Oui
Qui décide de ce que reçoit chaque fournisseur ?	Largement le script du fournisseur	Vous

L’article 5(3) de la directive ePrivacy porte sur le stockage d’informations sur le terminal et l’accès à celles-ci. Si votre serveur dépose un cookie d’identifiant de mesure d’audience et le relit à chaque requête, il s’agit bien d’un stockage et d’un accès sur le terminal, quel que soit le domaine ou le chemin de code qui en est à l’origine. L’exemption dépend de la finalité, c’est-à-dire du caractère strictement nécessaire à un service demandé par l’utilisateur, et non du caractère propriétaire du cookie ; voir les types de cookies.

Le RGPD s’applique aussi aux données d’événement. Les identifiants, adresses IP et URL de pages se rapportant à une personne sont des données personnelles : chaque flux vers un fournisseur nécessite donc une base légale au titre de l’article 6 et, lorsque cette base est le consentement, celui-ci doit remplir les conditions de l’article 7. Si ce que vous recherchez vraiment, c’est une mesure sans identifiants, la mesure d’audience sans cookies est un autre sujet.

Comment transmettre le consentement au serveur ?

Envoyez l’état du consentement avec chaque événement, appliquez-le sur le serveur et considérez toute absence comme un refus. Le serveur doit décider destination par destination, car un même événement entrant peut être réparti entre plusieurs fournisseurs aux finalités différentes.

Côté client, n’envoyez rien sans consentement et incluez l’état dans la charge utile :

type ConsentState = { analytics: boolean; marketing: boolean };

export function track(event: string, props: Record<string, unknown>, consent: ConsentState) {
  if (!consent.analytics && !consent.marketing) return; // rien ne peut être envoyé
  navigator.sendBeacon(
    'https://metrics.example.com/collect',
    JSON.stringify({ event, props, consent, ts: Date.now() }),
  );
}

Côté serveur, ne transmettez à chaque destination que ce que sa catégorie autorise :

export async function handleCollect(req: Request): Promise<Response> {
  const body = await req.json().catch(() => null);
  const analytics = body?.consent?.analytics === true; // absent signifie refusé
  const marketing = body?.consent?.marketing === true;
  if (!analytics && !marketing) return new Response(null, { status: 204 });

  const event = minimize(body); // supprimer les IP, retirer les query strings et les champs inutiles
  const jobs: Promise<unknown>[] = [];
  if (analytics) jobs.push(sendToAnalytics(event));
  if (marketing) jobs.push(sendToAdPlatform(event));
  await Promise.allSettled(jobs);

  return new Response(null, { status: 204 });
}

Si vous utilisez des balises Google avec Consent Mode, l’état du consentement accompagne les requêtes envoyées par les balises, et Google documente le comportement de ses balises selon chaque signal. Vérifiez que chaque balise de votre conteneur serveur, en particulier les modèles tiers, respecte effectivement cet état, plutôt que de le supposer. Notre guide Google Consent Mode v2 présente les quatre signaux.

Que doit faire mon serveur des données ?

Traitez le serveur de balisage comme un système de traitement de données doté de ses propres règles, et non comme un simple tuyau :

1. Refusez par défaut. Écartez les événements dont les champs de consentement sont absents ou mal formés.
2. Aiguillez selon la finalité. N’envoyez aux fournisseurs de mesure d’audience que les événements ayant reçu un consentement à la mesure d’audience, et aux fournisseurs publicitaires que ceux ayant reçu un consentement marketing.
3. Minimisez avant de transmettre. Tronquez ou supprimez les adresses IP, retirez les query strings et les fragments, et n’envoyez à chaque fournisseur que les champs dont il a besoin.
4. Limitez la conservation. Les journaux bruts d’événements sur votre serveur sont aussi des données personnelles. Fixez une durée de conservation courte et restreignez les accès.
5. Documentez chaque flux. Mentionnez chaque fournisseur, les données qu’il reçoit et la finalité dans votre politique de confidentialité et votre politique de cookies, car les visiteurs ne peuvent plus voir ces flux dans leur navigateur.
6. Auditez des deux côtés. Les scanners fonctionnant dans le navigateur ne voient pas le trafic de serveur à serveur : associez un audit des cookies régulier à un examen des balises et des destinations de votre conteneur serveur.

En résumé

Le balisage côté serveur change l’endroit où s’exécutent les balises et vous donne plus de contrôle sur ce que reçoivent les fournisseurs. Il ne change ni le moment où un consentement est nécessaire, ni ce qui constitue une donnée personnelle, ni ce que vous devez porter à la connaissance des visiteurs. Intégrez le consentement à chaque événement, appliquez-le sur le serveur et minimisez ce qui en sort. Des outils comme Cookiesh peuvent fournir l’état de consentement dont vos balises et votre serveur ont besoin, grâce à la prise en charge de Google Consent Mode v2, à un modèle Google Tag Manager et à une API JavaScript.

Cet article est fourni à titre d’information générale et ne constitue pas un avis juridique. Pour toute décision concernant votre situation, consultez un professionnel qualifié de la protection des données.