Zero-party data : cadre CNIL et mise en œuvre technique

"Zero-party data" est devenu un mot de pitch commercial : on le colle sur des quiz, des centres de préférences, des formulaires de qualification. Derrière le terme, il y a une idée simple et utile (demander aux gens plutôt que de les deviner) et des contraintes précises : le RGPD ne connaît pas cette notion, GA4 interdit d'y envoyer des données identifiantes, et les plateformes publicitaires imposent leurs règles de hachage et de consentement. Cet article pose la définition, le cadre juridique tel que la CNIL le formule dans son référentiel sur les activités commerciales, puis la mise en œuvre technique : schéma d'événements, GA4, CMP, Google Ads, Meta, et l'attribution déclarative ("comment nous avez-vous connus ?").

Méthode et réserves. Les points juridiques viennent du référentiel de la CNIL lu directement (PDF officiel), les contraintes GA4 et Google Ads de l'aide officielle Google, la définition de Forrester d'articles et de Q&A relayant ses publications. Les règles de hachage Meta proviennent de guides tiers (je n'ai pas pu lire la documentation officielle) et sont à confirmer. Les chiffres d'attribution déclarative sont de seconde main et signalés comme tels. Ceci n'est pas un avis juridique : validez vos formulaires avec votre DPO ou un juriste.

Définition : ce que zero-party data veut dire (et ne veut pas dire)

Le terme vient de Forrester, qui le définit comme des données qu'un client partage de façon intentionnelle et proactive avec une marque ("data that a customer intentionally and proactively shares with a brand"). Exemples typiques : les centres d'intérêt cochés dans un centre de préférences, la réponse à un quiz, la taille de l'entreprise déclarée dans un formulaire de demande de devis, le canal par lequel la personne dit vous avoir découvert.

Sur l'origine du terme : la date est discutée. Une Q&A de Forrester datée du 10 octobre 2018 traite déjà du sujet, d'autres sources citent 2017, et beaucoup d'articles marketing parlent de 2020, année où le terme s'est généralisé. Je n'ai pas pu confirmer la première utilisation. Formulation prudente : le terme est de Forrester, il s'est popularisé vers 2020, avec des traces antérieures dès 2018.

Le point à retenir : "zero-party" n'est pas une catégorie juridique. Une donnée déclarée reste une donnée personnelle, avec une base légale, une finalité, une durée de conservation et des droits d'accès, d'opposition et d'effacement. La déclaration volontaire est un avantage en termes de transparence (la personne sait ce qu'elle donne), pas une dispense de conformité.

Le cadre CNIL : ce que dit réellement le référentiel

La CNIL a publié un référentiel "relatif aux traitements de données à caractère personnel mis en œuvre aux fins de gestion des activités commerciales" (délibération n° 2021-131 du 23 septembre 2021). Il traite des fichiers clients et prospects des organismes privés et publics. Ce référentiel n'a pas de caractère contraignant : un organisme peut s'en écarter s'il peut justifier sa conformité au RGPD par d'autres moyens. Voici ce que j'y ai relevé, pertinent pour des données déclarées.

1. Le profilage à partir de données collectées directement est dans le périmètre

Le référentiel précise que ces traitements peuvent impliquer un profilage réalisé exclusivement à partir de données que l'organisme a collectées directement auprès de la personne. En revanche, le profilage à partir de sources tierces ou de données collectées par cookies et autres traceurs est exclu du périmètre, et renvoie aux lignes directrices et recommandations de la CNIL sur les traceurs. Autrement dit, segmenter vos contacts à partir de ce qu'ils ont déclaré relève de ce cadre ; croiser avec des données de navigation relève des règles sur les traceurs.

2. Finalité : ce qui est collecté pour un but ne se réutilise pas pour un autre

Le référentiel indique que les informations recueillies pour une finalité ne peuvent pas être réutilisées pour un autre objectif incompatible avec celle définie lors de la collecte, et que ces traitements ne doivent pas donner lieu à des interconnexions autres que celles nécessaires à ces finalités. Une réponse donnée pour recevoir une newsletter sur le tracking ne se recycle donc pas librement en critère de ciblage publicitaire.

3. Base légale : consentement ou intérêt légitime selon le canal

• Prospection par voie électronique (e-mail, SMS) pour des biens ou services non déjà achetés : consentement, au titre de l'article L. 34-5 du Code des postes et des communications électroniques.

• Prospection à destination de professionnels, et prospection électronique pour des biens ou services analogues déjà achetés : ces deux lignes figurent dans le tableau, mais leur colonne "base légale" est vide dans le PDF (cellules fusionnées), je ne l'interprète donc pas. D'après des synthèses de la CNIL relayées par des sources secondaires (non relues à la source), la prospection B2B par e-mail peut reposer sur l'intérêt légitime si le message concerne l'activité du destinataire et que celui-ci a été informé, avec un droit d'opposition toujours ouvert ; l'exception pour les clients existants sur des produits analogues vient de l'article L. 34-5 du CPCE. À valider avec un juriste.

• Prospection postale ou téléphonique avec intervention humaine : intérêt légitime ou consentement, à l'appréciation du responsable de traitement.

Pour que le consentement soit valable, le référentiel rappelle qu'il faut une action positive et spécifique de la personne : une case à cocher dédiée et non pré-cochée. L'acceptation de conditions générales d'utilisation ne suffit pas, d'après le CEPD (Comité européen de la protection des données) cité par la CNIL. Le consentement doit aussi être conservé à titre probatoire, et les cases pré-cochées ne sont pas admises pour le recueillir.

4. Minimisation

L'organisme ne doit collecter et utiliser que les données pertinentes et nécessaires au regard de ses besoins de gestion des activités commerciales. Le référentiel liste, à titre d'exemples, les données d'identité, de situation personnelle (profession, catégorie socioprofessionnelle, composition du foyer), de vie professionnelle, de transaction et de suivi de la relation commerciale. Concrètement, un quiz qui demande le revenu ou la situation familiale pour qualifier un lead B2B n'est pas défendable au titre de la minimisation.

5. Données sensibles

Le référentiel est explicite : la nature d'un bien ou d'un service consommé ne devrait pas servir à déduire des informations sensibles (origine, opinions politiques, convictions religieuses, appartenance syndicale, santé, vie sexuelle), et toute catégorisation ou création de segments à partir de telles données, y compris pour de la publicité personnalisée, doit répondre à une finalité légitime et être soumise au consentement préalable. Attention aux centres d'intérêt qui, par recoupement, révèlent de la santé (un centre de préférences d'une mutuelle, d'une marque de compléments).

6. Durée de conservation

Pour les actions de prospection commerciale (messages publicitaires, jeux concours, parrainage, promotion), le référentiel recommande une conservation "jusqu'au retrait du consentement ou 3 ans à compter du dernier contact des personnes avec l'organisme". Le chiffre de trois ans, souvent cité sans source, figure bien dans le tableau de la page 5 du référentiel. Il s'agit d'une durée recommandée, pas d'une règle absolue, et le "dernier contact" est celui de la personne avec l'organisme (une réponse, un clic, un échange), pas la date d'envoi de votre dernier e-mail. Pour la gestion des contrats, la durée est celle de la relation contractuelle ; pour les enquêtes de satisfaction, la durée nécessaire à l'enquête ou jusqu'à l'exercice du droit d'opposition.

7. Transmission à des partenaires

Si vous transmettez des données déclarées à des partenaires pour de la prospection électronique, il faut informer les personnes, recueillir leur consentement à cette transmission et leur permettre d'apprécier l'étendue de leur choix (nombre et secteur des partenaires), idéalement avec une liste exhaustive accessible depuis le support de collecte. Une case unique peut couvrir la transmission et l'utilisation future des données, sous réserve d'une information préalable complète. Le référentiel précise aussi que la demande de consentement ne doit pas elle-même constituer de la prospection.

D'où viennent les données zero-party

• Formulaires de demande de contact ou de devis : secteur, taille, budget indicatif, besoin. C'est la source la plus riche en B2B, à condition de limiter les champs au strict utile.

• Quiz et diagnostics : la personne reçoit un résultat en échange de ses réponses.

• Centres de préférences : thématiques, fréquence et canal de contact choisis par la personne.

• Enquêtes post-achat ou post-appel : satisfaction, motivation d'achat.

• Champ de découverte : "Comment nous avez-vous connus ?", traité en détail plus bas.

Centres de préférences et CMP

Une CMP (plateforme de gestion du consentement) gère des choix de consentement. Un centre de préférences va plus loin : il stocke ce que la personne veut recevoir. Certains éditeurs proposent les deux dans une même plateforme. Exemple documenté : la Preference Management Platform de Didomi. D'après la documentation de l'éditeur, la configuration repose sur deux types d'éléments : les finalités (purposes), qui expliquent pourquoi une donnée est collectée, et les préférences, qui offrent un choix plus fin à l'intérieur d'une finalité. Plusieurs préférences peuvent être rattachées à une finalité et imbriquées entre elles ; chaque préférence propose une liste de valeurs (la question et ses réponses possibles).

• Les finalités viennent du Data Manager de Didomi ; il en faut au moins une dans l'arbre de configuration pour créer un widget.

• Les préférences peuvent être associées à des canaux et à des métadonnées spécifiques.

• La bibliothèque de préférences (collection réutilisable) est indiquée comme fonction premium de la Preference Management Platform.

• Chaque widget enregistre les choix de la personne comme données de consentement. Pour construire ses propres formulaires, l'API de consentements de Didomi existe, avec une tarification distincte de la CMP et du centre de préférences.

Réserve : plusieurs pages de documentation Didomi que j'ai consultées datent de plus de mille jours. Vérifiez les pages développeurs actuelles avant de bâtir un projet dessus. Je n'ai pas vérifié les fonctions équivalentes chez Axeptio, CookieYes ou Usercentrics : renseignez-vous auprès de l'éditeur choisi sur l'existence d'un centre de préférences, de l'export des choix et d'une API.

Point d'architecture : un centre de préférences est un système de stockage de choix, pas un outil d'analytics. Les choix vivent dans la CMP ou le CRM ; ils ne doivent pas être envoyés en bloc à GA4 (voir plus bas).

Mise en œuvre technique : schéma d'événements

Quand une personne répond à une question (quiz, champ de découverte, centre de préférences), vous voulez deux choses distinctes : stocker la réponse là où elle sert (CRM, entrepôt) et mesurer l'événement dans l'analytics (taux de réponse, parcours). Ce ne sont pas les mêmes données.

// Au submit du formulaire ou du quiz.
// Le contenu libre reste dans le CRM : on ne pousse dans le dataLayer
// qu'une catégorie normalisée, jamais le texte saisi.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'zp_answer',
  zp_question_id: 'discovery_channel',   // identifiant stable de la question
  zp_answer_category: 'linkedin',        // valeur issue d'une liste fermée
  zp_form_id: 'contact_devis'
});

