La protection de la vie privée n'est pas un complément que l'on ajoute une fois le produit développé : c'est une exigence qui doit être présente dès la première ébauche de tout système d'information. C'est précisément ce qu'impose l'article 25 du Règlement (UE) 2016/679 (RGPD), une disposition qui reste l'une des moins connues dans les PME et les entreprises de taille intermédiaire, alors que son non-respect peut entraîner des sanctions au titre de l'article 83 du RGPD.
Dans cet article, nous analysons ce qu'exige exactement l'article 25 du RGPD, quelles sont les mesures techniques et organisationnelles les plus pertinentes pour le respecter, quel rôle joue la pseudonymisation et comment la division Systèmes de Summum Consultoría accompagne les organisations dans l'intégration de ces principes dès la phase de conception.
Ce qu'établit l'article 25 du RGPD
L'article 25 du RGPD encadre deux principes distincts mais étroitement liés :
- Protection des données dès la conception (privacy by design) : oblige le responsable du traitement à mettre en œuvre, tant lors de la détermination des moyens du traitement qu'au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées — telles que la pseudonymisation — conçues pour appliquer efficacement les principes relatifs à la protection des données et pour assortir le traitement des garanties nécessaires (article 25, paragraphe 1, du RGPD).
- Protection des données par défaut (privacy by default) : oblige le responsable à garantir que, par défaut, seules les données à caractère personnel nécessaires à chaque finalité spécifique du traitement font l'objet d'un traitement. Cette obligation porte sur la quantité de données collectées, l'étendue de leur traitement, leur durée de conservation et leur accessibilité (article 25, paragraphe 2, du RGPD).
L'article 25, paragraphe 3, précise que l'adhésion à un mécanisme de certification approuvé en vertu de l'article 42 du RGPD peut être utilisée comme élément pour démontrer le respect des deux paragraphes précédents.
Le législateur européen emploie deux seuils temporels pour la protection des données dès la conception : « au moment de la détermination des moyens du traitement » et « au moment du traitement lui-même ». Cela signifie que l'obligation prend effet avant que le système soit mis en service, et non une fois qu'il est déjà opérationnel. Une entreprise qui commence à construire un CRM, un portail clients ou un système de gestion des ressources humaines est déjà soumise à l'article 25 dès la phase de spécification fonctionnelle.
Contexte réglementaire : les origines de la protection des données dès la conception
Le concept de privacy by design trouve ses racines dans les travaux de la commissaire à la protection de la vie privée de l'Ontario (Canada), Ann Cavoukian. Le concept, né dans les années 1990, a été formalisé par la suite en sept principes fondateurs : la proactivité plutôt que la réactivité ; la protection de la vie privée comme réglage par défaut ; la protection de la vie privée intégrée dans la conception ; la fonctionnalité complète sans compromis ; la sécurité de bout en bout tout au long du cycle de vie de la donnée ; la visibilité et la transparence ; et le respect de la vie privée de l'utilisateur. Le RGPD a absorbé cette philosophie et l'a transformée en obligation juridique directement applicable dans les vingt-sept États membres de l'Union européenne.
En Espagne, la Loi organique 3/2018 du 5 décembre relative à la protection des données à caractère personnel et à la garantie des droits numériques (LOPDGDD — Ley Orgánica de Protección de Datos y garantía de los derechos digitales) ne développe pas spécifiquement l'article 25 du RGPD, mais complète le cadre européen sur des aspects procéduraux et sectoriels. La LOPDGDD a abrogé l'ancienne LO 15/1999 et constitue, avec le RGPD, la référence normative en vigueur pour les organisations opérant sur le territoire espagnol.
Le Comité européen de la protection des données (CEPD) a publié des lignes directrices spécifiques sur la privacy by design et la privacy by default qui orientent l'application pratique de l'article 25, notamment en ce qui concerne les critères d'évaluation des mesures techniques et organisationnelles.
Mesures techniques et organisationnelles : ce qu'exige le texte
L'article 25, paragraphe 1, du RGPD précise que les mesures doivent tenir compte « de l'état des connaissances, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement ainsi que des risques, dont le degré de probabilité et de gravité varie, que le traitement est susceptible d'engendrer pour les droits et libertés des personnes physiques ». Il n'existe donc pas de liste exhaustive de mesures obligatoires : le texte exige proportionnalité et adéquation au risque réel de chaque organisation et de chaque traitement concret.
Les mesures techniques les plus courantes contribuant au respect de l'article 25 comprennent :
- Pseudonymisation et chiffrement des bases de données, des fichiers et des communications.
- Contrôle d'accès basé sur les rôles (RBAC) : seul le personnel qui a besoin des données pour sa fonction spécifique peut y accéder.
- Minimisation dans les formulaires et les API : ne collecter que les champs strictement nécessaires à la finalité déclarée, sans demander d'informations supplémentaires « au cas où ».
- Dissociation des identifiants directs dans les environnements de développement et de test, afin que les développeurs ne travaillent pas avec de vraies données de clients ou d'employés.
- Journaux d'audit d'accès aux données à caractère personnel : traçabilité de qui a accédé à quelle donnée et à quel moment.
- Suppression automatique des données à l'expiration du délai de conservation établi pour chaque catégorie.
- Séparation des environnements (production, développement, préproduction) pour éviter l'utilisation de données réelles en dehors de l'environnement opérationnel nécessaire.
Les mesures organisationnelles complémentaires comprennent :
- La revue de confidentialité (privacy review) comme prérequis obligatoire avant le lancement de tout nouveau traitement ou fonctionnalité.
- Des clauses de protection des données dans les contrats avec les fournisseurs et les sous-traitants, détaillant les instructions techniques et organisationnelles exigibles.
- Des procédures internes de gestion du cycle de vie de la donnée, de la collecte à la suppression.
- Des formations régulières du personnel sur les principes de minimisation, de confidentialité et de gestion des incidents.
- Des analyses d'impact relatives à la protection des données (AIPD) pour les traitements à risque élevé, conformément à l'article 35 du RGPD.
La pseudonymisation : un outil clé, mais pas une solution totale
Le RGPD définit la pseudonymisation à son article 4, point 5, comme « le traitement de données à caractère personnel de telle façon que celles-ci ne puissent plus être attribuées à une personne concernée précise sans avoir recours à des informations supplémentaires, pour autant que ces informations supplémentaires soient conservées séparément et soumises à des mesures techniques et organisationnelles afin de garantir que les données à caractère personnel ne sont pas attribuées à une personne physique identifiée ou identifiable ».
La pseudonymisation est un outil puissant pour réduire le risque lié au traitement, mais elle n'équivaut pas à l'anonymisation. Les données pseudonymisées restent des données à caractère personnel au sens du RGPD, car la réidentification est possible si l'on accède aux informations supplémentaires (la clé ou la table de correspondance). Ce que la pseudonymisation permet, c'est de réduire significativement le risque d'exposition en cas de violation de données et de faciliter certains traitements secondaires compatibles avec la finalité initiale.
Les cas d'usage les plus pertinents dans un contexte d'entreprise sont :
- Environnements de développement et de test : travailler avec des données de structure réelle sans exposer les vraies données de clients ou d'employés.
- Analytique interne : mesurer le comportement des utilisateurs ou établir des statistiques sans identifier individuellement chaque personne.
- Partage de données avec des tiers : transmettre des jeux de données à des fournisseurs ou partenaires pour analyse sans révéler l'identité des personnes concernées.
- Recherche et statistique : réutilisation de données à des fins secondaires avec un impact moindre sur les droits des personnes concernées, au titre de l'article 89 du RGPD.
La protection des données par défaut : la minimisation comme obligation opérationnelle
Le principe de protection des données par défaut exige que la configuration initiale de tout système, application ou service soit la plus restrictive en matière de traitement de données à caractère personnel. Si un système propose des options de confidentialité configurables, l'option par défaut doit toujours être celle qui implique le moins de traitement de données, et non la plus permissive.
Cela a des implications directes et concrètes pour la conception de produits numériques et pour les procédures internes des organisations :
- Un formulaire d'inscription à un service ne doit pas collecter le numéro de téléphone si celui-ci n'est pas strictement nécessaire à la fourniture de ce service.
- Une application de ressources humaines ne doit pas relier l'historique médical d'un employé à sa fiche de paie si ces deux données n'ont pas à être intégrées pour une finalité légitime du traitement.
- Un tableau de bord d'analyse web ne doit pas stocker l'adresse IP complète si les trois premiers octets suffisent à l'analyse géographique visée.
- Un système de vidéosurveillance ne doit pas conserver les enregistrements au-delà du délai maximal d'un mois prévu à l'article 22, paragraphe 3, de la LOPDGDD, sauf en présence d'un motif légal spécifiquement justifié.
- Une plateforme de commerce électronique ne doit pas pré-cocher par défaut les cases d'abonnement aux communications commerciales : l'utilisateur doit activement choisir de les recevoir.
Comparaison : protection des données dès la conception et protection des données par défaut
| Critère | Protection dès la conception (art. 25, §1, RGPD) | Protection par défaut (art. 25, §2, RGPD) |
|---|---|---|
| Moment d'application | Dès la conception et l'élaboration du système | À chaque configuration et mise en service du traitement |
| Destinataires principaux | Équipes de développement, architectes systèmes, DPO | Produit, expérience utilisateur, administration des systèmes |
| Mesures techniques typiques | Pseudonymisation, chiffrement, RBAC, séparation des environnements | Champs optionnels désactivés par défaut, rétention minimale, accès restreint par défaut |
| Principe RGPD associé | Minimisation, intégrité et confidentialité (art. 5, §1, c) et f) du RGPD) | Minimisation, limitation des finalités, limitation de la durée de conservation |
| Preuves documentaires | Dossiers de conception, AIPD préalable, comptes rendus de revue de confidentialité | Configurations documentées, politiques de rétention, journaux d'accès |
| Régime de sanctions | Art. 83, §4, RGPD : jusqu'à 10 M€ ou 2 % du chiffre d'affaires mondial annuel | Art. 83, §4, RGPD : jusqu'à 10 M€ ou 2 % du chiffre d'affaires mondial annuel |
La jonction avec la division Systèmes : intégration dès la couche d'architecture
Le respect de l'article 25 du RGPD n'est pas seulement une tâche du département juridique ou du délégué à la protection des données : il exige que les équipes techniques — architectes systèmes, développeurs, administrateurs de bases de données, responsables d'infrastructure — intègrent les principes de privacy by design dans leur méthodologie de travail habituelle.
La division Systèmes de Summum Consultoría travaille précisément à cette intersection : nous accompagnons les équipes techniques des organisations pour intégrer les exigences de l'article 25 dans leurs flux de développement, leurs architectures de données et leurs procédures de déploiement. L'objectif n'est pas d'ajouter une couche de conformité en fin de processus, mais d'incorporer les mesures techniques et organisationnelles dès les premières décisions d'architecture, lorsque le coût d'une mise en œuvre correcte est minimal par rapport au coût d'une correction une fois le système en production.
Les actions les plus courantes dans ce domaine comprennent :
- Revue des schémas de bases de données pour identifier les champs collectant plus d'informations que strictement nécessaire à la finalité du traitement.
- Mise en place de politiques de rétention automatisées dans les systèmes de stockage, avec alertes et processus de suppression programmée.
- Définition et documentation des profils d'accès par rôles dans les applications de gestion interne.
- Audits de configuration des outils SaaS et des plateformes cloud pour vérifier que la configuration par défaut appliquée par le fournisseur est la plus restrictive disponible en matière de confidentialité.
- Conseil sur la conception des API pour minimiser l'exposition des données à caractère personnel dans les réponses, en évitant de renvoyer des champs inutiles pour le cas d'usage demandeur.
- Revue des environnements de développement et de test pour s'assurer qu'aucune donnée réelle de production n'est utilisée sans pseudonymisation préalable.
Si votre organisation développe un nouveau système d'information ou révise l'architecture d'un système existant, notre équipe de mise en conformité RGPD peut vous accompagner dans l'intégration des principes de l'article 25 dès la phase de conception, avant que le système ne soit mis en production et que les coûts de correction ne se multiplient.
Comment documenter la conformité à l'article 25
Le principe de responsabilité (accountability) énoncé à l'article 5, paragraphe 2, du RGPD oblige les responsables du traitement non seulement à respecter les principes relatifs aux données à caractère personnel, mais aussi à être en mesure de le démontrer activement aux autorités de contrôle. Dans le cas de l'article 25, cela se traduit par le maintien de preuves documentaires attestant que les mesures de protection des données dès la conception et par défaut ont été effectivement appliquées.
Les documents les plus pertinents pour attester de la conformité à l'article 25 sont :
- Registre des activités de traitement (art. 30 du RGPD) : doit refléter, entre autres éléments, les mesures de sécurité techniques et organisationnelles appliquées à chaque traitement.
- Analyse d'impact relative à la protection des données (AIPD, art. 35 du RGPD) : obligatoire pour les traitements à risque élevé, elle documente l'analyse de confidentialité réalisée avant le début du traitement.
- Comptes rendus de revue interne de confidentialité : registres attestant que chaque nouveau développement ou fonctionnalité a été évalué sous l'angle de la protection des données avant son lancement.
- Politique de rétention des données : document établissant les durées de conservation pour chaque catégorie de données et les mécanismes de suppression automatisée associés.
- Contrats avec les sous-traitants (art. 28 du RGPD) : doivent inclure les instructions spécifiques sur les mesures techniques et organisationnelles que le sous-traitant est tenu de mettre en œuvre.
- Journaux de configuration et d'audit : registres techniques attestant que les configurations de protection des données par défaut sont actives dans les systèmes en production.
L'Agence espagnole de protection des données (AEPD — Agencia Española de Protección de Datos) a publié des guides et des outils d'orientation qui facilitent l'application pratique de l'article 25, dont le cadre d'analyse des risques et les lignes directrices sur les analyses d'impact. Bien que ces guides n'aient pas de caractère contraignant, leur respect constitue un indicateur pertinent de diligence en cas d'enquête de l'AEPD.
L'équipe de protection des données de Summum Consultoría accompagne les organisations de Castille-et-León et des îles Canaries — avec des bureaux à Valladolid, Burgos, Palencia, León et Las Palmas — pour élaborer cette documentation de conformité de manière rigoureuse et proportionnée à la taille, au secteur et à l'activité de chaque entreprise. Depuis 2007, avec plus de deux mille projets de numérisation et de mise en conformité réglementaire en portefeuille, notre approche combine l'expertise juridique et les capacités techniques de la division Systèmes.
Questions fréquentes
L'article 25 du RGPD s'applique-t-il uniquement aux entreprises technologiques ou à tout responsable du traitement ?
L'article 25 du RGPD s'applique à tout responsable du traitement, quelle que soit sa taille ou son secteur d'activité. Un cabinet dentaire, un conseil fiscal, une entreprise de logistique ou une PME industrielle qui traite des données de clients, d'employés ou de fournisseurs est soumis à ses obligations. Le texte introduit la proportionnalité en exigeant que les mesures soient adaptées à l'état des connaissances, aux coûts et au niveau de risque du traitement concerné, mais il n'exonère aucun type d'organisation. La différence entre une grande entreprise et une petite structure ne réside pas dans l'obligation de se conformer, mais dans la complexité et le coût des mesures exigibles.
Quelle est la différence entre la protection des données dès la conception et une analyse d'impact (AIPD) ?
Ce sont des instruments distincts mais complémentaires. La protection des données dès la conception est un principe général qui oblige à intégrer la protection des données dans tout système dès sa conception, applicable à tous les traitements. L'analyse d'impact relative à la protection des données (AIPD, régie par l'article 35 du RGPD) est un processus formel et documenté, obligatoire uniquement pour les traitements susceptibles d'engendrer un risque élevé pour les droits et libertés des personnes concernées, qui analyse systématiquement les risques et les mesures pour les atténuer avant de commencer le traitement. L'AIPD est, en un sens, la traduction documentée de la protection des données dès la conception appliquée à un traitement spécifique à risque élevé.
Quelles sanctions l'AEPD peut-elle imposer pour non-respect de l'article 25 du RGPD ?
Le non-respect de l'article 25 du RGPD peut entraîner des sanctions relevant de l'article 83, paragraphe 4, du RGPD : des amendes administratives allant jusqu'à 10 000 000 EUR ou, pour une entreprise, jusqu'à 2 % de son chiffre d'affaires annuel mondial total de l'exercice précédent, le montant le plus élevé étant retenu. La LOPDGDD (LO 3/2018) complète ce régime dans l'ordre juridique espagnol avec des critères supplémentaires de graduation. Outre la sanction financière, l'AEPD (Agencia Española de Protección de Datos — Agence espagnole de protection des données) peut imposer des mesures correctrices telles que la suspension temporaire du traitement, l'obligation d'adopter des mesures techniques spécifiques dans un délai déterminé, ou l'injonction de mettre le système en conformité avec l'article 25 avant de le reprendre.
La protection des données par défaut empêche-t-elle de proposer à l'utilisateur des configurations plus permissives ?
Pas nécessairement. La protection des données par défaut exige que la configuration initiale soit la plus restrictive en matière de traitement des données, mais elle n'empêche pas la personne concernée d'opter librement, de manière éclairée et sans équivoque, pour une configuration impliquant un traitement plus important de ses données à caractère personnel. L'exemple le plus courant est celui des panneaux de préférences de confidentialité ou des centres de gestion du consentement : l'option par défaut doit être réglée au minimum nécessaire, mais l'utilisateur peut activement élargir son consentement à des traitements optionnels. Ce que l'article 25, paragraphe 2, du RGPD interdit, c'est de définir la configuration par défaut comme la plus permissive, contraignant ainsi l'utilisateur à déployer des efforts actifs pour protéger sa vie privée.