Consentement “ePrivacy” et consentement “RGPD” : étude d’une relation

Le consentement a toujours été présent dans le droit unioniste sur la protection des données. Déjà la directive 95/46/CE, l’ancêtre du RGPD, en sa version originelle, érigeait le consentement comme base légale de la licéité d’un traitement de données à caractère personnel. Mais, si le consentement avait une place certaine dans la réglementation, celle-ci n’en était pas pour autant spéciale. En effet, celui-ci constituait simplement l’une des six bases légales et l’une des six branches de la sainte hexalogie de la licéité. Sa position, en droit commun de la donnée, est restée inchangée avec le RGPD.

A côté de cela, le consentement a connu, et connait encore, une vie parallèle bien plus faste en droit spécial de la donnée. C’est ainsi que dès la première directive “Vie privée et télécommunications” du 15 décembre 1997, le consentement est venu justifier de la licéité de bon nombre de traitements de données propres au secteur de la télécommunication : l’interception, l’écoute, la surveillance et le stockage des télécommunications (article 5), la réutilisation des données relatives au trafic et à la facturation afin de commercialiser ses propres services de télécommunications (article 7), l’enrichissement des annuaires d’abonnés avec des données non nécessaires à leur identification (article 11), la prospection directe par téléphone (article 12).

Cette tendance s’est par la suite amplifiée avec l’adaptation ultérieure de la réglementation “vie privée” aux communications électroniques par l’intermédiaire de la directive 2002/58/CE dite “ePrivacy”, laquelle a rajouté la nécessité du consentement préalable des utilisateurs pour le traitement des données de localisation autres que les données relatives au trafic.

Si le consentement était omniprésent dans la directive ePrivacy en sa première version, et sa version révisée de 2006, la licéité d’un certain type d’opérations, nouvellement encadrée – et non pas des moindres car elle affectait tous les fournisseurs de services en ligne -, en était pourtant épargnée : le stockage et l’accès à de l’information déjà présente sur un terminal d’un utilisateur. Aussi, ces opérations, sauf exceptions restreintes, étaient-elles licites sous la seule réserve que l’utilisateur ait été clairement informé de leur existence et que la faculté de s’y opposer lui ait été présentée :

Les États membres garantissent que l’utilisation des réseaux de communications électroniques en vue de stocker des informations ou d’accéder à des informations stockées dans l’équipement terminal d’un abonné ou d’un utilisateur ne soit permise qu’à condition que l’abonné ou l’utilisateur, soit muni, dans le respect de la directive 95/46/CE, d’une information claire et complète, entre autres sur les finalités du traitement, et que l’abonné ou l’utilisateur ait le droit de refuser un tel traitement par le responsable du traitement des données.

Cependant, la dernière révision de la directive de ePrivacy intervenue en 2009 est venue nourrir l’impérialisme du consentement au sein de cette réglementation sectorielle en le hissant en condition de licéité au stockage et à l’accès à de l’information déjà présente sur un terminal d’un utilisateur :

[…] le stockage d’informations, ou l’obtention de l’accès à des informations déjà stockées, dans l’équipement terminal d’un abonné ou d’un utilisateur n’est permis qu’à condition que l’abonné ou l’utilisateur ait donné son accord, après avoir reçu, dans le respect de la directive 95/46/CE, une information claire et complète, entre autres sur les finalités du traitement.

Il est vrai que l’article 5.3 de la directive ePrivacy a, depuis son existence, toujours tempéré la nécessité d’obtenir un consentement préalable au stockage ou à l’accès à de l’information par le jeu de deux exceptions, une première pour les opérations nécessaire à ou facilitant les communications électroniques et une seconde pour les opérations strictement nécessaires à la fourniture d’un service demandé par un utilisateur :

Cette disposition ne fait pas obstacle à un stockage ou à un accès techniques visant exclusivement à effectuer ou à faciliter la transmission d’une communication par la voie d’un réseau de communications électroniques, ou strictement nécessaires à la fourniture d’un service de la société de l’information expressément demandé par l’abonné ou l’utilisateur.

