Sécurité, confidentialité, conformité

Un datamart concentre, par construction, des données issues de nombreux systèmes : c'est une cible de choix et un multiplicateur de risque. Dans une application de force de vente, il…

Guide≈ 8 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : SEC

Pourquoi ce thème#

Un datamart concentre, par construction, des données issues de nombreux systèmes : c'est une cible de choix et un multiplicateur de risque. Dans une application de force de vente, il contient des données sur des personnes (commerciaux, contacts clients, positions de visite) ; le RGPD s'applique donc, avec ses principes (article 5 : licéité, finalité, minimisation, exactitude, limitation de la conservation, intégrité et confidentialité), la protection dès la conception (article 25), le registre des traitements (article 30), la sécurité du traitement (article 32), l'analyse d'impact (article 35) et les droits des personnes (accès, effacement…). Ce n'est pas un avis juridique : validez avec votre DPO. Le risque d'ignorer le sujet est double : sanction et perte de confiance, mais aussi blocage opérationnel (impossibilité d'effacer, de prouver, de partager). La mise en œuvre technique des droits dans un rapport (RLS) est traitée côté BI : matrice BI — sécurité RLS et accès ; la sécurité du code est dans la matrice DL — sécurité.

Ce que mesure le thème#

Axe : de l'ignorance des données sensibles à la confidentialité par conception, prouvée et auditée.
Indicateur clé : part des jeux de données contenant des données personnelles ou sensibles connus, classifiés et protégés, et capacité de répondre à une demande d'effacement ou d'accès dans le délai légal.
Unité : % de jeux de données classifiés ; délai de traitement d'une demande de droit (en jours) ; nombre d'accès non justifiés détectés.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Ignoré	Les données sont disponibles pour ceux qui ont accès à la base ; la sensibilité n'est pas connue.	Aucune classification ; accès par comptes partagés
2	Inventorié	On sait quelles données personnelles et sensibles existent et où elles sont.	≥ 80 % des tables inventoriées avec indication « personnel »
3	Maîtrisé	Chaque traitement a une finalité, une durée de conservation, un accès minimal et un registre ; les demandes de droits ont un processus.	Registre à jour ; demande de droit traitée < 30 jours
4	Prouvé	La protection est vérifiée techniquement (chiffrement, masquage, journalisation) et l'effacement est testé de bout en bout.	Effacement vérifié sur tous les environnements ; revue d'accès trimestrielle
5	Par conception	La confidentialité est intégrée dès le cadrage ; les données sont anonymisées ou pseudonymisées par défaut dans les usages secondaires.	Données de test non personnelles ; audits externes sans écart majeur

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PD-SEC-1.1	Les accès à la base sont nominatifs, pas partagés.	Revue de comptes sans compte générique en lecture sur données personnelles.
PD-SEC-1.2	Les mots de passe et secrets ne figurent pas en clair dans les scripts ni les dépôts.	Recherche de motifs de secrets dans le dépôt sans résultat.
PD-SEC-1.3	La sauvegarde est chiffrée ou stockée dans un lieu à accès contrôlé.	Configuration vérifiée.
PD-SEC-1.4	Le contact DPO / sécurité est connu de l'équipe.	Équipe capable de le citer.
PD-SEC-2.1	Un inventaire des tables et colonnes contenant des données personnelles existe.	Liste des colonnes personnelles (nom, e-mail, géoposition, identifiant utilisateur).
PD-SEC-2.2	Les données sensibles (santé, syndicales, biométriques…) éventuelles sont identifiées à part.	Mention explicite « aucune » ou liste avec justification.
PD-SEC-2.3	La finalité de chaque jeu de données personnelles est écrite.	Colonne « finalité » dans l'inventaire.
PD-SEC-2.4	Les environnements non productifs ne contiennent pas de données personnelles réelles, ou en sont protégés comme la production.	Contrôle des environnements de test (voir DOP).
PD-SEC-3.1	Un registre des traitements (art. 30) est tenu à jour pour le périmètre data.	Registre daté, relu avec le DPO.
PD-SEC-3.2	La minimisation est appliquée : seules les colonnes nécessaires sont chargées.	Revue colonne par colonne justifiant chaque donnée personnelle.
PD-SEC-3.3	Une durée de conservation est définie et appliquée (purge ou anonymisation).	Procédure de purge exécutée au moins une fois avec trace.
PD-SEC-3.4	Un processus traite les demandes d'accès et d'effacement avec propriétaire et délai.	Demande fictive traitée de bout en bout.
PD-SEC-4.1	Les accès aux données personnelles sont journalisés et revus à échéance fixe.	Journal d'accès et compte rendu de revue trimestrielle.
PD-SEC-4.2	Le masquage ou la pseudonymisation est appliqué aux usages ne nécessitant pas l'identité.	Vue ou colonne masquée dans les couches d'exposition.
PD-SEC-4.3	L'effacement d'une personne est testé dans le datamart, ses sauvegardes, ses extractions et ses rapports.	Test d'effacement documenté sur tous les stocks.
PD-SEC-4.4	Une analyse d'impact (art. 35) est réalisée pour les traitements à risque élevé.	AIPD signée ou décision motivée de non-nécessité.
PD-SEC-5.1	La confidentialité est examinée dès le cadrage de chaque nouveau produit de données.	Rubrique « données personnelles » dans la fiche de cadrage (VAL).
PD-SEC-5.2	Les usages secondaires (tests, analyses, IA) reposent sur des données anonymisées ou synthétiques.	Vérification des jeux de test et des corpus d'entraînement.
PD-SEC-5.3	Un exercice de violation de données est réalisé (détection, notification dans les 72 h prévues par le RGPD).	Compte rendu d'exercice avec délais mesurés.
PD-SEC-5.4	Un audit indépendant (interne ou externe) confirme la conformité sans écart majeur.	Rapport d'audit et plan d'action clos.

Lecture détaillée par niveau#

🟢 Niveau 1 — Ignoré#

Signes : un compte commun pour les outils ; des extractions Excel avec noms circulent ; le mot de passe est dans un script.
Gain : simplicité apparente.
Ne garantit pas : rien que l'on puisse prouver à un auditeur ou à une personne qui exerce ses droits.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Inventorié#

Signes : un tableau des colonnes personnelles ; la finalité est écrite ; les environnements de test sont traités à part.
Gain : on sait de quoi on parle ; première base d'un registre.
Ne garantit pas : l'application des mesures ni la capacité d'effacer.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Maîtrisé#

Signes : registre, minimisation, durée de conservation, processus de droits testé par une demande fictive.
Gain : une posture défendable ; le DPO dispose d'éléments.
Ne garantit pas : l'exhaustivité technique (copies oubliées, extractions, caches de rapports).
Difficulté : 3/5 · Effort : 3/5.

🧪 Exemple

Une demande d'effacement d'un commercial quittant l'entreprise. Au niveau 3, le processus existe ; au niveau 4, on teste qu'il n'en reste aucune trace nominative : datamart, tables de staging, sauvegardes (délai d'expiration documenté), extractions partagées, caches de modèle sémantique. L'oubli le plus fréquent : la table de staging et la copie de l'environnement de test ; d'où PD-SEC-4.3, qui exige tous les stocks.

