RGPD, TCF et consent strings : ce qu’un DSP doit gérer en Europe

Chaque publicité programmatic achetée en Europe commence par une question que la plupart des acheteurs ne voient jamais : cette personne a-t-elle accepté que ses données soient utilisées à des fins publicitaires, et par qui ? La réponse circule dans la bid request sous la forme d’un court texte encodé appelé chaîne de consentement (consent string). Si un DSP ne sait pas la lire, il avance à l’aveugle.

Avancer à l’aveugle coûte cher. Un DSP qui enchérit sur des données personnelles sans base légale valable s’expose, ainsi que ses clients et ses partenaires d’inventaire, à un risque réglementaire au titre du RGPD. À l’inverse, un DSP qui ignore les signaux de consentement et cesse purement et simplement d’enchérir en Europe renonce à certains des inventaires les plus précieux au monde. La bonne réponse se situe entre les deux, et il s’agit avant tout d’un problème d’ingénierie.

Ce guide explique comment le RGPD s’applique à l’achat programmatic, ce qu’est le Transparency and Consent Framework (TCF) d’IAB Europe, ce que contient une chaîne de consentement TCF, comment cette chaîne parvient à un DSP dans une bid request OpenRTB, et quels contrôles un DSP doit effectuer avant d’enchérir. Il s’agit de recommandations pratiques, et non d’un avis juridique.

Pourquoi le RGPD compte pour les acheteurs programmatic

Le Règlement général sur la protection des données est entré en application le 25 mai 2018. Il s’applique dès qu’une entreprise traite des données personnelles de personnes situées dans l’Union européenne, et dans l’univers programmatic, presque tout relève des données personnelles : identifiants de cookies, identifiants publicitaires mobiles, adresses IP et géolocalisation précise sont autant d’identifiants permettant d’isoler une personne ou un appareil.

Un second texte vient s’y ajouter. La directive ePrivacy encadre le stockage d’informations sur l’appareil d’un utilisateur ou leur lecture, ce que fait précisément un cookie ou la consultation d’un identifiant d’appareil. Concrètement, un DSP a généralement besoin d’un consentement avant de pouvoir lire ou déposer son propre cookie dans le navigateur d’un utilisateur européen, avant même tout autre usage des données.

Pour un acheteur, cela soulève trois questions pratiques à chaque impression européenne :

• Le RGPD s’applique-t-il à cette requête ?
• L’utilisateur a-t-il consenti aux usages précis dont le DSP a besoin, comme la création de profils ou la mesure des résultats ?
• L’utilisateur a-t-il accepté que cette entreprise en particulier, le DSP lui-même, traite ses données ?

Qu’est-ce que le Transparency and Consent Framework d’IAB Europe ?

Le Transparency and Consent Framework est un standard volontaire géré par IAB Europe. Il offre aux éditeurs, aux fournisseurs technologiques et aux outils de consentement une manière commune de décrire à quoi servent les données, qui les utilise et ce que l’utilisateur en a dit. IAB Europe distingue trois groupes de participants :

• Les éditeurs : les propriétaires des sites et applications où les données sont collectées.
• Les vendors : des entreprises tierces telles que les ad servers, les prestataires de mesure, les agences, les SSP et les DSP.
• Les plateformes de gestion du consentement (CMP) : les outils qui affichent la bannière de consentement, enregistrent les choix de l’utilisateur et les convertissent en chaîne de consentement.

Les vendors s’inscrivent sur la Global Vendor List (GVL), une liste publique tenue par IAB Europe. Chaque vendor inscrit reçoit un identifiant numérique et déclare pour quelles finalités il traite des données et sur quelle base légale. En novembre 2026, la liste officielle compte plus de 1 200 vendors inscrits. Lorsqu’un utilisateur fait un choix dans une bannière de consentement, la CMP l’enregistre au regard de ces identifiants de vendors.

