Shower Thoughts

[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.

L’obligation d’information pesant sur le responsable de traitement et l’obligeant à communiquer à la personne concernée un certain nombre d’informations sur le traitement et son contexte¹Article 14 RGPD : “L’identité et les cordonnées du responsable de traitement et de son DPO, les finalités et la base légale du traitement (et, le cas échéant les intérêts légitimes poursuivis), les catégories de données concernées, les destinataires et les transferts à l’étranger éventuels, la durée de traitement, les droits de la personne sur le traitement, la source des données et l’existence d’une prise de décision automatisée éventuelle.“ est l’une des pierres angulaires du droit de la protection des données personnelles : elle permet de garantir que la personne concernée par le traitement a connaissance de ce dernier, des conditions auxquelles il est mis en œuvre, et de ses droits. Grâce à l’obligation d’information, une relation de confiance est ainsi instaurée entre le responsable de traitement et la personne concernée, ce qui répond au principe de traitement loyal et transparent découlant du considérant 39²Cons. 39 RGPD : “Tout traitement de données à caractère personnel devrait être licite et loyal. Le fait que des données à caractère personnel concernant des personnes physiques sont collectées, utilisées, consultées ou traitées d’une autre manière et la mesure dans laquelle ces données sont ou seront traitées devraient être transparents à l’égard des personnes physiques concernées. Le principe de transparence exige que toute information et communication relatives au traitement de ces données à caractère personnel soient aisément accessibles, faciles à comprendre, et formulées en des termes clairs et simples.“ et de l’article 5.1.a)³Art. 5.1.a) RGPD : “Les données à caractère personnel doivent être traitées de manière licite, loyale et transparente au regard de la personne concernée (licéité, loyauté, transparence.” du RGPD. C’est d’ailleurs ce que précise le considérant 60 en disposant que “le principe de traitement loyal et transparent exige que la personne concernée soit informée de l’existence de l’opération de traitement et de ses finalités“, ce qui implique même que le traitement serait déloyal en cas de non-respect de l’obligation d’information.

Lorsque les données sont collectées directement auprès de la personne concernée, l’information doit être communiquée “au moment où les données en question sont obtenues” (article 13), mais qu’en est-il lorsque les données ont été obtenues d’une source externe (comme par exemple pour un moteur de recherche) ?

L’article 14 du RGPD comporte à ce sujet un troisième paragraphe rédigé de manière assez baroque. Il comprend en effet trois propositions ainsi agencées :

3. Le responsable du traitement fournit les informations visées aux paragraphes 1 et 2 :

a) dans un délai raisonnable après avoir obtenu les données à caractère personnel, mais ne dépassant pas un mois, eu égard aux circonstances particulières dans lesquelles les données à caractère personnel sont traitées ;

b) si les données à caractère personnel doivent être utilisées aux fins de la communication avec la personne concernée, au plus tard au moment de la première communication à ladite personne ; ou

c) s’il est envisagé de communiquer les informations à un autre destinataire, au plus tard lorsque les données à caractère personnel sont communiquées pour la première fois.

Le premier point commence ainsi en instaurant ce qui semble être un principe de fourniture des informations dans un délai raisonnable ne dépassant pas un mois. Les deuxièmes et troisièmes points amènent des précisions dans deux cas, la collecte aux fins de communication avec la personne et la collecte aux fins de communication à un tiers : dans ces deux exemples, la fourniture des informations à la personne concernée peut être effectuée au plus tard lors de ladite communication. Notons au passage que dans le cas du point c), le nouveau destinataire des données, s’il est responsable de traitement, devra lui-même informer la personne concernée du traitement qu’il compte effectuer.

Comment alors concilier l’affirmation de principe du point a) avec les deux cas particuliers b) et c) ? Faut-il considérer que le délai maximal d’un mois s’applique quel que soit le cas, ou les situations particulières de b) et c) sont-elles des exceptions ? Concrètement si je collecte des données aux fins de communiquer avec la personne dans 6 mois, à quel moment l’en informer : dans un délai raisonnable ne dépassant pas un mois, ou au moment de la communication ?