🟡 Niveau 4 — Prouvé#

Signes : journal d'accès revu ; colonnes masquées par défaut ; effacement testé sur tous les stocks ; AIPD pour les traitements à risque.
Gain : la conformité devient démontrable, pas seulement déclarée.
Ne garantit pas : la résistance à un attaquant déterminé (voir DL — sécurité) ; le RGPD et la sécurité sont voisins, non identiques.
Difficulté : 4/5 · Effort : 4/5.

-- Pseudonymisation d'une colonne d'identité dans la couche d'exposition (T-SQL)
CREATE VIEW [expo].[Utilisateur] AS
SELECT USR_ID,
       CONVERT(CHAR(64), HASHBYTES('SHA2_256', CONCAT(USR_EMAIL, (SELECT SEL FROM [sec].[Parametre]))), 2) AS USR_EMAIL_PSEUDO,
       USR_PROFIL, USR_REGION
FROM   [dim].[Utilisateur];
-- Le sel est conservé hors de la vue, à accès restreint ; la pseudonymisation reste une donnée personnelle au sens du RGPD.

🔴 Niveau 5 — Par conception#

Signes : la confidentialité figure dans la fiche de cadrage ; les tests utilisent des données synthétiques ; un exercice de violation a eu lieu.
Gain : la conformité cesse d'être un frein et devient un attribut du produit.
Ne garantit pas : l'absence d'incident ; le niveau 5 réduit la probabilité et l'impact, pas le risque résiduel.
Difficulté : 5/5 · Effort : 5/5.