Mais même le champ de ces exceptions n’a eu de cesse de se réduire, laissant le consentement préalable conditionner toujours plus de cas de figure. Ainsi la révision de la directive ePrivacy de 2009 a-t-elle supprimé les mots “ou à faciliter” de la première exception pour ne régir que les opérations “visant exclusivement à effectuer la transmission d’une communication” :

Cette disposition ne fait pas obstacle à un stockage ou à un accès techniques visant exclusivement à effectuer la transmission d’une communication par la voie d’un réseau de communications électroniques, ou strictement nécessaires au fournisseur pour la fourniture d’un service de la société de l’information expressément demandé par l’abonné ou l’utilisateur.

Le stockage et l’accès à de l’information ne nécessitant pas le consentement préalable de l’utilisateur ont ainsi terminé par être des opérations résiduelles et marginales, si tant est qu’elles ne l’étaient pas déjà.

L’instauration de cette condition du consentement préalable au stockage et à l’accès à de l’information sur le terminal des utilisateurs a donc eu et a toujours pour effet d’amener de (très) nombreux acteurs du numérique à devoir manipuler deux consentements issus de deux réglementations distinctes : un consentement “ePrivacy”  issu de l’article 5.3 de la directive ePrivacy d’une part et un consentement “Directive données personnelles” devenu aujourd’hui “RGPD” d’autre part. Petite explication de la relation qu’ils entretiennent et de la juste manière de les manipuler.

Remarque liminaire : sur l’articulation de l’article 5.3 de la directive ePrivacy et du RGPD

L’existence de ces deux corps de règles, l’article 5.3 de la directive ePrivacy et le RGPD, qu’il est bien souvent nécessaire d’appliquer conjointement, mérite que l’on s’attarde quelque peu sur ce à quoi ils s’appliquent pour mieux en comprendre l’articulation.

Ainsi qu’il est apparent de la lettre de l’article 5.3, celui-ci a vocation à régir deux situations : le “stockage d’information” dans un terminal d’une part et “l’obtention de l’accès à des informations déjà stockées” dans un terminal d’autre part. Quelques observations doivent être faites à leurs égards.

En effet, le simple stockage d’information sur un terminal ne constitue pas, nécessairement et en soi, un traitement de données à caractère personnel dès lors que les informations stockées ne sont pas nécessairement à caractère personnel. C’est, par exemple, le cas de dépôt de cookie, qui, avant de commencer à enregistrer des données liées à la navigation de l’internaute, ne contient aucune donnée à caractère personnel mais simplement des données techniques envoyées depuis le serveur hébergeant le site auquel l’utilisateur accède.

En réalité donc, l’article 5.3 de la directive ePrivacy vient régir une situation qui ne tombe pas nécessairement dans le champ du RGPD, qui lui ne s’applique que lorsque des données à caractère personnel sont traitées.

Une remarque analogue peut être faite au sujet de l’obtention de l’accès à des informations déjà stockées. Là encore, la lettre du texte ne vise pas spécifiquement le cas où ces informations sont des données à caractère personnel de sorte que même s’il est question d’accéder à des informations purement techniques (et qui ne seraient pas indirectement identifiantes, je vous vois venir) comme l’heure seule ou le modèle d’un terminal, l’article 5.3 aura vocation à s’appliquer.

A nouveau, en encadrant les modalités d’obtention d’accès à des informations déjà stockées sur un terminal, l’article 5.3 de la directive ePrivacy vient régir une situation au terme de laquelle le RGPD n’a pas toujours vocation à s’appliquer.

L’article 5.3 n’est donc pas une règle “données à caractère personnel” mais une règle à part. Cependant, il convient de reconnaître que le “stockage d’information” et “l’accès à des informations déjà stockées” sur un terminal sont des opérations fréquemment mises en oeuvre justement à l’occasion d’un traitement de données à caractère personnel. Elles interviennent donc, dans ces cas de figure, en tant que moyen de la mise en oeuvre d’un tel traitement.

