Shower Thoughts


Les questions qu'on se pose sous la douche,
et les réponses qu'on leur donne autour d'un café

Prises de décision automatisées dans le GDPR : interdiction de principe ou simple droit de la personne concernée ?


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…

Un responsable de traitement décidément bien embêté

Peut-on financer une campagne électorale en bitcoins ?


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 ?

Fonctionnement du Bitcoin

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

L’acronyme “GAFA” est-il vraiment pertinent ?


GAFA par-ci, GAFA par-là : on ne peut plus trouver un article traitant de numérique sans tomber sur cet acronyme désignant Google, Apple, Facebook et Amazon. Gageons que vous pourriez même tomber dessus en cherchant, par exemple, un article sur Gaston Lagaffe. Mais cet acronyme a-t-il vraiment un sens ?

Célébration avec un doodle des 57 ans de Gaston Lagaffe par Google

Évidemment, les GAFA ont un point commun qui saute aux yeux : si vous détenez des actions chez eux, vous êtes riches – les GAFA font partie des premières capitalisations boursières mondiales. Ce sont par ailleurs des sociétés de tech relativement jeunes (Facebook, la plus jeune, a tout juste l’âge de se créer un compte sur son propre réseau – 13 ans – tandis qu’Apple, la plus vieille, vient de dépasser la quarantaine). Mais au-delà de ce pur aspect capitaliste, force est de constater, à l’instar de Numerama, que les GAFA diffèrent singulièrement les uns des autres.

Ainsi, Google n’est plus Google mais Alphabet, et cherche à diversifier grandement son business model basé jusqu’à alors exclusivement sur la pub, ce qui lui fait un point commun avec Facebook, mais pas plus. Apple reste une entreprise de hardware malgré ses quelques logiciels à succès, et Amazon un e-commerçant, dont les publicités servent à générer des achats sur sa propre plateforme. Comparer Google (réduit au moteur de recherche) et YouTube et Facebook a un sens, mais rajouter Apple et Amazon dans la boucle n’en a que peu. Par ailleurs, le sigle oublie complètement l’un des principaux acteurs de la tech, qui existe au sommet des capitalisations boursières depuis belle lurette et dispose de synergies avec l’ensemble des acteurs sus-cités : Microsoft. On voit ainsi se rajouter régulièrement le M de Microsoft pour donner GAFAM : si les business models des uns et des autres restent très différents (et d’ailleurs pas forcément liés directement au développement d’Internet pour Microsoft et Apple), il n’en reste pas moins qu’on englobe les plus grandes capitalisations boursières de la tech.

Reste que s’il s’agit de parler de l’évolution d’Internet en tant que technologie, le sigle est largement insuffisant : on met ainsi de côté le développement faramineux des “NATU” (Netflix, Airbnb, Tesla et Uber), et surtout la croissance phénoménale de l’Internet chinois avec ses “BATX” (Baidu, Alibaba, Tencent et Xiaomi), dont certains font désormais également partie du club des dix premières capitalisations boursières de la planète. Au fond, parler de “géants du net” permet de faire facilement référence aux entreprises extrêmement puissantes qui se partagent un oligopole sur les différents marchés d’Internet, tandis que les acronymes de noms de sociétés conservent un sens lorsque l’on traite de géopolitique. On privilégiera donc une utilisation modérée du sigle GAFAM, à n’employer qu’à bon escient.

Le consentement au contrat impliquant un traitement de données personnelles doit-il être un consentement GDPR ?


Parmi les conditions de licéité d’un traitement de données à caractère personnel alternatives au consentement, le nouveau règlement général sur la protection des données (GDPR) prévoit, dans la continuité de l’actuelle loi Informatique & Libertés, qu’un traitement est autorisé si et dans la mesure où il est “nécessaire à l’exécution d’un contrat auquel la personne concernée est partie” (article 6.1.b) : dans un tel cas, donc, nul besoin a priori de consentement au sens du GDPR.

Le serpent paraît cependant se mordre la queue lorsqu’on se rappelle que le droit civil français, à peine remanié à cet égard par la récente ordonnance du 10 février 2016, exige pour la validité d’un contrat la réunion de quatre conditions fondamentales, les quatre C canoniques : Capacité, Consentement, Cause, … Cobjet. Le consentement réapparaît donc dans l’ombre du contrat ; mais est-ce vraiment le même ?

Les articles 4.11 et 7 du GDPR, qui fixent les modalités d’un consentement valable, ne s’appliquent à l’évidence qu’au consentement tel que défini par le GDPR lui-même, à savoir le consentement au traitement, condition de licéité de l’article 6.1.a, et non pas le consentement au contrat impliquant un traitement. Autrement dit : rien n’impose que le consentement au contrat dont l’exécution nécessite un traitement de données à caractère personnel soit “libre, spécifique, éclairé et univoque” (article 4.11), ou encore puisse être retiré aussi facilement qu’il a été donné (article 7). On le comprend aisément : si tel était le cas, alors il n’existerait, de fait, aucune différence entre la base légale de l’article 6.1.a et celle de l’article 6.1.b.

