La plupart des PME équipées d'une bannière cookies pensent en avoir fini avec la conformité cookies. Ce n'est pas le cas. La bannière, c'est la moitié du tableau — le mécanisme de consentement. L'autre moitié — l'inventaire de ce pour quoi la bannière demande effectivement consentement — est l'endroit où les audits des autorités de contrôle continuent de trouver des lacunes. Une opération coup-de-poing menée en 2024 par l'Autoriteit Persoonsgegevens néerlandaise, la CNIL française et le Garante italien a constaté le même schéma sur des centaines de sites web : bannières présentes, mais aucun registre sous-jacent indiquant quels traceurs se déclenchent, qui les pose, quelles données ils lisent depuis l'appareil et s'ils sont effectivement classifiés correctement.

Un inventaire de cookies et traceurs constitue la couche de documentation située sous votre CMP. C'est ce qu'un auditeur demande lorsque le contrôle de la bannière est validé. Ce guide explique ce que doit contenir un inventaire, pourquoi il vit séparément de votre cartographie RGPD, ce qu'exige réellement l'article 5(3) ePrivacy, et comment maintenir l'inventaire à jour sans faire le travail deux fois.

ePrivacy Art. 5(3) : la règle que la plupart des PME interprètent mal

La directive ePrivacy 2002/58/CE article 5(3) — parfois appelée "loi cookies", plus précisément la règle relative aux équipements terminaux — exige un consentement préalable avant que toute information ne soit stockée sur ou lue depuis l'appareil d'un utilisateur. Deux choses la rendent plus difficile qu'elle n'en a l'air :

Elle s'applique même lorsque les données stockées ne sont pas des données personnelles. Un cookie compteur qui enregistre "il s'agit de la troisième visite de l'utilisateur" est régi par l'art. 5(3), que ce comptage soit ou non rattachable à une personne identifiée. ePrivacy et RGPD sont des cadres juridiques distincts ; respecter le RGPD ne libère pas d'ePrivacy.

Elle s'applique à tout ce qui est stocké sur l'appareil, pas seulement aux cookies. localStorage, sessionStorage, entrées IndexedDB, balises pixels qui lisent des identifiants existants, beacons de SDK, fingerprinting qui dérive un signal stable du navigateur, caches de service worker — tous sont des "informations stockées dans l'équipement terminal d'un abonné ou utilisateur". Si votre inventaire ne suit que les cookies par nom, il manque la majeure partie de ce que les autorités de contrôle examinent désormais.

L'exemption est étroite : un traceur est autorisé sans consentement uniquement s'il est "strictement nécessaire" à la fourniture du service que l'utilisateur a explicitement demandé. La CJUE et les autorités nationales ont lu cette exception strictement. Les cookies de session pour un parcours de paiement authentifié remplissent le critère. Les analytics qui "nous aident à améliorer le service" non. Les pixels marketing jamais.

Ce qu'il faut inventorier

Un inventaire de cookies et traceurs est plus large que la liste de cookies que montre votre scanner CMP. Six catégories de mécanismes de stockage et de collecte de signaux comptent :

  • Cookies — first-party et third-party, session et persistants
  • localStorage et sessionStorage — magasins clé-valeur du navigateur qui persistent plus longtemps que les cookies pour les origines first-party
  • Balises pixels — requêtes d'image 1×1 qui transportent des identifiants dans l'URL ou lisent des cookies existants sur le domaine de destination
  • SDK — bibliothèques JavaScript de tiers (analytics, widgets de chat, moniteurs d'erreur, régies publicitaires) qui posent souvent leurs propres cookies et lisent ou écrivent dans localStorage et déclenchent des beacons
  • Fingerprinting — dérivation d'un identifiant stable à partir des caractéristiques de l'appareil (canvas, WebGL, liste de polices, contexte audio). Même sans rien stocker, le fingerprinting lit depuis l'appareil — l'article 5(3) s'applique.
  • Beacons — appels navigator.sendBeacon() qui se déclenchent au déchargement de la page, courants dans les SDK d'analytics et de remontée d'erreurs

Pour chaque entrée, l'enregistrement auditable doit contenir au minimum : nom, fournisseur (l'entreprise derrière), domaine sur lequel il est posé, type, finalité, durée, base ePrivacy (consentement ou strictement nécessaire) et le mécanisme de consentement qui le contrôle (votre CMP, ou "pas de CMP — strictement nécessaire"). Sans cela, vous ne pouvez pas répondre à la question de l'autorité de contrôle : "montrez-moi la base légale de ce traceur précis sur ce service précis".

