Ce que Zaraz fait réellement à la périphérie

Zaraz est un gestionnaire de balises côté serveur qui s'exécute dans Cloudflare Workers. Quand un visiteur charge une page, le HTML de l'éditeur inclut un petit script d'initialisation Zaraz — généralement quelques kilo-octets — qui collecte une charge utile d'événement structuré depuis le navigateur (vue de page, clic, événement personnalisé) et l'envoie via POST à un endpoint Cloudflare sur le propre domaine de l'éditeur. Le Worker reçoit cette charge utile et exécute les outils Zaraz configurés contre elle : une intégration Google Analytics 4 envoie un hit Measurement Protocol, une intégration Meta Pixel envoie un événement Conversions API, une intégration Mixpanel envoie un appel HTTP API. Le JavaScript tiers du fournisseur ne se charge jamais dans le navigateur, les cookies du fournisseur ne sont soit jamais déposés, soit écrits via le domaine first-party de Cloudflare par le Worker, et le fournisseur ne reçoit que les données que la configuration Zaraz de l'éditeur transmet explicitement.

C'est la proposition de valeur architecturale. C'est également pourquoi le tableau du consentement est différent de tout gestionnaire de balises côté client. Avec une configuration traditionnelle, la question du consentement est de savoir si le JavaScript du fournisseur se charge ou non. Avec Zaraz, le JavaScript ne se charge jamais dans les deux cas — la question devient de savoir si la charge utile côté serveur est envoyée ou supprimée, et si la charge utile contient les identifiants dont le fournisseur a besoin pour suivre l'utilisateur. Les deux questions ont des réponses bien définies dans l'API Zaraz Consent ; le travail de l'éditeur est de les mapper correctement.

L'API Zaraz Consent et en quoi elle diffère des CMP côté client

Zaraz est livré avec un module de consentement intégré — Zaraz Consent Tools — qui maintient un état de consentement par visiteur et contrôle quels outils configurés se déclenchent. L'état est exposé via une petite API JavaScript : zaraz.consent.set({ analytics: true, marketing: false }) pour enregistrer le choix d'un utilisateur, zaraz.consent.get('analytics') pour le lire, zaraz.consent.getAll() pour la carte complète, zaraz.consent.modal() pour ouvrir l'interface de consentement, et des écouteurs d'événements sur zaraz.consent.onModalShown et les événements associés pour un comportement d'interface personnalisé. Chaque outil Zaraz dans le tableau de bord est configuré avec un ou plusieurs identifiants de finalité, et le Worker n'exécute un outil que lorsque les finalités concernées sont accordées dans l'état de consentement du visiteur.

Le choix d'intégration est d'utiliser la fenêtre de consentement intégrée de Zaraz ou de lier Zaraz à un CMP externe. La fenêtre intégrée est le chemin le plus simple : activer Consent Tools, définir les finalités, configurer chaque outil avec la bonne finalité, et déployer. Le chemin du CMP externe est le bon choix pour les organisations qui standardisent déjà sur Cookiebot, OneTrust, Usercentrics, ou un CMP personnalisé — Zaraz opère alors en aval du CMP, le CMP appelant zaraz.consent.set() au fur et à mesure que l'utilisateur interagit avec la bannière. Les deux chemins aboutissent au même point d'application : le Worker vérifie l'état de consentement avant que chaque outil s'exécute, et les outils dont les finalités ne sont pas accordées ne s'exécutent simplement pas.

Support IAB TCF et régimes régionaux

Zaraz a ajouté le support IAB TCF v2 en 2023 et a suivi l'évolution du cadre depuis. Pour les éditeurs opérant dans l'EEA et au Royaume-Uni dans le cadre de partenariats publicitaires basés sur TCF, l'intégration traduit automatiquement la chaîne de consentement TCF en état de finalité Zaraz lorsque l'éditeur opte. Pour les régions non-TCF, l'éditeur mappe des finalités personnalisées — généralement analytics, marketing, personalization, functional — directement aux outils Zaraz concernés. Le même Worker applique les deux, ce qui signifie qu'une seule configuration Zaraz peut servir à la fois un visiteur EEA via TCF et un visiteur californien via un portail de finalité marketing personnalisé sans deux pipelines parallèles.

Pourquoi Zaraz change le tableau GDPR et ePrivacy

La posture juridique sous le GDPR, l'ePrivacy et le CCPA n'est pas exemptée par l'exécution côté serveur — la base juridique suit les données, non le transport — mais la surface de conformité pratique change. Trois évolutions importent.