Prudence cependant : à bien y regarder, une partie au moins de ces modalités est tout de même recomposée par le biais d’autres principes du GDPR. Le traitement doit en effet être “loyal” et “transparent” (article 5.1.a), et le responsable du traitement reste tenu d’une obligation d’information (articles, 12, 13 et 14), de sorte que le consentement au contrat devra malgré tout être, d’une certaine manière, “éclairé“. De même, on rappellera que seuls les traitements véritablement “nécessaires” à l’exécution du contrat peuvent être couverts par ce contrat, de sorte qu’il ne devrait pas être possible de profiter de la souscription d’un contrat pour imposer au cocontractant une collecte ou d’autres traitements de données superflus – comme, par exemple, l’inscription automatique à la newsletter de l’entreprise…

La fameuse technique du pied dans la porte

Qu’est-ce que l’Internet Literacy, et pourquoi s’en soucier ?


Le sujet brûlant des fake news, devenu si actuel et problématique qu’il a fini par provoquer une réponse des institutions européennes en la forme d’une consultation publique, possible préalable à une intervention législative, a du moins le mérite d’avoir (re)mis en lumière le constat suivant : Internet, objet multimédia (mais majoritairement textuel), parce qu’il présente des codes complexes qui lui sont propres (des mèmes, des protocoles, des manières de présenter l’information tenant à sa structure en hyperliens, etc.), fait courir le risque permanent, pour celui qui ne maîtrise pas ces éléments de langage, de se laisser piéger, malicieusement ou non.

De ce point de vue, l’époque semble appeler à une revalorisation de ce concept (déjà) un peu désuet qu’est l’Internet Literacy (ou Digital Literacy) : popularisée vers la fin des années 2000 par la publication d’un handbook du Conseil de l’Europe, la notion désigne, en somme, cette capacité à lire Internet, pour y naviguer de façon raisonnée et sécurisée, dont la possession constitue à l’évidence un atout de plus en plus décisif.

Les illustrations sont nombreuses, et extrêmement quotidiennes : savoir formuler une requête efficace sur un moteur de recherche ; savoir identifier un lien suspect sans l’ouvrir ; savoir mettre à profit les forums “techniques” pour comprendre et résoudre un problème logiciel ; savoir se poser les bonnes questions sur l’origine humaine ou automatisée de certains contenus… Elles font apparaître une variété d’enjeux tout aussi importante, de la protection de la vie privée jusqu’à la compétitivité d’un travailleur, d’une entreprise, voire d’une économie.

Ces compétences, bien que valorisées, sont paradoxalement souvent reléguées à l’autodidactisme et à la “culture geek” ; plus discrètes, moins impressionnantes que le code, il n’a, à notre connaissance, jamais été sérieusement envisagées de les enseigner. Se joue là cependant, à l’évidence, une part cruciale des réponses à bon nombre de sujets qui nous préoccupent, dont il serait judicieux de se saisir à un niveau plus qu’individuel : le droit, c’est après tout, aussi, ce qui détermine le contenu des programmes scolaires…

Des débuts prometteurs

Qu’est-ce que la “responsabilité de plein droit” du e-commerçant ?


L’article 15 de la loi pour la confiance dans l’économie numérique prévoit que “[le e-commerçant] est responsable de plein droit à l’égard de l’acheteur de la bonne exécution des obligations résultant du contrat, que ces obligations soient à exécuter par [lui]-même ou par d’autres prestataires de services, sans préjudice de son droit de recours contre ceux-ci. Toutefois, [il] peut s’exonérer de tout ou partie de sa responsabilité en apportant la preuve que l’inexécution ou la mauvaise exécution du contrat est imputable, soit à l’acheteur, soit au fait, imprévisible et insurmontable, d’un tiers étranger à la fourniture des prestations prévues au contrat, soit à un cas de force majeure.

La responsabilité “de plein droit” s’oppose classiquement à la responsabilité “pour faute”, en matière par exemple de responsabilité des parents du fait de leurs enfants depuis le fameux arrêt Bertrand de 1997. Est-ce à dire que le e-commerçant est systématiquement tenu d’une obligation de résultat ? La solution ferait frémir, et pour cause : dans le cas de services fournis en ligne, elle imposerait d’indemniser l’utilisateur dès lors que ces services sont temporairement inaccessibles, par exemple pour motif de maintenance.