Une lecture littérale et attentive nous fait pencher pour la seconde option : la conjonction de coordination séparant les propositions b) et c) est un “ou”. Puisque nous sommes dans une liste de 3 points successifs, dont l’avant-dernier contient ce “ou”, les propositions semblent ainsi être des alternatives – c’est en tout cas ce que tout juriste déduirait d’une telle liste dans un contrat, et ce que la CJUE a déduit à au moins deux reprises. Notons que le texte anglais est rédigé de la même façon. Cette interprétation est confirmée par le considérant 61 qui précise que, lorsque les données à caractère personnel sont obtenues d’une autre source, le délai raisonnable est “fonction des circonstances propres à chaque cas” : la fourniture des informations lors du premier contact avec la personne ou du premier transfert à un tiers, lorsque les données ont été collectées à ces fins, constitue bien une circonstance propre à ces cas. Cela aurait également du sens d’un point de vue pragmatique : si les données sont collectées exclusivement à ces fins de communication, le traitement ne prend véritablement vie que lors du premier contact, et la personne ne voit pas ses droits bafoués par l’absence d’information – bien que l’on puisse tout de même concevoir que la personne concernée ait envie de savoir qu’elle figure dans un fichier même si ce dernier n’est pas utilisé.

Ce n’est cependant pas l’interprétation du G29 qui, dans ses lignes directrices sur la transparence, effectue une lecture extensive de la proposition a) et en applique le délai maximal aux deux cas particuliers des points b) et c) : “dans tous les cas, le délai maximal pendant lequel les informations prévues à l’article 14 doivent être fournies à une personne concernée est d’un mois“. À en lire ses développements, les cas développés aux points b) et c) sont en fait des exceptions au fait de communiquer les données “dans un délai raisonnable“, ce délai étant en fait, pour le G29, celui de communication à la personne concernée ou à un tiers, tant que ce délai est inférieur à un mois. Le G29 explicite cette position en note de bas de page : le fait que les propositions b) et c) commencent par la préposition conditionnelle “si” indiquerait “l’ajout d’une précision à la situation générale concernant le délai maximal établi à l’article 14, paragraphe 3, point a), mais elle ne la remplace pas“. Le G29 va même jusqu’à préconiser de ne pas tenir compte du délai maximal d’un mois et affirme que “les responsables du traitement devraient, conformément au principe d’équité, fournir les informations aux personnes concernées bien avant les délais indiqués“.

On peine cependant à comprendre pourquoi le délai maximal du point a) ne serait pas remplacé par les précisions des points b) et c) compte tenu du caractère alternatif des trois points. On ne peut donc que s’opposer à cette lecture qui ne découle pas de la lettre du texte et qui ne semble pas pragmatique au regard des cas spécifiques évoqués : une occasion utile de se rappeler qu’il n’est pas nécessaire de toujours être d’accord avec la CNIL ou le G29.

On restera cependant prudent dans le désaccord avec cette position : le non respect des obligations d’information est une contravention de 5ème classe et est surtout susceptible d’être l’objet des amendes administratives les plus élevées du RGPD (20 000 000 EUR ou, dans le cas d’une entreprise, jusqu’à 4 % du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu). On conclura en rappelant qu’évidemment, les exceptions à l’obligation d’information détaillées à l’article 14.5, et notamment la dispense d’obligation d’information individuelle lorsque la fourniture de cette information serait impossible ou exigerait des efforts disproportionnés, restent applicables en tout état de cause.

Parmi les obligations pas si nouvelles du Règlement Général sur la Protection des Données (GDPR) figure celle (article 5.1.e) de la limitation de la durée de conservation des données à caractère personnel. Le règlement n’a pourtant pas fait grand-chose pour faciliter la mise en application concrète de ce principe, qui se heurte encore régulièrement à la question d’espèce : qu’est-ce qu’une durée de conservation pertinente au vu de telle ou telle finalité ?

Non pas que l’autorité compétente n’ait pas donné quelques pistes à travers ses recommandations et autres outils de droit souple – mais enfin, ces outils sont aussi faits pour être discutés, et surtout ils ne sauraient à l’évidence couvrir l’immensité des possibles qui naissent du détail de situations toujours particulières.

