Bonjour Nal,
Chez nous en Belgique, c'est bien connu, on ne nomme pas les choses comme en France. Ça vous fait souvent rire (et nous aussi).
Mais trêve de considérations linguistiques, la CNIL au plat pays s'appelle l'APD, pour "Autorité de Protection des Données". Et chez ces gens-là, pour paraphraser un de nos chanteurs (qui n'est pas Stromae), on ne rigole pas, Monsieur, on ne rigole pas. On décide.
La décision tombée aujourd'hui est assez surprenante, je ne sais pas trop qu'en penser : les fenêtres popup qui permettent de refuser ou d'accepter les cookies sont illégales !
Ce qu'un de nos sites d'info abrège en "la publicité en ligne viole le RGPD" (le raccourci me paraît un peu exagéré).
Et toi, Nal, qu'est-ce qu'en penses-tu donc ?
Ah oui, le lien
# C'est rigolo...
Posté par Dring . Évalué à 10.
…car évidemment, la page de la RTBF commence évidemment par poser la question désormais inévitable.
Mais plus généralement, d'après l'article, ce qui est reproché c'est surtout que l'information donnée aux internautes ne leur permet pas de comprendre à quoi ils donnent leur consentement.
De ce point de vue là, la décision a du sens en effet.
Mais bon, l'internaute reste un consommateur normal. Plus on lui donne d'information, moins il la lit. Là, en général, y'a un gros bouton "Accepter tout" si il veut pas réfléchir, et "Personnaliser…" si son cerveau est allumé. J'avoue que personnellement, je clique généralement sur "Accepter tout", par pure faignantise.
Après, on peut aussi interdire la publicité ciblée, ce serait plus simple :-).
[^] # Re: C'est rigolo...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
Moi je choisis presque toujours de "Personnaliser…" ou quitte le site… J'aurais préférer un gros bouton "Refuser tout" à la place du "Accepter tout".
Je dis presque toujours parce-que je suis en train de tester l'extension Firefox nommé Ninja Cookie …et plus ça va et moins ça me plaît (ça fait un peu comme toi et donne l'impression de naviguer comme avant, en consentant par défaut.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: C'est rigolo...
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 04 février 2022 à 16:35.
Alors depuis très récemment j'ai changé de technique. Il se trouve que j'utilise uBlock Origin dans mon Firefox, et j'ai trouvé récemment (par hasard en cliquant au mauvais endroit) qu'il a une fonction "zap" : tu sélectionnes un bout de la page et il le tue immédiatement. Ça coûte tout de même 3 clics :
- cliquer sur l'icône de l'extension uBlock
- cliquer sur le petit éclair en bas à gauche
- cliquer sur la pop-up
Donc la pop-up, j'y réponds même pas, je la zappe direct !
Par exemple sur le lien cité dans le journal ça marche nickel.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'est rigolo...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Radical :D Le souci demeure quand même : je veux zapper en refusant, pas zapper en acceptant tout par défaut…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: C'est rigolo...
Posté par gUI (Mastodon) . Évalué à 2.
Ah mais tu n'acceptes rien ! Tu n'acceptes même pas le cookie qui dit que tu as refusé. La preuve, il faut re-zapper à chaque visite.
Pour les site que tu visites juste une fois (comme le lien de ce journal par exemple) c'est pas mal.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C'est rigolo...
Posté par eingousef . Évalué à 7.
Ah je ne connaissais pas cette astuce, quand c'est possible de fais "clic droit" -> "Block element" et ensuite j'ai une fenêtre de uBlock origin qui me permet de choisir l'élément à bloquer dans la page autour de l'endroit où on a cliqué, de façon permanente.
Ça marche bien sur les sites où la popup / le bandeau est une simple surimpression, comme stackoverflow par exemple.
Ça marche moins bien sur les sites où la popup s'accompagne d'un filtre qui grise tout le reste de la page et fait disparaître la scrollbar (twitter par exemple), dans ce cas-là je suppose qu'il faut lire tout le code pour connaître les éléments à bloquer.
*splash!*
[^] # Re: C'est rigolo...
Posté par Ytterbium . Évalué à 5. Dernière modification le 05 février 2022 à 12:34.
Alors pour Twitter qui bloque désormais la lecture lorsque l'on n'est pas inscrit, je suis tombé sur les règles suivantes
Et ça empêche la popup de blocage.
[^] # Re: C'est rigolo...
Posté par Misc (site web personnel) . Évalué à 9.
Oh, sympa.
Sinon, j'ai commencé à utiliser Nitter, et il y a des extensions Firefox pour automatiquement basculer sur Nitter.
[^] # Re: C'est rigolo...
Posté par kalimba . Évalué à 3.
Sinon il y a aussi l'extension "I don't care about cookies" qui supprime tous les bandeaux et popup inutiles du genre. Marche tres bien
[^] # Re: C'est rigolo...
Posté par Gabbro . Évalué à 4.
Je préfère « consent-O-matic », qui complète les popups à ta place, en rejetant tous les cookies non nécessaires, là où « I don't care about cookies » les accepte.
[^] # Re: C'est rigolo...
Posté par seveso . Évalué à 3. Dernière modification le 09 février 2022 à 08:00.
Ces 2 extensions ne sont pas vraiment comparables car elles ne s'adressent pas au même public.
"I don't care about cookies" s'adresse plutôt aux personnes ayant configuré leur navigateur pour ne jamais enregistrer les cookies par défaut.
Pour ces personnes, depuis RGPD, le Web est devenu un cauchemar, et cette extension est devenue indispensable.
Consent-O-matic s'adresse plutôt aux personnes dont le navigateur accepte les cookies par défaut, c'est à dire quasiment tout le monde. Donc c'est une extension intéressante aussi.
[^] # Re: C'est rigolo...
Posté par Misc (site web personnel) . Évalué à 4.
Je vois ce que tu veux dire, mais la publicité est toujours ciblé.
Si je mets un panneau sur l'autoroute de Namur, je cible un publique précis, à priori belge, avec le permis et sans doute capable de parler la langue de la publicité.
De même quand je passe une annonce dans le Figaro, je vais pas viser les classes ouvrières d'argentine.
C'est juste que maintenant, elle est ciblé de manière beaucoup plus fine et plus précise. Mais ça n'a jamais été non ciblé.
[^] # Re: C'est rigolo...
Posté par Elfir3 . Évalué à 3.
De plus, il y a 4 places dans la plupart des voitures. 5 voir plus dans certaines. Est-ce que la majorité des occupants d'un véhicule a le permis ? Je suis curieux de voir les chiffres !
C'est aussi osé de dire ça en Belgique. Heureusement que tu as choisi Namur et pas Overijse..
Note, je trouverais ça dommage que les muets n'aient pas droit à un ciblage publicitaire. C'est discriminant.
Sur ce, bon week end.
[^] # Re: C'est rigolo...
Posté par ted (site web personnel) . Évalué à 10.
Ce qui est communément admis quand on parle de ciblage publicitaire, c'est l'affichage de publicités en fonction de données récoltées auprès de l'utilisateur (historique de navigation). Ça implique et justifie la récolte de données afin de profiler l'utilisateur, je trouve ça malsain.
On ne parle pas d'un ciblage en fonction du support (genre de la publicité pour des PC sur un forum informatique) qui pose moins de soucis.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: C'est rigolo...
Posté par Misc (site web personnel) . Évalué à -1.
Tu parles d'un point de vue d'un site plus ou moins amateur (ou plutôt devrais je dire "sans avoir une tonne de moyen pour la publicité").
Mais par exemple, les chaînes de télés utilisent aussi des segmentations basé sur les données, et produisent des émissions pour cibler des publics spécifiques. Les stations de radio font des pubs locales (via la magie des antennes sur tout le territoire),
Et c'est fait aussi en récoltant des données pour cibler ce qui n'est pas moins malsain que ce que ferait Google ou Facebook au final.
Donc je vois pas en quoi ça pose moins de souci, à part si on pense qu'il y a moins de ciblage (car c'est pas sur la même échelle de temps), ou parce qu'on pense que la télévision est resté aux technos des années 1980.
[^] # Re: C'est rigolo...
Posté par Thomas Douillard . Évalué à 6.
Oui mais si tu réponds à un sondage pour savoir ce les gens de ton age / sexe / que sais-je regardent à la télé ils ne conservent pas en général ton nom associé à tes données, ils utilisent simplement les données agrégées. Et la pub ne change pas si c’est toi ou ta frangine qui regardent ta télé.
C’est « on pense généralement que les gens avec tel type de profil regardent cette émission, on place des publicité qui pourraient parler à ce type de profil ». Pas du tout « On sait que tu es en train de regarder cette émission, on connait ton profil parce qu’on a plein d’infos sur toi, par conséquent on te propose des pubs similaires aux produits que tu as regardé sur Amazon dernièrement » ou un test de grossesse pour ta frangine parce qu’on sait pas trop pourquoi …
[^] # Re: C'est rigolo...
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 9.
Elle ne te pose même pas de questions en fait, elle te dit "Le respect de votre vie privée est notre priorité", et te fait faire trois clics derrière des mentions équivoques ("Personnaliser") et un anti-pattern (ça fait quoi si j'oublie de cliquer sur "Enregistrer" après avoir cliqué sur "Tout refuser" ?) pour refuser les cookies traceurs. On peut faire un peu moins trompeur que ça, à mon avis.
[^] # Re: C'est rigolo...
Posté par aiolos . Évalué à 10. Dernière modification le 04 février 2022 à 17:02.
Et en plus, elle la pose sous une forme qui a déjà valu à Google et Facebook une condamnation : pour accepter tout, il suffit d'un clic, pour refuser tout, il faut aller dans configurer d'abord !
[^] # Re: C'est rigolo...
Posté par Misc (site web personnel) . Évalué à 10.
Si seulement on avait un mécanisme directement dans les navigateurs pour dire de refuser le tracking.
Par exemple, un entête HTTP JeRefuseLeTracking. En plus, ça changerais d'avoir du français pour une fois.
[^] # Re: C'est rigolo...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -3.
Ça existe déjà l'entête DNT et c'est actif chez moi. Mais « il n'y a pas d'obligation légale d'utiliser la fonction “ Do Not Track ”. Les sites web et les publicitaires peuvent décider eux-mêmes de se conformer ou non aux exigences du DNT. » on me souffle dans l'oreillette
Ceci dit, la problématique n'est normalement pas la même que les cookies…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: C'est rigolo...
Posté par mansuetus (site web personnel) . Évalué à 4.
En tant qu'utilisateur, j'avoue être passablement agacé lorsque je vous un site qui me colle une alerte JS qui me signale que mon DNT sera honoré.
Agacé parce que je DEVRAIS être content, mais ça me fait un clic de plus.
Au final, je clique sur accepter tout, mais j'ai firefox en mode << efface toutes les données de navigation chaque fermeture >>. C'est mon choix le plus efficace, et ça aide pour mon acuité dans les shoot'em'up.
[^] # Re: C'est rigolo...
Posté par GG (site web personnel) . Évalué à 3.
Apparemment la condamnation ne suffit pas. (de ce que j'ai vu pour Google)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: C'est rigolo...
Posté par aiolos . Évalué à 2.
De mémoire, ils sont encore dans le délais pour se mettre en conformité.
# Ad nauseam
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
En ce qui me concerne je n’ai jamais trop vu la pub. Ça ne me gêne guère. Mais depuis un moment je test l’extension ad nauseam. C’est amusant de penser qu’un script se charge de m’établir un profil personnaliser aléatoire dans les bases de données d’officine publicitaires. Peut être qu’une utilisation plus large de ce genre d’outil réduirait l’intérêt d’essayer de pister l’utilisateur à l’aide de cookies ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . Évalué à 7. Dernière modification le 04 février 2022 à 20:58.
Si on lit le délibéré de la sanction, c’est bien plus que la publicité en ligne qui est mise à mal pour le coup. C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS…
En TLDR (mais IANAL hein…), c’est essentiellement la notion même de « responsable de traitement » du RGPD qui a été étudié, en particulier dans le cas d’une sous-traitance.
Si on lit les considérants, en particulier à partir du 326-341, il devient vraiment assez difficile d’être sous-traitant dans une relation commerciale, et on endosse la responsabilité du traitement très très rapidement. Dès qu’on décide d’une modalité (326), dès qu’on vend/loue son produit (328), dès qu’on a décidé d’une orientation (330), en gros dès qu’on a développé une solution informatique (341), et ce y compris si on n’a pas accès directement aux données à caractère personnel (327), on est co-responsable avec son client de tous les traitements. Y compris des usages de son client du coup.
En pratique ça devient du coup très difficile pour une entreprise de pouvoir recourir à un sous-traitant, qui n’a aucune raison d’accepter cette responsabilité, en tout cas pas sans la faire payer, et à un coût qui risque fort d’être prohibitif…
La porte ouverte à l’obligation légale d’arrêter la sous-traitance pour n’autoriser que au mieux du on-premise assez drastique et à contraindre les entreprises à reprendre le contrôle de leur système, ouvrant la voie royale au libre et à l’auto-hébergement ? Peut-être bien ! 😊
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Benjamin Henrion (site web personnel) . Évalué à 2.
"C’est extrêmement violent, plus ou moins du même niveau que l’arrêt Schrems II qui invalide tout service US… Ça remet en question complètement l’usage voire l’existence même du SaaS"
Tu peux avoir un logiciel SaaS hébergé en Europe par une société européenne.
Pour l'instant, les gros fournisseurs américains de SaaS et de cloud ignorent ou essaient de contourner la décision.
Il faudra un bout de temps pour renvoyer les ricains chez eux.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . Évalué à 3. Dernière modification le 05 février 2022 à 22:21.
Non justement. La décision prise envers l’IAB Europe s’applique également aux SaaS européen du coup.
Il n’y a de toute façon pas de notion de localisation des services dans le délibéré, uniquement de responsable de traitement contre sous-traitant. Une boîte EU hébergeant un service SaaS EU est du coup tout aussi dans la mouise.
Après ça va certainement mettre du temps à percoler avec d’autres condamnations arrivants à des sanctions pour ce même motif, mais c’est ce que j’entrevois entre les lignes du délibéré.
Schrems II a éradiqué les US. Panoptikon a éradiqué le SaaS.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Je ne partage pas ta lecture de cette décision.
On peut comprendre ta phrase comme étant dès que l'on fait A ou dès que l'on fait B ou dès que l'on fait C, alors on est automatiquement caractérisé comme co-responsable de traitement. Alors, que pour moi, IAB Europe a voulu se défendre en indiquant qu'ils fournissaient des spécifications techniques et des documents de politiques (policies), un peu comme l'IETF pourrait le faire pour spécifier HTTP et les cookies, et l'APD vient démontrer que la position d'IAB Europe est bien large que ça et qu'elle recouvre ET les critères de A, de B et de C.
Le point 331 montre l'importance de la détermination des finalités de traitement pour désigner un responsable de traitement. Or, je ne pense pas que tous les services SaaS déterminent eux-mêmes les finalités pour leurs clients. Si un service fournit un chatbot, il peut servir pour des finalités commerciales, ou du support, ou d'autres raisons, et c'est au client de ce service de définir la finalité pour laquelle il compte utiliser le services en question.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . Évalué à 1. Dernière modification le 07 février 2022 à 11:22.
Tout à fait, ils fournissent un service « as is » et ce qu’en fait le client est effectivement de sa propre responsabilité.
Mais ils ont aussi fait LEURS propres choix (techniques, infras…), le soft est souvent fournis avec d’autres fonctionnalités qui ne sont pas directement une demande du client (debug & maintenance, au moins, voir ici l’IAPD des Pays-Bas sur ce sujet pour Microsoft Office 365, § 16.2.4 Microsoft does not act as a data processor), ce qui fait qu’ils en deviennent de fait un co-responsable de traitement.
Au final on a 3 bouts distincts : les parties à la charge stricte du client (faire du support sur le chatbot), les parties à la charge stricte du prestataire (maintenance, debug…) mais un gros bout en co-responsabilité de traitement qui représente l’essentiel des finalités (vu que le presta a quasi tout développé de sa propre initiative, donc a minima choisi les moyens).
Pour le cas du ET ou du OU entre les 3 clauses, ici l’APD a fait son taff en pointant tous les manquements, mais le texte est clair : c’est bien finalité OU moyens. Et il me semble qu’il existe une ligne directrice EDPB qui formalise justement cette compréhension du OU, je vais la rechercher :)
C’était le taff de l’APD d’aligner le plus de non-conformités possibles pour estimer l’amende à la fin. Ils ont condamné pour l’ensemble de l’œuvre, mais ils auraient pu condamner juste avec un seul chapitre.
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Encore une fois, je pense que tu généralises un cas particulier sans que ça ne me paraisse très clair que ce soit vraiment généralisable. Dans la partie 5, l'IAPD fait valoir de nombreux arguments pour justifier que Microsoft n'est pas qu'un data contractor :
Globalement, ce qui ressort, c'est que Microsoft empêche son client de pouvoir jouer son rôle de contrôle, et que du coup, il ne peut pas être qualifié de data processor. Mais je ne pense pas que l'on puisse étendre ça à tous les SaaS.
Le point 331 dit pourtant :
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 07 février 2022 à 15:58.
Oui, mais justement. Définir les finalités implique être responsable de traitement. Ça c’est clair net et précis.
Mais l’inverse n’est pas vrai : ne pas définir les finalités n’impliquent pas de ne pas être responsable, il reste encore au moins à étudier la définition des moyens. D’autant plus que l’un des 2 soit responsable de traitement n’empêche pas l’autre de pouvoir l’être (co-responsable de traitement). Et que, y compris pour une même donnée, le statut de processeur de données n’est pas exclusif d’être aussi responsable de traitement.
C’est aussi plutôt visible dans les lignes directrices EDPB.
Le 1er diagramme de la page 46 évacue rapidement les cas où tu es responsable de traitement de manière évidente (tu as dis ou écris que tu l’étais ou une loi t’y contraint).
On arrive sur « tu fais quoi en pratique ». Les 2 portes de sortie « data processor » implique « decision based on general security objective set by the other party » et « solely in accordance with its instruction ».
Dans le cas du SaaS, c’est pas évident parce que le logiciel existait déjà avant la conclusion du contrat, donc les décisions ayant été prises sans lui, le cas « 2- solely » est difficile à défendre. Et pour le cas « 1- set by the other party », le mécanisme de décision est au mieux inversé. On part de finalité et de moyens déjà offerts par un logiciel existant et on s’arrange pour faire matcher les objectifs du client avec les possibilités (« oh vous conservez 6 mois chez vous ? On aurait plutôt dit 3, mais aller, on va marquer 6, ça nous va aussi mais on est bien d’accord qu’on n’écrit ça nul part hein » ou autre « ah zut, vous fait machin-truc pour votre maintenance ? Bon, on va l’indiquer aussi chez nous et on en prend la DC et on vous dit DP »).
L’arrangement est au final un jeu de dupe, on change le registre de traitement du client avec les possibilités du logiciel SaaS plutôt que d’arranger le logiciel SaaS pour coller avec le registre de traitement.
Sur un contrôle APD, ça ferait quand même vachement mauvaise foi d’avoir trouver un presta 100% conforme à tes exigences alors qu’il existait depuis 10 ans et n’a pas fait de développement spécifique notable pour toi.
Surtout que l’objectif de ce jeu de dupe est clair : éviter la responsabilité de traitement du prestataire (qu’il préférerait ne pas assumer ou te le fera payer, cf Microsoft & IAB), éviter de devoir aller voir ailleurs, et en plus risquer de devoir constater qu’il n’existe pas d’offre SaaS correspondant strictement aux besoins et donc de devoir investir dans un développement de produit ad-hoc ou on-premise (cher, long, etc).
En pratique sur un produit SaaS, on devrait donc plutôt sortir sur 4.1 « you are the controller ». Ce qui ne serait pas/moins vrai pour un logiciel à façon du coup, développé spécifiquement pour tes besoins propres (quitte à partir d’une base SaaS existante), ou on-premise où tu gères assez finement ton paramétrage et tes accès, et où tu sortirais en 4.2/4.3.
Sur toutes les finalités offertes par un logiciel SaaS, la proba d’avoir du 100% « data processor » est quand même faible… En pratique, on va avoir :
- « client DC, presta DP » sur peu de finalité : celles spécifiquement créées par le client à partir du logiciel en SaaS et dont le presta se fout un peu (« gérer le service client via un chatbot », « réserver un billet de train via un chatbot »…)
- « client/presta co-DC » sur un petit bout : toutes les finalités existantes dans le produit avant l’arrivée du nouveau client et correspondant à 100% à un besoin précis de ce client avant le choix du prestataire (« conserver un historique des échanges », « répondre à une demande d’accès RGPD »).
- « presta DC » pour le reste : toutes celles existantes dans le produit avant l’arrivée du nouveau client et ne correspondant pas à un besoin précis à 100% du client avant le choix du prestataire (« maintenir la plateforme », « offrir du support à mes clients », « obtenir des stats/KPI de ma plateforme »). Pour moi ça risque d’être ça le très gros du paquet.
J’ai même des cas assez chiants à faire rentrer dans les cases…
Quid d’une analyse côté client qui montre un besoin de rétention d’historique à 3 mois côté client quand la seule possibilité côté SaaS est de le faire à 6 mois ? Tu vas quand même chez ton prestataire en violant ton propre registre de traitement ? 🤔
Ton analyse dit 6 mois mais le SaaS fait 3 mois. Tu revois ton analyse à 3 mois en reconnaissant avoir mal fait ton boulot de minimisation dans l’analyse préliminaire vu qu’a priori c’était nécessaire de conserver 6 mois minimum ? 🤔
En théorie tu es supposé aller voir ailleurs dans les 2 cas du coup… 🤷
Et si tu trouves un presta SaaS capable d’adapter son soft existant et ses paramétrages à tes propres besoins de conformité sans toucher à ceux de ses autres clients (par exemple garantir cette suppression à 3 mois pour un client et à 6 mois pour les autres, ou désactiver toute télémétrie et acte de maintenance pour l’un mais pas pour l’autre, ou virer de stats de KPI tout ce qui est généré par les usages d’un client donné), je doute que le tarif soit si intéressant que ça par rapport à un développement à façon… On serait rapidement plus proche en pratique au moins du on-premise, ou à des usines à gaz type SAP… 🤔
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Je ne dis pas que tu as forcément tord, je dis juste que tu mélanges ton opinion avec des faits avérés. Les 2 décisions que tu as citées ne permettent pas à elles-seules d'affirmer la remise en cause de l'existence des services SaaS.
Pour moi, les services SaaS sont dans une zone floue, sujette à l’interprétation du RGPD par la CNIL et ses consœurs. J'ai tendance à penser que tant que les services SaaS ne cherchent pas à définir les finalités, et offrent à leurs clients un certain contrôle, ils vont pouvoir rester data processor (mais la ligne peut être rapidement franchie).
Note également que le paragraphe 28 des lignes directrices EDPB dit :
Pour moi, ça indique bien qu'un SaaS avec un service pré-existant peut quand même être un data processor (sous certaines conditions).
[^] # Re: Jurisprudence pour l’obligation d’auto-hébergement ?
Posté par Aeris (site web personnel) . Évalué à 3.
La différence est grande entre une opinion (ce que je souhaiterais) et une analyse jurisprudentielle (les orientations que prennent les condamnations) :D
Là il se trouve que la tendance des condamnations me va plutôt bien, mais ça aurait pu ne pas être le cas et ça aurait été tout aussi intéressant à étudier.
Aligné, ça reste(rait) possible, mais les conditions ont l’air tellement minces qu’en pratique tu as plutôt intérêt à envisager autre chose (self-hosting ou au moins on premise) qui coûtera moins cher et sera moins complexe administrativement parlant.
Les requalifications de DP en DC sont quand même vachement nombreuses et avec des cas où je n’aurai même pas parié un kopec dessus à l’origine (typiquement celle de l’IAB, certains considérants me semblent complètement hallucinants, comme 328 par exemple…).
Et dans les lignes EDPB, le « a detailed description » me semble assez hors de portée d’une relation de sous-traitance conventionnelle en tout cas telle qu’envisagée en 2022…
Tu dois littéralement collé au cul de ton sous-traitant pour connaître l’intégralité de tous ses petits secrets… à date et surtout sur toute la durée de la prestation. Avec côté sous-traitant de sacrées restrictions dont on n’a(vait) pas l’habitude aujourd’hui (peu de liberté d’innovation, pas de gestion/évolution de son propre produit, en tout cas pas sans accord de tous ces clients, etc).
Ça me semble vachement changer des relations de sous-traitances telles qu’on les connaît aujourd’hui.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.