Privacy by design : les sept principes en pratique

Page du service : Commerce numérique et IA : un avocat pour les conditions générales, la vie privée et la prospection directe.

Scénario type : une société qui avait construit un produit comptant 100 000 utilisateurs a découvert, lors de l’audit préalable (due diligence) en vue d’une levée de fonds, qu’elle présentait une énorme exposition en matière de vie privée dans l’architecture de ses données — et elle a perdu le tour de table. Le privacy by design n’est pas seulement « la bonne chose à faire » : c’est une question de survie de l’entreprise.

Qu’est-ce que le privacy by design ?

Le privacy by design (PbD) est une approche du développement de produits selon laquelle la protection de la vie privée est intégrée au système dès le premier jour, et non ajoutée après coup. L’idée a été développée dans les années 1990 par la docteure Ann Cavoukian, au Canada, et elle est devenue une obligation juridique en 2018 avec l’entrée en vigueur du RGPD européen (article 25).

En Israël, le règlement sur la protection de la vie privée (sécurité des données), 5777-2017, va dans la même direction : il oblige les organisations à adopter des mesures de sécurité adaptées à la sensibilité des données et aux risques — autrement dit, à penser la vie privée comme une partie de la conception, et non comme une case à cocher.

Les sept principes du privacy by design

Ann Cavoukian a défini sept principes directeurs. Voici à quoi ils ressemblent en pratique dans une entreprise technologique :

1. Prévenir plutôt que corriger : identifier les risques pour la vie privée avant le développement, et non vérifier une fois le code en production. Threat modeling (modélisation des menaces) dès l’étape de conception.
2. La vie privée par défaut : le produit partage le moins d’informations possible et exige un consentement actif pour étendre le partage. Le paramètre par défaut est « ne pas partager », et non « tout partager ».
3. La vie privée intégrée à l’architecture : la protection de la vie privée fait partie de la conception technique, et n’est pas un plug-in externe. Le chiffrement, la séparation des réseaux et le principe d’accès minimal sont prévus à l’avance.
4. Pas un jeu à somme nulle : la vie privée et la sécurité ne s’opposent pas à la fonctionnalité — on peut construire un produit qui fait les deux. « Cela nuira à l’expérience utilisateur » est le plus souvent une excuse, et non une vraie contrainte.
5. Une sécurité de bout en bout : la donnée est protégée du moment de la collecte jusqu’à sa suppression. Pas seulement pendant la transmission, mais aussi dans le stockage, dans les sauvegardes et dans chaque interface interne.
6. Transparence et visibilité : les utilisateurs savent ce qui est collecté, pourquoi et comment. Pas une politique de confidentialité de 40 pages que personne ne lit, mais une transparence réelle.
7. Le respect de la vie privée de l’utilisateur : les informations sensibles sont mieux protégées, les consentements peuvent être retirés, et les utilisateurs peuvent accéder à leurs données et les supprimer.

Mise en œuvre pratique dans le développement logiciel

Quatre outils que toute équipe de développement devrait adopter :

• Data Flow Diagram : la cartographie de tout le parcours de la donnée — d’où elle est collectée, où elle transite, qui y accède et quand elle est supprimée. Sans carte, impossible de savoir où se trouve l’exposition.
• Data Minimization : on ne collecte que ce qui est vraiment nécessaire. Une base de données riche est un actif, mais aussi une responsabilité. Chaque champ superflu est une fuite potentielle.
• Access Control : une définition précise de qui accède à quoi et quand, et non un accès général à toutes les données pour chaque développeur. Principle of least privilege (principe du moindre privilège).
• Retention Policy : les données qui ne sont plus nécessaires sont supprimées (voir les durées de conservation prévues par la loi). Les anciennes sauvegardes qui s’accumulent sont l’une des sources de fuite les plus fréquentes.

Privacy Impact Assessment : quand et pourquoi

La DPIA (Data Protection Impact Assessment, analyse d’impact relative à la protection des données) est une procédure d’évaluation des conséquences d’un nouveau projet sur la vie privée. Selon le RGPD, elle est obligatoire avant un traitement susceptible d’engendrer un risque élevé, par exemple un traitement à grande échelle de catégories particulières comme des données biométriques ou médicales, ou un profilage systématique et étendu (article 35). En Israël, elle n’est pas obligatoire selon la loi, mais elle est devenue un important outil de protection juridique.