Cette distinction entre moyen et traitement de données à caractère personnel, et entre les deux corps de règles qui les régissent, impose de ventiler sa réflexion sur la licéité d’un traitement en deux parties, lorsqu’il est à la fois déposé des informations sur un terminal ou qu’il y est accédé à de l’information et que par ailleurs ces opérations s’inscrivent dans le cadre d’un traitement de données à caractère personnel. Ainsi est-il nécessaire de se poser les deux questions suivantes :

1. Ai-je obtenu un consentement préalable valable pour le stockage ou l’accès aux informations sur les terminaux de mes utilisateurs ? (licéité au titre de l’article 5.3 de la directive ePrivacy)
2. Mon traitement est-il fondé sur une des six bases légales prévues par le RGPD ? (licéité au titre de l’article 6 du RGPD)

L’on remarquera donc que, l’importance du propos justifiant l’insistance, le consentement préalable au titre de l’article 5.3 de la directive ePrivacy n’a rien à voir avec la base légale du traitement de données à caractère personnel au titre de l’article 6 du RGPD de sorte que derrière ce consentement “ePrivacy”, toutes les six bases légales peuvent potentiellement venir justifier de la licéité du traitement mis en oeuvre.

Bien évidemment, le consentement de la personne concernée constituant une des six bases légales au titre du RGPD, il est donc possible de se retrouver dans une situation où la mise en oeuvre d’un traitement nécessite la collecte deux consentements distincts, un consentement “ePrivacy” et un consentement “RGPD”. Qu’en penser ?

Identité du consentement “ePrivacy” et du consentement “RGPD”

A la simple lecture de l’article 5.3 de la directive ePrivacy, une première question se pose : si son texte mentionne que la validité du consentement “ePrivacy” doit se faire à l’aune des règles régissant le consentement au titre de l’ancienne directive 95/46/CE sur la protection des données, aujourd’hui abrogée, doit-on en tirer pour conséquence que la validité du consentement “ePrivacy” s’apprécie désormais différemment de la validité du consentement “RGPD” ?

Pour une fois, la réponse est simple et univoque. En effet, l’article 94.2 du RGPD pose le principe d’une substitution totale du RGPD à la directive 95/46/CE :

Les références faites à la directive abrogée s’entendent comme faites au présent règlement.

Partant, la référence à la directive 95/46/CE dans la rédaction actuelle de l’article 5.3 de la directive ePrivacy doit être comprise comme une référence au RGPD. Les conditions de validité du consentement “ePrivacy” sont donc identiques à celles du consentement “RGPD”.

De la possibilité de fondre le consentement “ePrivacy” et le consentement “RGPD”

Ainsi que précédemment évoqué, la double condition de licéité d’un traitement de données à caractère personnel ayant pour moyen le dépôt et/ou l’accès à de l’information déjà stockée sur un terminal, ou plutôt la distinction de la licéité des moyens du traitement au titre de l’article 5.3 de la directive ePrivacy et du traitement lui-même au titre de l’article 6 du RGPD peut donc requérir d’un responsable de traitement qu’il collecte parallèlement deux consentements distincts : un consentement “ePrivacy” pour le dépôt ou l’accès à de l’information sur un terminal d’une part et un consentement “RGPD” pour constituer la base légale du traitement de données envisagé d’autre part.

Les plus économes se poseront alors la question de savoir, à raison, s’il est possible de faire une pierre deux coups et de collecter les consentements “ePrivacy” et “RGPD” en même temps.

A nouveau, la réponse est claire et univoque : oui.

En effet, rien dans la réglementation sur la protection des données  ne s’oppose, par principe, à ce que des consentements “ePrivacy” et “RGPD” soient collectés en même temps par la voie d’un seul opt-in, déjà que leurs modalités d’obtention sont identiques. Et cela est heureux dans la mesure où exiger que la personne concernée consente par deux fois pour la mise en oeuvre d’un seul et même traitement n’ajouterait rien à la protection de ses droits et libertés mais irait surtout à l’encontre de son expérience utilisateur qui l’amènerait alors, pour les besoins du respect de la réglementation, à être criblé de demandes de consentement au risque que mort s’en suive avant que ne puisse être mis en oeuvre le traitement envisagé.

