Le RGPD a introduit de nouveaux concepts intéressants afin d’assurer la protection des données personnelles, dont un qui est la notion de “privacy by design”. En fait pour être totalement exact, il faut distinguer deux choses derrière cette notion : l’idée de “privacy by design” et l’idée de “privacy by default”. Ces concepts nous viennent de la Commissaire de l’agence canadienne de protection des données personnelles (Dr. Anne Cavoukian) qui a développé une série de principes en 2010 tendant à prendre en compte la vie privée dès la conception des systèmes de traitement. Le RGPD a repris cette idée, mais sous un angle assez spécifique. On verra donc ces notions en détail (I) avant de voir la place que leur réserve le RGPD et les obligations légales qui sont en vigueur (II).
I - Qu’est-ce que le privacy by design ?
Le principe est assez simple : le privacy by design est l’idée que l’on doit prendre en compte la protection de la vie privée au moment même de la conception d’un système d’information. Pour prendre un exemple, pour un fabricant d’ordinateurs portables - comme Apple - c’est l’idée que l’entreprise doit penser à chiffrer les disques durs des portables qui sont mis en vente, car il est possible que les utilisateurs de ces portables conservent des données personnelles dessus ; et en cas de perte, ou de vol, le chiffrement du disque dur permettra de préserver la confidentialité des données. En clair, cela signifie que les concepteurs de systèmes d’information doivent prévoir des mesures de protection réelles pour protéger les données personnelles traitées par leurs utilisateurs.
Cette notion se distingue du “privacy by default” qui est l’idée que - si des mesures de protection existent - et qu’elles ont bien été prévues par le fabriquant, celles-ci devront être activées par défaut. Dans le cas d’Apple précité, c’est l’idée que la case “chiffrer les données de mon disque dur” soit bien cochée par défaut, dès la livraison de l’ordinateur portable, et cela afin d’éviter de demander aux utilisateurs un effort supplémentaire qui n’est pas systématiquement réalisé.
Voici donc les deux concepts essentiels, mais le document écrit en 2010 reprenait en fait plus largement 7 principes :
- “Proactive not reactive—preventative not remedial. Anticipate, identify, and prevent invasive events before they happen; this means taking action before the fact, not afterward.”
- “Lead with privacy as the default setting - Ensure personal data is automatically protected in all IT systems or business practices, with no added action required by any individual.”
- “Embed privacy into design - Privacy measures should not be add-ons, but fully integrated components of the system.”
- “Retain full functionality (positive-sum, not zero-sum) - Privacy by Design employs a “win-win” approach to all legitimate system design goals; that is, both privacy and security are important, and no unnecessary trade-offs need to be made to achieve both.”
- “Ensure end-to-end security - Data lifecycle security means all data should be securely retained as needed and destroyed when no longer needed.”
- “Maintain visibility and transparency—keep it open - Assure stakeholders that business practices and technologies are operating according to objectives and subject to independent verification.”
- “Respect user privacy—keep it user-centric - Keep things user-centric; individual privacy interests must be supported by strong privacy defaults, appropriate notice, and user-friendly options.”
En résumé voici les règles à prendre en compte lors de la conception d’un système d’information (telles que décrites par l’agence canadienne de protection des données en 2010 - celles-ci n’ont pas de valeur juridique en Europe, voir la partie II sur ce point):
- Anticiper les risques relatifs à la vie privée
- Activer toutes les options protectrices de la vie privée par défaut
- Prévoir la vie privée comme une fonction centrale de tout SI
- Ne pas limiter les fonctionnalités du système en contrepartie d’une protection de la vie privée
- Assurer la sécurité informatique de bout en bout
- Maintenir la transparence des traitements opérés par le SI
- Respecter la vie privée des utilisateurs et prévoir cela comme un bénéfice additionnel offert aux utilisateurs
II - Quelles sont les obligations imposées par le Privacy By Design dans le RGPD ?
Ces principes étaient donc posés en 2010 et ont influencé substantiellement les discussions lors de la rédaction du RGPD qui, en 2016, a repris cette l’idée de “privacy by design” et “privacy by default”, mais avec certain problèmes.
Si l’on observe l’article 25 son titre indique “Article 25 - Protection des données dès la conception et protection des données par défaut”. On peut donc jusque là penser que l’on est bien dans la logique du sujet initial.
Toutefois, la lecture de l’article 25 va surprendre :
Article 25 - Protection des données dès la conception et protection des données par défaut
- Compte tenu de l’état des connaissances, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement ainsi que des risques, dont le degré de probabilité et de gravité varie, que présente le traitement pour les droits et libertés des personnes physiques, le responsable du traitement met en œuvre, tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées, telles que la pseudonymisation, qui sont destinées à mettre en œuvre les principes relatifs à la protection des données, par exemple la minimisation des données, de façon effective et à assortir le traitement des garanties nécessaires afin de répondre aux exigences du présent règlement et de protéger les droits de la personne concernée.
- Le responsable du traitement met en œuvre les mesures techniques et organisationnelles appropriées pour garantir que, par défaut, seules les données à caractère personnel qui sont nécessaires au regard de chaque finalité spécifique du traitement sont traitées. Cela s’applique à la quantité de données à caractère personnel collectées, à l’étendue de leur traitement, à leur durée de conservation et à leur accessibilité. En particulier, ces mesures garantissent que, par défaut, les données à caractère personnel ne sont pas rendues accessibles à un nombre indéterminé de personnes physiques sans l’intervention de la personne physique concernée.
- Un mécanisme de certification approuvé en vertu de l’article 42 peut servir d’élément pour démontrer le respect des exigences énoncées aux paragraphes 1 et 2 du présent article.
On peut légitimement se demander ce que l’article 25 apporte vraiment, en effet:
- l’obligation principale posée par l’art. 25.1 est la suivante : “le responsable du traitement met en œuvre (…) des mesures (…) afin de répondre aux exigences du présent règlement”. Si l’on résume : la loi impose au responsable de traitement de respecter la loi. Cela n’apporte pas grand-chose.
- l’article 25.2 ne fait pas vraiment mieux dans la mesure où il indique, pour résumer, que le responsable de traitement s’assure de collecter le minimum de données personnelles. Or, cela n’est rien d’autre que le rappel du principe de minimisation qui est déjà très clairement explicité à l’article 5 du RGPD.
Il est courant, lorsque l’on est confronté à une telle problématique, d’analyser les considérants du texte afin de déterminer quelle a été ici l’intention du législateur. Le considérant 78 du RGPD précise quelque peu l’article 25 :
(78) La protection des droits et libertés des personnes physiques à l’égard du traitement des données à caractère personnel exige l’adoption de mesures techniques et organisationnelles appropriées pour garantir que les exigences du présent règlement sont respectées. Afin d’être en mesure de démontrer qu’il respecte le présent règlement, le responsable du traitement devrait adopter des règles internes et mettre en œuvre des mesures qui respectent, en particulier, les principes de protection des données dès la conception et de protection des données par défaut. Ces mesures pourraient consister, entre autres, à réduire à un minimum le traitement des données à caractère personnel, à pseudonymiser les données à caractère personnel dès que possible, à garantir la transparence en ce qui concerne les fonctions et le traitement des données à caractère personnel, à permettre à la personne concernée de contrôler le traitement des données, à permettre au responsable du traitement de mettre en place des dispositifs de sécurité ou de les améliorer. Lors de l’élaboration, de la conception, de la sélection et de l’utilisation d’applications, de services et de produits qui reposent sur le traitement de données à caractère personnel ou traitent des données à caractère personnel pour remplir leurs fonctions, il convient d’inciter les fabricants de produits, les prestataires de services et les producteurs d’applications à prendre en compte le droit à la protection des données lors de l’élaboration et de la conception de tels produits, services et applications et, compte dûment tenu de l’état des connaissances, à s’assurer que les responsables du traitement et les sous-traitants sont en mesure de s’acquitter des obligations qui leur incombent en matière de protection des données. Les principes de protection des données dès la conception et de protection des données par défaut devraient également être pris en considération dans le cadre des marchés publics.
Pour autant, il est difficile de trouver des obligations qui ne sont pas déjà existantes au sein du RGPD - principe de minimisation (art. 5), principe de minimisation dans le temps (art. 5), principe de sécurité des données (art. 5, art. 32), respect des droits des personnes (art. 12 et s.) etc.
En fait, il y a ici un bug législatif. Il manque dans le RGPD une catégorie spécifique de personnes directement concernées par ce principe de Privacy By Design : les concepteurs de systèmes de traitement de données personnelles. Le RGPD mentionne le responsable de traitement, le sous-traitant, les responsables conjoints, mais à aucun moment les éditeurs de logiciel, ou les concepteurs de systèmes informatiques. C’est là un chaînon manquant, envers qui les principes posés par l’article 25 devraient être appliqués. Le RGPD a fait le choix de ne pas viser spécifiquement ces intermédiaires qui fournissent les outils pour opérer le traitement des données (éditeurs de logiciel, fournisseurs de matériel type serveurs, etc). Par voie de conséquence il en résulte une obligation pratiquement vide de sens - et qui n’apporte pas grand-chose au regard de ce qui est déjà prévu par le règlement. Il est probable que la prochaine révision de la règlementation - probablement vers 2035-2040 - leur réserve une place à part.
En attendant il faut faire au mieux pour essayer de donner sens à l’intention du législateur : penser à protéger le traitement des données personnelles dès qu’un traitement est envisagé. Mais ce faisant, on ne fait qu’appliquer ce qui existe déjà au sein du RGPD.
III - Des outils opérationnels pour appliquer le Privacy By Design
D’un point de vue opérationnel il est important toutefois de s’assurer que les principes essentiels posés par le RGPD - et auxquels l’article 25 revoit, sont bien respectés au sein de l’organisation. À ce titre, il est important de disposer de processus clairs afin par exemple de veiller à ce que les préconisations en matière de sécurité informatique sont bien respectées:
Voici un exemple tiré d’un logiciel de gestion de la conformité RGPD qui permet de gérer l’ensemble des obligations imposées par le règlement européen.
