Protection de la vie privée dès la conception et par défaut.

Deux obligations, pas une

La protection des données dès la conception (privacy by design) et la protection des données par défaut (privacy by default) sont formulées comme une seule obligation du RGPD, mais elles exigent deux choses différentes, et les praticiens s'exposent à des difficultés lorsqu'ils les confondent.

Dès la conception signifie que les mesures de protection de la vie privée sont intégrées à un système dès la phase des exigences, avant qu'une ligne de code ne soit écrite ou qu'un prestataire ne soit choisi, plutôt que rajoutées une fois que les demandes d'accès des personnes concernées commencent à arriver. Par défaut signifie que lorsqu'un utilisateur ne fait rien, le système se trouve déjà dans son réglage le plus protecteur : la collecte de données la plus restreinte, la durée de conservation la plus courte, le partage le plus limité. L'une porte sur la façon dont vous construisez ; l'autre sur ce que le système fait dès le premier jour, sans aucune configuration.

La distinction importe parce qu'une équipe peut satisfaire l'une et manquer l'autre. Vous pouvez mener une revue de conception approfondie, documenter une AIPD, et tout de même livrer un produit dont tous les réglages par défaut sont positionnés sur un partage maximal parce que c'est ce que l'équipe de croissance a demandé. Ce produit relève de la protection dès la conception mais non par défaut, et il n'est pas conforme. L'inverse se produit également : un réglage par défaut prudent rajouté à un système qui n'a jamais été évalué laisse le responsable de traitement incapable de démontrer comment le choix a été fait.

Ce que cela change concrètement en pratique

Le changement pratique consiste à déplacer la protection des données en amont. Au lieu que le service juridique examine une fonctionnalité finalisée, les exigences de protection de la vie privée deviennent des contraintes de conception que l'ingénierie et le produit portent dès le premier sprint. La minimisation des données cesse d'être un slogan et devient une question posée pour chaque champ de chaque formulaire : en avons-nous besoin pour fournir le service, et sinon, pourquoi est-il là. La limitation des finalités devient une contrainte sur ce à quoi un ensemble de données pourra ultérieurement être réutilisé. La conservation devient un calendrier par défaut que le système applique, et non un nettoyage manuel que personne ne pense à lancer.

• Collectez le minimum de champs dont le service a réellement besoin, et justifiez chacun d'eux.
• Définissez les durées de conservation comme des paramètres par défaut appliqués, avec suppression ou anonymisation automatique à leur expiration.
• Positionnez les réglages par défaut de partage, de visibilité et de profilage sur l'option la moins permissive, en laissant l'utilisateur choisir d'en autoriser davantage.
• Appliquez la pseudonymisation et le chiffrement comme des choix architecturaux standard plutôt que comme des exceptions.
• Délimitez l'accès aux données personnelles par finalité, afin qu'un système n'expose que ce qu'une fonction donnée requiert.

Comment cela se situe par rapport aux concepts voisins

La protection des données dès la conception se comprend le plus facilement par contraste avec ce à quoi on la confond. Elle n'est pas la même chose qu'une AIPD, qui est un élément de preuve parmi d'autres que l'obligation plus large a été remplie pour une activité de traitement spécifique et à risque plus élevé.

Elle n'est pas la sécurité dès la conception, qui protège les données contre les attaquants indépendamment de la question de savoir si ces données auraient dû être collectées ; la protection dès la conception commence une étape plus tôt en questionnant la collecte elle-même. Et ce n'est pas un point de contrôle unique. Parce que les systèmes évoluent, l'obligation est continue : chaque nouvelle fonctionnalité, intégration ou flux de données rouvre les mêmes questions de minimisation, de finalité et de réglages par défaut.

Dans un programme mature, la protection des données dès la conception devient une habitude ancrée dans le cycle de développement plutôt qu'un point de contrôle détenu par le service juridique. Le produit et l'ingénierie soulèvent les questions d'eux-mêmes, l'AIPD est déclenchée automatiquement lorsque le traitement franchit un seuil de risque, et la configuration par défaut est examinée dans le cadre de la mise en production plutôt que découverte en production. C'est là toute la différence entre une organisation qui peut démontrer le principe et une autre qui se contente de l'affirmer.