GDPR et RGPD sont le même règlement, UE 2016/679, nommé ainsi en anglais et en espagnol. Le compliance IT le traduit en contrôles techniques vérifiables — chiffrement, contrôle d'accès par rôles, politiques de rétention — appuyés sur les normes ISO 27001 et 27701, avec un délai maximal de 72 heures pour notifier une violation à l'AEPD.
Le compliance des technologies de l'information est la discipline qui garantit que les systèmes d'une organisation respectent l'ensemble des normes légales, sectorielles et contractuelles qui leur sont applicables. Ce n'est pas une démarche documentaire : c'est la traduction d'obligations juridiques en contrôles techniques concrets — chiffrement, journaux d'accès, politiques de rétention — pouvant être démontrés devant une autorité de contrôle. Dans le cas des données personnelles, cette exigence porte un nom : le RGPD, dénomination en espagnol du Règlement général sur la protection des données, qui est exactement le même texte que l'anglo-saxon GDPR (General Data Protection Regulation).
Il convient de dissiper une confusion fréquente : GDPR et RGPD ne sont pas deux normes distinctes, mais le même règlement (UE) 2016/679 nommé en anglais et en espagnol. En Espagne, il est en outre développé et complété par la loi organique 3/2018 relative à la protection des données personnelles et à la garantie des droits numériques (LOPDGDD), qui ajoute des nuances propres comme la réglementation des droits numériques dans le domaine professionnel.
Principes du RGPD que le système doit incarner
L'article 5 du règlement fixe six principes qui cessent d'être de la théorie dès qu'on conçoit un système. La minimisation oblige à ne collecter que les données nécessaires : une base de données qui stocke le numéro de carte d'identité « au cas où » est déjà en infraction. La limitation de la finalité empêche de réutiliser des données collectées pour un usage à des fins différentes sans nouvelle base légale. La limitation de la durée de conservation exige de supprimer ou d'anonymiser les données dès qu'elles cessent d'être nécessaires, ce qui se traduit par des politiques de rétention automatisées. Et l'intégrité et la confidentialité imposent une sécurité technique adéquate. L'article 25 ajoute la protection des données dès la conception et par défaut : la vie privée ne se rajoute pas à la fin du projet, elle s'intègre dès l'architecture.
Le privacy by design dans la pratique technique
Traduire le « dès la conception » en ingénierie réelle implique des décisions concrètes. La pseudonymisation sépare les identifiants directs des données comportementales, de sorte qu'une fuite partielle ne permette pas de réidentifier les personnes. Une anonymisation effective — irréversible, pas un simple effacement de la colonne du nom — fait sortir la donnée du champ d'application du règlement. Le chiffrement au repos et en transit avec une gestion adéquate des clés protège contre les accès non autorisés. Et le contrôle d'accès basé sur les rôles (RBAC) avec le principe du moindre privilège garantit que chaque personne ne voit que ce que sa fonction exige, en laissant une trace auditable de chaque accès.
La distinction entre pseudonymisation et anonymisation est plus que terminologique et est souvent confondue. Une donnée pseudonymisée reste une donnée personnelle au sens du RGPD, car il existe une clé qui permet de réidentifier la personne concernée ; elle n'est protégée que face à ceux qui ne possèdent pas cette clé. Une donnée véritablement anonymisée, en revanche, ne permet plus la réidentification par aucun moyen raisonnable et sort du champ du règlement. La conséquence pratique est importante : de nombreuses organisations pensent avoir anonymisé alors qu'elles n'ont en réalité que pseudonymisé, et restent soumises à toutes les obligations. Une anonymisation robuste exige des techniques comme la généralisation, la suppression des quasi-identifiants ou la confidentialité différentielle, et doit résister aux tentatives de réidentification par recoupement avec d'autres sources — le risque qu'un code postal, une date de naissance et un sexe identifient une personne précise est réel et documenté.
Audit des systèmes et référentiels
Un audit de compliance IT confronte l'état réel des systèmes à un référentiel de contrôle reconnu. Le plus répandu pour la sécurité de l'information est ISO/IEC 27001, qui définit un système de management de la sécurité de l'information (SMSI) certifiable et, dans son annexe de contrôles, des pratiques concrètes. Pour la vie privée spécifiquement, il existe l'extension ISO/IEC 27701, qui ajoute les contrôles d'un système de management de l'information relative à la vie privée (PIMS). Dans les environnements cloud, des référentiels comme le CIS Benchmark et la Cloud Controls Matrix traduisent les contrôles en configurations vérifiables. L'audit produit des preuves : captures de configuration, extraits de logs, matrices de rôles et registres de traitement.
L'intérêt de s'appuyer sur ces référentiels est qu'ils transforment des obligations juridiques abstraites en contrôles vérifiables et répétables. Le RGPD exige des « mesures techniques et organisationnelles appropriées », une formule délibérément ouverte ; l'ISO 27001 traduit cette exigence en contrôles concrets sur la gestion des accès, le chiffrement, les sauvegardes, la gestion des incidents et la continuité d'activité, chacun assorti de sa preuve associée. Lorsqu'arrive une inspection ou un audit client, l'organisation n'improvise pas : elle présente l'inventaire des contrôles, leur état de mise en œuvre et les preuves qu'ils fonctionnent. C'est la différence entre affirmer qu'on est conforme et le démontrer. L'audit doit en outre être récurrent : un contrôle qui fonctionnait il y a un an peut avoir été désactivé après une migration, et seule une révision périodique le détecte avant qu'il ne devienne une faille.
Étapes pour un programme de compliance IT
- Inventorier les traitements. Élaborer et tenir à jour le registre des activités de traitement de l'article 30, base de tout le reste : quelles données, à quelle fin, où sont-elles stockées et à qui sont-elles cédées.
- Déterminer la base légale. Chaque traitement a besoin de l'une des six bases de l'article 6 (consentement, contrat, obligation légale, intérêt vital, intérêt public ou intérêt légitime).
- Évaluer le risque. Lorsque le traitement comporte un risque élevé, réaliser une analyse d'impact relative à la protection des données (AIPD/DPIA) conformément à l'article 35.
- Mettre en œuvre des contrôles techniques. Chiffrement, RBAC, journaux d'audit, sauvegardes chiffrées et politiques de rétention automatisées.
- Préparer la réponse aux violations. Définir la procédure pour notifier l'AEPD dans les 72 heures (article 33) et les personnes concernées le cas échéant (article 34).
- Désigner un DPO si nécessaire. Le délégué à la protection des données est obligatoire pour certains traitements (article 37) et recommandé dans beaucoup d'autres.
Erreurs courantes
L'erreur la plus récurrente est de confondre avoir de la documentation avec être conforme : une politique de confidentialité impeccable sur le site web ne sert à rien si le système continue de conserver des données pendant dix ans sans base qui le justifie. La deuxième est de traiter le consentement comme un fourre-tout, alors qu'il s'agit souvent de la base légale la plus fragile et révocable ; le contrat ou l'intérêt légitime sont souvent plus solides et adaptés. La troisième est d'ignorer les sous-traitants : chaque prestataire cloud ou SaaS qui traite des données pour le compte de l'organisation exige un contrat au titre de l'article 28 et, s'il se trouve hors de l'Espace économique européen, des garanties de transfert international. La quatrième est de découvrir la procédure de notification des violations le jour même où la violation survient, avec le chronomètre des 72 heures déjà lancé.
Comparatif des référentiels applicables
| Référentiel / norme | Portée | Nature | Certifiable |
|---|---|---|---|
| RGPD / GDPR (UE 2016/679) | Données personnelles | Obligatoire | Non (c'est la loi) |
| LOPDGDD (LO 3/2018) | Données personnelles en Espagne | Obligatoire | Non (c'est la loi) |
| ISO/IEC 27001 | Sécurité de l'information | Volontaire | Oui |
| ISO/IEC 27701 | Gestion de la vie privée (PIMS) | Volontaire | Oui (extension de la 27001) |
Questions fréquentes
GDPR et RGPD sont-ils des normes différentes ? Non. Ce sont le même règlement (UE) 2016/679 : GDPR est son nom en anglais et RGPD en espagnol. Une entreprise conforme à l'un est conforme à l'autre par définition.
Quel montant l'AEPD peut-elle sanctionner ? Le RGPD prévoit des amendes allant jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial du groupe, le montant le plus élevé étant retenu, pour les infractions les plus graves. Les sanctions réelles sont graduées selon la gravité, l'intentionnalité et les mesures adoptées.
Toute entreprise a-t-elle besoin d'un DPO ? Non. C'est obligatoire pour les autorités publiques et pour ceux qui réalisent une surveillance systématique à grande échelle ou qui traitent des catégories particulières de données à grande échelle. En dehors de ces cas, le désigner est volontaire, bien que souvent recommandé.
La certification ISO 27001 garantit-elle la conformité au RGPD ? Pas automatiquement. L'ISO 27001 apporte une base de sécurité solide et démontre la diligence, mais la conformité au RGPD exige en plus des contrôles spécifiques de confidentialité que couvre mieux l'ISO 27701.
Quel est le délai pour notifier une violation de sécurité ? L'article 33 du RGPD fixe un maximum de 72 heures à partir du moment où le responsable a connaissance de la violation pour la notifier à l'autorité de contrôle, sauf s'il est improbable qu'elle engendre un risque pour les droits des personnes. Si le risque est élevé, l'article 34 impose en outre de le communiquer aux personnes concernées elles-mêmes sans délai injustifié. Avoir la procédure répétée à l'avance — qui décide, ce qui est documenté, comment on contacte l'AEPD — est ce qui permet de respecter ce délai sous la pression réelle d'un incident.
Le RGPD s'applique-t-il à une entreprise hors de l'Union européenne ? Oui, lorsqu'elle propose des biens ou des services à des personnes dans l'UE ou surveille leur comportement, selon le principe d'extraterritorialité de l'article 3. La localisation des serveurs n'exonère pas : ce qui compte, c'est à qui les données sont destinées.
Chez Summum Sistemas, nous abordons le compliance IT comme de l'ingénierie appuyée sur le droit, pas comme de la paperasse défensive. Le RGPD ne sanctionne pas le fait de subir un incident, mais le fait de ne pas avoir mis en place les mesures raisonnables qui l'auraient prévenu ou contenu. C'est la clé pratique : un programme bien construit transforme chaque obligation légale en contrôle technique vérifiable — un log qu'on peut exhiber, une politique de rétention qui s'exécute d'elle-même, un contrat de sous-traitance signé avec chaque prestataire — de sorte que, le jour d'un audit ou d'une violation, l'organisation puisse démontrer sa diligence avec des preuves et non avec de bonnes intentions. Être conforme, ce n'est pas avoir les documents ; c'est pouvoir prouver que le système fait ce que les documents promettent.