Des cookies sont encore définis après Reject

Pourquoi c'est important

Un bouton Reject qui ne bloque pas réellement le traitement optionnel est l'un des signes les plus nets d'un mécanisme de consentement mal appliqué.

Comment vérifier manuellement

1. Refusez le traitement optionnel dans une session propre puis rechargez la page.
2. Inspectez cookies et requêtes réseau après Reject.
3. Comparez le comportement avant et après Reject pour vérifier si le stockage optionnel s'arrête réellement.

Causes typiques

• Reject modifie seulement l'état visuel de la bannière sans propager un état denied.
• Les tags optionnels repartent au reload malgré un choix refusé.
• Les valeurs de consentement stockées sont mal lues ou ignorées après navigation.

Correction dans GTM

1. Assurez-vous que l'état denied est lu avant que les tags puissent repartir après reload.
2. Attachez des contrôles de consentement à tous les tags optionnels, pas uniquement aux événements du premier chargement.
3. Vérifiez dans GTM Preview que Reject persiste bien à travers les reloads.

Correction dans WordPress ou les plugins CMP

1. Contrôlez les intégrations de plugin qui continuent à charger des tags optionnels après Reject.
2. Vérifiez que le plugin CMP stocke et applique bien l'état denied sur tous les chargements de page.
3. Retirez les plugins de tracking redondants qui ignorent l'état CMP.

Correction générique côté développeur

1. Traitez Reject comme un état runtime exécutoire et non comme une simple action UI.
2. Bloquez les loaders optionnels sur chaque page lorsque le consentement stocké est denied.
3. Testez les scénarios de reload, revisit et navigation entre pages, pas seulement le premier chargement.

Comment confirmer que la correction fonctionne

• Reject puis reload: confirmez que les cookies optionnels restent absents.
• Reject puis reload: confirmez que les requêtes optionnelles restent bloquées.
• Lancez un nouveau scan et vérifiez que les findings liés à Reject disparaissent.