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 :

• CHCB
• 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.