La Loi Cookies Ne Concerne Plus les Cookies : Ce Que Couvre Désormais l'Article 5(3)

L'expression « loi cookies » a toujours été un faux nom. L'article 5(3) de la directive ePrivacy n'a jamais utilisé le mot cookie — il parle de « stocker des informations, ou d'obtenir l'accès à des informations déjà stockées, dans l'équipement terminal d'un abonné ou d'un utilisateur ». Pendant deux décennies, les régulateurs ont appliqué ce texte surtout aux cookies parce que les cookies étaient le mécanisme de stockage dominant. Cette période est révolue.

En octobre 2024, le Comité européen de la protection des données a finalisé les Lignes directrices 2/2023 sur le champ technique de l'article 5(3). Ces lignes directrices sont technologiquement neutres et couvrent explicitement les pixels de suivi, le suivi par URL, le suivi par IP seule et les identifiants uniques. En avril 2026, la CNIL française et le Garante italien ont traduit ce cadre en orientations nationales contraignantes sur le suivi par pixel dans les e-mails. La direction est sans ambiguïté : si une technique permet à un serveur de lire des signaux identifiants depuis l'appareil d'un visiteur, le consentement est requis, qu'il y ait ou non quelque chose d'écrit en retour.

Ce que « obtenir l'accès » signifie désormais

L'article 5(3) repose sur deux concepts opérationnels : le stockage et l'obtention de l'accès. La majorité du travail de conformité actuel ne traite que le stockage comme déclencheur — si vous ne déposez pas de cookie, vous présumez qu'aucun consentement n'est nécessaire. Les lignes directrices rejettent cette lecture.

L'obtention de l'accès est satisfaite lorsqu'un serveur instruit activement l'appareil de renvoyer des valeurs. Un pixel de suivi déclenche une requête dont la chaîne de requête porte des identifiants. Une URL unique intégrée à une newsletter résout le destinataire. Une adresse IP, lorsqu'elle est utilisée pour suivre le même appareil entre sessions, est également un accès — la valeur provient de la pile réseau de l'appareil et est envoyée à chaque requête.

Ce qui compte, c'est le mécanisme, pas le format de persistance. Une empreinte stockée dans une base de données côté serveur est traitée à l'identique d'un cookie stocké dans le navigateur.

Pourquoi cela réécrit la cartographie des outils analytics

De nombreux outils analytics axés sur la vie privée se présentent comme sans cookies tout en s'appuyant encore sur des schémas désormais couverts par les lignes directrices :

• Cookies côté serveur et identifiants partitionnés de type CHIPS. Déplacer le cookie vers un contexte partitionné ou vers un stockage de première partie côté serveur ne change rien à la question de l'accès. Si le même identifiant atteint le serveur analytics entre les visites, il s'agit toujours d'un accès.
• Identifiants visiteurs dérivés de l'IP. Les outils qui hachent l'IP et utilisent le hachage comme identifiant stable entre les jours accèdent à des informations provenant de l'appareil. L'avis du CEPD est explicite : cela nécessite un consentement, à moins que le responsable du traitement ne puisse démontrer que l'IP ne provenait pas de l'équipement terminal de l'utilisateur.
• Suivi par pixel des ouvertures et des vues. La décision n° 2026-042 de la CNIL (14 avril 2026) et les lignes directrices du Garante du 17 avril 2026 exigent un consentement explicite et distinct pour le suivi individuel des ouvertures dans l'e-mail — avant l'envoi de l'e-mail.

Le schéma commun est un identifiant stable qui survit entre les visites, les sessions ou les messages. Quelle que soit la couche de stockage, il crée la même exposition réglementaire qu'un cookie.

Le test technique pour une collecte conforme

Les lignes directrices laissent un couloir étroit : des signaux agrégés où aucune valeur stockée par le serveur ne se résout vers un appareil spécifique au fil du temps. Une requête vers un endpoint de collecte porte des valeurs qui se répartissent en trois catégories :

1. Transport-layer values (IP, User-Agent) the server cannot avoid receiving
2. Contextual values (path, referrer domain, country derived from IP)
3. Derived values the server chooses to produce and store

La catégorie 1 est inévitable en TCP/HTTP. La question est de savoir à quoi ressemble la catégorie 3. Si une valeur dérivée est un identifiant persistant — même hachée, même salée — c'est un accès. Si une valeur dérivée se réinitialise dans une fenêtre bornée et ne peut être corrélée entre fenêtres, l'analyse du CEPD la traite comme agrégée.

Le hachage visiteur quotidien de Monoid est conçu en regard de ce test :

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

L'IP et l'User-Agent ne sont utilisés qu'en mémoire pour calculer le hachage, puis écartés. L'entrée de date signifie que le même visiteur produit un hachage différent demain — par construction, aucun identifiant inter-jours n'existe à atteindre. Au sein d'une même journée, le hachage déduplique un visiteur pour les comptages agrégés ; entre les jours, il n'y a rien qu'un adversaire ou un régulateur puisse reconstituer.

Les en-têtes qui comptent sur l'endpoint de collecte

Deux en-têtes HTTP portent l'essentiel de la surface vie privée d'un collecteur edge de première partie et doivent être définis délibérément.

Referrer-Policy: strict-origin-when-cross-origin est la valeur par défaut moderne de Chrome et n'envoie que l'origine sur les requêtes cross-origin. Évitez unsafe-url et no-referrer-when-downgrade — tous deux fuitent des informations de chemin inutilement.

Permissions-Policy doit refuser explicitement les fonctionnalités dont le traceur analytics n'a pas besoin :

Permissions-Policy: geolocation=(), microphone=(), camera=(),
  payment=(), usb=(), interest-cohort=()

Un traceur qui ne peut pas demander la localisation, l'audio ou les capteurs de l'appareil ne peut pas être contraint de le faire par un script tiers compromis partageant la page.

Ce que les développeurs devraient auditer ce trimestre

Trois questions font avancer l'audit :

1. Une valeur quelconque stockée par le serveur analytics permet-elle d'identifier le même visiteur sur une fenêtre de 25 heures ? Si oui, le déploiement nécessite probablement désormais le consentement de l'article 5(3).
2. Des identifiants pixel et URL sont-ils utilisés dans les e-mails transactionnels ou marketing ? Selon les orientations de la CNIL et du Garante, le suivi individuel des ouvertures requiert un consentement distinct et explicite avant l'envoi de l'e-mail.
3. L'endpoint de collecte définit-il une Referrer-Policy stricte et une Permissions-Policy refusant par défaut ?

La question du « bandeau cookies » est subordonnée à une plus fondamentale : le modèle de données produit-il un identifiant inter-sessions tout court ? Lorsque la réponse est non, toute la machinerie de l'article 5(3) — consentement, retrait, registre des traitements — ne s'engage pas, parce que le déclencheur technique de la réglementation n'a jamais été actionné.