Privacy by design : la protection des données dès la conception et par défaut

L'expression anglaise privacy by design désigne une démarche simple dans son principe : la protection de la vie privée se pense en même temps que le produit ou le service, comme une exigence de conception, et non comme une couche ajoutée avant la mise en production. Le RGPD l'a transformée en obligation juridique sous le nom de protection des données dès la conception, et l'a complétée par la protection des données par défaut (privacy by default).

Pour un RSSI, la logique est familière : c'est l'équivalent, pour les droits des personnes, de la sécurité dès la conception (security by design). Les deux démarches gagnent à être menées ensemble, avec les mêmes jalons de projet.

D'où vient le privacy by design ?

Le concept a été formulé dans les années 1990 par Ann Cavoukian, alors commissaire à l'information et à la protection de la vie privée de l'Ontario (Canada). En octobre 2010, la conférence internationale des commissaires à la protection des données et de la vie privée, réunie à Jérusalem, l'a adopté par une résolution qui invite les organisations à en faire leur mode de fonctionnement par défaut. Le RGPD, adopté en 2016, l'a ensuite inscrit dans le droit européen.

Ce que dit l'article 25

Ann Cavoukian a résumé la démarche en sept principes fondateurs, repris dans les publications du commissariat ontarien. Ils ne sont pas juridiquement contraignants en eux-mêmes, mais la plupart trouvent un écho direct dans le RGPD.

En pratique, ces principes servent surtout de grille de lecture. Ce que le responsable du traitement doit démontrer, ce sont les exigences de l'article 25, précisées par le Comité européen de la protection des données.

Le Comité européen de la protection des données (CEPD) a précisé l'article 25 dans ses lignes directrices 4/2019, dont la version définitive a été adoptée le 20 octobre 2020. Quatre idées structurent le texte.

• L'efficacité avant tout. Une mesure ne compte que si elle produit l'effet attendu. Le responsable doit pouvoir le démontrer, par exemple avec des indicateurs de performance.
• L'état des connaissances est une notion dynamique. Une mesure acceptable il y a cinq ans peut ne plus l'être : il faut suivre les évolutions techniques et organisationnelles, en s'appuyant notamment sur les normes et certifications reconnues.
• Le coût est un facteur, pas une excuse. Il peut orienter le choix entre plusieurs mesures efficaces, mais ne justifie pas de renoncer à une protection adaptée au risque.
• Le moment compte. L'obligation s'applique dès la définition des moyens (choix d'un logiciel, d'un prestataire, d'une architecture) et pendant toute la vie du traitement, y compris pour les systèmes antérieurs au RGPD.

Le CEPD décline ensuite chaque principe de l'article 5 en « éléments clés » à mettre en œuvre. En voici une sélection, utile comme liste de questions en revue de conception :

La protection par défaut porte sur les réglages initiaux d'un traitement, ceux qui s'appliquent si personne ne change rien. Le principe : le réglage le plus protecteur est le point de départ, et c'est à la personne (ou à une décision justifiée du responsable) d'aller au-delà.

La meilleure façon de respecter l'article 25 est de l'inscrire dans la méthode de conduite de projet, avec des jalons où le DPO et le RSSI interviennent ensemble. Voici une trame possible :

Le CEPD insiste sur le rôle des achats : intégrer les exigences de protection des données dans les appels d'offres et les contrats évite de découvrir trop tard qu'un produit ne permet pas, par exemple, de purger les données ou de restreindre les accès. Pour l'appréciation des risques sécurité, le RSSI peut s'appuyer sur une méthode comme EBIOS RM et sur sa PSSI.

Côté développement, la CNIL publie un guide RGPD de l'équipe de développement dont une fiche porte précisément sur la préparation des projets : intégrer la protection des données dans la méthode de développement, puis dans le choix de l'architecture et des outils. C'est un bon point de départ pour traduire le privacy by design en pratiques de code.

Comme pour le reste du RGPD, il ne suffit pas d'avoir bien fait : il faut pouvoir le montrer. Les traces utiles sont les comptes rendus des revues de conception, les exigences du cahier des charges, les analyses d'impact, les réglages par défaut documentés, les tests de recette, et les indicateurs suivis dans le temps (taux de comptes purgés, nombre d'habilitations revues, délais de réponse aux demandes de droits). Un manquement à l'article 25 relève du plafond d'amende de 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial.