Un scanner de cookies est un outil qui visite les pages de votre site comme le ferait un navigateur, observe tout ce qui est écrit ou lu sur l'appareil de l'utilisateur, puis dresse l'inventaire des traceurs trouvés. Chaque ligne de cet inventaire indique un nom, un domaine, une durée de vie et, dans le meilleur des cas, une finalité.

C'est la première brique d'une CMP (plateforme de gestion du consentement) sérieuse. Sans inventaire fiable, impossible d'informer correctement l'utilisateur, de bloquer ce qui doit l'être avant son choix ou de rédiger une politique de cookies qui décrive la réalité.

Un scanner ne dit pas si votre site est conforme. Il répond à une question plus simple et indispensable : qu'est-ce qui se passe réellement sur mon site ? La conformité vient ensuite, quand vous comparez cette réponse à ce que votre bandeau cookies annonce et à ce que l'utilisateur a choisi.

Un cookie est un petit fichier que le navigateur stocke à la demande d'un site. Un traceur est le terme plus large employé par la CNIL : dans ses lignes directrices, il désigne l'ensemble des dispositifs susceptibles d'être visés par l'article 82 de la loi Informatique et Libertés, et pas seulement les cookies HTTP.

Un tag est un morceau de code, souvent installé via Google Tag Manager ou un outil équivalent, qui se charge dans la page et qui peut déposer un ou plusieurs cookies. C'est l'unité que la plupart des scanners détectent en premier, puis dont ils déduisent les cookies associés. Retenez cette chaîne : un tag est le déclencheur, le cookie est la trace laissée sur l'appareil.

La CNIL précise que ses lignes directrices concernent toutes les opérations de lecture ou d'écriture dans le terminal de l'utilisateur. Elle cite expressément le « local storage » du standard HTML 5, le calcul d'empreinte du terminal (« fingerprinting ») et les identifiants générés par les systèmes d'exploitation, en plus des cookies HTTP.

Elle ajoute que ces règles s'appliquent que les données concernées soient personnelles ou non. Vous trouverez le texte dans la délibération n° 2020-091 du 17 septembre 2020, aux points 9 à 14. Un bon scanner doit donc regarder au-delà des seuls cookies, ou vous dire clairement qu'il ne le fait pas.

Tous les scanners suivent la même logique en trois temps, même si les moteurs diffèrent : charger, observer, reconnaître. Comprendre ces trois temps permet de savoir à quoi vous fier dans un rapport, et à quoi ne pas vous fier.

Le scanner ouvre chaque URL avec un navigateur, généralement sans interface, qui exécute le code de la page. C'est indispensable : un simple téléchargement du HTML ne verrait pas les traceurs créés par du JavaScript, qui sont très répandus.

Le scanner attend que la page se stabilise, puis parfois fait défiler le contenu pour déclencher les éléments chargés à la demande. Plus la simulation est proche d'une vraie visite, plus l'inventaire est complet. À l'inverse, un scanner qui ne charge que la page d'accueil ne voit que la page d'accueil, ce qui explique pourquoi il faut scanner régulièrement et sur plusieurs pages.

Pendant le chargement, l'outil enregistre les écritures dans le stockage du navigateur. Il note les cookies reçus dans les en-têtes de réponse des serveurs, ceux créés par les scripts, le contenu du stockage local et les requêtes envoyées vers des domaines tiers.

Pour chaque cookie, il conserve les attributs qui comptent : nom, domaine, chemin, date d'expiration, mention « Secure » ou « HttpOnly », et valeur de l'attribut SameSite. Cette liste brute est le matériau du scan. Elle est exacte à l'instant de la visite, et uniquement à cet instant.

Une liste de noms techniques comme _ga, _fbp ou PHPSESSID ne dit rien à un utilisateur. Le scanner rapproche donc chaque trace d'une base de connaissances, qui associe un traceur connu à un fournisseur, à une finalité et à une catégorie.

Quand la base ne connaît pas le traceur, l'outil ne peut pas deviner. Il le signale comme non reconnu, et c'est à vous de trancher. Cette étape est celle où la qualité d'un scanner se joue, car la classification alimente directement ce que l'utilisateur lit dans votre bannière.

Démarrer gratuitement

Sur un site public classique, un scanner est très efficace pour ce qui se déclenche au chargement des pages qu'il visite. Il excelle dans les cas suivants :

• les cookies de mesure d'audience, publicitaires ou de réseaux sociaux déposés par des tags présents dans le code de la page ;
• les cookies de session et de préférences déposés par votre propre site ;
• les requêtes vers des domaines tiers, révélatrices d'un pixel ou d'un script oublié ;
• les durées de vie, qui permettent de repérer un cookie de plusieurs années.

