Le consentement et le droit à l'oubli

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 5 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Précédent : Les lois sur la protection des données façonnent la conception · Suivant : Protéger, conserver et prouver

La question à laquelle répond ce module : comment concevoir pour le consentement, et pour l’effacement d’une personne ?

Steve Trucking a le numéro de téléphone d’un destinataire. Question simple : pouvons-nous lui envoyer un SMS ? Peut-être. À propos de la livraison d’aujourd’hui ? De celle de demain ? Pouvons-nous utiliser le numéro pour une promotion ? Et s’il a dit non aux SMS, ou oui aux mises à jour de livraison mais non au marketing, puis a changé d’avis ?

Maintenant, l’autre sens. Le destinataire dit : supprimez mes informations personnelles. Où sont-elles ? Dans Salesforce, probablement, mais nous avons appris que ce n’est pas toute la réponse. Elles venaient d’un partenaire distributeur. Elles peuvent être dans une plateforme de données client, l’historique des champs, une archive, une note de livraison, un export, un journal d’intégration, la conversation d’un agent. Le consentement et la suppression ressemblent à des questions de politique, mais au bout du compte, c’est le système qui doit y répondre. C’est de l’architecture.

Le consentement est une donnée

Le premier principe : le consentement est une donnée. Ne le réduisez pas à Has_Opted_In__c = true. La vraie question n’est jamais seulement « a-t-il consenti ? » C’est consenti à quoi, par quel canal, à quelle adresse ou quel numéro, pour quelle finalité, quand, cela a-t-il changé, et pouvons-nous le prouver ? Si le métier prend des décisions sur ces réponses, elles doivent être stockées comme données structurées. Un paragraphe dans une politique de confidentialité ne suffit pas, et une case à cocher sur un formulaire web non plus : la case capture un événement ; l’architecture doit garder ce que l’événement signifie.

Utilisez le modèle que Salesforce a déjà construit

Ma position : utilisez le modèle de consentement standard chaque fois que vous le pouvez, plutôt que de reconstruire la même chose dans des champs personnalisés. Le modèle de données de consentement de Salesforce gère le consentement à quatre niveaux, chacun étant une question plus précise (Understand the Salesforce Consent Data Model (opens in a new tab), en anglais) :

• Le consentement global, sur l’individu (Individual) : qui est cette personne, et a-t-elle dit non à tout ?
• Le consentement par canal d’engagement (Contact Point Type Consent) : pouvons-nous utiliser ce type de canal, comme le SMS ou le courriel ?
• Le consentement par point de contact : et pour ce numéro de téléphone ou cette adresse courriel précis ?
• La finalité d’utilisation des données (Data Use Purpose) : pour quelle raison : notifications de livraison, service, marketing ?

Mis ensemble, ils permettent à l’architecture de répondre à « pouvons-nous utiliser les informations de cette personne, par ce point de contact, pour cette finalité ? », ce qui est bien plus utile que « consentement = oui ». Tout enregistrement lié à un individu peut y participer : pistes, contacts, comptes personnels, utilisateurs.

Click to enlarge

Quatre questions, chacune plus étroite que la précédente. Une seule case d’opt-in ne répond bien à aucune d’elles.

La finalité compte

Un partenaire distributeur envoie à Steve Trucking le numéro d’un destinataire pour que l’équipe puisse coordonner la livraison. Cela ne fait pas du destinataire une piste marketing. Les mêmes données peuvent avoir des utilisations autorisées différentes : coordination de la livraison, suivi du service, marketing, personnalisation par l’IA. Si la politique ou la loi les traite différemment, le modèle doit les distinguer. La question n’est pas avons-nous le numéro de téléphone ? C’est qu’avons-nous le droit d’en faire ?

Et le consentement n’est pas toujours la base juridique. Certaines utilisations reposent sur d’autres fondements prévus par la loi, et c’est au service juridique de le déterminer. Ne construisez pas une architecture qui suppose que chaque décision de protection des données est une case d’acceptation. Prenez en charge ce que dit la politique : si une utilisation dépend du consentement, modélisez et appliquez le consentement ; si une autre base s’applique, stockez quand même ce qu’il faut pour décider si l’utilisation est autorisée.

Le consentement a un cycle de vie et une autorité

Les gens donnent leur consentement, le retirent, changent de préférences, changent de numéro. Le métier ajoute de nouvelles finalités ; les lois changent. Concevez donc le cycle de vie : ce qui a été choisi, quand, comment, pour quelle finalité, et ce qui se passe en cas de retrait. Et c’est là que ça devient intéressant : quand un destinataire retire son consentement, Salesforce le sait. Et la plateforme de messagerie ? L’analytique ? L’agent ? Un consentement qui vit dans un système pendant que d’autres agissent sur une autorisation périmée n’est pas un vrai contrôle.

