Read this article in English

Cet article a été écrit sans IA (enfin presque)
Aucun tiret cadratin n’a été maltraité pour écrire cet article, et les jeux de mots douteux, répétitions et autres phrases beaucoup trop longues ont été réalisés à l’aide de mes gros doigts, sur un device de type clavier Logitech.
Cela dit, je ne suis pas non plus un homme des cavernes, j’utilise tout de même le LLM qui me passe sous la main (Codex en ce moment) pour :

• Corigé lé faute d’ortpgraphes
• Améliorer les petites maladresses de syntaxe
• Repérer les répétitions, chose dont j’abuse beaucoup de base
• Générer les résumés / sommaires des articles
• Traduire en anglais

Accepter des cookies dans les années 2020

Je ne sais pas vous, mais perso, j’adore cliquer sur des boutons de bandeaux de cookie consent. Ce que je préfère, c’est globalement ouvrir la liste des partenaires IAB, même si j’adore également refuser les cookies, puis finalement être tenté de m’abonner pour pouvoir les refuser mais en fait non, je les accepte et OH MAIS POURQUOI CETTE DOUCHETTE REVOLUTIONNAIRE FAIT UN CARTON A BAIN DE BRETAGNE TRENTE CINQ MILLE BRETAGNE (oui, je peux parfois avoir une capacité d’attention assez limitée).

Mais le fait est que cliquer sur des boutons de bandeaux de cookie consent, c’est un peu ma passion inavouée, comme d’autres aiment les mots croisés, le tennis de table, ou insulter des gens sur League of Legends. Merci de respecter.

Et donc, au-delà de cette saine distraction, si je clique beaucoup sur des bandeaux de cookie consent (allez, on va tout de suite dire CMP pour Consent Management Platform, on est entre connaisseurs), c’est aussi et surtout parce que c’est mon gagne-pain. Pas que hein, je fais aussi des trucs avec GCP et Piano, mais au fond, il faut reconnaître que depuis 5 ou 6 ans, un setup d’analytics ne peut pas s’envisager sereinement sans une CMP bien fagotée.

Je ne vais pas vous refaire l’histoire complète des CMPs depuis la chute de l’Empire byzantin, cela prendrait sans doute bien trop longtemps (et globalement, la partie entre la chute de l’Empire byzantin et la crise des missiles de Cuba est moyennement intéressante), mais en substance, ceci s’est globalement déroulé sous la forme d’une trilogie avec des épisodes de qualité et d’intensité variables, à la façon de Matrix, ou d’une formule salade-tomate-oignon du kebabier du coin de ma rue (qu’on salue, fidèle lecteur de ce blog) :

• Temps 1 (avant 2012) : tout le monde pose des cookies en toute impunité
• Temps 2 (2012-2018) : tout le monde pose des cookies en toute impunité, mais met un bandeau flottant qui dit qu’il pose des cookies en toute impunité
• Temps 3 (depuis 2019) : IL FAUT UN BANDEAU AVEC LE FRAMEWORK IAB MAIS QUI DOIT BLOQUER LA NAVIGATION MAIS PAS TROP NON PLUS ET LE BOUTON REFUSER DOIT ETRE EN HAUT MAIS PAS TROP EN HAUT ET COMMENT JE METS MON HEADER BIDDING MOI BORDEL ET EST CE QUE FINALEMENT AVEC SERVER SIDE TOUT CA NE SERAIT PAS UN PEU FUTILE ENFIN J’EN SAIS RIEN MOI JE VOULAIS JUSTE ECRIRE UN ARTICLE SUR LES CMP DANS QUOI JE ME SUIS ENGAGE

Bon oui, c’est une affaire qui est devenue un tantinet plus complexe au fil du temps. Donc, une fois que l’on a aimablement passé sous silence cette partie historique, faisons un rapide tour d’horizon des solutions qui existent sur le marché, du moins en Europe, sans ordre de préférence et par simple hiérarchie de “ça m’est venu à l’esprit au moment de faire cette liste” :

• Axeptio
• Didomi
• Tarte Au Citron
• Complianz
• OneTrust
• Sirdata
• CookieBot