Ce dernier point mérite attention. Pour les traceurs de mesure d'audience exemptés de consentement, la CNIL recommande une durée de vie limitée, comme les treize mois qu'elle cite en exemple, et une conservation des informations collectées de vingt-cinq mois maximum. Cette recommandation figure au point 50 de la délibération n° 2020-092. Un scanner qui affiche l'expiration de chaque cookie vous donne la matière première pour ce contrôle.

Un scanner constate, il ne juge pas. Il peut vous dire qu'un cookie publicitaire existe sur votre page d'accueil. Il ne peut pas, seul, vous dire si ce cookie a été déposé avant ou après le choix de l'utilisateur, sauf si vous lui faites simuler les deux situations.

C'est pourquoi la lecture du rapport reste une étape humaine, et pourquoi la suite de cet article vous montre comment vérifier vous-même. Nous détaillons cette lecture, catégorie par catégorie, dans notre guide pour lire les résultats du scan et faire l'audit de vos cookies.

Aucun scanner ne voit tout. Ce n'est pas un défaut d'un produit en particulier : c'est une limite de la méthode, puisque le scanner n'observe que ce qui se passe pendant ses propres visites. Voici les angles morts qui reviennent le plus souvent. Pour connaître la couverture exacte de votre outil, reportez-vous à la documentation de votre produit.

Un scanner part d'une liste d'URL, ou d'une exploration à partir de la page d'accueil. Une page profonde, une page de campagne créée la semaine dernière ou une page orpheline peut ne jamais être visitée. Si un script est installé uniquement sur cette page, il échappe à l'inventaire.

Tout dépend donc de la liste de pages fournie. Un site de plusieurs milliers de pages ne se scanne pas comme un site vitrine de dix pages, et la liste doit inclure les gabarits qui portent des traceurs différents : page produit, tunnel de commande, blog, formulaire, page de campagne.

Un scanner anonyme n'a pas de compte. Tout ce qui se trouve derrière une connexion, comme un espace client ou un tableau de bord, reste hors de sa vue, sauf si l'outil sait s'authentifier. Or c'est souvent là que se trouvent les outils de support, d'analyse produit ou de chat, qui méritent une place dans votre inventaire puis dans votre politique de cookies.

La CNIL donne un exemple qui illustre ce piège. Dans un service à authentification, un cookie peut servir à identifier l'utilisateur sans consentement, car il est strictement nécessaire au service. Le même cookie, utilisé aussi à des fins publicitaires, exige un consentement préalable pour cette finalité, comme le rappelle le point 48 des lignes directrices.

Certains traceurs n'apparaissent qu'après une action : un clic, l'ouverture d'une vidéo intégrée, l'envoi d'un formulaire, un achat. D'autres dépendent du pays de l'utilisateur, de l'appareil, d'un test A/B ou de l'heure de la journée. Un scanner qui ne reproduit pas ces situations ne les verra pas.

Un cas fréquent : la vidéo intégrée. Tant que personne ne clique, aucun cookie du fournisseur n'est déposé. Au premier clic, la lecture peut ouvrir une session avec un tiers. Le scan de la page à froid conclut à tort qu'il n'y a rien.

Un scanner centré sur les cookies peut passer à côté du stockage local, des identifiants d'appareil ou du calcul d'empreinte. La CNIL les range pourtant tous dans le champ de l'article 82. Vérifiez ce que votre outil déclare inspecter, et n'attendez pas de lui ce qu'il ne promet pas.

Pour les mêmes raisons, un scanner n'est pas un contrôle technique de la conformité. Il ne lit pas votre bannière, ne juge pas l'égalité entre les boutons accepter et refuser, et ne dit rien de la validité du consentement recueilli. Il sert à voir, pas à décider.

Un site change. Une équipe marketing ajoute un tag un mardi soir, un prestataire met à jour un script qui embarque désormais un nouveau sous-traitant, un thème est modifié. Un rapport de scan est une photographie datée. C'est la raison pour laquelle nous consacrons un article entier à la nécessité de scanner et de re-scanner.

Vous pouvez vérifier l'essentiel en vingt minutes avec votre navigateur. Cet exercice est utile même si vous utilisez déjà un scanner : il vous apprend ce que l'outil est censé vous montrer, et il permet de repérer un écart entre le rapport et la réalité.

