anonymisation/docs/cadrage-projet-anonymisation.md

# Cadrage projet — anonymisation

## 1. Objet du projet

Le projet n'a pas pour finalite de "faire tourner un pipeline" ni de "passer des tests".
La finalite est plus stricte :

- produire des documents exploitables sans fuite de donnees personnelles ;
- conserver l'information medicale utile au controle ;
- permettre une validation humaine fiable et rapide ;
- rendre les regles d'anonymisation pilotables sans repasser systematiquement par du code.

Autrement dit, la qualite du projet se mesure d'abord sur la **fonction d'anonymisation**,
pas sur l'elegance interne du code.

## 2. Priorites produit

Ordre de priorite assume :

1. **Ne pas laisser fuiter de PII**.
2. **Preserver le sens medical et administratif utile**.
3. **Rendre le comportement verifiable, explicable et auditable**.
4. **Permettre l'ajout rapide de regles metier locales**.
5. **Industrialiser ensuite seulement** : performance, packaging, confort d'usage.

Consequence directe :

- un faux negatif est plus grave qu'un faux positif ;
- mais un taux trop eleve de faux positifs finit par rendre le systeme inutilisable ;
- la bonne cible n'est donc pas "tout masquer", mais "masquer tout ce qui doit l'etre, sans casser l'usage metier".

## 3. Definition de "fonctionne correctement"

Le systeme fonctionne correctement si, ensemble, les conditions suivantes sont remplies :

- aucune fuite critique sur le corpus de validation bloquant ;
- rappel tres eleve sur les PII obligatoires ;
- preservation correcte des termes metier, structures, services, formulations cliniques utiles ;
- stabilite du comportement entre deux versions ;
- explicabilite minimale via les sorties texte, les audits et les diffs ;
- capacite a integrer rapidement une nouvelle regle locale sans regression laterale evidente.

## 4. Definition de done d'une evolution

Une evolution ne doit pas etre consideree comme "terminee" parce que le code compile.
Elle est terminee si :

- les tests unitaires regressifs passent ;
- les cas synthetiques rapides passent ;
- le corpus synthetique complet de revue est relu ou au minimum regenere sans surprise ;
- le sous-ensemble reel annote est dans les seuils cibles ;
- les ecarts nouveaux sont compris et documentes ;
- la revue humaine metier valide que le document reste exploitable.

## 5. Risques structurants du projet

### 5.1 Faux negatifs

Risque principal :

- nom patient en en-tete non propage ;
- identifiant compact non reconnu ;
- libelle et valeur separes sur plusieurs lignes ;
- OCR degrade ;
- PII noyé dans un tableau ou un layout multi-colonnes ;
- nouvelle variante locale non couverte.

Impact :

- non-conformite ;
- exposition de donnees de sante ;
- perte de confiance dans le systeme.

### 5.2 Faux positifs

Risque secondaire mais reel :

- services, actes, classes medicales, phrases metier masques a tort ;
- document rendu illisible pour le controle ;
- inflation des exceptions manuelles.

Impact :

- baisse d'utilite ;
- surcharge de revue humaine ;
- contournements du systeme.

### 5.3 Pilotage des regles

Risque operationnel :

- ajout d'une regle locale trop large ;
- regle non testee qui casse 20 autres formats ;
- absence de trace de qui a ajoute quoi et pourquoi.

Impact :

- regressions silencieuses ;
- gouvernance faible ;
- difficultes d'audit interne.

## 6. Etat actuel utile dans le depot

Le projet dispose deja de briques solides, mais elles ne sont pas encore un cadre complet de validation produit.

Existant :

- configuration externalisee :
  - `config/dictionnaires.default.yml`
  - `config/dictionnaires.yml`
  - `config_defaults.py`
- evaluation :
  - `evaluation/quality_evaluator.py`
  - `evaluation/leak_scanner.py`
  - `evaluation/benchmark.py`
- corpus reel annote :
  - `tests/ground_truth/`
- suite synthetique rapide :
  - `tests/synthetic_regression/`
- corpus synthetique complet de revue humaine :
  - `tests/synthetic_review/`
  - `tools/run_synthetic_review_corpus.py`

Manque encore a ce stade :

- des gates de release formels et assumes ;
- un workflow standard de revue humaine ;
- un moteur de regles administrables avec versioning et validation avant activation ;
- un tableau de bord simple "safe / warning / blocked" pour une version donnee.

## 7. Strategie de validation complete

Il faut raisonner en **4 couches** et non en un seul type de test.

### Couche 1 — garde-fous rapides

Objectif :

- attraper vite les regressions simples et frequentes.

Contenu :

- tests unitaires sur regex, rescan, config, propagation ;
- cas synthetiques courts et stables ;
- verification des sorties texte et de l'audit.

Dans le depot :

- `tests/unit/`
- `tests/synthetic_regression/`

Usage :

- a executer a chaque modification.

### Couche 2 — revue sur documents synthetiques complets

Objectif :

- verifier le comportement d'ensemble sur des documents realistes et diffables.

Contenu :

