Choisir et configurer une CMP pour Consent Mode v2

Le cadre juridique du ciblage et de la mesure publicitaire commence par les opérations réalisées dans le terminal. En France, l’article 82 de la loi Informatique et Libertés exige une information claire et un consentement préalable pour les lectures ou écritures non exemptées. Si les données collectées sont personnelles, leurs traitements ultérieurs relèvent aussi du RGPD et de leur propre base légale. Une CMP est un moyen d’exécuter ces choix, pas une autorisation générale.

Pourquoi un bandeau visible ne suffit-il pas ?

Un bandeau peut être propre et l’exécution fausse. Le contrôle porte sur six parcours : première visite sans action, tout accepter, tout refuser, choix granulaire, retrait, puis retour lors d’une autre session. Pour chacun, observez le texte présenté, le choix enregistré, les cookies, les stockages locaux, les scripts et les requêtes réellement déclenchés.

Pour les usages Google Ads et Analytics traités ici, quatre types sont centraux : ad_storage encadre le stockage publicitaire, analytics_storage le stockage analytique, ad_user_data l’envoi de données utilisateur à Google pour la publicité et ad_personalization la publicité personnalisée. Google documente aussi des types liés aux stockages fonctionnels, de personnalisation et de sécurité. Votre inventaire doit donc couvrir tous les types réellement utilisés. Ce sont des états techniques, pas des finalités juridiques prêtes à copier dans votre bandeau.

En mode Basic, les balises Google restent bloquées jusqu’au choix ; après un refus, aucune donnée n’est envoyée à Google. En mode Advanced, elles chargent avec les valeurs par défaut et peuvent envoyer des pings sans cookie lorsque le consentement est refusé. La modélisation propre à l’annonceur reste conditionnelle, notamment à l’éligibilité et à des seuils de données. Votre CMP doit exécuter le régime décidé, pas le choisir à votre place.

Consent Mode n’est ni le bandeau, ni la preuve du consentement, ni un moteur juridique. L’interface doit informer par finalité et service, rendre le refus aussi simple que l’acceptation, mémoriser la décision selon une durée justifiée et offrir un retrait accessible. Après ce retrait, les lectures et écritures concernées doivent cesser. C’est là que je commence l’audit.

Quels critères pour choisir une CMP intégrée à Consent Mode v2 ?

Partenaire intégré ou CMP certifiée : deux périmètres

Google présente des partenaires dont les modèles facilitent le déploiement de Consent Mode dans Tag Manager. Une intégration personnalisée reste possible pour un site annonceur. Un autre programme vise les éditeurs qui monétisent avec AdSense, Ad Manager ou AdMob : pour diffuser des annonces personnalisées dans l’EEE, au Royaume-Uni ou en Suisse, ils doivent utiliser une CMP certifiée par Google et intégrée au TCF. Mélanger ces deux listes conduit à un mauvais cahier des charges.

• Droit et interface. Exigez des finalités compréhensibles, la liste des responsables et services, un bouton « tout refuser » aussi accessible que « tout accepter », un choix granulaire, une gestion des langues et un mécanisme de retrait présent sur toutes les pages.
• Preuve et durée de vie. La solution doit conserver la décision, sa date, la version de l’information présentée et le périmètre choisi. Vérifiez l’export, la durée de conservation, le renouvellement et la suppression. Un simple statut « accepté » ne suffit pas à démontrer ce qui a été accepté.
• Inventaire et blocage. Demandez comment sont détectés les cookies, pixels, stockages locaux, appels réseau et contenus tiers. Un scanner aide à dresser l’inventaire ; seule une recette manuelle prouve que les éléments non exemptés sont bloqués avant l’accord et après le retrait.
• Intégration Google. Contrôlez le modèle Tag Manager, les API de consentement utilisées, les quatre types publicitaires et analytiques décrits ici, tout autre type effectivement exploité, le mode Basic ou Advanced, les valeurs régionales et la capacité à tester les mises à jour. Le logo d’un partenaire ne dit rien de votre conteneur.
• Périmètres réels. Listez domaines, sous-domaines, iframes, applications, langues et pays. Vérifiez aussi les formulaires, lecteurs vidéo, prises de rendez-vous, paiements et autres services tiers qui peuvent lire ou écrire dans le terminal.
• Exploitation et sécurité. Comparez accessibilité au clavier et au lecteur d’écran, journal des changements, disponibilité, reprise après incident, support, fréquence des mises à jour et coût total. L’accord de traitement, les sous-traitants ultérieurs, les transferts, la localisation et les mesures de sécurité font partie du choix.