La CNIL a publié CookieViz, un outil de son laboratoire d'innovation numérique qui visualise les échanges entre votre navigateur et les domaines tiers au fil des pages visitées. Le projet n'est plus maintenu (dernière version publiée en juin 2022) : ne comptez pas sur lui pour un audit courant. Pour la démarche pas à pas, les outils de développement de votre navigateur suffisent.

Ouvrez une fenêtre de navigation privée, sans extension. Une extension de blocage ou un cookie déjà présent fausserait le résultat. Ouvrez ensuite les outils de développement de votre navigateur.

Dans Chrome, le panneau Application contient, sous Storage, la rubrique Cookies. Comme le décrit la documentation de Chrome pour les développeurs, vous y voyez pour chaque origine le nom, le domaine, l'expiration, les attributs de sécurité et un avertissement pour les cookies tiers. Les autres navigateurs proposent un panneau équivalent.

La méthode tient en trois observations successives, sur la même page, avec le même navigateur propre.

1. Avant tout choix. Chargez la page, ne touchez pas à la bannière, et notez les cookies présents. Tout ce qui n'est pas strictement nécessaire à ce stade mérite une explication.
2. Après un refus. Videz les cookies, rechargez, cliquez sur « Tout refuser », puis notez ce qui reste. Aucun traceur soumis au consentement ne doit apparaître. Un cookie strictement nécessaire qui mémorise votre refus peut s'ajouter : la liste peut donc être un peu plus longue, sans que ce soit un défaut.
3. Après une acceptation. Videz de nouveau, rechargez, cliquez sur « Tout accepter », puis notez ce qui apparaît. La différence avec l'état précédent est ce que la bannière contrôle réellement.

Cette comparaison est celle qui compte, parce qu'elle confronte le comportement réel du site à ce que la bannière annonce. Chaque écart entre ce que vous voyez et ce que votre bannière promet est un point à corriger.

Répétez l'opération sur trois ou quatre pages représentatives : l'accueil, une page de contenu, une page avec formulaire, une page avec une vidéo ou un widget intégré. Chaque type de page peut charger des tags différents. Ajoutez le parcours de commande si vous vendez en ligne.

Ce test est volontairement modeste. Il ne remplace pas un scan complet, mais il vous donne un jeu de comparaison indépendant. Si votre scanner annonce dix-huit cookies et que vous en voyez vingt-quatre après acceptation, la question à poser est claire : d'où viennent les six autres ?

Démarrer gratuitement avec AdOpt

Un scan sert trois usages qui s'enchaînent. C'est cet enchaînement qui donne sa valeur à l'exercice, bien plus que le rapport lui-même.

Avant que l'utilisateur choisisse, il doit être informé. Selon la CNIL, l'information doit être complète, visible et mise en évidence, et l'utilisateur doit pouvoir identifier les responsables des traitements avant d'exprimer son choix. La liste exhaustive et à jour de ces entités doit lui être accessible simplement (points 23 à 25 des lignes directrices).

Un inventaire tenu à la main est presque toujours incomplet ou périmé. Le scan est l'outil qui permet de maintenir cette liste alignée sur ce que le site charge vraiment.

Pour qu'un refus ait un sens, les traceurs soumis à consentement ne doivent pas se déclencher avant l'accord. Le scan vous dit lesquels sont concernés. Le blocage lui-même est une autre fonction, qui doit être configurée séparément. Les deux fonctionnent ensemble, mais le premier ne remplace pas le second.

L'éditeur du site reste concerné même lorsque le traceur vient d'un tiers. La CNIL rappelle, en s'appuyant sur une décision du Conseil d'État du 6 juin 2018, que l'éditeur doit s'assurer auprès de ses partenaires qu'ils n'émettent pas, par l'intermédiaire de son site, des traceurs non conformes (point 35).

Enfin, il faut pouvoir démontrer le choix. Le point 29 des lignes directrices indique que les organismes exploitant des traceurs doivent être en mesure de fournir, à tout moment, la preuve du recueil valable du consentement. Le scan n'est pas cette preuve : il documente ce qui existe, le registre documente ce que la personne a choisi. Les deux se complètent.

Pour situer ces obligations dans le cadre plus large de la loi française, consultez notre guide du RGPD en France et l'article sur les missions et les contrôles de la CNIL.

Le Scanner de tags d'AdOpt propose automatiquement une classification pour les tags trouvés dans les URL rattachées à votre bannière. Rappelons qu'un tag déclenche un ou plusieurs cookies : le scanner travaille à l'échelle du tag, puis vous voyez les cookies associés. La disponibilité de la fonction et la fréquence du scan varient selon le plan.

