The Short Version

TCF v2.3 est une évolution de v2.2, pas une ré-architecture. Le format de la TC String reste compatible, les finalités et fonctionnalités existantes sont conservées et la plupart des exigences d’interface côté éditeur sont reconduites telles quelles. Les changements significatifs se concentrent sur quatre axes :

• Des règles plus claires sur la façon dont les CMP doivent présenter les informations sur les vendors et les durées de conservation.
• De nouvelles exigences pour des contrôles granulaires en deuxième couche, réclamés par les régulateurs depuis la décision de l’Autorité belge (DPA) de 2022.
• Un renforcement de l’application des Policies concernant les dark patterns, l’égalité de mise en avant et l’interdiction des options pré-cochées.
• Des ajustements du schéma de la Global Vendor List (GVL) et du flux d’information sur les vendors.

Why v2.3 Exists

Chaque version du TCF résulte d’un compromis entre trois publics : les éditeurs qui doivent continuer à monétiser, les vendors qui ont besoin d’une interface technique stable, et les régulateurs qui identifient en continu des lacunes de conformité. La v2.3 répond directement à trois types de pression :

1. Les mesures d’application contre l’usage abusif de la « legitimate interest » sous v2.2. Plusieurs DPA européennes ont estimé que trop de vendors revendiquaient la LI pour des finalités pour lesquelles seul le consentement était juridiquement valable. La v2.3 durcit la transparence sur la base juridique déclarée par les vendors et la fait apparaître plus tôt dans l’interface de consentement.
2. Les plaintes persistantes relatives aux dark patterns. Les Policies mises à jour rendent la règle d’égalité de mise en avant plus explicite et referment les failles autour des boutons pré-cochés sur la deuxième couche.
3. Les retours opérationnels de grandes CMP et de gros éditeurs. La v2.2 avait introduit plusieurs mentions obligatoires difficiles à implémenter proprement sur mobile et en CTV. La v2.3 rationalise l’ensemble des informations à afficher et permet d’en placer davantage dans une vue en couches.

TC String Compatibility

La TC String elle-même reste rétrocompatible. Une CMP v2.3 produit des chaînes que des vendors v2.2 peuvent lire, et un vendor v2.3 peut consommer des chaînes v2.2 pendant la période de transition. L’indicateur de version dans le segment central de la chaîne identifie la version des Policies avec laquelle la CMP revendique sa conformité, tandis que le pointeur de version de la GVL évolue, lui, de manière indépendante.

Concrètement, cela signifie que vous n’avez pas besoin de mettre à jour tous vos vendors en même temps, ni de forcer un nouvel événement de consentement pour chaque utilisateur le jour où vous déployez la v2.3. Un déploiement progressif est explicitement prévu.

Key Technical Changes

1. Vendor Disclosure and Retention

La v2.3 impose aux CMP d’afficher la durée de conservation des données déclarée par chaque vendor dans l’interface en couches, et pas seulement dans une liste de vendors séparée. Cette durée figurait déjà dans la GVL, mais la v2.2 n’imposait pas que l’utilisateur la voie à côté des finalités. La v2.3 comble cette lacune, les régulateurs considérant que l’utilisateur ne peut pas faire un choix éclairé sans savoir combien de temps ses données seront conservées.

2. Stricter Second-Layer Controls

Sur la deuxième couche — la vue « gérer les préférences » — la v2.3 précise que les interrupteurs relatifs aux finalités et vendors non essentiels doivent être, par défaut, désactivés. Les cases pré-cochées ou curseurs activés par défaut constituent une violation des Policies, même si l’utilisateur ne clique jamais explicitement sur « tout accepter ». Les CMP qui s’appuyaient jusqu’ici sur un schéma de « soft opt-in » devront réimplémenter la deuxième couche.

3. Equal Prominence Enforcement

La règle d’égalité de mise en avant existe depuis la v2.1, mais la v2.3 en réduit la marge d’interprétation : le contrôle « tout refuser » doit se trouver au même niveau, avec le même poids visuel, la même classe de contraste de couleur et la même distance d’interaction que « tout accepter ». Dissimuler le refus derrière un lien, un bouton plus petit ou un écran secondaire est désormais clairement considéré comme une non-conformité, et non plus comme une simple question d’appréciation.

4. Legitimate Interest Signalling

Les vendors qui déclarent la legitimate interest comme base juridique sous v2.3 doivent désormais également indiquer pour quelles finalités ils ont réalisé une Legitimate Interests Assessment et lesquelles ont été menées à terme. Les CMP sont tenues de faire remonter ces informations dans l’interface afin que l’utilisateur puisse formuler son objection en connaissance de cause. En pratique, cela signifie que le flux d’« objection » affiche désormais, vendor par vendor, le statut de LIA, plutôt qu’un simple interrupteur générique.

5. GVL Schema Updates