On trouve dans cette liste une techno open source, d’autres dont les prix peuvent atteindre plusieurs milliers d’euros par mois pour des gros sites, des fonctionnalités qui vont du simple affichage du bandeau jusqu’à une gestion centralisée des consentements entre votre site web et votre app, certaines qui sont marrantes et rigolotes, d’autres qui semblent avoir copié leur design sur le site de la DGFIP. Pour nous qui passons nos journées avec ces technos, c’est déjà compliqué. Mais pour le pauvre petit site qui craint qu’un activiste quelconque (voire la CNIL, mais là ils n’ont pas le temps ils réparent leur imprimante pour envoyer les mises en demeure, le toner est en rade, sale histoire) le dénonce pour pose illégale de cookie fbclid sans consentement libre, éclairé, révocable, tracé, non ambigu, made in France, 2 cafés, l’addition, oui tu passeras le bonjour à Micheline de ma part, avec possibilité égale d’accepter ou refuser ; oui, eh bien pour lui, là, c’est un peu compliqué. Et la plupart du temps, cela finit avec une CMP qui est par nature une friction pour l’expérience utilisateur, mais qui n’est au final même pas bien configurée, avec des cookies qui font leur vie de façon absolument libre et autonome en mode Montessori.

Être une CMP, c’est une bonne ou une mauvaise situation ?

Donc, cela nous amène à l’exercice du jour : je vais partir du postulat que je suis le propriétaire d’un site, qui va être amené, à un moment ou à un autre, à poser une certaine forme de cookies. En substance, j’ai donc au moins un outil d’analytics (par exemple GA), et une plateforme publicitaire à laquelle je dois envoyer des events (par exemple, Meta ou Tiktok), en respectant le consentement de l’utilisateur. Je veux donc en premier lieu une collecte qui soit propre vis-à-vis des guidelines et récentes mises en demeure de la CNIL, mais je veux tout de même maximiser mon consentement, pour pouvoir faire plaisir aux algos des plateformes publicitaires, et avoir un calcul pas absolument éclaté de mes conversions par source de trafic dans GA.

J’exclus donc (merci de ranger vos fourches) les features suivantes, du moins pour l’instant :

• Non je ne veux pas un dashboard de monitoring pour avoir le taux d’acceptation / refus, avec un peu de segmentation.
• Non je ne cherche pas à mettre en place une ergonomie spécifique basée sur la localisation de l’utilisateur, on va se contenter de ce qui marche en France, et globalement dans une bonne partie de l’UE.
• Globalement on ne va pas se mentir, si vous travaillez pour un site qui monétise son audience, et a donc un adserver, je ne sais pas trop ce que vous faites là. Vous passez votre vie à négocier avec Taboola, GAM, et consorts, j’ai beaucoup d’empathie pour vous, et vous êtes les bienvenus, mais vraiment, globalement, juste continuez d’utiliser Didomi. Accessoirement, force.
• Non je ne cherche pas à faire de l’AB test de fifou pour optimiser le taux de consent en changeant la transparence sur le bouton “continuer sans accepter mais bon êtes-vous vraiment sûr allez non bon d’accord OK bisous”. J’aime le risque mais j’ai mieux à faire.
• “Ouais mais moi je veux gérer mes cookies dans une interface, parce que pour faire une MEP je dois ouvrir un ticket à l’équipe de dev et ça me crée de la charge mentale” => Oui et moi je veux te faire économiser de l’argent et gagner de la webperf. Si éventuellement vous avez envie d’avoir une interface administrable, voyez ça avec vos devs. Mais sinon, regardez la réalité en face : vous en rajoutez souvent, des nouveaux vendors ?
• “J’ai Shopify, comment j’intègre ça sur mon checkout ?”.

Oui

• Non Vincent, je ne veux pas non plus faire un consent wall, merci de retourner à tes activités.
• On verra peut-être dans un 2ème temps mais non, on ne va pas mettre en place une preuve du recueil du consentement. Juste pour rigoler, je vous copie-colle ce que dit la CNIL à ce sujet :

