Recense les traitements de données personnelles

L’idée reçue

« Un tableau des logiciels utilisés suffit pour faire le registre RGPD. »

Un traitement se recense d’abord par sa finalité. Un même logiciel peut servir plusieurs traitements et un même traitement peut mobiliser plusieurs applications.

01Pars de la finalité, pas du produit

Exemple pédagogique :

Mauvais point de départ
→ « Microsoft 365 »

Meilleur point de départ
→ « gérer les candidatures »
→ « administrer les comptes salariés »
→ « facturer les clients »

Pour chaque activité, demande : pourquoi ces données sont-elles utilisées, par qui, pour quelles personnes et pendant combien de temps ?

02Décris les acteurs

Un registre exploitable relie au minimum :

responsable de traitement
service propriétaire
sous-traitant éventuel
catégories de personnes concernées
catégories de destinataires

Ne déduis pas automatiquement le rôle juridique d’un acteur à partir d’un contrat commercial ou d’un nom de produit : ce rôle dépend du traitement réel.

03Décris ce qui est traité

Finalité
→ objectif précis

Catégories de personnes
→ salariés, clients, candidats, visiteurs...

Catégories de données
→ identité, contact, facturation, connexion...

Destinataires
→ équipes ou tiers autorisés

Conservation
→ durée ou critère de suppression/archivage

Sécurité
→ mesures organisationnelles et techniques pertinentes

Le registre n’est pas seulement un inventaire : il sert aussi à repérer les incohérences.

04Ajoute la base légale comme décision à vérifier

Le RGPD prévoit plusieurs bases légales. Le choix doit être effectué pour le traitement concerné ; il ne faut pas utiliser « consentement » ou « intérêt légitime » comme valeur par défaut.

Dans ce cours, on conserve une règle simple :

finalité définie
→ base légale identifiée et justifiée
→ information cohérente
→ durée cohérente
→ mesures cohérentes

En situation réelle, un doute juridique doit être remonté au DPO, au référent protection des données ou au conseil compétent.

05Recherche les signaux d’un registre incomplet

finalité vague
base légale absente
catégorie de personnes absente
aucune durée
« tous les employés » comme destinataire
sous-traitant non identifié
mesure de sécurité générique non vérifiable

Un champ rempli n’est pas automatiquement une preuve de conformité ; il doit refléter la réalité.

06Exécute le laboratoire synthétique

lab=/tmp/soria-bts-data-identity-$USER
bash module6-bts-data-identity-evidence.sh setup "$lab"
bash module6-bts-data-identity-evidence.sh run "$lab"
column -s, -t "$lab/output/treatment-review.csv"

Le lab contient uniquement des identifiants fictifs. Il ne collecte aucune donnée réelle et n’interroge aucun service externe.

07Transforme les écarts en actions

Pour chaque ligne non conforme au scénario :

écart observé
→ information manquante
→ propriétaire de la décision
→ action de correction
→ preuve attendue
→ limite de conclusion

Cette chaîne prépare directement le dossier de preuve BTS.

Mission

Construis le registre de SORIA Distribution

À partir des traitements synthétiques du lab, corrige les lignes incomplètes et justifie pourquoi chaque traitement doit être identifié par sa finalité plutôt que par son logiciel.

✓À retenir

Le registre des traitements donne une vue structurée de ce que l’organisation fait réellement avec les données personnelles. Il relie finalité, acteurs, catégories de données, destinataires, conservation et mesures de sécurité.