Une difficulté majeure tient selon nous à la conservation de long terme des données (en archive) aux fins de se prémunir des preuves utiles dans l’anticipation d’un contrôle administratif ou d’une action judiciaire. Celle-ci est implicitement autorisée par les règles d’archivage édictées par la CNIL ; reste toutefois à en déterminer la durée maximale avant destruction ou anonymisation des données. Il est d’usage de se référer pour ce faire aux durées de prescription légales ou réglementaires, applicables au contrôle ou à l’action redouté(e) ; problème, cependant : quelle est la limite du raisonnable ? Un hébergeur ne doit-il, par exemple, que craindre une action en responsabilité civile de ses utilisateurs (prescription de cinq ans), ou peut-il légitimement toujours se préparer à une accusation criminelle (et partant conserver une trace des contenus hébergés jusqu’à trente ans) ? Rien de fantaisiste dans cette seconde proposition, tant les débats sur la responsabilité à l’égard des contenus terroristes sont d’actualité.

La question prend un tour encore plus mystérieux lorsqu’il s’agit des contrôles administratifs : ainsi par exemple de l’Autorité de Contrôle Prudentiel et de Régulation (ACPR), dont les pouvoirs de contrôle ne subissent aucune prescription légale (!), et qui pourra donc exiger communication de données dans l’avenir le plus lointain. Or ces données ne peuvent pas toujours être anonymisées, comme dans le cas de l’intermédiaire en financement participatif, soumis à des obligations de KYC très précises.

Comment donc concilier cette imprescriptibilité avec l’exigence de limitation des durées de conservation ? Difficile d’apporter une véritable réponse ici – si ce n’est que d’une autorité l’autre, il serait bon d’accorder ses violons…

Parce qu’on a conscience que c’est une vraie galère pour retrouver le lien, cliquez donc ici.

Parmi les six conditions alternatives sous lesquelles l’article 17 du Règlement Général sur la Protection des Données (GDPR) reconnaît un droit à l’effacement (“droit à l’oubli”) au bénéfice de la personne concernée (droit que nous analysions en détails dans un précédent article), figure la condition suivante : “les données à caractère personnel ont fait l’objet d’un traitement illicite“. La formule, pour le moins laconique, invite naturellement à s’interroger : qu’est-ce donc qu’un “traitement illicite” ?

Deux hypothèses principales semblent pouvoir être envisagées – l’une stricte, l’autre large. Dans une acception stricte, un traitement illicite serait un traitement dépourvu de “condition de licéité” au sens de l’article 6 du GDPR : il s’agirait ainsi d’un traitement dont le responsable ne peut justifier d’aucune des six bases légales parmi la liste (limitative) prévue par cet article. Cette lecture a le mérite de la cohérence interne du texte (de même, dans la version anglaise du texte, la notion de données à caractère personnel “unlawfully processed” de l’article 17 se réfère assez intuivement à la “lawfulness of processing” de l’article 6).

Néanmoins, force est de constater, à lecture plus précise de la formule introductive de cet article 6 (“le traitement n’est licite que si, et dans la mesure où […]”), que l’existence d’une base légale n’est pas une condition suffisante, mais seulement nécessaire, de la licéité du traitement : il s’agit en effet, dans cette formule, d’un “seulement si”, et non pas d’un “si et seulement si” (dont cette simple évocation ravira à coup sûr les nostalgiques des cours de mathématiques au lycée). Pour le dire autrement : il y aurait, dans une acception plus large de la notion, d’autres conditions qui, si elles ne sont pas satisfaites, entraînerait l’illicéité du traitement.

Telle semble être la position de la CJUE, exprimée dans l’arrêt fondateur du “droit à l’oubli” pré-GDPR, Costeja c/ Google Spain (CJUE, 13 mai 2014, C-131/12), selon laquelle “même un traitement initialement licite de données exactes peut devenir, avec le temps, incompatible avec cette directive lorsque ces données ne sont plus nécessaires au regard des finalités pour lesquelles elles ont été collectées ou traitées. Tel est notamment le cas lorsqu’elles apparaissent inadéquates, qu’elles ne sont pas ou plus pertinentes ou sont excessives au regard de ces finalités et du temps qui s’est écoulé“. La Cour semble ainsi considérer que l’exactitude des données, leur pertinence et leur nécessité au regard de la finalité poursuivie, sont autant de conditions nécessaires de la licéité de leur traitement, pouvant le cas échéant justifier une demande de droit à l’oubli. Sauf à envisager que l’entrée en jeu du GDPR puisse amener la CJUE à restreindre le champ d’application de ce droit, et partant à réduire la protection accordée aux personnes concernées, l’acception large paraît donc devoir prévaloir.