Dans GTM, un déclencheur d'événement personnalisé zp_answer alimente une balise d'événement GA4 dont les paramètres lisent ces variables de couche de données. Les paramètres doivent ensuite être déclarés comme dimensions personnalisées dans GA4 pour apparaître dans les rapports (code d'illustration, non exécuté).

Ce qu'il ne faut pas envoyer à GA4

L'aide Google Analytics sur les informations personnelles identifiables (PII) est claire : il est interdit d'envoyer à Google des données qu'il pourrait reconnaître comme PII (e-mail, téléphone, etc.), et ces données fuient souvent par les URL, les titres de page et le texte des formulaires. Deux conséquences pour des données déclarées :

• Jamais de texte libre dans un paramètre d'événement. Un champ "autre, précisez" contient parfois un nom ou un e-mail. Ne remontez à GA4 que des catégories issues d'une liste fermée ; le texte libre reste dans le CRM.

• User-ID prudent : si vous utilisez un User-ID, il ne doit pas permettre à un tiers de déterminer l'identité de la personne (pas d'e-mail, pas de numéro de téléphone), dans la limite de 256 caractères.

Côté quotas, une propriété GA4 standard autorise 25 dimensions personnalisées de portée utilisateur (100 en GA4 360) d'après l'aide Google. Les limites des dimensions de portée événement et élément (50 et 10 en standard) viennent de guides tiers : vérifiez dans l'aide officielle. Ces quotas poussent à sélectionner 2 ou 3 réponses utiles (le canal de découverte, le type de projet) plutôt qu'à transposer tout un questionnaire dans GA4.

