Privacy by Design est devenu pour la première fois une obligation légale explicite en Suisse avec la loi sur la protection des données révisée (LPD) depuis le 1er septembre 2023. L'art. 7 LPD oblige le responsable du traitement à prévoir des mesures techniques et organisationnelles dès la phase de planification d'un traitement, et à garantir, par des paramètres favorables à la protection des données (Privacy by Default), que seules les données personnelles nécessaires à la finalité concernée sont traitées. Sur le fond, la norme s'inspire de l'art. 25 RGPD, le Conseil fédéral ne fixant pas de prescriptions techniques détaillées dans l'OPDo (Ordonnance sur la protection des données), mais suivant l'approche par les risques.

Cet article traite :

• Des sept principes fondateurs d'Ann Cavoukian (Information & Privacy Commissioner Ontario, 2009) comme cadre conceptuel
• Du mapping de chaque principe sur l'art. 7 LPD et l'art. 25 RGPD
• Des points de contrôle concrets pour le développement et les produits (PRD, revue de conception, revue de code, modélisation des menaces)
• Des artefacts de preuve que les autorités de contrôle comme le PFPDT attendent dans le cadre d'une procédure d'information ou de sanction
• Des constatations typiques qui conduisent régulièrement à des mesures correctives dans nos audits

Le public cible est constitué des Product Owners, des CTOs et des conseillers en protection des données qui souhaitent intégrer Privacy by Design non pas comme un terme abstrait, mais comme une procédure vérifiable dans le cycle de développement logiciel (SDLC).

L'art. 7, al. 1 LPD oblige le responsable du traitement à concevoir le traitement des données sur le plan technique et organisationnel de manière à ce que les dispositions sur la protection des données soient respectées, notamment les principes de l'art. 6 LPD. La norme applicable est l'état de la technique, la nature et l'étendue du traitement ainsi que le risque pour les personnes concernées. L'art. 7, al. 3 LPD complète cela par l'obligation de paramètres favorables à la protection des données, soit la Privacy by Default. Celui qui conçoit un système de traitement qui collecte par défaut tous les champs optionnels, affiche tous les destinataires ou installe des cookies de suivi avant le consentement viole cette norme.

L'art. 25 RGPD formule la même obligation avec deux orientations : Privacy by Design (al. 1, au moment de la détermination des moyens) et Privacy by Default (al. 2, limité au nécessaire pour la finalité concernée). Contrairement à la LPD, l'art. 83, al. 4, lit. a RGPD prévoit en cas d'infraction des amendes allant jusqu'à 10 mio. EUR ou 2 % du chiffre d'affaires mondial annuel. En Suisse, la norme pénale personnelle des art. 60-61 LPD s'applique lorsque des mesures minimales sont intentionnellement omises.

En pratique : une entreprise suisse qui traite des données personnelles dans l'UE doit satisfaire cumulativement aux deux régimes. Une architecture Privacy by Design rigoureuse est la solution la plus économique, car elle économise des couches de conformité redondantes.

Proactive not Reactive ; Preventative not Remedial. La protection des données est traitée avant qu'un risque ne se matérialise, et non après un incident. En pratique, cela signifie que chaque nouvelle activité de traitement fait l'objet d'une évaluation préalable avant la mise en production. En cas de risque élevé, une analyse d'impact relative à la protection des données (AIPD) complète est obligatoire en vertu de l'art. 22 LPD ou de l'art. 35 RGPD. L'indicateur de maturité décisif : l'équipe de sécurité est impliquée dès le Product Requirements Document (PRD), et non seulement lors d'une revue de sécurité deux semaines avant la sortie.