Fort heureusement, tel n’est pas le sens de la responsabilité de plein droit, laquelle a trait non pas à la nature des obligations (de moyens ou de résultat), mais à l’imputation de la responsabilité qui résulte de leur inexécution, dans le souci d’une bonne indemnisation de la personne lésée : comme le parent, le e-commerçant est érigé en “guichet unique”, tenu d’assurer l’indemnisation quand bien même l’inexécution aurait pour origine le comportement de son sous-traitant (de son enfant) – à charge pour lui de se retourner ensuite contre ce sous-traitant. La responsabilité de plein droit est ainsi une responsabilité “du fait de”, ayant pour objet de distinguer entre la personne cause de l’inexécution et la personne chargée de l’indemnisation.

Encore faut-il, donc, caractériser une inexécution ! Si l’obligation de continuité du service, par exemple, ne s’analyse qu’en une obligation de moyens (comme c’est le cas en général), la simple fermeture temporaire pour maintenance ne saurait constituer une inexécution ; la question de l’imputation de la responsabilité sera dans ce cas sans objet, faute précisément de fait générateur de responsabilité. Pour le e-commerçant avisé, il y a donc lieu de définir d’autant mieux, dans les conditions générales qui le lient à l’utilisateur, la nature et l’étendue de ses obligations, pour couper court dans bien des litiges à toute application du fameux article 15.

Apprenez à jongler avec les notions du droit civil pour impressionner vos amis !

Comment prononce-t-on “Aeon” ?


Vous êtes arrivé(e) sur le site, vous avez lu son nom, et donc, forcément, vous l’avez pensé, voire dit tout haut. Mais comment l’avez-vous prononcé ?

Sébastien Chabal a un avis sur la question

“Aeon” est le nom latin du dieu phénicien “Eon”, dieu du temps éternel et de la prospérité, n’ayant ni commencement ni fin. Le mot “éon”, qui en est dérivé, désigne la plus grande unité de période de temps de l’échelle géologique et évoque un avenir empli de questions insondables (et juridiques).

Tout cela est bien joli, mais encore – comment le dire ? Nouvelles tech’ obligent, nous avons choisi de nous en remettre à une intelligence artificielle : la voix de Google Translate, comme vous pouvez l’entendre ci-dessous, adopte avec bonheur la même prononciation en français et en anglais. De part et d’autre de la Manche et de l’Atlantique, tout est simple finalement : dites donc Éonne !

Peut-on échapper au risque de surveillance par l’administration américaine ?


La surveillance des communications électroniques par le gouvernement des Etats-Unis a pour fondement légal le Foreign Intelligence Surveillance Act tel qu’amendé par le Patriot Act en 2001 à la suite des attaques du 11 septembre, ses modifications ultérieures ainsi que tout dernièrement par le USA Freedom Act de 2015. On retrouve aujourd’hui les dispositions pertinentes codifiées à l’article 1881 du Code des Etats-Unis.

Ce corpus législatif autorise le gouvernement américain à surveiller (selon certaines conditions et avec certaines limitations) les communications électroniques entre les Etats-Unis et l’étranger. Les autorités américaines peuvent ainsi enjoindre à toute société située sur le sol américain de lui donner accès aux informations et données dont elle aurait connaissance et qui transiteraient de l’étranger vers les Etats-Unis ou, inversement, des Etats-Unis vers l’étranger.

C’est notamment dans ce cadre que le programme PRISM de la NSA, révélé par Edward Snowden, a été développé, lequel a permis aux autorités américaines d’avoir accès à une quantité massive de données sur les citoyens et entreprises européens.

La problématique de la surveillance gouvernementale se fait particulièrement ressentir à l’occasion des prestations de services en cloud dont le principe de fonctionnement suppose le transfert des données de l’utilisateur vers les serveurs du prestataire. Ces serveurs peuvent se trouver à plusieurs endroits du globe mais sont assez fréquemment localisés aux Etats-Unis. Or, comme précédemment énoncé, dès qu’une donnée passe, même temporairement, par un serveur américain, celle-ci est susceptible d’être interceptée par les autorités américaines.

Dans les faits, il est très difficile d’échapper au risque de la surveillance des Etats-Unis dans la mesure où même si des données sont hébergées et stockées sur des serveurs européens, elles sont toujours susceptibles de transiter sur un serveur situé sur le sol américain, par exemple à l’occasion de services de maintenance à distance ou de sous-traitance d’opérations.

Le caractère tentaculaire de la loi encadrant la surveillance américaine et la circonstance que tous les leaders du numérique soient américains est une des raisons pour lesquelles l’Union Européenne tente désespérément de créer des conditions favorables à l’émergence d’un cloud 100% européen. Dans l’attente de l’émergence d’un tel service, peu de mesures concrètes et efficaces peuvent être prises pour échapper à la possibilité que des informations stratégiques et confidentielles terminent dans des mains autres que celles de leurs destinataires souhaités.

Comment lutter contre une telle compétence ?

“Smart cities” : quel impact du GDPR sur les règles de la commande publique ?


