Après notre introduction à Google Analytics 4, dans laquelle nous avons très brièvement évoqué la mise en conformité aux normes RGPD, il nous semblait important de revenir sur la situation actuelle. En effet, le domaine de la web analyse est surveillé de près par la CNIL, laquelle a récemment publié une mise au point concernant l’usage de Google Analytics.
Après examen des recommandations de la CNIL du 7 juin 2022, il en ressort que si l’utilisation d’Universal Analytics est problématique du point de vue du RGPD, la succession assurée par GA4 permettrait une protection des données suffisantes… mais uniquement sous certaines conditions !
Ainsi, même sans expertise juridique ou RGPD, il est donc capital pour les web analystes de bien comprendre les enjeux techniques auxquels ils seront confrontés durant les prochains mois (au moins jusqu’en septembre 2022) !
Alors que faire ou ne pas faire aujourd’hui avec Google Analytics 4 pour rester dans les clous de la CNIL ?
Problèmes juridiques : la CNIL restreint les transferts de données des utilisateurs à l’international
Tout part de l’affaire des 101 plaintes NOYB et de l’invalidation du Privacy Shield, un arrêt censé encadrer les transferts de données entre l’Union Européenne et les États-Unis, mais qui ne garantit pas un assez haut niveau de confidentialité pour les utilisateurs européens.
En effet, vous n’êtes sans doute pas sans savoir qu’afin d’être traitées par la solution analytics de Google, les données collectées sur les internautes font l’objet d’un transfert transatlantique, avant d’être traitées et renvoyées au web analyste sous forme d’informations structurées et interprétables.
Sauf que…
Conditions pour un transfert international de données conforme au RGPD
Le chapitre 5 du Règlement Général sur la Protection des Données indique qu’ “un transfert
vers un pays tiers ou à une organisation internationale de données à caractère personnel qui font ou sont destinées à faire l’objet d’un traitement après ce transfert ” ne peut avoir lieu que dans deux cas de figures :
- soit le pays de l’entreprise qui reçoit les données est considéré comme “adéquat”, à savoir qu’il offre une protection équivalente à ce qu’attend la législation européenne. C’est notamment le cas de pays comme Andorre, la Suisse, l’Argentine ou bien la Nouvelle-Zélande (alerte spoiler : les USA n’en font pas partie) ;
- soit l’organisme destinataire du transfert (ou son gouvernement) prend des mesures spécifiques afin de quand même proposer les garanties nécessaires, par des moyens que l’on détaillera juste après.
Malheureusement, Google et les États-Unis ne semblent rentrer dans aucun de ces cadres légaux.
Les États-Unis : un pays “inadéquat
En effet il existe deux types d’états : ceux que l’on qualifie d’adéquats, et ceux qui ne le sont pas. Les pays adéquats sont désignés comme tels du fait de leur législation ou de leurs accords internationaux qui les contraignent à intégrer des procédures de protection de la confidentialité des personnes.
Or, les derniers contrôles ont révélé que des multinationales américaines telles que Google et Facebook recevaient régulièrement, de la part de leurs propres autorités publiques, des demandes d’accès aux données personnelles des utilisateurs, sans que ces derniers n’aient leur mot à dire – ni même n’en soient informés.
Cette pratique considérée comme illicite au regard des normes RGPD a contribué à classer les USA dans les pays dits “inadéquats”.
Les 4 solutions pour les pays classés “inadéquats”
En principe, les entreprises dont le siège se situe en pays inadéquat peuvent avoir recours à quatre alternatives…
Les BCR ou “règles d’entreprises contraignantes”
Elles s’appliquent à toutes les entités d’un groupe. En principe, cet outil s’adresse justement aux multinationales. Problème : la loi nationale américaine surpasse les BCR.
Nota Bene : cette solution convient mieux aux entreprises dont le siège est en Europe, même dans un pays inadéquat.
Des clauses types de protection des données adoptées par la Commission
Là encore, le droit américain passe avant ce type de clauses. Donc retour à la case départ…
➜ Certification par la CNIL
L’idée est que l’entreprise passerait une certification de ses traitements d’informations (analyse, e-mailing, campagne publicitaire, etc.) approuvée par une autorité de contrôle, à l’instar de logiciels de mesure d’audience tels que Matomo, Piwik, et beaucoup d’autres que la CNIL recommande, si utilisés sous un certain type de configuration. Cependant, aucun écho ne semble rapporter la moindre démarche de Google dans ce sens.
➜ Le Privacy Shield
Ce dispositif juridique, chargé d’encadrer les transferts de données entre l’Europe et les États-Unis, aurait pu constituer une solution adaptée. Mais face au risque d’accès par les autorités aux données des internautes européens, le Privacy Shield a été invalidé via l’arrêt du 16 juillet 2020, où il est expliqué que les garanties proposées ne sont pas suffisantes.
Or, ce Privacy Shield devait permettre le transfert de datas sans procédure contraignante additionnelle. Son invalidation rend donc obligatoires ces mesures de mise en conformité, du moins jusqu’à nouvel ordre.
En conséquence, qu’on parle de Facebook, de Google ou même de Microsoft, le transfert de données aux États-Unis est tout bonnement illégal à l’heure actuelle ! On attend néanmoins une seconde version du Privacy Shield d’ici fin 2022, voire début 2023… en espérant que celui-ci passe !
Réaction à chaud de Google
En substance, le géant de la mountain view objecte que la CNIL, au lieu de “spéculer” sur les hypothétiques demandes d’accès aux user datas européennes de la part du gouvernement américain, devrait plutôt se fonder sur la réalité du terrain – conformément aux recommandations de l’EDPB.
À cet égard, la firme déclare n’avoir jamais eu, en 15 ans d’activités webanalytics, à fournir aux autorités américaines la moindre donnée provenant d’un résident de l’UE. À défaut que le dossier ne soit étudié sous cet angle, Google espère néanmoins que les réformes faisant l’objet du prochain décret exécutif des États-Unis donneront lieu à un meilleur encadrement de la confidentialité des données lors d’échanges transatlantiques.
Mais alors… Que faire en attendant ?
Article 49.1 a : une possible dérogation grâce au consentement ?
Après ce qu’on vient de voir, la première tentation qui nous vient à l’esprit est : “oui mais si l’utilisateur est d’accord ?”. À ce titre, le point a de la section 1 de l’article 49 dit qu’ “un transfert ou un ensemble de transferts de données à caractère personnel vers un pays tiers ou à une organisation internationale” que si :
- la personne concernée a été informée des risques encourus dans un pays inadéquat et en l’absence de garanties appropriées ;
- l’utilisateur a malgré tout donné son consentement explicite.
Autrement dit, si vous informez l’internaute que, dans le cadre d’une utilisation de Google Analytics, les autorités américaines seront en droit de demander l’accès à ses données personnelles, et si l’utilisateur accepte malgré tout, un transfert légal des datas vers les USA serait possible.
Ce que dit l’expert RGPD : oui mais uniquement pour des cas exceptionnels !
Par définition, la dérogation ne peut être accordée qu’à titre d’exception. Ainsi, le consentement de l’utilisateur s’inscrit dans un cadre légal qui ne concerne que des transferts occasionnels.
Or, avec Google Analytics en l’occurrence, les transferts de données sont tout sauf occasionnels, puisque chaque data collectée est transférée directement afin d’être traitée ! Cette protection ne saurait donc être suffisante au regard de la CNIL, sauf pour un traitement très spécifique sur une période donnée (une petite campagne d’e-mailing par exemple).
Politique de confidentialité : ce qu’il faut néanmoins faire
Même sans invoquer l’article 49.1 a, il reste fondamental :
- de préciser, dans votre politique de confidentialité, la façon dont vous traitez les données, notamment quant à leur exploitation via Google Analytics ;
- de continuer d’en informer les internautes avec demande de consentement dès leur arrivée sur le site au moyen de la bannière des cookies.
Quoi qu’il en soit, l’article 49.1 a représente une trop maigre marge de manœuvre pour s’en contenter. L’unique issue semble donc résider dans la manière dont on va utiliser GA4.
Problèmes techniques : Google Analytics n’offre pas toutes les garanties requises par le RGPD
On pourrait se dire qu’un géant tel que Google aurait prévu une parade afin qu’un problème aussi simple (du moins en apparence), puisse être résolu techniquement. Après tout, ce que veut la CNIL, c’est simplement une garantie de confidentialité.
Toutefois, le problème touche au cœur du fonctionnement de Google Analytics…
Ce qu’implique un transfert de données vers les serveurs de Google Analytics
Pour rappel, lorsque Google Analytics est exécuté et qu’il envoie une requête vers les serveurs situés aux USA, cette requête contient :
- une adresse IP, qui va, entre autre, permettre de déduire les données de géolocalisation des utilisateurs ;
- un client_id, qui sert d’identifiant unique pour un utilisateur, avec des informations sur son terminal. Il permet d’analyser des parcours utilisateurs sous forme de session, page visitée après page visitée (à ne pas confondre avec un user_id qui va reconnaître l’internaute partout et sur tous ses appareils) ;
- un user agent : il catégorise les internautes selon la combinaison du navigateur, de l’appareil utilisé, de son système d’exploitation. Cela aide, par exemple, à dresser des rapports techniques, en cas de problème rencontré, par exemple vis-à-vis d’un affichage sur une certaine taille d’écran ou de la version trop ancienne d’une OS.
Ce sont justement ces informations, d’apparence anodines, qui heurtent la sensibilité de la CNIL. “Et pourquoi ?” me direz-vous. Eh bien parce que…
Réidentification par recoupement d’informations : le pouvoir redouté de Google
Le problème que relève la CNIL, c’est que la solution Google Analytics récupère des données qui parviennent à un organisme détenant une somme colossale de user datas.
En effet, Google dispose déjà de milliards de données qui ont pu être collectées légalement à travers pléthore de produits matériels et logiciels distribués dans le monde (smartphones, navigateurs, moteur de recherche, plateforme YouTube, etc.).
Par conséquent, la CNIL craint qu’en recoupant ces innombrables sources d’informations, la célèbre firme ne soit indirectement en mesure de réaliser une ré-identification des utilisateurs.
Évidemment, aucune autre solution analytics sur le marché ne détient pareille force de recoupement. C’est pourquoi la décision de la CNIL pénalise particulièrement Google, qui, de son côté, se défend – mais sans fournir davantage de preuves – d’avoir recours à ce genre de pratiques.
Certes, mieux vaut prévenir que guérir, mais pour l’heure, ce sont surtout les web analystes qui trinquent… Ce qui nous ramène à nos moutons !
Chiffrement, anonymisation, pseudonymisation des user datas : la meilleure piste ?
C’est en effet à cet endroit qu’il y aurait un coup à jouer. Mais les moyens proposés par Google Analytics seuls restent limités…
Le problème des adresses IP avant GA4
Premier point essentiel : Google Analytics a été conçu pour n’enregistrer ou stocker aucune adresse IP individuelle. Toutefois, du moins jusqu’à très récemment, il y avait quand même transfert aux USA pour traitement des données, qui permet de déduire la géolocalisation des utilisateurs.
Il en va de même pour la fonctionnalité de pseudonymisation des IPs, une fonctionnalité d’Universal Analytics qui permet d’en masquer les deux derniers chiffres. C’est insuffisant pour deux raisons :
- la pseudonymisation est effectuée après transfert, donc ça ne règle pas le problème ;
- elle est réversible, donc on lui préfèrera une anonymisation, consistant à délivrer une autre adresse IP ;
Ainsi, même si Google affirme supprimer ou anonymiser les adresses IP immédiatement après réception, la CNIL refuse tout simplement que ces fameuses adresses atterrissent aux USA.
L’avantage des dernières versions de GA4
Tout le problème est là : que l’adresse IP parvienne en entier dans un pays hors de l’Union Européenne et non adéquat, même si elle se trouve anonymisée par la suite.
Mais bonne nouvelle, Google a introduit une mise à jour dans GA4 : l’arrêt pur et simple des transferts d’adresses IP hors de la zone européenne. Comme dirait l’autre : c’est déjà ça de pris !
Anonymisation ou pseudonymisation du client_id : non suffisant
Concernant le client_id, il est tout à fait possible de procéder à son chiffrement (pseudonymisation), voire de le remplacer complètement par un identifiant généré par l’opérateur du site (anonymisation).
C’est une bonne pratique, à condition qu’elle soit mise en œuvre avant tout traitement par GA4. Ce qui nous amène à considérer sérieusement la mise en place d’un proxy.
Une configuration server side de GA4 : la clé pour un Google Analytics 4 RGPD friendly ?
On l’a vu plus haut, dans une configuration client-side (échange direct entre le navigateur et les serveurs américains de Google Analytics), GA4 ne permet pas de contourner le problème majeur posé par la CNIL : le transfert international de données.
En conséquence, la meilleure approche serait de trouver un moyen de rompre tout contact entre le terminal de l’utilisateur et le serveur situé aux États-Unis. Un moyen pour y parvenir réside dans le recours à un serveur mandataire (ou “proxy”), qui serait basé en Europe.
Ce que permet l’utilisation d’un proxy
Cet intermédiaire éviterait tout contact direct entre le terminal de l’internaute et les serveurs de GA4. Là, tout le travail de pseudonymisation et d’anonymisation habituellement assuré par Google serait effectué en amont, donc AVANT tout export aux USA.
Ainsi, par exemple, aucune adresse IP ne sortirait de la zone européenne, puisqu’on aurait la possibilité d’enlever les deux derniers numéros de l’IP, voire davantage. On pourra même aller jusqu’à envoyer systématiquement l’IP de notre serveur pour toutes les requêtes de tous les utilisateurs, pour une totale anonymisation…
Même si, on l’a vu, cet exemple ne s’adresse plus qu’à ceux qui travaillent encore sur Universal Analytics.
Ce que dit l’expert RGPD : solution validée !
Halleluia ! On a senti que vous perdiez espoir au cours de cette lecture mais on tient le bon bout.
Évidemment, il faudra s’assurer que ce serveur remplisse un ensemble de critères pour s’inscrire dans la ligne de ce qui est prévu par le CEPD dans ses recommandations du 18 juin 2021. Sinon, ce serait trop facile !
Les inconvénients du proxy
D’abord, un server side, ce n’est pas gratuit. Ça peut même coûter relativement cher (entre 1500 € et 4000 € à l’année, rien que pour les frais de serveur). Donc malheureusement, tout le monde ne pourra pas adopter cette technique.
En outre, cette étape intermédiaire du traitement des données n’est pas sans conséquences sur le bon usage de Google Analytics.
Vous allez donc devoir adopter une démarche assez subtile, afin d’éviter :
- une approche trop superficielle (et donc sanctionnable) de la mise en conformité. Dans l’ensemble, il s’agira de s’assurer systématiquement qu’aucune des informations transmises à l’outil de mesure ne puissent donner lieu à une réidentification de la personne. C’est vraiment le point le plus important à garder en tête ;
- la perte de fonctionnalités importantes pour le travail d’analyse en ne se focalisant que sur la dimension RGPD de l’outil.
C’est ce que nous allons développer au point suivant.
Google Analytics et RGPD : 6 contraintes juridiques résolubles par des manipulations techniques
Ici, tout l’enjeu va résider dans votre capacité à jongler entre mise en conformité et conservation de la qualité des informations à exploiter. En effet, les exigences du RGPD et d’une web analyse fine obligent au funambulisme sur bien des points…
1. Anonymisation des IPs Universal Analytics : le problème de la géolocalisation des utilisateurs
Certes, l’installation server side assure l’absence de transfert de l’adresse IP vers les serveurs américains, par exemple en en coupant une partie dans un premier temps, AVANT d’envoyer la requête finale chez Google.
Mais dans le cadre d’une anonymisation totale par exemple, si Universal reçoit toujours la même IP, l’outil ne sera plus capable de déduire lui-même la provenance des utilisateurs. C’est un vrai problème du point de vue de la web analyse. Il faudra donc parvenir à configurer le proxy de sorte qu’il puisse lui-même déduire de l’adresse IP la géolocalisation de vos visiteurs.
Nota Bene : le niveau de précision doit garantir contre toute tentative de réidentification de la personne (par exemple, en utilisant un maillage géographique donnant l’assurance d’un certain nombre d’internautes par cellule).
2. Pseudonymisation du client_id
On l’a vu, il est nécessaire de pseudonymiser le client_id. Pour ce faire, le plus intéressant reste de mettre en place un hash, autrement dit une opération de cryptage du client_id, dont la clé sera conservée sur un serveur européen.
Attention à garder un format exploitable par l’outil analytics
En effet, il faudra s’assurer que le hachage n’altère pas le format de la requête envoyée à l’outil d’analyse, sans quoi le traitement ne permettra pas de rendre compte du parcours utilisateur lors de sa session.
En résumé, il faut :
- que le client_id soit haché, donc non lisible et non attribuable à une personne physique ;
- qu’il conserve un format exploitable par Google Analytics afin de suivre chaque interaction du visiteur inconnu lors d’une visite sur le site.
Garantir un bon niveau de collision tout en conservant la notion de “session”
Mieux, il est recommandé de remplacer l’identifiant utilisateur (ou client_id) par le serveur de proxification. L’algorithme chargé de ce remplacement assure alors :
- un niveau de collision suffisant après hachage (à savoir une probabilité assez élevée que deux identifiants donnent un résultat identique après hachage) ;
- l’ajout d’une composante temporelle variable, comme un timestamp, qui sert à compter les secondes (ce qui fait que chaque information envoyée sera différente à cause de la valeur temporelle qui change en permanence).
Cependant, afin de garantir un effet “session”, il faudra faire en sorte que le client_id pseudonymisé soit persistant (qu’il ne soit pas modifié à chaque événement), auquel on collera un timestamp à la première interaction avec le site web visité.
Dès lors, on doit pouvoir analyser un parcours utilisateur, non-identifiable mais complet, à travers plusieurs pages.
Fin (ou suspension) de l’analyse des parcours multi-visite
La technique détaillée ci-dessus se heurte néanmoins à une contrainte : il faut s’assurer que, lorsque l’utilisateur termine sa session puis se reconnecte, il ne soit pas reconnu. Plusieurs manières de procéder :
- soit paramétrer les cookies de manière à ce qu’ils soient tout bonnement supprimés à la sortie de la session ;
- conserver le client_id (haché au préalable) mais réenclencher le time stamp à chaque début de session, ce qui ne laisse aucun moyen de savoir si le visiteur est déjà venu.
En conséquence, on n’a plus que des clients uniques, ce qui, aujourd’hui entrave totalement l’approche multi-visite et multi-canal. Ainsi la notion d’utilisateur au profit de la simple session, au même titre que la notion d’attribution (que nous développons dans notre article sur les AARRR) !
Enfin, outre le travail d’anonymisation de l’IP et la pseudonymisation du client_id, il faudra de surcroît obtenir le consentement de l’utilisateur. Cela va de soi…
3. Suppression de l’information du site référent (ou referrer)
Lorsqu’on reçoit une visite issue d’une redirection depuis un site extérieur, la CNIL demande qu’on ne puisse pas savoir d’où elle provient.
Cela étant, il semble possible de ne pas supprimer complètement l’information, et de retirer uniquement le referrer path, afin de conserver le nom de domaine du site d’origine, comme le font déjà les navigateurs anti-tracking.
D’ailleurs, beaucoup de solutions analytics recommandées par la CNIL ont non seulement accès à des éléments d’informations issus du referrer, mais également sans besoin d’obtenir le consentement des utilisateurs !
4. Suppression des paramètres contenus dans les URLs collectées
Ici, on réfère aux paramètres d’URL permettant un routage interne du site, mais également des UTM, qui permettent de distribuer le trafic selon diverses catégories de provenance (en faisant, par exemple, la distinction entre trafic organique et trafic payant), notamment grâce au referrer.
Néanmoins, difficile de croire que les UTM puissent relever du domaine des données personnelles. Quant à savoir s’il s’agit encore d’une crainte de recoupement d’informations permettant un retracking, rien d’explicite n’a été évoqué à ce sujet.
C’est pourquoi vous pouvez procéder à une AIPD (Analyse d’Impact sur la Protection des Données), afin d’attester de la sécurité de votre propre usage des UTM, et ce justement par toutes les précautions que vous aurez prises en amont. À cet égard, le site de la CNIL met à disposition un outil, le PIA, qui vous facilitera grandement la tâche.
Vous pourrez ensuite ranger votre AIPD dans votre registre de traitement des données personnelles.
5. Modification des informations pouvant contribuer à du fingerprint
Ici, on parle principalement des user-agents, ces espèces d’empreintes informatiques qui varient selon :
- l’appareil de l’utilisateur ;
- la génération de cet appareil ;
- le système d’exploitation utilisé (change selon la version) ;
- le navigateur (idem) ;
- etc.
Le problème des user-agents, c’est que certaines configurations sont plus rares que d’autres. Or, à un certain niveau de rareté, un retracking devient possible. De ce fait, la CNIL demande de remplacer les cas de figure les plus singuliers par des configurations plus standard (ce qui ne chamboulera guère vos statistiques).
C’est d’ailleurs très facile à faire au niveau du server side avant l’envoi de la requête finale aux serveurs de Google Analytics.
Nota Bene : vous pouvez tester votre propre configuration en ligne. Vous pourriez être surpris du résultat !
Conserver les user agents communs : un intérêt légitime
On rappelle que les user agents aident souvent à générer des rapports techniques visant à réparer des problèmes liés aux appareils et aux logiciels qu’ils font tourner. En effet, si votre site s’affiche mal sur le dernier téléphone d’Apple, vous serez plutôt content de le savoir afin d’y remédier au plus vite.
C’est même considéré comme un intérêt légitime, puisque c’est user friendly. Néanmoins, il faudra pouvoir le justifier dans le même registre des activités de traitement que nous avons évoqué au point précédent.
6. Pas de collecte d’identifiants d’un site à l’autre (cross-site) ni déterministe (CRM, unique ID)
Ce dernier point concerne les fonctionnalités user_id (servant à identifier un même utilisateur sur différents appareils suite à une première connexion) et de cross domain tracking (pour suivre un utilisateur entre plusieurs sites).
À l’origine, le cross domain tracking n’est autorisé qu’en Europe, en circuit court si international, et uniquement après consentement.
On peut y avoir recours lorsque l’on tient un restaurant, un camping, un établissement de santé, et tous ces lieux pour lesquels les personnes prennent rendez-vous avant de s’y rendre. Si on n’a pas de solution en interne, on va alors choisir un agenda en ligne, sur lequel vont être redirigés les utilisateurs. Or, il peut être important, toujours dans un souci UX, de connaître les parcours suivis dans leur entièreté (afin de détecter des aller-retours anormaux par exemple, ou pour savoir d’où viennent les réservations).
C’est dans ce cas particulier qu’on met en place un cross-domain tracking faisant le pont entre deux domaines. Ce que réprouve la CNIL, à moins d’obtenir un consentement explicite exprès pour ça et que tous les points évoqués précédemment soient peu ou prou respectés.
Enfin, à l’instar des UTM, il est tout à fait envisageable de justifier le cross-domain tracking comme un intérêt légitime, en suivant exactement la même procédure. Vous pouvez, par exemple, mettre en lumière la nécessité d’une sous-traitance au lieu d’opter pour une solution en interne.
RGPD, CNIL, GA4 : que retenir de tout ça ?
Aujourd’hui, en server side, on peut faire fonctionner GA4 tout en étant conforme RGPD.
Cela étant, il faudra veiller à effectuer tout un travail d’anonymisation et de pseudonymisation des user datas, mettre son registre des traitements des données personnelles à jour et toujours penser votre utilisation de l’outil en termes de réidentification par recoupement et d’intérêt légitime.
Nota Bene : il existe également des pistes à étudier comme Sirdata, Eurelian ou Dot anonymizer, qui peuvent peut-être compléter GA4 et, dans certains cas, remplacer une installation de type server side.
Le chantier de Google
Quoi qu’il en soit, la non-conformité d’une installation client-side de GA4 pourrait évoluer d’ici les prochains mois, car Google a pris très au sérieux les publications de la CNIL. La firme planche donc sur les moyens de fournir des garanties appropriées “pour répondre aux préoccupations concernant l’association éventuelle des données et l’identification des utilisateurs” dans le cadre de l’utilisation de GA4.
À ce titre, les dernières mises à jour incluent :
- l’arrêt du transfert d’adresses IP (on l’a évoqué en début d’article) en dehors de l’UE ;
- la possibilité de désactiver Google Signal, soit l’identification d’un utilisateur sur un appareil connecté à son compte Google (reste à voir si cela relève de l’intérêt légitime) ;
- la possibilité de désactiver la localisation granulaire et la collecte de données sur les appareils au niveau du pays
Rendez-vous pour une veille en septembre, car d’ici là les choses auront probablement bougé !
En vidéo, retrouvez l’origine de cet article :
Vos questions, nos réponses !
Mon client ne se soucie pas des normes RGPD, que faire ?
Si vous faites du web marketing et que votre client n’y connaît rien en RGPD, deux solutions s’offrent à vous. Soit vous lui expliquez les mesures à mettre en place, quitte à inclure certaines tâches de mise en conformité à la facture de votre prestation. Soit vous faites apparaître dans votre contrat que vous n’êtes pas la personne chargée de la protection des données des utilisateurs, afin de ne pas être inquiété en cas de contrôle de la CNIL.
Mise en conformité RGPD, par où commencer ?
Le mieux est de faire appel à un consultant certifié dans la protection des personnelles ou à un DPO (délégué à la protection des données). En visitant votre entreprise, à travers divers entretiens avec ses acteurs, l’expert sera en mesure de dresser la liste de vos commandements RGPD, concernant toutes les données que vous êtes amené à exploiter. Bien sûr, vous restez seul décisionnaire à la fin.
Combien de temps ça prend, une mise en conformité RGPD ?
Si on part de zéro, l’ensemble des tâches à effectuer peut facilement prendre entre 18 mois et 2 ans !
Registre de traitement des données personnelles : à quoi ça sert ?
Il s’agit d’un classeur de format physique ou numérique recensant tous les types de traitement de données qui servent à votre activité. On y trouve des fiches qui récapitulent les besoins liés à ces traitements, les agents et logiciels chargés de leur exécution, les personnes concernées, etc. Grâce à ce registre, vous pouvez justifier votre politique RGPD lors d’un contrôle de la CNIL. Ainsi, en cas de mésinterprétation des consignes de votre part, vous attestez de votre bonne foi et ne risquez, en principe, pas de sanction pécuniaire.
Quelles sanctions risque-t-on en cas de non mise en conformité RGPD ?
Si vous avez un registre de traitement des données personnelles mis à jour, normalement, le pire qui puisse arriver est un avertissement public. Mais en cas de contrôle de la CNIL et qu’aucun document ne justifie des pratiques jugées répréhensibles, vous pouvez écoper d’amendes allant jusqu’à 500 €… par jour de retard sur la mise en conformité RGPD de votre entreprise !
