La plupart des sites ont un bandeau de cookies parce que leur analytics en exige un. Retirez l'exigence et le bandeau peut partir avec elle, en même temps que le problème de taux de consentement qui est dessous, et c'est cette part-là qui vous coûte vraiment.

Ceci est un résumé du fonctionnement des règles en pratique, pas un conseil juridique. Si votre situation est inhabituelle, demandez à quelqu'un de qualifié.

La règle porte sur le stockage, pas sur les cookies

Le texte pertinent est l'article 5, paragraphe 3, de la directive ePrivacy, que chaque État membre de l'UE a transposé dans son propre droit : en France, l'article 82 de la loi Informatique et Libertés, appliqué par la CNIL. Il ne parle pas de cookies. Il couvre le fait de stocker des informations sur l'équipement terminal d'un utilisateur, ou d'accéder à des informations qui y sont stockées, son téléphone, son ordinateur portable.

Cette formulation est délibérément neutre du point de vue technologique, et elle tranche une question dont les gens débattent encore. localStorage est du stockage sur l'appareil de l'utilisateur. sessionStorage aussi, ainsi qu'un enregistrement IndexedDB, une entrée de cache utilisée comme identifiant, et une empreinte de canvas ; cette dernière parce que lire les caractéristiques d'un appareil, c'est « accéder à des informations stockées sur » cet appareil.

Échanger document.cookie contre localStorage.setItem ne change rien juridiquement. Un très grand nombre d'outils d'analytics « sans cookie » font exactement cela, et se décrivent comme dépourvus de cookies sur cette base. Le critère est de savoir si quelque chose est écrit sur la machine du visiteur ou lu depuis elle, pas le nom de l'API.

L'exemption, et pourquoi l'analytics y entre rarement

L'article 5, paragraphe 3, comporte deux exemptions. Le stockage est permis sans consentement lorsqu'il a pour seule finalité d'effectuer une transmission, ou lorsqu'il est strictement nécessaire à un service que l'utilisateur a expressément demandé.

« Strictement nécessaire » veut dire nécessaire à la chose que le visiteur a demandée. Un panier d'achat entre dans la catégorie : sans lui, le passage en caisse que le visiteur a demandé ne fonctionne pas. Une session de connexion aussi. L'analytics, non, parce que le site fonctionne parfaitement pour le visiteur que vous le comptiez ou non. La mesure est quelque chose que vous avez demandé.

Certaines autorités ont ménagé une place étroite à la mesure d'audience en propre. La CNIL française en est l'exemple le plus clair : elle publie une exemption pour l'analytics strictement limitée à la mesure de l'audience du site lui-même, utilisée par le seul éditeur du site, sans suivi entre sites et avec une limite de conservation. Les conditions sont précises et valent d'être lues si vous opérez en France. La plupart des États membres n'ont pas d'équivalent, et c'est pourquoi un outil qui évite entièrement le stockage sur l'appareil est la position la plus simple.

Ce qu'un bandeau vous coûte

Outre sa laideur, un bandeau de consentement a un coût mesurable : les visiteurs qui refusent manquent dans vos données.

Le taux exact dépend de votre public, de votre géographie et de la formulation du bandeau : traitez donc tout chiffre publié avec méfiance, y compris ceux qui sont énoncés avec assurance. Ce qui est constant, c'est le sens. Les gens les plus susceptibles de refuser penchent du côté des soucieux de leur vie privée, des techniciens et des utilisateurs de bloqueurs de publicité, et ce n'est pas un échantillon aléatoire de votre trafic. Votre analytics cesse d'être un décompte et devient une enquête dont le groupe de répondants s'est choisi lui-même.

Cette distorsion se propage. Le taux de conversion est calculé sur un dénominateur auquel manque une fraction inconnue des visites. L'attribution par canal manque des canaux d'où venaient ces visiteurs. Les résultats des tests A/B sont tirés du sous-ensemble qui a accepté d'être mesuré.