Cette grille s’applique à la version et au contrat réellement achetés. Une fonction affichée sur la page commerciale peut dépendre d’un forfait, d’un module ou d’un volume. Demandez une démonstration sur votre architecture et faites inscrire les fonctions critiques dans le périmètre contractuel. Ni le prix, ni la certification, ni un taux d’acceptation promis ne remplacent cette preuve.

Le TCF s’applique-t-il à votre site ?

Le Transparency and Consent Framework de l’IAB Europe organise la transmission des choix aux acteurs publicitaires participants. La CMP produit une chaîne TC qui décrit ce contexte. Cette chaîne n’est pas une cinquième valeur Consent Mode et ne remplace pas ad_storage, analytics_storage, ad_user_data ou ad_personalization. Votre matrice doit relier séparément finalités, services, base légale applicable, choix TCF éventuels et types Google.

Depuis le 1er mars 2026, les nouvelles chaînes TC doivent être au format TCF v2.3 ; Google continue d’accepter les chaînes v2.2 créées avant cette date jusqu’à leur renouvellement. Le TCF n’est pas requis pour chaque site annonceur. Dans le périmètre éditeur décrit plus haut, vérifiez la version, l’identifiant de la CMP, les fournisseurs déclarés et les erreurs remontées par le produit Google. La certification contrôle des critères Google centrés sur le TCF ; Google précise qu’elle ne valide ni la conformité complète au TCF ni celle au droit applicable.

Comment configurer et valider l’ensemble du parcours ?

Je demande une matrice avant de toucher au conteneur : chaque finalité du bandeau, chaque service chargé et chaque type de consentement Google doivent avoir une règle explicite. Cette matrice vient de votre analyse juridique et de votre inventaire. Elle évite qu’une catégorie vague comme « marketing » commande indistinctement publicité, analyse, personnalisation et transmission de données.

L’ordre, la matrice et tous les choix

• Avant le choix. Définissez les valeurs par défaut avant toute balise ou tout code qui utilise ou met à jour le consentement. Elles peuvent varier selon la région et votre politique ; elles ne sont pas mécaniquement denied partout.
• Après « tout accepter ». Seuls les types couverts par l’accord passent à granted. La CMP enregistre la version du texte, l’horodatage et le périmètre de cette décision.
• Après « tout refuser ». Le refus reste aussi simple que l’accord. Les services non exemptés sont bloqués et les types correspondants restent ou passent à denied.
• Après un choix granulaire ou un retrait. Chaque type évolue séparément. Le retrait met à jour l’état, empêche les lectures ou écritures suivantes et rend de nouveau accessibles les préférences.

Dans Tag Manager, utilisez les API de consentement prévues dans un modèle de la galerie ou un modèle personnalisé. Le déclencheur Consent Initialization sert aux balises qui fixent ou mettent à jour ces états avant les autres déclencheurs. Google déconseille de piloter les mises à jour avec une balise Custom HTML qui appelle gtag : l’ordre de traitement n’est pas garanti.

1. Figer l’inventaire. Listez pages, domaines, sous-domaines, iframes, scripts, cookies, stockages locaux, requêtes et responsables associés.
2. Ouvrir une session neuve. Effacez les données du site, lancez Tag Assistant et vérifiez les valeurs par défaut avant le premier événement concerné.
3. Tester « tout refuser ». Contrôlez l’égalité du bouton, la décision enregistrée, les mises à jour et l’absence réelle des traceurs non exemptés.
4. Tester « tout accepter ». Vérifiez les quatre types publicitaires et analytiques, les autres types utilisés par votre configuration, puis les services effectivement autorisés par la matrice. Un état granted ne justifie pas un service absent du bandeau.
5. Tester un choix granulaire. Autorisez une finalité et refusez les autres. Les changements doivent rester indépendants dans Tag Assistant et dans le réseau.
6. Retirer le consentement. Revenez aux préférences depuis une autre page, retirez l’accord et confirmez l’arrêt des lectures et écritures suivantes.
7. Revenir plus tard. Ouvrez une nouvelle session. Vérifiez la persistance, l’expiration, un éventuel renouvellement et la cohérence avec la preuve conservée.
8. Changer de contexte. Rejouez les cas utiles par région, langue, sous-domaine, domaine distinct, iframe et appareil. Conservez les captures et la version testée.

