Le WordPress d'aujourd'hui, décodé pour les développeurs

Sécurité

Cookies et ePrivacy : ce qu’il faut vérifier avant d’activer le premier script tiers

Avant d'ajouter un script tiers à un site, encore faut-il s'assurer qu'il ne dépose aucun cookie tant que le visiteur n'a pas donné son consentement. Checklist technique.

Par WordPress Développement • 5 décembre 2021 • 4 min de lecture • Aucun commentaire
Cookies et ePrivacy : ce qu'il faut vérifier avant d'activer le premier script tiers

Depuis l’entrée en application des lignes directrices de la CNIL sur les cookies, au printemps 2021, une obligation technique précise s’impose à tout site qui intègre un script tiers : aucun cookie non essentiel ne doit être déposé avant que le visiteur n’ait donné un consentement explicite. Ce n’est pas une question de design de bannière, déjà traitée ailleurs en détail ; c’est une question de comportement réel du navigateur, vérifiable techniquement, indépendamment de ce que la bannière affiche visuellement.

Un développeur qui installe un plugin de widget de chat, un lecteur vidéo tiers ou un outil de mesure d’audience part souvent du principe que la bannière de consentement, une fois en place, protège automatiquement contre le dépôt anticipé de cookies. C’est faux dans une majorité des cas : la bannière et le blocage effectif du script sont deux choses distinctes, et la seconde ne découle pas automatiquement de la première.

Vérifier ce qui se passe vraiment avant le clic

Le test le plus fiable ne consiste pas à lire la documentation du plugin de consentement, mais à observer le comportement réel du navigateur. Ouvrir les outils de développement, onglet réseau, avant tout clic sur la bannière, et recharger la page en navigation privée révèle immédiatement si des requêtes vers des domaines tiers (un CDN de widget de chat, un service de mesure d’audience) partent déjà, avant même que le visiteur n’ait exprimé un choix.

Ce que la checklist technique doit couvrir

L'essentiel à retenir : Un script chargé avant consentement dépose déjà des cookies ; La directive ePrivacy encadre le dépôt, pas seulement la bannière ; Un test réseau vaut mieux qu'une supposition
  • Aucune requête réseau vers un domaine tiers non essentiel avant interaction avec la bannière.
  • Aucun cookie visible dans l’onglet « Application » du navigateur avant ce même moment.
  • Les scripts intégrés via un thème ou une extension (pas seulement ceux ajoutés manuellement) respectent la même règle.
  • Le refus du consentement empêche réellement le chargement, pas seulement l’affichage visuel du widget.
  • Un changement de choix (retrait du consentement) déclenche la suppression effective des cookies déjà posés, pas uniquement l’arrêt des nouveaux dépôts.

Le piège des scripts chargés par le thème lui-même

Un cas fréquent : un thème premium intègre nativement une police ou une bibliothèque hébergée sur un CDN externe, chargée dans le <head> de chaque page indépendamment de tout gestionnaire de consentement. Ce chargement, invisible dans la configuration du plugin de bannière puisqu’il n’y transite pas, échappe facilement à l’audit si l’on se contente de vérifier les scripts ajoutés explicitement par l’équipe éditoriale.

Toutes les technologies de suivi ne sont pas logées à la même enseigne. Un cookie strictement nécessaire au fonctionnement du site (panier d’achat, session de connexion) ne requiert pas de consentement préalable. Un cookie de mesure d’audience, même agrégée, en requiert un dès lors qu’il permet un suivi individualisé du visiteur d’une visite à l’autre. Cette distinction, souvent mal comprise, explique pourquoi certains outils de statistiques peuvent fonctionner en mode « exempté de consentement » lorsqu’ils sont configurés pour ne pas déposer d’identifiant persistant, quand d’autres l’exigent systématiquement.

Utiliser un gestionnaire de balises conditionné au consentement

Plutôt que de gérer manuellement le chargement conditionnel de chaque script, un gestionnaire de balises qui n’exécute un tag qu’après réception d’un signal de consentement explicite (stocké côté client, vérifié avant chaque exécution de script) centralise cette logique et réduit le risque d’oubli lors de l’ajout d’une nouvelle intégration.

Une bannière de consentement bien conçue ne prouve rien tant qu’un test réseau, effectué avant tout clic, n’a pas confirmé qu’aucun cookie tiers ne part réellement avant ce clic.

Documenter chaque script tiers ajouté au site

Pour éviter que ce contrôle ne redevienne nécessaire à chaque audit, un registre simple, tenu à jour à chaque ajout de script tiers, recense sa finalité, les cookies qu’il dépose et la catégorie de consentement dont il dépend. Ce registre sert aussi de base au registre des traitements exigé par ailleurs sur le plan réglementaire plus large.

Pour aller plus loin

La conception de la bannière elle-même, son texte, son design, ses options de granularité, mérite un traitement à part entière. Ce qui compte avant tout, techniquement, c’est que le comportement réel du site corresponde à ce que la bannière promet : aucun script tiers actif avant un consentement effectivement donné, vérifié dans les outils du navigateur et non supposé sur la seule foi de la configuration du plugin.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi