Les lois sur la protection des données façonnent la conception

🌐 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 4 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Précédent : Connaître ses données · Suivant : Le consentement et le droit à l’oubli

La question à laquelle répond ce module : qu’exigent les réglementations sur la protection des données et les réglementations sectorielles d’une conception Salesforce ?

Quand je travaillais en Australie, j’ai rencontré beaucoup d’aspirants architectes qui n’avaient jamais entendu parler du RGPD. Les Européens, souvent, n’ont jamais entendu parler de la loi californienne sur la protection des données, ni de celle du Canada, ni de celle du Brésil. C’est naturel : on connaît les règles là où l’on travaille. Mais ces lois franchissent les frontières, et elles façonnent la conception des systèmes même si aucune ne parle de Salesforce. Elles ont donc leur place dans un cours d’architecture de données.

Vous n’avez pas besoin de devenir avocat. Vous devez en revanche voir qu’une réglementation peut changer l’endroit où les données sont stockées, ce que vous collectez, qui les voit, pourquoi vous pouvez les utiliser, combien de temps vous les gardez, où vous les envoyez, si vous pouvez les supprimer, quel historique vous conservez, et ce que vous pourrez prouver plus tard. Ce ne sont pas seulement des questions juridiques. Ce sont des questions d’architecture de données.

Ce module est un guide d’architecture, pas un avis juridique. Les équipes juridiques et conformité décident quelles lois s’appliquent et ce qu’elles exigent. L’architecte transforme ces exigences en une conception applicable.

Les lois ne s’arrêtent pas à la frontière

D’abord le plus gros malentendu : « nous ne sommes pas en Europe, donc le RGPD ne s’applique pas ». Peut-être, peut-être pas. Le champ d’application territorial du RGPD s’étend aux organisations situées hors de l’UE qui proposent des biens ou des services à des personnes dans l’UE, ou qui y suivent leur comportement (article 3, Règlement (UE) 2016/679 (opens in a new tab)). L’endroit où se trouve le siège de votre entreprise ne clôt donc pas la question. Où sont vos clients, vos employés, les personnes dont vous détenez les données, vos systèmes, vos sous-traitants ? Où voyagent les données ? C’est de nouveau le paysage du chapitre 4. Vous ne pouvez pas prendre de bonnes décisions de protection des données sans savoir où vont les données.

Les réglementations que vous devez savoir reconnaître

Voici les noms qu’un architecte doit connaître, avec ce que chacun couvre. C’est un tableau pour les reconnaître, pas une matrice d’applicabilité : ne le lisez pas pour décider « nous avons des clients en Californie, donc l’exigence X s’applique ». C’est au service juridique d’en décider. Votre travail est d’en savoir assez pour poser la question avant que le système ne soit construit.

Loi ou norme	Où ou quoi	Pourquoi un architecte doit la reconnaître
RGPD (opens in a new tab)	Union européenne	Données personnelles, traitement licite, droits des personnes, conservation, transferts, protection des données dès la conception
CCPA, modifié par le CPRA (opens in a new tab)	Californie	Les droits des consommateurs sur les informations personnelles que les entreprises collectent à leur sujet
LPRPDE (PIPEDA) (opens in a new tab)	Canada	La façon dont les organisations du secteur privé traitent les renseignements personnels
LGPD (opens in a new tab)	Brésil	La loi générale brésilienne sur la protection des données personnelles
Privacy Act 1988 (opens in a new tab)	Australie	La façon dont les organisations traitent les informations personnelles, selon les Australian Privacy Principles
HIPAA (opens in a new tab)	Santé aux États-Unis	Les informations de santé protégées dans les contextes concernés
PCI DSS (opens in a new tab)	Cartes de paiement	La protection des données des comptes de cartes de paiement
Sarbanes-Oxley (SOX) (opens in a new tab)	Sociétés cotées aux États-Unis	Les contrôles et les preuves derrière l’information financière
COPPA (opens in a new tab)	États-Unis, enfants en ligne	Les informations personnelles collectées en ligne auprès d’enfants