Le TCF v2.2 a été lancé le 16 mai 2023. En avril 2025, IAB Europe a lancé le TCF v2.3, qui rend obligatoire la section Disclosed Vendors de la chaîne de consentement afin de lever une ambiguïté concernant l’intérêt légitime. Les participants avaient jusqu’au 28 février 2026 pour adopter la v2.3 : tout DSP qui achète aujourd’hui de l’inventaire européen doit donc s’attendre à recevoir des chaînes v2.3.

Les finalités TCF qu’un DSP doit connaître

Le TCF ne pose pas à l’utilisateur une seule question fermée. Il découpe l’usage des données en finalités standard, chacune dotée d’un numéro et d’un nom fixes. Un DSP déclare celles dont il a besoin, et la chaîne de consentement enregistre la réponse de l’utilisateur pour chacune. Voici les onze finalités de la Global Vendor List officielle :

En complément, le TCF définit des finalités spéciales qui ne nécessitent pas de consentement, comme assurer la sécurité et prévenir la fraude, ou diffuser et présenter les publicités. Il définit également des fonctionnalités spéciales qui exigent un opt-in distinct, la plus pertinente étant l’utilisation de données de géolocalisation précise.

Chaque finalité repose sur une base légale : le consentement ou l’intérêt légitime. Depuis le TCF v2.2, les finalités 3 à 6, celles liées au profilage, ne peuvent reposer que sur le consentement. Pour un DSP qui pratique le ciblage d’audience ou le retargeting, c’est la règle la plus importante : sans consentement pour les finalités 3 et 4, pas d’enchère personnalisée.

Que contient une chaîne de consentement TCF ?

La chaîne de consentement TCF, aussi appelée TC string, est un texte encodé compact que la CMP génère une fois que l’utilisateur a fait son choix. Une fois décodée, la partie principale de la chaîne contient :

• Des métadonnées : la version du TCF, les dates de création et de dernière mise à jour de la chaîne, l’identifiant de la CMP, la langue du consentement et la version de la Global Vendor List utilisée.
• Les consentements par finalité : un oui ou un non pour chaque finalité soumise à l’utilisateur.
• Les intérêts légitimes par finalité : si le traitement fondé sur l’intérêt légitime a été présenté à l’utilisateur, sans opposition de sa part, pour chaque finalité éligible.
• Les opt-ins aux fonctionnalités spéciales : par exemple, l’autorisation ou non d’utiliser la géolocalisation précise.
• Les consentements et intérêts légitimes par vendor : un oui ou un non pour chaque identifiant de vendor de la liste.
• Les restrictions de l’éditeur : des règles fixées par l’éditeur pour certains vendors, comme exiger le consentement là où un vendor s’appuierait autrement sur l’intérêt légitime, ou bloquer complètement une finalité.

Avec le TCF v2.3, la chaîne comporte aussi un segment Disclosed Vendors, qui liste les vendors réellement présentés à l’utilisateur dans la notice de consentement. Un vendor peut ainsi faire la différence entre « l’utilisateur s’est opposé à moi » et « l’utilisateur n’a jamais été informé de mon existence ».

Le point clé pour les acheteurs : une chaîne de consentement est bidimensionnelle. Un DSP a besoin à la fois que la finalité soit autorisée et que son propre identifiant de vendor soit autorisé. Un utilisateur peut accepter la publicité personnalisée en général tout en refusant un DSP en particulier, et la chaîne enregistre les deux réponses.

Comment la chaîne de consentement parvient au DSP

La chaîne de consentement circule dans la chaîne d’approvisionnement en même temps que la requête publicitaire. Le parcours habituel est le suivant :