Et pourtant… A l’analyse des autres cas reconnus par l’article 17 du GDPR pour l’exercice du droit à l’effacement, la plupart de ces situations apparaissent déjà couvertes spécifiquement : ainsi des données devenues non nécessaires à la finalité poursuivie (article 17.1.a) ou de l’absence de base légale disponible à la suite d’un retrait du consentement (article 17.1.b). A quel saint donc se vouer ? Dans quels cas concrets ce fondement du “traitement illicite” doit-il être invoqué ? Une petite série de lignes directrices du CEPD (feu le G29) ne serait à l’évidence pas de refus…

Entre autres apports majeurs, le (désormais plus si) nouveau Règlement Général sur la Protection des Données (GDPR) prévoit, à son article 28, l’obligation d’encadrer toute sous-traitance d’un traitement de données à caractère personnel par un contrat (ou par tout “autre acte juridique au titre du droit de l’Union ou du droit d’un État membre“), lequel doit être écrit (article 28.9) et contenir un certain nombre de clauses obligatoires (article 28.3). Cette obligation compte à l’évidence parmi celles nécessitant le plus d’efforts et de diligence de la part des entreprises et organismes publics concernés, dans la mesure où elle leur impose dans la plupart des cas de revenir à la table des négociations (pour les contrats en cours ne présentant pas le niveau de conformité requis), ou à tout le moins d’y prolonger leur séjour (pour les contrats nouveaux à négocier).

Curieusement, pourtant, le GDPR fait le choix d’une formulation suffisamment neutre (“le traitement par un sous-traitant est régi par un contrat ou un autre acte juridique au titre du droit de l’Union ou du droit d’un État membre“) pour ne pas indiquer qui, du responsable du traitement ou du sous-traitant, sera in fine responsable de l’absence d’un contrat conforme aux exigences de son article 28. Difficile ainsi de savoir laquelle des parties a le plus d’intérêt à être à l’impulsion des négociations (du point de vue du strict risque juridique, du moins), et il pourrait être tentant par exemple pour un sous-traitant de se réfugier derrière l’absence de diligence du responsable du traitement.

En réalité, le législateur européen semble avoir fait le choix délibéré de laisser, par son silence, une vraie marge de manoeuvre au bénéfice des autorités de contrôle – lesquelles peuvent d’ailleurs toujours, de façon générale, répartir leurs sanctions compte tenu du “degré de responsabilité [respectif] du responsable du traitement ou du sous-traitant” (article 83.2.d). Ces autorités n’ont d’ailleurs pas tardé à laisser entendre que, selon elles, la charge de cette obligation est partagée : ainsi de l’ICO britannique (“The GDPR imposes a legal obligation on both parties to formalise their working relationship“) ou de la CNIL (“Vous [le sous-traitant] devez […] établir avec votre client un contrat ou un autre acte juridique précisant les obligations de chaque partie et reprenant les dispositions de l’article 28 du règlement européen“).

Il y a fort à parier que ce partage sera conduit de façon largement casuistique, en tenant compte, notamment, du rapport de force commercial entre responsable du traitement et sous-traitant ; les prestataires de services en ligne d’envergure mondiale, dont les conditions générales sont souvent autant de purs contrats d’adhésion, semblent ainsi avoir tout intérêt à prendre en charge la mise en conformité de ces dernières, fussent-ils “simples” sous-traitants.

EDIT au 27 novembre 2018 : Les lignes directrices du Comité Européen de la Protection des Données, longtemps attendues, ont fini par apporter une réponse à cette Shower Thought. En un mot, cette réponse est oui. On vous laisse apprécier le détail du raisonnement du CEPD dans les dites lignes directrices (non définitives) (pages 10 et suivantes).

