Greboca  

Suport technique et veille technologique

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

Blog : NullPointerException  -  Le RGPD en 10 minutes (ou un peu plus) [2/5]

 -  Novembre 2022 - 


Disclaimer:
Le texte qui va suivre n’est PAS une analyse juridique et ne doit certainement pas être considéré comme un conseil juridique. Je ne suis PAS juriste mais uniquement un citoyen éclairé qui (essaie de) faire respecter ses droits au quotidien. Ce texte fait volontairement des raccourcis et omet des points de détails pour rester concis mais ces raccourcis ne changent pas la teneur du texte pour le cas général standard de 99.99% des lecteurs ici.
Dans tous les cas, analysez votre situation. Ne le prenez pas pour argent comptant et n’hésitez pas à vous faire votre propre avis sur le sujet.


Dans l’épisode précédent, j’ai présenté un peu le contexte historique du RGPD. Passons maintenant aux choses sérieuses et commençons par voir qui exactement est concerné par ce texte.

Du périmètre

De par son article 2 et 3, le RGPD s’applique à toute entité manipulant des données personnelles à partir du moment où elles concernent un Européen.

Que vous soyez une entreprise, une association ou un particulier, que vous agissez à but lucratif ou non, que vous soyez domicilié en Europe ou non, vous devez respecter le RGPD. Point. Les 2 seules exceptions sont l’usage strictement domestique (article 2(2)c) ou si votre entreprise non européenne traitent des données d’Européens à titre accidentel (APD/GBA (Belgium) - 161/2022) .

L’usage strictement domestique doit être strictement domestique (sic). Un carnet de contact contenant des données professionnelles ne l’est pas. Un particulier louant son domicile ne l’est pas. Opérer un réseau social non plus. La jurisprudence est très sévère sur ce critère.

Au quotidien, je ne compte plus les entreprises ou autres qui refusent de se considérer comme couvertes par le RGPD pour des motifs complètement délirants même pas inscrits dans le RGPD… « Je ne suis pas à but lucratif » (un cabinet d’avocats), « Je ne revend pas vos données » (une boîte de com’) ou plus naïvement « Mais je n’en fais rien de mal » (un prestataire cloud)… 😑

Des données personnelles

Qu’est-ce qu’une donnée à caractère personnel (DCP, ou Personally Identifiable Information (PII) en anglais) du coup ? Très simple, c’est défini à l’article 4(1) :

« données à caractère personnel » : toute information se rapportant à une personne physique identifiée ou identifiable (ci-après dénommée « personne concernée »); est réputée être une « personne physique identifiable » une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu’un nom, un numéro d’identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale;

Autant vous dire que ça ratisse large. Très large. Vraiment très large.
Le triplet « genre / âge / ville » est-il une donnée personnelle ? Oui. 87% de réidentification. Avec Éric on avait fait un petit jeu pour classer des données en personnel ou non personnel. À la fin c’était assez clair : tout était DCP.

En pratique pourtant, tout le monde utilise des arguments de très mauvaise foi pour justifier qu’une donnée n’est pas une DCP.

Le RGPD dit bien identifiable et non identifiante ou identifiée. La différence existe bien entre ces 3 termes, par exemple dans le cas d’une étude clinique. Le numéro patient de l’étude est identifiant pour l’agence de santé en charge de l’étude (les ARS peuvent remonter au numéro de Sécu du patient). Ce même numéro est seulement identifiable pour les médecins menants l’étude (eux ne peuvent pas remonter au numéro de Sécu mais savent qu’il correspond bien à ce patient précis). Le numéro de Sécu associé à ce numéro patient est identifié pour l’ARS. Mais dans les 3 cas il s’agit bien d’une DCP au sens RGPD du terme et aucun n’échappe à ce texte : le médecin, la clinique, l’ARS et la Sécu doivent appliquer le RGPD.

Ce n’est pas non plus parce qu’une donnée est non nominative qu’elle ne peut pas être une DCP. Par exemple un numéro de client reste une DCP même si on n’a pas immédiatement le nom et le prénom de la personne concernée.
La différence n’existe pas non plus à ce niveau entre une donnée identifiante (le numéro de client) et identifiable (le triplet genre/âge/ville). RGPD complet dans les 2 cas.

La jurisprudence est aussi claire (et directement de la CJUE, excusez du peu) sur le sujet : le moyen de réidentification n’a même pas besoin d’être détenu par le responsable de traitement, il suffit qu’il existe quelque part sur Terre. C’est comme ça qu’une adresse IP ou une plaque minéralogique restent des DCP même si vous n’avez aucun moyen de remonter à la personne concernée sans faire appel respectivement à son fournisseur d’accès ou à la préfecture de police.

