Types de cookies : guide technique complet

Tous les cookies ne se valent pas. Le type d'un cookie détermine sa durée de vie, qui peut le lire, la sécurité de sa transmission et — point crucial — s'il nécessite le consentement de l'utilisateur. Comprendre ces distinctions est essentiel, tant pour la conformité que pour la mise en œuvre technique.

Cookies de session ou cookies persistants

La distinction la plus fondamentale porte sur la durée de vie d'un cookie.

Cookies de session

Un cookie de session n'existe que le temps d'une session de navigation. Il ne possède pas d'attribut Expires ni Max-Age. Lorsque l'utilisateur ferme son navigateur, le cookie est supprimé.

Set-Cookie: cart_id=xyz789; Path=/; Secure; HttpOnly

Les cookies de session servent généralement à :

• Maintenir l'état de connexion pendant une visite
• Conserver le contenu d'un panier d'achat
• Gérer les jetons de protection CSRF
• Stocker les données de formulaires multi-étapes

Comme les cookies de session ne persistent pas, ils sont en général moins intrusifs du point de vue de la vie privée. Ils nécessitent toutefois un consentement s'ils ne sont pas strictement nécessaires au service demandé par l'utilisateur.

Cookies persistants

Un cookie persistant possède une date d'expiration explicite. Il survit aux redémarrages du navigateur et reste sur l'appareil de l'utilisateur jusqu'à son expiration ou sa suppression manuelle.

Set-Cookie: preferences_lang=en; Path=/; Max-Age=31536000; Secure

Ce cookie persistera pendant un an (31 536 000 secondes). Les usages courants incluent :

• La fonctionnalité « se souvenir de moi » à la connexion
• Les préférences de langue et de thème
• Les identifiants d'analyse (les cookies Google Analytics persistent jusqu'à 2 ans)
• Le suivi publicitaire (certains cookies publicitaires persistent 13 mois ou plus)

Les cookies persistants font l'objet d'une surveillance accrue au titre des réglementations sur la vie privée. La CNIL (l'autorité française de protection des données) recommande une durée de vie maximale de 13 mois pour les cookies, et le consentement doit également être renouvelé au moins tous les 13 mois.

Cookies internes ou cookies tiers

Cette distinction est au cœur du débat sur la vie privée et affecte directement les exigences de consentement.

Cookies internes (first-party)

Un cookie interne est déposé par le domaine que l'utilisateur consulte réellement. Si vous visitez example.com, tout cookie déposé par example.com est un cookie interne.

Les cookies internes assurent les fonctionnalités essentielles du site : sessions, préférences, analyses gérées par l'exploitant du site lui-même. Ils ne peuvent être lus que par le domaine qui les a déposés.

Exemple : vous visitez shop.example.com. Le serveur dépose un cookie nommé session_id. Ce cookie n'est transmis qu'à shop.example.com et à ses sous-domaines. Aucun autre site web ne peut y accéder.

Cookies tiers (third-party)

Un cookie tiers est déposé par un domaine autre que celui que l'utilisateur consulte. Lorsque example.com charge un script publicitaire depuis ads.tracker.com et que ce script dépose un cookie sous le domaine tracker.com, il s'agit d'un cookie tiers.

C'est ainsi que fonctionne le suivi intersites. Le cookie tracker.com est transmis à chaque requête vers tracker.com, quel que soit le site web à l'origine de la requête. Si les scripts de tracker.com sont intégrés à 10 000 sites web, ils peuvent observer le même utilisateur sur l'ensemble de ces 10 000 sites.

Les cookies tiers sont la cible principale à la fois des actions réglementaires et des restrictions imposées au niveau des navigateurs :

• Safari bloque les cookies tiers par défaut depuis 2020 (ITP)
• Firefox bloque par défaut les traceurs tiers connus (ETP)
• Chrome abandonne progressivement les cookies tiers avec son initiative Privacy Sandbox
• Les actions réglementaires visent massivement les cookies de suivi tiers

Cookies sécurisés (Secure)

Un cookie doté de l'attribut Secure n'est transmis que via des connexions HTTPS. Il ne sera jamais transmis via une connexion HTTP non chiffrée.

Set-Cookie: auth_token=secret123; Secure

Cela empêche un attaquant de type « homme du milieu » d'intercepter le cookie sur une connexion non sécurisée. Tout cookie contenant des informations sensibles — identifiants de session, jetons d'authentification, données personnelles — devrait toujours être marqué comme Secure.

Du point de vue de la conformité, ne pas utiliser l'attribut Secure sur des cookies sensibles pourrait être considéré comme un manquement à l'obligation de mettre en œuvre des mesures techniques appropriées au titre de l'article 32 du RGPD (sécurité du traitement).

Cookies HttpOnly

Un cookie doté de l'attribut HttpOnly ne peut pas être lu par JavaScript via document.cookie. Il n'est transmis qu'avec les requêtes HTTP vers le serveur.

Set-Cookie: session_id=abc123; HttpOnly

Il s'agit d'une mesure de sécurité essentielle. Les attaques par script intersites (XSS) tentent souvent de dérober des cookies en injectant du code JavaScript qui lit document.cookie. L'attribut HttpOnly neutralise entièrement ce vecteur d'attaque.

Les cookies de session et d'authentification devraient presque toujours être HttpOnly. Les cookies qui doivent être lus par du JavaScript côté client (comme les cookies de préférence qui influent sur l'interface) ne peuvent pas être HttpOnly.

