IAB TCF v2.4 : Ce que les CMP doivent changer d'ici octobre 2026

IAB TCF v2.4 a maintenant un calendrier de déploiement confirmé. IAB Europe prévoit de publier les spécifications techniques finales et la liste mondiale des fournisseurs (GVL) mise à jour le 23 juillet 2026. Les CMP ont ensuite jusqu'au 23 octobre 2026 pour les mises en œuvre web et jusqu'au 23 février 2027 pour les environnements d'applications mobiles et de télévision connectée. Si votre pile de consentement participe au TCF, il s'agit d'un projet de mise en œuvre—pas d'une simple mise à jour de bandeau.

Les changements se situent dans la politique TCF v5.0.b et les spécifications techniques v2.4. Ils affectent la manière dont les CMP expliquent les fonctionnalités, divulguent l'étendue d'un choix, soutiennent le consentement multi-appareils et encodent un cas de signalisation de fournisseur étroit. Pour un aperçu du cadre actuel, consultez le aperçu de la conformité IAB TCF de Conzent.

Points clés

Les dates confirmées donnent aux CMP et aux éditeurs une séquence courte mais réalisable : inspecter le package final en juillet, terminer les changements web en octobre, et garder mobile et CTV sur un plan séparé en février. Les points les plus importants sont :

• 23 juillet 2026 : IAB Europe prévoit de publier les spécifications techniques v2.4 et la mise à jour correspondante de la GVL.
• 23 octobre 2026 : Les CMP doivent mettre en œuvre les nouvelles divulgations dans les environnements web.
• 23 février 2027 : la date limite équivalente s'applique aux environnements d'applications mobiles et de CTV.
• Les interfaces CMP ont besoin d'explications et d'illustrations standard plus claires pour les fonctionnalités.
• La couche initiale doit indiquer aux utilisateurs si un choix est spécifique à un service, spécifique à un groupe ou multi-appareils.
• La prévisualisation technique supprime un contournement d'intérêt légitime obsolète pour les fournisseurs qui déclarent uniquement des objectifs spéciaux ; les équipes doivent vérifier le libellé final le 23 juillet.
• La participation au TCF soutient le travail de conformité, mais ne remplace pas l'évaluation légale propre à un éditeur ou à un fournisseur.

Les trois dates à inscrire dans votre plan de livraison

La confirmation d'IAB Europe datée du 16 juillet 2026 établit trois jalons distincts. Les traiter comme une seule date limite comprimerait la découverte, la mise en œuvre, la traduction et l'assurance qualité dans la même fenêtre de publication.

La séquence pratique est :

1. 23 juillet 2026 — publication des spécifications et de la GVL. Téléchargez les fichiers finaux, comparez-les avec le matériel de commentaires publics, et transformez chaque différence confirmée en une tâche à prendre en charge.
2. 23 octobre 2026 — date limite web. Les CMP web en production doivent exposer les nouvelles divulgations et suivre les exigences de signalisation finales v2.4.
3. 23 février 2027 — date limite pour les applications et CTV. Les SDK natifs, les délais de mise en magasin, les interfaces de télévision et les tests d'accessibilité spécifiques aux appareils obtiennent une date ultérieure, pas une exemption.

L'écart entre la publication et la date limite web est de trois mois. Cela suffit pour une mise à jour contrôlée si les équipes commencent par un diff de spécification et une matrice de test. C'est serré si le travail commence par une refonte tardive du bandeau.

La séquence confirmée sépare le matériel source, la mise en œuvre web et le déploiement des applications/CTV. Planifiez et testez-les comme trois jalons plutôt qu'un seul lancement.

Qui doit agir—et qui devrait encore prêter attention

Les délais s'appliquent aux mises en œuvre TCF en direct et aux CMP responsables. Les politiques TCF officielles couvrent à la fois les CMP commerciales servant des clients et les CMP privées opérées par un éditeur pour ses propres propriétés. Les éditeurs restent responsables de l'interface utilisateur du cadre présentée sur leurs propriétés numériques, même lorsqu'un tiers fournit la CMP.

Vous devriez inscrire ce travail dans un plan de livraison si vous :

• construisez ou exploitez une CMP TCF enregistrée ;
• utilisez une CMP commerciale sur un site web financé par la publicité programmatique ;
• maintenez une CMP d'éditeur privée ;
• expédiez la même expérience de consentement sur le web, l'application et la CTV ;
• dépendiez des signaux TCF pour les fournisseurs, les enchères, la mesure ou les publicités personnalisées.