Atteinte partielle et notation#

Évaluez sur chaque jeu de données contenant des données personnelles (ou à défaut les trois plus sensibles). Un jalon vaut 1 si tous les jeux concernés satisfont, 0,5 si la majorité, 0 sinon. Un jalon sans preuve vaut 0 : la conformité se démontre.

Un « 5 partiel » : la confidentialité figure dans le cadrage des nouveaux produits (5.1 à 1), les jeux de test sont anonymisés pour deux domaines sur cinq (5.2 à 0,5), un exercice de violation a été fait sur table (5.3 à 0,5), aucun audit externe n'a eu lieu (5.4 à 0).

⚠️ Piège

Pseudonymiser en croyant anonymiser : un hachage d'e-mail reste une donnée personnelle (réidentifiable par recoupement). Symptôme : « il n'y a plus de données personnelles ». Cause : confusion entre pseudonymisation et anonymisation. Remède : traitez le résultat comme personnel, sauf avis du DPO.

⚠️ Piège

L'effacement qui oublie les copies : staging, sauvegardes, extractions Excel, caches. Remède : cartographier les stocks (voir MET, lineage) et prévoir une durée d'expiration des sauvegardes compatible avec les délais de réponse.

⚠️ Piège

Sécurité de la donnée et sécurité du rapport confondues : une RLS parfaite n'empêche pas l'export complet en base. Chaque couche se protège.

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage	Leviers possibles
1 → 2	Scanner les colonnes par noms et motifs (e-mail, téléphone, nom) ; faire valider par les propriétaires (GOV).
2 → 3	Construire le registre avec le DPO ; supprimer les colonnes personnelles inutiles ; écrire la procédure de droits.
3 → 4	Journalisation des accès ; vues masquées ; test d'effacement transversal ; AIPD.
4 → 5	Données synthétiques ou anonymisées pour tests ; exercice de violation ; audit externe.

Pièges transverses : (1) Faux positif — un registre à jour mais déconnecté de la réalité technique : comparez-le à l'inventaire des colonnes. (2) Goodhart — viser « 100 % de tables classifiées » conduit à classifier par défaut « interne » ; auditez un échantillon. (3) Sécurité par obscurité — des données masquées dans le rapport mais lisibles dans le modèle.

🤖 IA

Elle aide à détecter des colonnes personnelles par profilage, à rédiger un projet de registre et à générer des données synthétiques. Risque majeur : les données personnelles ne doivent pas être envoyées à un service d'IA non autorisé ; vérifiez le contrat, la région et la conservation avant tout usage. L'IA ne remplace ni le DPO ni la décision de licéité.

Voir aussi#

Même matrice : 02 Gouvernance · 05 Modélisation · 12 Métadonnées et lineage · 10 Exploitation · README
Autres matrices : DL — sécurité · BI — sécurité RLS et accès · PI — gestion des risques · BI — gouvernance, catalogue et self-service
Pratique : méthodes spécifiques data · SQL Server SaaS — difficultés · OneLake — difficultés · IA et conduite de projet
Glossaire · Notation

✻ Rédigé par Claude Sonnet 5.5