Une mise sous séquestre auprès d’un tiers du code informatique utilisé par l’organisme recueillant le consentement, pour les différentes versions de son site ou de son application mobile, voire simplement par la publication horodatée sur une plate-forme publique d’un condensat (ou « hash ») de ce code pour pouvoir prouver son authenticité a posteriori

Franchement à ce stade ils auraient pu l’écrire en alexandrins que ça n’aurait pas été plus beau. Donc non, pas de mise sous séquestre auprès d’un tiers du code informatique.

cmp_speficications_fonctionnelles_detaill%C3%A9es_v4_retour_client_final_1_def_retour_patrick.pptx

Voici donc le cahier des charges, à vos User Stories (oui, je laisse les 6 minutes réglementaires pour que votre page Confluence se charge) :

• La CMP doit être bloquante. Oui, BLOQUANTE. Elle doit tout de même montrer qu’il y a vaguement du contenu accessible ensuite (l’utilisateur est quand même venu pour ça), mais l’utilisateur doit se la prendre en pleine face tel le videur du Pacha Disco club à la soirée années 80, et n’en sortir (enfin n’en rentrer) que quand il aura fait son choix en son âme et conscience. Et si à tout hasard un UX / UI designer passait par ici (c’est peu probable mais sait-on jamais), eh bien sache que oui, Célestin (dans mon monde, tous les designers s’appellent Célestin), j’en suis conscient, c’est une friction. Mais au cas où tu n’eusses pas été mis au courant, si cette CMP doit être bloquante, Célestin, c’est pour une simple et bonne raison : si l’utilisateur accepte les cookies, il doit le faire lors de sa première page vue. Parce que c’est là qu’il a les beaux UTMs qui ont été soigneusement placés par votre chargé de CRM (sauf si Safari s’amuse à les stripper, mais c’est une autre histoire). C’est là qu’il a encore un beau referrer de type Google (ou OpenAI). C’est là que l’on sait à la fois d’où il vient, et accessoirement que l’on peut avoir son consentement pour lier cette info à notre outil d’analytics. Donc oui, bannière bloquante, et pas qu’à moitié. Dézo, Célestin, même si je respecte ton travail : d’ailleurs tu peux mettre le CtA plus gros sur la page panier ? Merci.
• Sur le premier niveau de la bannière, on veut :
  • Un paragraphe synthétique qui répertorie le nombre de vendors qui utilisent des cookies ou technologies similaires, et qui décrit le cas échéant les familles que vous avez mises en place.
  • Un texte, synthétique également, qui explique qu’il est possible de retirer à tout moment son consentement pour ces partenaires.
  • Si vous utilisez des tags Google, une mention spécifique du fait que le site utilise spécifiquement des tags liés à Google, avec un lien vers https://business.safety.google/privacy/. Je sais que ça peut paraître une blague, mais j’y reviens plus tard. Et je pense que les vrais savent pourquoi.
  • Un lien vers la politique de confidentialité.
• Sur le premier niveau, toujours, on veut 3 boutons :
  • “Autoriser tous les cookies”, visible, en bas à droite, joli, charté, cordial. Un bouton avec qui on a envie de partager un moment agréable. Un bouton qu’on pourrait tout à fait inviter au resto et avec qui on pourrait passer un moment sincère et agréable.
  • “Continuer sans accepter”, dans la bannière, en haut à droite. Oui, DANS la bannière, pas en extérieur sur fond transparent. Des petits rigolos ont pris des mises en demeure pour ça. La CNIL doit probablement avoir l’équivalent de la goal line technology, mais avec les boutons “Continuer sans accepter” à la place d’un ballon de foot. On n’arrête pas le Progrès©.
  • “Personnaliser mes choix”, en bas à gauche. Visible et cordial, mais quand même un peu moins que le bouton pour valider les cookies.