Le G29, en son temps, c’était déjà prononcé en ce sens dans son opinion sur les applications mobiles :

[…] the two types of consent can be merged in practice, either during installation or before the app starts to collect personal data from the device, […]

Puis à nouveau dans son opinion sur le device fingerprinting.

De la bonne fondue du consentement “ePrivacy” et du consentement “RGPD”

Mais s’il est possible de collecter les consentements “ePrivacy” et “RGPD” en un seul trait de temps, il convient tout de même de rester sur ses gardes en s’assurant qu’ils sont obtenus valablement et qu’ils répondent chacun aux conditions de validité du consentement.

Nonobstant leur obtention conjointe, ils doivent ainsi rester notamment libres, spécifiques et éclairés/informés. Aussi, plusieurs règles particulières doivent être observées pour remplir ces trois conditions de manière distribuée pour l’un et l’autre des consentements :

• La personne concernée doit être informée, au moment de la collecte de ses consentements, qu’elle consent à deux opérations distinctes : le stockage et/ou l’accès à ses informations de terminal d’une part et le traitement de ses données d’autre part, et cela pour que ses consentements soient éclairés ;
• Le stockage et/ou l’accès aux informations de terminal doit partager la même finalité que le traitement de données mis en œuvre par respect de l’exigence de spécificité, laquelle exclut la possibilité d’obtenir un seul consentement pour plusieurs traitements distincts ; et
• Le stockage et/ou l’accès aux informations de terminal doit être techniquement nécessaire à la mise en œuvre du traitement envisagé, autrement le consentement “ePrivacy” ne sera pas libre puisqu’il aurait été possible de mettre en œuvre le traitement envisagé sans stocker ou accéder aux informations du terminal de la personne concernée et que, du fait du groupement de l’obtention des consentements, la personne concernée aurait ainsi été contrainte de donner son consentement “ePrivacy” pour donner son consentement “RGPD”.

Gardons-donc ces éléments en-tête, car ils sont la condition nécessaire d’une bonne fondue de consentements.

Petit détour sur le respect de la condition d’univocité des consentements “ePrivacy” et “RGPD”

Si le respect des trois conditions de validité du consentement précédemment évoquées nécessite d’observer des règles particulières propres à la bonne articulation des consentements “ePrivacy” et “RGPD”, tel n’est pas le cas de la quatrième et dernière condition de validité du consentement : la condition d’univocité.

En effet, que l’on veuille collecter seulement un des deux consentements “ePrivacy” ou “RGPD” ou que l’on veuille les collecter de manière simultanée, le mode d’expression du consentement de la personne concernée reste le même et doit procéder, selon la lettre de l’article 4.11) du RGPD, d’un “acte positif clair”. Autrement dit, seuls les actes dont l’on ne peut légitimement prétendre qu’ils peuvent signifier autre chose qu’une acceptation pure et simple permettront d’obtenir un consentement univoque, de la personne concernée, au dépôt ou à l’accès à de l’information sur un terminal/au traitement de données à caractère personnel.

C’est ainsi que le consentement, qu’il soit “ePrivacy” ou “RGPD” ne peut pas être valablement obtenu lorsqu’un internaute/utilisateur poursuit sa navigation sur un site internet ou sur une application. En effet, l’acte de poursuite ne permet pas de déterminer de manière certaine si l’utilisateur/internaute a entendu effectivement consentir à ce à quoi il lui était proposé de consentir ou s’il a simplement souhaité accéder au contenu du site/de l’application. Cette ambiguïté d’interprétation prive dès lors le consentement obtenu de son caractère univoque et donc de sa conformité.

Le G29, fort de ce raisonnement, a d’ailleurs clairement énoncé, dans ses lignes directrices “Consentement”, que :

