Privacy by design : guide, checklist & 7 principes 2026

L’essentiel. Le privacy by design (protection dès la conception) et le privacy by default (protection par défaut) sont deux obligations de l’article 25 du RGPD, à la charge du responsable de traitement. La première impose d’intégrer la protection des données dès la phase de conception d’un traitement ; la seconde, que seules les données strictement nécessaires soient traitées par défaut, sans action de l’utilisateur. En pratique, c’est le volet « by default » qui concentre l’essentiel des sanctions (cases pré-cochées, paramètres de suivi activés). Ce guide vous donne les 7 principes, une checklist opérationnelle et un cahier des charges type.

Le privacy by design et le privacy by default sont deux notions séduisantes sur le papier, mais qui posent de réelles difficultés d’interprétation juridique. Elles sont pourtant devenues un point de contrôle régulier de la CNIL et un réflexe attendu de tout responsable de traitement. Cet article démonte le concept, explique ce que l’article 25 impose réellement, et surtout comment le traduire en mesures concrètes que vous pourrez documenter en cas de contrôle.

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, un modèle d’IA : chacun de ces outils doit être pensé dès le départ pour respecter les principes du RGPD.

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

• identifier les données personnelles qui seront traitées, et leur niveau de sensibilité ;
• 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 (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. C’est toute la logique du privacy by design : anticiper plutôt que corriger.

Les 7 principes fondateurs d’Ann Cavoukian

Le concept trouve son origine dans les travaux de la D^re Ann Cavoukian, ancienne commissaire à la protection de la vie privée de l’Ontario (Canada), qui a formulé sept principes fondateurs, popularisés à partir de 2009-2010.

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

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

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 œuvre 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 œuvre, 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 (…) destinées à mettre en œuvre 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 œuvre des mesures pour respecter le RGPD. La formulation est en partie tautologique — et c’est là le problème juridique fondamental de cet article. Il fixe une obligation de moyens à géométrie variable (« compte tenu des coûts… de l’état des connaissances… ») plutôt qu’une liste de mesures précises. La preuve du respect repose donc entièrement sur la documentation que vous serez capable de produire.

Privacy by default : article 25(2)

L’article 25(2) est plus opérationnel :

Le responsable du traitement met en œuvre 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.

Cette exigence se décline sur 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 rendues accessibles à un nombre indéterminé de personnes.

En pratique, l’article 25(2) prolonge le principe de minimisation déjà posé à l’article 5(1)©, et y ajoute une exigence de restriction d’accès par défaut. C’est ce volet qui est le plus facilement constatable — et donc le plus sanctionné.

Privacy by design vs privacy by default : la distinction

Les deux notions sont souvent confondues. Voici comment les distinguer.

Critère	Privacy by design (Art. 25.1)	Privacy by default (Art. 25.2)
Question posée	Comment concevoir le traitement pour respecter le RGPD ?	Quels réglages sont actifs sans intervention de l’utilisateur ?
Moment	Conception, avant le démarrage du traitement	Paramétrage livré à l’utilisateur
Portée	Tous les principes du RGPD	Minimisation + restriction d’accès
Exemple conforme	AIPD réalisée en amont, chiffrement intégré	Marketing en opt-in, profil non public par défaut
Exemple non conforme	Fonctionnalité ajoutée sans réflexion « données »	Case newsletter pré-cochée, géolocalisation activée

Le chaînon manquant : les concepteurs de logiciels

Il y a un véritable angle mort 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 techniquement en position d’intégrer la protection des données dès la conception.

Le considérant 78 du RGPD le reconnaît implicitement : « 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 ; il n’impose pas directement au concepteur de les fabriquer conformes.

Ce déséquilibre a une conséquence pratique : le responsable de traitement se retrouve à exiger de ses sous-traitants et de ses fournisseurs des garanties que le RGPD n’impose pas frontalement à ces derniers. D’où l’importance de traduire ces exigences dans le contrat de sous-traitance de l’article 28 et de les vérifier en amont via un questionnaire de sélection des sous-traitants. Ce que le RGPD ne réussit pas à imposer par la loi, vous devez l’obtenir par le contrat.

Les lignes directrices du CEPD (Guidelines 4/2019)

Le Comité européen de la protection des données (CEPD/EDPB) a tenté de donner corps à l’article 25 avec ses lignes directrices 4/2019, adoptées dans leur version finale en octobre 2020. Le document relie chaque principe du RGPD à des mesures concrètes de conception.

Principe RGPD	Mesure de privacy by design attendue
Transparence	Interfaces informant clairement des traitements effectués
Licéité	Base légale choisie et documentée dès la conception
Limitation des finalités	Architecture empêchant les détournements de finalité
Minimisation	Formulaires ne collectant que le strict nécessaire
Exactitude	Mécanismes de mise à jour et de rectification prévus
Limitation de conservation	Purge automatique alignée sur les durées de conservation définies
Sécurité	Pseudonymisation, chiffrement et contrôle d’accès dès la conception

Le CEPD insiste : ces mesures doivent être prises « au moment de la détermination des moyens du traitement » — c’est-à-dire avant que le traitement ne commence. Pour tout nouveau projet impliquant des données personnelles à risque, la meilleure façon de documenter cette démarche reste de réaliser une analyse d’impact (AIPD), qui matérialise l’articulation entre risques identifiés et mesures intégrées.

Checklist : intégrer le privacy by design dans un projet

Voici la checklist que je recommande d’insérer dans le cahier des charges de tout nouveau projet manipulant des données personnelles. Elle sert aussi de grille d’évaluation lors d’un audit RGPD des systèmes existants.

Cadrage (avant le développement)

• [ ] Les données personnelles traitées sont listées, avec leur niveau de sensibilité.
• [ ] La finalité de chaque collecte est définie et documentée.
• [ ] La base légale est identifiée pour chaque finalité.
• [ ] Le principe de minimisation est appliqué : chaque champ collecté est justifié.
• [ ] Une AIPD est déclenchée si le traitement est susceptible d’engendrer un risque élevé.

Conception technique

• [ ] Les durées de conservation sont paramétrées et automatisées (purge/archivage).
• [ ] Le chiffrement au repos et en transit est prévu pour les données sensibles.
• [ ] Les accès sont cloisonnés selon le principe du moindre privilège.
• [ ] La journalisation des accès et des modifications est en place.
• [ ] Les API/fonctions d’export, de rectification et de suppression sont prévues.

Paramétrage par défaut (privacy by default)

• [ ] Le marketing est en opt-in : aucune case pré-cochée.
• [ ] Les profils ne sont pas publics par défaut.
• [ ] La géolocalisation et le suivi sont désactivés par défaut.
• [ ] Le partage de données avec des tiers requiert un consentement explicite.

Gouvernance

• [ ] Les choix de conception sont documentés (traçabilité des décisions « données »).
• [ ] Les sous-traitants sont évalués et contractualisés (art. 28).
• [ ] Le traitement est inscrit au registre des activités.

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 : elle le combine avec les manquements substantiels aux principes de l’article 5, ou avec les règles de consentement.

Deux illustrations méritent d’être décrites avec précision — sans surinterprétation.

Cases pré-cochées et consentement (CJUE, affaire Planet49, 1^er octobre 2019). La Cour de justice a jugé qu’une case pré-cochée ne peut pas constituer un consentement valable au dépôt de traceurs : le consentement suppose un acte positif clair. Cette décision est le socle jurisprudentiel de la logique « by default » appliquée au consentement.

Google LLC — 50 millions d’euros (CNIL, janvier 2019). La formation restreinte de la CNIL a sanctionné Google, en retenant notamment un défaut d’information et l’absence de consentement valablement recueilli pour la personnalisation de la publicité, plusieurs options étant pré-cochées lors de la création d’un compte. Le fondement juridique retenu portait principalement sur la transparence (art. 12-13) et le consentement (art. 6-7), plus que sur l’article 25 lui-même — mais l’affaire illustre parfaitement la logique du « by default » : ce qui est activé sans action de l’utilisateur doit être le réglage le plus protecteur.

Plus largement, la CNIL relève régulièrement, lors de ses contrôles de sites et d’applications, des manquements au privacy by default : cases pré-cochées pour la réception de newsletters, paramètres de géolocalisation activés d’office, partage de données avec des tiers actif sans consentement. C’est donc bien le volet « by default » (art. 25.2) qui fait l’objet de l’enforcement le plus effectif, parce qu’il est directement constatable.

Mettre en œuvre le privacy by design en pratique

Pour les responsables de traitement

1. Intégrer un volet « données » dans chaque projet. Tout nouveau traitement, formulaire ou application doit faire l’objet d’une évaluation préalable. Un audit des systèmes existants permet d’identifier les lacunes accumulées.
2. Rédiger un cahier des charges « privacy ». Documenter, pour chaque projet IT : quelles données, quelle finalité, quelle durée, quels mécanismes d’exercice des droits, quelles mesures de sécurité.
3. Évaluer et contractualiser les sous-traitants. Vérifier que les outils choisis offrent chiffrement, purge automatique, export des données et journalisation. C’est l’obligation qui découle de l’article 25 combiné à l’article 28.
4. Paramétrer par défaut. Vérifier que les options les plus protectrices sont actives d’origine : opt-in marketing, accès restreint, durées de conservation configurées.

Pour les concepteurs de logiciels

Bien que le RGPD ne les vise pas directement, les éditeurs ont un intérêt commercial évident à intégrer le privacy by design — c’est devenu un critère d’achat :

• purge automatique configurable ;
• chiffrement des données sensibles par défaut ;
• API d’export, de suppression et de rectification ;
• documentation des traitements réalisés par le logiciel ;
• paramètres de confidentialité protecteurs par défaut.

C’est le type de fonctionnalités qu’un logiciel RGPD permet d’industrialiser : cartographie des traitements, paramétrage des durées de conservation et génération de la documentation de conformité au fil des projets.

Ce qu’il faut retenir

• Le privacy by design (art. 25.1) impose d’intégrer la protection des données dès la conception ; le privacy by default (art. 25.2) impose que les réglages les plus protecteurs soient actifs par défaut.
• L’article 25 souffre d’un angle mort : il vise le responsable de traitement, pas les concepteurs de logiciels. À vous de combler ce vide par le contrat.
• C’est le volet « by default » qui concentre les sanctions (cases pré-cochées, tracking activé).
• Les lignes directrices 4/2019 du CEPD donnent un cadre opérationnel pour traduire l’article 25 en mesures concrètes.
• Chaque nouveau projet devrait embarquer la checklist privacy dès le cahier des charges, et une AIPD dès qu’un risque élevé apparaît.

FAQ

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

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

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

L’AIPD (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égrées pour y répondre. Réaliser une AIPD est souvent la meilleure façon de documenter la démarche.

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

Oui, dès lors qu’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 une newsletter ou pour le partage de données viole ce principe. La CJUE l’a confirmé pour les traceurs dans l’affaire Planet49 (1^er octobre 2019) : le consentement suppose un acte positif clair.

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

La CNIL vérifie la documentation. Conservez : 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 justifiés (pourquoi tel outil), les configurations par défaut, et l’inscription des mesures techniques et organisationnelles au registre des activités de traitement. C’est cette traçabilité qui matérialise l’accountability (art. 5.2).

Le privacy by design s’applique-t-il aux projets d’intelligence artificielle ?

Oui, et c’est même un terrain sensible. Un modèle entraîné sur des données personnelles, un outil de scoring ou de profilage doivent intégrer minimisation, base légale, information et sécurité dès leur conception. Lorsqu’une décision automatisée est en jeu, la logique du traitement doit pouvoir être expliquée. Les recommandations de la CNIL sur l’IA et le règlement européen sur l’IA renforcent cette exigence de « protection dès la conception » pour les systèmes à risque.

Faut-il désigner un DPO pour piloter le privacy by design ?

Pas nécessairement, mais c’est fortement recommandé. Le DPO est le mieux placé pour porter la démarche : il intervient en amont des projets, arbitre les choix « données » et documente les décisions. Les organisations sans DPO interne peuvent s’appuyer sur un DPO externalisé ou intégrer un point de contrôle « privacy » dans leur processus projet.