Privacy by design et by default : guide RGPD

Le privacy by design et le privacy by default sont deux obligations imposées par l’article 25 du RGPD. L’idée : intégrer la protection des données personnelles dès la conception d’un système de traitement, et activer cette protection par défaut. En pratique, ces concepts — séduisants sur le papier — posent de réelles difficultés d’interprétation juridique. Voyons ce qu’ils impliquent concrètement.

Qu’est-ce que le privacy by design ?

Le concept : protéger dès la conception

Le privacy by design repose sur un constat pragmatique : il est infiniment plus efficace (et moins coûteux) d’intégrer la protection des données personnelles dès la conception d’un système que de tenter de la greffer après coup. Un formulaire de collecte, une application mobile, un CRM, un dispositif de vidéosurveillance — chacun de ces outils doit être pensé dès le départ pour respecter les principes du RGPD.

Prenons un exemple concret. Un éditeur de logiciel qui conçoit un outil de gestion RH devrait, dès la phase de spécification :

• Identifier les données personnelles qui seront traitées
• Prévoir des mécanismes de minimisation des données (ne collecter que le nécessaire)
• Intégrer des durées de conservation automatisées
• Chiffrer les données sensibles par défaut
• Prévoir les interfaces permettant l’exercice des droits des personnes (accès, rectification, effacement)

Si ces éléments sont pensés après le développement, leur intégration sera techniquement complexe, coûteuse, et souvent incomplète.

Les 7 principes fondateurs d’Ann Cavoukian

Le concept trouve son origine dans les travaux de Dr. Ann Cavoukian, commissaire à l’agence canadienne de protection des données, qui a formulé en 2010 sept principes fondateurs :

1. Proactif, non réactif — Anticiper les risques plutôt que réagir aux incidents. Ne pas attendre une violation de données pour agir.
2. Protection par défaut — La vie privée doit être protégée automatiquement, sans action requise de l’utilisateur.
3. Protection intégrée à la conception — La protection des données n’est pas un module complémentaire, mais un composant central du système.
4. Somme positive, pas somme nulle — La protection de la vie privée ne doit pas se faire au détriment des fonctionnalités. L’objectif est un bénéfice mutuel (win-win).
5. Sécurité de bout en bout — Protection complète sur l’ensemble du cycle de vie des données, de la collecte à la suppression.
6. Visibilité et transparence — Les traitements doivent être documentés et vérifiables.
7. Respect de l’utilisateur — Le système doit être centré sur la personne concernée, avec des paramètres de confidentialité compréhensibles.

Ces principes donnent une vision ambitieuse et cohérente. Mais qu’en a fait le RGPD ?

Ce que le RGPD impose réellement (article 25)

Privacy by design : article 25(1)

L’article 25(1) du RGPD dispose :

Compte tenu de l’état des connaissances, des coûts de mise en oeuvre et de la nature, de la portée, du contexte et des finalités du traitement ainsi que des risques (…), le responsable du traitement met en oeuvre, tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées (…) qui sont destinées à mettre en oeuvre les principes relatifs à la protection des données (…) de façon effective et à assortir le traitement des garanties nécessaires afin de répondre aux exigences du présent règlement.

Si l’on résume sans détour : le RGPD impose au responsable de traitement de mettre en oeuvre des mesures pour respecter le RGPD. C’est tautologique — et c’est là le problème juridique fondamental de cet article.

Privacy by default : article 25(2)

L’article 25(2) est légèrement plus précis :

Le responsable du traitement met en oeuvre les mesures techniques et organisationnelles appropriées pour garantir que, par défaut, seules les données à caractère personnel qui sont nécessaires au regard de chaque finalité spécifique du traitement sont traitées.

Cela s’applique à quatre dimensions :

• La quantité de données collectées
• L’étendue de leur traitement
• La durée de conservation
• L’accessibilité des données (par défaut, elles ne doivent pas être accessibles à un nombre indéterminé de personnes)

En pratique, l’article 25(2) reformule le principe de minimisation déjà prévu à l’article 5(1)© et le complète par une exigence de restriction d’accès par défaut.