Les responsables du traitement devraient élaborer des mécanismes de consentement clairs pour les personnes concernées. Ils doivent éviter toute ambiguïté et s’assurer que l’acte par lequel le consentement est accordé puisse se distinguer de tout autre acte. Aussi la simple poursuite de l’utilisation ordinaire d’un site Internet n’est-elle pas un comportement qui permet de supposer une manifestation de volonté de la part de la personne concernée visant à donner son accord à une opération de traitement envisagée.

Ce petit détour sur la condition d’univocité du consentement permet d’évoquer un sujet quelque peu fâcheux : la doctrine historique de la CNIL en matière de cookies et traceurs, le recours auxquels, parce qu’ils impliquent le dépôt et/ou l’accès à de l’information sur un terminal, nécessite au moins d’obtenir un consentement “ePrivacy”, voire également un consentement “RGPD” si le traitement de données à caractère personnel dont ils sont le moyen a cette base légale comme fondement de sa licéité.

Depuis de nombreuses années, la CNIL considère que l’acte de poursuite de navigation est un mode d’expression valide du consentement des personnes concernées à ce que soient déposés et/ou lus des cookies/traceurs sur leurs terminaux. Or, ainsi qu’il vient d’être évoqué, ni le RGPD ni l’article 5.3 de la directive ePrivacy ne tolère que le consentement soit valablement obtenu par ce biais. L’on regrettera donc fortement que la CNIL persiste à recommander aux acteurs du marché de mettre en place des mesures de collecte du consentement non-conformes à la réglementation, car en plus d’être objectivement erronées, elles ont pour effet de faire croire aux responsables de traitement qui les implémentent qu’ils sont conformes et créent pour eux une grande insécurité juridique.

Un certain Adrien Aulas s’interrogeait, dans un autre article publié maison, sur la point de savoir s’il fallait toujours être d’accord avec la CNIL. Et bien voici une belle occasion de prendre son envol intellectuel.

Consentement “ePrivacy” et consentement “RGPD” : la question du droit de retrait

L’identité du consentement “ePrivacy” au consentement “RGPD” n’a pas uniquement pour effet de les assortir des mêmes conditions de validité. En effet, elle a également pour conséquence d’accorder aux personnes concernées, eu égard à leur consentement “ePrivacy”, les mêmes droits qu’ils détiennent eu égard à leur consentement “RGPD” et en particulier le droit de le retirer comme le pose l’article 7.3 du RGPD :

La personne concernée a le droit de retirer son consentement à tout moment. Le retrait du consentement ne compromet pas la licéité du traitement fondé sur le consentement effectué avant ce retrait. La personne concernée en est informée avant de donner son consentement. Il est aussi simple de retirer que de donner son consentement.

Comment, donc, comprendre le droit au retrait du consentement “ePrivacy” et quelle est sa conséquence s’il est exercé dans le cadre d’un traitement de données à caractère personnel ?

Pour répondre à cette question, il convient tout d’abord d’évoquer ce qu’implique l’exercice d’un droit de retrait lorsqu’il porte sur un consentement “RGPD” qui vient fonder la licéité d’un traitement de données à caractère personnel. Lorsqu’une personne concernée retire son consentement au traitement de ses données, le responsable de traitement doit (i) interrompre immédiatement les opérations sur les données qu’il mettait en oeuvre (données activées) mais également, en principe, (ii) supprimer toutes les données qui ont été collectées pendant la période où le consentement de la personne concernée était en vigueur (données au repos) car même la conservation de données est un traitement au titre du RGPD (voir article 4.2 RGPD). Sur ce dernier aspect, l’on précisera tout de même qu’un responsable de traitement pourra pallier cette nécessité de supprimer les données traitées à la suite du retrait du consentement “RGPD” en justifiant la licéité de leur conservation grâce à une autre base légale, comme l’intérêt légitime par exemple. En tout état de cause, le retrait du consentement “ePrivacy” n’a pas le même effet que le retrait du consentement “RGPD”.

