Le privacy by design selon le RGPD : ce que l'article 25 impose vraiment

Le privacy by design n’est pas une option de bonne conduite : l’article 25 du RGPD oblige tout responsable de traitement à intégrer, dès la conception d’un produit ou d’un service, des mesures techniques et organisationnelles capables de démontrer la conformité. Ce n’est pas une obligation de résultat absolue, mais une obligation de moyens documentée : vous devez pouvoir prouver, à tout moment, pourquoi vos choix de conception protègent les données. La CNIL et l’EDPB attendent trois preuves minimales : une analyse d’impact (AIPD) pour les traitements à risque élevé, une documentation des arbitrages de conception, ainsi que des paramètres par défaut réglés au niveau le plus protecteur.

Concrètement, avant tout lancement de projet impliquant des données personnelles, vous devez :

• Identifier si le traitement déclenche une obligation d’AIPD au sens de l’article 35.
• Documenter chaque choix technique qui réduit la collecte ou l’exposition des données.
• Vérifier que les paramètres par défaut ne favorisent jamais la collecte maximale.
• Conserver les preuves de ces décisions dans un format exploitable en cas de contrôle.

Points clés

Le privacy by design réussit quand la documentation des choix de conception, le paramétrage protecteur par défaut et l’AIPD avancent ensemble, pas en silos séparés.

Point	Détails
Article 25 impose deux volets	La conception et le paramétrage par défaut se vérifient et se documentent séparément.
AIPD dès le risque élevé	Déclenchez l’analyse d’impact avant le développement pour les traitements sensibles ou de profilage massif.
Paramètres par défaut sous surveillance	Les sanctions visent souvent les cases pré-cochées et le tracking activé sans consentement.
ISO 27001 et ISO 27701 se complètent	L’un couvre la sécurité, l’autre étend l’approche à la confidentialité.
Centraliser les preuves simplifie le contrôle	Une plateforme comme Adryo aide à regrouper journaux, exports horodatés et registre des traitements.

Table des matières

• Les 7 principes du privacy by design et leur traduction opérationnelle
• Ce que disent l’article 25, l’EDPB et la CNIL sur la mise en œuvre
• Privacy by design et privacy by default : où se situe la frontière ?
• Mettre en œuvre le privacy by design : checklist, AIPD et preuves à rassembler
• ISO 27001, ISO 27701 et les clauses à négocier avec vos fournisseurs
• Centraliser les preuves et les journaux : ce qu’une plateforme peut apporter
• Centraliser vos preuves de conformité sans multiplier les outils
• Questions fréquentes sur le privacy by design et le RGPD
• Sources

Les 7 principes du privacy by design et leur traduction opérationnelle

Le concept, formalisé par Ann Cavoukian avant d’être repris dans le RGPD, se décline en sept principes. Chacun a une traduction technique précise, pas seulement une intention.

1. Être proactif et non réactif. Vous n’attendez pas un incident pour agir. Concrètement, cela veut dire fixer des déclencheurs d’AIPD dès la phase de cadrage projet : dès qu’un traitement porte sur des données sensibles, un profilage à grande échelle ou une surveillance systématique, l’analyse d’impact démarre avant le premier développement.
2. La protection par défaut. Chaque paramètre initial doit protéger l’utilisateur sans qu’il ait à agir. Une case de partage de données jamais pré-cochée, une durée de conservation minimale appliquée d’office.
3. L’intégration dès la conception. La vie privée n’est pas une couche ajoutée après coup, elle influence l’architecture : choix de la base de données, séparation des environnements, structure des tables.
4. La sécurité de bout en bout. Chiffrement au repos et en transit, contrôle d’accès par rôle, cloisonnement des environnements de test et de production.
5. La transparence et le respect des droits. Les interfaces doivent permettre l’exercice réel des droits d’accès, de rectification et d’effacement, pas seulement une mention légale illisible en bas de page.
6. La minimisation et la limitation des finalités. Un formulaire d’inscription ne doit demander que ce qui est strictement nécessaire à la finalité annoncée, pas des champs “au cas où”.
7. La preuve et la documentation continue. Journaux d’accès, versions successives des cahiers des charges, comptes-rendus d’AIPD : tout doit rester traçable dans le temps.

Conseil de pro : Ne traitez pas ces sept principes comme une liste à cocher une fois pour toutes. Réévaluez-les à chaque évolution fonctionnelle majeure, même mineure en apparence, comme l’ajout d’un champ de formulaire ou d’un nouveau partenaire technique.

Ce que disent l’article 25, l’EDPB et la CNIL sur la mise en œuvre

L’article 25 distingue deux obligations souvent confondues : la protection des données dès la conception, et la protection par défaut. Les lignes directrices 04/2019 de l’EDPB précisent que ces deux volets se combinent mais se vérifient séparément : un système peut être bien conçu sur le papier tout en ayant des réglages par défaut dangereux.

La formulation légale laisse une marge d’appréciation volontaire. La CNIL rappelle que le niveau de mesures attendu dépend de plusieurs critères, pas d’un standard unique :

