Automatiser la cartographie RGPD : méthode et limites
Inventaire des outils, fiches de traitements, validation métier : automatisez la cartographie RGPD sans confondre détection et conformité.
- Cartographier des traitements, pas seulement des logiciels
- Répartir les tâches entre outil et validation
- Construire une chaîne de preuve simple
- Protéger les sources utilisées pour la découverte
- Évaluer une solution sur un lot pilote
- Cas pratique : trois achats logiciels ne donnent pas trois fiches fiables
- Ce qu’il faut retenir
- FAQ
Automatiser une cartographie RGPD peut réduire les ressaisies, signaler des changements et faciliter le suivi des validations. La difficulté est de conserver la distinction entre ce que l’outil détecte, ce qu’il propose et ce que l’organisme a vérifié.
Un logiciel repéré dans les achats ne révèle pas, à lui seul, la finalité de tous ses usages. Une fiche préremplie ne prouve ni la base légale ni les durées réellement paramétrées. Voici une méthode pour évaluer l’automatisation et organiser les contrôles humains nécessaires.
Cartographier des traitements, pas seulement des logiciels
La CNIL recommande de recenser les traitements par finalité principale, en identifiant les acteurs, données et flux. Une application peut soutenir plusieurs finalités ; une même activité peut utiliser plusieurs applications.
Exemple hypothétique : un CRM sert à gérer les commandes et la prospection. La liste des licences donne le nom de l’application. Les entretiens et les configurations permettent de distinguer les usages, les destinataires et les règles de conservation. Une seule fiche « CRM » peut masquer ces différences.
L’Art. 30 du RGPD précise le contenu du registre. Il n’impose pas un logiciel particulier. Le registre peut être tenu sous forme écrite, y compris électronique, et doit pouvoir être présenté à l’autorité. Sa fiabilité dépend de l’organisation de ses mises à jour, pas seulement du format utilisé.
Répartir les tâches entre outil et validation
Le tableau décrit des capacités à vérifier auprès d’un fournisseur, pas des fonctions réputées présentes dans toute solution.
| Travail | Aide possible de l’outil | Validation qui reste nécessaire |
|---|---|---|
| Inventorier les applications | Import de listes autorisées ou rapprochement de sources | Confirmer l’usage réel et les outils manquants |
| Préparer une fiche | Proposition de catégories et de champs | Vérifier finalité, rôle, données et périmètre |
| Relier les prestataires | Référentiel et rapprochement de contrats | Vérifier l’entité et les services effectivement souscrits |
| Détecter un changement | Comparaison de versions, alertes | Décider de son impact juridique et opérationnel |
| Alimenter le registre | Réutilisation des données validées | Contrôler les champs réglementaires et les exceptions |
| Suivre les décisions | Historique, tâches et validations | Nommer un responsable et vérifier les actions réalisées |
L’automatisation du registre RGPD prolonge ce travail. Elle ne transforme pas une supposition en fait validé.
Construire une chaîne de preuve simple
Associez à chaque information sa source, sa date et son statut : détectée, proposée, vérifiée ou à revoir. Par exemple, « région déclarée dans la console » et « pays d’accès du support confirmé par contrat » ne sont pas la même preuve.
Une procédure proposée peut suivre cinq étapes :
- Importer uniquement les informations nécessaires depuis une source autorisée.
- Rapprocher les noms d’applications sans fusionner automatiquement leurs finalités.
- Faire compléter les usages par le métier et les aspects techniques par l’équipe compétente.
- Faire valider les qualifications et documenter les questions ouvertes.
- Publier la fiche validée dans le registre et conserver la provenance des changements.
Le registre des traitements rempli donne un repère de structure. Ajoutez les champs de pilotage utiles sans les présenter tous comme imposés par l’Article 30.
Protéger les sources utilisées pour la découverte
Un inventaire peut lui-même contenir des informations sur les salariés, les accès et les fournisseurs. Avant de connecter un outil, examinez les permissions demandées, les données exportées, leur conservation et les destinataires. N’accordez pas l’accès au contenu de toutes les messageries lorsqu’une liste d’applications suffit au besoin.
Les Art. 5(1)(c), 25(1–2) et 32(1) du RGPD conduisent à limiter la collecte et à sécuriser le traitement. Si le fournisseur agit comme sous-traitant, examinez le contrat et ses garanties. Ne créez pas, pour documenter votre conformité, un nouvel accès non maîtrisé à des données sensibles.
Évaluer une solution sur un lot pilote
Choisissez un lot comprenant des usages simples, un prestataire complexe et un traitement à risque. Vérifiez les résultats avec les métiers avant d’étendre le dispositif.
Mesurez notamment le temps de validation, les fiches rejetées ou corrigées, les traitements réellement confirmés, la couverture des sources et la qualité de l’export. Le nombre de lignes générées ne mesure pas l’exactitude. La décision de réaliser une AIPD dépend du risque du traitement, pas du seul fait qu’un outil l’ait découvert.
Demandez aussi ce qui reste accessible après la fin du contrat : fiches, pièces, historique et liens entre objets. Ces éléments aident à comparer un logiciel RGPD avec votre organisation actuelle. Un tableur bien administré peut convenir à un périmètre stable ; un logiciel doit démontrer son intérêt sur votre travail réel, sans seuil universel de rentabilité.
Cas pratique : trois achats logiciels ne donnent pas trois fiches fiables
Ce scénario est fictif ; il ne décrit pas l’essai d’un produit. Atelier Cobalt, une PME de maintenance industrielle de 42 salariés, veut documenter trois activités : commandes professionnelles, organisation des interventions et service après-vente. La responsable conformité commence par un périmètre limité, avec les responsables commercial, technique et SAV. La paie et le recrutement seront examinés dans des lots distincts.
L’export des achats contient un CRM, un outil de planning et un abonnement à un ancien logiciel de tickets. Un dispositif d’import propose une fiche par application. La responsable ne les transforme pas directement en fiches validées. Elle conserve la provenance « achats », la date de l’export et le statut « usage à confirmer ». Les montants et coordonnées bancaires des fournisseurs sont exclus de cet import : ils ne servent pas au recensement étudié.
La carte obtenue après vérification métier
Les entretiens montrent que l’abonnement au logiciel de tickets n’a pas été résilié, mais que son utilisation a cessé. Le SAV fonctionne désormais dans une boîte partagée. Les équipes utilisent aussi un dossier documentaire commun, absent de l’export des achats parce qu’il relève d’un contrat bureautique global.
| Activité confirmée | Outils et données nécessaires constatés | Décision de cartographie |
|---|---|---|
| Commandes professionnelles | CRM et dossier documentaire ; coordonnées des interlocuteurs, demandes et commandes | Une fiche pour cette finalité, avec les deux supports reliés |
| Organisation des interventions | Planning et dossier documentaire ; techniciens affectés, contacts du site et contraintes d’accès utiles | Fiche distincte ; ne pas copier automatiquement les destinataires du CRM |
| Service après-vente | Boîte partagée et dossier documentaire ; interlocuteur, matériel concerné et échanges techniques | Créer la fiche manquante et faire vérifier ses accès par le responsable SAV |
| Ancien logiciel de tickets | Plus de nouveaux tickets, mais présence éventuelle d’un historique à vérifier | Statut « arrêt en cours de vérification », sans déclarer les données supprimées |
La carte comprend donc trois finalités actives sur quatre supports : CRM, planning, messagerie et espace documentaire. L’ancien outil reste suivi séparément pour son historique et sa fermeture. Le dossier partagé apparaît dans plusieurs fiches, sans devenir une finalité autonome appelée « stockage ». Ce résultat n’est pas obtenu par le seul rapprochement des noms commerciaux des applications.
Un champ de registre doit garder sa provenance
Pour la fiche SAV, la responsable renseigne les catégories : interlocuteurs des clients professionnels, techniciens concernés et coordonnées de contact. Elle note les destinataires internes réellement autorisés et identifie le prestataire de messagerie à examiner. Le service décrit les durées des échanges et les éventuels dossiers conservés pour une garantie ou un litige ; les paramètres doivent ensuite être rapprochés de ces décisions.
La base légale ne provient pas d’un menu précoché par l’outil. Pour les coordonnées des salariés des clients, l’équipe examine l’intérêt légitime de gérer le SAV professionnel, sa nécessité et les garanties : informations professionnelles limitées, absence de prospection ajoutée et accès aux seuls intervenants concernés. Le contrat conclu avec la société cliente ne transforme pas automatiquement ses salariés en parties à ce contrat. Pour une prestation demandée par un entrepreneur individuel en son nom, l’Art. 6(1)(b) doit être examiné dans ce contexte différent. Art. 6(1)(b) et (f).
Ces précisions dépassent les champs expressément énumérés à l’Art. 30(1). Elles sont utiles au pilotage, mais l’article 30 n’impose pas que toutes les analyses juridiques soient contenues dans la même fiche. Atelier Cobalt relie les justificatifs au lieu de recopier un raisonnement standard pour chaque application.
La synchronisation dégrade une information déjà vérifiée
Pendant le pilote fictif, le responsable SAV confirme que trois personnes accèdent à la boîte partagée. La responsable conformité valide cette information à partir de la liste d’habilitations. Au prochain import, une ancienne liste d’équipe remplace cette valeur par six personnes, sans avertissement. La fiche conserve pourtant son badge « vérifiée ».
La responsable refuse alors d’étendre l’automatisation. Une mise à jour qui écrase une preuve récente par une source moins fiable peut rendre le registre moins exact. Elle restaure l’information documentée, conserve la trace de la divergence et demande que l’import produise une proposition de changement. Le statut de validation ne doit pas être hérité d’une ancienne valeur si la valeur change.
Le pilote est repris sur ce même cas : l’arrivée de la liste ancienne ouvre une question, identifie les six noms proposés et conserve les trois accès vérifiés jusqu’à décision. L’équipe contrôle les habilitations réelles, écarte la proposition périmée et clôt la divergence avec son motif. Si le dispositif ne sait pas préserver cette séparation, les imports restent dans un fichier préparatoire ; ils ne mettent pas à jour directement le registre.
Décider de l’extension avec une preuve exploitable
La décision du pilote est limitée : les trois activités ont été confrontées aux pratiques, la boîte SAV a été ajoutée et le traitement des divergences fonctionne dans le scénario. La fermeture de l’ancien logiciel reste ouverte tant que son historique n’a pas été examiné. Aucune formule « 100 % conforme » ne résulte de ces constats.
Avant une extension, Atelier Cobalt exporte les fiches avec leurs identifiants, sources, dates et liens vers les pièces. La responsable ouvre cet export hors de l’outil : si les fiches sont lisibles mais que leurs justificatifs deviennent introuvables, la réversibilité reste insuffisante. Elle demande un export complémentaire et le vérifie avant de confier le lot suivant au même dispositif. La décision porte ainsi sur un fonctionnement observé dans le cas, pas sur le nombre de fiches générées.
Ce qu’il faut retenir
- L’inventaire des logiciels est une source, pas la cartographie complète des traitements.
- Gardez les propositions automatiques distinctes des informations validées.
- Limitez les accès et les données collectées par l’outil de découverte.
- Évaluez le gain sur la qualité, la validation et la réversibilité d’un lot réel.
FAQ
Un outil peut-il déterminer automatiquement la base légale ?
Il peut proposer des pistes, mais la justification dépend de la finalité, du contexte et des conditions du traitement. Une proposition doit être examinée et validée.
Faut-il abandonner le registre existant ?
Non. Il fournit une base de comparaison utile. Rapprochez-le des pratiques actuelles et conservez les informations encore exactes, avec leur historique disponible.
Existe-t-il un nombre de traitements qui impose un logiciel ?
L’Article 30 n’impose pas un seuil de ce type. Décidez selon la complexité, les changements, les responsabilités et les résultats du pilote, pas selon un nombre arbitraire de fiches.
Recevez nos analyses pratiques de conformité dans la newsletter.
Thiébaut Devergranne, docteur en droit, travaille depuis plus de vingt ans sur le droit du numérique et la protection des données. Il est le fondateur de Legiscope.