# 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.