- documents synthetiques longs ;
- `test.txt` source ;
- `expected.txt` attendu metier ;
- `review.md` indiquant les points critiques ;
- `actual.txt` et `diff.txt` generes par le runner.

Dans le depot :

- `tests/synthetic_review/`
- `tools/run_synthetic_review_corpus.py`

Usage :

- a executer pour toute evolution de regles ou de pipeline ;
- support principal de revue humaine rapide.

### Couche 3 — corpus reel annote

Objectif :

- mesurer la qualite sur des documents representatifs du terrain.

Contenu :

- annotations manuelles ;
- precision, rappel, F1 ;
- analyse des faux positifs / faux negatifs ;
- scanner de fuite.

Dans le depot :

- `tests/ground_truth/`
- `evaluation/`

Usage :

- avant merge important ;
- avant release ;
- avant activation d'une famille de nouvelles regles.

### Couche 4 — validation humaine metier

Objectif :

- confirmer que le document reste exploitable et conforme dans la vraie vie.

Contenu :

- lecture de `expected.txt` vs `actual.txt` ou du PDF de sortie ;
- checklist de revue ;
- validation ou rejet motive ;
- trace date / personne / version / decision.

Usage :

- obligatoire pour les changements qui touchent :
  - les noms patients ;
  - les identifiants administratifs ;
  - les regles globales ;
  - les whitelists / blacklists sensibles ;
  - les formats documentaires majeurs.

## 8. Gates de release proposes

Une release ne doit pas se limiter a "tout est vert dans pytest".

### Gate A — technique minimale

- les tests unitaires passent ;
- la suite synthetique rapide passe ;
- le corpus synthetique complet ne presente aucun ecart non explique ;
- aucun leak critique dans le scanner de fuite.

### Gate B — qualite reelle

Sur le corpus reel annote :

- rappel global >= 99,5 % sur les PII obligatoires ;
- precision >= 97 % ;
- F1 >= 0,98 ;
- aucun document critique avec fuite non acceptee.

Si ces seuils sont trop ambitieux pour une famille documentaire donnee, il faut documenter explicitement l'exception, pas l'ignorer.

### Gate C — validation humaine

- un echantillon de documents impactes est relu ;
- les nouveaux faux positifs sont juges acceptables ou corriges ;
- la decision est tracee.

Sans Gate C, on a un systeme "teste", pas un systeme "approuve".

## 9. Workflow cible d'une modification

### Cas 1 — correction technique simple

1. ecrire ou adapter le test unitaire ;
2. corriger le moteur ;
3. rejouer la suite rapide ;
4. rejouer le corpus synthetique complet ;
5. si changement visible, faire relire les cas impactes.

### Cas 2 — ajout de regle metier

1. definir la regle ;
2. preparer 1 a 3 documents synthetiques representatifs ;
3. lancer le runner de revue ;
4. verifier l'absence de regression sur le corpus reel ;
5. faire valider la regle avant activation globale.

### Cas 3 — nouvelle famille documentaire

1. echantillonner des documents reels ;
2. construire 2 a 4 cas synthetiques representatifs ;
3. annoter un sous-ensemble reel ;
4. regler le pipeline ;
5. passer la revue humaine ;
6. seulement ensuite integrer la famille au gate standard.

## 10. Gouvernance des regles d'anonymisation

Il faut distinguer plusieurs classes de regles.

### 10.1 Regles coeur

Exemples :

- nom, prenom, date de naissance, telephone, email, adresse ;
- RPPS, FINESS, IPP, OGC, NDA, dossier.

Caracteristiques :

- versionnees dans le code ou dans la config versionnee ;
- modifiees rarement ;
- forte revue requise.

### 10.2 Regles locales / metier

Exemples :

- un sigle d'etablissement local ;
- un format de numero interne ;
- un libelle administratif propre a l'organisation.

Caracteristiques :

- doivent etre administrables sans dev lourd ;
- doivent etre historisees ;
- doivent etre testables avant activation.

### 10.3 Regles de preservation

Exemples :

- "classification internationale" ;
- "prise en charge" ;
- "service de cardiologie" ;
- termes structurels indispensables a la lecture.

Caracteristiques :

- aussi importantes que les regles de masquage ;
- toute regle de masquage nouvelle doit etre testee contre elles.

## 11. Cadrage de l'interface d'administration

L'interface d'administration n'est pas une "feature de confort".
C'est un dispositif de pilotage du risque.

### 11.1 Objectif

Permettre a un administrateur metier autorise de :

- ajouter une regle ;
- la tester ;
- visualiser son effet ;
- l'activer ;
- la desactiver ;
- savoir qui l'a creee et pourquoi.

### 11.2 Principe cle

L'admin ne doit jamais saisir "une regex brute obligatoire" comme seule option.
Il faut partir d'objets metier.

### 11.3 Types de regles a proposer en MVP

#### Type A — terme exact

Exemple :

- `CHUXX`
- `LOCAL_SIGLE`

Usage :

- masquer exactement cette chaine, avec ou sans casse.

#### Type B — identifiant normalise

Exemple :