La liste s’allonge (de plus en plus d’États américains ont leurs propres lois), et les lois changent. C’est pourquoi je ne veux pas que vous mémorisiez un tableau en pensant avoir appris l’architecture de la protection des données. Apprenez les noms, puis apprenez les questions qui leur survivent.

Ce que les lois ont en commun

Les détails diffèrent, mais les grandes lois sur la protection des données reviennent toujours aux mêmes quelques points, et chacun retombe sur l’architecture.

Les droits. Les personnes peuvent demander à voir leurs données, à les rectifier, à les effacer et à les emporter ; selon les lois californienne et brésilienne, elles peuvent aussi refuser qu’elles soient vendues. Chacune de ces demandes oblige à retrouver les données de la personne, toutes ses données.

Les transferts. Le RGPD et la LGPD encadrent les données personnelles qui quittent leur territoire et exigent une protection adéquate là où elles vont ; la LPRPDE attend le même niveau de protection quand un tiers traite les données, où qu’il se trouve. C’est à nouveau le paysage : quelles flèches franchissent une frontière ?

La notification des violations. Quand des données personnelles sont exposées, les lois attendent que vous préveniez les autorités, et parfois les personnes concernées, dans un délai qui varie selon la loi. Vous ne pouvez pas signaler des données dont vous ignoriez l’existence, ni dire ce qui a été exposé si vous ne trouvez pas les copies.

La responsabilité. Vous devez pouvoir démontrer votre conformité : des registres de ce que vous traitez et pourquoi, des analyses d’impact pour les traitements à haut risque et, selon le RGPD et la LGPD, un délégué à la protection des données. L’architecture doit produire ces registres.

Commencez par ce qui est personnel

Avant de protéger les informations personnelles, trouvez-les. Certaines sont évidentes : nom, adresse du domicile, téléphone, courriel. D’autres non : localisation, identifiants d’appareil, adresses IP, images, données comportementales, tout ce qui peut être relié à une personne. Et le contexte compte. Une livraison Steve Trucking porte le nom du destinataire, son adresse, son numéro de téléphone, des notes de livraison et des photos. Une photo peut montrer un carton sur un perron, ou une personne, ou l’intérieur d’un domicile. La livraison est une donnée opérationnelle, mais certains de ses attributs sont personnels. C’est pourquoi le module 3 a classé les champs : la protection des données commence par savoir ce que l’on détient.

Où vivent-elles ?

« Dans Salesforce. » Probablement pas seulement dans Salesforce. Sont-elles venues d’un partenaire distributeur ? Ont-elles été copiées dans Snowflake, ingérées par Data 360, écrites dans un journal d’intégration, exportées par un utilisateur, laissées dans l’historique des champs, archivées, copiées dans une sandbox, transmises à un partenaire, utilisées dans la conversation d’un agent ? Les données personnelles se répandent. Alors quand le service juridique demande « où détenons-nous les informations de cette personne ? », « nous savons où se trouve la valeur actuelle » n’est pas une réponse. Je veux le paysage et le lignage : où sont allées les copies.

Click to enlarge

Un numéro de téléphone, de nombreuses copies. La protection des données s’applique aussi aux copies.

Pourquoi avez-vous le droit de les utiliser ?

Avoir des données et avoir le droit de les utiliser, ce n’est pas la même chose. Steve Trucking a le numéro de téléphone d’un destinataire pour coordonner la livraison du jour. Cela en fait-il une liste marketing ? Non. La base juridique dépend de la juridiction et de la situation, et c’est le service juridique qui l’éclaire, mais l’architecture doit porter la réponse : pourquoi la donnée a été collectée, quelle utilisation a été autorisée, si un consentement était nécessaire, donné, retiré, et pour quel canal, quelle adresse et quelle finalité. L’autorisation d’utiliser des données doit pouvoir être représentée sous forme de données, car un document de politique ne peut pas prendre de décision à l’exécution. Le module suivant la modélise.

Collecter moins est une décision d’architecture

