L'article 5(3) de la directive ePrivacy expliqué : quand le consentement est-il nécessaire pour l'analytique ? -- Web-Tracking.eu

Qu'est-ce que la directive ePrivacy ?

La plupart des gens dans le monde de l'analyse web parlent du RGPD comme s'il était la seule loi pertinente pour suivre les visiteurs. Ce n'est pas le cas. La règle qui décide réellement si vous avez besoin d'une bannière de consentement cookies est plus ancienne que le RGPD et figure dans un texte distinct : la directive ePrivacy, formellement la directive 2002/58/CE, modifiée par la directive 2009/136/CE.

La directive ePrivacy encadre la vie privée dans le secteur des communications électroniques. Elle régit entre autres la confidentialité des communications, la conservation des données de trafic, les communications commerciales non sollicitées (spam) et — le plus connu — le dépôt et la lecture d'informations sur les équipements terminaux des utilisateurs finaux. Ce dernier sujet est couvert par l'article 5(3), qui constitue la base juridique de la « bannière cookies » que l'on voit sur presque tous les sites web dans l'UE.

Comme la directive ePrivacy est une directive et non un règlement, chaque État membre de l'UE la transpose en droit national. En France, elle figure dans la Loi Informatique et Libertés via l'article 82. En Allemagne, il s'agit désormais du §25 TTDSG / TDDDG. Au Danemark, c'est la cookie bekendtgørelse. Au Royaume-Uni (post-Brexit), elle reste en vigueur sous forme de PECR. Le texte sous-jacent est harmonisé, de sorte que l'analyse ci-dessous s'applique largement dans toute l'UE, même si la référence légale exacte diffère.

Le texte intégral de l'article 5(3)

Voici la disposition opérationnelle en entier. Elle mérite d'être lue lentement :

"Les États membres garantissent que le stockage d'informations, ou l'obtention de l'accès à des informations déjà stockées, dans l'équipement terminal d'un abonné ou d'un utilisateur n'est permis qu'à la condition que l'abonné ou l'utilisateur ait donné son accord, après avoir reçu, dans le respect de la directive 95/46/CE, une information claire et complète, entre autres sur les finalités du traitement. Cette disposition ne fait pas obstacle à un stockage ou à un accès techniques visant exclusivement à effectuer ou à faciliter la transmission d'une communication par la voie d'un réseau de communications électroniques, ou strictement nécessaires au fournisseur pour la fourniture d'un service de la société de l'information expressément demandé par l'abonné ou l'utilisateur."

Trois expressions font presque tout le travail dans ce paragraphe : « stockage d'informations, ou l'obtention de l'accès », « équipement terminal d'un abonné ou d'un utilisateur » et « strictement nécessaires ». Tout le reste est un échafaudage. Prenons-les une par une.

Le déclencheur « stockage ou accès à des informations »

L'article 5(3) est technologiquement neutre. Il ne parle pas de « cookies ». Il parle de « stockage d'informations » ou d'« obtention de l'accès à des informations déjà stockées ». Cette formulation est délibérément large et couvre toute technique qui écrit des données sur l'appareil de l'utilisateur ou en lit.

En pratique, cela inclut :