- `1234567`

L'outil doit pouvoir generer automatiquement des variantes comme :

- `1234567`
- `N°1234567`
- `N° 1234567`
- `No 1234567`
- `Numero 1234567`

Et, selon le contexte choisi :

- seulement comme jeton entier ;
- seulement apres certains prefixes ;
- partout dans le document.

#### Type C — prefixe + valeur

Exemple :

- `N° venue : 1234567`
- `IPP : ABC12345`

Usage :

- quand on veut contraindre la detection a un contexte structure plutot qu'au nombre seul.

#### Type D — phrase a ne jamais masquer

Exemple :

- `classification internationale`
- `prise en charge`

Usage :

- proteger les formulations critiques contre les regressions.

### 11.4 Champs minimum d'une regle

- identifiant technique ;
- libelle humain ;
- type de regle ;
- valeur source ;
- placeholder cible ;
- options de normalisation ;
- options de contexte ;
- portee ;
- priorite ;
- auteur ;
- motif ;
- date d'effet ;
- statut : brouillon / testee / active / retiree.

### 11.5 Options de normalisation necessaires

Pour le cas `1234567`, il faut pouvoir cocher par exemple :

- ignorer les espaces ;
- accepter ou non les prefixes `N°`, `No`, `Numero` ;
- accepter ou non les separateurs `:`, `-` ;
- matcher sur ligne simple ou multi-ligne ;
- matcher en casse insensible ;
- matcher seulement sur mot entier.

### 11.6 Portee de la regle

La regle ne doit pas etre obligatoirement globale.
Il faut pouvoir choisir :

- globale ;
- famille documentaire ;
- etablissement ;
- lot de validation ;
- environnement de test uniquement.

### 11.7 Cycle de vie d'une regle

1. creation en brouillon ;
2. simulation sur corpus synthetique ;
3. simulation sur sous-ensemble reel ;
4. lecture du diff ;
5. approbation ;
6. activation ;
7. surveillance ;
8. retrait ou revision.

### 11.8 Garde-fous obligatoires dans l'interface

- previsualisation des variantes generees ;
- affichage du nombre de documents impactes ;
- exemples "avant / apres" ;
- lancement automatique des tests associes ;
- blocage si fuite critique ou regression majeure ;
- journal d'audit des changements ;
- possibilite de rollback.

## 12. Proposition concrete pour ton exemple `N°1234567` / `1234567`

Oui, c'est realisable proprement.

La bonne approche n'est pas :

- "ajouter une ligne de dictionnaire brute et prier".

La bonne approche est :

- creer un type de regle **identifiant normalise** ;
- stocker la valeur canonique `1234567` ;
- generer les variantes autorisees ;
- choisir la portee :
  - partout ;
  - seulement apres prefixes ;
  - seulement en contexte administratif ;
- visualiser les occurrences matchees ;
- valider la regle sur corpus avant activation.

Cela evite deux erreurs classiques :

- rater `N°1234567` parce qu'on n'avait saisi que `N° 1234567` ;
- masquer tous les `1234567` partout alors qu'il fallait un contexte plus strict.

## 13. Tableau de bord de pilotage recommande

Pour chaque version du moteur ou du jeu de regles :

- nombre de cas synthetiques rapides passes ;
- nombre de cas complets de revue passes ;
- nombre de documents reels evalues ;
- rappel / precision / F1 ;
- nombre de fuites critiques ;
- top faux positifs ;
- top faux negatifs ;
- liste des regles ajoutees ou modifiees ;
- decision : OK / WARNING / BLOCKED.

## 14. Roadmap recommandee

### P0 — securiser la fonction d'anonymisation

- stabiliser les gates ;
- enrichir le corpus synthetique complet jusqu'a 10 documents ;
- selectionner un sous-ensemble reel bloquant ;
- formaliser la revue humaine.

### P1 — administrabilite

- definir le modele de regles ;
- implementer le moteur de regles administrables ;
- ajouter la simulation avant activation ;
- tracer les changements.

### P2 — industrialisation

- tableau de bord de validation ;
- packaging propre ;
- exports de rapports ;
- gestion du cycle de vie des regles.

## 15. Decisions recommandees maintenant

### Decision 1

Assumer officiellement que la validation produit repose sur :

- unitaires ;
- corpus synthetique rapide ;
- corpus synthetique complet ;
- corpus reel annote ;
- revue humaine.

### Decision 2

Assumer que toute nouvelle regle d'anonymisation passe par :

- un cas synthetique ;
- une simulation ;
- une validation humaine si la portee est large.

### Decision 3

Faire de l'interface d'administration un **moteur de regles gouverne**, pas un simple formulaire de texte.

## 16. Prochaine etape concrete

La suite la plus utile n'est pas de rajouter encore du code "au hasard".
La suite utile est :

1. fixer le protocole de validation humaine ;
2. etendre `tests/synthetic_review/` a 10 documents complets ;
3. definir le schema de regles d'administration ;
4. concevoir l'ecran MVP d'ajout de regle ;
5. brancher la simulation automatique avant activation.