L’un des contrôles de protection des données les plus forts consiste à ne pas collecter la donnée, ou à ne pas la copier là où elle n’est pas nécessaire. Snowflake a-t-il besoin du numéro de téléphone du destinataire ? L’analytique a-t-elle besoin de l’adresse complète ? La sandbox a-t-elle besoin de vraies photos de livraison ? Un agent a-t-il besoin des coordonnées personnelles du destinataire pour répondre à cette question ? Sinon, le contrôle le plus fort est peut-être de ne pas les y mettre. Chaque copie que vous ne faites pas est une copie que vous n’avez pas à sécuriser, conserver, supprimer, suivre pour le consentement, auditer ou déclarer en cas de violation. Les données sensibles les moins coûteuses à gouverner sont celles que vous n’avez jamais copiées.

La conservation fait partie du modèle

« On garde tout pour l’instant » est une politique de conservation. C’est juste une mauvaise politique. Pour les données importantes, je veux savoir dès la conception combien de temps nous en avons besoin et pourquoi ; si une réglementation fixe un minimum ou une autre un maximum ; quand le compte à rebours commence ; et ce qui se passe à la fin : suppression, archivage, désidentification, et où sont les copies ? Les documents financiers peuvent devoir être conservés pendant une durée fixée. Le code de portail d’un destinataire n’a aucune utilité des années après la livraison. Ces décisions n’attendent pas que la base de données soit grosse.

Anonymisé, pseudonymisé, chiffré, masqué

Remplacez « Jane Smith » par 7F92A1. Jane est-elle anonymisée ? Pas si une autre table dit encore 7F92A1 = Jane Smith. C’est de la pseudonymisation : l’identifiant direct est remplacé, mais les données peuvent être reliées de nouveau à l’aide d’informations conservées séparément, et selon le RGPD, les données pseudonymisées restent des données personnelles (article 4, point 5). L’anonymisation va plus loin : les données ne peuvent plus raisonnablement être reliées à la personne (considérant 26). Alors quand quelqu’un dit « pas besoin de le supprimer, on va juste retirer le nom », soyez prudent. Si la personne peut encore raisonnablement être identifiée, vous n’avez pas franchi cette ligne. Savoir si un résultat satisfait la loi relève du service juridique ; le travail de l’architecte est de dire exactement ce que fait le système : peut-on relier de nouveau, quelles clés restent, où sont les tables de correspondance ?

Employez les mots avec précision, car ils résolvent des problèmes différents. Le chiffrement protège les données contre une divulgation non autorisée ; un utilisateur autorisé peut toujours les déchiffrer. Le masquage change ce que voient certains utilisateurs ou certains environnements. La pseudonymisation sépare l’identité directe tout en gardant un chemin de retour. L’anonymisation supprime la possibilité raisonnable d’identifier la personne. Seule la dernière fait sortir des données de la catégorie « personnelles ».

La réglementation devient des exigences

Le service juridique n’a pas besoin de me dire de créer un ensemble d’autorisations ; c’est mon côté de la ligne. Le service juridique peut dire « seuls les employés ayant un besoin métier légitime peuvent accéder à cette catégorie d’informations personnelles ». Alors je traduis : qui sont-ils, comment identifier la catégorie, comment l’accès est-il accordé, que se passe-t-il quand quelqu’un change de poste, une intégration peut-elle la lire, un agent le peut-il, peut-elle être exportée, et comment prouver qui l’a vue ? Les propriétaires fixent la politique ; les architectes l’appliquent. Les équipes juridiques et conformité établissent l’obligation, les propriétaires des données fixent la politique métier, et l’architecte conçoit l’application.

Click to enlarge

De la réglementation aux preuves : le juridique interprète, le propriétaire fixe la politique, l’architecte la fait fonctionner et la rend prouvable.

Et la conformité n’est pas un produit. Vous ne pouvez pas acheter « conformité : activée ». Le chiffrement peut soutenir une exigence, les fonctions d’audit fournissent des preuves, les outils de conservation exécutent la politique, les données de consentement soutiennent l’utilisation autorisée, mais acheter la licence d’une fonctionnalité ne rend pas une architecture conforme. La conformité vient de toute la conception : les personnes, la politique, les processus, les données, les contrôles et les preuves. Salesforce en fait partie, pas en totalité. Et si une politique compte assez pour être appliquée, demandez-vous si elle compte assez pour être prouvée : qui a consulté cet enregistrement le 17 mars, qui a modifié ce champ, que contenait cet export ? Le module 6 traite des preuves.