Privacy as the Default Setting. Si la personne concernée ne fait rien, ses données doivent être protégées. Points de contrôle concrets : bannières de cookies avec des boutons équivalents (Accepter / Refuser au même niveau), champs de newsletter en opt-in, visibilité du profil par défaut sur privé, télémétrie en opt-in plutôt qu'opt-out, géolocalisation désactivée jusqu'au consentement explicite. Les recommandations du PFPDT sur les bannières de cookies (état 2024) et les lignes directrices du CEPD 4/2019 sur l'art. 25 RGPD fixent ici l'étalon.

Artefact de preuve : un inventaire des paramètres par défaut dans le registre des activités de traitement (art. 12 LPD), qui documente pour chaque fonctionnalité le paramètre par défaut choisi et sa justification.

Privacy Embedded into Design. La protection des données n'est pas un module complémentaire, mais fait partie intégrante de l'architecture du système. Modèles d'architecture : stockage séparé des données personnelles et non personnelles, pseudonymisation au niveau de la couche de persistance, séparation des mandants par Row-Level Security, journalisation des événements sans données en clair. Les cadres de modélisation des menaces comme LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) complètent STRIDE par des risques liés à la protection des données et fournissent des entrées structurées pour la revue d'architecture.

Full Functionality – Positive-Sum, not Zero-Sum. Cavoukian souligne que la confidentialité et la fonctionnalité sont atteignables simultanément. La pseudonymisation permet des analyses de produit sans créer de profils identifiables. La confidentialité différentielle permet des analyses agrégées sans reconstruction. Le Confidential Computing (Intel SGX, AMD SEV-SNP) permet le traitement de données chiffrées dans le cloud sans que le fournisseur voie les données en clair. Celui qui travaille selon le principe de la somme positive lors de la phase de conception évite l'argument ultérieur : pour des raisons de performance, nous avons besoin de données en clair.

Question d'audit du PFPDT dans la procédure de sanction : quelles alternatives architecturales ont été examinées, et pourquoi celle choisie a-t-elle été considérée comme la plus respectueuse des droits fondamentaux ? Celui qui ne peut pas répondre à cette question n'a pas satisfait à l'art. 7 LPD.

End-to-End Security – Full Lifecycle Protection. Les données personnelles sont protégées tout au long de leur cycle de vie : collecte, transmission, traitement, stockage, suppression. Concrètement, cela implique le chiffrement en transit (TLS 1.2+, mTLS pour les communications API à API), le chiffrement au repos (AES-256 avec rotation des clés), le chiffrement des sauvegardes, une gestion sécurisée des clés (KMS / HSM, idéalement des clés gérées par le client chez les fournisseurs cloud) ainsi que des procédures de suppression vérifiables. L'obligation de suppression de l'art. 6, al. 4 LPD (proportionnalité, limitation de la finalité) n'est satisfaite que si le système applique techniquement les délais de conservation – et non par une simple aide-mémoire organisationnelle.

