La plupart des équipes découvrent les fuites de données personnelles après une plainte client ou un audit de conformité. À ce moment-là, les données ont déjà traversé votre pipeline ETL, atterri dans les logs d’application, et été indexées par trois outils d’observabilité différents.

Les retrouver après coup, c’est de l’archéologie. Ce dont vous avez réellement besoin, c’est d’un système qui trace les données personnelles dès leur entrée dans votre code, propage cette connaissance à travers chaque transformation, et les bloque de sortir par les mauvais canaux. Ce n’est pas un problème résolu, mais c’est un problème soluble.

Ce que « tracer les données personnelles » signifie réellement

Le traçage des données personnelles est souvent confondu avec le masquage de données ou le contrôle d’accès. Ce sont des préoccupations liées, mais elles sont en aval du vrai problème. Vous ne pouvez pas rédiger, chiffrer, ou restreindre l’accès à des données que vous ne pouvez pas localiser.

Tracer signifie savoir, à chaque point de votre pipeline, quels champs contiennent des données sensibles. Pas deviner en se basant sur des noms de colonnes comme email ou ssn. Savoir réellement, parce que les données portent une étiquette qui survit à la transformation, l’agrégation et la sérialisation.

Cela nécessite trois choses : un système de types ou une couche de métadonnées qui peut étiqueter des champs comme sensibles, un mécanisme de propagation qui porte ces étiquettes au fur et à mesure que les données se déplacent entre fonctions et services, et des points d’enforcement où vous validez que les données étiquetées ne sont écrites que vers des destinations approuvées.

L’architecture : étiqueter, propager, enforcer

Les implémentations les plus propres que j’ai vues utilisent un type de données étiqueté au niveau du langage. En Python, vous pouvez envelopper des valeurs dans une classe qui porte une étiquette de sensibilité.

from dataclasses import dataclass
from enum import Enum, auto
from typing import Generic, TypeVar

T = TypeVar("T")

class Sensitivity(Enum):
    PLAIN = auto()
    PII = auto()
    PCI = auto()

@dataclass(frozen=True)
class Labeled(Generic[T]):
    value: T
    sensitivity: Sensitivity = Sensitivity.PLAIN

    def map(self, fn):
        return Labeled(fn(self.value), self.sensitivity)

Quand un utilisateur crée un compte, vous étiquetez les entrées brutes à la frontière.

from labeled import Labeled, Sensitivity

def create_user(payload: dict) -> dict:
    email = Labeled(payload["email"], Sensitivity.PII)
    name = Labeled(payload["name"], Sensitivity.PII)
    age = Labeled(int(payload["age"]), Sensitivity.PLAIN)

    user = {
        "id": generate_uuid(),
        "email": email,
        "name": name,
        "age": age,
    }

    return user

L’insight clé est que email et name sont maintenant auto-descriptifs. Toute fonction qui reçoit une valeur Labeled peut inspecter sa sensibilité sans parser le payload ou deviner à partir du nom de clé.

Propager les étiquettes à travers les transformations

Les données étiquetées ne sont utiles que si l’étiquette survit à votre logique métier. Quand vous mappez, filtrez, ou agrégez, vous avez besoin de règles pour comment la sensibilité se combine.

L’ensemble de règles le plus simple est un join semilattice. Si vous fusionnez deux valeurs, le résultat obtient l’étiquette la plus restrictive.

class Sensitivity(Enum):
    PLAIN = 1
    PII = 2
    PCI = 3

    def join(self, other: "Sensitivity") -> "Sensitivity":
        return self if self.value >= other.value else other

Quand vous sérialisez un enregistrement pour un service en aval, vous incluez l’étiquette dans les métadonnées. Le consommateur peut alors décider d’écrire dans une base de données brute, un entrepôt d’analytics masqué, ou un log d’audit.

def serialize(record: dict) -> dict:
    return {
        key: {
            "value": serialize_value(val.value),
            "sensitivity": val.sensitivity.name.lower(),
        }
        for key, val in record.items()
        if isinstance(val, Labeled)
    }

C’est la partie qui fait trébucher les gens. Vous ne pouvez pas simplement étiqueter à l’ingestion et espérer le meilleur. Les étiquettes doivent être une préoccupation de première classe dans votre couche de sérialisation. Si votre format RPC interne perd les métadonnées, votre pipeline devient aveugle dès que les données traversent une frontière de service.

Enforcement : là où les étiquettes comptent réellement

Tracer sans enforcement, c’est du théâtre d’observabilité coûteux. Vous avez besoin de points de blocage où les données étiquetées sont inspectées avant d’être écrites dans un stockage, envoyées sur un réseau, ou rendues dans une interface utilisateur.

Un pattern courant est un registre de sinks qui mappe les destinations à une sensibilité maximale autorisée.

SINK_POLICIES = {
    "raw_postgres": {Sensitivity.PLAIN, Sensitivity.PII, Sensitivity.PCI},
    "analytics_clickhouse": {Sensitivity.PLAIN},
    "application_logs": {Sensitivity.PLAIN},
    "third_party_api": set(),
}