La protection des données change le paysage

Chez Steve Trucking, les données personnelles du destinataire arrivent par trois intégrations de partenaires. Salesforce en a besoin pour faire tourner les livraisons ; les équipes en ont besoin d’une partie, seulement pour leurs propres arrêts, seulement le jour même ; Snowflake veut l’analytique des livraisons ; la finance a besoin d’assez pour facturer, mais pas de ce que voit l’équipe. Et un partenaire distributeur ne doit jamais voir les destinataires d’un autre. La protection des données change les flèches : certains champs ne vont pas dans Snowflake, l’analytique reçoit une version moins identifiable, les équipes ne voient que leurs arrêts, la conservation en aval diffère de la conservation opérationnelle. L’exigence de protection des données ne se pose pas à côté du diagramme de paysage. Elle le change.

Les questions qui survivent aux réglementations

Les réglementations changent, alors gardez un ensemble durable de questions pour toute donnée sensible ou réglementée :

• Qu’est-ce que c’est ? Personnel, sensible, financier, de santé, de paiement, concernant des enfants ou autrement réglementé ?
• Où vivent-elles ? Chaque copie : intégrations, historique, analytique, archives, sandboxes, journaux, usage par l’IA.
• Pourquoi pouvons-nous les utiliser ? Quelle finalité et quelle base juridique s’appliquent ? Le consentement est-il en jeu ?
• Qui peut les utiliser ? Personnes, systèmes, partenaires, intégrations, agents.
• Combien de temps les gardons-nous, et que se passe-t-il à la fin ?
• La personne peut-elle exercer ses droits sur elles ? Accès, rectification, effacement, portabilité, opposition, selon ce que prévoit la loi.
• Pouvons-nous prouver ce qui s’est passé ? Accès, modifications, exports, consentement, suppression, conservation.

La gouvernance de l’IA devient une loi

L’IA ajoute un consommateur de plus aux données gouvernées. Un système d’IA peut-il utiliser ces données, dans quel but, comme ancrage (grounding), combinées avec quoi, répétées dans sa réponse, journalisées où, pour combien de temps ? La gouvernance de l’IA passe de la politique d’entreprise à la loi : le règlement européen sur l’IA (Règlement (UE) 2024/1689 (opens in a new tab)) en est le premier grand exemple. Ce qu’il exige dépend du système et de l’usage. La direction est claire pour les architectes : l’IA ne se trouve pas en dehors de la gouvernance ; c’est un consommateur de plus des données gouvernées.

Ce qu’un architecte décide ici

• Où les données réglementées ou sensibles entrent, vivent, circulent et sont copiées dans le paysage.
• Comment la politique juridique et de conformité devient des exigences applicables, sans que l’architecte n’interprète la loi.
• Si chaque système qui reçoit des données sensibles en a besoin, ou si une version moins identifiable suffirait.
• Comment la conservation, la suppression, l’anonymisation, la pseudonymisation, la protection et les preuves façonnent le cycle de vie des données.
• Quelles preuves doivent exister pour montrer que les contrôles importants ont réellement fonctionné.

Les réglementations ne deviennent pas de l’architecture parce qu’on met leur nom sur une diapositive. Elles deviennent de l’architecture quand elles changent la façon dont les données sont collectées, classées, déplacées, protégées, conservées, supprimées et prouvées.

Pour aller plus loin

• Les sources officielles des réglementations sont liées dans le tableau ci-dessus, consultées le 2026-10-14.
• Règlement (UE) 2016/679 (RGPD) (opens in a new tab) : article 3 (champ d’application territorial), article 4, point 5 (pseudonymisation), considérant 26 (informations anonymes).
• Règlement (UE) 2024/1689 (règlement sur l’IA) (opens in a new tab), EUR-Lex.