> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/fonctionnalites/realtime-cookie-scanner/legal-and-technical-position-paper.md). # Note de position juridique et technique #### À l’intention des DPO, des équipes juridiques et des responsables de la conformité *** ### 1. Objet du présent document Ce document présente le fonctionnement technique du module Commanders Act Realtime Cookie Scanner et fournit aux équipes juridiques et de conformité les informations nécessaires pour évaluer sa qualification réglementaire. Il décrit le fonctionnement technique du module et les métadonnées techniques qu’il observe, puis propose une analyse juridique de son fonctionnement au regard de l’article 5(3) de la directive ePrivacy et une explication des raisons pour lesquelles le module n’implique pas de traitement de données personnelles au sens du GDPR. Le document présente également les garanties techniques mises en œuvre pour garantir que le module fonctionne exclusivement comme un outil de surveillance de la conformité. *** ### 2. Fonctionnement technique du module #### 2.1 Nature et finalité du module Realtime Cookie Scanner est un module JavaScript exécuté dans le navigateur du visiteur. Son unique finalité est de permettre aux exploitants de sites web de vérifier que leurs sites respectent les règles applicables au déploiement de cookie et de technologies similaires, en particulier les exigences découlant du cadre ePrivacy. Concrètement, le module permet aux exploitants de : * maintenir un inventaire à jour des cookie présents sur leur site web ; * identifier les sources techniques responsables de la création des cookie ; * détecter les cookie qui apparaissent avant le consentement de l’utilisateur ou après un refus ; * suivre l’évolution de l’utilisation des cookie dans le temps ; * appuyer les audits internes de confidentialité et de conformité. #### 2.2 Opérations techniques effectuées Le module effectue les opérations suivantes dans le navigateur : * lecture des **noms des cookie** présents dans le navigateur via `document.cookie`; * lecture des **clés présentes dans `localStorage`**; * lecture des **clés présentes dans `sessionStorage`**; * tentative, dans la mesure du possible, d’identifier les **sources techniques** potentiellement associées aux cookie, lorsque cela est techniquement possible ; * enregistrement des **URL des pages analysées**; * détection de l’état de **consentement** fourni par la Consent Management Platform (CMP) (par exemple Didomi, OneTrust, Commanders Act CMP). Le scanner **ne modifie pas** les cookie présents dans le navigateur. Son rôle est strictement limité à l’observation. #### 2.3 Données observées et transmises Le module collecte uniquement les métadonnées techniques nécessaires à l’établissement d’un inventaire de cookie. **Données observées et transmises aux serveurs Commanders Act :** * noms de cookie * clés présentes dans `localStorage` et `sessionStorage` * URL des pages analysées * catégories de consentement activées par le CMP **Données ni collectées ni exploitées :** * valeurs de cookie ou tout identifiant associé à un utilisateur individuel * browser fingerprinting * données comportementales ou analytiques **Remarque sur l’adresse IP et le user-agent :** lorsque le module transmet des métadonnées aux serveurs Commanders Act, une requête HTTP est initiée par le navigateur. Dans le cadre du fonctionnement normal du protocole HTTP, ces requêtes contiennent intrinsèquement des informations techniques, notamment l’adresse IP de l’émetteur et la chaîne user-agent. Ces éléments ne sont pas collectés ni utilisés par le module aux fins du service et ne sont pas traités dans le cadre de la fonctionnalité de scan de cookie. #### 2.4 Hébergement et transfert des données Toutes les métadonnées techniques transmises par le module sont envoyées exclusivement à des serveurs Commanders Act hébergés au sein de l’Union européenne. Aucune donnée n’est transférée vers des serveurs situés en dehors de l’UE. #### 2.5 Exécution avant consentement Le module s’exécute au chargement de la page, indépendamment de l’état de consentement de l’utilisateur. Il ne s’agit pas d’un choix de conception arbitraire. Afin de détecter les cookie susceptibles d’apparaître avant le consentement de l’utilisateur ou après un refus, le module doit être en mesure d’observer l’environnement du navigateur au moment où la page est chargée. Si le module n’était déclenché qu’après la collecte du consentement, certaines situations de déploiement non conforme de cookie ne pourraient pas être détectées. Le module surveille ensuite les changements d’état de consentement via l’API du CMP afin de comparer la présence de cookie avant et après la décision de l’utilisateur. *** ### 3. Analyse juridique #### 3.1 Champ d’application de l’article 5(3) de la directive ePrivacy L’article 5(3) de la directive ePrivacy exige le consentement préalable pour toute opération impliquant **l’accès à des informations stockées dans l’équipement terminal de l’utilisateur**ou leur stockage, que ces informations constituent ou non des données personnelles. Le Realtime Cookie Scanner, dans la mesure où il accède aux cookie et aux clés de stockage présents dans le navigateur, entre dans le champ d’application de cette disposition. Cela est reconnu. La question juridique pertinente consiste donc à déterminer si cet accès peut être considéré comme strictement nécessaire à la fourniture du service. Le module n’est pas conçu pour suivre ou identifier les utilisateurs, et son fonctionnement peut être examiné à la lumière de l’exception de stricte nécessité pour les raisons exposées ci-dessous. #### 3.2 Qualification au titre de l’exception de stricte nécessité La directive ePrivacy prévoit une exception pour les opérations qui sont **strictement nécessaires** soit dans le seul but d’effectuer une transmission sur un réseau de communications électroniques, soit lorsque l’accès est strictement nécessaire afin de fournir un service expressément demandé par l’utilisateur. La question pertinente est donc de savoir si le fonctionnement de Realtime Cookie Scanner peut relever du second volet de cette exception, à savoir lorsque l’accès à l’équipement terminal est strictement nécessaire à la fourniture d’un service. Cette appréciation peut être examinée sur les bases suivantes : **a) Finalité exclusive de conformité et d’audit technique** Le module n’effectue aucun suivi des utilisateurs, n’exploite pas les données à des fins marketing ou analytiques et ne produit aucun profilage. Son unique finalité est de permettre à l’exploitant du site web de vérifier que son propre site web respecte les obligations applicables de la directive ePrivacy et du GDPR. À cet égard, le module fonctionne comme un outil de surveillance technique destiné à appuyer la vérification interne de conformité par l’exploitant du site web. **b) Nécessité technique de l’observation avant consentement** L’exécution avant consentement est étroitement liée à la fonctionnalité principale du module. Un outil conçu pour détecter les cookie déployés avant consentement doit être en mesure de fonctionner en observant l’environnement du navigateur à cet instant précis. Limiter le module à une observation postérieure au consentement l’empêcherait de détecter précisément les situations de déploiement non conforme de cookie que le module est destiné à identifier. Cette exigence opérationnelle découle donc directement de la finalité du service plutôt que d’un choix de mise en œuvre discrétionnaire. En pratique, les approches fondées uniquement sur des scans automatisés de type crawler présentent des limites structurelles lorsqu’il s’agit de détecter certaines catégories de déploiements de cookie. Les scans fondés sur des crawlers s’appuient généralement sur des scénarios de navigation prédéfinis et ne peuvent pas reproduire toute la diversité des parcours réels de navigation des utilisateurs. Certains cookie n’apparaissent que dans des conditions spécifiques, des cookie rares, des cookie déclenchés par des parcours utilisateurs particuliers ou des cookie déployés de manière conditionnelle selon des paramètres techniques, qui ne peuvent pas toujours être capturés au moyen de scénarios de scan automatisés. Parce que la finalité du module est précisément d’identifier les situations de déploiement non conforme de cookie, l’observation des conditions réelles de navigation devient nécessaire pour atteindre cet objectif. Les approches fondées sur des crawlers ne peuvent pas reproduire de manière fiable l’ensemble des conditions réelles de navigation, ce qui fait de l’observation en temps réel la méthode la plus fiable pour garantir une détection exhaustive des déploiements non conformes de cookie. **c) Absence de traitement de données personnelles** Le module ne collecte pas les valeurs de cookie, les identifiants utilisateur ni les empreintes navigateur. Les métadonnées observées (noms de cookie, clés de stockage, URL) sont traitées uniquement dans le but d’établir un inventaire technique des cookie déployés sur le site web et ne sont pas utilisées pour identifier des utilisateurs individuels. En conséquence, le module n’est pas conçu pour traiter des données personnelles dans le cadre de sa finalité fonctionnelle. **d) Aucun transfert à des tiers publicitaires ou analytiques** Les données observées par le module sont transmises exclusivement aux serveurs Commanders Act, dans le but de fournir le service de surveillance de la conformité. Elles ne sont pas partagées avec des tiers publicitaires ou analytiques et ne sont pas utilisées à des fins marketing, de suivi ou de profilage. #### 3.3 Absence de traitement de données personnelles au titre du GDPR Dans la mesure où les métadonnées observées par le module ne permettent pas d’identifier directement ou indirectement un utilisateur, le module n’est pas conçu pour traiter des données personnelles dans le cadre de sa finalité fonctionnelle. En conséquence, l’analyse juridique du module concerne principalement l’application de l’article 5(3) de la directive ePrivacy. À titre subsidiaire, si une autorité de contrôle estime que certaines métadonnées techniques pourraient être qualifiées de données personnelles dans un contexte spécifique, l’intérêt légitime du responsable du traitement à assurer sa propre conformité réglementaire (article 6(1)(f) du GDPR) constituerait une base légale, sous réserve de la mise en balance des intérêts. #### 3.4 Position des autorités nationales et recommandations de documentation Certaines autorités de contrôle, notamment l’AEPD (Espagne) et les autorités allemandes, ont historiquement adopté une interprétation particulièrement stricte du concept de « strictement nécessaire » pour les technologies exécutées dans le navigateur avant consentement. L’architecture technique de Realtime Cookie Scanner a été conçue en tenant compte de ces interprétations réglementaires plus strictes. La combinaison d’une finalité exclusivement liée à la conformité, d’une collecte minimale de données, de l’absence de traitement de données personnelles dans la conception fonctionnelle du module et d’un hébergement des données basé dans l’UE vise à fournir une base solide d’évaluation pour les organisations opérant dans différentes juridictions européennes, y compris celles appliquant des normes réglementaires particulièrement exigeantes. #### 3.5 Appréciation globale Le déploiement d’un outil de surveillance de la conformité en temps réel peut contribuer à la capacité d’une organisation à identifier et à gérer les risques réglementaires potentiels liés au déploiement de cookie. Les approches fondées uniquement sur des scans automatisés de type crawler, ou l’absence de mécanismes de surveillance continue, peuvent dans certaines circonstances ne fournir qu’une vision partielle des cookie effectivement déployés sur un site web. Certaines catégories de cookie, telles que les cookie conditionnels, les cookie déclenchés par des parcours de navigation spécifiques ou les cookie déployés uniquement dans certains contextes techniques, peuvent donc rester plus difficiles à détecter sans observation dans des conditions réelles de navigation. À cet égard, Realtime Cookie Scanner peut contribuer à réduire l’exposition réglementaire d’une organisation en aidant à identifier les situations potentielles de déploiement non conforme de cookie. Sur cette base, le module peut raisonnablement être qualifié d’outil de surveillance de la conformité, plutôt que de technologie de suivi conçue pour analyser ou profiler le comportement des utilisateurs. Les garanties techniques décrites dans ce document contribuent à étayer cette qualification. *** ### 4. Résumé des garanties techniques | Critère | Realtime Cookie Scanner | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | Collecte de données personnelles | Non (le module n’est pas conçu pour collecter des données personnelles dans le cadre de sa finalité fonctionnelle) | | Collecte des valeurs de cookie | Non | | Identifiants utilisateur | Non | | browser fingerprinting | Non | | Finalité de suivi ou de profilage | Non | | Transfert à des tiers publicitaires | Aucun transfert à des tiers publicitaires ou analytiques | | Adresse IP / user-agent stockés ou exploités | Non (une transmission technique via HTTP peut avoir lieu, mais ces éléments ne sont ni stockés ni utilisés par le module) | | Nécessité technique d’une exécution avant consentement | Oui — liée à la fonction du module consistant à détecter les cookie apparaissant avant le consentement | | Finalité exclusive de conformité et d’audit | Oui | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.commandersact.com/fr/fonctionnalites/realtime-cookie-scanner/legal-and-technical-position-paper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.