Cette formulation change beaucoup de choses en pratique. Une start-up de trois personnes n’a pas les mêmes obligations techniques qu’un grand groupe bancaire, mais les deux doivent documenter leur raisonnement. Points d’attention à retenir :

• L’EDPB insiste sur la nécessité de documenter pourquoi une mesure a été retenue ou écartée, pas seulement laquelle.
• La CNIL sanctionne fréquemment les paramétrages par défaut non protecteurs plutôt que l’architecture technique elle-même.
• Les deux textes convergent sur un point : l’absence de preuve documentée équivaut, en contrôle, à l’absence de démarche.

Privacy by design et privacy by default : où se situe la frontière ?

Le privacy by design porte sur l’architecture et les choix de conception en amont. Le privacy by default porte sur ce qui se passe sans intervention de l’utilisateur : les réglages tels qu’ils sont livrés le premier jour. Un site peut respecter parfaitement le premier principe (chiffrement, minimisation des champs) et échouer totalement sur le second si les cookies de tracking sont activés avant tout consentement.

C’est précisément ce qu’a jugé la Cour de justice de l’Union européenne dans l’affaire Planet49 : une case pré-cochée pour l’installation de cookies ne constitue pas un consentement valable, quelle que soit la qualité du système sous-jacent. Les erreurs les plus fréquentes relevées en pratique :

• Des cases de consentement pré-cochées dans les formulaires d’inscription.
• Des trackers publicitaires ou analytiques chargés avant le recueil du consentement.
• Des durées de conservation par défaut fixées à “indéfiniment” par simplicité technique.
• Des paramètres de visibilité de profil réglés sur “public” par défaut.

Chacune de ces erreurs relève du privacy by default, même quand l’architecture technique sous-jacente est irréprochable.

Mettre en œuvre le privacy by design : checklist, AIPD et preuves à rassembler

Un cahier des charges rédigé sans volet privacy garantit presque toujours un retour en arrière coûteux six mois plus tard. Voici les éléments à intégrer systématiquement, dans l’ordre où ils doivent apparaître dans le document.

1. Inventaire des données envisagées. Listez chaque catégorie de données que le projet va collecter, sa source et sa durée de vie prévue.
2. Finalités et bases légales. Chaque catégorie de donnée doit être rattachée à une finalité précise et à une base légale identifiée avant le premier développement, pas après.
3. Minimisation active. Pour chaque champ de collecte envisagé, posez la question inverse : que se passe-t-il si on le supprime ? Si la réponse est “rien”, supprimez-le.
4. Durées de conservation différenciées. Une donnée de facturation n’a pas la même durée de vie légale qu’une donnée de navigation ou un historique de support client.
5. Déclencheurs d’AIPD. Un traitement impliquant un profilage automatisé à grande échelle, des données sensibles, ou une surveillance systématique d’un lieu public déclenche presque toujours une obligation d’AIPD au sens de l’article 35.

L’AIPD elle-même doit contenir, au minimum, une description systématique du traitement, une évaluation de la nécessité et de la proportionnalité, une évaluation des risques pour les personnes concernées, et les mesures envisagées pour y répondre. Ce document devient la pièce maîtresse en cas de contrôle : c’est souvent le premier élément demandé par la CNIL lors d’une vérification.

Conseil de pro : Rédigez l’AIPD comme si elle devait être lue par quelqu’un qui n’a jamais vu le projet. Un document qui ne se comprend qu’avec l’auteur à côté ne sert à rien en cas de contrôle six mois ou deux ans plus tard.

Sur le plan technique, quatre mesures reviennent systématiquement dans les projets bien conçus : la pseudonymisation des identifiants dans les bases de travail, le chiffrement des données au repos et en transit, le cloisonnement strict entre environnements de développement, de test et de production, et la journalisation systématique des accès aux données sensibles.

Les autorités de protection concentrent souvent leurs sanctions sur des défauts de paramétrage par défaut plutôt que sur des failles d’architecture complexes à détecter. Vérifier ses réglages par défaut reste l’action la plus rentable pour réduire le risque de sanction, bien avant un audit de sécurité complet.

En contrôle, les éléments de preuve les plus souvent demandés sont les journaux d’accès sur une période donnée, les rapports de tests de sécurité, les comptes-rendus de décision de conception (pourquoi telle option a été retenue plutôt qu’une autre), et les contrats de sous-traitance couvrant les prestataires techniques impliqués.

ISO 27001, ISO 27701 et les clauses à négocier avec vos fournisseurs

L’ISO 27001 structure la sécurité de l’information : gestion des risques, contrôle d’accès, continuité d’activité. Elle recouvre une bonne partie des exigences de l’article 32 du RGPD sur la sécurité du traitement, mais elle ne couvre pas les obligations propres à la vie privée : bases légales, minimisation, droits des personnes. C’est là qu’intervient l’ISO 27701, une extension spécifiquement conçue pour la gestion de la confidentialité, qui vient combler ce vide.