On le sait bien désormais : l’une des principales innovations du nouveau Règlement Général sur la Protection des Données (GDPR) est de s’intéresser d’un peu plus près à la figure du sous-traitant, en introduisant pour lui un régime de responsabilité à part entière ainsi qu’une série d’obligations propres. L’article 28, en particulier, impose à responsable de traitement et sous-traitant de conclure un contrat réglementé, contenant, pour encadrer les opérations de traitement confiées au second par le premier, un certain nombre de clauses obligatoires.

Le texte ne dit pas, cependant, si un tel contrat s’impose uniquement lorsque les deux parties sont situées dans le champ d’application territorial du GDPR, tel que précisé à son article 3, ou également lorsque l’une des deux seulement s’y trouve.

A la première moitié de ce mystère, la pratique semble déjà apporter une réponse intuitive : lorsque le responsable de traitement est soumis au GDPR, il impose à son sous-traitant, que celui-ci le soit ou non lui-même, le fameux contrat de l’article 28. Mais quid de l’hypothèse inverse, où par exemple un sous-traitant établi dans l’Union, et partant soumis au GDPR, travaillerait pour le compte d’une entreprise américaine, traitant des données de personnes situées aux Etats-Unis uniquement, et par conséquent non sujette elle-même au règlement européen ? La conclusion d’un contrat réglementé façon article 28 aurait dans un tel cas peu de sens, dans la mesure notamment où il contient des références à des obligations du responsable de traitement prévues par le GDPR lui-même, non applicables ici par hypothèse.

Et pourtant : à s’en tenir à la lettre de l’article 3 du règlement, il semblerait que celui-ci s’applique non pas à raison de l’entité (rationae personae), mais bien à raison du traitement (rationae… traitementae) – et qu’à cet égard, la simple localisation du sous-traitant dans l’Union suffise à déclencher son application pleine et entière. Selon les termes mêmes du GDPR, celui-ci s’applique en effet “au traitement des données à caractère personnel effectué dans le cadre des activités d’un établissement d’un responsable du traitement ou d’un sous-traitant sur le territoire de l’Union” ; cela signifie-t-il que le simple recours à un sous-traitant situé dans l’Union suffirait à imposer à notre responsable de traitement américain, qui ne s’occupe pourtant de données que d’américains, de respecter le droit européen ? En fait d’extra-territorialité, on toucherait ainsi à l’extrême limite.

Osons quand même, pour ne pas rester en peine, une proposition d’interprétation plus raisonnable : le texte prévoyant des obligations et responsabilités à la charge du responsable de traitement d’une part, et d’autre part du sous-traitant, son champ d’application semble plutôt devoir être “ventilé” selon la localisation, notamment, de l’un et de l’autre. De ce point de vue, l’article 28 créant une obligation manifestement imputable au responsable de traitement et non au sous-traitant (il appartient au responsable de sous-traitant de s’assurer qu’un contrat est conclu conformément aux exigences de l’article), il ne devrait s’appliquer, par conséquent, que dans la mesure où le responsable de traitement remplit, lui-même, les critères d’application de l’article 3.

La Déclaration Sociale Nominative (“DSN”) est un mécanisme introduit par la loi n°2012-387 du 22 mars 2012 relative à la simplification du droit et à l’allégement des démarches administratives, grâce auquel l’employeur dispose d’un “guichet unique” pour réaliser ses différentes déclarations sociales. La déclaration, qui contient un grand nombre de données à caractère personnel relatives à l’employé concerné, communiquées aux organismes sociaux en vue de la réalisation de leurs missions, constitue à l’évidence un traitement de ces données au sens de la réglementation applicable.

Se pose cependant la question, délicate, de la qualification des différents acteurs en présence : qui, de l’employeur ou de l’organisme social, doit être vu comme “détermin[ant] les finalités et les moyens du traitement“, et par conséquent être qualifié de “responsable du traitement” au sens de l’article 4.7 du nouveau règlement général sur la protection des données (GDPR) ? De prime abord, l’employeur se contente de transmettre les données requises par l’organisme social ; parce qu’il agit ainsi “sur instruction”, son rôle s’apparente plutôt à celui d’un sous-traitant au sens de l’article 4.8 du même GDPR. De cette vision naît une difficulté pratique majeure : l’article 28 du règlement imposerait alors à l’organisme social de conclure un contrat de sous-traitance avec chacun des employeurs déclarants, solution hautement coûteuse en termes opérationnels.

