RGPD : cartographie SI et registre des traitements, deux outils différents mais complémentaires

Le registre des activités de traitement et la cartographie du système d’information répondent à deux questions différentes. Le premier documente les activités de traitement de données personnelles ; la seconde décrit les composants du SI et leurs dépendances.

L’article 30 du RGPD impose au responsable du traitement de tenir un registre comportant notamment les finalités, catégories de personnes et de données, catégories de destinataires, transferts éventuels et, lorsque cela est possible, les délais d’effacement et une description générale des mesures de sécurité.4 La CNIL présente ce registre comme un outil de recensement, d’analyse et de pilotage de la conformité.1

Une cartographie SI peut enrichir ce travail, mais elle ne doit pas transformer une application en « traitement RGPD ».

Traitement

Processus métier

Application

Données & flux

Stockage / hébergement

Le registre part de la finalité

La CNIL rappelle qu’un traitement de données personnelles doit avoir une finalité déterminée.3 Dans sa méthode de constitution du registre, elle recommande d’identifier les traitements par finalité et non par logiciel utilisé, car un même logiciel peut servir différents traitements et un traitement peut utiliser plusieurs outils.1

C’est la raison pour laquelle les objets « traitement » et « application » doivent rester distincts.

Un outil de paie peut intervenir dans le traitement « gestion de la paie », mais aussi dans d’autres activités RH. À l’inverse, un traitement de gestion de la relation client peut s’appuyer sur un CRM, une messagerie, un outil d’analytics et une plateforme de support.

La cartographie SI part des composants et des dépendances

Une cartographie SI s’intéresse à la structure : applications, interfaces, données, infrastructures, réseaux, identités, tiers, processus et flux. Son apport principal est de relier ces éléments.

Elle peut répondre à des questions que le registre n’a pas vocation à détailler : sur quelle infrastructure cette application fonctionne-t-elle ? quels flux techniques alimente-t-elle ? de quel fournisseur d’identité dépend-elle ? quel prestataire héberge la base ? quelle autre application consomme le même service ?

Approfondir
Cartographie SI : les 5 étapes de l’ANSSI transformées en plan opérationnel →

Le point de jonction : relier plutôt que recopier

Un modèle simple peut utiliser la chaîne : Traitement → processus métier → application → données → flux → stockage / hébergement.

Cette relation permet de naviguer du registre vers le SI sans recopier toutes les informations. Le traitement conserve sa finalité, ses catégories de personnes, sa base juridique et ses durées ; l’application conserve ses informations techniques ; le lien entre les deux indique simplement qu’elle participe au traitement.

Cette logique évite les divergences. Si une application change d’hébergeur, la cartographie technique est mise à jour une fois. Les traitements qui dépendent de cette application peuvent ensuite être identifiés pour déterminer si leurs informations de localisation, de transfert ou de sécurité doivent être revues.

Les informations du registre qui gagnent à être reliées au SI

La CNIL recommande de recenser précisément les catégories de données, les acteurs, les destinataires et les flux, notamment leur origine et leur destination.2

Plusieurs de ces informations ont un équivalent ou un contexte dans la cartographie :

• destinataire / tiers : peut être relié à un fournisseur ou partenaire ;
• lieu d’hébergement : peut être relié à une région cloud, un datacenter ou un service ;
• flux : peut être relié aux interfaces applicatives ou aux échanges externes ;
• mesures de sécurité : peuvent pointer vers des contrôles ou systèmes existants sans être dupliquées intégralement ;
• propriétaire métier : peut être partagé avec le processus ou l’application lorsque l’organisation le décide.

Le but n’est pas de faire du référentiel technique le registre officiel. Il est de réduire les incohérences entre plusieurs listes qui parlent du même système sous des angles différents.

Une application n’est pas un traitement

C’est l’erreur de modélisation la plus fréquente.

