Guides

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.
Publié le 21 octobre 2026 · Par l’équipe Cookiequiet

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.

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.uk ou github.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 :

  1. 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é.
  2. 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.

Questions

Seulement si le cookie de consentement a été déposé pour le domaine parent et si le bandeau a indiqué aux visiteurs que le choix couvre la boutique. Un cookie lié à l’hôte reste sur www, donc la boutique redemande, ce qui est aussi le réglage par défaut le plus sûr quand les sous-domaines utilisent des outils différents.
Pas avec un cookie. Les navigateurs ne laissent jamais un domaine enregistrable déposer ou lire des cookies pour un autre. Demandez sur chaque domaine, ou transmettez le choix par vos propres liens et stockez-le de nouveau à l’arrivée.
Non. Le local storage appartient à une origine, c’est-à-dire un schéma, un hôte et un port. Chaque sous-domaine a le sien, donc un choix enregistré seulement dans le local storage n’est pas visible sur les autres sous-domaines.
Pas nécessairement, mais chaque enregistrement doit indiquer l’hôte où le choix a été fait et les hôtes qu’il couvre. Cela vous permet de prouver le consentement pour n’importe quel sous-domaine sur lequel une autorité vous interroge.

Mettez un bandeau discret sur votre site dès aujourd’hui

Gratuit pour un site avec toutes les fonctions essentielles, sans carte ni période d’essai qui expire. Passez un site en Starter pour €3 par mois pour le mettre à vos couleurs par IA sans la mention Cookiequiet, ou en Pro pour €9 pour le concevoir avec l’agent IA.