• On arrive donc au 2ème écran :
  • On répertorie des cookies strictement nécessaires dans une famille dédiée, présente en premier, avec un design différent des autres familles.
  • Celui-ci affiche tous les partenaires publicitaires (pour parler en jargon IAB, on nommera ces derniers des vendors). Chaque vendor a un texte dépliable qui décrit succinctement ce qu’il fait et pourquoi il pose des cookies. Chaque partenaire a un toggle pour accepter / refuser.
  • Des vendors peuvent être regroupés par familles (“Marketing”, “Analytics”, “Revente de données à des plateformes russes”… Faites-vous plaisir). Ici aussi pour simplifier et coller avec la nomenclature du marché, on parlera de purposes. Il y a un toggle qui permet d’accepter / refuser chaque purpose en bloc. Pour un nouvel utilisateur, tous les vendors sont refusés en arrivant sur cet écran. Bien sûr, dans le cas d’un nouvel affichage, les toggles reflètent le consentement préalablement accordé (ou non du coup).
  • Si on a besoin d’utiliser Consent Mode de Google (on parlera de CoMo par souci de place), on l’affiche également sur cet écran, en reprenant explicitement la typologie de Google (Analytics Storage, Ad Storage, etc.). Oui ça fait du texte en plus, oui personne ne sait trop quelle nouvelle drogue synthétique a consommé l’inventeur de Consent Mode chez Google qui a décidé que bah en fait ils allaient faire, et je cite de mémoire (fiable), “leur propre truc parce que pourquoi pas”. Mais je trouve qu’au vu de l’ambiguïté qu’il y a derrière Consent Mode, je préfère me couvrir en affichant très explicitement ceci, comme seul le fait Axeptio à ma connaissance. On affiche donc explicitement ad_storage, analytics_storage, ad_user_data et ad_personalization.
  • Sur cet écran des options, on a un bouton “Valider mes préférences”, et c’est tout. La modification des préférences (écriture ou modification du cookie, puis dataLayer.push, on y revient après) n’est effective qu’à partir du moment où ce bouton est cliqué.
• Il faut que cette CMP soit affichable à tout moment via un lien dans le footer (pour faire très original, “Modifier mes choix de cookies”).
• Note importante, notamment pour les utilisateurs de Didomi. Oui, je sais, dans ma logique (et à ma connaissance dans la logique de la plupart des CMPs) un vendor dépend d’un seul et unique purpose. Dans la logique IAB, et donc Didomi, la relation purpose / vendor n’est pas un One to Many, mais un Many to Many. Ce qui signifie que si vous refusez le purpose “Publicité”, vous ne refusez pas la pose de cookies Facebook. Enfin, pas complètement. Mais un peu quand même. Soyons honnêtes, environ 0,000024% de vos utilisateurs vont sur cet écran et trifouillent les boutons. Le problème est que ces utilisateurs sont tous soit DPO, soit consultants en “conformité de tracking”. Ça ne résout rien, mais on va donc dire qu’on veut garder notre santé mentale, et donc qu’un vendor n’appartient qu’à un purpose. Voilà.
• Il va de soi que la CMP doit continuer à s’afficher en l’absence de choix.

Intégration avec GTM

On arrive à la partie la plus croustifondante de notre exercice. Parce qu’en substance, je trouve que c’est précisément à ce moment que la plupart des plateformes du marché font, et je vais le dire avec beaucoup de parcimonie, de l’énorme merde. Pour résumer, je pense que beaucoup de personnes qui ont conçu les CMPs du marché ne comprennent globalement pas grand-chose à GTM, et sont quasi systématiquement à côté de la plaque. Et sans vouloir citer de nom (oui oui Tarte Au Citron) je pense qu’il y a certaines plateformes qui ignorent globalement le concept de plaque.

Et Zébartiii, voici le brief des specs techniques côté GTM, ramenez votre meilleur Coach Agile, on spécifie ça pour le sprint 14 (personne ne sait quand il aura lieu, mais on sait qu’il sera sans doute entre le 13 et le 15) :

Le cookie

On veut un cookie lisible, qui reflète le consentement de l’utilisateur, c’est-à-dire qui nous dit quels sont tous les vendors pour lesquels il a donné son consent, ainsi que les familles de CoMo, selon le même principe, mais qui auront leur propre préfixe réservé. En substance, un truc comme ça :