def write(sink_name: str, record: dict):
    allowed = SINK_POLICIES[sink_name]
    for key, val in record.items():
        if isinstance(val, Labeled) and val.sensitivity not in allowed:
            raise ValueError(
                f"Field {key} with sensitivity {val.sensitivity.name} "
                f"is not allowed in sink {sink_name}"
            )
    # proceed with write

Si votre pipeline d’analytics essaie d’ingérer un enregistrement contenant Sensitivity.PII dans ClickHouse, l’écriture échoue au runtime avec une erreur claire. Ce n’est pas élégant, mais c’est explicite. Explicite vaut mieux qu’une violation du GDPR.

Pour les logs en particulier, vous pouvez enforcer ça au niveau du logger. Le module logging de Python supporte des filters qui peuvent inspecter les log records avant qu’ils ne soient émis.

import logging

class PiiFilter(logging.Filter):
    def filter(self, record):
        msg = record.getMessage()
        # In practice, use a more sophisticated check or structured logging
        if any(label in msg for label in ["email", "ssn", "phone"]):
            record.msg = "[REDACTED: PII detected]"
            record.args = ()
        return True

logger = logging.getLogger(__name__)
logger.addFilter(PiiFilter())

C’est un instrument brutal. Une meilleure approche est le structured logging où votre payload de log est le même dictionnaire étiqueté, et le formatter rédige en se basant sur l’étiquette de sensibilité plutôt que sur une regex.

Analyse statique comme filet de sécurité

L’étiquetage au runtime est puissant mais il exige de la discipline. Quelqu’un oubliera d’envelopper un nouveau champ, ou il fera un cast d’une valeur Labeled vers un primitif pour éviter une erreur de type.

L’analyse statique comble le fossé. Des outils comme Semgrep ou des linters personnalisés peuvent enforcer que des strings brutes de bodies de requêtes HTTP ne sont jamais passées directement à des loggers ou des database sinks sans passer par un constructeur d’étiquetage.

Une règle Semgrep minimale pourrait ressembler à ceci :

rules:
  - id: unlabeled-pii-log
    patterns:
      - pattern: logger.info($X)
      - metavariable-pattern:
          metavariable: $X
          pattern-either:
            - pattern: request.json[$FIELD]
            - pattern: request.form[$FIELD]
    message: "Logging raw request data without sensitivity labeling"
    languages: [python]
    severity: ERROR

Ça n’attrapera pas toutes les fuites, mais ça attrapera les évidentes, qui sont là d’où viennent la plupart des fuites.

Les compromis dont personne ne veut parler

Cette approche ajoute de la friction. Chaque transformation de données implique maintenant un champ de métadonnées supplémentaire. Les payloads de sérialisation deviennent plus gros. Les revues de code deviennent des disputes sur le fait que user_agent soit des données personnelles. (Ça l’est en général, d’ailleurs. L’UE le pense.)

Les performances sont une vraie préoccupation. Si vous traitez des millions d’événements par seconde, allouer un wrapper Labeled pour chaque champ est un surcoût mesurable. Dans les hot paths, vous devrez peut-être traiter les vérifications d’étiquettes par lots ou déplacer l’enforcement vers l’edge.

Il y a aussi la charge de maintenance. Les étiquettes de sensibilité ne valent que les humains qui les maintiennent. Quand les réglementations sur la vie privée changent, ou quand votre entreprise s’étend dans une nouvelle juridiction, vous devez ré-étiqueter les données. Il n’y a pas de magie ici. C’est du travail.

Ce que nous n’avons pas choisi : le scan regex au repos

Certaines équipes résolvent ça en scannant les data stores après coup avec des regex, à la recherche de patterns qui ressemblent à des emails ou des numéros de sécurité sociale. C’est mieux que rien, mais c’est fondamentalement réactif.

Les regex manquent les données obfusquées, les identifiants hachés, et les données personnelles composites. Elles produisent aussi des faux positifs qui érodent la confiance dans le système. Nous avons envisagé cette approche tôt et l’avons rejetée parce qu’elle traite le symptôme (données au mauvais endroit) plutôt que la cause (données quittant le service sans étiquette).

Commencez par les points de blocage

Vous n’avez pas besoin d’étiqueter chaque champ dans chaque service dès le premier jour. Commencez par les frontières. Étiquetez les données à leur entrée dans votre système depuis les utilisateurs, les API tierces, et les flux d’événements. Puis ajoutez de l’enforcement à vos sinks à plus haut risque : pipelines d’analytics, infrastructure de logs, et intégrations externes.

Une fois ceux-ci en place, étendez vers l’intérieur. L’objectif n’est pas une couverture parfaite. L’objectif est de rendre les fuites de données personnelles coûteuses à créer par accident, et évidentes à attraper en revue de code.

Si vous construisez ça en Python, la classe Labeled ci-dessus suffit pour commencer. En TypeScript, un branded type ou un wrapper similaire fonctionne de la même manière. En Go, vous voudrez une struct avec un champ non exporté pour éviter les casts accidentels.

Les outils sont simples. La partie difficile est de décider que les données personnelles non tracées sont un bug, et de les traiter comme tel.