La protection des données by design — la donnée comme passif

Cette page n'explique pas comment se mettre en conformité — pour les étapes concrètes, voir le guide Respecter le RGPD et la vie privée by design. Elle explique pourquoi une discipline de protection des données modifie la conception en amont, avant même la première ligne de code. Le fil directeur tient en une phrase : une donnée personnelle est un passif, pas un actif.

Le renversement : la donnée n'est pas un trésor

L'intuition ordinaire traite la donnée comme une richesse à accumuler. Plus on en collecte, plus on croit en savoir, plus on se sent capable d'agir plus tard. Cette intuition est un piège de conception. Chaque champ personnel stocké est trois choses à la fois, et aucune n'est un actif :

• une responsabilité — on doit le protéger, le documenter, savoir en rendre compte, et le restituer ou l'effacer sur demande ;
• un risque — il peut fuiter, être détourné de sa finalité, ou devenir la pièce qui transforme un incident mineur en incident grave ;
• un coût — de stockage, de sécurisation, d'audit, et de charge mentale à chaque évolution du système.

Le renversement de la discipline consiste à inscrire ce constat au bilan : au lieu de porter la donnée à l'actif (« ce qu'on possède »), on la porte au passif (« ce dont on répond »). Ce changement de colonne comptable change toutes les décisions qui suivent. On ne se demande plus « quelle donnée puis-je capturer ? » mais « quelle donnée suis-je obligé de porter ? ».

De ce principe unique découlent cinq choix d'architecture. Ils ne sont pas des obligations réglementaires qu'on subit : ce sont les conséquences logiques d'un raisonnement sur le risque, exactement comme les couches d'une défense en profondeur découlent de la défiance envers l'entrée.

Minimisation — la donnée qu'on n'a pas ne fuit pas

C'est le principe premier, celui dont tous les autres dérivent. Réduit à l'essentiel : la seule donnée parfaitement protégée est celle qu'on n'a jamais collectée. Aucun chiffrement, aucune liste blanche, aucun contrôle d'accès ne protège aussi bien que l'absence.

En conception, la minimisation retourne la charge de la preuve. Le défaut n'est pas « je collecte, sauf raison de m'abstenir » mais « je ne collecte pas, sauf raison de le faire ». Devant chaque champ de formulaire, chaque colonne de base, chaque ligne de log, la question précède le code : ai-je réellement besoin de cette donnée pour la finalité que je sers ? Si la réponse hésite, le champ ne naît pas.

C'est le même renversement que le moindre privilège en sécurité : on n'accorde rien par défaut, et chaque exception se justifie. La minimisation est le moindre privilège appliqué à la donnée elle-même. Elle a aussi une hiérarchie interne : préférer l'anonyme au pseudonyme, et le pseudonyme au nominatif. À chaque cran, on réduit ce qu'une fuite pourrait révéler.

L'effet le plus sous-estimé de la minimisation est qu'elle simplifie le système. Moins de champs, c'est moins de surface à sécuriser, moins de chemins à tester, moins de dettes à porter. La donnée non collectée n'a pas besoin d'être chiffrée, sauvegardée, auditée, ni effacée. Elle ne coûte rien parce qu'elle n'existe pas.

Limitation de finalité — un champ sans usage n'existe pas

Une donnée n'est jamais collectée « en général ». Elle l'est pour quelque chose. La limitation de finalité pose que cet usage doit être déclaré avant la collecte, et qu'aucun autre usage ne peut s'y greffer après coup.

En termes de conception, cela transforme la finalité en attribut de premier rang. Un champ sans finalité claire n'est pas un champ « au cas où » : c'est un champ à supprimer. Et un champ collecté pour une finalité ne peut pas être recyclé silencieusement pour une autre — réemployer une adresse fournie pour créer un compte afin d'alimenter une prospection, par exemple, n'est pas une optimisation, c'est un détournement.

La discipline pratique en découle : maintenir une correspondance explicite entre chaque champ et sa raison d'être. Cette table n'est pas un artefact administratif ; c'est la carte qui permet, plus tard, de décider ce qu'on peut supprimer sans rien casser. Un système où l'on ne sait plus pourquoi un champ existe est un système où l'on n'ose plus rien effacer — et l'accumulation s'installe par simple perte de mémoire.

Durée de conservation — la rétention est une décision, pas un défaut

Le comportement par défaut de tout système est de garder. Une donnée écrite reste, sauf effort explicite pour l'effacer. Ce défaut est exactement l'inverse de la bonne posture : conserver doit être une décision, pas l'état par défaut qu'on hérite de l'outillage.

Traiter la donnée comme un passif éclaire ce point. Un passif qu'on garde plus longtemps que nécessaire est un risque qu'on prolonge gratuitement. Une donnée utile aujourd'hui devient, six mois après la fin de son usage, un pur risque résiduel : elle n'apporte plus rien et peut encore fuiter. La durée de conservation borne cette fenêtre de risque.