Les cookies HTTP, qu'ils soient first-party ou third-party
localStorage, sessionStorage et IndexedDB
L'API Cache et les Service Workers
Les ETags, les en-têtes Last-Modified et autres astuces de cache HTTP
L'état du Server Push HTTP/2, le pinning HSTS
Le fingerprinting via Canvas, WebGL, audio et polices (qui techniquement lit des informations de l'appareil)
La lecture des polices installées, des plugins ou des capacités matérielles de l'utilisateur
La lecture du contenu du presse-papiers, de l'état de la batterie ou d'autres API de l'appareil

Notez que le déclencheur s'applique indépendamment du fait que les informations stockées ou consultées soient des données personnelles. Même un jeton opaque et non identifiant compte. Et il s'applique que le site lise activement ou non les informations — le simple stockage suffit.

Cela signifie également que l'argument « ce n'est pas un cookie, c'est du localStorage » que certains fournisseurs d'analytique avançaient est sans fondement. La loi n'a jamais porté spécifiquement sur les cookies ; elle a toujours porté sur toute forme de stockage ou d'accès sur l'appareil de l'utilisateur.

L'élément « équipement terminal »

« Équipement terminal » désigne l'appareil que l'utilisateur utilise pour accéder à internet : téléphone, ordinateur portable, tablette, smart TV, console — n'importe quoi. La directive trace une ligne claire entre le réseau (serveurs, routeurs, le câble) et le point d'extrémité (l'appareil de l'utilisateur).

Cette distinction est le concept le plus important pour l'analytique sans cookies. Tout ce qui se passe entièrement du côté serveur de cette ligne est en dehors de l'article 5(3). Tout ce qui touche l'appareil de l'utilisateur est à l'intérieur. Il n'y a pas de terrain intermédiaire.

Les logs serveur, les identifiants hachés calculés sur le serveur, les en-têtes de requête analysés et rejetés, les recherches géographiques basées sur l'adresse IP — aucun de ces éléments n'est « stockage d'informations sur l'équipement terminal » ou « obtention de l'accès à des informations déjà stockées » sur l'appareil. Ce sont des choses que le serveur a déjà parce qu'il reçoit la requête HTTP.

Cookies, localStorage, fingerprinting, lectures d'API d'appareil — tous franchissent la ligne vers l'appareil. Ils sont tous dans le champ d'application.

L'exception « strictement nécessaires »

L'article 5(3) contient une exception pour le stockage ou l'accès « strictement nécessaires » à l'une des deux finalités suivantes :

Transmettre une communication via un réseau de communications électroniques — cela couvre des éléments tels que le routage, l'équilibrage de charge et l'état au niveau TCP.
Fournir un « service de la société de l'information expressément demandé par l'abonné ou l'utilisateur ».

La seconde branche est celle qui importe aux opérateurs web. Parmi les exemples généralement acceptés comme « strictement nécessaires » :

Le cookie de session qui vous maintient connecté après votre connexion active
Le cookie qui stocke les articles de votre panier pendant le checkout
Le cookie qui mémorise votre propre choix de consentement aux cookies (une exception circulaire mais pragmatique)
Les jetons CSRF qui protègent contre la falsification de requêtes intersites
Les cookies d'adhérence de l'équilibreur de charge

Exemples qui ne sont pas « strictement nécessaires » :

Les cookies d'analytique, car l'utilisateur n'a pas demandé à être mesuré
Les cookies publicitaires, car l'utilisateur n'a pas demandé à voir des annonces ciblées
Les cookies de préférence pour des choses que le site peut livrer sans eux

Le test n'est pas « est-ce utile à l'opérateur du site ? » mais « est-ce nécessaire pour un service que l'utilisateur a explicitement demandé ? » L'analytique échoue à ce test dans toute lecture honnête, car les visiteurs ne demandent presque jamais à être mesurés.

Comment les autorités de protection des données interprètent « strictement nécessaires »

Le Comité européen de la protection des données (CEPD) et les autorités nationales individuelles ont constamment appliqué une lecture restrictive de « strictement nécessaires ». Les interprétations qui comptent le plus en pratique :

CNIL (France) a publié des lignes directrices détaillées reconnaissant une « exemption mesure d'audience » limitée pour l'analytique qui remplit des conditions spécifiques : strictement first-party, pas de suivi intersites, finalités limitées, conservation limitée et aucun partage avec des tiers. Les outils qui remplissent toutes les conditions peuvent être déployés sans bannière de consentement. Ceux qui ne le font pas, non.
DSK (Allemagne) adopte une ligne plus stricte : toute analytique qui stocke quoi que ce soit sur l'appareil requiert un consentement. L'analytique sans cookies qui ne stocke rien sur l'appareil est simplement hors du champ du §25 TTDSG et donc hors de l'exigence de consentement.
Datatilsynet (Danemark) suit fidèlement la directive : les règles cookies s'appliquent à tout ce qui stocke ou lit des informations sur l'appareil. Si rien n'est stocké ou lu, les règles ne sont pas engagées du tout.
ICO (Royaume-Uni) confirme explicitement dans ses lignes directrices PECR que l'analytique first-party peut bénéficier d'une exemption dans des circonstances limitées, mais le chemin le plus sûr est de s'appuyer sur le consentement ou sur une architecture qui n'implique aucun stockage.

Malgré des différences de ton, toutes les autorités de protection des données de l'UE s'accordent sur le même mécanisme juridique : si vous ne stockez rien sur l'appareil, l'article 5(3) n'est pas déclenché, et l'exigence de consentement ne s'applique pas à l'analytique elle-même.

L'exemption CNIL pour la mesure d'audience

La position de la CNIL mérite un examen plus attentif car c'est la plus permissive et la plus explicite en Europe. Selon ses lignes directrices, les cookies et traceurs d'analytique peuvent être exemptés de consentement si toutes les conditions suivantes sont remplies :

Le traitement est strictement limité à la production de statistiques anonymes
Les données sont utilisées exclusivement par l'éditeur ou son sous-traitant
Les données ne sont pas recoupées avec d'autres traitements ni partagées avec des tiers
Le traceur est limité à la production de statistiques agrégées
Les adresses IP ne sont pas conservées au-delà de ce qui est strictement nécessaire (généralement anonymisées par troncature avant conservation)
Le suivi est strictement limité à un seul site web
La conservation des données ne dépasse pas une durée raisonnable (la CNIL a précédemment indiqué 13 mois pour les cookies et 25 mois pour les données statistiques sous-jacentes)

La CNIL maintient une liste de solutions d'analytique qu'elle a examinées et considère comme exemptes dans leur configuration par défaut. La liste n'est pas contraignante pour les autres autorités, mais elle est largement référencée dans toute l'Europe comme guide pratique.

Un outil d'analytique qui ne stocke jamais rien sur l'appareil se situe au-dessus de cette exemption. Il n'a pas besoin de se qualifier pour l'exemption car il ne déclenche pas le mécanisme de consentement en premier lieu.

La relation avec le RGPD

Les gens confondent souvent ePrivacy et RGPD, mais ils répondent à des questions différentes :

Article 5(3) ePrivacy : « Ai-je le droit de déposer des données sur l'appareil de l'utilisateur ou d'en lire ? » Pas de stockage ou d'accès, pas engagé.
Article 6 RGPD : « Ai-je une base légale pour traiter des données personnelles ? » S'applique chaque fois que des données personnelles sont traitées, y compris par des outils d'analytique qui ne stockent rien sur l'appareil mais traitent néanmoins les adresses IP.

Les deux doivent être satisfaits. Un outil d'analytique qui ne stocke rien sur l'appareil passe gratuitement l'obstacle ePrivacy, mais il a encore besoin d'une base légale RGPD pour les données personnelles qu'il traite côté serveur. Pour l'analytique, cette base légale est généralement l'intérêt légitime au titre de l'article 6(1)(f), soutenu par une analyse d'impact documentée démontrant que le traitement est proportionné et respecte les droits du visiteur.

Vous ne pouvez pas contourner l'analyse RGPD en étant sans cookies. Vous pouvez contourner la bannière de consentement au titre d'ePrivacy, mais vous devez toujours documenter votre conformité RGPD et respecter les droits des personnes concernées.

Ce que cela signifie pour les fournisseurs d'analytique

Il existe trois voies architecturales réalistes pour un produit d'analytique qui souhaite opérer légalement dans l'UE :

Utiliser des cookies et afficher une bannière. C'est la voie empruntée par Google Analytics, Matomo (mode par défaut) et la plupart des outils historiques. L'utilisateur voit une demande de consentement. S'il accepte, vous obtenez des données. S'il refuse (ou ferme la bannière), vous n'obtenez rien.
Utiliser des cookies mais remplir l'exemption mesure d'audience type CNIL. Matomo dans son mode sans cookies-mais-toujours-fingerprinted essaie cela. C'est faisable mais dépend d'une configuration précise et de l'interprétation de l'autorité.
Ne pas toucher du tout à l'appareil. C'est la voie choisie par Web-Tracking.eu, Plausible, Fathom, Simple Analytics et Pirsch, chacun avec ses propres détails d'implémentation. L'article 5(3) n'est simplement pas déclenché, et la question du consentement s'évapore pour la couche analytique.

La troisième voie est la plus propre juridiquement et la plus simple opérationnellement. Elle exige de repenser la façon dont vous comptez les visiteurs uniques — vous ne pouvez pas compter sur un identifiant stocké sur l'appareil, vous devez donc en calculer un sur le serveur — mais elle contourne tout le débat sur les bannières cookies.

Exemples : ce qui déclenche et ne déclenche pas le consentement

Pour rendre cela concret, voici quelques schémas de déploiement et leur interaction avec l'article 5(3) :

Un script de suivi qui dépose un cookie first-party _ga — déclenche l'article 5(3), nécessite un consentement.
Un script de suivi qui écrit un identifiant de visiteur dans localStorage — déclenche l'article 5(3), nécessite un consentement.
Un script de suivi qui lit uniquement l'en-tête User-Agent et envoie un ping au serveur — ne déclenche pas l'article 5(3). Le User-Agent est dans la requête HTTP, pas sur l'appareil. Pas de stockage, pas d'accès au-delà de la transmission réseau normale.
Un serveur qui hache IP + User-Agent + date à la réception et ne stocke que le hachage — ne déclenche pas l'article 5(3). Rien n'est stocké sur l'appareil.
Un script de suivi qui utilise le fingerprinting Canvas pour générer un identifiant de visiteur — déclenche l'article 5(3), car il lit des informations de l'appareil (caractéristiques de rendu).
Un script de suivi qui utilise navigator.sendBeacon() pour envoyer des données de requête au serveur — ne déclenche pas en soi l'article 5(3). sendBeacon est un mécanisme de transport, pas un stockage sur l'appareil.
Un script de suivi qui dépose un ETag et le relit pour identifier les visiteurs récurrents — déclenche l'article 5(3). Les ETags sont une forme de stockage sur l'appareil.
Un CDN qui enregistre les en-têtes des requêtes entrantes — ne déclenche pas l'article 5(3). Les logs sont sur le serveur.

Si votre architecture s'inscrit clairement dans la catégorie « uniquement côté serveur », vous n'avez pas besoin de bannière cookies pour la partie analytique de votre site. Vos autres outils tiers peuvent encore en nécessiter une.

En résumé

L'article 5(3) est une règle claire et technologiquement neutre : si vous stockez des informations sur l'appareil d'un utilisateur ou en lisez, vous avez besoin d'un consentement (sauf s'il est strictement nécessaire pour un service que l'utilisateur a expressément demandé). Sinon, non.

Cette règle a été rédigée en 2002 et modifiée en 2009. Elle a survécu au RGPD, à la mort des cookies tiers, à la montée du fingerprinting et au débat continu sur la fatigue des bannières cookies, car sa logique sous-jacente est saine. La façon la plus propre de se conformer à l'article 5(3) en 2026 est de ne pas s'y conformer du tout — en construisant un produit qui ne le déclenche jamais en premier lieu.

Web-Tracking.eu est une plateforme d'analytique sans cookies. Pour en savoir plus sur notre approche, consultez l'explication juridique aucune bannière cookies.