La CNIL définit un traitement comme une opération ou un ensemble d’opérations portant sur des données personnelles, avec un objectif déterminé.3 Le logiciel est un moyen. Si l’on crée automatiquement un traitement pour chaque application, on perd la finalité et on obtient un inventaire technique maquillé en registre.

Cette confusion a aussi un effet pratique : les changements d’outil deviennent des changements artificiels de traitement, alors qu’une migration technique peut conserver la même finalité, les mêmes catégories de personnes et les mêmes grandes règles de gestion.

Le registre n’est pas non plus une cartographie technique

L’erreur inverse existe : considérer qu’un registre suffisamment détaillé remplace la cartographie SI.

Le registre contient des informations essentielles sur les traitements, mais il ne décrit pas nécessairement la topologie d’une architecture, les dépendances d’identité, les flux applicatifs internes, les ressources d’infrastructure ou les points de concentration techniques. L’article 30 ne demande pas un modèle complet du SI.4

Les deux référentiels sont complémentaires précisément parce qu’ils ne répondent pas à la même question.

Construire les liens en quatre étapes

1. Stabiliser les identifiants

Une application, un traitement et un fournisseur doivent avoir des identifiants stables. Le nom affiché peut évoluer ; le lien ne doit pas casser parce qu’un produit est renommé.

2. Définir un nombre limité de relations

Commencer par quelques relations explicites : « traitement supporté par application », « application manipule catégorie de données », « application hébergée chez fournisseur », « flux à destination de tiers ».

3. Choisir la source de vérité de chaque donnée

La finalité appartient au registre RGPD ; la région cloud peut venir de l’inventaire cloud ; le propriétaire applicatif du portefeuille SI. Une donnée ne devrait pas être maintenue manuellement dans trois outils sans raison.

4. Définir les événements qui déclenchent une revue

Changement d’hébergeur, ajout d’un destinataire, nouveau pays de transfert, ajout d’une catégorie de données, fusion d’applications ou nouveau sous-traitant : ces événements peuvent déclencher une vérification du registre et de la cartographie.

Le bénéfice principal : rendre le changement visible

La valeur ne vient pas seulement de la photographie initiale. Elle vient de la capacité à savoir quels traitements doivent être réévalués lorsqu’un composant du SI change.

Prenons une application déplacée vers un nouveau fournisseur cloud. La cartographie identifie les traitements qui l’utilisent et les flux associés. Le DPO peut alors vérifier si le lieu d’hébergement, les sous-traitants, les transferts ou les mesures de sécurité documentés dans le registre restent corrects.

Cette approche réduit la dépendance aux campagnes annuelles où l’on demande à chaque équipe de reconstruire la réalité à partir de mémoire et de feuilles de calcul.

Quelles données ne faut-il pas partager automatiquement ?

Relier les référentiels ne signifie pas exposer toutes les informations à tout le monde. Certaines informations de sécurité, de vulnérabilité ou d’architecture peuvent être sensibles. Les droits d’accès doivent rester adaptés au besoin.

Le registre et la cartographie peuvent partager des identifiants et des relations tout en ayant des vues, niveaux de détail et règles d’accès différents.

Checklist : vérifier que les deux référentiels restent distincts et cohérents

Pour chaque traitement important, il devrait être possible de répondre :

1. Quelle est sa finalité ?
2. Quelles catégories de données et de personnes sont concernées ?
3. Quelles applications le supportent ?
4. Où ces applications et données sont-elles hébergées ?
5. Quels tiers ou destinataires interviennent ?
6. Quels flux significatifs existent ?
7. Quelle donnée est maintenue dans quel référentiel ?
8. Quel changement technique doit déclencher une revue RGPD ?
9. Qui valide les informations métier et techniques ?
10. Quand le lien a-t-il été vérifié pour la dernière fois ?

La bonne architecture de gouvernance n’est donc pas un « registre unique pour tout ». C’est un ensemble de référentiels reliés, avec des responsabilités claires, où l’information circule sans perdre sa signification réglementaire ou technique.