En conception, cela veut dire attacher une durée — ou une condition d'expiration — à chaque catégorie de donnée, au même titre qu'on lui attache une finalité. La règle la plus simple est souvent la plus sûre : rien au-delà de la vie de ce qui justifie la donnée (le compte, la transaction, la session). Une donnée dont la date de péremption n'est pas pensée est une donnée qu'on gardera indéfiniment par inertie.

Le consentement comme contrat, pas comme case cochée

Réduit à une case à cocher, le consentement devient un obstacle qu'on cherche à faire disparaître au plus vite. C'est un contresens. Le consentement est un contrat entre la personne et le système : elle accorde un usage précis, délimité, et elle peut le reprendre.

Les conséquences de conception sont exigeantes. Un contrat suppose que les deux parties savent ce qui est échangé — donc une finalité lisible, pas noyée dans des conditions générales. Il suppose qu'on ne prenne que ce qui a été accordé — donc pas de collecte annexe glissée sous un consentement obtenu pour autre chose. Il suppose surtout la révocabilité : un consentement qu'on ne peut pas retirer n'est pas un consentement, c'est une capture. Le système doit donc être conçu pour que le retrait soit aussi simple que l'octroi, et qu'il produise un effet réel — l'arrêt du traitement, l'effacement le cas échéant.

Ce n'est pas propre à la donnée : c'est la même logique que la confiance révocable côté serveur d'un appareil validé en sécurité. Une permission qu'on ne peut pas reprendre n'est pas une commodité, c'est une porte qui reste ouverte.

Vie privée par défaut — l'option la plus protectrice est l'état initial

Le dernier principe concerne le point de départ. By default, avant tout choix de l'utilisateur, le système doit se trouver dans sa configuration la plus protectrice. La protection n'est pas une option qu'on active : c'est l'état initial, et c'est l'exposition qui demande un acte explicite.

Cela renverse un réflexe courant. On construit souvent en ouvrant tout, puis en restreignant « si besoin ». La vie privée par défaut fait l'inverse : tout est fermé, et chaque ouverture est un choix conscient. Un profil n'est pas public tant que la personne ne l'a pas rendu public. Un traceur n'est pas posé tant qu'il n'a pas été accepté. Un site public en lecture anonyme peut souvent fonctionner sans aucun cookie de suivi — alors on ne pose rien.

C'est la traduction, côté donnée, du principe qui gouverne l'inscription fermée par défaut et la révélation minimale : un système révèle et expose le moins possible tant qu'un acte explicite ne l'a pas décidé.

Le volet IA ne change pas le raisonnement — il en augmente l'enjeu

L'ajout d'une brique d'intelligence artificielle ne crée pas de nouvelle doctrine ; il applique la même sous une pression plus forte. Un prompt envoyé à un service tiers, un index vectoriel calculé sur des contenus, une collecte automatisée de sources : chacun est un canal par lequel une donnée personnelle peut sortir du périmètre maîtrisé.

La minimisation y devient une règle de filtrage en amont : ne laisser partir dans un prompt que du contenu non personnel, et caviarder ce qui ne devrait pas franchir la frontière. La limitation de finalité y interdit de réutiliser des données collectées pour un usage afin d'entraîner ou d'alimenter un autre. Le raisonnement « la donnée qu'on n'envoie pas ne fuit pas » est le même que « la donnée qu'on ne collecte pas ne fuit pas », transposé à la sortie plutôt qu'à l'entrée. Les questions plus lourdes — transferts hors zone de protection, base légale, sous-traitance d'un fournisseur — ne sont pas des réglages de code : ce sont des décisions à documenter en amont.

Ce que cette discipline n'est pas

Elle n'est pas un frein à ce qu'on construit. Traiter la donnée comme un passif ne veut pas dire tout refuser : cela veut dire ne porter que le passif qu'on assume, en connaissance de cause. Un système qui collecte peu n'est pas un système diminué — c'est un système dont la surface de risque est délibérément petite.

Elle n'est pas non plus une garantie. Comme toute discipline d'ingénierie, elle ne supprime pas le risque ; elle en réduit la probabilité et le coût, et elle rend explicite ce qu'on choisit de porter. Sa seule constante est une posture : à chaque champ envisagé, se demander non pas ce qu'il pourrait rapporter, mais ce qu'il coûtera à protéger — et n'accepter le passif que lorsque la finalité le justifie vraiment.

Voir aussi

• Respecter le RGPD et la vie privée by design — les étapes concrètes de mise en conformité (le comment).
• La sécurité en couches — minimisation, moindre privilège et révélation minimale appliqués à la sécurité.
• La discipline d'ingénierie — le registre général des arbitrages assumés.
• Catalogue des standards et normes — les référentiels officiels applicables.