Lors de nos audits de sites web, certaines non-conformités au RGPD reviennent fréquemment (information incomplète, utilisation des polices Google Fonts à distance, mauvais paramétrage du gestionnaire de cookies…). Ce qui est plus embêtant, c’est lorsque les erreurs arrivent à la suite d’un travail… de mise en conformité ! Il faut reconnaitre que relever de telles erreurs est décevant, tant pour l’éditeur du site que pour l’auditeur. Le but de cet article est de vous aider à identifier ces pièges et les corriger.
Migrer de Google Analytics à Matomo… mais l’implémenter avec Google Tag Manager
Pourquoi l’idée de départ est bonne ?
Nous avons déjà eu l’occasion de l’aborder, l’utilisation de Google Analytics n’est pas conforme au RGPD (Règlement Général de Protection des Données). Et contrairement à ce que peuvent insinuer certains fans de la firme américaine, le passage à GA4 ne règle pas le problème : les données des utilisateurs continueront à être transférées à Google, en méconnaissance du RGPD.
Alors oui, passer de Google Analytics à Matomo (ou toute autre solution conforme au RGPD et hébergée en Europe) est une étape importante et prioritaire de votre mise en conformité.
Pourquoi ce n’est pas conforme au RGPD ?
Lors du paramétrage d’une solution d’analyse d’audience comme Matomo, vous allez mettre en place des « tags » sur les pages de votre site. Le problème c’est qu’en utilisant le système de tag management de Google, vous allez continuer à effectuer des transferts illicites de données ! Concrètement, vos utilisateurs vont faire appel sans s’en rendre compte à des ressources situées sur les serveurs de Google, qui de leur côté vont enregistrer l’adresse IP et la page consultée de l’utilisateur.
Comment corriger l’erreur ?
La solution est assez logique : changer de système de tag management. Pour reprendre l’exemple de Matomo, vous pouvez notamment utiliser le Matomo Tag Manager.
Choisir un composant hébergé en France… par une entreprise américaine
Pourquoi l’idée de départ est bonne ?
Depuis l’arrêt Schrems II de la CJUE (Cour de Justice de l’Union Européenne), on sait que les transferts de données vers les États-Unis sont illicites car ils ne peuvent pas être suffisamment encadrés [1]. Vérifier auprès de ses prestataires la localisation de l’hébergement est donc important : qu’il s’agisse d’un module d’inscription à un évènement, d’une carte ou de cookies comme nous l’avons vu dans le paragraphe précédent.
Si nous avons pris l’exemple d’un hébergement en France, notez que l’hébergement dans un autre État de l’UE ou dans un pays considéré comme adéquat par l’UE est également conforme au RGPD.
[1] Sauf en cas de chiffrement sans clé de déchiffrement côté américain ou pseudonymisation sans table de pseudonymisation côté américain. Ces systèmes n’existent pas sur les outils fréquemment utilisés, la seule solution identifiée à l’heure actuelle par la CNIL (Commission Nationale de l’Informatique et des Libertés)étant l’utilisation d’un PROXY, et à condition qu’aucune donnée personnelle ne soit utilisée sur l’outil.
Pourquoi ce n’est pas conforme au RGPD ?
Le Cloud Act est une réglementation états-unienne imposant aux entreprises américaines de rendre accessibles sur demande, aux autorités fédérales, les données qu’elles hébergent, y compris en dehors des États-Unis, et notamment en Europe ! L’hébergement de données personnelles sur un serveur physiquement situé en Europe mais appartenant à Microsoft, Amazon ou Google est donc illicite.
L’éditeur est responsable de choisir des composants et des prestataires conformes au RGPD. Cette non-conformité est malheureusement souvent liée à une désinformation de prestataires se présentant comme 100% conformes au RGPD
, avec 100% des données localisées en France
… sur des serveurs Azur ou AWS.
Comment corriger cette erreur ?
Au moment du choix de votre prestataire, vérifiez auprès de chacun où vos données seront hébergées et par quel hébergeur. Il est a priori possible de trouver une alternative hébergée en Europe et/ou Open-source pour chaque outil et composant.
Améliorer la sécurité des espaces personnels… en installant un reCaptcha
Pourquoi l’idée de départ est bonne ?
L’une des obligations fondamentales du RGPD, prévue à l’article 32, est d’assurer la sécurité des données personnelles. D’après la recommandation de la CNIL du 21 juillet 2022 sur les mots de passe, la mise en œuvre d’un mécanisme de restriction d’accès peut être une bonne solution pour permettre une sécurité suffisante d’un accès sans imposer à l’utilisateur le choix d’un mot de passe de 12 ou 14 caractères. C’est notamment le cas des mécanismes de type « captcha » qui permettent « de se prémunir contre les soumissions automatisées et intensives de tentatives ».
Pourquoi ce n’est pas conforme au RGPD ?
La mise en place du reCaptcha (de Google) implique généralement deux non-conformités, que nous avons déjà abordé en détail dans un article « captcha et numérique responsable » : un détournement de finalité et un transfert illicite de données. La CNIL a déjà alerté à plusieurs reprises sur cette non-conformité.
Comment corriger cette erreur ?
Tout dépend du contexte. En cas d’authentification de l’utilisateur, vous pourrez vous tourner vers les recommandations de la CNIL (blocage du compte au bout de 10 échecs, temporisation de l’accès au compte après plusieurs échecs…).
En revanche si le reCaptcha est là pour bloquer le spam dans les commentaires ou dans un formulaire, d’autres solutions, décrites dans notre article, pourront être utilisées (Honeypot, Live Identity Captcha d’Orange, test logique…).
Prévoir une information complète… mais difficilement accessible
Pourquoi l’idée de départ est bonne ?
Le droit à l’information, prévu aux articles 13 et 14 du RGPD et complété par la CNIL et le CEPD (Comité Européen de Protection des Données), impose à l’éditeur du site web de communiquer un certain nombre d’informations aux utilisateurs du site web, de manière claire et complète. La rédaction de votre politique de confidentialité, en particulier, vous permet de remplir cette obligation.
Pourquoi ce n’est pas conforme au RGPD ?
Le problème, c’est que la politique aura beau être parfaite, le droit à l’information ne sera pas assuré si elle n’est pas accessible.
Plusieurs écueils sont souvent rencontrés :
Le lien vers la politique est implémenté après le bouton d’envoi du formulaire, ce qui ne permet pas aux personnes aveugles, par exemple, de connaitre le contenu de l’information.
Le lien vers la politique en bas de page est difficile à trouver, ce qui peut être accentué par un choix de couleur non contrasté.
Comment corriger cette erreur ?
Assurez-vous que les mentions d’information et les liens vers votre politique de confidentialité sont facilement accessibles, y compris aux personnes en situation de handicap. Pour une prise en compte plus globale de l’accessibilité numérique de votre site web aux personnes handicapées, vous pouvez faire réaliser un audit de votre site au RGAA (Référentiel Général d’Amélioration de l’Accessibilité). Vous retrouverez également quelques conseils pratiques sur le site design.cnil.
Recueillir le consentement de l’utilisateur… via une interface ambiguë
Pourquoi l’idée de départ est bonne ?
Recueillir le consentement est obligatoire pour certains traitements de données réalisés sur un site web : c’est le cas du dépôt et de l’utilisation des cookies (article 82 de la loi informatique et libertés), et de tout autre traitement dont la base légale est le consentement (article 6 du RGPD). Le consentement d’un utilisateur doit par exemple être recueilli en cas d’inscription à un jeu concours ou pour lui proposer de la prospection commerciale.
Pourquoi ce n’est pas conforme au RGPD ?
Le consentement doit répondre à certaines caractéristiques : il doit être libre, éclairé, explicite et univoque. Il est malheureusement fréquent de rencontrer des designs trompeurs (volontairement ou pas) dans le recueil du consentement, que ce soit en jouant sur les couleurs, sur l’emplacement des boutons, etc.
Ces designs doivent être évités dans la mesure où ils rendent équivoque l’expression du consentement.
Comment corriger cette erreur ?
Les lignes directrices du CEPD du 14 février 2023 sur les design patterns déceptifs donnent de nombreux exemples de design trompeurs à bannir et des conseils pour les éviter.
Conclusion
On peut avoir tendance à penser que son site web est conforme parce que l’on a rédigé sa politique de confidentialité ou supprimé Google Analytics… Si ces actions sont positives, vous aurez compris qu’elles ne sont pas suffisantes pour autant.
Pour la seule année 2021, la CNIL avait réalisé 173 contrôles en ligne (sur 384 au total). Alors n’attendez pas pour vérifier les 5 points développés dans cet article !
Vous pouvez confier à Empreinte Digitale la réalisation d’un audit de conformité de votre site web à la réglementation sur les données personnelles : pour en savoir plus, n’hésitez pas à nous contacter.