{
    'meta' : 'granted',
    'tiktok' : 'granted',
    'linkedin' : 'denied',
    'como_analytics_storage' : 'granted',
    'como_ad_storage' : 'denied'
}

En bonus, on va même y ajouter quelques métadonnées :

{
    'last_consent' : 321654897 // Timestamp de la dernière acceptation, vide par défaut
}

Pour ne pas faire imploser notre navigateur (ou en tout cas y participer) on encode tout ceci en base 64, et on se couvre comme il faut sur le cookie en lui-même :

• Domain : top level domain explicite, ou bien domaine complet si on n’a pas vocation à avoir plusieurs sous-domaines
• Path : /, pour rendre le cookie disponible partout
• Secure : activé, parce qu’on se respecte
• Samesite : Lax

Par défaut, au 1er affichage de la CMP, avant le moindre choix, le cookie est posé (oui je sais ça peut paraître un peu contre-intuitif mais on a le droit de poser sans consentement un cookie qui répertorie les cookies qui ont besoin de consentement), et on considère bien sûr que l’ensemble des vendors est en “denied”.

Et à ce sujet j’utilise à dessein la notion “granted” / “denied”, qui est plutôt le jargon de CoMo, mais a le mérite d’être explicite. On pourrait remplacer ceci par un booléen, mais ça ne changerait pas le fond de l’affaire.

Pour moi, rien de plus, rien de moins. Évidemment le cookie doit être mis à jour en live à chaque changement de consent. Point absolument crucial, le cookie doit être mis à jour avant les instructions dataLayer.push, dont nous allons parler dans moins de 200 signes.

L’idée est d’avoir un cookie ultra lisible, simple, et qui ne nécessite pas une librairie JS de 60 ko pour être décodé (ui bjr l’IAB)

Pour ce qui est de la durée du cookie, nous allons être prudents, et nous contenter de 6 mois non glissants ; aucune mécanique de renouvellement ne doit être mise en place.

La communication avec le data layer

Ici encore, beaucoup de CMPs sont en roue libre totale, et en font soit trop, soit trop peu (et étonnamment, parfois un peu les 2 à la fois). Alors qu’en réalité, il y a besoin de littéralement trois fois rien pour que vos tags puissent fonctionner de façon ultra efficace.

On doit avoir donc des calls dataLayer.push dans les cas suivants :

• De très loin le plus important : dès qu’il y a un changement de consent, on le pousse dans le DL. Très concrètement :

dataLayer.push({
    'event': 'cmpInteraction',
    'cmpInteraction' : {
        'action' : 'consentChange',
        'changeType' : 'First Consent' //String : 'First consent' ou 'Ulterior consent'
    }
})

Ce que j’entends par “changement de consent”, c’est une validation totale, un clic sur “Continuer sans accepter”, ou bien un clic sur la validation dans l’écran des préférences. C’est d’ailleurs pour ceci qu’on ne se complique pas la vie avec des refus partiels, comme une CMP qui disparaîtrait. Et on va bien prendre soin de différencier le premier consent d’un consent ultérieur, pour pouvoir différencier le déclenchement de nos tags dans GTM (on y revient plus bas).

• En option, à l’affichage de la bannière (ex : “cmpDisplay”), avec une distinction sur l’affichage initial, ou via le footer :

dataLayer.push({
    'event': 'cmpInteraction',
    'cmpInteraction' : {
        'action' : 'display',
        'displayType' : 'Website load' //String : 'Website load' ou 'Footer'
    }
})

• En option également, on peut pousser un event au clic sur les différents boutons

dataLayer.push({
    'event': 'cmpInteraction',
    'cmpInteraction' : {
        'action' : 'button click',
        'button' : 'Continuer sans accepter' //String : Libellé du bouton
    }
})

Je pense que nombre d’entre vous se demandent pourquoi je ne pousse pas les vendors dans le datalayer. Déjà, parce que je fais ce que je veux, c’est MA CMP. Et aussi parce que je pars du principe que le cookie est une source de vérité largement fiable. Et si vous vous souvenez bien, je demande de façon très explicite à ce que le cookie soit mis à jour avant de faire le dl.push. Si vous ne captez pas, attendez une minute, vous comprendrez avec la partie sur GTM.

