Protection des données et développement de logiciels

Les développeurs de logiciels sont souvent confrontés aux obstacles de la protection des données. On a vite l'impression que la protection des données et le développement de logiciels sont deux domaines incompatibles.

Voici donc une brève présentation des points de repère pour les développeurs de logiciels.

Privacy by Design (art. 25 I RGPD)

La limitation du stockage, la minimisation des données, la confidentialité et l'intégrité ne sont que les principes les plus évidents de la protection des données, qui ne peuvent être intégrés ultérieurement qu'au prix d'efforts considérables. C'est pourquoi l'approche préventive est la clé. Dès l'architecture de l'application informatique, il convient d'établir un standard élevé de protection des données afin de ne pas dépasser le cadre légal avec les possibilités techniques infinies.

Prendre en compte tous les aspects de la protection des données dès le début du développement permet en outre d'économiser des quantités de coûts qui seraient générés par la correction d'un logiciel fini ne respectant pas la protection des données.

Si le logiciel est développé de manière à ce que l'utilisateur puisse voir clairement quelles données sont collectées et que cela se fasse de manière transparente, minimisée et dans un but précis, non seulement les principes importants de la protection des données sont respectés (transparence, art. 5 I, lettre a du RGPD ; minimisation des données, art. 5 I, lettre c du RGPD ; finalité, art. 5 I, lettre b du RGPD), mais la confiance de l'utilisateur dans le logiciel est également augmentée. Au final, cela représente à nouveau une valeur économique.

En ce qui concerne la transparence, il convient de noter que tous les flux de données doivent être présentés à la personne concernée. Cela inclut notamment les flux de données vers des tiers, dont il faut dans tous les cas informer la personne concernée (article 13 du RGPD).

Il en résulte que l'objectif du développement de logiciels devrait toujours être d'éviter, dans la mesure du possible, de devoir collecter des données à caractère personnel et, en cas de collecte, de ne collecter que les données réellement nécessaires à l'objectif poursuivi. Les décisions dans ce domaine relèvent généralement du domaine de responsabilité de la partie prenante concernée et doivent donc être discutées en détail avec elle.

Sécurité des données de la collecte à l'effacement

La sécurité des données doit en outre être garantie tout au long du "cycle de vie du logiciel". Les données doivent être protégées dès leur collecte, pendant leur stockage et jusqu'à leur suppression. Les principes de confidentialité et d'intégrité s'expriment ici (article 5 I, lettre f du RGPD).

D'une part, il faut empêcher l'accès non autorisé aux données. Pour cela, le choix d'une norme de cryptage appropriée est tout aussi essentiel que la mise en œuvre de contrôles d'accès. Pour que la disponibilité des données soit également assurée, il faut penser aux sauvegardes et à la résilience.

L'obligation d'assurer la protection des données par de telles mesures incombe généralement au développeur de logiciels lui-même, dont les obligations contractuelles de développement de logiciels pour le client (qui est généralement le responsable) sont ici affectées.

Supprimer correctement

Lorsque la finalité du traitement disparaît, ou au plus tard lorsque les délais de conservation expirent, les données correspondantes doivent être immédiatement effacées. Si cela n'est pas fait, les autorités de protection des données risquent d'infliger de lourdes amendes.

La suppression des données devrait donc également être prise en compte très tôt dans la planification du logiciel. Un système d'effacement automatisé s'impose ici.

L'anonymisation comme alternative à la suppression

Si l'effacement des données correspondantes n'est pas techniquement possible ou judicieux, les données peuvent également être rendues anonymes. Cela doit être fait de manière à ce qu'il ne soit plus possible d'établir un lien avec une personne. En raison de la complexité des données et de leur présentation, l'anonymisation est généralement plus facile à mettre en œuvre que la suppression.

Il convient de noter qu'une pseudonymisation n'est pas suffisante. La pseudonymisation signifie que les données n'ont plus de lien avec une personne sans l'utilisation d'informations supplémentaires, mais que ce lien peut être établi grâce à ces informations supplémentaires. Il y a pseudonymisation, par exemple, lorsque les données relatives à une personne sont enregistrées avec un numéro d'identification individuel (par exemple un numéro de client) au lieu d'être associées à son nom. Cela ne répond pas aux exigences de l'obligation d'effacement, alors qu'une anonymisation effective y répond.

Privacy by default (art. 25 II RGPD)

S'il existe une structure de base selon le principe "Privacy by Design", le principe "Privacy by Default" (protection des données par défaut) devrait également être pris en compte. Ces paramètres par défaut permettent de garantir que seules les données nécessaires à la finalité indiquée sont traitées. Les paramètres par défaut doivent donc toujours représenter l'étendue la plus réduite possible du traitement.

Exemples

Dans un système CRM (Customer Relationship Management), différents rôles d'utilisateurs doivent être définis via un système d'autorisation détaillé, de sorte que chacun n'ait accès qu'aux données nécessaires à son domaine de travail.

S'il s'agit de l'envoi de newsletters ou autres, l'utilisateur doit pouvoir s'y inscrire via une option opt-in. Si l'utilisateur doit désactiver activement cette option (opt-out), cela n'est pas conforme à la protection des données.

Conseils pour la pratique

Miser sur ce qui a fait ses preuves : Les composants et frameworks généralement très répandus résistent en général mieux aux contrôles externes que les moins répandus. L'utilisation de composants comparables ne doit pas être exclue en soi. Dans des catégories telles que le cryptage et d'autres composants de sécurité, il convient toutefois de recourir en premier lieu à des normes universelles.

La communication est importante ! En tant que développeur de logiciels, il est important d'attirer l'attention des architectes, des parties prenantes et, le cas échéant, des autres développeurs sur les exigences en matière de protection des données dès le début, afin qu'elles soient prises en compte et planifiées à l'avance. Cela permet d'économiser beaucoup d'efforts et de coûts et l'interaction entre la protection des données et le développement de logiciels est plus simple.