Cookies SameSite

L'attribut SameSite contrôle si un cookie est transmis lors de requêtes intersites. Il a été introduit pour atténuer les attaques par falsification de requête intersite (CSRF) et pour donner aux sites un meilleur contrôle sur le comportement des cookies intersites.

SameSite=Strict

Le cookie n'est transmis qu'avec les requêtes provenant du même site. Si un utilisateur clique sur un lien situé sur other.com qui mène vers your-site.com, le cookie ne sera pas transmis avec cette requête initiale.

C'est le paramètre le plus sûr, mais il peut casser des fonctionnalités légitimes. Par exemple, si un utilisateur clique sur un lien vers votre site depuis un e-mail, son cookie de session ne serait pas transmis et il apparaîtrait comme déconnecté.

SameSite=Lax

Le cookie est transmis lors des navigations de premier niveau (clic sur un lien), mais pas lors des sous-requêtes intersites (chargement d'images, de cadres ou requêtes AJAX depuis un autre site). C'est le comportement par défaut des navigateurs modernes lorsqu'aucun attribut SameSite n'est spécifié.

Lax offre un équilibre raisonnable entre sécurité et convivialité. Il empêche des sites tiers de déclencher des actions authentifiées sur votre site tout en permettant à la navigation normale par lien de fonctionner.

SameSite=None

Le cookie est transmis avec toutes les requêtes, y compris les requêtes intersites. C'est indispensable au fonctionnement des cookies tiers. Un cookie défini avec SameSite=None doit également posséder l'attribut Secure.

Set-Cookie: tracking_id=xyz; SameSite=None; Secure

Tout cookie devant fonctionner dans un contexte intersite (widgets intégrés, authentification tierce, suivi intersites) doit utiliser SameSite=None. Ce point est de plus en plus pertinent à mesure que les navigateurs durcissent leurs politiques par défaut en matière de cookies.

Cookies zombies et supercookies

Il vaut la peine de les mentionner car ils représentent des tentatives de contourner les contrôles de confidentialité :

• Les cookies zombies sont des cookies qui se recréent après avoir été supprimés. Ils fonctionnent généralement en stockant le même identifiant dans plusieurs mécanismes de stockage (cookies, localStorage, IndexedDB, LSO Flash) et en utilisant celui qui survit pour régénérer les autres. Cette pratique est largement considérée comme trompeuse et a fait l'objet d'actions répressives.
• Les supercookies sont des mécanismes de suivi qui opèrent à un niveau inférieur aux cookies classiques — comme l'injection d'en-têtes au niveau du fournisseur d'accès (l'UIDH de Verizon) ou le fingerprinting basé sur HSTS. Ils sont extrêmement difficiles à contrôler ou à supprimer pour les utilisateurs.

Les cookies zombies comme les supercookies sont manifestement incompatibles avec les exigences du RGPD et de la directive ePrivacy. Les utiliser constituerait une violation des principes de transparence, de licéité et de minimisation des données.

Tableau comparatif

Type	Durée de vie	Portée	Consentement généralement requis ?	Principaux cas d'usage
Session	Session de navigation uniquement	Interne	Uniquement si non essentiel	État de connexion, panier, jetons CSRF
Persistant (interne)	De quelques jours à plusieurs années	Interne	Généralement oui	Préférences, analyses, « se souvenir de moi »
Persistant (tiers)	De quelques jours à plusieurs années	Intersite	Presque toujours oui	Publicité, reciblage, widgets sociaux
Secure	Variable	HTTPS uniquement	Selon la finalité	Tout cookie sensible
HttpOnly	Variable	Côté serveur uniquement	Selon la finalité	Identifiants de session, jetons d'authentification
SameSite=Strict	Variable	Même site uniquement	Selon la finalité	Opérations sensibles au CSRF
SameSite=Lax	Variable	Même site + navigation de premier niveau	Selon la finalité	Gestion générale des sessions
SameSite=None	Variable	Tous les contextes (nécessite Secure)	Presque toujours oui	Intégrations tierces, authentification intersite

Ce que cela signifie pour la conformité

Le type d'un cookie influe directement sur vos obligations de conformité :

1. Les cookies de session internes strictement nécessaires (sessions de connexion, paniers d'achat, jetons CSRF) sont exemptés de l'exigence de consentement au titre de l'article 5(3) de la directive ePrivacy.
2. Les cookies persistants internes destinés aux analyses, aux préférences ou aux fonctionnalités nécessitent généralement un consentement — même si certaines autorités de protection des données autorisent des exceptions limitées pour les analyses internes sous certaines conditions.
3. Les cookies tiers, quels qu'ils soient, nécessitent presque toujours un consentement explicite préalable. Les exceptions légitimes sont très rares.
4. Les attributs de sécurité (Secure, HttpOnly, SameSite) ne modifient pas les exigences de consentement, mais leur utilisation témoigne de bonnes pratiques de sécurité — ce qui constitue en soi une exigence du RGPD.

Savoir précisément quels cookies votre site web dépose — et de quel type chacun relève — est le fondement de tout programme de conformité. Le scanner de Passiro identifie et classe automatiquement chaque cookie présent sur votre site web, y compris les cookies tiers déposés par des scripts intégrés dont vous ignorez peut-être même l'existence.

Maintenant que nous comprenons les types de cookies, voyons comment ils sont organisés en catégories de consentement — le système de classification qui détermine leur présentation dans votre bandeau de cookies.