1. L’utilisateur visite un site ou ouvre une application, et la CMP affiche une notice de consentement.
2. L’utilisateur fait son choix, et la CMP l’enregistre sous forme de TC string, généralement dans un cookie first-party ou dans le stockage de l’application.
3. Lorsqu’un emplacement publicitaire se charge, la stack publicitaire de l’éditeur lit la chaîne et la transmet au SSP.
4. Le SSP l’ajoute à la bid request OpenRTB qu’il envoie à chaque DSP connecté.
5. Le DSP décode la chaîne, vérifie ses propres autorisations et décide comment enchérir, ou s’il doit enchérir.

Dans la bid request OpenRTB, deux champs transportent le signal. OpenRTB 2.6 dispose d’un champ natif regs.gdpr, défini à 1 lorsque le RGPD s’applique et à 0 dans le cas contraire, et d’un champ natif user.consent qui contient la TC string elle-même. Les intégrations plus anciennes en OpenRTB 2.5 placent ces mêmes valeurs dans des extensions, sous regs.ext.gdpr et user.ext.consent : un DSP connecté à de nombreux partenaires d’inventaire doit donc lire les deux emplacements. Notre guide sur l’anatomie d’une bid request montre où se situent ces objets dans la requête complète.

Certains partenaires envoient également une chaîne Global Privacy Platform (GPP) dans regs.gpp et regs.gpp_sid. Le GPP est un conteneur de l’IAB Tech Lab qui peut inclure la chaîne TCF aux côtés d’autres signaux régionaux : un DSP doit donc en extraire la section TCF et lui appliquer la même logique.

La chaîne ne s’arrête pas au DSP. Les tags publicitaires et les pixels de tracking peuvent la recevoir via des macros standard, comme ${GDPR} pour l’indicateur d’application et ${GDPR_CONSENT_XXX} pour la chaîne, où XXX correspond à l’identifiant de vendor de l’entreprise appelée.

Les contrôles qu’un DSP doit effectuer avant d’enchérir

Tout cela se déroule dans la fenêtre d’enchère, qui dure généralement de quelques dizaines à quelques centaines de millisecondes, comme décrit dans notre guide sur le fonctionnement du real-time bidding. La logique de consentement doit être rapide, prévisible et identique pour chaque requête. Un DSP bien conçu effectue ces contrôles dans l’ordre :

1. Le RGPD s’applique-t-il ? Lisez l’indicateur gdpr. S’il vaut 1, les règles de consentement s’appliquent. S’il est absent sur du trafic provenant d’un pays de l’UE, traitez la requête comme si le RGPD s’appliquait.
2. La chaîne est-elle présente et valide ? Une chaîne absente, vide ou corrompue équivaut à une absence de consentement. N’utilisez aucune donnée personnelle.
3. L’identifiant de vendor du DSP est-il autorisé ? Vérifiez votre propre identifiant dans les sections consentement et intérêt légitime des vendors.
4. Les finalités nécessaires sont-elles autorisées ? Vérifiez la finalité 1 avant de lire le cookie ou l’identifiant d’appareil de l’utilisateur, les finalités 3 et 4 avant d’utiliser des segments d’audience, et la finalité 7 avant toute mesure.
5. Les restrictions de l’éditeur changent-elles quelque chose ? Appliquez toute restriction définie par l’éditeur pour votre identifiant de vendor avant d’agir sur la base des réponses relatives au vendor et aux finalités.
6. Une fonctionnalité spéciale est-elle nécessaire ? N’utilisez la géolocalisation précise que si l’opt-in correspondant à cette fonctionnalité spéciale est activé.

Le résultat ne doit pas se réduire à enchérir ou ne pas enchérir. Un DSP bien conçu choisit l’un des modes suivants pour chaque requête :

Le mode contextuel mérite d’être soigné. De nombreux utilisateurs européens refusent la publicité personnalisée, et les acheteurs capables d’enchérir malgré tout sur le contexte et le format continuent d’accéder à cet inventaire. Notre article sur la publicité cookieless présente les options de ciblage qui fonctionnent encore sans données au niveau de l’utilisateur.

Les erreurs de consentement courantes dans les DSP