Un site web qui ne participe pas au TCF n'est pas automatiquement tenu de mettre en œuvre le TCF v2.4. Il peut encore avoir besoin d'un mécanisme de consentement valide en vertu de la loi applicable ou des règles de la plateforme. La version du cadre et le devoir légal d'obtenir le consentement sont des questions connexes, mais pas la même question.

Cette distinction est importante pour les produits éditeurs de Google. Google exige une CMP certifiée intégrée au TCF pour les publicités personnalisées diffusées via AdSense, Ad Manager ou AdMob aux utilisateurs dans l'EEE, au Royaume-Uni et en Suisse. Google indique également que son examen de certification ne vérifie pas la conformité totale avec le TCF ou la loi sur la vie privée applicable.

Ce que les utilisateurs verront différemment dans une CMP

Le changement le plus visible est un effort pour expliquer les fonctionnalités plus clairement. Dans le TCF, un objectif décrit pourquoi les données sont traitées et donne à l'utilisateur un choix de consentement ou d'objection lorsque cela est applicable. Une fonctionnalité décrit une méthode de traitement utilisée dans la poursuite d'un ou plusieurs objectifs ; elle ne comporte pas un contrôle utilisateur séparé de la même manière.

Selon la politique v5.0.b et la mise à jour GVL confirmée, les CMP doivent tenir compte de :

• un nouveau champ standardTexts contenant l'explication standard pour les fonctionnalités ;
• des illustrations pour chaque fonctionnalité dans la GVL mise à jour ;
• l'explication standard de la fonctionnalité affichée avec le nom standard et le texte convivial complet ;
• des informations sur les fonctionnalités qui ne sont pas visuellement associées à des contrôles qui ne peuvent pas réellement désactiver la fonctionnalité ;
• un nouveau nom et des conseils pour la fonctionnalité spéciale 2.

Le nom mis à jour pour la fonctionnalité spéciale 2 est “Identifier les appareils en fonction des informations demandées activement.” Les conseils de politique couvrent explicitement les caractéristiques collectées via JavaScript ou API—telles que les polices, la résolution d'écran et les plugins—et les informations demandées activement via les indices de client User-Agent. Les utilisateurs doivent donner leur consentement avant qu'un fournisseur n'utilise cette fonctionnalité spéciale.

Pourquoi cela va au-delà d'une simple mise à jour de texte

Une CMP qui code en dur des étiquettes ou suppose l'ancienne forme de la GVL pourrait échouer même si le bandeau a toujours l'air normal. Les équipes produit doivent tracer les nouvelles données de l'ingestion à chaque couche d'interface utilisateur, étiquette d'accessibilité, enregistrement de fournisseur mis en cache et test de régression. Le principe de conception sûr est simple : rendre le sens officiel avec précision, rendre la présence ou l'absence d'un choix utilisateur indiscutable, et ne pas transformer une fonctionnalité explicative en un faux interrupteur.

Le consentement multi-appareils nécessite une portée explicite

La politique v5.0.b ajoute une portée multi-appareils aux définitions du cadre. Une base légale peut s'appliquer à travers des points d'accès pour le même service ou groupe—par exemple, un site web et une application mobile utilisés par un compte authentifié—lorsque la mise en œuvre soutient cette portée. La couche initiale de l'interface utilisateur du cadre doit indiquer à l'utilisateur si le choix de consentement est spécifique à un service, spécifique à un groupe et/ou multi-appareils.

Cette commodité crée une responsabilité produit. Une CMP a besoin d'un moyen défini pour résoudre un choix fait sur un appareil avant la connexion par rapport aux préférences déjà stockées sur le compte. Elle doit également garder le refus et le retrait aussi utilisables que l'acceptation dans la même portée.

La recommandation de la CNIL de janvier 2026 sur les dispositifs croisés est un guide réglementaire français plutôt qu'une règle TCF applicable à l'échelle de l'UE, mais c'est un point de référence utile pour la mise en œuvre. La CNIL recommande que :

• l'acceptation, le refus et le retrait aient la même portée multi-appareils ;
• les utilisateurs soient informés avant de choisir que la préférence s'appliquera aux appareils connectés à leur compte ;
• un court rappel soit affiché lorsque l'utilisateur se connecte sur un nouvel appareil ;
• les conflits soient gérés de manière transparente, soit en priorisant le choix le plus récent avant la connexion, soit la préférence du compte.

Documentez la règle de conflit choisie et testez les deux directions. Un magasin de préférences techniquement cohérent peut toujours créer une expérience trompeuse si les utilisateurs ne sont pas informés de quel choix l'emporte.

Ce qui change en coulisses

