Une base de données concentre souvent l’essentiel de la valeur d’une organisation, mais aussi une part importante de ses risques juridiques. Dès qu’elle contient des noms, adresses e-mail, identifiants, historiques d’achat ou données de santé, le RGPD impose des règles précises. Les respecter ne relève pas seulement de la conformité : c’est aussi une manière de sécuriser les systèmes, de limiter les incidents et de renforcer la confiance des utilisateurs.
Le Règlement général sur la protection des données encadre la collecte, le stockage, l’utilisation et la suppression des informations permettant d’identifier une personne. Dans une base de données, la conformité commence par une question simple : quelles données sont réellement nécessaires ? Le principe de minimisation des données impose de ne conserver que les informations utiles à une finalité clairement définie.
Une entreprise ne devrait donc pas stocker une date de naissance, une adresse postale ou un numéro de téléphone si ces éléments ne sont pas indispensables au service fourni. Cette approche réduit l’exposition en cas de fuite et simplifie la gestion des droits. Elle oblige aussi les équipes métiers et techniques à documenter chaque champ sensible, afin de justifier sa présence dans le système.
Le RGPD repose également sur le principe de finalité déterminée. Une donnée collectée pour créer un compte client ne peut pas être réutilisée librement pour une campagne commerciale, une analyse comportementale ou un partage avec un partenaire. Chaque usage doit avoir une base légale, comme le consentement, l’exécution d’un contrat, une obligation légale ou l’intérêt légitime, selon les cas.
Avant de chiffrer, d’anonymiser ou de supprimer des informations, il faut savoir précisément ce que contient la base. La cartographie consiste à identifier les tables, colonnes, flux entrants, exports, sauvegardes, journaux et interfaces applicatives où circulent des données personnelles. Ce travail est indispensable pour tenir un registre des traitements fiable et exploitable.
Dans la pratique, cette étape réunit souvent plusieurs profils : responsables métiers, développeurs, administrateurs système, juristes, DPO et parfois prestataires. Elle permet de repérer les données directement identifiantes, comme un nom ou une adresse e-mail, mais aussi les données indirectes, comme un identifiant client, une adresse IP ou un historique de navigation.
Une bonne cartographie doit aussi prendre en compte les environnements de test, de préproduction et d’analyse. Beaucoup d’incidents naissent de copies de bases réelles utilisées pour développer une fonctionnalité ou réaliser des statistiques. Dans ces contextes, le recours à des données fictives, pseudonymisées ou anonymisées est une mesure de protection fortement recommandée.
Le RGPD interdit de conserver des données personnelles indéfiniment. Chaque catégorie d’information doit être associée à une durée de conservation cohérente avec sa finalité. Par exemple, les données liées à une commande peuvent être gardées pendant la durée nécessaire à la gestion commerciale, puis archivées pour répondre à des obligations comptables ou fiscales.
La base de données doit donc intégrer des mécanismes de purge, d’archivage ou d’anonymisation. Ces opérations peuvent être planifiées automatiquement, à condition d’être contrôlées et documentées. L’objectif est d’éviter l’accumulation de données obsolètes, souvent invisibles au quotidien mais très problématiques en cas de contrôle ou de violation de sécurité.
Pour être efficace, une politique de durée de conservation doit être comprise par les équipes qui conçoivent les formulaires, les applications et les rapports. Si un champ n’a plus d’utilité, il doit être supprimé ou rendu non identifiant. Cette discipline améliore aussi les performances, car une base moins encombrée est souvent plus simple à maintenir.
La conformité RGPD implique de garantir la confidentialité, l’intégrité et la disponibilité des données. Cela commence par une gestion stricte des accès. Chaque utilisateur, administrateur ou application doit disposer uniquement des droits nécessaires à sa mission. Ce principe, appelé moindre privilège, limite fortement les risques d’erreur humaine ou d’abus.
Les comptes partagés sont à éviter, car ils rendent les actions difficiles à tracer. Il est préférable d’utiliser des comptes nominatifs, des rôles précis et une authentification renforcée pour les accès sensibles. Dans les architectures modernes, la sécurisation peut aussi s’appuyer sur les mécanismes d’autorisation modernes, notamment lorsque plusieurs services applicatifs échangent des données.
Le chiffrement joue également un rôle central. Les données sensibles peuvent être chiffrées au repos, c’est-à-dire lorsqu’elles sont stockées, et en transit lorsqu’elles circulent entre serveurs, applications ou utilisateurs. Toutefois, le chiffrement ne suffit pas à lui seul : les clés doivent être protégées, renouvelées et séparées des données qu’elles permettent de déchiffrer.
Les journaux techniques sont indispensables pour détecter un incident, comprendre une erreur ou prouver qu’une action a été réalisée. Une base conforme doit donc permettre une certaine traçabilité : connexions, requêtes sensibles, exports massifs, suppressions et changements de droits. Ces logs constituent un élément important de la sécurité des données.
Mais les journaux peuvent eux-mêmes contenir des données personnelles. Il faut donc éviter d’y enregistrer inutilement des mots de passe, des numéros complets de carte bancaire, des pièces d’identité ou des informations médicales. Les logs doivent être protégés, horodatés, conservés pendant une durée limitée et accessibles uniquement aux personnes autorisées.
Pour les données de paiement, les exigences vont au-delà du seul RGPD. Les organisations qui manipulent des cartes bancaires doivent aussi tenir compte des exigences de sécurité applicables aux paiements, qui imposent des contrôles spécifiques sur le stockage, la transmission et la protection des informations sensibles.
Le RGPD accorde aux personnes plusieurs droits : accès, rectification, effacement, opposition, limitation, portabilité et retrait du consentement lorsque celui-ci est utilisé. Une base de données doit être conçue pour répondre à ces demandes dans des délais maîtrisés. Le délai standard est d’un mois, avec prolongation possible dans certains cas complexes.
Concrètement, il faut pouvoir retrouver rapidement toutes les données liées à une personne, y compris dans les tables secondaires, les archives et parfois les sauvegardes. Un simple champ e-mail dans une table principale ne suffit pas toujours. Les identifiants internes, les historiques de transaction et les relations entre tables doivent être compris pour garantir une réponse complète.
Le droit à l’effacement demande une attention particulière. Certaines données peuvent être supprimées immédiatement, tandis que d’autres doivent être conservées pour respecter une obligation légale ou défendre un droit en justice. Dans ce cas, il est possible de restreindre l’usage des données plutôt que de les effacer totalement, à condition de documenter la décision.
La pseudonymisation consiste à remplacer les éléments directement identifiants par des valeurs de substitution, par exemple un identifiant aléatoire. Elle réduit les risques, mais reste soumise au RGPD si une réidentification demeure possible. Une table de correspondance, une clé ou un croisement de données peut suffire à retrouver la personne concernée.
L’anonymisation, elle, suppose qu’aucune réidentification raisonnable ne soit possible. Une fois correctement anonymisées, les données ne sont plus considérées comme personnelles. Cette technique est utile pour les statistiques, la recherche, les tableaux de bord ou les jeux de données de test. Elle exige toutefois une méthode solide, car une anonymisation approximative peut créer une fausse impression de sécurité.
Le choix entre pseudonymisation et anonymisation dépend de l’usage attendu. Si l’entreprise doit encore rattacher l’information à un compte client, la pseudonymisation est plus réaliste. Si elle souhaite seulement mesurer des tendances globales, l’anonymisation est souvent préférable. Dans tous les cas, il faut documenter les méthodes utilisées et les risques résiduels.
Une base de données ne se limite jamais à son serveur principal. Les sauvegardes, fichiers CSV, outils de reporting, entrepôts de données, solutions cloud et applications tierces peuvent contenir les mêmes informations. Le respect du RGPD suppose donc de maîtriser tout l’écosystème. Un export non sécurisé peut annuler les efforts réalisés sur la base centrale.
Les sauvegardes doivent être chiffrées, testées et conservées pendant une durée proportionnée. Elles doivent aussi être prises en compte dans les procédures de suppression. Même si l’effacement immédiat dans toutes les sauvegardes est parfois difficile, l’organisation doit garantir que les données supprimées ne seront pas restaurées sans contrôle lors d’une reprise d’activité.
Lorsque des prestataires interviennent, ils sont souvent qualifiés de sous-traitants au sens du RGPD. Le contrat doit alors préciser les finalités, les mesures de sécurité, les lieux d’hébergement, les conditions de sous-traitance ultérieure et l’assistance en cas de demande d’exercice de droits. La responsabilité du responsable de traitement ne disparaît pas avec l’externalisation.
Le RGPD repose sur le principe d’accountability, c’est-à-dire la capacité à démontrer sa conformité. Il ne suffit pas d’affirmer qu’une base est sécurisée : il faut conserver des preuves. Registre des traitements, analyses d’impact, politiques de conservation, procédures d’accès, audits et décisions techniques constituent une documentation essentielle.
Pour les traitements présentant un risque élevé, notamment en cas de données sensibles, de surveillance systématique ou de volume important, une analyse d’impact relative à la protection des données peut être nécessaire. Elle permet d’évaluer les risques pour les personnes et de définir des mesures adaptées avant la mise en production.
Enfin, toute organisation doit prévoir un plan de réaction en cas de violation de données. Si un incident présente un risque pour les personnes, il doit être notifié à l’autorité compétente, en France la CNIL, dans un délai de 72 heures après en avoir pris connaissance. Les personnes concernées doivent aussi être informées lorsque le risque est élevé.
Respecter le RGPD dans une base de données n’est pas une opération ponctuelle, mais un processus continu. À chaque nouveau champ, nouvelle fonctionnalité, migration ou intégration logicielle, les mêmes questions doivent revenir : pourquoi cette donnée est-elle collectée, qui peut y accéder, combien de temps sera-t-elle conservée et comment sera-t-elle protégée ?
Les équipes techniques ont un rôle déterminant, mais elles ne peuvent pas agir seules. La conformité suppose une coopération entre métiers, juridique, sécurité, direction et prestataires. En plaçant la protection des données personnelles au cœur de la conception, une organisation réduit ses risques, améliore la qualité de ses systèmes et construit une relation plus transparente avec ses utilisateurs.