Ainsi qu’il l’a été précédemment évoqué, l’article 5.3 de la directive ePrivacy, a vocation a régir la licéité de certains moyens d’un traitement de données indépendamment du fait que ces données traitées soient à caractère personnel ou non. Il ne porte pas sur le même objet que l’article 6 du RGPD qui, lui, tend à encadrer la licéité des traitements de données à caractère personnel en tant que tel.

Du fait de cette indépendance, il est naturel que les effets du retrait du consentement “ePrivacy” se limitent à l’interruption de ce sur quoi il portait initialement à savoir le stockage ou l’accès à de l’information sur le terminal de la personne concernée et ne requièrent pas que le responsable du traitement interrompe également le traitement des données qu’il a pu collecter avant que la personne concernée ne retire son consentement.

Cela se comprend d’autant plus aisément que le traitement peut porter uniquement sur des données à caractère non-personnel, l’utilisation desquelles est entièrement étrangère au RGPD.

Cela se comprend également dès lors qu’il a déjà été démontré qu’un consentement “ePrivacy” ne vaut pas base légale du traitement de données à caractère personnel dont la mise en oeuvre nécessite le stockage ou l’accès à de l’information sur un terminal. Si le traitement de données nécessitant le stockage ou l’accès à de l’information sur un terminal repose, par exemple, sur l’intérêt légitime du responsable de traitement, le retrait du consentement au stockage et à l’accès à de l’information n’affecte en aucun cas la licéité du traitement concerné car il n’existe aucun rapport entre ce consentement retiré, la caractérisation de cet intérêt légitime et sa mise en balance d’avec les droits et libertés des personnes concernées qu’il requiert.

Pour prendre le cas de l’utilisation de cookies et/ou de traceurs de mesure d’audience de site internet ou d’application mobile, le retrait du consentement à cette utilisation (“ePrivacy”) dans un tel cas de figure n’impose pas que le responsable de traitement vide sa base et supprime l’historique des données de navigation qu’il a pu collecter par le passé, mais simplement qu’il cesse de stocker ou d’accéder à des informations sur le terminal de l’utilisateur pour l’avenir.

Le même argument pourrait être avancé pour le reste des bases légales, comme l’exécution d’une mission d’intérêt publique ou le respect d’une obligation légale voire même… le consentement de la personne concernée.

En effet, nonobstant le fait que des consentements “ePrivacy” et “RGPD” aient pu être collectés en même temps, ils restent des consentements distincts qui portent sur des objets différents : des moyens de traitement de données à caractère personnel ou non d’une part, et un traitement de données à caractère personnel d’autre part. Le retrait du consentement “ePrivacy” ne peut donc valoir retrait du consentement “RGPD” et ne peut encore moins avoir ses effets. Un responsable de traitement qui aurait conjointement obtenu des consentements “ePrivacy” et “RGPD” aura donc tout intérêt à ne pas prévoir également la possibilité de leur retrait conjoint mais plutôt à laisser la personne concernée exercer son droit de retrait de manière granulaire pour ne pas placer cette personne dans la situation où elle souhaiterait simplement retirer son consentement “ePrivacy” mais en vienne à retirer également son consentement “RGPD” faute pour elle de pouvoir exercer chacun de ses droits indépendamment.

Consentement “ePrivacy” et consentement “RGPD” : à quoi bon les fondre ?

Il a été évoqué précédemment que lorsqu’un traitement de données à caractère personnel nécessitait le dépôt et/où l’accès à de l’information sur un terminal d’une personne concernée, le responsable de traitement qui le met en oeuvre doit remplir deux conditions de licéité : (i) un consentement préalable (sauf exceptions restreintes) au dépôt et/où l’accès à de l’information pour respecter les exigences de l’article 5.3 de la directive ePrivacy et (ii) avoir pour fondement une des six bases légales visées à l’article 6.1 du RGPD.