Il est également probable que vous vous soyez fait la remarque suivante : “Hé mais mon petit bonhomme, tu oublies les calls Gtag ! Tu veux aller en prison ou bien ?” Grande question philosophique, on pourrait effectivement les ajouter, ça ne serait pas un scandale. Mais je préfère les gérer dans GTM également, on y revient aussi ci-après.

La config côté GTM

Je ne vais pas m’amuser à répertorier les horreurs que je vois au quotidien dans la gestion des CMP dans les setups GTM que je récupère. Il est vrai que les plateformes n’aident pas franchement (eu égard à l’histoire de plaque ci-dessus), mais en l’occurrence si je prends le trio Didomi / Axeptio / OneTrust, qui est le plus courant en France, leurs interactions avec GTM sont différentes, mais avec à chaque fois une logique assez claire. Pour autant je vois des choses côté GTM qui sont l’équivalent de ce mème qui reste un grand classique :

Comme vous l’avez compris, le duo cookie / data layer sur le front est très frugal, GTM le sera donc également.

Lire le cookie

Notre cookie est donc la source de vérité. Disons qu’il s’appelle “mm_consent”, et est encodé en base 64 : on va devoir travailler en plusieurs étapes.

1/ Lire le cookie (je pense que jusqu’ici vous suivez)

2/ Le décoder, et le passer en JSON

3/ Avoir une variable par vendor

Les tags qui partent à la page vue

Ici, vu qu’on se base sur un cookie, il n’y a rien de plus simple à lire, donc chaque tag est déclenché avec un trigger de type page vue / DOM Ready, et une condition sur le cookie, tout simplement.

À noter qu’il est tout à fait possible que vous ayez un event de type “pageLoad” / “appLoad” poussé avec votre data layer initial qui contient des infos sur la page, l’environnement, etc. Bien évidemment aucun souci, vous pouvez utiliser exactement la même logique.

Je sais que la plupart des CMPs exposent un event de type “cmpReady”, qui attend que leur SDK soit chargé, et recommandent d’utiliser le consent qui est poussé dans le data layer. Et pour des events qui pourraient être poussés avant le chargement dudit SDK (un “purchase”, un “view_item”…), il faut naturellement utiliser un trigger group, pour être sûr d’avoir à la fois l’event poussé par la CMP, et celui qui a été poussé au data layer (“purchase” + “cmpReady”).

Eh bien je suis désolé, et même si je sais que c’est la reco officielle des plateformes, cette approche est très objectivement une superbe façon de se tirer une balle dans le pied :

• Un tag de page, c’est beaucoup trop crucial, et devoir attendre cet event de la CMP revient à s’imposer un goulot d’étranglement non nécessaire. Si jamais un utilisateur bloque le domaine qui appelle le SDK de votre CMP, l’event ne partira jamais, donc le trigger group ne sera jamais évalué, et vous l’avez dans l’os.
• Lire un cookie, ce n’est quand même pas la chose la plus compliquée du monde. Le cookie est là, il est dispo au chargement de page, autant l’utiliser.
• Les trigger groups, c’est très bien, mais quand on peut éviter, eh bien on évite, car ils peuvent amener quelques coups fourrés. Cas typique de site e-commerce : un dataLayer.push est fait avec un “purchase”, avec toutes les infos e-commerce qui vont bien, puis l’event “cmpReady” est poussé à son tour. Vous avez un trigger group “cmpReady” + “purchase” qui est donc évalué plus tard. Sauf qu’entre-temps, l’objet “ecommerce” a été purgé pour un autre push quelconque. Eh bien, au moment du trigger group, il deviendra impossible de lire les infos liées à la transaction. Vos infos produit seront absentes. Et ne venez pas me dire que c’est un cas à la marge, la purge de l’objet “ecommerce” est une reco officielle de la doc de Google, et je me suis très officiellement pris la tête avec le support d’un acteur majeur du marché pas plus tard que l’année dernière à ce sujet (s’il se reconnaît, ce n’était pas personnel)
• L’autre cas problématique concerne un event qui pourrait être déclenché plusieurs fois par page, comme à tout hasard un “add_to_cart”, ou bien un “route_change” sur une app React, Vue ou autre. Bien malheureux est le consultant qui a voulu être ceinture et bretelles en mettant des trigger groups à base de “add_to_cart” + “cmp_load”, puisque pour rappel, un trigger group peut être évalué une et une seule fois par page, et que dans ce schéma, le tag ne pourra donc être déclenché qu’une fois, ce qui fait qu’un utilisateur qui ajouterait plusieurs produits à son panier sur une page de liste ne verrait pas l’ensemble des actions remonter.

