Un bon moyen de réduire les risques pour les utilisateurs consiste à ne pas conserver de données sensibles les concernant dont vous n'avez pas besoin et qui ont un impact sur leur confidentialité. Il existe un nombre surprenant de méthodes pour y parvenir tout en atteignant vos objectifs commerciaux, et chacune d'entre elles est intéressante. Vous pouvez:
- Expliquez pourquoi vous avez besoin de ces données.
- Collecter les données avec un niveau de précision inférieur
- Supprimez les données une fois utilisées.
- Ne pas les collecter en premier lieu.
Chacune de ces approches peut aider vos utilisateurs à se sentir plus à l'aise avec ce que vous faites et pourquoi, ce qui contribue grandement à votre relation avec eux. La transparence renforce la confiance et, surtout, elle peut être un argument de vente unique pour vous. De nombreuses personnes partent du principe que les utilisateurs et les clients leur font confiance par défaut, mais les consommateurs évaluent constamment les produits et services, ce qui n'est pas toujours le cas. Si vous établissez une relation avec vos utilisateurs dans laquelle ils vous font confiance pour gérer leurs données et vos interactions avec respect, cela peut vous offrir un avantage concurrentiel en tant que projet ou entreprise: c'est quelque chose que vos concurrents peuvent ne pas correspondre, un véritable facteur de différenciation.
Examinons les approches ci-dessus, de la plus efficace (mais aussi ayant le plus d'impact sur votre entreprise) à la moins efficace à mettre en œuvre, mais la moins perturbatrice.
Ne les collectez pas en premier lieu.
Le moyen le plus évident d'éviter de compromettre les données de vos utilisateurs est de ne pas les collecter. Une certaine collecte de données est nécessaire pour fournir des services, mais il existe plus d'endroits où vous pouvez éviter la collecte de données que vous ne le pensez. Prenons l'exemple du paiement sans connexion. Lorsque les utilisateurs viennent effectuer un achat via votre application Web, vous pouvez leur demander de créer un compte, car vous avez alors collecté des informations personnelles pour un traitement ultérieur: ils peuvent être ajoutés à la liste de diffusion, ils sont déjà préqualifiés en tant que clients intéressés, etc. Toutefois, les clients le sont, et ils ne l'apprécient pas : en 2021, une étude a révélé qu'une vente abandonnée sur quatre était due au fait que le site exigeait que l'utilisateur crée un compte. Si vous n'en avez pas besoin, vous avez plus de chances de conserver ces clients. Permettre aux utilisateurs d'effectuer un achat sans s'inscrire offre de meilleures options aux utilisateurs, et signifie que vous n'avez pas autant de données à protéger et à sécuriser.
« Faites un plein d'énergie » pour vos données
Évidemment, il n'est pas toujours possible d'éviter de collecter des données. Il est important de collecter des données pour fournir des services et prendre des décisions commerciales raisonnables. Il peut également être utile d'établir des communications marketing dans le contexte d'une relation de confiance. Cependant, il est également important de comprendre que les décisions prises de façon agrégée (c'est-à-dire, qui concernent de nombreux utilisateurs à la fois) sont prises à propos des données agrégées (c'est-à-dire, concernant les propriétés collectives des données).
Par exemple, il est parfois utile d'avoir une idée des caractéristiques démographiques de votre audience: la tranche d'âge dans laquelle elle appartient, sa zone géographique, etc. Cela peut modifier votre message ou votre approche. Toutefois, cela ne signifie pas que vous devez collecter l'âge exact de chaque utilisateur de votre service. Ce que vous recherchez souvent, ce sont les tendances et les propriétés globales. Si la décision à laquelle vous souhaitez vous adresser dépend du fait que la majorité de votre audience appartient ou non à la "catégorie démographique clé des 18-34 ans", la seule question à se poser est de savoir si vos utilisateurs font partie de cette catégorie démographique. Elles sont alors regroupées dans deux "buckets": dans ce groupe et non dans celui-ci. Dans certains cas, vous aurez besoin de données plus précises, mais il est tout à fait raisonnable de prendre la liste des données démographiques que vous utilisez pour prendre des décisions et de demander à vos utilisateurs de se classer à l'aide de cette liste.
Exemple
Ainsi, s'il est utile de connaître la répartition de votre base d'utilisateurs entre les tranches d'âge "18-34", "35-49", "49-64" et "65 ans et plus", vous pouvez demander à vos utilisateurs de choisir la catégorie dans laquelle ils appartiennent. Il est tentant de demander des données extrêmement précises, personnelles et personnalisées, puis de classer vous-même vos utilisateurs, car cela évite d'avoir à poser à nouveau la même question plus en détail par la suite (par exemple, pour demander un âge et une date de naissance exacts, puis vous en servir pour générer vos propres listes du nombre d'utilisateurs dans la catégorie "35-49"). Toutefois, il est important de comprendre à quoi cela ressemble: comme nous l'avons déjà vu dans ce cours et que nous le verrons plus en détail, demander des niveaux de données détaillés peut mettre les gens mal à l'aise et diminuer la confiance des utilisateurs envers votre organisation, tout en augmentant les risques.
Il est également important de tenir compte de vos besoins en données. Parfois, le "besoin" de données plus granulaires est spéculatif, une exigence "juste au cas où". Peut-être n'avons-nous besoin pour le moment que de classer les utilisateurs dans ces quatre tranches d'âge, mais à l'avenir, nous pourrions vouloir restreindre cette catégorie. Nous devrions donc recueillir des données très détaillées maintenant pour garder cette option ouverte pour plus tard. Il peut être intéressant d'envisager la fréquence à laquelle des données plus précises ont été utilisées dans le passé pour guider les décisions. Le fait de demander des données perçues comme invasives par rapport au service proposé entraîne nécessairement une diminution de la confiance des utilisateurs envers votre organisation. Si ces données sont collectées pour des raisons "juste au cas", vous risquez non seulement de perdre la confiance des utilisateurs au profit de décisions commerciales améliorées, mais aussi de la négliger simplement pour la possibilité d'une décision future théorique qui n'existe peut-être pas, tout en répondant aux exigences de sécurité pour ces informations.
Des algorithmes plus détaillés permettent également de réduire la précision des données collectées. Les méthodes de réponse randomisée signifient que les données sont collectées avec un degré d'imprécision ajustable. Elles sont utilisées depuis des décennies dans les sciences sociales lors de la collecte de données potentiellement invasives ou sensibles tout en préservant la confidentialité des personnes interrogées. La méthode de collecte de données ci-dessus implique d'élargir les réponses de l'utilisateur (afin que "quel âge avez-vous" devient "à quelle tranche d'âge appartenez-vous"), où la réponse aléatoire implique qu'une certaine proportion d'utilisateurs mentent sur leurs réponses. Si la proportion d'utilisateurs qui répondent de manière incorrecte est connue, des conclusions significatives peuvent toujours être tirées des données collectées, mais la confidentialité des utilisateurs individuels n'est pas compromise, car les données collectées peuvent être incorrectes. Dans ce cas, si 80% de votre audience indique toujours qu'elle appartient à la catégorie démographique 18-34 ans, vous pouvez être relativement sûr que cette part reste la plus importante, même si 10% d'entre eux donnent délibérément des réponses incorrectes. Le degré d'inexactitude peut également être modifié par programmation : les bonnes réponses sont toujours demandées, mais le logiciel modifie un certain pourcentage de réponses avant de les transmettre. Ce processus et ses conséquences peuvent également être expliqués aux utilisateurs lors de la collecte de données: cela signifie que les utilisateurs n'ont pas à croire que vous n'utiliserez pas leurs données collectées de manière abusive, car les données individuelles ne sont pas fiables.
La confidentialité différentielle est un processus similaire, mais plus techniquement complexe. Elle utilise des techniques mathématiques pour modifier le stockage des données de sorte que les propriétés agrégées des données soient toujours présentes, mais il n'est même pas possible de savoir si un individu particulier a même fourni des données, ou si des données ont été fournies. Comme pour les réponses aléatoires, cela protège les données des utilisateurs, même de vous, et démontre une intention claire de votre part : vous ne pouvez pas utiliser les données de vos utilisateurs si vous ne disposez pas de ces données.
Ces approches et des approches similaires offrent également une sécurité accrue contre les violations et les fuites de données, car les données collectées réduisent les compromissions concernant la confidentialité des utilisateurs, y compris vous-même, ainsi que le niveau de compromission en cas de fuite. Toutefois, n'oubliez pas que si vous appliquez des techniques de confidentialité différentielle sur le serveur (afin que vos utilisateurs vous envoient des données non agrégées, puis que vous vous servez de ces techniques pour les agréger), vous devez tout de même sécuriser ces données utilisateur brutes, puis les supprimer après le traitement. Vous devez également appliquer des règles claires pour confirmer que vous ne les utilisez pas avant l'agrégation (ou que vous savez clairement à quoi elles servent).
Conservation: collectez des données et supprimez-les lorsqu'elles sont utilisées
Il est utile de se rappeler que les données collectées ont un cycle de vie : elles sont collectées, utilisées pour vous aider à prendre des décisions commerciales, puis, à un moment donné, elles doivent être supprimées. Il s'agit là encore de compromis: lorsque vous posez des questions à vos utilisateurs, que vous stockez des informations sur d'autres sites Web qu'ils ont consultés, ou que vous suivez les éléments qu'ils ont consultés et pendant combien de temps afin de faire des prévisions sur leurs préférences, ces données vous sont accordées dans un but spécifique, et non comme une subvention ouverte que le développeur peut utiliser comme il le souhaite. Lorsque ces données ne sont plus nécessaires à cette fin (parfois après une minute, parfois après de nombreuses années), elles doivent être supprimées.
Chaque fois que vous recueillez des informations sur vos utilisateurs, vous devez savoir à quelles fins vous les utiliserez (voir ci-dessous), et quand et pourquoi vous cesserez de les conserver. Cela peut se produire lorsque l'utilisateur choisit de le supprimer, qu'il se déconnecte, après une période spécifique ou après un événement spécifique. Un excellent moyen de renforcer la confiance dans cette relation consiste à indiquer clairement à vos utilisateurs comment ils peuvent contrôler les données les concernant, y compris, dans la mesure du possible, une désactivation unilatérale. Comment suppriment-ils leurs données ? Comment peut-il supprimer son compte ? En plus de vous aider à établir cette relation, il est recommandé de stocker les données aussi longtemps que nécessaire pour les traiter, et non plus longtemps. En outre, vos utilisateurs doivent disposer d'un moyen de voir et de supprimer les données que vous collectez chez eux ou en leur nom. Il se peut même qu'il existe une législation à ce sujet dans les territoires dans lesquels vous opérez.
Il s'agit d'un domaine dans lequel vous pouvez définir des objectifs techniques clairs, ce qui aide les utilisateurs en libre-service. Si vos utilisateurs peuvent se désinscrire de votre entrepôt de données sans avoir à demander l'autorisation, ils sont beaucoup plus à l'aise pour s'inscrire, et cela ne nécessite aucune ressource d'assistance pour le faire.
Il est important de reconnaître l'importance de la désactivation simple et par défaut: "Pour instaurer la confiance et la reconnaissance, les entreprises peuvent commencer par accepter un contrat social dans lequel elles s'engagent à respecter leur audience à chaque point de contact, à écouter leurs besoins et à y répondre en conséquence", explique l'IAPP. Selon Nielsen Norman Group, les utilisateurs "ont besoin d'une 'sortie d'urgence' clairement marquée' pour quitter l'action indésirable sans avoir à subir un processus prolongé". Tout le monde sait qu'il est plus facile de s'abonner que de se désabonner. Toutefois, comme l'indique Nielsen Norman, le fait d'offrir aux utilisateurs la possibilité de partir sans avoir à sauter des paniers "renforce un sentiment de liberté et de confiance". Des études universitaires appuient ce point et l'appellent le "principe de révocabilité" : "L'interface doit permettre à l'utilisateur de révoquer facilement les autorisations qu'il a accordées, chaque fois que la révocation est possible. Les utilisateurs doivent pouvoir révoquer ce consentement et, par conséquent, réduire si possible les autorités à accéder à leurs ressources." (Voir Yee et Iacono pour des exemples.)
La durée de conservation et la nature des données à conserver sont des sujets qui diffèrent considérablement entre les organisations et les projets, mais il convient de prendre en compte certaines consignes communes.
À faire
Elle est utile ici pour permettre aux utilisateurs de supprimer des comptes (et toutes les données associées, si possible) et d'effacer régulièrement les données éphémères et stockées localement (lors de la déconnexion, par exemple) à la déconnexion avec l'en-tête Clear-Site-Data.
Fournissez un en-tête Clear-Site-Data pour supprimer tout ou partie des données utilisateur qui ont été stockées côté client (que ce soit dans les cookies, localStorage, IndexedDB ou le cache du navigateur), lorsque cela est raisonnable. Le cas d'utilisation évident de l'option "Clear-Site-Data" est lorsqu'un utilisateur se déconnecte, mais elle peut également être utilisée après des incidents de sécurité pour s'assurer qu'un compte potentiellement piraté ne conserve aucune trace de données compromises stockées sur le client.
La prise en charge de Clear-Site-Data implique l'envoi d'un en-tête HTTP, Clear-Site-Data, lorsque l'utilisateur se déconnecte (ou, à d'autres moments, lorsque vous souhaitez effacer l'espace de stockage côté client), sur la page qui confirme l'état de déconnexion (https://your-site/logout ou similaire). Cet en-tête peut avoir tout ou partie des valeurs suivantes, ou "*" pour toutes:
Clear-Site-Data: "cache", "cookies", "storage"
Ces valeurs effacent, respectivement, les pages mises en cache (et les autres ressources en cache HTTP), les cookies stockés, localStorage et IndexedDB, et autres.
Vous verrez peut-être une référence à une autre option, executionContexts, mais de nombreux navigateurs ne la prennent pas en charge.
Notez qu'il sera probablement plus facile d'utiliser l'en-tête Clear-Site-Data que de supprimer individuellement toutes les ressources créées vous-même, car il ne nécessite pas l'exécution de code JavaScript sur le client (et c'est le seul moyen officiel de vider le cache du navigateur), mais il n'est pas compatible avec tous les navigateurs.
Remarque d'utilisation: Si vous videz le cache (en envoyant Clear-Site-Data: cache), l'en-tête Clear-Site-Data ne doit pas être envoyé sur votre page de déconnexion réelle. Toutefois, la page se charge sur d'autres ressources. En effet, sur un ordinateur plus lent avec un cache volumineux, la page se bloque pendant le nettoyage du cache, ce qui empêche la navigation. Cela peut prendre quelques minutes, ce qui frustre l'utilisateur. Cela est peu probable, mais il est difficile à tester et il est donc recommandé de le garder à l'esprit.
Expliquer ce pour quoi vous avez besoin des données
Nous avons répété l'importance de la confiance dans la relation de vos utilisateurs avec votre service, car cela augmente la longévité des utilisateurs. Elle offre également un avantage concurrentiel. Une façon d'augmenter ce niveau de confiance consiste à assurer la transparence de vos processus. Un bon moyen d'être transparent consiste à expliquer pourquoi vous souhaitez obtenir des données. Vous avez appris précédemment que pour chaque élément collecté, vous devez savoir quand cet élément sera supprimé. Pour le savoir, vous devez savoir pourquoi vous souhaitez obtenir ces données, quelles questions spécifiques en ont besoin pour obtenir des réponses et quelles décisions seront guidées par leur collecte. Une fois que vous savez pourquoi vous avez besoin de ces données que vous avez demandé à votre utilisateur d'abandonner, cela vous aidera à gagner la confiance des utilisateurs en les expliquant. Dans vos règles de confidentialité ou lorsque vous posez des questions sur la création d'un compte, décrivez pourquoi vous avez besoin d'une réponse à cette question spécifique, ce que vous allez faire de ces données, et quand et comment elles peuvent être supprimées.
Ces explications sont beaucoup plus visibles lorsqu'elles sont présentées de manière intégrée. Des explications cachées dans un document de politique dense ailleurs sur le site Web peuvent sembler être une tentative de les dissimuler. Un formulaire d'inscription, de règlement ou de demande peut présenter les raisons de collecter des données en plus de la collecte elle-même. Souvent, un champ de formulaire peut comporter un astérisque (*) pour indiquer qu'un champ est requis. Les formulaires complexes comportent souvent un lien d'information (i) pour expliquer la signification du champ. Pensez à ajouter à ces explications une description des raisons pour lesquelles les données sont collectées. La phrase "Pourquoi avons-nous besoin de ce code ?" est fréquemment utilisée à côté d'un champ de formulaire. Lorsque vous cliquez dessus, une fenêtre pop-up d'explication s'affiche.
Certains exemples de code HTML peuvent se présenter comme suit. CSS et JavaScript se chargent de masquer le <aside> et de l'afficher dans une fenêtre pop-up lorsque l'utilisateur clique sur le lien. (N'oubliez pas de confirmer l'accessibilité du formulaire que vous créez pour votre site.)
La manière exacte de les présenter dépend de vos styles et de vos approches, mais le principal point ici est d'associer directement la collecte de données à une explication des raisons pour lesquelles ces données sont collectées. Cette opération n'est pas nécessaire pour chaque champ. Personne n'a besoin d'explications expliquant pourquoi vous lui demandez de choisir un mot de passe lors de l'inscription. Toutefois, décorer chaque demande d'informations personnelles et de contact avec la manière dont vous prévoyez de les utiliser et de les conserver peut permettre d'indiquer clairement à vos utilisateurs que vous vous engagez à protéger leurs données.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
Suivre ce processus avec tout ce que vous collectez sur un utilisateur peut également faciliter les processus et les discussions internes. Précédemment, vous avez vu à quel point il peut être tentant de collecter des données "au cas où". Si vous êtes transparent sur les raisons de votre collecte, il peut être tout à fait évident que cela se produit. Si vous êtes réticent à indiquer publiquement ce que vous voulez faire des données utilisateur parce que ces utilisateurs n'apprécieront pas l'explication, cela peut indiquer qu'il est utile de repenser leur collecte. Cela s'applique si l'explication désagréable est trop invasive ("nous l'utiliserons pour suivre l'endroit où vous vous rendez toutes les heures"), trop étendue ("nous ne savons pas encore à quoi servira cette explication, mais nous la voulons au cas où nous y réfléchissons") ou trop évasives ("nous l'utiliserons à des fins internes non divulguées"). Il ne s'agit pas seulement d'une question de moralité. Les gens sont assez intelligents pour le reconnaître, comme déjà décrit, et les utilisateurs s'attendent à ce qu'expérimenter quelque chose ne soit pas le début d'un engagement à long terme. La conception de l'expérience utilisateur est monnaie courante pour rendre l'inscription aussi simple et fluide que possible, car au début, l'utilisateur n'est pas fortement investi dans votre service. Il est donc important de lui permettre de s'investir facilement lorsqu'il a encore peu de envie de le faire. S'il est aussi facile de quitter le service, il ne s'agit pas d'un engagement à long terme forcé. Comme précédemment, il est paradoxal, mais vrai, que le meilleur moyen d'instaurer un climat de confiance est de ne pas exiger des utilisateurs qu'ils vous fassent confiance s'ils ne le souhaitent pas.
Les gens ont de bonnes raisons de ne pas partager des données ou de partager un minimum de données. Au début de votre relation avec eux, ils n'ont peut-être pas de raison de vous faire confiance, et ne devraient pas avoir à le faire. Votre objectif est de démontrer pourquoi ils devraient.
À faire
- Décidez pour toutes les données que vous prévoyez de recueillir pourquoi vous les voulez et combien de temps vous les conserverez.
- Lorsque vous demandez ces données, expliquez à vos utilisateurs pourquoi vous les collectez.
- Supprimez-le de vos bases de données serveur après l'avoir utilisé.
- Autoriser les utilisateurs à supprimer les comptes qu'ils ont créés et à effacer les données stockées de leur espace de stockage avec l'en-tête
Clear-Site-Data.
Pourquoi
Créer une relation avec vos utilisateurs est une question de confiance, laquelle dépend de l'ouverture. Si vous pouvez démontrer que vous ne vous contentez pas de collecter autant de données que possible sur vos utilisateurs et de dissimuler leurs utilisations, cela vous aide à gagner la confiance des utilisateurs, ce qui peut être un avantage concurrentiel pour vous par rapport à des concurrents moins scrupuleux.