Le résultat dépend du mode retenu. En Basic, l’absence de requête Google après un refus peut être exactement le comportement attendu. En Advanced, cherchez les pings sans cookie et leur état, sans les confondre avec une preuve de consentement. Dans les deux cas, un signal propre ne valide ni l’information affichée ni la base légale des traitements réalisés ensuite.

Sous-domaines, domaines distincts et iframes : trois cas

Un sous-domaine peut parfois partager un cookie avec le domaine parent, si sa portée et votre configuration le permettent. Un domaine distinct ne partage pas ce stockage : transmettre le choix exige un mécanisme prévu, un périmètre d’information cohérent et des garanties contre l’altération. Une iframe tierce possède encore un autre contexte ; elle ne reçoit pas automatiquement la décision de la page parente.

Ne cherchez donc pas à supprimer le bandeau partout par principe. Demandez d’abord si les mêmes responsables, finalités, services et textes couvrent le contexte suivant. Un choix réutilisé hors de son périmètre devient un problème juridique, même si la synchronisation technique fonctionne. À l’inverse, une décision valide qui disparaît à chaque navigation dégrade l’expérience et la cohérence de la preuve.

1. Partir sans choix enregistré. Ouvrez directement chaque hôte et chaque page embarquée ; vérifiez son état initial et les éléments bloqués.
2. Choisir sur le domaine principal. Testez accord, refus et préférence granulaire, puis consultez le stockage créé et sa portée.
3. Changer de contexte. Passez au sous-domaine, au domaine distinct et à la page qui contient l’iframe. Notez ce qui est transmis, redemandé ou isolé.
4. Retirer depuis un autre point. Confirmez que le retrait atteint tous les contextes couverts et bloque les opérations suivantes. Si ce n’est pas possible, le périmètre annoncé doit être revu.

Pour une vidéo, un agenda ou un formulaire tiers, vérifiez le code réellement chargé avant le choix. Une vignette locale peut remplacer le contenu tant que la finalité correspondante est refusée. Après l’accord, chargez le service ; après le retrait, empêchez les nouvelles lectures et écritures. Le simple fait de masquer visuellement l’iframe ne suffit pas.

Balisage côté serveur : où circule le choix ?

Le balisage côté serveur ajoute un conteneur intermédiaire entre le navigateur et les destinations. Il ne déplace pas le recueil du consentement sur le serveur. Pour la mise en œuvre Google documentée, les choix sont définis dans le conteneur Web, puis la balise Google les transporte dans ses requêtes HTTP vers le conteneur serveur.

Les clients Google du conteneur serveur lisent ces informations, et les balises Google natives savent adapter leur comportement. Vos balises personnalisées, destinations tierces et transformations doivent, elles, être vérifiées. Une requête reçue par le serveur ne donne pas carte blanche pour la transmettre, l’enrichir ou la conserver.

Suivez toute la chaîne : état visible dans Tag Assistant, requête envoyée par le navigateur, données reçues par le client serveur, déclenchement de chaque balise et appel sortant. N’inventez pas une seconde mise à jour de consentement dans le conteneur serveur pour compenser une erreur Web. Corrigez l’ordre ou la matrice à leur source.

Gratuite ou payante : jugez la version, pas le tarif

Une offre gratuite peut couvrir votre besoin ; une offre payante peut manquer une fonction décisive. Le prix ne prédit ni la validité du recueil ni la qualité de l’intégration. Comparez la version déployée sur des capacités vérifiables : volume et domaines couverts, personnalisation des finalités, preuve, retrait, géolocalisation, TCF si nécessaire, modèle Tag Manager, export et support.