Inventaire ≠ CMP — ils font des choses différentes

Un CMP (Consent Management Platform) — Cookiebot, OneTrust, Didomi, Iubenda, Usercentrics, Cookie Information, Axeptio — fait trois choses :

  1. Afficher la bannière avec des bascules par catégorie
  2. Stocker les enregistrements de consentement individuels avec un horodatage et la version de la politique en vigueur
  3. Bloquer les traceurs jusqu'à l'obtention du consentement (la couche d'application technique)

Un CMP est opérationnel. Il s'exécute à chaque chargement de page. Sa mission est de gérer le consentement en temps réel.

Un inventaire fait autre chose : il est la documentation de ce pour quoi le CMP demande consentement. Il répond à des questions que le CMP ne peut pas :

  • Pourquoi ce traceur est-il classifié comme analytics plutôt que marketing ?
  • Qui dans l'organisation a approuvé l'ajout du LinkedIn Insight Tag, et à quelle date ?
  • Quelles données ce SDK lit-il ou écrit-il réellement — au-delà de ce que prétend la documentation du fournisseur ?
  • Si un régulateur demande "démontrez la nécessité de ce cookie analytics au titre de votre évaluation des intérêts légitimes", quelle est la réponse ?
  • Lorsque la liste des cookies change — un nouveau SDK ajouté, un fournisseur changé — la modification apparaît-elle dans votre journal d'audit ?

Un scan CMP vous indique quels cookies se déclenchent aujourd'hui. Un inventaire vous indique lesquels devraient se déclencher, pourquoi chacun est sur la liste, et ce qui a changé au cours des six derniers mois. Les deux sont complémentaires ; aucun ne remplace l'autre.

C'est aussi pourquoi les autorités de contrôle demandent de plus en plus les deux. Un CMP sans inventaire est une bannière sans justification. Un inventaire sans CMP est un registre sans mécanisme d'application. Les PME qui confondent les deux — généralement en traitant le scan automatique du CMP comme l'inventaire — découvrent lors d'un audit que le scanner CMP a manqué les SDK qui ne se déclenchent qu'après un clic, le beacon analytics qui ne se déclenche qu'aux erreurs, et l'entrée localStorage que le widget de chat écrit après que l'utilisateur a tapé un message.

Les quatre catégories de traceurs

Tout CMP sérieux et tout document d'orientation des autorités de contrôle classifient les traceurs dans les quatre mêmes seaux. La classification détermine à la fois le flux de consentement et la posture de risque de l'inventaire.

Strictement nécessaires. Traceurs sans lesquels le service explicitement demandé ne peut fonctionner. Identifiants de session pour une session authentifiée, cookie de jeton CSRF, cookie qui mémorise votre préférence de langue pour la visite en cours, cookie d'affinité du load balancer. Ces traceurs sont exemptés de l'exigence de consentement. Soyez conservateur — si un régulateur peut plausiblement dire "le service fonctionnerait quand même sans cela", ce n'est pas strictement nécessaire.

Fonctionnels. Traceurs qui améliorent l'expérience utilisateur sans être essentiels — mémoriser les préférences UI entre sessions, mémoriser une liste d'éléments récemment consultés, persister la préférence de langue entre visites. Ceux-ci nécessitent un consentement. La frontière entre strictement nécessaire et fonctionnel est étroite et souvent débattue ; documenter votre raisonnement par traceur est ce qui résiste à un audit.

Analytics. Traceurs qui mesurent comment le service est utilisé — pages vues, durée de session, parcours de conversion, taux d'erreur. La CJUE et la plupart des autorités nationales ont jugé que même les analytics first-party nécessitent un consentement, sauf si les données sont véritablement agrégées et utilisées uniquement par le responsable de traitement pour mesurer son propre service. Matomo auto-hébergé avec anonymisation IP et sans suivi cross-site est ce qui se rapproche le plus d'une configuration analytics sans consentement ; Google Analytics 4 non.

Marketing. Pixels de retargeting, identifiants des régies publicitaires, balises de conversion, pixels de suivi des réseaux sociaux. Nécessitent toujours un consentement. Presque toujours third-party. La catégorie qui attire le plus l'attention en matière de répression.

L'inventaire enregistre la catégorie pour chaque traceur, la base ePrivacy (consentement ou nécessaire) et — c'est crucial — le raisonnement. La catégorie détermine le flux de consentement ; le raisonnement détermine si la classification résiste à l'inspection.

Base ePrivacy vs base légale RGPD Art. 6 : ne pas confondre

C'est l'erreur la plus fréquente dans la documentation cookies des PME. L'art. 5(3) ePrivacy et l'art. 6 RGPD sont des cadres juridiques distincts qui posent des questions distinctes :

  • ePrivacy Art. 5(3) demande : ce traceur peut-il être posé sur l'appareil ? La réponse est consentement ou strictement nécessaire.
  • RGPD Art. 6 demande : si des données personnelles résultent de ce traitement, quelle est la base légale pour les traiter ? La réponse est l'une des six bases de l'art. 6(1) — consentement, contrat, obligation légale, intérêts vitaux, mission d'intérêt public, intérêts légitimes.

Un cookie analytics first-party qui exige le consentement de l'utilisateur sous ePrivacy peut, après obtention du consentement, traiter les données qui en résultent au titre du RGPD Art. 6(1)(a) (consentement) — ou de l'Art. 6(1)(f) (intérêts légitimes) une fois que le consentement a été valablement obtenu pour la pose du cookie. Selon certaines interprétations, la pose et le traitement reposent tous deux sur le consentement ; selon d'autres, la pose est conditionnée au consentement et le traitement repose sur les intérêts légitimes. Les orientations des autorités nationales varient. Ce qui est universel : les deux bases sont enregistrées séparément. Un inventaire avec un seul champ "base légale" par traceur confond les deux et produit un registre qu'aucune autorité de contrôle n'acceptera.

Un inventaire sérieux comporte un champ legal_basis_eprivacy sur chaque traceur (consentement / nécessaire) et un champ legal_basis distinct sur les éléments de données personnelles que le traceur génère (la base RGPD Art. 6). Ils vivent dans des tables différentes du modèle de données parce qu'ils répondent à des questions différentes.

Ce qui change avec la proposition Digital Omnibus

En novembre 2025, la Commission européenne a publié la proposition Digital Omnibus COM(2025) 837 final. Elle n'est pas encore adoptée — et il n'est pas certain qu'elle passe sous sa forme actuelle — mais la direction prise importe car elle remodèlerait l'application d'ePrivacy.

La proposition déplacerait la règle cookies/équipement terminal de l'art. 5(3) ePrivacy vers un nouvel art. 88a RGPD pour les abonnés personnes physiques. Six finalités nommées seraient licites sans consentement : effectuer une communication électronique, fournir un service explicitement demandé, mesurer l'audience agrégée pour l'usage propre du responsable, maintenir la sécurité du service, et soutenir les services de la société de l'information demandés par l'utilisateur. Le refus de consentement devrait s'effectuer en un clic, et un responsable refusé devrait attendre au moins six mois avant de redemander.

Un art. 88b d'accompagnement obligerait les responsables à respecter les signaux de consentement lisibles par machine — Global Privacy Control, un éventuel standard ESO — une fois les spécifications techniques publiées, et exigerait des navigateurs non-PME qu'ils les fournissent.

Pour les PME maintenant aujourd'hui un inventaire de traceurs, rien ne change opérationnellement. La distinction actuelle consentement/nécessaire au titre de l'art. 5(3) ePrivacy reste correcte sous la directive en vigueur. Mais deux orientations prospectives en découlent :

  • La taxonomie qui comptera désormais est la finalité, pas le type de cookie. Un inventaire qui enregistre la finalité de chaque traceur (le service explicitement demandé par l'utilisateur, la mesure d'audience pour usage propre, etc.) se transposera proprement dans le régime de l'art. 88a s'il aboutit. Un inventaire qui n'enregistre que "analytics — consentement requis" devra être reclassifié.
  • La prise en charge des signaux de consentement lisibles par machine sera une fonctionnalité du CMP, pas de l'inventaire — mais l'inventaire doit enregistrer quel CMP est utilisé pour que l'auditeur puisse vérifier la conformité à l'art. 88b une fois le standard publié.

La proposition est datée et préfigure explicitement le droit futur. Construisez pour le droit actuel ; concevez pour la direction proposée.

Comment Readmodel® gère les inventaires de cookies et traceurs

Readmodel® conserve l'inventaire des cookies et traceurs au niveau du service — sous le même modèle de données qui stocke vos services, éléments de données et transferts — afin qu'un traceur soit toujours rattaché au service qui le pose, aux données qu'il lit ou génère, et (lorsque des données personnelles en résultent) au registre RGPD qui les traite.

Chaque entrée de traceur capture : nom, fournisseur, domaine, type (cookie / localStorage / pixel / fingerprint / SDK / beacon / autre), catégorie (strictement_necessaire / fonctionnel / analytics / marketing), la legal_basis_eprivacy (consentement / nécessaire) — délibérément nommée pour éviter toute confusion avec la legal_basis RGPD Art. 6 sur les éléments de données — finalité, durée, la référence au mécanisme de consentement (votre CMP) et une URL optionnelle vers la documentation du fournisseur.

Une bibliothèque préchargée de 167 traceurs courants — couvrant les CMP européens (Cookiebot, Didomi, Iubenda, Usercentrics, Axeptio), analytics (GA4, Matomo, Piwik PRO, Hotjar, Microsoft Clarity), régies publicitaires (Meta, LinkedIn, TikTok, Criteo, RTB House, Google Ads), widgets de chat (Intercom, Crisp, LiveChat, Tidio), SDK de paiement (Stripe, Adyen, Mollie, Klarna), identité (Auth0, Keycloak, NextAuth.js), commerce (Shopify, WooCommerce, Magento), erreur/APM (Sentry, Datadog, New Relic) et schémas CMS (WordPress, Drupal, TYPO3) — couvre la plupart des stacks PME en quelques clics. Les entrées personnalisées suivent le même schéma.

Le registre des risques signale automatiquement tout traceur non essentiel (category != 'strictly_necessary' et legal_basis_eprivacy = 'consent') pour lequel aucun mécanisme de consentement n'est documenté au niveau de la ligne et aucun CMP n'est défini au niveau du projet. L'un ou l'autre niveau lève le drapeau — donc les PME qui documentent un seul CMP au niveau du projet (Cookiebot pour tout le site, par exemple) n'ont pas à le répéter sur chaque ligne de traceur.

Un générateur intégré de politique cookies produit un document de politique cookies prêt à imprimer et copier-en-Markdown / copier-en-HTML, regroupant les traceurs par catégorie et incluant descriptions et durées. C'est le document que vous publiez sur votre site web pour remplir l'exigence de transparence qui se tient aux côtés de l'exigence de consentement.

Crucialement, Readmodel® ne remplace pas votre CMP. Il ne génère pas de bannières de consentement, ne stocke pas d'enregistrements individuels de consentement, ne parse pas les chaînes TCF et ne scanne pas votre site automatiquement. C'est la couche d'inventaire sous le CMP que vous utilisez. Pour la vue d'ensemble de la place de Readmodel® dans votre stack vie privée, voir la comparaison des outils de conformité RGPD.

Inventaire de cookies et traceurs : questions fréquentes

Un inventaire de cookies est-il légalement obligatoire ? L'inventaire de cookies en tant que tel n'est nommé dans aucun texte, mais l'obligation qu'il satisfait l'est. L'art. 5(3) ePrivacy exige un consentement avant de poser ou lire des informations sur l'appareil d'un utilisateur, sauf pour les traceurs strictement nécessaires. Au titre du principe de responsabilité du RGPD (art. 5(2)), le responsable doit pouvoir démontrer la conformité — ce qui signifie en pratique un inventaire documenté de chaque traceur, sa catégorie, sa finalité et la base légale. Les autorités de contrôle demandent de plus en plus l'inventaire lors des audits.

Mon scanner CMP ne me donne-t-il pas l'inventaire automatiquement ? Un scanner CMP vous donne un instantané des cookies déclenchés pendant le scan. Il manque les traceurs qui se déclenchent conditionnellement (après un clic, sur erreur, dans des zones authentifiées où le scanner ne s'est pas connecté), il manque sur la plupart des plans le stockage non-cookie (localStorage, fingerprinting, beacons), et il n'enregistre pas le raisonnement derrière vos classifications par catégorie. Utilisez le scanner comme entrée de l'inventaire ; ne traitez pas la sortie du scanner comme l'inventaire.

