RGPD et votre site : ce qui vous incombe en tant que propriétaire

Un formulaire de contact, une inscription à une lettre d'information, une prise de rendez-vous, un compte client dans votre boutique. Chacun collecte un nom, une adresse e-mail, parfois un numéro de téléphone. Au sens du RGPD, ce sont des données personnelles, et votre entreprise en est le responsable du traitement.

Beaucoup de propriétaires pensent que, puisqu'une agence a construit le site et qu'un hébergeur fait tourner le serveur, la sécurité est leur affaire. Ce n'est pas ainsi que cela fonctionne. Le développeur et l'hébergeur ont leurs propres obligations, mais c'est vous, en tant que responsable du traitement, qui répondez devant l'autorité de contrôle et devant vos clients.

Voici ce que les règles attendent de vous en tant que propriétaire, en termes simples. Ce n'est pas un conseil juridique : pour tout cas inhabituel, adressez-vous à un avocat ou à votre délégué à la protection des données.

Qui est qui sur votre site

Le RGPD répartit les acteurs en deux rôles. Le responsable du traitement décide pourquoi et comment les données sont collectées : c'est votre entreprise. Un sous-traitant traite les données pour votre compte : l'hébergeur dont le serveur contient la base de données, le développeur ou l'agence qui a accès à l'administration, l'outil de lettre d'information, le système de réservation.

Les conséquences sont pratiques. Si l'agence néglige les mises à jour et que quelqu'un vole les messages des formulaires, c'est vous qui notifiez la violation, qui prévenez vos clients et qui répondez aux questions de l'autorité. Vous réglez vos comptes avec l'agence ensuite, selon votre contrat, si vous en avez un.

Article 32 : une sécurité à la mesure du risque

L'article 32 ne dit pas quelle extension utiliser ni quelle doit être la longueur d'un mot de passe. Il demande des « mesures techniques et organisationnelles appropriées », c'est-à-dire adaptées au risque. Il donne quelques exemples : le chiffrement, la confidentialité et la disponibilité des données, la capacité de les rétablir rapidement après un incident, et des tests réguliers pour vérifier que votre sécurité fonctionne réellement.

Sur le site d'une petite entreprise, cela donne des choses très concrètes :

• tout le site fonctionne en HTTPS, et aucun formulaire n'envoie de données en http simple,
• le CMS, le thème et les extensions sont mis à jour selon un calendrier, et pas quand quelqu'un y pense,
• seules les personnes qui en ont vraiment besoin peuvent se connecter à l'administration, avec une connexion à deux facteurs,
• les sauvegardes sont stockées ailleurs que sur le serveur du site, et quelqu'un a vérifié qu'une restauration fonctionne,
• les anciens messages de formulaires ne restent pas des années dans la base sans raison,
• de temps en temps, quelqu'un contrôle le site de l'extérieur, par exemple avec un scanner de sécurité, et note le résultat.

Le dernier point est le plus facile à sauter, pourtant il répond directement à l'exigence de « tests réguliers ». Si l'autorité vous demande un jour comment vous gérez la sécurité, une note « testé le 3 mars, deux problèmes, corrigés le 10 mars » vaut mieux que n'importe quelle assurance que le site va probablement bien.

72 heures pour prévenir l'autorité

Une violation de données personnelles n'est pas forcément un piratage spectaculaire. Cela peut être un export de messages de formulaires que n'importe qui pouvait télécharger depuis une adresse publique. Un compte administrateur détourné. Un e-mail envoyé à tous vos clients avec leurs adresses en copie visible au lieu de la copie cachée.

L'article 33 prévoit que le responsable du traitement notifie l'autorité de contrôle dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance. En Pologne, cette autorité est l'UODO, au Royaume-Uni l'ICO (le UK GDPR a conservé la même règle), en Irlande la Data Protection Commission. Ce sont des heures réelles : un week-end ne suspend pas le délai. La notification n'est pas nécessaire seulement lorsque la violation n'est pas susceptible d'engendrer un risque pour les personnes dont les données sont concernées.