Demandez aussi ce qui se passe quand le scanner échoue, qu’un fournisseur change son script ou que la plateforme devient indisponible. Le comportement par défaut doit rester maîtrisé. Un journal des versions, un environnement de test et une procédure de retour arrière valent davantage qu’une longue liste de logos.

Enfin, l’outil traite souvent des identifiants, des journaux de consentement et des données techniques pour votre compte. Lisez l’accord de traitement, la liste des sous-traitants, les lieux d’hébergement et de transfert, les délais d’assistance, les mesures de sécurité et les modalités de restitution ou de suppression. Ce contrôle ne se délègue pas à une mention « conforme RGPD ».

Tag Assistant d’abord, requêtes réseau ensuite

Tag Assistant est le point de départ recommandé par Google. Dans le résumé de consentement, il permet de voir les valeurs par défaut, leur ordre, les mises à jour et les balises qui lisent chaque type. Rejouez toute la recette dans une fenêtre neuve et conservez une preuve datée de chaque parcours.

L’onglet Réseau complète ce constat. Le paramètre gcs ne représente que ad_storage et analytics_storage. Le paramètre gcd transporte des informations sur les types de consentement et peut être envoyé même lorsque Consent Mode n’est pas activé. Leur encodage est évolutif : ne transformez pas une chaîne copiée dans une requête en verdict universel.

Pour chaque requête, regardez le moment, l’initiateur, la destination, les cookies joints et le choix courant. Puis rapprochez ce constat de Tag Assistant. L’absence d’un paramètre sur un appel donné ne prouve pas à elle seule une panne ; sa présence ne prouve ni un consentement valide ni l’absence d’autres traceurs.

Ce que le contrôle prouve, et ce qu’il ne prouve pas

La recette peut prouver qu’une version donnée du site présente les bons choix, conserve la bonne décision et commande les bons services dans les contextes testés. Elle peut aussi produire une piste de preuve : captures Tag Assistant, export de configuration, traces réseau, date, navigateur, région simulée et version du texte.

Elle ne délivre pas un certificat juridique. Il reste à confirmer les responsabilités, les finalités, les bases légales des traitements ultérieurs, la minimisation, les durées, les destinataires, les transferts et les droits des personnes. La certification d’un outil ne transfère pas cette responsabilité à son éditeur.

Rejouez le contrôle après une modification du bandeau, du plan de balisage, du conteneur serveur, d’un domaine, d’une iframe ou d’un fournisseur. Ajoutez une vérification périodique de l’inventaire et un test après incident. Les interfaces changent ; vos critères de preuve restent stables.

Sources officielles vérifiées le 21 juillet 2026 : La documentation Google couvre les principes et modes de consentement, la configuration, le débogage dans Tag Assistant, les partenaires CMP, les API de consentement de Tag Manager et le balisage côté serveur (pages techniques clés mises à jour le 17 avril 2026). Les règles Google portent sur la certification des CMP pour les éditeurs et la transition vers le TCF v2.3, avec la note IAB Europe du 15 décembre 2025. S’y ajoutent l’article 82 en vigueur, la FAQ CNIL du 29 avril 2026, la recommandation CNIL consolidée de janvier 2026 et la fiche CNIL du 14 mars 2024 sur la sous-traitance.

Reconfigurer ou migrer : la décision

Reconfigurez si la version actuelle couvre votre matrice, conserve une preuve exploitable, rend le retrait effectif et permet de corriger l’ordre ou les mises à jour. Migrez si une fonction critique manque réellement, si le fournisseur ne corrige pas un défaut, si le contrat ou la sécurité sont insuffisants, ou si l’architecture requise reste impossible à tester.

Une migration doit préserver ce qui doit l’être : politique affichée, registre des versions, preuves encore nécessaires, préférences actives lorsque leur réutilisation reste licite, accès permanent au retrait et procédure de retour arrière. Testez l’ancienne et la nouvelle solution sur les mêmes parcours avant la bascule. Sinon, vous changez deux variables à la fois et perdez le point de comparaison.

Mon verdict : gardez l’outil qui prouve le choix, respecte le retrait et exécute votre matrice dans chaque contexte. Tout le reste est une promesse commerciale à tester.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026