Consentement aux cookies sur plusieurs sous-domaines et domaines
Un choix cookies peut-il couvrir les sous-domaines www, shop, blog ou d’autres domaines ? Portée des cookies, quand partager ou redemander, et comment tester.Un choix de consentement est stocké dans un cookie ou dans le local storage, et l’endroit où il peut être lu dépend de la façon dont il a été stocké. Un cookie déposé avec Domain=example.com est lisible sur chaque sous-domaine (www, shop, blog), donc un seul choix peut tous les couvrir. Un cookie déposé sans attribut Domain est lié à l’hôte (host-only) et reste sur l’hôte exact qui l’a déposé, et le local storage est toujours limité à une seule origine. Des domaines distincts (example.com et example.de) ne peuvent jamais partager un cookie. Faut-il partager le choix ? C’est une autre question : cela a du sens quand la même organisation exploite les sous-domaines pour les mêmes finalités et que le bandeau dit que le choix les couvre.
Comment fonctionne la portée d’un cookie ?
La référence de MDN sur l’en-tête Set-Cookie résume la règle :
- Domain renseigné : le cookie est disponible pour ce domaine et tous ses sous-domaines. Une réponse de shop.example.com peut poser
Domain=example.com, et le cookie est alors envoyé aussi à www.example.com et à blog.example.com. - Domain omis : le cookie est lié à l’hôte, renvoyé seulement à l’hôte qui l’a déposé, pas à ses sous-domaines.
- Limites : la valeur doit être le domaine du serveur lui-même ou un domaine parent, jamais un domaine voisin (shop ne peut pas déposer de cookie pour blog) et jamais un suffixe public comme
com,co.ukougithub.io.
Le local storage, que certains outils de consentement utilisent aussi, appartient à une origine : schéma, hôte et port. https://www.example.com et https://shop.example.com ont des stockages distincts, tout comme les versions http et https d’un même hôte.
Quand le partage a-t-il du sens ?
Partager un même choix entre sous-domaines est raisonnable quand :
- la même entreprise est responsable du traitement sur chaque sous-domaine ;
- les sous-domaines utilisent les mêmes catégories et à peu près les mêmes outils ;
- le bandeau indique aux visiteurs que le choix s’applique aux sites listés ;
- un retrait sur un sous-domaine vaut retrait partout.
Mieux vaut redemander quand un sous-domaine est exploité par une autre entreprise (un franchisé, une boutique partenaire sur votre domaine), quand il utilise des traceurs très différents (une boutique très orientée marketing sous un site de documentation sobre), ou quand il vise une autre audience. Le consentement au sens du RGPD doit être spécifique et éclairé ; un choix fait sur docs.example.com n’informe personne de la publicité sur shop.example.com si le bandeau ne l’a jamais mentionnée.
Comment partager le consentement entre sous-domaines ?
Si votre outil de consentement vous permet de régler le domaine du cookie, réglez-le sur le domaine parent sur chaque sous-domaine, utilisez la même configuration et les mêmes catégories partout, et assurez-vous que le texte du bandeau précise la portée (« Votre choix s’applique à example.com, shop.example.com et blog.example.com »). Les étapes numérotées sous l’article détaillent la marche à suivre.
Deux pièges techniques :
- Les cookies en double. Si l’outil stockait auparavant un cookie lié à l’hôte et stocke désormais un cookie de domaine du même nom, le navigateur envoie les deux. Supprimez l’ancien au déploiement ou renommez le cookie, sinon les visiteurs risquent de voir un choix périmé.
- Les versions différentes. Si un sous-domaine utilise une version plus récente du bandeau avec une catégorie supplémentaire, un choix partagé fait sous l’ancienne version ne couvre pas la nouvelle catégorie. Redemandez pour les nouvelles finalités.
Et les domaines distincts ?
Les cookies ne peuvent pas franchir les domaines enregistrables. example.com ne peut ni déposer ni lire un cookie pour example.de ou example-shop.com. Les approches qui fonctionnaient autrefois, comme une iframe cachée servie depuis un domaine central, reposent sur les cookies tiers, que Safari et Firefox restreignent et que les réglages de confidentialité bloquent souvent. Deux options praticables :
- Demander sur chaque domaine. La plus simple et la plus transparente. Chaque domaine a son propre bandeau, son propre registre et sa propre politique.
- Transmettre le choix dans un lien. Quand vous faites un lien d’un domaine vers un autre, la destination peut lire un paramètre dans l’URL et stocker le même choix localement, si le visiteur a suivi votre propre lien. C’est plus de travail, et le lien ne doit transporter aucun identifiant qui permette de suivre le visiteur.
Pour la plupart des entreprises, demander une fois par domaine est le bon compromis : les visiteurs passent rarement d’un domaine pays à l’autre, et la preuve du consentement reste simple.
Comment le tester ?
Effacez toutes les données du site pour le domaine parent, ouvrez www, choisissez « Tout refuser », puis ouvrez chaque sous-domaine dans le même navigateur. Avec le partage, aucun bandeau ne doit apparaître et les traceurs doivent rester désactivés. Vérifiez dans le panneau Application que le cookie de consentement porte le domaine parent dans sa colonne Domain. Retirez ensuite le consentement sur un sous-domaine et vérifiez les autres. Vérifier les cookies avant consentement donne la procédure DevTools complète.
Que mettre dans le registre des consentements ?
Enregistrez l’hôte sur lequel le choix a été fait et les hôtes qu’il couvre. Si vous tenez vos preuves de consentement par site, assurez-vous qu’un choix fait sur un sous-domaine peut être retrouvé quand une autorité pose des questions sur un autre.
Comment Cookiequiet gère les sous-domaines
Cookiequiet stocke le choix dans un cookie interne sur l’hôte exact, plus le local storage, donc chaque sous-domaine et chaque domaine demande une fois, ce qui est le réglage par défaut prudent. Les offres payantes permettent de rattacher des domaines supplémentaires (www, préproduction, domaines pays) à un même site, avec une seule configuration et un seul registre des consentements : 1 sur Starter, à 3 € par site et par mois, et jusqu’à 5 sur Pro, à 9 €. L’installation tient en une balise script sur chaque hôte, avant vos autres scripts ; la page tarifs détaille ce que comprend chaque offre.