La plupart des problèmes de consentement relèvent de petits raccourcis d’ingénierie, et non de malentendus juridiques. Les plus fréquents :

• Vérifier les finalités mais pas le vendor. L’utilisateur a accepté la publicité personnalisée, mais pas votre entreprise. L’utilisation des données reste interdite.
• Synchroniser des identifiants utilisateur sans la finalité 1. Les cookie syncs et les consultations d’identifiants constituent un accès à l’appareil. Ils nécessitent au préalable la finalité 1 et le consentement du vendor.
• Considérer une chaîne absente comme un consentement. Lorsque le RGPD s’applique et qu’aucune chaîne n’est reçue, le comportement par défaut prudent consiste à n’utiliser aucune donnée personnelle.
• Ne lire qu’un seul emplacement OpenRTB. Certains partenaires envoient regs.gdpr, d’autres regs.ext.gdpr, d’autres encore du GPP. Lisez-les tous.
• Utiliser une liste de vendors obsolète. Actualisez votre copie de la Global Vendor List selon un calendrier régulier.
• Ne pas transmettre la chaîne en aval. Si les créations et les trackers ne reçoivent pas la chaîne via les macros, ils ne peuvent pas prendre leur propre décision, et c’est l’acheteur qui porte ce risque.
• Ne pas journaliser la décision. Si un régulateur ou un partenaire demande pourquoi les données d’un utilisateur ont été utilisées, vous devez disposer de l’état du consentement applicable au moment de l’impression.

La même rigueur s’applique aux données que vous intégrez à la plateforme. Si vous connectez une DMP à votre DSP, les segments d’audience ne doivent être activés que sur les requêtes dont la chaîne de consentement autorise le profilage pour votre identifiant de vendor.

La position des régulateurs et des tribunaux

Le TCF est un standard d’autorégulation, et non une loi, et les régulateurs l’ont examiné de près. En mars 2024, la Cour de justice de l’Union européenne a jugé, dans une affaire impliquant IAB Europe, qu’une TC string peut constituer une donnée personnelle lorsqu’elle peut être associée à un identifiant tel qu’une adresse IP. La chaîne elle-même mérite donc le même soin que les autres données utilisateur.

Pour le propriétaire d’un DSP, la leçon pratique est simple. Le TCF vous offre un langage commun, pas un bouclier juridique. Définissez votre rôle dans chaque flux de données avec un conseil juridique qualifié, documentez votre logique de consentement et assurez-vous que la plateforme se comporte conformément à cette documentation.

Ce qui change lorsque vous possédez le DSP

Lorsque vous achetez via la plateforme d’un tiers, c’est sa logique de consentement qui détermine le comportement de vos campagnes en Europe, et vous ne pouvez souvent pas comprendre pourquoi votre portée européenne est inférieure aux attentes.

Lorsque vous possédez la plateforme, le consentement devient un élément que vous pouvez configurer et auditer :

• Vous décidez du niveau de rigueur du comportement par défaut en l’absence de consentement, et de l’activation ou non de l’enchère contextuelle sur les requêtes sans consentement au profilage.
• Vous pouvez rapporter la portée européenne par état de consentement, afin que vos clients comprennent pourquoi une campagne d’audience ne monte pas en puissance de la même manière en France qu’au Brésil.
• Vous contrôlez la durée de conservation des enregistrements de consentement et des logs, ainsi que les personnes qui peuvent y accéder.
• Vous choisissez les partenaires d’inventaire à connecter en fonction de la fiabilité avec laquelle ils transmettent les indicateurs gdpr et les chaînes de consentement.

Le DSP d’AdTech Europe comprend un module Consent Management et TCF qui s’intègre au Transparency and Consent Framework de l’IAB pour gérer les signaux de consentement dans les régions soumises au RGPD, afin que le ciblage et la mesure respectent à la fois les autorisations des annonceurs et celles des éditeurs.

