Réponse courte : IAB Europe a publié TCF 2.4 le 23 juillet 2026. Les implémentations Web doivent être migrées avant le 23 octobre 2026 ; pour les applications mobiles et CTV, la date limite est le 23 février 2027. La version de format TC-String reste 2 et la version de politique TCF reste 5. TCF 2.4 n'introduit donc pas un nouveau format de chaîne global. Les points clés sont les directives mises à jour, en particulier le traitement plus strict de l'intérêt légitime des vendeurs.
L'essentiel
- TCF 2.4 est la spécification actuelle ; le délai de migration est séparé par environnement.
- Web : 23 octobre 2026. Application mobile et CTV : 23 février 2027.
- La version binaire TC-String reste 2 ;
tcfPolicyVersionreste 5. - Les consentements déjà valides ne nécessitent pas automatiquement un nouveau consentement en raison seul du changement de version. Une nouvelle demande peut cependant être nécessaire pour d'autres raisons, par exemple en cas de modification des vendeurs, des finalités ou des textes juridiques.
- Le segment
DisclosedVendorsest devenu obligatoire avec TCF 2.3 et se poursuit sous 2.4. Ce n'est pas une nouvelle fonctionnalité 2.4. - Les vendeurs ne peuvent pas signaler l'intérêt légitime uniquement sur la base des Special Purposes. Cette règle 2.4 s'applique déjà depuis avril 2026.
- L'enregistrement et la certification sont des déclarations différentes. Vérifiez également pour quel environnement une CMP est enregistrée.
Qu'est-ce qui change avec IAB TCF 2.4 ?
TCF 2.4 met à jour les directives et les spécifications techniques du Transparency and Consent Framework. Pour les implémenteurs, il est particulièrement important de ne pas confondre les numéros de version avec les champs du TC-String : le segment Core continue d'utiliser la version de format 2, et la version de politique reste 5. Les intégrations ne doivent donc ni coder une version de chaîne fictive « 2.4 » ni rejeter tous les signaux existants uniquement en raison du changement de version.
Le changement le plus important en pratique concerne Vendor Legitimate Interest. Un vendeur ne peut définir un bit LI que s'il existe au moins une finalité de traitement autorisée pour cela. Les Special Purposes seules ne suffisent pas. Les CMP doivent appliquer cette invariante lors de la génération, de la restauration et de la révocation des signaux.
Disclosed Vendors : introduit en 2.3, toujours requis en 2.4
Le segment DisclosedVendors documente quels vendeurs ont été réellement affichés à la personne. Il est devenu obligatoire avec TCF 2.3 et reste une partie d'une implémentation 2.4 correcte. Lors de la migration vers 2.4, le segment ne doit donc pas être réinventé, mais vérifié par rapport à la liste des vendeurs visibles :
- Chaque vendeur contenu dans le segment doit avoir été divulgué dans l'interface de consentement.
- Les vendeurs non affichés, supprimés ou inactifs ne doivent pas être signalés comme divulgués.
- L'ensemble des vendeurs dans la configuration, l'interface,
DisclosedVendorsetTCDatadoit être traçable et cohérent.
Délais par environnement
| Environnement | Délai de migration vers TCF 2.4 |
|---|---|
| Web | 23 octobre 2026 |
| Application mobile | 23 février 2027 |
| CTV | 23 février 2027 |
Un enregistrement Web ne couvre pas automatiquement les applications mobiles ou CTV. Vérifiez l'entrée de la CMP dans la liste officielle des CMP et les environnements mentionnés. Biscotti CMP est exploité par Campcruisers GmbH et est enregistré avec l'ID CMP 497 pour Web. Aucune enregistrement pour application native ou CTV n'est affirmé.
Migration progressive vers TCF 2.4
1. Vérifier le statut d'enregistrement et d'environnement
Comparez l'ID CMP, l'entité juridique et les environnements enregistrés avec la liste officielle des CMP. Ne vous fiez pas à un logo ou à une formulation générale comme « conforme IAB ».
2. Lier la GVL actuelle et la sélection des vendeurs
Chargez une Global Vendor List actuelle et déterminez les vendeurs réellement utilisés pour le site Web ou l'application spécifique. L'interface et l'état de consentement généré doivent être dérivés du même ensemble de vendeurs.
3. Implémenter la règle Vendor-LI en fail-closed
Ne générez pas de signal Vendor-LI si le vendeur ne déclare que des Special Purposes ou s'il ne reste aucune finalité LI autorisée. Vérifiez cette règle également après Reject, révocation, changement de GVL et restauration d'un état enregistré.
4. Maintenir la sémantique TC-String
Continuez à coder la version de format TC-String 2 et la version de politique 5. Conservez le segment DisclosedVendors obligatoire. Ne modifiez pas les champs de version API uniquement parce que la spécification du framework s'appelle 2.4.
5. Décider du reconsent de manière ciblée
Un changement de version seul n'est pas une raison de reconsent global. Vérifiez plutôt si les finalités, les vendeurs, les bases juridiques, les Publisher Restrictions ou les informations présentées à la personne ont changé de manière substantielle. Documentez la décision.
6. Tester les transitions d'état complètes
Testez au minimum Accept All, Reject All, sélection granulaire, intérêt légitime, révocation, réouverture, redémarrage du navigateur et une mise à jour de GVL. Décodez les chaînes générées indépendamment et comparez les ensembles de vendeurs et de finalités.
Liste de contrôle technique
__tcfapi('ping', 2, ...)signale des données CMP et de politique cohérentes.- La version de format TC-String est 2 et
tcfPolicyVersionest 5. DisclosedVendorscorrespond à la liste des vendeurs réellement visible.- Vendor-LI n'est jamais défini sans finalité LI autorisée.
- Reject et révocation suppriment les signaux de consentement et LI non autorisés.
- Les états enregistrés ne sont acceptés que s'ils correspondent à la configuration actuelle.
- L'ID CMP et l'environnement enregistré correspondent à la liste officielle des CMP.
- Les versions Web, application mobile et CTV sont publiées séparément.
Les utilisateurs existants doivent-ils être interrogés à nouveau ?
Pas automatiquement. La désignation de version TCF 2.4 ne change ni le format TC-String ni le numéro de version de politique à elle seule. Cependant, un nouveau consentement est requis si la décision précédente ne représente plus correctement le traitement actuel ou si la personne doit recevoir de nouvelles informations substantielles. La décision doit être prise en fonction du changement de configuration réel et avec des conseils juridiques.
Erreurs courantes
- Coder TCF 2.4 comme une nouvelle version de format TC-String.
- Augmenter
tcfPolicyVersionsans base normative. - Décrire Disclosed Vendors à tort comme un changement nouveau 2.4.
- Traiter les Special Purposes comme une base suffisante pour Vendor-LI.
- Présenter un enregistrement Web comme un enregistrement d'application mobile ou CTV.
- Utiliser « enregistré », « validé » et « certifié » comme synonymes.
- Tester uniquement le chemin Accept All et omettre Reject, révocation ou redémarrage.
Conclusion
La migration vers TCF 2.4 n'est pas un simple changement de texte. Elle nécessite une publication planifiée par environnement, des signaux Vendor-LI corrects et la preuve que les vendeurs visibles, l'état enregistré et le TC-String sont cohérents. Ceux qui distinguent correctement la version de format 2, la version de politique 5 et l'historique de Disclosed Vendors évitent les erreurs de migration les plus courantes.
FAQ
TCF 2.4 est-il une nouvelle version de format TC-String ?
Non. Le champ de version du TC-String reste 2 ; la version du framework 2.4 ne doit pas être écrite dans ce champ.
La version de politique TCF change-t-elle ?
Non. Pour TCF 2.4, tcfPolicyVersion reste à 5.
Disclosed Vendors est-il nouveau dans TCF 2.4 ?
Non. Le segment est devenu obligatoire avec TCF 2.3 et se poursuit en 2.4.
TCF 2.4 nécessite-t-il toujours un reconsent ?
Non. Les changements réels du traitement et de l'information utilisateur sont décisifs, pas seulement le numéro de version.
Biscotti CMP est-il enregistré pour les applications mobiles ou CTV ?
L'entrée d'enregistrement actuelle de Campcruisers GmbH, ID CMP 497, couvre Web. Il n'en découle aucun enregistrement pour les applications mobiles ou CTV.
Sources et références
- IAB Europe, TCF Policies v5.0.b et Specifications v2.4 : https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, liste des CMP : https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, Consent String and Vendor List Formats : https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Cet article explique les aspects techniques et organisationnels et ne constitue pas un conseil juridique.