L’inventaire des actifs exigé par l’ISO 27001 constitue une base technique précieuse pour construire le registre des activités de traitement prévu à l’article 30 du RGPD : les deux documents cartographient en réalité les mêmes flux de données, vus sous deux angles différents.

Le privacy by design vise juridiquement le responsable de traitement, pas l’éditeur du logiciel qu’il utilise. Ce vide se comble par le contrat : c’est ce qu’on appelle parfois le privacy by design by contract. Avant de signer avec un fournisseur SaaS, quatre clauses méritent une attention particulière :

• Un engagement de niveau de service sur la sécurité, incluant les délais de notification en cas d’incident.
• Les conditions de sous-traitance ultérieure et la liste des sous-traitants autorisés.
• Le droit d’auditer ou de faire auditer les mesures de sécurité mises en œuvre.
• La localisation d’hébergement des données et le droit d’accès aux journaux techniques.

Centraliser les preuves et les journaux : ce qu’une plateforme peut apporter

Sur le terrain, la difficulté n’est pas de savoir quoi documenter, mais de le retrouver rapidement le jour du contrôle. Trois éléments techniques facilitent concrètement cette démonstration :

• Un hébergement localisé en France, qui simplifie la réponse aux questions de transfert de données.
• Une piste d’audit continue, qui trace qui a modifié quoi et à quel moment.
• Des exports horodatés, mobilisables immédiatement sans reconstitution manuelle.

Sur le plan organisationnel, un registre des traitements relié directement à l’outil de gestion des dossiers évite la ressaisie et les versions contradictoires. Mais aucune certification, aussi solide soit-elle, ne remplace le travail juridique de fond : qualification des bases légales, rédaction des mentions d’information, gestion effective des droits des personnes restent des décisions humaines.

Priorités pratiques pour les prochains mois

Concentrez d’abord vos efforts sur les traitements à risque élevé : ce sont eux qui déclenchent l’AIPD et représentent une part importante du risque de sanction. Intégrez ensuite la checklist privacy dans tout nouveau cahier des charges, sans exception. Enfin, faites travailler ensemble DPO, RSSI et service achats sur la contractualisation fournisseurs : c’est souvent l’angle mort le plus coûteux à corriger après coup.

Centraliser vos preuves de conformité sans multiplier les outils

Adryo est la plateforme que les sociétés de domiciliation agréées utilisent pour gérer leurs obligations LCB-FT et leur documentation de conformité au même endroit, plutôt que dispersées entre tableurs, papier et logiciel de facturation.

Concrètement, Adryo héberge les données en France, tient une piste d’audit horodatée sur chaque dossier et permet des exports immédiats en cas de contrôle préfectoral, du greffe ou de Tracfin. Le registre des mandats se met à jour automatiquement, tout comme le dossier de vigilance de chaque entreprise domiciliée. Ce que la plateforme ne fait pas, en revanche : elle ne remplace pas l’analyse juridique de vos bases légales ni la qualification de vos traitements au regard de l’article 25. Ce travail reste celui du DPO ou du conseil spécialisé. Adryo apporte l’infrastructure de preuve qui vient après cette analyse. Pour voir comment la plateforme structure la documentation LCB-FT et les journaux d’audit au quotidien, consultez la page produit Adryo.

Questions fréquentes sur le privacy by design et le RGPD

Le privacy by design s’applique-t-il à tous les traitements, même les plus simples ? Oui, l’obligation de l’article 25 s’applique à tout traitement de données personnelles, mais le niveau de mesures attendu varie selon la nature, la portée et les risques du projet concerné.

Une AIPD est-elle toujours obligatoire dans une démarche privacy by design ? Non, seulement pour les traitements susceptibles d’engendrer un risque élevé pour les droits des personnes, comme le profilage à grande échelle ou le traitement de données sensibles.

L’ISO 27001 suffit-elle à prouver la conformité au RGPD ? Non, elle couvre la sécurité de l’information mais pas les obligations propres à la vie privée comme la minimisation ou les droits des personnes, que l’ISO 27701 permet de mieux couvrir.

Quelle est la différence pratique entre privacy by design et privacy by default ? Le premier concerne les choix d’architecture faits en amont, le second concerne les réglages livrés par défaut, sans action de l’utilisateur, comme les cases de consentement ou les durées de conservation.

Quelles preuves demande le plus souvent un contrôle de la CNIL ? Les journaux d’accès, les comptes-rendus d’AIPD, les décisions de conception documentées et les contrats de sous-traitance avec les prestataires techniques.

Sources

Les lignes directrices EDPB 04/2019 restent la référence pour traduire l’article 25 en mesures concrètes. Les pages RGPD de la CNIL apportent les points de vigilance appliqués au contexte français. Les ressources sur l’ISO 27001 pour le SaaS éclairent l’articulation entre certification technique et conformité RGPD.

• Guidelines 04/2019 on Article 25 — EDPB (version française)
• ISO 27001 for SaaS startups — ISO Central

Recommandation

• Adryo — Toute votre domiciliation, une seule plateforme