La même difficulté se retrouve par ailleurs dans l’analyse alternative où employeur et organisme social seraient responsables conjoints du traitement : l’article 26 exige en effet lui aussi que soit conclu un contrat (quoique de façon moins détaillée) entre de tels responsables conjoints, pour la bonne répartition de leurs obligations respectives.

Le Groupe de travail de l’Article 29, réunissant l’ensemble des autorités de contrôle compétentes en matière de protection des données à caractère personnel dans les différents Etats membres de l’Union Européenne, adoptait à l’égard de situations similaires, dans un avis du 16 février 2010 (exemple n°9, p. 20), une approche qui relève quelque peu du “bottage en touche” : il faudrait voir dans l’activité de l’employeur et dans celle de l’organisme social deux traitements distincts, dont chacun serait individuellement responsable. La proposition ne convainc pas entièrement : on ne saurait éluder le fait, au principe même de ces mécanismes de déclaration obligatoire, que l’organisme social “délégue” à l’employeur la charge de collecter et transmettre les données qui lui sont nécessaires.

Pas de réponse définitive à la sortie de cette douche ; la discussion est ouverte autour du café !

S’il est un sujet d’intérêt pour l’économie et l’administration de demain dans le règlement général sur la protection des données (GDPR), c’est sans nul doute la réglementation des prises de décision automatisée (automated decision-making) par son article 21. Nous abordions déjà récemment les aspects liés à l’obligation d’information spécifique en cette matière ; telle était l’occasion d’éclaircir les notions concernées, et notamment la distinction entre “simple” profilage et prise de décision purement automatisée : nous y renvoyons donc ici, par souci d’économie d’espace.

La question qui nous intéresse ici repose sur le constat d’une vraie incertitude : là où le texte évoque assez clairement un droit de la personne concernée (celui “de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé […] produisant des effets juridiques la concernant ou l’affectant de manière significative de façon similaire“), le Groupe de travail de l’article 29 (G29), réunissant l’ensemble des autorités de contrôle des Etats membres de l’Union Européenne, y lit sans ciller, dans ses lignes directrices correspondantes, une “interdiction de principe” (page 9), assortie de trois exceptions (consentement explicite de la personne concernée, autorisation légale, ou nécessité du recours à une telle automatisation pour l’exécution d’un contrat).

La nuance n’est pas mince, loin s’en faut. S’il s’agit d’une telle interdiction, la simple mise en place d’un mécanisme de prise de décision automatisée, hors les cas d’exceptions ci-dessus, pourra être sanctionnée per se ; si, à l’inverse, il s’agit d’un droit de la personne concernée, seul sera répréhensible le refus de donner effet à ce droit, par exemple en faisant intervenir une personne humaine dans la décision à première demande de l’intéressé. Dans la seconde hypothèse, on le comprend bien, le mécanisme de prise de décision automatisée peut fonctionner en toute légalité tant que les personnes concernées n’y émettent aucune objection.

Mais alors, à quel saint se vouer – législateur ou autorités de contrôle ? La contradiction est d’autant plus troublante que la directive (UE) 2016/680, qui constitue le side-car légistique du GDPR en matière de traitements à finalités pénales, prévoit quant à elle un principe d’interdiction très explicite (article 11). Faut-il expliquer cette différence par les risques accrus que fait peser la procédure pénale sur les personnes concernées, ou par une toute bête légèreté de plume ? Pas de réponse tranchée pour cette shower thought. Par prudence, on se rappellera néanmoins qu’en dernier lieu, ce n’est pas le législateur lui-même qui tient le marteau de la sanction entre ses mains…