Les tags à l’acceptation

Il faut bien sûr gérer le cas du changement du consent, au sens large du terme, c’est-à-dire majoritairement le premier consent, mais aussi de possibles changements ultérieurs. Pour rappel, on a bien fait le distinguo entre ces 2 cas dans le data layer.

Eh bien ici, en revanche, on va se baser sur l’event poussé dans le data layer.

Concernant nos tags de page vue (GA et autres), on peut se la jouer de 2 façons :

• Soit on a un tag de page vue, qui a 2 triggers (l’un au DOM ready ou équivalent, l’un spécifique à cet event “cmpInteraction”)
• Soit, et c’est ma préférence même si c’est un chouïa plus verbeux, un tag de page vue au DOM Ready, et un tag dédié au changement de consent, avec un nom explicite (consent_changed par exemple).

Pour rappel et à toutes fins utiles, dans le cas d’un CoMo avancé, même si le premier tag de page vue part en G100 (toutes les familles refusées), si, sur la même page, un nouvel event part avec le consent qui va bien, GA fera du backfill et pourra récupérer la source et tutti quanti.

Le cas de Gtag

Même si aujourd’hui les plateformes ont tendance à gérer Gtag de leur côté, je préfère, quand c’est possible, faire le mapping moi-même dans GTM. Pourquoi ? Parce que la façon dont fonctionne Gtag dans GTM me dérange de base profondément, car là où les tags Meta / Tiktok ont un conditionnement bien visible, ceux de Google sont gérés par le biais de “on coche un truc et on fait confiance sur le fait que promis juré craché même si ça part tout le temps des cookies ne seront pas posés”. Au moins, si on gère CoMo dans GTM, on a un contrôle précis sur la correspondance entre ce qui est au niveau de la CMP, et la façon dont ceci communique avec les tags de Google.

On doit donc pour commencer lire les différentes familles CoMo, vous voyez le bail, je ne vais pas vous faire toute la famille :

Ensuite, on va avoir besoin de 2 tags, en utilisant le template désormais plus ou moins officiel de Simo “Consent Mode (Google + Microsoft Tags)” (par pitié arrêtez de mettre des calls Gtag en custom HTML dans GTM, je l’ai trop vu et j’ai eu de nombreuses envies de génocide) : un “Default” dès que possible, au lancement de la page, et l’autre au moment de l’update.

La beauté de la chose, c’est que, vu que notre cookie est la seule et unique source de vérité (je pense que vous avez compris), ces 2 tags sont globalement identiques :

Vous êtes de grands (garçons|filles), vous n’oubliez ensuite pas d’aller mapper le “Consentement intégré” à tous les tags qui le demandent :

Après, si vous tenez à tout prix à mettre les calls Gtag liés à CoMo dans les appels en dur, en complément des appels dl.push, je ne vous en voudrai pas, et ça ne change pas non plus radicalement le sujet.

Bien sûr, cela vaut lorsqu’on fait du CoMo avancé. Si vous avez un DPO plus royaliste que le roi (ou plus royaliste que la CNIL dans le cas présent) et que vous voulez faire du CoMo basique, vous avez gagné le droit de faire un trigger d’exception. Après tout, on a l’implémentation que l’on mérite.

Et vous savez quoi ? Eh bien, c’est fini. Basta. Terminado. Abgeschlossen. Tout ceci sans trigger group de l’enfer, sans tag en séquentiel “au cas où”. Sans avoir à rentrer dans le 17ème niveau de l’interface pour aller s’assurer que CoMo est bien envoyé.