Quelle est la différence entre strictement nécessaire et fonctionnel ? Les traceurs strictement nécessaires sont ceux sans lesquels le service explicitement demandé par l'utilisateur ne peut fonctionner — identifiants de session pour un parcours de paiement, jetons CSRF, affinité du load balancer. Les traceurs fonctionnels améliorent l'expérience utilisateur sans être essentiels — mémorisation des préférences UI entre sessions, listes d'éléments récemment consultés. Strictement nécessaire est exempté de consentement ; fonctionnel exige un consentement. Les autorités nationales lisent l'exemption strictement ; en cas de doute, classifiez comme fonctionnel et exigez le consentement.

Dois-je inventorier les traceurs tiers ? Oui. Tout ce qui pose ou lit des informations sur l'appareil de l'utilisateur compte, peu importe qui l'exploite. Les vidéos YouTube intégrées qui posent des cookies DoubleClick, Stripe Elements qui pose des cookies de prévention de fraude, l'intégration Google Maps qui pose NID — tout cela doit figurer dans l'inventaire, avec le fournisseur tiers documenté.

Ma bibliothèque de fingerprinting doit-elle figurer dans l'inventaire ? Oui. Le fingerprinting lit les caractéristiques de l'appareil de l'utilisateur pour dériver un identifiant stable — la CJUE et l'EDPB ont confirmé que cela relève de l'art. 5(3) même lorsque rien n'est stocké. Documentez la bibliothèque, sa finalité et le mécanisme de consentement qui la régit. La plupart du fingerprinting en production sert à la prévention de la fraude (Sift, Forter, DataDome) et peut se qualifier comme strictement nécessaire pour la finalité de sécurité ; documentez le raisonnement.

