Tout site Internet doit être conforme au RGPD, ce qui va beaucoup plus loin que de demander une autorisation pour les cookies. Chaque intervenant possède sa part de responsabilité, le propriétaire du site ayant la sienne également. Je vais aujourd’hui développer de façon synthétique 3 obligations principales que sont la communication, la sécurité et le traitement des informations.
Pour les fichiers de traitement des informations que vous devez maintenir à jour, il est préférable de les automatiser. Mais dès lors qu’aucune action manuelle n’est attendue, des traitements tout à fait légitimes peuvent survenir, mais qui échappent du coup à votre connaissance. Si bien que le site ne peut plus être considéré comme conforme au règlement n° 2016/679.
Enfin, le Règlement Général sur la Protection des Données est un règlement de l'Union européenne qui met à l’abri l’internaute contre une attaque, des mauvais traitements, ou tout danger lié à son identification ses données à caractère personnel. Ce qui impose un principe de sécurité dans beaucoup de niveau de la programmation : qui à le droit de voir quoi ?
Il d’abord identifier quelles sont les données à caractère personnel. La chapitre III du RGPD relatifs aux droits de la personne concernée expose ce que l’internaute peut exiger. Notamment avoir accès aux informations que :
L’article 13 dispose des informations que vous devez lui transmettre avant qu’il utilise un service ou une fonctionnalité, dont :
Pour illustrer, avant de demander un devis en ligne ou commander un produit, l’utilisateur doit être informé de tout cela ! Il est clair que votre webmaster doit avoir élaboré une stratégie sur mesure pour remplir cette obligation, tout en s’assurant qu’elle ne vienne pas gâcher l’expérience utilisateur ou le design du site. Ainsi, dans le cas d’un site de covoiturage, énormément de données à caractère personnel sont demandées et sont obligatoires (sur les personnes, les véhicules, les trajets, etc.), et vous devez gérer ceci avec subtilité. De l’expertise est indispensable, et plusieurs semaines de travail également pour les audits et les développements web.
L’article 15 dispose du droit de se renseigner sur le fait que la personne en charge de ses données, va en faire ou non usage. Dans l’affirmative, un internaute peut demander à quelles fins, pour quelle catégories de données, à qui les datas ont été ou peuvent être communiquées. Et si les informations n’ont pas été collectées sur votre site Internet, vous êtes dans l’obligation de lui communiquer la source des données.
Il doit pouvoir exiger que vous rectifiez ou effaciez des données, ou que vous en limitiez l’usage, voire que vous n’en fassiez rien !
Si le système est automatisé pour réaliser une action en fonction de données spécifiques, qu’il y ait un profilage ou non, l’article 22 du RGPD autorise l’internaute à demander - et le responsable du site à lui donner l’information – quelle est la règle de l’algorithme, ou du moins quelle est la logique faisant déclencher l’automatisation. Vous devez également lui expliquer quelles sont les conséquences à son égard.
Que ce soit pour communiquer ces informations à l’internaute, ou pour utiliser tout simplement les données récoltées afin que le site fonctionne parfaitement, il faut que les données collectées soient répertoriées en base de données. Elle est généralement sur votre serveur, dans votre hébergement avec les codes de votre site Internet.
Il est évident qu’une table Contact ou Client contient des datas entrant dans le cadre du RGPD. Mais quid de la table Facture, Parrain, etc. ? J’échangeais sur la mise en conformité de diverses plateformes avec un développeur en PHP qui connaissait les grandes lignes du Règlement Général sur la Protection des Données, et qui m’expliquait qu’un site e-commerce pouvait collecter toutes les informations nécessaires à la commande et à la livraison des produits commandés, sans qu’il ait à demander l’autorisation à son client. Ce qui fait du sens, car j’imagine mal un internaute passer une commande et refuser de communiquer ses nom, prénom et adresse pour la recevoir. Il n’avait toutefois pas compris que personne d’autre que l’individu chargé de la commande ne doit voir ces informations à caractère personnel. L’idée est que chaque personne pouvant voir des datas, peut les récupérer d’une façon ou d’une autre pour les revendre ou les exploiter à titre lucratif par exemple. C’est de la prévention, ce qui entre dans le champs du RGPD et de la mise en conformité de votre site Internet.
Outre des Tables, une base de données est constituée de colonnes : elles peuvent également indiquer des informations personnelles, comme un intitulé adresse, ou encore prénom.
En dehors des Tables, des procédures stockées peuvent également avoir des données à caractère personnel. La mise en conformité toute aussi cette partie qui n’est plus du MySQL.
Le Règlement Général sur la Protection des Données de l’Union Européenne impose aux personnes responsables du site Internet d’identifier les traitements qu’ils vont faire des données personnelles collectées. Ce qui va au-delà de l’envoi d’une newsletter… A titre d’illustration, des applications externes peuvent avoir besoin des datas de la base de données MySQL, pour que des fonctionnalités offertes aux internautes marchent.
Dans le cadre d’un site de rencontres, un web service est utilisé pour le tchat webcam, or des données à caractère personnel sont obligatoirement transmises à ce prestataire dont vous avez installé l’API pour que vos membres échangent par visio. J’ai choisi cet exemple, mais il en existe beaucoup d’autres.
Des API peuvent fonctionner en interne, et elles ont besoin des données de connexion, des sessions. Il peut même exister des requêtes SQL qui ne font pas parties des procédures stockées, bien qu’exécutées en faisant appel à ces datas.
Il est nécessaire de réaliser un audit du site, en ce sens.
Un serveur sur lequel est hébergé un site Internet et sa base de données MySQL ou autre, doit être sécurisé pour éviter des piratages. Tout le monde ou presque à conscience de cela. En revanche, savez-vous qu'il est intéressant de sécuriser le périmètre du serveur pour éviter qu'un codeur ne lie des datas de la base de données à son code, pour faire marcher une fonctionnalité ?
Pour illustrer, une agence web peut développer des programmes permettant d'envoyer des mails en tenant compte de données personnelles, en automatisant le processus d’une newsletter. Ceci est courant et est tout à fait légitime. En contrepartie, cette fonctionnalité nécessite de créer des traitements au sens du RGPD, sans que le responsable n'en soit informé ni que quiconque ne pense au Règlement de l’UE. En fait, à chaque fois qu’une nouvelle programmation est mise en place, ou qu’un prestataire intervient quelle qu’en soit la raison, vous devez vous poser la question de l’incidence sur les traitements des données collectées.
Sécuriser les données, c'est aussi empêcher que de nouveaux traitements apparaissent sans que vous ne soyez informé. Je ne parle pas de mauvaises actions, juste du fait d’avoir fait apporter de nouveaux développements à votre site Internet ou une refonte partielle : ces nouveaux scripts utilisent-ils des données à caractère personnel pour fonctionner ?
Par expérience, je sais qu'un webmaster n'a pas nécessairement en tête les obligations RGPD quand il crée du code. La question de la compatibilité est fugace, mais concrètement ce n'est pas son métier à l’origine. Et il est difficile de s’accaparer cette nouveauté. Il a fallu que je me forme par exemple, une veille documentaire ne suffit pas.
Pour comprendre, voici une situation basique : un développeur freelance a généré une programmation de qualité, mais la mise en œuvre n’est pas conforme au RGPD malgré des cases à cocher pour les autorisations, parce qu'il n'existe pas de registres sur les traitements des données. Concrètement, si une autorité - au hasard la CNIL - vous demande des comptes, vous devez être en mesure de produire des documents à jour qui précisent que telles données collectées de telle façon a reçu telle autorisation pour telles utilisations sur une durée de tant de temps. Et les documents de prouver qu’au-delà de ce temps, le droit à l’oubli est géré de telle manière.
Bien sûr, le créateur de votre site Internet doit automatiser tout cela. Mais vous devez comprendre que même un prestataire indépendant ne peut pas raccourcir le temps de réalisation s’il faut rendre en plus de la programmation classique, le site web conforme au règlement européen. Il ne faut pas se mentir, chaque création étant différente, la mise en conformité ne peut-être que sur mesure. Elle sera plus rapide sur un simple site vitrine, et peut rajouter facilement 20 jours de travail sur une plateforme de mise en relation complexe. Ce qui a une incidence sur le prix bien sûr. Mais vous n’avez pas le choix. Votre prestataire non plus, puisqu’il engage sa responsabilité !
A titre d'illustration, quand un développeur configure une messagerie, comme attribuer un serveur SMTP, il active des droits, sans qu'il ait nécessairement conscience qu'il y aura une incidence sur la conformité au RGPD. La base de données et ses propriétés, ses facettes de déclaration de la surface d'exposition, etc. Pour sécuriser tout cela, il faut créer ce que l'on appelle des stratégies de sécurité : des conditions pour différentes conditions. Ainsi, quand une permission est modifiée, une stratégie de sécurité se mettra en route.
Il faut également gérer ce qu’en développement web nous appelons les privilèges, c'est également un principe de sécurité. Les 2 principaux privilèges sont généralement l'utilisateur et les connexions. Il y a aussi les rôles, mais n'entrons pas dans le détail ici. Il faut donc auditer quels sont les privilèges donnés aux différents utilisateurs et aux logins (les connexions).
Le principe consiste à ne rendre visibles les données à caractère personnel, en clair donc, qu'aux personnes autorisées à les voir. L'article 32 sur la sécurité du traitement des données fait référence à cette sécurité. A ce titre, le règlement exige la pseudonymisation et le chiffrements de ces datas sensibles.
Le mot pseudonymisation est un peu rugueux, mais il signifie que vous devez cacher ces datas personnelles aux personnes non autorisées à les voir. Il faut donc dissimuler les donnée dans les requêtes. Il faut donc se demander si faire circuler les données dans une URL avec une fonction Get ne contrevient pas au RGPD. Vous allez me dire que c’est le principe de la fonction… Il faudra peut-être trouver autre chose, une autre stratégie de programmation.
Pour illustrer ce sujet, prenons l'exemple d'une plateforme de voyance, où la société de téléphonie a besoin de recevoir le N° de téléphone du voyant et du consultant pour les appeler simultanément. Les N° de téléphones doivent donc bels et bien être stockés en clair. Mais la commande SELECT ne doit pas afficher le N° complet. Des fonctionnalités de masquage interne sont donc à mettre en œuvre.
Gardez en tête que ce que l’on nomme les vues en programmation informatique, peuvent aussi effectuer un select pour exécuter une requête, et sans parler des procédures stockées. Il peut être utile parfois de donner des privilèges à une vue ou à une procédures stockée, sans que ce soit à la table sous-jacente. Mais ce réflexe n’est pas un acquis, il faut posséder de l’expertise en termes de développement PHP pour y penser. A condition d’avoir réfléchi à une bonne stratégie de mise en conformité. Voilà pourquoi vous avez besoin d’un prestataire qui connaisse vraiment son sujet.