Consentement

Le recueil d'une réponse dans un formulaire et la mesure de cet événement dans GA4 sont deux traitements distincts. L'événement analytics relève du consentement analytics (Consent Mode ou blocage de la balise selon votre configuration). Le stockage de la réponse dans votre CRM repose sur sa propre base légale. Les politiques de Google (mise à jour du 23 mars 2026 pour la politique développeur Google Analytics) exigent une information et un consentement ou une possibilité de refus.

Activer des données déclarées dans Google Ads et Meta

L'activation publicitaire de données déclarées passe par des identifiants que le formulaire collecte déjà : l'e-mail, le téléphone, le nom. Les segments (budget, secteur) ne partent pas vers les plateformes via ces mécanismes.

Google Ads : conversions améliorées pour les leads

• Hachage : la documentation Google indique que l'e-mail, le téléphone, le prénom, le nom et l'adresse postale doivent être hachés en SHA-256 avant import ; les champs pays, région, ville et code postal ne se hachent pas. Avant hachage : e-mail en minuscules et sans espaces, téléphone au format E.164 (11 à 15 chiffres avec le préfixe +).

• Qui hache : avec la balise Google, c'est la balise qui hache ; avec l'API ou l'import par fichier, c'est à vous de normaliser et hacher.

• Prérequis du compte : accepter les conditions relatives aux données client (Objectifs > Paramètres > Conversions) et activer les conversions améliorées pour les prospects. Côté API, les champs accepted_customer_data_terms et enhanced_conversions_for_leads_enabled doivent être à vrai ; l'erreur d'import "data terms" signale généralement qu'un des deux manque.

