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.

La suite du petit voyage dans le doux monde du RGPD. Aujourd’hui, la partie plus organisationnelle de votre conformité.

De la « privacy by design »

L’article 25 du RGPD impose la prise en compte de la protection des données dès l’étape de conception d’un nouveau traitement de données.

Cela veut dire que dès l’étape d’avant-projet, avant même la réalisation de la moindre ligne de code, il est nécessaire de se poser les bonnes questions et de commencer à réfléchir en mode « IAPD light ».
Quelles sont les finalités visées par ce traitement ? Quelle durée de rétention sur les données ? Quelle base légale va être utilisée ? N’existerait-il pas une manière de faire qui soit plus respectueuse de la vie privée de la personne concernée ? Ne pourrait-on pas remplir le même objectif mais avec moins de données ?
Et c’est aussi le moment de réfléchir aux moyens de protection, comme la mise en place de chiffrement, les restrictions d’accès ou les moyens de journalisation.

Ici en pratique ce type de question arrive bien trop souvent bien trop tard dans la boucle. En avant-projet, on ne trouve que des équipes commerciales livrées à elles-mêmes et en conflit d’intérêt direct. Une fois le contrat signé, les développeurs aussi peu sensibilisés se retrouvent mis au pied du mur sur des délais et des budgets n’incluant pas les briques essentielles à une mise en conformité. Et quand l’équipe conformité arrive après coup, c’est toute l’application qui est à repenser si ce n’est carrément à interdire…
Les différentes instances comme la CNIL ou l’ANSSI sont de plus formelles sur ce sujet : la conformité RGPD ne peut que difficilement être intégrée après coup sur un outil pas du tout adapté pour dès l’origine. C’est trop cher, trop coûteux, trop complexe.

Du délégué à la protection des données

L’article 37 impose la nomination d’un Data Protection Officer (DPD, Délégué à la Protection des Données en français) dans certains cas :

• Vous êtes une autorité ou une entité publique
• Vous effectuez des traitements à grande échelle ou en suivi systématique
• Vous traitez des données sensibles à grande échelle

L’article 38 définit les modalites de mise-en-œuvre d’un DPO. Votre DPO ne doit pas être en conflit d’intérêt sur le sujet de la protection des données personnelles, donc pas un représentant de l’entreprise ni une personne décidant des traitements à réaliser ou des moyens à mettre en œuvre (38(6)). Il doit être autonome et n’a de compte à rendre qu’à la plus haute instance dirigeante de l’entreprise (généralement le comité de direction) (38(3)). L’entreprise doit lui fournir les moyens de faire son travail correctement (38(2)), comme lui alloué son propre budget ou lui libérer suffisamment de temps pour remplir ses obligations. Et il est salarié protégé. Il est aussi supposé être mis dans la boucle dès l’avant-projet sur tout nouveau traitement à réaliser, en particulier pour respecter les obligations de l’article 25 vu précédemment.
Les lignes directrices WP243 (30 pages) éclaircissent encore une fois les modalités autour de ce poste. De la même manière que pour les IAPD, relisez bien les directives autour du traitement à grande échelle ou systématique, le concept est tout sauf naïf…

Le DPO est en quelque sorte au sein de l’entreprise la voix des personnes concernées par le traitement de données personnelles, le contre-pouvoir à la direction pour prendre les décisions adéquates. Sans lui, il serait assez certain que seuls les intérêts de l’entreprise seraient pris en compte. Cela est particulièrement visible dans les obligations autour des IAPD, en particulier le logiciel PIA de la CNIL, où le DPO doit rendre son avis au même moment que le représentant des personnes concernées.

Sur le sujet de la nomination d’un DPO, les entreprises traînent aussi beaucoup des pieds et font beaucoup des mains pour s’éviter la présence d’un DPO dans leurs équipes. Ou en choisissent un de complaisance qui mangera dans la main de la direction. Forcément, un électron libre qui a plus ou moins tout pouvoir sans avoir à rendre de compte à personne et en capacité de s’opposer à plein de trucs, ça gêne. Beaucoup.
Les APD en arrivent aujourd’hui à devoir sanctionner les entreprises sur ce sujet, par exemple celles n’allouant pas un DPO à temps plein, ou ne l’invitant pas à toutes les réunions voire carrément pour interdire le licenciement d’un DPO un peu trop génant.
Le métier de DPO est lui-même sous surveillance, les conditions de travail pouvant être difficiles, 40% des DPO ayant vécus des situations de souffrance au travail et 20% s’estimant être souvent en situation de stress.

Des droits des personnes concernées

Certainement le morceau le plus intéressant, en particulier pour les personnes concernées mais qui a de lourdes implications sur les process internes des responsables de traitement.

On va commencer par les plus simples.

L’article 16 définit le droit de rectification, qui n’est ni plus ni moins que l’obligation faite au responsable de traitement de conserver à jour en permanence les données qu’il traite. Et donc que la personne concernée peut en demander la modification.
Ça n’a l’air de rien dit comme ça, mais c’est cet article par exemple qui a conduit une banque à être condamnée pour ne pas avoir une base de données capable de supporter les majuscules accentuées. La modification du système d’information de la banque a été estimée à plusieurs mois de travail.