• La surface des cookies se réduit. La plupart des cookies des fournisseurs ne sont jamais écrits car le JavaScript du fournisseur ne s'exécute jamais dans le navigateur. Les cookies qui subsistent sont généralement le propre identifiant de session de Zaraz et tous les identifiants first-party que l'éditeur a délibérément propagés. La surface des cookies non essentiels que la bannière doit contrôler est donc considérablement plus petite — parfois seulement un ou deux cookies contre la douzaine ou plus qu'une pile côté client typique produit.
• La divulgation du transfert vers des tiers change. Comme le Worker envoie des données aux fournisseurs via des appels serveur à serveur, le chemin des données depuis le navigateur du visiteur passe par la périphérie de Cloudflare puis vers les fournisseurs configurés. La notice de confidentialité doit refléter cela — Cloudflare est un sous-traitant et chaque outil Zaraz est un destinataire en aval — mais la divulgation est à bien des égards plus claire que le chemin côté client équivalent car l'éditeur a un contrôle total sur ce qui est transmis.
• La piste d'audit est plus centralisée. Comme chaque événement de fournisseur passe par le Worker, l'éditeur dispose d'un point unique où l'état de consentement, la charge utile de l'événement et le destinataire en aval peuvent être enregistrés. Les régulateurs qui attendent un journal de consentement interrogeable ont une réponse plus claire avec Zaraz qu'avec un ensemble épars de balises côté client.

Le schéma d'intégration qui fonctionne

Le déploiement de référence comporte quatre composants mobiles. Le premier est l'initialisation de Zaraz dans la page, chargée depuis le domaine de l'éditeur via le proxy de Cloudflare. Le second est soit la fenêtre Consent Tools intégrée, soit un CMP externe qui appelle zaraz.consent.set() au fur et à mesure que l'utilisateur fait ses choix. Le troisième est la configuration du tableau de bord Zaraz qui mappe chaque outil aux bonnes finalités — les outils d'analyse à la finalité analytique, les outils publicitaires à la finalité marketing, les outils d'enregistrement de session à une finalité fonctionnelle ou de recherche plus stricte, et tout outil dépendant d'un transfert vers un tiers à la finalité de transfert transfrontalier si la notice de confidentialité de l'éditeur l'expose comme un choix distinct. Le quatrième est un journal côté serveur — soit Cloudflare Analytics, Logpush vers un data lake de l'éditeur, soit un Worker personnalisé qui écrit les décisions de consentement dans un stockage interrogeable — afin que le registre de consentement puisse être produit sur demande du régulateur.

L'étape de validation est la même séquence de quatre vérifications qui s'applique à toute intégration de consentement mais avec une particularité propre à Zaraz. Une session de navigateur propre avec la bannière affichée mais aucun choix effectué devrait produire zéro requête depuis le navigateur du visiteur vers tout domaine de fournisseur et zéro cookie non essentiel — les deux étant plus faciles à confirmer avec Zaraz qu'avec une pile côté client car l'absence de requêtes tierces est le comportement par défaut plutôt qu'une exception configurée. Une visite de refus devrait maintenir cet état. Une visite d'acceptation devrait produire les POST vers l'endpoint Zaraz ne portant que les événements pour lesquels l'utilisateur a consenti, et les journaux Worker devraient montrer les déclenchements des outils en aval. Un retrait devrait immédiatement arrêter les exécutions supplémentaires des outils Worker, expirer les cookies définis par Zaraz, et déclencher les signaux appropriés de suppression ou d'exclusion vers les fournisseurs en aval configurés.

Où Zaraz nécessite encore une attention particulière

Zaraz n'est pas une solution de consentement par architecture qui supprime le besoin de réfléchir. Trois domaines nécessitent une attention délibérée. Les intégrations click-to-load — YouTube, Twitter, Instagram, vidéo TikTok — nécessitent encore le même modèle de contenu de substitution qu'utilise tout déploiement consent-first, car Zaraz ne proxifie pas actuellement les iframes vidéo intégrées. Les identifiants côté client que l'éditeur choisit de définir dans le navigateur à des fins first-party — un identifiant d'utilisateur connecté, un jeton de session, un bucket de test A/B — restent du côté éditeur de la frontière du consentement et nécessitent leur propre logique de contrôle. Et la notice de confidentialité doit décrire avec précision le modèle de transfert côté serveur, y compris le rôle de Cloudflare comme sous-traitant et l'emplacement géographique des Workers qui traitent les données, car la périphérie Cloudflare fonctionne dans plusieurs régions et le trafic du visiteur peut être traité dans une région qui n'est pas la sienne. Ces points étant gérés, un déploiement Zaraz en 2026 se transforme d'un produit de gestion de balises en l'une des architectures de consentement les plus propres qu'un éditeur puisse déployer : surface des cookies plus petite, moins de requêtes tierces, application centralisée et piste d'audit qu'un régulateur peut réellement lire.