Les tags sont rangés dans cinq catégories : nécessaires, marketing, statistiques, performance et fonctionnelles. Quand le scanner ne reconnaît pas un tag, il le place dans une sixième catégorie, « Inconnus », et ce tag n'apparaît pas dans la bannière tant qu'il n'est pas classé. Vous choisissez alors vous-même l'une des cinq catégories, puis vous enregistrez et publiez la modification.

La bannière affichée aux utilisateurs reprend la liste des tags et cookies de tiers avec la classification que vous avez validée, et l'utilisateur peut personnaliser son choix par catégorie. C'est pourquoi la qualité de la classification n'est pas un détail : elle est visible pour vos utilisateurs, et elle engage votre information.

Deux précisions évitent les malentendus. D'abord, le réglage « Tags inactifs par défaut » détermine seulement si les tags non nécessaires sont cochés ou non lors de la première visite. Il ne dispense pas de configurer le blocage des tags, qu'il soit manuel ou automatique, qui est une fonction distincte.

Ensuite, AdOpt enregistre le choix de chaque utilisateur avec un identifiant unique, le CookieID, stocké dans le navigateur. C'est la trace du consentement. Le scan et le registre répondent à deux questions différentes : qu'y a-t-il sur le site, et qu'a choisi la personne.

AdOpt propose aussi un Scanner planifié, dont la fréquence se règle (manuelle, hebdomadaire, mensuelle, tous les 45 ou 60 jours), et un Scanner authentifié pour les zones connectées. Leur disponibilité dépend du plan : vérifiez la documentation avant de vous reposer sur un rapport.

La démarche de vérification décrite plus haut fonctionne aussi avec AdOpt. Ouvrez votre site en navigation privée, comparez les cookies avant et après le choix, puis comparez le résultat avec la liste affichée dans la bannière. Si un cookie apparaît dans le navigateur sans figurer dans la liste, vous avez trouvé un écart à traiter.

Démarrer gratuitement avec AdOpt

Quelques erreurs reviennent presque systématiquement quand une équipe découvre l'exercice. Les connaître évite de perdre du temps, et surtout de fausses assurances.

• Scanner une seule fois. Un rapport daté d'il y a un an décrit le site d'il y a un an.
• Scanner uniquement l'accueil. Les pages de conversion et les pages de campagne portent souvent les traceurs les plus intrusifs.
• Confondre « détecté » et « bloqué ». Voir un cookie dans un rapport ne l'empêche pas de se déposer avant le choix.
• Laisser des traceurs inconnus sans catégorie. Une ligne non classée est une ligne que l'utilisateur ne comprend pas.
• Ne jamais comparer avec la bannière et la politique. Le scan prend tout son sens quand il est rapproché des deux.

Demander une démo AdOpt

Non. Un scanner établit l'inventaire des traceurs présents au moment de sa visite, ce qui est une étape nécessaire mais pas suffisante. Il ne vérifie ni la validité du consentement, ni la parité entre les boutons, ni l'exactitude de vos textes. La conformité résulte de la comparaison entre l'inventaire, l'information affichée, le blocage avant choix et la preuve du consentement recueilli.

Il n'existe pas de fréquence imposée par un texte. Le bon rythme dépend de la vitesse à laquelle votre site change : ajout de tags, mise à jour de plugins, nouvelles campagnes, changement de prestataire. Une règle simple consiste à re-scanner après chaque modification technique importante et à programmer un contrôle régulier, pour repérer les traceurs arrivés sans que personne ne les ait décidés.

Seulement s'il reproduit ce clic. Un scan à froid charge les pages sans interagir, et ne voit donc pas les traceurs qui se déclenchent après l'ouverture d'une vidéo, l'envoi d'un formulaire ou un achat. Pour ces cas, complétez le scan par un test manuel dans un navigateur propre, en comparant les cookies avant et après l'action.

Identifiez d'abord son origine : le nom, le domaine et le tag qui le dépose donnent en général la réponse. Rattachez-le ensuite à la catégorie qui correspond à sa finalité réelle, puis publiez la modification. Nous détaillons la méthode dans notre guide pour lire les résultats du scan.

Non, mais il l'alimente. La politique décrit vos traceurs en langage clair, avec leur finalité et leur durée ; le scan vous donne la liste factuelle de ce qu'elle doit décrire. Quand le second évolue sans que la première suive, votre texte cesse de refléter la réalité, ce qui est l'écart que les contrôles cherchent en premier.

• Pourquoi scanner les cookies de son site, et le refaire régulièrement
• Audit de cookies : lire les résultats du scan