[Version mise à jour d’un article publié le 11 septembre 2018]
Dans sa délibération n° 2020-091 du 17 septembre 2020, la CNIL est claire : la recommandation qu’elle effectue porte sur “d’autres technologies telles que les «local shared objects» appelés parfois les «cookiesFlash», le «local storage» mis en œuvre au sein du standard HTML5, les identifications par calcul d’empreinte du terminal ou «fingerprinting», les identifiants générés par les systèmes d’exploitation (qu’ils soient publicitaires ou non: IDFA, IDFV, Android ID, etc.), les identifiants matériels (adresse MAC, numéro de série ou tout autre identifiant d’un appareil), etc“. Il s’agit donc d’obtenir le consentement de la personne concernée préalablement à toute mise en œuvre de ces technologies, conformément à l’article 82 de la LIL, sauf exceptions des cas purement techniques.
Pourtant, à y regarder de plus près, ce texte a-t-il vraiment vocation à s’appliquer à certaines des technologies du web ? En effet, l’article 32.II. vise spécifiquement “toute action tendant à accéder, par voie de transmission électronique, à des informations déjà stockées dans son équipement terminal de communications électroniques, ou à inscrire des informations dans cet équipement“.
Le texte vise expressément le fait d’interagir avec le système de stockage du support numérique utilisé par la personne concernée, ce qui est bien le cas des cookies, petits fichiers textes déposés sur le terminal de l’utilisateur, ou de l’accès à des identifiants uniques de l’appareil (adresse MAC, numéro de série). En revanche, les pixels de tracking, eux, ne sont jamais déposés sur le terminal de l’utilisateur et n’accèdent à aucune information stockées dessus : ce sont de simples pixels ! Il en va de même pour les paramètres d’une URL s’ils ne sont pas issus du terminal de l’utilisateur, ou de logs de requêtes HTTP sur un serveur.
Techniquement, comment cela fonctionne-t-il ? Le pixel est une image qui doit être téléchargée depuis le serveur hôte. Ce faisant, une requête HTTP est effectuée par l’utilisateur, comprenant les informations usuelles d’une telle requête, avec entre autres l’adresse IP de l’utilisateur et son navigateur. En affublant le pixel demandé d’un identifiant unique, et en associant cet identifiant à un email envoyé, il est possible de savoir avec certitude l’heure à laquelle un email a été lu, sans pour autant jamais stocker d’informations sur le terminal de l’utilisateur ou accéder à de telles informations.
Il en est parfaitement de même pour beaucoup d’autres techniques modernes de suivi comportemental, qui s’exécutent dans le navigateur sans jamais avoir besoin de stocker d’informations sur le terminal utilisateur. Il est par exemple possible, en quelques lignes de code, d’obtenir les coordonnées de mouvement de la souris de l’utilisateur, et ce sans cookies.
L’avis du G29 sur la publicité ciblée semble indiquer que le simple fait d’utiliser des technologies exécutées côté client (donc par le navigateur de l’utilisateur, même si aucune information n’est stockée sur son terminal ou extraite directement de son terminal) devrait être considéré comme un “accès à des informations déjà stockées” (lettre de l’article 82 de la LIL mais également de l’article 5 de la Directive ePrivacy révisée) : “Most tracking and advertising technologies used to deliver behavioural advertising use some form of client-side processing. It uses information from the user’s browser and terminal equipment“.
Plusieurs arguments, une fois de plus d’ordre technique, peuvent être opposés à cette logique. En effet, si l’accès à des informations côté client revient à mettre en œuvre une technologie de tracking, alors c’est la base même du web qui est en cause puisque la requête HTTP, émise par l’utilisateur pour accéder à un site sans que le site n’en sache rien jusqu’à réception de ladite requête, contient des données à caractère personnel ! De la même façon, énormément de sites modernes se servent d’informations côté client non pas pour suivre le comportement de l’utilisateur, mais pour améliorer son expérience : ces informations ne sont pas stockées ou utilisés pour d’autres raisons que de modifier l’apparence du site au fur et à mesure de la navigation – on pense notamment au défilement infini ou aux technologies dites de parallax, pour des effets de style jouant sur la profondeur de champ.
In fine, la stricte lettre actuelle des textes ne semble pas couvrir beaucoup d’autres technologies que le cookie. L’esprit, en revanche, est clair : les technologies de suivi comportemental posent, pour la CNIL, le G29 et le législateur, un problème de vie privée et de protection des données qui ne peut être résolu que par le consentement. C’est ainsi que le considérant 24 de la directive ePrivacy affirme que “les logiciels espions, les pixels invisibles (web bugs), les identificateurs cachés et les autres dispositifs analogues peuvent pénétrer dans le terminal de l’utilisateur à son insu afin de pouvoir accéder à des informations, stocker des informations cachées ou suivre les activités de l’utilisateur, et peuvent porter gravement atteinte à la vie privée de ce dernier“.
Si le législateur et le régulateur souhaitent encadrer une finalité précise, il est temps d’adapter la lettre de la loi pour être conforme à son esprit. En l’état actuel des textes, il semble cependant totalement exclu de “finaliser” l’application de la réglementation “cookies” : il s’agit d’une réglementation d’un usage technologique, le stockage ou l’accès à du stockage sur le terminal de l’utilisateur, et non d’une réglementation finalisée portant par exemple sur la prévention du suivi en ligne.
Le Règlement ePrivacy, qui sera peut-être un jour adopté, peut être le lien de clarification de l’intention du législateur, mais les dernières versions publiées ne rendent pas optimiste : le législateur semble encore et toujours tomber dans le travers de réglementer une technologie (l’accès à des informations client) plutôt qu’une fin (le suivi comportemental). Pour un texte agnostique à la technique et qui s’applique quel que soit l’état de l’art, on repassera.
