Shower Thoughts


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

Les pixels de tracking doivent-ils vraiment faire l’objet d’un consentement préalable ?


Dans sa délibération du 5 décembre 2013 n° 2013-378, la CNIL est claire : la recommandation qu’elle effectue “a vocation également à s’appliquer à d’autres technologies (notamment, en l’état des connaissances actuelles, les local shared objects appelés parfois les cookies “flash”, les pixels invisibles ou web bugs , les identifications par calcul d’empreinte du terminal ou encore des identificateurs cachés)“. 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 32.II 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 à autre chose que des cookies ? 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. 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 !

Nous avons l’habitude de mettre des gifs, mais l’illustration du danger posé par un pixel nous semblait ici plus pertinente

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 32.II 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 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 l’appréciation purement technique peut être contestée, l’intention du législateur, elle, est limpide.

Il est donc temps d’adapter la lettre de la loi pour être conforme à son esprit : c’est en partie ce qu’accomplit l’article 8 du projet de Règlement ePrivacy, qui interdit “l’utilisation des capacités de traitement et de stockage des équipements terminaux et la collecte d’informations provenant des équipements terminaux des utilisateurs finaux, y compris sur les logiciels et le matériel“, sauf notamment dans les cas techniques (requête HTTP !).

On ne peut en revanche que déplorer que le législateur soit à nouveau tombé 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.

La sentence est irrévocable

Qu’est-ce qu’un traitement de données à caractère personnel “illicite” ?


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…

Perclus de doute face au GDPR, de nombreux juristes en deviennent émos. Agissons maintenant.

Qui est responsable de la conformité des contrats entre responsable de traitement et sous-traitant ?


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.

Un service provider excédé par l’impact du GDPR sur ses contrats

Sous-traitant établi dans l’Union Européenne, dois-je conclure un contrat avec mes clients qui ne le sont pas ?


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.

L’auteur de cette Shower Thought se payant le luxe d’une interprétation totalement libre et non sourcée

Déclaration Sociale Nominative : qui est responsable du traitement de données à caractère personnel ?


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é !

Une séance de brainstorming à laquelle vous êtes tou(te)s invité(e)s

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

En discuter
2 commentaires

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

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