Le chaînon manquant : les concepteurs de logiciels

Il y a un véritable bug législatif dans l’article 25. Les obligations visent le responsable de traitement, mais pas les concepteurs de systèmes — éditeurs de logiciels, fabricants de matériel, développeurs de plateformes. Or ce sont précisément eux qui sont en position d’intégrer la protection des données dès la conception.

Le considérant 78 du RGPD le reconnaît implicitement, en indiquant qu’« il convient d’inciter les fabricants de produits, les prestataires de services et les producteurs d’applications à prendre en compte le droit à la protection des données ». Mais « inciter » n’est pas « obliger ». L’article 25 crée une obligation pour le responsable de traitement de choisir des outils conformes, mais pas pour le concepteur de les fabriquer conformes.

Ce problème structurel explique pourquoi l’article 25, malgré son ambition, reste difficile à appliquer de manière autonome. Le responsable de traitement se retrouve à exiger de ses prestataires des garanties que le RGPD n’impose pas directement à ces derniers.

Les lignes directrices du CEPD (Guidelines 4/2019)

Le Comité européen de la protection des données (CEPD) a tenté de donner corps à l’article 25 avec ses Guidelines 4/2019 adoptées en octobre 2020. Ce document identifie les principes du RGPD que le privacy by design doit concrétiser :

• Transparence — Les interfaces doivent informer clairement l’utilisateur des traitements effectués
• Licéité — Le choix de la base légale doit être intégré dès la conception du traitement
• Limitation des finalités — L’architecture technique doit empêcher les détournements de finalité
• Minimisation — Les formulaires et systèmes ne doivent collecter que le strict nécessaire
• Exactitude — Des mécanismes de mise à jour et de rectification doivent être prévus
• Limitation de la conservation — Des processus de purge automatique doivent être intégrés
• Sécurité — Pseudonymisation, chiffrement, contrôle d’accès dès la conception

Le CEPD souligne que ces mesures doivent être prises « au moment de la détermination des moyens du traitement » — c’est-à-dire avant même que le traitement ne commence. Pour tout nouveau projet impliquant des données personnelles, il est recommandé de réaliser une analyse d’impact (AIPD) qui intègre cette dimension privacy by design.

Sanctions et enforcement

La violation de l’article 25 expose à des amendes pouvant atteindre 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial (Art. 83(4)(a) RGPD). En pratique, la CNIL retient rarement l’article 25 comme fondement autonome d’une sanction — elle le combine généralement avec les violations substantielles des principes de l’article 5.

Quelques décisions illustratives :

Google LLC — 50 millions d’euros (CNIL, 2019). La formation restreinte a retenu un manquement au privacy by default : les paramètres de personnalisation de la publicité étaient pré-cochés lors de la création d’un compte Google, en violation de l’article 25(2). L’utilisateur devait activement décocher ces options pour limiter le traitement de ses données.

La CNIL sanctionne régulièrement des manquements au privacy by default dans le cadre des contrôles de sites web et d’applications : cases pré-cochées pour la réception de newsletters, paramètres de géolocalisation activés par défaut, partage de données avec des tiers activé sans consentement explicite.

Ces décisions montrent que c’est surtout le volet « by default » (Art. 25(2)) qui fait l’objet d’un enforcement effectif, car il est plus facilement constatable qu’un manquement au « by design ».

Mettre en oeuvre le privacy by design en pratique

Pour les responsables de traitement

1. Intégrer un volet données personnelles dans chaque projet — Tout nouveau traitement, toute nouvelle application, tout nouveau formulaire doit faire l’objet d’une évaluation préalable. Un audit RGPD des systèmes existants permet d’identifier les lacunes.

2. Rédiger un cahier des charges « privacy » — Pour tout projet IT impliquant des données personnelles, documenter les exigences : quelles données, quelle finalité, quelle durée de conservation, quels mécanismes d’exercice des droits, quelles mesures de sécurité.