Cela veut dire demander quel système fait autorité pour le consentement. Salesforce, une plateforme de gestion des préférences, autre chose ? Quelle que soit la réponse, ne laissez pas cinq systèmes décider chacun de leur côté si la même personne a accepté la même utilisation. Le consentement a besoin de ce dont toute donnée gouvernée a besoin : un propriétaire, un enregistrement qui fait autorité, un moyen de synchroniser, et une application.

Maintenant, la personne dit : oubliez-moi

Le premier réflexe est de supprimer le contact et de considérer l’affaire réglée. Mais les données de la personne peuvent se trouver sur un contact, une livraison, une note de livraison, une requête, une photo, dans l’historique des champs, dans Snowflake, dans une archive, un journal d’intégration, un index de recherche ou l’historique de conversation d’un agent. C’est pourquoi ma position sur l’effacement commence plus tôt : la suppression est rare et difficile en pratique, alors contrôlez d’abord où vont les données personnelles. Concevez pour qu’elles atterrissent au plus petit nombre d’endroits possible. Puis, quand une demande arrive, masquez-les ou dissociez-les là où cela satisfait la politique, et traquez chaque copie : historique des champs, archives, Data 360, et maintenant index de recherche et conversations des agents.

Ne commencez pas la traque quand la demande arrive. À ce moment-là, il est trop tard pour commencer à comprendre le paysage. Le dictionnaire, le lignage et la classification du module 3 n’étaient pas de la paperasse ; ce sont eux qui rendent cela possible. Vous savez déjà quels champs contiennent des données personnelles et où sont allées les copies.

Click to enlarge

Une demande d’oubli, c’est une décision pour chaque copie.

Le compte à rebours est lancé

Ces demandes ont des délais. Selon le RGPD, l’organisation doit donner suite à la demande d’une personne dans les meilleurs délais et au plus tard dans un délai d’un mois à compter de sa réception ; pour des demandes complexes ou nombreuses, ce délai peut être prolongé de deux mois, mais la personne doit en être informée dans le premier mois, avec les motifs (article 12, paragraphe 3, règlement (UE) 2016/679 (opens in a new tab)). D’autres lois fixent leurs propres délais ; le juridique vous dira lesquels s’appliquent. Dans tous les cas, un mois ne suffit pas pour découvrir le paysage. C’est ce délai que la carte des copies doit battre.

Supprimer, désidentifier ou conserver ?

Une demande ne veut pas forcément dire que tout disparaît partout. Certains enregistrements doivent ou peuvent être conservés ; certains enregistrements opérationnels peuvent rester mais cesser d’identifier la personne ; certaines données peuvent être désidentifiées. La politique et la loi applicables décident ; l’architecture prend en charge chaque résultat, endroit par endroit : supprimer, désidentifier, ou conserver selon une exigence approuvée (et alors, qui peut les voir, pendant combien de temps, pourquoi ?).

Souvenez-vous de la distinction du module 4. Dissocier ne vaut oubli que si la personne ne peut pas raisonnablement être réidentifiée. Les données pseudonymisées restent des données personnelles. N’utilisez pas le masquage comme raccourci pour contourner une exigence légale.

On ne peut pas supprimer ce qu’on ne trouve pas

Avant de pouvoir effacer quelqu’un, il faut le trouver. La demande arrive depuis une adresse courriel. Un partenaire distributeur a envoyé « Jane Smith », un autre « J. Smith », et le numéro de téléphone a changé. Le destinataire n’est pas du tout un contact ; ses coordonnées sont sur chaque livraison. La même personne a reçu des livraisons pour deux partenaires différents. Un système la connaît par son courriel, un autre par un ID externe. L’effacement dépend de l’identité, et vous ne voulez pas supprimer les données de quelqu’un d’autre parce que votre rapprochement était trop agressif. L’architecture de l’identité fait partie de l’architecture de la protection des données.

Steve Trucking rend cela plus difficile encore. Un partenaire distributeur ne doit jamais voir les livraisons ni les destinataires d’un autre. Si la même personne a reçu des livraisons pour deux partenaires, les opérations doivent garder ces relations séparées, alors que la protection des données peut quand même avoir besoin de retrouver la personne dans les deux. Ne résolvez pas la protection des données en cassant la frontière de sécurité, et ne protégez pas la frontière en rendant les demandes de protection des données impossibles. L’architecture doit faire les deux.

Les photos et le texte libre sont aussi des données

Il est facile de penser la protection des données en termes de champs : nom, courriel, téléphone, adresse. Mais Steve Trucking prend des millions de photos de livraison par an, et certaines montrent des personnes ou l’intérieur d’un domicile. Une politique de conservation ou d’effacement qui ne regarde que les champs structurés est incomplète ; de même qu’une politique qui ignore les fichiers, les documents, les transcriptions, les journaux, et les prompts et réponses de l’IA.