Prêt à acheter dans le respect du consentement sur votre propre DSP ?

AdTech Europe fournit une technologie de demand-side platform aux agences, ad networks, équipes d’achat média et entrepreneurs de l’adtech qui souhaitent posséder leur stack d’achat plutôt que la louer. La plateforme fonctionne sous votre propre marque et votre propre domaine, lit les signaux de consentement transmis par l’inventaire connecté et vous laisse la maîtrise des règles d’enchère.

En novembre 2026, vous pouvez louer le DSP pour $500 par mois (les formules mensuelles comprennent des frais de mise en place uniques équivalents à un mois) ou $5,000 par an, l’acquérir sous licence pour $25,000 en une fois ou en 12 versements, ou devenir propriétaire de l’intégralité du code source pour $50,000. Les tarifs actuels dans toutes les devises prises en charge figurent sur la page Tarifs, et la page White Label DSP présente l’option en marque blanche. Pour concevoir une configuration européenne adaptée à vos clients et à vos sources d’inventaire, planifiez un rendez-vous stratégique programmatic avec notre équipe.

FAQ

Qu’est-ce qu’une chaîne de consentement TCF ?

Une chaîne de consentement TCF, ou TC string, est un texte encodé généré par une plateforme de gestion du consentement après qu’un utilisateur a exprimé un choix en matière de confidentialité. Elle enregistre les finalités et les vendors autorisés par l’utilisateur, et accompagne les requêtes publicitaires afin que chaque entreprise de la chaîne puisse la vérifier.

Où se trouve la chaîne de consentement dans une bid request OpenRTB ?

En OpenRTB 2.6, elle se trouve dans le champ user.consent, le champ regs.gdpr étant défini à 1 lorsque le RGPD s’applique. Les intégrations plus anciennes en OpenRTB 2.5 utilisent user.ext.consent et regs.ext.gdpr. Certains partenaires l’envoient également dans une chaîne GPP, dans regs.gpp.

Que doit faire un DSP en l’absence de chaîne de consentement ?

Si le RGPD s’applique et qu’aucune chaîne valide n’est reçue, le DSP ne doit utiliser aucune donnée personnelle. Cela signifie aucun identifiant utilisateur, aucun segment d’audience et aucune cookie sync. Selon son conseil juridique, il peut ignorer la requête ou n’enchérir que sur des signaux non personnels.

De quelles finalités TCF un DSP a-t-il besoin pour le retargeting ?

Le retargeting repose sur des profils : il nécessite donc le consentement à la finalité 3, créer des profils pour une publicité personnalisée, et à la finalité 4, utiliser des profils pour sélectionner une publicité personnalisée. Il nécessite également la finalité 1 pour lire le cookie ou l’identifiant d’appareil de l’utilisateur, ainsi que le consentement pour l’identifiant de vendor du DSP lui-même.

Quelle est la version actuelle du TCF ?

La version actuelle est le TCF v2.3, lancé par IAB Europe en avril 2025. Il rend obligatoire la section Disclosed Vendors de la chaîne de consentement. Les participants avaient jusqu’au 28 février 2026 pour l’adopter.

Le TCF est-il imposé par la loi ?

Non. Le TCF est un standard sectoriel volontaire géré par IAB Europe. Ce sont le RGPD et la directive ePrivacy qui constituent la loi. Le TCF est un moyen commun permettant aux entreprises de recueillir, transmettre et respecter le consentement afin de se conformer à ces textes à la vitesse des enchères.

Un DSP peut-il enchérir sans consentement à la publicité personnalisée ?

Souvent, oui. Si l’identifiant de vendor du DSP est autorisé mais que les finalités de profilage sont refusées, il peut enchérir à partir de données limitées telles que le site, l’application, le format publicitaire et la localisation approximative. Cette enchère contextuelle préserve la portée européenne tout en respectant le choix de l’utilisateur.