Deux choses devraient rendre cela moins intimidant. Il n'est pas nécessaire d'avoir le tableau complet tout de suite : les règles permettent de fournir les informations de manière échelonnée, et il vaut mieux signaler à temps ce que vous savez et compléter ensuite que d'attendre un rapport complet de votre développeur. Et la plupart des autorités reçoivent les notifications par un formulaire en ligne sur leur site.

Une notification tardive doit expliquer le retard. Convenez donc avec la personne qui s'occupe de votre site que vous serez informé le jour même de toute fuite présumée. Un sous-traitant doit vous prévenir dans les meilleurs délais, mais la décision de notifier vous revient, et le délai aussi.

Quand vous devez prévenir vos clients

L'article 34 va un cran plus loin. Si une violation est susceptible d'engendrer un risque élevé pour les personnes concernées, vous devez aussi les informer, toujours dans les meilleurs délais. En clair : ce qui s'est passé, les conséquences probables, ce que vous avez fait, et à quoi elles doivent faire attention, par exemple des e-mails qui prétendent venir de votre entreprise.

Un risque élevé, ce sont par exemple des mots de passe de comptes clients divulgués, des numéros d'identité nationale, des informations de santé tirées du formulaire d'inscription d'une clinique, ou la liste de clients d'un cabinet d'avocats avec des notes sur leurs dossiers. Une adresse e-mail issue d'une inscription à une lettre d'information pèse en général moins, mais l'appréciation dépend toujours de la situation.

Il y a des exceptions. Vous n'avez pas à informer les personnes si les données étaient chiffrées de façon qu'aucun tiers ne puisse les lire, ou si vous avez agi immédiatement de manière à rendre le risque élevé peu probable. Quand contacter chacun individuellement exigerait des efforts disproportionnés, une communication publique peut la remplacer.

Un contrat de sous-traitance avec votre hébergeur et votre développeur

Quiconque traite des données personnelles pour votre compte doit avoir avec vous un contrat de sous-traitance (article 28). Il n'a pas besoin d'être épais. Les grands hébergeurs et les outils de lettre d'information ont en général un modèle prêt dans leur espace client ou leurs conditions d'utilisation. Vous l'acceptez et vous en gardez une copie.

Avec les indépendants et les petites agences, personne n'y a souvent pensé. Le contrat précise notamment qu'ils ne traitent les données que sur vos instructions, qu'ils les protègent, qu'ils vous aident en cas de violation, et qu'ils les suppriment ou les restituent quand vous cessez de travailler ensemble. Ajoutez les détails pratiques : qui est l'interlocuteur, par quel canal il signale un incident, et sous quel délai.

Ce qu'il faut garder par écrit

Le RGPD repose sur la responsabilité. Il ne suffit pas d'être en règle, il faut pouvoir le démontrer. Pour le site d'une entreprise, cela veut dire un dossier, sur papier ou sur un disque partagé :

1. Les contrats de sous-traitance avec votre hébergeur, votre développeur ou votre agence, et chaque outil qui reçoit des données de vos formulaires.
2. Une courte description de votre sécurité : ce qui est mis à jour et par qui, où sont les sauvegardes, qui a un accès administrateur.
3. Les résultats des contrôles périodiques du site, et une note de ce qui en a été fait.
4. Un registre des violations. L'article 33 impose de documenter chaque violation, y compris celles que vous décidez de ne pas notifier : ce qui s'est passé, quels en ont été les effets et ce que vous avez fait. Pour celles qui ne sont pas notifiées, notez pourquoi vous avez décidé de ne pas le faire.
5. Un registre des activités de traitement, s'il vous concerne. L'exemption pour les organisations de moins de 250 salariés est plus étroite qu'il n'y paraît : elle ne couvre pas les traitements qui ne sont pas occasionnels, et un formulaire qui apporte des demandes chaque semaine est difficile à qualifier d'occasionnel.

Rien de tout cela n'exige un gros budget. Il faut un accord clair sur qui fait quoi avant que quoi que ce soit n'arrive. Pendant un incident, 72 heures passent très vite, surtout si vous passez la première journée à chercher qui a accès au serveur.