• GCLID : les pages d'aide divergent (exigé sur l'une, "recommandé" sur l'autre). Envoyez-le dans tous les cas.

• Consentement : il faut confirmer la conformité à la politique de Google sur le consentement des utilisateurs de l'UE ; renseigner le champ de consentement lors de l'import est "hautement recommandé", faute de quoi des conversions risquent de ne pas être attribuables.

• Utilisation par Google : Google indique n'utiliser ces données que pour vous fournir ses services, dont la mesure sur l'ensemble de ses médias.

Une règle diverge entre sources pour les adresses Gmail : le guide Tag Manager demande de retirer les points précédant le domaine, l'exemple de code de l'API retire aussi les signes plus de la partie locale. Vérifiez la règle correspondant à votre mode d'intégration.

Meta : Conversions API

Je n'ai pas pu lire la documentation officielle de Meta ; les éléments suivants proviennent de guides tiers concordants et sont à confirmer avant mise en production.

• Les identifiants personnels (e-mail em, téléphone ph, prénom, nom, ville, région, code postal, pays, date de naissance, genre) sont hachés en SHA-256 après normalisation (minuscules et sans espaces pour l'e-mail, format E.164 pour le téléphone).

• Les signaux techniques (fbc, fbp, adresse IP, user agent) sont envoyés en clair via HTTPS ; hacher l'IP ou le user agent rend l'événement non rapprochable, selon un outil de validation tiers.

• Plus l'événement est complet et correctement formaté, meilleur est le rapprochement (Event Match Quality).

Le hachage n'anonymise pas. Un e-mail haché reste lié à une personne : les obligations de consentement et de protection des données s'appliquent. C'est le piège classique d'une présentation de CAPI comme "conforme parce que haché".

L'attribution déclarative : "comment nous avez-vous connus ?"

C'est l'usage le plus simple et le plus rentable du zero-party data pour un site B2B. Un champ libre dans le formulaire de contact capte ce que les outils de mesure ne voient pas : une recommandation entre pairs, un podcast, un post LinkedIn lu sans cliquer, un message privé. Les outils les classent en "direct" ou ne les voient pas du tout (le dark social).

Méthode recommandée par les praticiens

• Champ en texte libre plutôt qu'en liste déroulante : une liste biaise vers les options proposées et oblige à choisir parmi des réponses qui ne reflètent pas toujours la réalité.

• Champ obligatoire, avec discernement : un guide cité par Recast rapporte que près de 30 % des personnes ne le remplissent pas quand il est facultatif (chiffre attribué à Dreamdata, que je n'ai pas vérifié à la source). Les praticiens recommandent de le rendre obligatoire ; à vous de le mettre en balance avec la friction du formulaire et le principe de minimisation.

• Catégorisation automatique des réponses par correspondance de chaînes ("LI" devient LinkedIn), avec vérification manuelle des premières réponses.

• Placement : formulaires de contact ou de devis, téléchargements, et appels de qualification, plutôt qu'après l'achat (la mémoire s'efface).

Les limites à annoncer au client

• Biais de mémoire et de récence : les gens citent le dernier point de contact ou celui qu'ils se rappellent.

• Surreprésentation des canaux mémorables : un podcast ou un événement marque plus qu'un clic sur une annonce.

• Réponses paresseuses : "Google" revient souvent par défaut et ne dit pas grand-chose.

• Effet d'ordre en liste déroulante : la première option est choisie plus souvent (présenté comme une croyance dans l'article Recast, sans chiffre).

Sur l'ampleur du problème de mesure, deux chiffres circulent dans la littérature marketing, tous deux de seconde main dans ce que j'ai lu : un écart de 90 % entre attribution logicielle et données déclarées pour le dark social (attribué à une étude Refine Labs sur 12 mois), et une étude SparkToro sur plus de 1 000 visites selon laquelle 100 % des visites venant de TikTok, Slack, Discord, Mastodon et WhatsApp, et 75 % de celles venant de Messenger, sont classées en "direct". Je n'ai pas retrouvé les études primaires : traitez ces chiffres comme des ordres de grandeur, pas comme des références. Ils décrivent l'insuffisance de l'attribution logicielle, pas la fiabilité du questionnaire.

Les pondérations proposées par certains guides pour mélanger données déclarées et attribution logicielle (70/30 dans l'un, 40/40/20 dans un autre) sont des heuristiques non validées. La seule position défendable : ne s'appuyer sur aucune source seule, ce que l'article Recast formule en disant que se fier uniquement au questionnaire est aussi risqué que se fier uniquement au dernier contact.

Croiser déclaratif et GA4 dans BigQuery

Le champ de découverte est stocké dans le CRM avec un identifiant de lead. Le croiser avec la source GA4 de la session de conversion montre où les deux sources divergent. Exemple de normalisation (SQL BigQuery, illustratif, non exécuté sur vos données) :

SELECT
  lead_id,
  CASE
    WHEN REGEXP_CONTAINS(LOWER(declared_source), r'linkedin|\bli\b') THEN 'linkedin'
    WHEN REGEXP_CONTAINS(LOWER(declared_source), r'google|recherche|search') THEN 'google'
    WHEN REGEXP_CONTAINS(LOWER(declared_source), r'bouche|recommand|collegue|ami') THEN 'recommandation'
    WHEN REGEXP_CONTAINS(LOWER(declared_source), r'podcast|newsletter|youtube') THEN 'contenu'
    ELSE 'autre'
  END AS declared_channel
FROM `mon-projet-gcp.crm.leads`

Comparez ensuite declared_channel au canal GA4 de la session de conversion. Les écarts sont l'information utile : une part élevée de "recommandation" déclarée face à du trafic "direct" mesuré dit où l'effort de marque porte ses fruits.

Erreurs fréquentes

• Cases pré-cochées pour le consentement à la prospection : non admises d'après le référentiel de la CNIL.

• Questionnaire trop long : chaque champ doit se justifier par un usage précis (minimisation).

• Texte libre dans GA4 : fuite de PII non maîtrisée.

• Réutilisation sans nouvelle base légale : une réponse donnée pour recevoir un contenu ne sert pas de critère de ciblage publicitaire sans nouveau recueil.

• Aucune preuve de consentement conservée alors que le référentiel demande de la conserver à titre probatoire.

• Pas de purge : sans règle de conservation, les prospects dorment dans le CRM bien au-delà de la durée recommandée.

• Croire que "haché" veut dire "anonyme" dans les flux Google Ads et Meta.

Par où commencer

• Ajoutez un champ de découverte en texte libre et obligatoire au formulaire de contact, stocké dans le CRM.

• Définissez une liste fermée de catégories et un schéma d'événement (zp_question_id, zp_answer_category) pour la mesure.

• Vérifiez que votre CMP enregistre une preuve de consentement exportable.

• Fixez une durée de conservation et une purge automatique (le repère CNIL : 3 ans après le dernier contact, ou retrait du consentement, pour la prospection).

• Activez les conversions améliorées pour les leads une fois le consentement correctement transmis.

Sources

• CNIL, référentiel relatif aux traitements de données à caractère personnel mis en œuvre aux fins de gestion des activités commerciales (délibération n° 2021-131 du 23 septembre 2021) : périmètre et profilage (p. 3), bases légales et durées (p. 4-5), minimisation et données sensibles (p. 6-7), transmission à des partenaires (p. 9-10)

• Forrester, définition du zero-party data (Khatibloo et al.) ; Q&A Forrester du 10 octobre 2018

• Aide Google Analytics, bonnes pratiques sur les informations personnelles identifiables ; limites de dimensions personnalisées dans la documentation GA4

• Aide Google Ads, conversions améliorées et règles d'utilisation des données de conversions améliorées

• Google Ads API, import de conversions hors ligne (hachage et normalisation)

• Didomi, bibliothèque de préférences et arbre de configuration

• Recast, "How did you hear about us?" et les limites des techniques de mesure actuelles (méthode, biais ; chiffres de seconde main)

• Guides tiers sur Meta Conversions API (champs hachés et normalisation), à confirmer dans la documentation officielle de Meta

Ce contenu est informatif et ne constitue pas un avis juridique. Les référentiels et la documentation des éditeurs évoluent : vérifiez les sources en vigueur avant de mettre en production.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.