Visibility and Transparency. Le traitement doit être vérifiable. L'équivalent suisse se trouve aux art. 19-21 LPD (obligation d'information), art. 25 LPD (droit d'accès) et art. 28 LPD (remise des données). Privacy by Design signifie ici : la déclaration de protection des données est générée à partir du registre des activités de traitement et non maintenue manuellement, les demandes d'accès sont soutenues par des portails en libre-service, et le système enregistre qui a accédé à quelles données personnelles et à quel moment (journaux d'accès avec champ de justification pour les données sensibles selon l'art. 5, lit. c LPD).

Artefact de preuve : un diagramme de lignage des données qui montre pour chaque catégorie de données où elle est générée, par quels systèmes elle circule et où elle est persistée.

Respect for User Privacy – Keep It User-Centric. Le septième principe opérationnalise les droits des personnes concernées des art. 25-32 LPD et art. 12-22 RGPD dans la conception du produit. Points de contrôle concrets dans le SDLC :

• Droit d'accès (art. 25 LPD) : Export en libre-service dans un format standard (JSON / CSV), et non seulement un téléchargement PDF d'un rapport non structuré.
• Droit de rectification (art. 32, al. 1 LPD) : Éditeur de profil avec piste d'audit, propagation automatique dans les systèmes en aval.
• Droit à l'effacement (art. 32, al. 2, lit. c LPD) : Suppression du compte avec suppression en cascade dans les bases de données, les sauvegardes (après le cycle de rotation), les journaux et les sous-traitants SaaS.
• Portabilité des données (art. 28 LPD, art. 20 RGPD) : Export structuré, lisible par machine, schéma documenté.
• Droit d'opposition (art. 30, al. 2, lit. b LPD) : Paramètres granulaires de consentement et d'opposition par finalité de traitement.
• Interdiction des décisions individuelles automatisées (art. 21 LPD) : Notice dans l'interface, mécanisme permettant de demander un examen humain.

Celui qui traite ces droits après la conclusion du contrat dans des listes Excel a manqué l'objectif de Privacy by Design – indépendamment de l'élégance du chiffrement backend.

Les sept principes ne deviennent efficaces que s'ils sont ancrés comme points de contrôle obligatoires dans le cycle de développement logiciel. Nous recommandons quatre portes de contrôle :

1. Porte Découverte (revue PRD) : Évaluation préalable selon l'art. 22 LPD. Le délégué à la protection des données ou le Privacy Engineer vérifie si de nouvelles données personnelles sont collectées, si une nouvelle activité de traitement est créée et si une AIPD est nécessaire.
2. Porte Conception (revue d'architecture) : Modélisation des menaces avec LINDDUN, minimisation des données documentée, paramètres par défaut définis, diagramme de flux des données avec base juridique par étape de traitement.
3. Porte Construction (revue de code & SAST) : Analyse statique des secrets codés en dur, du chiffrement manquant, des contenus de journaux excessifs. Modèles de pull-request avec liste de contrôle Privacy.
4. Porte Mise en production (audit pré-production) : Vérification des paramètres par défaut dans le système en direct, test d'intrusion en cas de risque élevé, mise à jour finale du registre des activités de traitement et de la déclaration de protection des données.

Ces portes coûtent initialement en vélocité, mais économisent en moyenne 40 à 60 % des coûts de remédiation que génèrent les corrections de confidentialité a posteriori. Si une AIPD révèle après la mise en production un risque résiduel élevé, la consultation du PFPDT selon l'art. 23 LPD est obligatoire avant tout traitement ultérieur – un rendez-vous qu'aucune direction ne souhaite. Nous recommandons de représenter les quatre portes dans le système de contrôle interne (SCI) comme des portes de stade contraignantes et de conserver leur réalisation dans le registre des activités de traitement comme preuve.

SIDD accompagne les entreprises suisses dans l'intégration de Privacy by Design dans le processus de développement de produits et de logiciels. Notre conseil en protection des données en Suisse comprend l'évaluation initiale de votre SDLC par rapport à l'art. 7 LPD et à l'art. 25 RGPD, la définition des quatre portes Privacy, la création de modèles de modélisation des menaces et d'AIPD ainsi que le coaching de vos Product Owners et Privacy Engineers. Pour les entreprises qui construisent parallèlement un système de management de la sécurité de l'information, nous couplons les portes Privacy avec la mise en œuvre ISO 27001 / ISMS, de sorte que les contrôles de sécurité et de protection des données soient mis en œuvre de manière cohérente.

En cas d'obligation RGPD, nous complétons le périmètre du mandat par un délégué externe à la protection des données (DPO RGPD) et assumons le rôle de représentant UE selon l'art. 27 RGPD si vous n'avez pas d'établissement dans l'Union. Pour la conformité continue, la plateforme Priverion est disponible – avec le registre des activités de traitement, le module AIPD et le flux de traitement des droits des personnes concernées.

Prenez rendez-vous pour un premier entretien sans engagement via le formulaire de contact ou demandez directement une offre. Nous répondons généralement dans les 24 heures avec une proposition pour la prochaine étape.