diff --git a/docs/cadrage-projet-anonymisation.md b/docs/cadrage-projet-anonymisation.md
new file mode 100644
index 0000000..26b7369
--- /dev/null
+++ b/docs/cadrage-projet-anonymisation.md
@@ -0,0 +1,558 @@
+# 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.