Et le texte libre est dangereux. Vous retirez le nom, le téléphone et l’adresse, puis vous trouvez cette note de livraison : « Appeler Jane au 602-555-0198. Code du portail 4821. Le chien est dans le jardin. » Les voilà. Classer les notes de livraison comme sensibles vous dit qu’il peut y avoir un problème ; cela ne trouve pas et ne retire pas les données personnelles à l’intérieur du texte. Parfois, la meilleure réponse est d’empêcher que des détails personnels inutiles y arrivent. Contrôlez d’abord où vont les données personnelles.

Privacy Center est un outil, pas toute l’architecture

Salesforce Privacy Center aide à faire tourner ces processus. Ses politiques de droit à l’oubli se construisent objet par objet, pour capturer tout ce que vous voulez retirer, et s’exécutent sur la fiche d’un client précis (Delete Data with Right to Be Forgotten Policies (opens in a new tab), en anglais). C’est utile. Mais « nous avons acheté Privacy Center, donc c’est réglé » n’est pas une architecture. Les données de la personne peuvent vivre hors de portée d’un outil donné : Data 360, l’entrepôt de données, les systèmes des partenaires, les archives, les journaux, la recherche, les fichiers, les conversations des agents. L’entreprise a toujours besoin d’une réponse d’entreprise, et vous devez vérifier ce que couvre réellement chaque outil avant de vous y fier.

Portabilité et preuve

Certaines lois donnent aussi aux personnes le droit d’obtenir une copie de leurs données. Remarquez que c’est le même problème de découverte : la suppression demande où sont les données de cette personne, pour que nous puissions agir ? La portabilité demande où sont-elles, pour que nous puissions les fournir ? Les deux reposent sur l’identité, la classification, le lignage, l’inventaire des systèmes et la propriété.

Et ensuite : comment prouvez-vous que vous l’avez fait ? Demande reçue, identité vérifiée, systèmes parcourus, actions menées, exceptions consignées, données conservées justifiées, achèvement journalisé. Il y a ici une vraie tension : vous retirez les données personnelles de quelqu’un tout en gardant assez de preuves pour montrer que vous avez traité la demande correctement. C’est exactement pourquoi les architectes ne doivent pas inventer seuls les règles de conservation. Les équipes juridiques et conformité décident quelles preuves doivent rester ; l’architecture les garde sans garder les données qu’elle était censée retirer.

Au-delà de l’examen : ce que l’IA change. L’IA crée de nouvelles finalités et de nouvelles copies. L’autorisation d’utiliser des données pour fournir un service ne couvre pas automatiquement l’ancrage d’un agent, la personnalisation ou l’entraînement ; la finalité d’utilisation des données (Data Use Purpose) est l’endroit naturel pour les distinguer. Et les données personnelles peuvent survivre dans les prompts, le contexte d’ancrage, les conversations, les résumés, les index de recherche et vectoriels, et les journaux. « Nous avons supprimé l’enregistrement source » n’est pas une réponse complète si la couche d’IA s’en souvient encore.

Ce qu’un architecte décide ici

• Comment le consentement et l’utilisation autorisée sont modélisés, pour que les systèmes puissent répondre : qui, quel canal, quel point de contact et quelle finalité.
• Quel système fait autorité pour le consentement, et comment les retraits atteignent chaque système qui agit en conséquence.
• Où les données personnelles peuvent se répandre : champs, texte libre, fichiers, historique, analytique, archives, intégrations, recherche et IA.
• Comment une demande trouve la bonne personne et déclenche la suppression, la désidentification ou une conservation approuvée à chaque endroit.
• Quelles preuves restent pour montrer que le consentement et les demandes de protection des données ont été traités.

Le consentement et l’effacement ont l’air opposés (pouvons-nous utiliser ces données ? pouvons-nous arrêter et les retirer ?) mais ils reposent sur les mêmes fondations : identité, finalité, classification, lignage, propriété, application et preuves. Utilisez le modèle de consentement standard, contrôlez où vont les données personnelles, sachez où sont les copies, et concevez le processus d’effacement avant que la première demande n’arrive. Quand quelqu’un demande « pouvez-vous m’oublier ? », l’architecture a besoin d’une meilleure réponse que « nous pensons que oui ».

Pour aller plus loin

• Aide Salesforce, Understand the Salesforce Consent Data Model (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Règlement (UE) 2016/679 (RGPD) (opens in a new tab), article 12, paragraphe 3, le délai pour donner suite à une demande, consulté le 2026-10-14.
• Aide Salesforce, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, en anglais), consulté le 2026-10-14.