La DPIA comprend : la description du traitement des données, l’évaluation de sa nécessité et de sa base légale, l’identification des risques pour les personnes concernées et les mesures d’atténuation. Une société qui a réalisé une DPIA et l’a documentée est en bien meilleure position face à un régulateur et face à un tribunal, si une violation survient.

Que risquent les entreprises qui ne l’appliquent pas ?

Trois expositions principales :

• Sanctions réglementaires : selon le RGPD, la violation de l’article 25 est passible d’une amende jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial (article 83(4)), et la violation des principes du traitement, comme la minimisation des données, jusqu’à 20 millions d’euros ou 4 % (article 83(5)). En Israël, depuis l’amendement n° 13, l’Autorité de protection de la vie privée a le pouvoir d’imposer une sanction pécuniaire aussi pour la violation du règlement sur la sécurité des données (article 23Z(h) et troisième annexe de la loi sur la protection de la vie privée, 5741-1981 (חוק הגנת הפרטיות, התשמ״א-1981)). Par exemple, celui qui n’a pas examiné ou n’a pas documenté l’examen annuel visant à vérifier si les données de la base dépassent ce qui est nécessaire à ses finalités (article 2(c) du règlement) s’expose à une sanction de 2 000 ₪ pour une base de niveau de sécurité de base, 40 000 ₪ pour un niveau moyen et 160 000 ₪ pour un niveau élevé (point 3 de la troisième annexe ; montants de base actualisés le 1er janvier de chaque année selon l’article 23FF(b)).
• Actions civiles : les victimes d’une atteinte à la vie privée peuvent réclamer des dommages-intérêts. En cas de violations de grande ampleur, une demande d’autorisation d’une action collective risque aussi d’être déposée.
• Préjudice commercial : des fuites de données ont détruit des entreprises. Les investisseurs, les entreprises clientes et les partenaires internationaux examinent la vie privée comme un critère rédhibitoire (deal breaker). La conformité au RGPD (GDPR readiness) est devenue une condition d’entrée sur le marché européen.

Liste de vérification pour une entreprise qui veut commencer

Cinq étapes pratiques pour une entreprise qui commence à appliquer ces principes :

1. Nommez un DPO (Data Protection Officer). Depuis l’amendement n° 13, c’est une obligation pour les organismes publics, les courtiers en données et ceux dont l’activité principale comprend une surveillance systématique ou un traitement d’informations sensibles à une échelle importante (article 17B1 ; voir qui doit nommer un délégué après l’amendement n° 13). Dans les autres cas, désignez au moins un responsable interne. Quelqu’un doit prendre le sujet en main.
2. Établissez un Data Inventory — une liste de toutes les données personnelles que vous détenez, de leur provenance et de l’endroit où elles se trouvent.
3. Réalisez une DPIA pour les nouveaux projets — avant le sprint, et non après.
4. Rédigez une politique de confidentialité (Privacy Policy) que les gens peuvent lire — courte, claire et exacte.
5. Formez l’équipe de développement : un développeur qui sait ce qu’est le PbD prendra de meilleures décisions sans attendre l’avocat.

Questions fréquentes

L’analyse d’impact sur la vie privée (DPIA) est-elle obligatoire en Israël ?

En Israël, elle n’est pas obligatoire selon la loi, mais elle est devenue un important outil de protection juridique. Selon le RGPD, elle est obligatoire avant un traitement susceptible d’engendrer un risque élevé, par exemple un traitement à grande échelle de catégories particulières comme des données biométriques ou médicales, ou un profilage systématique et étendu (article 35).

Nous avons une bonne politique de confidentialité. Est-ce du privacy by design ?

Non. La politique est un document ; le PbD est une architecture. On peut avoir une excellente politique et, à côté, une architecture complètement défaillante.

Qui doit nommer un délégué à la protection de la vie privée ?

Depuis l’amendement n° 13, c’est une obligation pour les organismes publics, les courtiers en données et ceux dont l’activité principale comprend une surveillance systématique ou un traitement d’informations sensibles à une échelle importante (article 17B1 de la loi sur la protection de la vie privée). Dans les autres cas, il est recommandé de nommer au moins un responsable interne.