Pire, la perte est silencieuse. Rien dans le tableau de bord ne dit « et 30 % de visites en plus ont eu lieu que vous ne pouvez pas voir ». Les chiffres ont l'air complets.

À quoi ressemble une identité sans stockage sur l'appareil

Si rien ne peut être écrit sur l'appareil, la question évidente est de savoir comment on distingue un visiteur d'un autre.

La réponse est de dériver un identifiant sur le serveur à partir de choses que la requête contient déjà (typiquement l'adresse IP, l'agent utilisateur, le site et la date) et de les hacher ensemble avec un secret qui tourne. Faire tourner le secret chaque jour veut dire que l'identifiant d'un visiteur donné est différent demain et ne peut pas être reconstitué après coup, même par celui qui détient les données.

Cela vous donne des comptes exacts à l'intérieur d'une journée et vous fait perdre délibérément la capacité de suivre quelqu'un d'un jour sur l'autre. C'est un vrai compromis, et il vaut la peine d'être direct sur les rapports que cela vous coûte :

  • Les visiteurs uniques par jour, les sessions, le taux de rebond, les sources, les pages, les conversions fonctionnent tous normalement.
  • Les taux de visiteurs revenants et les cohortes de rétention sur plusieurs jours, non. Ils ne le peuvent pas, parce que tout l'intérêt est que l'identifiant d'hier soit irrécupérable.

Quiconque prétend que vous pouvez avoir une identité d'un jour sur l'autre sans rien de stocké sur l'appareil et sans identifiant persistant décrit une empreinte, quel que soit le nom qu'il lui donne, et une empreinte relève pleinement de l'article 5, paragraphe 3.

Où Skomi se situe

Skomi dérive l'identité sur le serveur à partir d'un sel qui tourne chaque jour et n'est jamais consigné. Le traceur n'écrit aucun cookie et ne touche à aucun stockage sur l'appareil du visiteur ; le code qui le ferait n'est pas simplement désactivé, il est retiré du fichier que le navigateur télécharge, ce qui est une affirmation matériellement différente de « nous ne l'utilisons pas ».

Les cohortes de rétention sont le rapport que cela coûte, et c'est dit franchement sur la page Analytics plutôt qu'enterré. Un site qui les veut peut activer par site une identité stockée sur l'appareil, moment à partir duquel il a de nouveau besoin d'un bandeau, ce qui est la description honnête de ce que fait cet interrupteur.

L'autre chose qui vaut d'être vérifiée dans tout outil que vous évaluez : le fournisseur peut-il relier vos visiteurs entre eux à travers les autres sites qu'il mesure ? Un identifiant par site qui ne franchit jamais les frontières entre sites est une posture de confidentialité différente d'un identifiant global, et cela n'est en général pas mis en avant.

Ce qu'il faut vérifier sur votre propre site

  1. Ouvrez votre site dans une fenêtre privée avec les outils de développement ouverts.
  2. Avant d'accepter quoi que ce soit, regardez Application → Local Storage, Session Storage, IndexedDB et Cookies.
  3. Tout ce qui s'y trouve a été écrit avant le consentement. Si c'est votre analytics qui l'y a mis, le bandeau ne vous sert à rien juridiquement, parce que le stockage a déjà eu lieu.

Ce troisième point attrape plus de sites que n'importe quelle autre erreur isolée. Un bandeau qui apparaît après que le traceur a déjà écrit son identifiant est une décoration.

Si vous voulez que l'outil lui-même soit la raison pour laquelle le bandeau peut partir, c'est ce pour quoi le réglage par défaut de Skomi est fait. Les pages de comparaison disent lesquelles des alternatives partagent ce défaut et lesquelles ne le partagent pas, y compris les lignes où elles gagnent.

Le mécanisme a un nom et une définition : sans cookie veut dire une identité dérivée sur le serveur à partir d'un sel changé chaque jour, ce qui est aussi pourquoi un visiteur qui revient la semaine prochaine est compté comme un nouveau.