Le schéma de la Global Vendor List ajoute des champs pour la granularité de conservation, le statut LIA et un lien lisible par machine vers la section pertinente de la politique de confidentialité de chaque vendor pour les finalités déclarées. Les CMP qui mettent en cache la GVL doivent mettre à jour leur parseur de schéma pour prendre en compte ces nouveaux champs avant de pointer vers une GVL v2.3.

Policy Changes That Affect UX

Le TCF est à la fois une spécification technique et un ensemble de Policies. Plusieurs changements de Policies en v2.3 impactent directement l’interface de consentement :

• Fin de « continuer sans accepter » comme équivalent au refus, sauf si ce contrôle présente le même aspect visuel que le bouton d’acceptation et produit la même TC String qu’un refus complet.
• Parité linguistique : l’information de consentement doit être disponible dans toutes les langues proposées par le site, et pas uniquement dans la langue du navigateur de l’utilisateur. Les CMP doivent permettre une surcharge manuelle de la locale.
• Accès permanent : l’utilisateur doit pouvoir accéder au centre de préférences depuis chaque page du site, et pas seulement depuis la page d’atterrissage. Le lien d’accès doit être formulé de manière à ce qu’un utilisateur non expert comprenne qu’il concerne le consentement.

What Publishers Must Do

1. Confirmer le support v2.3 de votre CMP. Demandez la date exacte de disponibilité de la version certifiée v2.3 et la version que la CMP déclarera dans la chaîne.
2. Mettre à jour la logique de cache de votre GVL. Si vous hébergez un miroir de GVL, mettez à jour le parseur de schéma avant le déploiement de la GVL v2.3, sous peine de voir votre CMP incapacité à valider les nouveaux vendors.
3. Réécrire votre interface de deuxième couche pour que tous les interrupteurs soient désactivés par défaut, que l’égalité de mise en avant soit respectée visuellement et que les durées de conservation apparaissent à côté des finalités.
4. Relancer votre audit de conformité. Les infractions les plus faciles à identifier pour les régulateurs concernent les dark patterns que la v2.3 explicite désormais. Corrigez-les avant votre prochain contrôle.
5. Planifier une stratégie de re-sollicitation du consentement. Même si la TC String reste compatible, les Policies encouragent les éditeurs à redemander le consentement lorsque l’étendue ou la transparence du traitement évoluent de manière significative. Décidez si votre déploiement v2.3 constitue un changement « substantiel » pour votre audience.

What Vendors Must Do

1. Mener une Legitimate Interests Assessment pour chaque finalité pour laquelle vous déclarez une LI, et transmettre le résultat dans la GVL.
2. Mettre à jour votre entrée dans la GVL avec les champs de schéma v2.3 : granularité de conservation, déclaration LIA et lien profond vers la politique de confidentialité.
3. Valider votre parseur de TC String à l’aide des chaînes de référence v2.3 fournies par IAB Europe.
4. Coordonner avec vos partenaires CMP une date de bascule commune, afin que la première requête d’achat portant une chaîne v2.3 n’arrive pas chez un vendor limité à la v2.2.

Common Migration Pitfalls

• Traiter la v2.3 comme une opportunité de refonte graphique. Il peut être tentant de regrouper mise à jour de marque et passage en v2.3, mais cela complique les tests de conformité. Déployez d’abord une version v2.3 centrée sur la conformité, puis itérez sur le design.
• Oublier l’obligation d’affichage de la durée de conservation. Les équipes mettent souvent à jour la vue « liste de vendors », mais oublient que la conservation doit aussi figurer dans la vue en couches, finalité par finalité.
• Considérer que la seule TC String suffit. Une chaîne techniquement conforme issue d’une interface non conforme reste non conforme. Les régulateurs ont à plusieurs reprises sanctionné des acteurs dont les chaînes étaient correctes, mais dont les bannières cachaient le bouton de refus.
• Laisser la CTV et le mobile hors périmètre. La v2.3 s’applique à tous les environnements où des signaux TCF sont générés. Les éditeurs qui mettent à jour le web mais pas leurs applications CTV ou mobiles créent un environnement hybride non conforme.

Conclusion

TCF v2.3 n’est pas une rupture radicale avec la v2.2, mais c’est un resserrement significatif des règles qui structurent l’écosystème programmatique européen. La trajectoire est claire : plus de transparence, moins de dark patterns, un contrôle plus granulaire pour l’utilisateur et une moindre tolérance pour les cas limites qui passaient auparavant. Les CMP et éditeurs qui traitent la v2.3 comme un simple correctif rapide se retrouveront à nouveau face au régulateur. Ceux qui profitent de la migration pour assainir l’UX de deuxième couche, abandonner les raccourcis basés sur la legitimate interest et reconstruire un vrai parcours de consentement à égalité de mise en avant disposeront, à l’arrivée, d’un inventaire qui se monétise réellement à l’ère de la v2.3 — et d’un dispositif de consentement capable de résister à ce que la v2.4 apportera ensuite.