Comment cela se rapporte-t-il au règlement européen sur l'IA ? Si vous utilisez l'IA sur les données collectées par vos traceurs — systèmes de recommandation alimentés par le clickstream, modèles de ciblage publicitaire comportemental, ML de détection de fraude —, la couche de traitement IA est régie par le règlement IA, tandis que la pose sous-jacente du traceur est régie par ePrivacy. Les deux doivent être documentés séparément. Voir le guide gouvernance IA pour la couche IA.

Que se passe-t-il si la proposition Digital Omnibus est adoptée ? La règle cookies/équipement terminal passe de l'art. 5(3) ePrivacy à un nouvel art. 88a RGPD pour les abonnés personnes physiques, avec six finalités nommées licites sans consentement. Un inventaire construit autour de la finalité (plutôt qu'autour des noms de cookies) se transpose proprement. La proposition n'est pas encore adoptée ; construisez pour le droit actuel.

À quelle fréquence dois-je mettre à jour l'inventaire ? Au moins trimestriellement, plus à chaque changement : un nouveau SDK ajouté au site, un changement de fournisseur (Cookiebot → OneTrust), une nouvelle fonctionnalité qui introduit des traceurs conditionnels, une mise à jour des règles CMP. L'inventaire est un document vivant ; le journal d'audit sur chaque traceur prouve que vous le maintenez.

Commencez à documenter vos traceurs

Les inventaires de cookies et traceurs sont ingrats. Ce sont aussi le terrain vers lequel se déplacent les audits des autorités de contrôle, à mesure que l'application centrée sur la bannière atteint son plafond. Le travail est véritablement gérable pour une PME une fois la structure en place : un traceur par ligne, une catégorie, une base, une finalité, une référence CMP et une durée.

Créez un compte Readmodel® gratuit, importez la bibliothèque préchargée, et vous obtenez un inventaire prêt pour l'audit en moins d'une heure. La page traceurs, le générateur de politique cookies, le drapeau du registre des risques pour le consentement manquant et l'inclusion dans le registre RGPD sont disponibles dans tous les plans, y compris le plan Explore gratuit.