Server side en 7 mots et demi

Oui oui passer le consent dans un param

Le SKILL

J’avais parlé de vibe coding en préambule de ce billet de blog. Mais ici, on a beaucoup parlé de coding, et nettement moins de vibe. Vous pouvez donc tout à fait vous arrêter ici, prendre cet article, en parler lors du Comité d’arbitrage mensuel, qui pourra valider l’enveloppe budgétaire pour le passer sur la roadmap, afin qu’en Q4 l’équipe Client Design Centricity EMEA prépare des maquettes Figma pour intégrer ceci à votre Bootstrap 3.16 si toutefois ceci était validé en PIP.

OU ALORS.

Merde, on est en 2026. Je vous ai donc écrit un Skill, il est disponible en suivant ce lien hypertexte : https://github.com/aristideriou/agent-skills/blob/main/README.md

Le repo est en licence MIT, donc vous pouvez l’utiliser, le forker, l’offrir à votre neveu pour son baptême, m’envoyer des messages pour me dire que je suis très beau et intelligent, ou juste rien de tout ça parce que vous êtes heureux avec votre CMP actuelle.

Comme indiqué dans la doc, vous pouvez l’installer via un simple npx skills. C’est un Skill qui est sympa et plutôt bavard, puisqu’il va vous poser des questions sur les familles, les descriptions, et quelques autres trucs. Et à la fin, il vous balance une CMP.

J’ai créé ce petit site que j’utilise pour mes démos, sur lequel vous pouvez voir la tête que ça a, même si bien sûr tout le principe est qu’il s’adapte à votre design, et que donc il n’aura pas la même tête selon la tête de votre codebase.

Comme de bien entendu, je vois ce repo et ce Skill comme une solution légère, minimaliste, très optimisée pour GTM, et j’ai beau avoir une grande expérience avec ces outils, je ne suis pas juriste, donc n’allez pas m’attaquer en justice parce que vous avez pris une mise en demeure, ou bien parce que votre RSSI vous reproche que cette solution n’est pas certifiée ISO 980001 (elle n’est probablement même pas certifiée ISO 1, si tant est que ça existe).

Mais en revanche, ce que je peux vous garantir, c’est que ce que vous offre cette CMP, c’est une absence d’appel de librairie tierce, un design qui est cohérent avec celui de votre site, un cookie tout gentil tout sympa qui ne met pas vos headers en flammes, une webperf qui reste au top, et surtout, SURTOUT, un coût de 0 €. 0 € par mois, ou ramené à l’année et parce que vous êtes sympas et que je vous connais bien, 0 € par an.

Travail en progrès

J’ai volontairement écarté certaines features, qui pourraient être gérables, mais que je garde sous le coude pour une version ultérieure :

• La dernière petite tendance des mises en demeure CNIL a souligné un point vicieux mais intéressant : ils préconisent qu’en cas d’acceptation puis de refus (oui, absolument personne ne fait ça, je sais), on doit faire une purge des cookies préalablement posés. Ça peut tout à fait se gérer soit au niveau de la CMP elle-même, soit éventuellement avec un script un peu malin côté GTM.
• Avoir un dashboard de suivi (taux de consentement, taux de non-choix) façon Didomi : peut se faire avec une petite Cloud Function ou équivalent, qui va venir écrire dans une table BQ, à laquelle vous pourrez brancher un petit outil de dataviz, ou bien vous faire une petite interface avec votre outil de vibe coding préféré. L’enjeu va sans doute être d’avoir une Cloud Function suffisamment énervée pour prendre les hits proportionnels au trafic de votre site.

Et vous, avez-vous vibecodé des CMP ? Lâchez vos comms !

Bien évidemment, il est totalement possible que je sois passé à côté de cas gros comme une maison, en dehors de ce que j’ai évoqué en début d’article, et qui est selon moi très bien pour des organisations d’une certaine complexité, il y a peut-être des trous dans ma raquette, donc n’hésitez pas à me contacter, ou bien à me faire une petite PR sur le repo du skill.