Le cours du Bitcoin flambe, et avec lui, les regrets de ne pas avoir investi plus tôt (à l’heure de rédaction de cette pensée, 1 BTC = 9698 $). De quoi faire également réfléchir certains politiciens qui souhaiteraient bien bénéficier de cette manne pour financer leurs campagnes. La Commission gouvernementale d’éthique du Kansas vient d’ailleurs d’interdire les donations en bitcoins pour ses propres élections, malgré un avis divergent de la FCC qui avait autorisé en 2014 les donations allant jusqu’à 100$. Qu’en est-il pour la France ?

Il s’agirait ainsi pour un candidat soit de percevoir directement des bitcoins, soit d’utiliser des sommes issues de la vente de bitcoins pour sa campagne.

Pour ce qui est de la perception de fonds directement en bitcoins, il faut donc se plonger dans les règles de financement des campagnes électorales. L’article L. 52-8 du Code électoral dispose que “les dons consentis par une personne physique dûment identifiée pour le financement de la campagne d’un ou plusieurs candidats lors des mêmes élections ne peuvent excéder 4 600 €“. Il faut donc (i) que la personne physique donatrice soit dûment identifiée – ce qui implique dévoiler l’adresse d’envoi des bitcoins – et (ii) que le montant du don ne dépasse pas 4 600 €. Se pose ainsi une nouvelle question : au vu de la volatilité du cours du Bitcoin, à quelle date doit-on, le cas échéant, effectuer l’opération de change pour vérifier la légalité du don ? L’article L. 330-10 du même code prévoit, pour les français de l’étranger, que le montant de 4 600 € doit être converti en devise locale au taux de change du “dernier jour du mois précédant le paiement de la dépense ou l’encaissement de la recette“. En admettant que ces textes n’excluent pas d’office un don émis dans une devise autre qu’une devise étatique officielle, on peut supposer que le même raisonnement trouverait à s’appliquer pour un don en bitcoins – ce qui pourrait faire réfléchir à deux fois certains donateurs, le cours du Bitcoin ayant par exemple progressé de 67% entre le mois d’octobre et le mois de novembre 2017.

Par ailleurs, l’article L. 52-8 dispose également que “tout don de plus de 150 € consenti à un candidat en vue de sa campagne doit être versé par chèque, virement, prélèvement automatique ou carte bancaire.” De plus, les fonds ne peuvent être perçus que par le mandataire financier du candidat et doivent être versés directement sur le compte bancaire ouvert à cet effet – c’est notamment pourquoi l’utilisation de PayPal est a priori interdite. C’est également la raison pour laquelle il semble qu’un don effectué directement en bitcoins ne puisse être considéré comme licite, pour la simple raison qu’une adresse Bitcoin n’est pas un moyen autorisé pour recevoir des dons. Il conviendrait alors de changer les bitcoins que l’on souhaite donner en euros et de transférer lesdits euros, à défaut de pouvoir verser directement des bitcoins.

Reste à déterminer si l’utilisation de bitcoins (et donc l’utilisation de l’argent issu du change) serait un motif de réformation ou de rejet des comptes par la Commission nationale des comptes de campagne et des financements politiques (CNCCFP) : outre les règles sur le financement des campagnes, la question porte donc également sur le statut du Bitcoin en France. Dans un arrêt rendu le 22 octobre 2015, la Cour de justice de l’Union Européenne a considéré que “la devise virtuelle «bitcoin» étant un moyen de paiement contractuel elle ne saurait, d’une part, être regardée ni comme un compte courant ni comme un dépôt de fonds, un paiement ou un virement“. Si cet arrêt exclut donc certaines qualifications, le statut du Bitcoin n’en reste pas moins flou au regard des règles électorales qui prévoient que le candidat peut effectuer des apports personnels ou bénéficier de produits d’opérations commerciales : il est probablement possible pour un candidat de changer des bitcoins en euros et d’utiliser ces sommes comme apport personnel, à charge pour ce candidat de justifier que les bitcoins changés ne provenaient pas de dons mais bien d’un investissement personnel.

Il est à noter qu’une question similaire (peut-on financer un parti politique en bitcoins) avait été posée directement par le Parti Pirate à la CNCCFP en 2014 : se basant sur des textes semblables, la CNCCFP avait conclu qu’en “l’état actuel des textes“, il n’était pas possible de financer un parti politique en bitcoins.

Merci à William de Blockchain Partner pour son input sur le sujet