Le package technique est prévu pour le 23 juillet, donc les équipes de mise en œuvre devraient utiliser le matériel actuel pour se préparer—pas pour prétendre que le diff final a déjà été vérifié. Le résumé des commentaires publics de l'IAB Tech Lab identifie deux domaines d'ingénierie concrets.

Tout d'abord, la GVL obtient l'objet standardTexts utilisé pour les explications des fonctionnalités. Les analyseurs, types, caches, API et code de rendu doivent accepter et préserver le nouveau champ. Un repli gracieux est utile pour la résilience opérationnelle, mais il ne doit pas omettre silencieusement une divulgation requise après la date limite.

Deuxièmement, la prévisualisation supprime un contournement pour les fournisseurs qui déclarent uniquement des objectifs spéciaux. Depuis que le TCF v2.3 a rendu le segment disclosedVendors obligatoire, ces fournisseurs peuvent déterminer s'ils ont été divulgués à partir de ce segment. La prévisualisation supprime donc l'exigence de placer les fournisseurs uniquement à but spécial dans la section d'intérêt légitime du fournisseur de la chaîne TC.

Une règle de mise en œuvre prudente

Préparez les tests maintenant, puis liez le comportement de production au texte final v2.4 publié le 23 juillet. En particulier, comparez la spécification finale de la chaîne TC, le matériel API CMP, le schéma GVL, les traductions et les exemples avec la prévisualisation. Enregistrez la version que vous avez testée. “Nous avons suivi l'article de juin” n'est pas une piste d'audit utile lorsque une spécification finale existe.

Une liste de contrôle de préparation au TCF v2.4 en sept points

La date limite est plus facile à gérer lorsque chaque exigence a un propriétaire et un test d'acceptation observable. Commencez avec cette liste de contrôle et développez-la pour votre architecture.

1. Inventoriez chaque surface TCF. Listez les propriétés web, les expériences intégrées, les applications mobiles, les applications CTV, les paramètres de consentement, les centres de préférences de compte, les SDK et les consommateurs de GVL mis en cache. Marquez chacune comme web, application ou CTV pour la planification des délais.
2. Diff du 23 juillet. Comparez la spécification finale, le schéma GVL, les traductions, les illustrations et les références de politique avec votre mise en œuvre actuelle v2.3 et la prévisualisation des commentaires publics.
3. Mettez à jour l'ingestion de la GVL. Vérifiez que standardTexts, les illustrations, la fonctionnalité spéciale 2 renommée et les futurs champs inconnus survivent à l'analyse, au stockage, aux API et à la mise en cache.
4. Testez l'interface utilisateur. Vérifiez que les explications des fonctionnalités apparaissent à côté des bonnes informations, ne ressemblent pas à des contrôles, restent lisibles avec un zoom et une technologie d'assistance, et fonctionnent dans toutes les langues prises en charge. Examinez l'expérience du bandeau de cookies comme un flux complet plutôt qu'une seule première couche.
5. Testez la signalisation. Créez des fixtures pour les fournisseurs uniquement à but spécial et vérifiez les règles finales d'encodage et de décodage v2.4 à travers la CMP, les fournisseurs en aval et tout traitement de consentement côté serveur.
6. Définissez le comportement multi-appareils. Documentez la portée, les exigences d'identité, le stockage, la propagation, le retrait et la règle utilisée lorsque les choix d'appareil et de compte sont en conflit. Testez les chemins d'acceptation, de refus, de changement, de déconnexion, de nouvel appareil et de suppression de compte.
7. Expédiez et observez. Publiez les changements web avant le 23 octobre avec une surveillance des échecs de GVL, des erreurs de chaîne de consentement, des divulgations manquantes et des changements inhabituels dans les taux de choix. Gardez les publications d'applications et de CTV sur un plan séparément détenu pour le 23 février 2027.

L'auto-hébergement ne supprime pas ces responsabilités. Si vous exploitez OCI sur votre propre infrastructure, vous contrôlez la fenêtre de mise à niveau et pouvez inspecter la mise en œuvre, mais vous êtes également responsable de la révision, du déploiement et de la vérification de la spécification finale.

Ce que les éditeurs devraient demander à leur fournisseur de CMP

Les éditeurs n'ont pas besoin de mettre en œuvre chaque changement de parseur eux-mêmes, mais ils ne devraient pas accepter “prêt pour le TCF” comme une réponse complète. Demandez des preuves liées à vos environnements et dates réels.

Des questions utiles incluent :

