Le RGPD encadre la manière dont une organisation décide d'utiliser des données personnelles. Il ne demande pas d'accumuler des formulaires. Il demande de connaître les traitements, de justifier leur utilité, de protéger les personnes et de pouvoir démontrer les décisions prises.
Une donnée personnelle dépend du lien avec une personne
Un nom ou une adresse sont des exemples évidents. Une adresse IP, un identifiant client, une plaque, un historique de navigation ou une combinaison de critères peuvent aussi rendre une personne identifiable. Le test ne porte pas seulement sur ce que l'entreprise voit immédiatement, mais sur les moyens raisonnablement utilisables pour relier l'information à quelqu'un.
Le traitement commence dès qu'une opération est menée sur ces données : collecte, consultation, classement, transmission, modification, archivage ou suppression. Un fichier partagé, un outil métier et une procédure papier peuvent donc relever du même cadre. Le RGPD s'intéresse à la finalité et au flux, pas à l'apparence technique du support.
Obligation 1 : savoir ce qui est fait et pourquoi
Chaque traitement reçoit une finalité précise. « Gérer les clients » reste trop large pour expliquer facturation, livraison, support, fidélité ou prospection. En séparant les objectifs, l'entreprise peut choisir les bonnes données, la bonne base légale, la durée et les personnes autorisées.
Le registre constitue le point de départ pratique. La méthode de la CNIL pour le registre des traitements invite à organiser les fiches par finalité et à les maintenir avec les métiers. Un inventaire exporté automatiquement depuis le parc informatique ne répond pas seul à cette question, car un logiciel peut servir plusieurs objectifs et une finalité peut traverser plusieurs outils.
Obligation 2 : réduire la collecte au besoin démontré
Demandez pour chaque champ ce qui devient impossible sans lui. Une réponse comme « cela pourra servir » révèle une finalité non définie. La minimisation agit au moment de concevoir le formulaire, mais aussi lors d'un import, d'un enrichissement, d'un partage avec un prestataire ou d'un accès accordé à une équipe.
Réduire ne signifie pas effacer au hasard. Il faut conserver ce qui répond à l'objectif et aux obligations applicables, puis distinguer la base active de l'archivage. Une donnée nécessaire à un litige potentiel n'a pas à rester dans l'interface quotidienne de tous les commerciaux.
Obligation 3 : rendre les droits réellement praticables
Informer une personne n'est pas recopier une politique interminable. Elle doit comprendre qui agit, pourquoi, sur quelle base, avec quels destinataires, pendant combien de temps et comment exercer ses droits. Le niveau de détail peut être progressif, mais l'essentiel doit apparaître au moment pertinent.
Le processus interne compte autant que le texte publié. Qui reçoit une demande, comment l'identité est-elle vérifiée sans collecter excessivement, quels systèmes sont interrogés et qui décide d'une limitation ? Testez ce parcours avec un dossier fictif. Les réponses manquantes montrent les dépendances invisibles du traitement.
Obligation 4 : protéger et pouvoir prouver
La sécurité doit correspondre aux risques pour les personnes. Habilitations, authentification, sauvegardes, chiffrement, journalisation et procédure d'incident prennent leur sens dans un traitement donné. Une mesure générale peut être excellente et laisser un export local sans contrôle.
La preuve ne consiste pas à stocker tous les documents. Elle relie une décision à son contexte : version du registre, analyse, contrat, test, compte rendu ou validation. Une politique non appliquée ne prouve pas la pratique. À l'inverse, une action bien menée mais jamais consignée devient difficile à expliquer lors d'un contrôle ou d'un changement d'équipe.
Le responsable du traitement ne délègue pas sa décision
L'entreprise qui détermine les finalités et les moyens essentiels reste responsable, même si un fournisseur héberge ou exécute l'opération. Le sous-traitant apporte ses garanties, suit les instructions documentées et signale les difficultés, mais il ne transforme pas automatiquement le service en conformité.
Avant de signer, décrivez les données, les finalités, les durées, les lieux, les accès, les sous-traitants ultérieurs, la restitution et l'assistance. Comparez ces réponses à l'architecture réelle. Une clause générique ne corrige pas un produit dont les réglages rendent la suppression impossible.
Un premier mois de travail sans chantier infini
Commencez par les traitements qui combinent volume, sensibilité, exposition et dépendance opérationnelle. Pour chacun, réunissez le métier, l'informatique, la sécurité, les achats et le DPO ou référent. En une séance, remplissez la finalité, les personnes, les données, la base, les destinataires, la durée et les protections. Listez les inconnues sans les masquer.
Choisissez ensuite trois actions fermables : retirer un champ inutile, limiter un accès, corriger une information ou formaliser une durée. Attribuez un responsable et une preuve attendue. Cette première boucle vaut mieux qu'un inventaire massif qui reste sans décision.
Le RGPD devient alors un système de pilotage. Le registre révèle le traitement, les principes posent les questions, les métiers décident, les mesures réduisent le risque et les preuves rendent l'ensemble explicable. La conformité n'est pas un état final : c'est la capacité à refaire cette boucle lorsque le service change.
Commentaires
Aucun commentaire pour le moment