L’article 17 définit lui le droit de suppression. La suppression peut venir de plusieurs facteurs, de l’obsolescence des données ou du traitement (17(1)a, dans la droite ligne de l’obligation de minimisation et de durée de rétention), du retrait du consentement (17(1)b, oui, si l’utilisateur retire son consentement, vous devez supprimer toutes les données collectées auparavant 😊), idem lors de l’exécution du droit d’opposition (17(1)c), si le traitement est déclaré illicite (17(1)d, et ça peut être sanglant, comme devoir purger l’intégralité de sa base de données cliente 🤣 (je mettrais ici la condamnation si je la retrouve))…

Plus difficile, l’article 15, certainement mon petit chouchou, impose au responsable de traitement de divulguer plus ou moins l’intégralité de tout ce qui est connue sur une personne, ainsi que tout le rationnel autour du choix de la base légale retenue, des durées de rétention, les destinataires des données, l’origine des données si ce n’est pas l’utilisateur qui vous les a données directement… En très résumé ça revient à devoir lui transmettre toutes les données, votre registre de traitement et vos IAPD…
En règle générale les entreprises n’arrivent pas à répondre correctement à une demande d’accès, elles se contentent trop souvent d’un export CRM en pensant être bon, en oubliant toutes les données marketing ou KPI, les logs d’accès, les trackers type ouverture d’email, les suivis d’audience… Faute de registre de traitement à jour, elles ne savent de toute façon même pas où sont les données en pratique et ce qui en est réellement fait.
Sur la liste des destinataires ou autres, elles se réfugient derrière la protection de leurs secrets industriels pour ne pas avoir à la transmettre, quand elles ne savent tout simplement pas à qui elles refourgent les données, passant par les databrokers qui s’occupent ensuite de revendre les données pour elles.

Pour finir, le mode hardcore et l’article 21 instituant le droit d’opposition consistant à permettre à toute personne concernée par un traitement fondé sur la base légale de l’intérêt légitime de s’opposer au traitement pour des raisons strictement personnelles. Le responsable du traitement doit alors complètement suspendre les traitements liés à cette finalité, sauf à démontrer qu’il a des raisons légitimes et impérieuses à continuer. C’est en particulier valable pour toutes les finalités de prospection (21(2)) où l’utilisateur doit être immédiatement informé de ce droit dès la première prise de contact (et pour rappel pour le démarchage par email en B2C, c’est le régime strict du consentement qui prévaut).

L’ensemble de ces droits (et je n’ai pas parlé d’autres droits plus accessoires, comme l’article 18 sur la restriction de traitement ou le 20 sur la portabilité) doit être exécuté au plus tôt et au maximum sous 1 mois (article 12(3)) à réception de la demande, prolongeable 2 mois de plus en cas de demande complexe.
Non, vos périodes de congés en entreprise ne sont pas une justification à un éventuel retard. N’utilisez pas non plus l’excuse d’une demande complexe pour gratter 2 mois supplémentaires alors que vous n’avez juste pas les moyens de répondre à une quelconque demande d’accès dans les délais légaux, votre non conformité RGPD ne sera jamais un argument recevable à commettre une nouvelle non conformité.

De pourquoi le RGPD en 10 minutes alors que ça fait 2h que vous êtes ici

Je n’ai fait ici qu’effleurer le problème, il y aurait encore tant à dire sur le RGPD, comme la distinction à faire entre responsable de traitement et processeur de traitement, les obligations liées à la sous-traitance (comment ça vous ne savez pas exactement ce que fait votre sous-traitant avec vos données).
Aussi je vais conclure en résumant comment se mettre en conformité avec le RGPD en 10 minutes.

• Quasiment toutes vos données sont des données personnelles.
• Ne cherchez pas à vous en dédouanner, vous êtes soumis au RGPD.
• Nommez un DPO, dotez-le correctement et écoutez-le.
• Faites avec lui des IAPD « light » pour tous vos traitements.
• Considérez le consentement comme la base légale par défaut et la nécessité au contrat ou l’intérêt légitime comme repli éventuel. Pas l’inverse.
• Minimisez le périmètre des données collectées, qui doivent avoir une nécessité réelle et immédiate. Une donnée non nécessaire ne doit pas être collectée.
• Rédigez un registre de traitement (finalité, base légale, durée de rétention)
• Rédigez une privacy policy pour l’expliquer simplement à vos utilisateurs. Soyez transparent et honnête avec eux.
• Si vous vous sentez mal à l’idée de devoir dire à vos clients que vous réalisez un traitement, il est très certainement illicite, supprimez-le.
• Intégrez votre conformité à tous les étages, et au plus tôt.
• Automatisez vos réponses aux demandes au titre des articles 15 à 22.

On pourrait finalement résumer ça encore plus facilement en « Ne soyez pas un connard » !

Dans le dernier épisode bonus, nous verrons pourquoi la conformité est si difficile en pratique et ce que peut bien faire notre autorité de protection des données nationale…

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