• Quelles versions de politique TCF et de spécifications techniques sont en production aujourd'hui ?
• Quand le support web pour v2.4 sera-t-il généralement disponible, et quelle action client est requise ?
• Comment les nouvelles explications de fonctionnalités, illustrations et texte de la fonctionnalité spéciale 2 sont-ils rendus et traduits ?
• Le produit prend-il en charge la portée multi-appareils, et comment exactement les choix conflictuels sont-ils résolus ?
• Quelles versions de SDK web, application et CTV contiennent les changements ?
• Quels tests automatisés et manuels couvrent le comportement final de la chaîne TC v2.4 ?
• Les utilisateurs devront-ils revoir l'interface utilisateur du cadre, et quelle est la source de cette décision ?

Demandez au fournisseur de séparer la conformité au cadre, la certification Google et le soutien général à la loi sur la vie privée. Ils se chevauchent, mais aucun n'est la preuve de l'autre. Vos propres obligations de contrôleur, d'éditeur et de fournisseur nécessitent toujours une évaluation de conformité au RGPD appropriée au traitement que vous effectuez.

Ce que le TCF v2.4 ne signifie pas

Le TCF v2.4 est une mise à jour du cadre industriel, pas un nouveau statut et pas un mandat universel pour chaque site web. La propre politique d'IAB Europe décrit la participation comme volontaire et indique que le cadre n'est pas un substitut à la prise de responsabilité par les participants individuels pour leurs obligations légales.

Gardez ces limites visibles dans la communication interne et avec les clients :

• respecter la date limite du TCF ne rend pas en soi un flux de consentement légal ;
• la certification CMP de Google n'est pas équivalente à une conformité totale au TCF ou à la loi sur la vie privée ;
• une chaîne TC techniquement valide ne prouve pas que l'utilisateur a reçu des informations claires ou a fait un choix valide ;
• la commodité multi-appareils ne justifie pas une portée cachée ou une propagation unidirectionnelle ;
• une nouvelle étiquette standard ne corrige pas une interface trompeuse autour d'elle.

Utilisez un conseiller juridique pour des conclusions spécifiques à la juridiction. Utilisez la spécification, la politique et les conseils des régulateurs comme des entrées séparées aux exigences produit plutôt que de les mélanger en un vague ticket de “conformité”.

Questions fréquemment posées

Que signifie IAB TCF ?

IAB TCF signifie le Cadre de Transparence et de Consentement de l'IAB Europe. Il standardise la manière dont les éditeurs, CMP et fournisseurs participants divulguent le traitement des données, capturent les choix pertinents et communiquent les signaux de consentement, d'objection et de transparence dans l'écosystème de la publicité numérique.

Qu'est-ce que le TCF v2 3 ?

Le TCF v2.3 est la version technique immédiatement avant le v2.4. Parmi d'autres changements, il a rendu le segment disclosedVendors obligatoire. Cela est important pour le v2.4 car le projet de commentaire public utilise le segment obligatoire pour supprimer l'ancien contournement d'intérêt légitime pour les fournisseurs uniquement à but spécial.

Qu'est-ce que la liste TCF ?

Le terme fait généralement référence à la Liste Mondiale des Fournisseurs, ou GVL. L'IAB Europe la maintient pour les fournisseurs TCF enregistrés, et les CMP utilisent ses déclarations, texte standard et données connexes pour présenter des informations et produire des signaux de cadre. Le déploiement v2.4 comprend une mise à jour GVL correspondante prévue pour le 23 juillet 2026.

Chaque CMP doit-elle mettre en œuvre le TCF v2.4 ?

Non. Les délais concernent les CMP et les installations en direct participant au TCF de l'IAB Europe. Un outil de consentement non-TCF peut encore avoir des obligations en vertu de la loi sur la vie privée ou de la politique de la plateforme, mais ces obligations ne le transforment pas automatiquement en participant au TCF.

Quand est la date limite du TCF v2.4 pour les CMP ?

La date limite confirmée est le 23 octobre 2026 pour les environnements web et le 23 février 2027 pour les environnements d'applications mobiles et de CTV. Les spécifications et la mise à jour GVL correspondante sont prévues pour publication le 23 juillet 2026.

Conclusion

Le TCF v2.4 n'est pas une raison de redessiner chaque flux de consentement. C'est une raison de vérifier les parties sur lesquelles les utilisateurs et les fournisseurs comptent : des explications claires des fonctionnalités, une portée honnête, des choix réversibles entre appareils et des signaux précis. Commencez avec les fichiers du 23 juillet, testez le web avant le 23 octobre, et gardez mobile et CTV sur le plan de février 2027. Un déploiement documenté et basé sur des preuves surpassera une mise à jour précipitée du seul bandeau.