Une CMP peut afficher un très beau bandeau tout en laissant partir Google Analytics, Meta Pixel ou un autre service avant que le visiteur ait fait son choix.
Pour savoir si une installation fonctionne réellement, je préfère donc regarder ce que fait le navigateur plutôt que ce qu’affiche la bannière.
Les DevTools intégrés à Chrome, Firefox, Safari et Edge permettent déjà de réaliser une grande partie de ce contrôle. Il n’est pas nécessaire d’utiliser un scanner spécialisé pour effectuer les vérifications de base.
Ce que l’on cherche à vérifier
Le principe est assez simple.
Lors de la première visite, avant toute interaction avec le bandeau, les services nécessitant un consentement ne doivent pas fonctionner.
Après un refus, ils doivent rester bloqués. Après une acceptation, ils peuvent être chargés conformément au choix effectué.
Le test consiste donc essentiellement à comparer trois situations : avant le choix, après refus et après acceptation.
Commencer avec une session propre
Avant chaque test, il faut éviter qu’un ancien consentement influence le résultat.
Le plus simple est d’utiliser une fenêtre de navigation privée ou de supprimer les données du site avant de recharger la page.
Dans Chrome et les navigateurs basés sur Chromium, l’onglet Application des DevTools permet notamment d’inspecter et de supprimer les cookies et différentes données stockées localement.
L’objectif est de reproduire la situation d’un nouveau visiteur qui arrive sur le site sans choix précédent.
Ouvrir Network avant de recharger la page
L’onglet Network est probablement l’outil le plus utile pour tester une CMP.
Je l’ouvre avant de recharger la page afin de capturer les requêtes dès le début du chargement.
L’option permettant de conserver le journal peut également être utile lorsque le test implique une navigation ou un rechargement.
Une fois la capture active, je recharge complètement la page sans toucher au bandeau.
Rechercher directement les services connus
Si le site utilise GA4, YouTube, Meta Pixel ou reCAPTCHA, je commence par rechercher les domaines et ressources associés dans Network.
Le but n’est pas de mémoriser toutes les URL utilisées par chaque fournisseur. Il suffit généralement de rechercher quelques termes caractéristiques du service que l’on sait présent sur le site.
Si une requête correspondant à un service soumis au consentement apparaît immédiatement alors que le visiteur n’a encore rien choisi, il faut comprendre pourquoi.
Dans une intégration où ce service doit être bloqué avant consentement, le problème est déjà visible.
Attention à la différence entre télécharger et exécuter
Lors du diagnostic, il faut comprendre précisément l’architecture utilisée.
Un script présent directement dans le HTML peut être téléchargé et exécuté immédiatement. Une ressource peut aussi être injectée plus tard par Google Tag Manager, une extension WordPress ou un autre script.
Le panneau Network permet de voir les requêtes réellement effectuées, tandis que l’inspection du DOM permet de comprendre d’où vient une balise présente dans la page.
Ces deux vues sont complémentaires.
Inspecter le HTML et le DOM
Dans l’onglet Elements ou Inspector selon le navigateur, je recherche également les scripts des services concernés.
En mode manuel avec tarteaucitron open source, une erreur classique consiste à déclarer correctement GA4 dans tarteaucitron tout en laissant l’ancienne balise Google Analytics directement dans le site.
Dans ce cas, tarteaucitron contrôle sa propre intégration de GA4, mais il ne peut pas empêcher magiquement une seconde balise indépendante déjà exécutée par la page.
Le service doit réellement passer par la CMP.
Vérifier l’ordre des scripts
Je regarde ensuite où se trouve la CMP par rapport aux services qu’elle doit contrôler.
Avec tarteaucitron Pro en détection automatique, le marqueur doit être chargé aussi tôt que possible, avant les trackers qu’il doit détecter et bloquer.
Si un service tiers apparaît et s’exécute avant tarteaucitron, la CMP arrive trop tard.
C’est la raison pour laquelle l’ordre de chargement est une règle fondamentale de ce type d’intégration.
Faire un premier test sans cliquer sur le bandeau
Une fois la page chargée, je ne clique volontairement sur rien.
Je vérifie les requêtes Network et les cookies présents.
Les traceurs nécessitant un consentement préalable ne devraient pas apparaître simplement parce que quelques secondes se sont écoulées ou parce que j’ai fait défiler la page.
La CNIL rappelle d’ailleurs que la poursuite de la navigation ne constitue pas un consentement : l’acceptation nécessite un acte positif clair.
Tester ensuite "Tout refuser"
Je recharge avec une session propre, puis je refuse cette fois les services.
Après le clic, je continue à surveiller Network.
Un refus ne devrait évidemment pas provoquer le chargement des services qui viennent d’être refusés.
Je navigue également vers une seconde page afin de vérifier que le choix est conservé et que le bandeau ne redemande pas immédiatement la même chose.
Contrôler les cookies après le refus
L’onglet Application permet ensuite d’inspecter les cookies présents pour le domaine et, selon le navigateur, différentes formes de stockage local.
Il ne faut pas conclure que tout cookie présent est nécessairement problématique. Certains traceurs peuvent être strictement nécessaires au service et ne nécessitent pas le même mécanisme de consentement.
Ce qui m’intéresse est surtout de retrouver un cookie appartenant à un service qui était censé rester bloqué.
Si GA4 a été refusé et que son intégration ne devrait pas fonctionner, retrouver ses cookies constitue un bon point de départ pour le diagnostic.
Faire enfin le test inverse avec "Tout accepter"
Je recommence ensuite depuis une session propre et j’accepte les services.
Cette fois, les requêtes précédemment absentes doivent pouvoir apparaître.
Le test permet donc de vérifier les deux côtés du mécanisme : la CMP sait-elle empêcher le chargement avant consentement et sait-elle ensuite correctement autoriser le service ?
Une CMP qui bloque parfaitement un service mais ne réussit jamais à le charger après acceptation n’est pas correctement intégrée non plus.
Tester les choix service par service
Le bouton global n’est qu’un premier test.
J’ouvre ensuite le panneau détaillé et j’accepte un service tout en en refusant un autre.
Si GA4 est accepté mais YouTube refusé, les comportements correspondants doivent être indépendants.
C’est particulièrement important avec Google Tag Manager et les consentements en cascade. Accepter un conteneur ne devrait pas être interprété automatiquement comme l’acceptation de tous les services qu’il peut contenir.
Tester les iframes et contenus externes
YouTube, Google Maps et d’autres services intégrés avec des iframes méritent également un contrôle visuel.
Lorsque le contenu est bloqué, la page peut afficher un emplacement ou un bouton permettant au visiteur d’autoriser ce service.
Je vérifie alors qu’aucune requête vers le fournisseur n’est partie avant cette autorisation, puis que le contenu apparaît correctement après le choix.
Le fait de masquer une iframe avec du CSS ne constitue évidemment pas un blocage si celle-ci a déjà été chargée derrière le placeholder.
Regarder la colonne Initiator
Lorsqu’une requête inattendue apparaît, la colonne Initiator de Network est particulièrement pratique.
Elle permet souvent de retrouver le script ou la chaîne d’exécution qui a provoqué la requête.
On découvre ainsi qu’un tracker ne vient pas forcément du code que l’on pensait. Il peut être injecté par GTM, un plugin WordPress, un widget externe ou un autre script.
C’est souvent beaucoup plus efficace que de chercher au hasard dans des milliers de lignes de code.
Ne pas oublier les erreurs JavaScript
Je regarde également rapidement la console.
Une CMP peut bloquer correctement un service tout en provoquant une erreur dans un autre script qui supposait que ce service était toujours disponible.
Le site doit donc rester fonctionnel lorsque les services facultatifs sont refusés.
Un refus de consentement ne devrait pas casser le menu, le panier ou une fonctionnalité essentielle qui n’a aucun rapport avec le tracker bloqué.
Un test simple vaut mieux qu’un badge "conforme"
Cette méthode ne constitue évidemment pas un audit juridique complet du site.
Elle répond cependant à une question technique fondamentale : les services que la CMP prétend contrôler sont-ils réellement contrôlés ?
Je trouve cette vérification beaucoup plus utile que la simple présence d’un logo, d’un scanner vert ou d’une mention indiquant que la CMP est correctement installée.
Quelques minutes dans Network permettent souvent de découvrir immédiatement une intégration incorrecte.
Ma routine de vérification
- Ouvrir une session propre.
- Lancer Network avant le chargement.
- Recharger sans effectuer de choix.
- Rechercher les principaux services tiers.
- Contrôler les cookies et le DOM.
- Recommencer après "Tout refuser".
- Recommencer après "Tout accepter".
- Tester quelques choix individuels.
- Vérifier les iframes et contenus externes.
- Utiliser Initiator pour toute requête inattendue.
Une CMP reste du JavaScript exécuté dans un navigateur. Le navigateur fournit justement tous les outils nécessaires pour observer ce qu’elle fait réellement.
