Comment ajouter un bandeau cookies à un site Django
Dans Django, collez la balise dans le head du template de base dont hérite chaque page (en général templates/base.html), au-dessus de tout bloc où les templates enfants ajoutent des scripts. Passez la clé de site depuis les settings avec un petit context processor, marquez les balises de suivi dans le même template avec type="text/plain" et data-cq-category, et listez les cookies sessionid et csrftoken de Django comme strictement nécessaires.Étapes
Où placer la balise dans Django ?
L’héritage de templates de Django construit chaque page à partir d’un template de base, le « squelette », que les templates enfants nomment avec {% extends "base.html" %} et remplissent via des balises {% block %}. La balise Cookiequiet va dans le head de ce template de base, au-dessus de tout bloc où les pages ajoutent des scripts :
django{# templates/base.html #}<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><script src="https://cookiequiet.com/cq.js" data-site="{{ COOKIEQUIET_SITE }}" data-consent-mode="1" data-auto-block="1" defer></script><title>{% block title %}My site{% endblock %}</title>{% block extra_head %}{% endblock %}</head><body>{% block content %}{% endblock %}</body></html>
Chaque vue qui rend un template héritant de base.html charge désormais le bandeau, pages Wagtail comprises, puisque les projets Wagtail utilisent le même héritage de templates.
Passez la clé depuis les settings. Un context processor ajoute une variable à chaque template rendu avec une requête :
python# settings.pyCOOKIEQUIET_SITE = os.environ.get("COOKIEQUIET_SITE", "")# mysite/context_processors.pyfrom django.conf import settingsdef cookiequiet(request):return {"COOKIEQUIET_SITE": settings.COOKIEQUIET_SITE}
Ajoutez ensuite "mysite.context_processors.cookiequiet" à la liste context_processors de TEMPLATES. Écrire la clé directement dans le template fonctionne aussi : elle est publique, elle apparaît dans chaque page.
Comment bloquer mes balises jusqu’au consentement ?
Collez les balises de suivi sous la balise Cookiequiet et modifiez leur balise d’ouverture :
html<script type="text/plain" data-cq-category="analytics" src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script><script type="text/plain" data-cq-category="analytics">window.dataLayer = window.dataLayer || [];function gtag(){dataLayer.push(arguments);}gtag('js', new Date());gtag('config', 'G-XXXXXXX');</script>
Cookiequiet exécute les balises marquées quand la catégorie est accordée, et d’emblée lors des visites suivantes où le choix enregistré l’inclut. Les balises qu’une page ajoute dans {% block extra_head %} fonctionnent de la même façon quand le bloc se trouve sous la balise Cookiequiet. Le guide Google Analytics 4 explique l’alternative du Consent Mode, et le guide sur le blocage des scripts couvre les contenus embarqués et les autres balises. Les scripts créés à l’exécution par JavaScript sont retenus par le bloqueur automatique quand ils viennent de l’un des quelque 80 traceurs qu’il connaît.
L’admin Django. L’admin utilise ses propres templates et n’hérite pas de votre base.html : il n’a donc pas de bandeau. Il sert à votre équipe, pas aux visiteurs, et ne dépose que les cookies propres à Django.
Et les cookies propres à Django ?
Django dépose sessionid quand la session est utilisée (par exemple après une connexion) et csrftoken pour la protection contre la falsification de requêtes intersites sur les pages avec formulaires. Les deux servent une fonction demandée par le visiteur : ils sont donc strictement nécessaires et ne demandent pas de consentement dans la plupart des lectures des règles ePrivacy. Listez-les comme nécessaires dans le tableau des cookies ; le bandeau ne les bloque pas. Le scanner de cookies les trouve, ainsi que les éventuels cookies tiers.
Comment cela fonctionne-t-il avec la Content Security Policy de Django ?
Django 6.0 a ajouté la prise en charge intégrée de la Content Security Policy : un middleware envoie l’en-tête, le réglage SECURE_CSP contient la politique, et le context processor django.template.context_processors.csp expose une variable csp_nonce. Ajoutez https://cookiequiet.com à script-src et connect-src (le bandeau récupère sa configuration, la géolocalisation et les enregistrements de consentement depuis cette origine), et donnez aux scripts inline nonce="{{ csp_nonce }}". Les scripts inline marqués le reçoivent aussi (<script type="text/plain" data-cq-category="analytics" nonce="{{ csp_nonce }}">) : Cookiequiet copie le nonce sur le script qu’il exécute après le consentement, et la politique le laisse donc passer.
Comment ajouter le lien Préférences de cookies ?
html<a href="#cq-preferences" data-cq-show-preferences>Cookie preferences</a>
Comment tester ?
- Lancez le serveur de développement, ou déployez, et affichez le code source de la page :
cq.jsest le premier script du head. - Ouvrez le site dans une fenêtre de navigation privée et cliquez sur Tout refuser. Les cookies sont
cq_consentet, sur les pages avec formulaires ou après une connexion,csrftokenetsessionid. - Effacez les cookies, cliquez sur Tout accepter, rechargez : les balises marquées s’exécutent et
_gaapparaît. - Consultez le registre des consentements dans le tableau de bord.
L’installation tient en une balise dans un template, sans paquet Django à installer. Cookiequiet est gratuit pour un site, ciblage géographique compris ; Starter coûte 3 € par site et par mois, sans limite de pages vues.
Questions
Sources
- Docs Django : le langage de templates de Django (héritage de templates)
- Docs Django : écrire vos propres context processors
- Docs Django : utiliser la Content Security Policy de Django
- Docs Django : notes de version de Django 6.0
- Docs Django : protection contre la falsification de requêtes intersites (CSRF)