3. Évaluer les sous-traitants — Vérifier que les outils et prestataires choisis offrent les garanties techniques nécessaires (chiffrement, purge automatique, export des données, journalisation des accès). C’est l’obligation qui découle directement de l’article 25 combiné avec l’article 28.

4. Paramétrer les systèmes par défaut — Vérifier que les options les plus protectrices de la vie privée sont activées par défaut dans tous les systèmes : opt-in pour le marketing, accès restreint aux données, durées de conservation configurées.

Pour les concepteurs de logiciels

Bien que le RGPD ne les vise pas directement, les éditeurs de logiciels ont un intérêt commercial évident à intégrer le privacy by design :

• Proposer des mécanismes de purge automatique configurables
• Implémenter le chiffrement des données sensibles par défaut
• Prévoir les API nécessaires à l’exercice des droits (export, suppression, rectification)
• Documenter les traitements de données réalisés par le logiciel
• Proposer des paramètres de confidentialité configurables et protecteurs par défaut

C’est ce type de fonctionnalités que des outils comme Legiscope intègrent nativement pour faciliter la gestion de la conformité RGPD.

Ce qu’il faut retenir

• Le privacy by design impose d’intégrer la protection des données dès la conception d’un traitement (Art. 25(1) RGPD) ; le privacy by default impose que les paramètres les plus protecteurs soient activés par défaut (Art. 25(2))
• L’article 25 souffre d’un problème structurel : il vise le responsable de traitement mais pas les concepteurs de logiciels, qui sont pourtant les mieux placés pour intégrer ces protections
• En pratique, c’est le volet « by default » qui fait l’objet du plus grand nombre de sanctions (cases pré-cochées, paramètres de tracking activés, etc.)
• Les Guidelines 4/2019 du CEPD donnent un cadre opérationnel pour traduire l’article 25 en mesures concrètes
• Chaque nouveau projet impliquant des données personnelles devrait inclure un volet privacy by design dès le cahier des charges

FAQ

Le privacy by design est-il obligatoire pour toutes les entreprises ?

Oui. L’article 25 du RGPD s’applique à tout responsable de traitement, quelle que soit la taille de l’organisation. En revanche, les mesures à mettre en oeuvre doivent être proportionnées : le RGPD précise qu’il faut tenir compte de « l’état des connaissances, des coûts de mise en oeuvre » et de la nature du traitement. Une PME n’aura pas les mêmes exigences qu’un GAFAM, mais elle devra démontrer qu’elle a intégré la réflexion sur la protection des données dans ses processus.

Quelle est la différence entre privacy by design et AIPD ?

L’AIPD (analyse d’impact relative à la protection des données, Art. 35 RGPD) est un outil d’évaluation des risques obligatoire pour les traitements à risque élevé. Le privacy by design est un principe de conception qui s’applique à tout traitement. Les deux sont complémentaires : l’AIPD identifie les risques, le privacy by design guide les mesures de protection à intégrer pour y répondre. En pratique, réaliser une AIPD est souvent le meilleur moyen de documenter la démarche privacy by design.

Comment prouver que j’ai appliqué le privacy by design en cas de contrôle ?

La CNIL vérifie la documentation. Il est recommandé de conserver : le cahier des charges intégrant les exigences de protection des données, les comptes rendus de réunions où ces sujets ont été discutés, les choix techniques documentés (pourquoi tel outil plutôt qu’un autre), et les configurations par défaut des systèmes. L’inscription au registre des activités de traitement des mesures techniques et organisationnelles mises en oeuvre est également un élément probant.

Les cases pré-cochées sont-elles interdites par le RGPD ?

Oui, dans la mesure où elles concernent un consentement ou un traitement non nécessaire à l’exécution du contrat. L’article 25(2) impose que par défaut, seules les données nécessaires soient traitées. Une case pré-cochée pour l’envoi de newsletters ou le partage de données avec des partenaires viole ce principe. La CNIL sanctionne régulièrement ce type de pratique, et la CJUE a confirmé cette interprétation dans l’arrêt Planet49 (C-673/17, 1er octobre 2019).