Ce dernier cas est d’ailleurs une parfaite illustration du problème de la lettre et de l’esprit de la loi : il avait été acté dès 2007 par EDPB (WP29 à l’époque) dans ses lignes directrices WP 136 Opinion 4/2007 s’appuyant elles-même sur des textes de 1995 (directive 95/46/EC), mais il aura fallu aller jusque devant la CJUE en 2016, après quasiment 2 ans de procédures pour le faire à nouveau reconnaître… Minimum 9 ans si ce n’est 21 de perdus pour une évidence… Et certains persistent toujours à le nier…

C’est aussi cette non distinction identifiée/identifiante/identifiable qui fait qu’un hash est de la pseudonymisation et non de l’anonymisation et qu’à ce titre un hash d’une DCP reste une DCP et que donc l’intégralité du RGPD reste applicable sur la nouvelle donnée obtenue.
Les procédures de réelle anonymisation (randomisation ou généralisation) sont actuellement inutilisées si ce n’est inconnues par les entreprises. Pire, les études scientifiques sur le sujet tendent à démontrer que l’anonymisation réelle est trop souvent impossible, en tout cas pas sans perdre tout intérêt aux données anonymes obtenues à la fin.

Pour résumer simplement : considérez toute donnée comme une DCP (vous avez plus de chance que ce soit le cas que l’inverse) et oubliez la notion d’anonymisation (vous êtes très certainement en train de parler uniquement de pseudonymisation).

Du traitement de DCP

Autre définition très importante du RGPD : la notion de traitement d’une DCP. On la trouve à l’article 4(2):

« traitement », toute opération ou tout ensemble d’opérations effectuées ou non à l’aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel, telles que la collecte, l’enregistrement, l’organisation, la structuration, la conservation, l’adaptation ou la modification, l’extraction, la consultation, l’utilisation, la communication par transmission, la diffusion ou toute autre forme de mise à disposition, le rapprochement ou l’interconnexion, la limitation, l’effacement ou la destruction

Le telles que montre que cette liste à la Prévert n’est ni exhaustive ni restrictive.

Comme pour la définition de DCP, beaucoup de monde a tenté de se justifier que ce qu’il faisait n’était pas un traitement de DCP, avec des arguments guère plus recevables… « Le RGPD ne s’applique qu’aux traitements informatiques » (cabinet d’avocats), « Le RGPD ne s’applique qu’au numérique et pas au papier » (une agence immobilière, et ça c’est ePrivacy, en cours de négociation au niveau européen), « On ne traite pas, on ne fait que stocker » (un databroker).

On va du coup résumer ça tout aussi simplement ici : en pratique, l’intégralité de ce que vous faites au quotidien relève du traitement de DCP au sens du RGPD.

Et donc au prochain épisode, nous verrons du coup quelles obligations découlent du fait que vous êtes concernés par le RPGD.

Épisode 1Épisode 2Épisode 3Épisode 4Épisode 5

par

Blog : NullPointerException

Blog d’un groupe crypto-terroriste individuel auto-radicalisé sur l’Internet digital

Le RGPD en 10 minutes (ou un peu plus) [5/5]

 -  Décembre 2022 - 

Après les 4 articles précédents posant les bases de ce que devrait être le respect du RGPD, une analyse plus personnelle du problème pour répondre à (...)


Le RGPD en 10 minutes (ou un peu plus) [4/5]

 -  Novembre 2022 - 

Disclaimer:Le texte qui va suivre n’est PAS une analyse juridique et ne doit certainement pas être considéré comme un conseil juridique. Je ne suis (...)


Le RGPD en 10 minutes (ou un peu plus) [3/5]

 -  Novembre 2022 - 

Disclaimer:Le texte qui va suivre n’est PAS une analyse juridique et ne doit certainement pas être considéré comme un conseil juridique. Je ne suis (...)


Le RGPD en 10 minutes (ou un peu plus) [1/5]

 -  Novembre 2022 - 

Disclaimer:Le texte qui va suivre n’est PAS une analyse juridique et ne doit certainement pas être considéré comme un conseil juridique. Je ne suis (...)


Déploiement d’un projet Ruby-on-Rails

 -  Juin 2020 - 

Un petit article mémo technique sur comment déployer un projet Ruby-on-Rails. Installation de RubyLe principal problème est que Ruby est mal (...)