L’exemple édifiant du premier “quartier connecté” commandé à Alphabet, société du groupe Google, par la ville de Toronto, interroge de façon plus générale sur la prise en compte de la réglementation des traitements de données à caractère personnel dans le cadre des marchés publics : les projets de smart cities, même de moindre envergure, mobilisent en effet par définition un grand nombre de ces traitements, visant par exemple à optimiser les flux de circulation automobile ou la distribution de l’énergie (smart grids).

Au regard des catégories historiques de la réglementation (reprises pour l’essentiel dans le nouveau règlement général sur la protection des données), l’Etat ou la collectivité territoriale qui est à l’initiative d’un tel projet sera de toute évidence désigné comme responsable des traitements mis en oeuvre (éventuellement de façon conjointe avec la ou les société(s) prestataire(s)). Il en découle, pour ce responsable, l’obligation de s’assurer (et de pouvoir démontrer) que le projet est bien conforme aux exigences de la protection des données à caractère personnel ; en particulier, il s’agira, au titre de l’obligation de privacy by design et by default, d’opter constamment pour les solutions les plus respectueuses de cette protection.

Du point de vue des procédures de la commande publique, cela signifie prendre en compte ces aspects réglementaires depuis la détermination des critères de mise en concurrence jusqu’au choix final du prestataire et de son projet : toutes choses égales par ailleurs, ce choix ne pourra ainsi porter que sur le projet le plus protecteur, à savoir notamment le plus économe en traitements et le plus sécurisé. Pour satisfaire par ailleurs au principe de transparence et d’accountability, il conviendra donc d’accorder une importance toute particulière à la rédaction d’un volet “Données personnelles” du cahier des charges – davantage en tous cas que ne l’ont fait, outre-atlantique, les commanditaires torontois (voir l’annexe C de l’appel d’offres publié)…

Quant au prestataire candidat, il va sans dire que la compliance représente ici encore, dans son intérêt, un argument commercial décisif.

Et le GDPR dans tout ça ?

Quelle condition de licéité pour les traitements automatiques de données personnelles réalisés par les serveurs ?


Tout traitement de données personnelles doit être fondé sur une condition de licéité (article 7 de la LIL, article 6 du RGPD). Tout traitement ? Un traitement pourtant universel résiste peut-être encore et toujours à l’envahisseur (le droit de la protection des données personnelles). Or, l’article 13 du GDPR impose au responsable de traitement, au titre de son obligation d’information, de clairement indiquer les bases légales de tous les traitements effectués. Afin d’assurer une conformité totale au GDPR, il est donc essentiel de déterminer la condition de licéité applicable à ce traitement récalcitrant.

Le traitement en question face au droit des données personnelles

Afin d’expliquer ce dont il retourne, il est nécessaire de revenir aux fondamentaux du fonctionnement du web : lorsque vous tentez d’accéder à une URL, https://aeonlaw.eu par exemple, vous envoyez une requête HTTP au serveur hébergeant le site en question. Cette requête contient plusieurs paramètres, qui sont automatiquement envoyés par votre navigateur et automatiquement enregistrés par le serveur destinataire de la requête pour traitement de celle-ci. Parmi ces paramètres, votre adresse IP, votre système d’exploitation, la version de votre navigateur Internet, et bien entendu, des métadonnées telles que la date et l’heure exacte (à la seconde près) de votre requête. Or, l’on sait que l’adresse IP est généralement considérée comme une donnée personnelle. C’est a fortiori le cas lorsqu’il est possible d’obtenir l’identité d’une personne auprès des fournisseurs d’accès à Internet, comme en France. Ainsi, tout site Internet que vous visitez collecte automatiquement certaines données qui peuvent permettre de vous identifier. La question est donc : quelle condition de licéité pour ces traitements automatiques réalisés par des serveurs ?

Il n’y a en effet ni consentement (qui doit être explicite et éclairé), ni contrat (puisque vous n’avez pas encore accédé au site), qui sont les deux options les plus courantes. Reste ainsi l’intérêt légitime du responsable de traitement. Cela pourrait se tenir (après tout, le traitement est automatique et nécessaire à l’accès au site), si ce n’est que le responsable du traitement n’est pas si facile à déterminer que cela : en effet, dans beaucoup de cas, l’éditeur du site n’est pas le propriétaire du serveur, qui appartient plutôt à un prestataire d’hébergement. Celui-ci contrôle son serveur de manière autonome, notamment en ce qui concerne la durée de conservation de ces données. Ainsi, à la question de la condition de licéité applicable à ces traitements s’ajoute celle de savoir qui est le responsable du traitement : une fois n’est pas coutume, cette Shower Thought se conclut donc sans réponse mais avec encore plus de questionnements.

Vous à la fin de cette Shower Thought

Nous n'avons plus de Shower Thoughts supplémentaires à vous montrer !