Il a également été démontré que si un responsable de traitement souhaitait choisir le consentement (“RGPD'”) comme base légale du traitement à l’occasion duquel il était amené à obtenir un consentement “ePrivacy”, il lui était possible de fondre les deux et de les obtenir de manière conjointe.

Vient maintenant le temps de la question à 1000 points : est-ce que cela vaut le coup ?

A la différence de certaines des réponses données dans cet article, celle-ci est moins évidente. Car cette question ainsi posée amène in fine à s’interroger sur le bien fondé de choisir telle ou telle base légale pour justifier de la licéité du traitement de données à caractère personnel qui sera mis en oeuvre grâce au stockage ou à l’accès à de l’information sur un terminal et qui se trouvera derrière le consentement “ePrivacy” en résultant. Cela relève donc de la stratégie de conformité.

Sans pour autant comparer les avantages et les inconvénients de chacune des six bases légales du RGPD, l’on remarquera que l’arbitrage se fera principalement en fonction de deux paramètres :

• les droits que les personnes concernées peuvent exercer à l’égard de leurs données : à titre d’exemple, la base légale du consentement ouvre le droit au retrait du consentement et à la portabilité des données, ce qui n’est pas le cas de la base légale de l’intérêt légitime.
• La rigueur de l’appréciation de la licéité du traitement et de sa preuve dans la perspective d’un contrôle administratif : à titre d’exemple, la base légale du consentement ne requiert “que” l’obtention d’un consentement valide pour être licite et sa documentation est simple tandis que celle de l’intérêt légitime requiert que le responsable de traitement mette en balance ses intérêts avec ceux des personnes concernées et implémente éventuellement des garanties appropriées pour protéger leurs droits et libertés afin de rééquilibrer cette balance, tout en documentant l’ensemble de sa réflexion.

Il n’existe, en définitive, pas de réponse figée à la question de déterminer la base légale adéquate pour justifier la licéité du traitement de données à caractère personnel qui se trouverait derrière un consentement “ePrivacy” et il reviendra à chacun d’opérer un arbitrage entre elles en fonction de ses contraintes et des caractéristiques propres au traitement mis en oeuvre.

Quel avenir pour le consentement ePrivacy ?

La mort de la directive ePrivacy et de son article 5.3 est programmée de longue date. En effet, la refonte du droit des données à caractère personnel amenée par le RGPD a appelé celle de la réglementation ePrivacy. Depuis le 10 janvier 2017, les instances de l’Union Européenne discutent ainsi d’une proposition de règlement qui abrogerait la directive et en actualiseraient les règles à l’aune des récents développements technologiques et des évolutions des pratiques dans le domaine des communications électroniques.

Si l’on trouve dans la dernière version du texte de la proposition de règlement (au 22 février 2019), un article 8 qui adopte pour architecture de l’encadrement du stockage et de l’accès à de l’information sur un terminal celle de la prohibition de principe et de l’autorisation par exception, l’on remarquera également que le consentement de l’utilisateur final y a perdu, dans la bataille, son statut impérial :

Article 8
Protection of end-users’ terminal equipment information stored in terminal equipment of endusers and related to or processed by or emitted by end-users’ terminal such equipment

The use of processing and storage capabilities of terminal equipment and the collection of information from end-users’ terminal equipment, including about its software and hardware, other than by the end-user concerned shall be prohibited, except on the following grounds:

(a) it is necessary for the sole purpose of carrying out the transmission of an electronic communication over an electronic communications network; or

(b) the end-user has given his or her consent; or

(c) it is necessary for providing an information society service requested by the end-user; or

(d) if it is necessary for web audience measuring, provided that such measurement is carried out by the provider of the information society service requested by the end-user or by a third party on behalf of the provider of the information society service provided that conditions laid down in Article 28 of Regulation (EU) 2016/679 are met.; or

(da) it is necessary to maintain or restore the security of information society services, prevent fraud or detect technical faults for the duration necessary for that purpose; or

(e) it is necessary for a security software update provided that:

(i) security such updates are is necessary for security reasons and does not in any way change the privacy settings chosen by the end-user are not changed in any way,

(ii) the end-user is informed in advance each time an update is being installed, and

(iii) the end-user is given the possibility to postpone or turn off the automatic installation of these updates; or

(f) it is necessary to locate terminal equipment when an end-user makes an emergency communication either to the single European emergency number ‘112’ or a national emergency number, in accordance with Article 13(3). it is necessary to locate, at the time of the incident, a caller of an emergency call from the terminal by organisations dealing with emergency communications.

Le consentement est donc en passe de devenir une simple exception au principe d’interdiction du stockage ou de l’accès à des informations d’un terminal d’un utilisateur final et des cas de figure importants, qui nécessitent actuellement un consentement au titre de la directive ePrivacy, vont devenir des exceptions autonomes. Cet assouplissement des règles ePrivacy est opportun et heureux car il vient pallier des situations quelques peu ubuesques que pouvait engendrer l’application de la réglementation actuelle. Deux exemples :

• Sous l’empire de l’actuelle directive, le dépôt et la lecture de cookies à des fins de mesure d’audience est soumis au consentement préalable de l’utilisateur final. Or, la variable du nombre de visiteurs uniques d’un site (ou application) est par ailleurs utilisée dans la loi pour déclencher l’application de certaines dispositions légales. Ainsi des articles L111-7-1 et D111-15 du Code de la consommation qui fixe à cinq millions de visiteurs uniques mensuels le seuil au delà duquel les plateformes se doivent d’élaborer et diffuser des bonnes pratiques aux consommateurs. L’article 13 de la nouvelle directive droit d’auteur (encore en discussion) prévoit également d’utiliser un seuil identique pour aménager la limitation de responsabilité des intermédiaires techniques en matière de droit d’auteur. On a donc, main gauche, une obligation indirecte de mesurer l’audience à la charge des plateformes afin de pouvoir démontrer qu’elles n’atteignent pas certains seuils légaux de visiteurs uniques et, main droite, l’interdiction qu’elles mesurent leur audience sans le consentement des utilisateurs finaux car cette mesure requiert l’utilisation de cookies ou assimilables. Cette situation n’était simplement pas tenable.
• Sous l’empire de l’actuelle directive ePrivacy, seuls les cookies (ou assimilables) qui sont strictement nécessaires à la performance d’une communication électronique ou à la fourniture d’un service de la société de l’information explicitement demandé par un utilisateur peuvent bénéficier d’une exemption de l’obtention du consentement préalable. En matière de sécurité informatique, seuls les cookies utilisés à des fins de sécurité d’un service explicitement demandé par un utilisateur peuvent bénéficier de cette exemption à l’exclusion, donc, des cookies utilisés pour protéger les sites internet/applications et les services qui n’ont pas été explicitement demandés par l’utilisateur, qu’ils soient édités par un tiers ou par l’éditeur du site ou de l’application que l’internaute visite/utilise. Or, le RGPD fait peser sur les responsables de traitement des obligations importantes de sécurité des données à caractère personnel qu’ils traitent. On a donc, main gauche, une obligation de sécuriser des services et des outils informatiques qui pèse sur les responsables de traitement et, main droite, une règle qui soumet la mise en place de certains types de mesures de protection au bon vouloir des utilisateurs. Cette situation, à nouveau, n’était simplement pas tenable.

Si, donc, la version actuelle de la proposition de règlement ePrivacy laisse intacte la question de la détermination de la base légale, au titre du RGPD, des traitements de données à caractère personnel qui peuvent être mis en oeuvre à l’occasion d’un stockage ou d’un accès à de l’information sur un terminal, il n’en reste pas moins que, dans l’hypothèse où la rédaction de l’article 8 du règlement était conservée à son adoption, les cas de jumelage des consentements ePrivacy et RGPD, et même du recours au consentement RGPD derrière les exceptions nouvellement créées se feront bien plus rares. Car, ces nouvelles exceptions autonomes, qui flottent à côté de celle du consentement préalable de l’utilisateur, ne sont elles pas, en creux, la reconnaissance que les intérêts qui motivent leur existence sont légitimes ? De quoi rassurer, donc, certains écosystèmes, le règlement ePrivacy n’empirera pas leur situation, peut-être même l’améliorera-t-il.