# Protocole de validation humaine

## 1. Objet

Ce protocole sert a valider la fonction d'anonymisation avant diffusion ou activation
d'une nouvelle version du moteur, d'une nouvelle regle ou d'une nouvelle famille de
documents.

Il ne remplace pas les tests automatiques. Il les complete sur le point qui compte
le plus pour le projet : **le document anonymise est-il conforme et exploitable ?**

## 2. Quand la validation humaine est obligatoire

La validation humaine est obligatoire si l'un des points suivants est vrai :

- modification du coeur d'anonymisation ;
- ajout ou modification d'une regle de masquage globale ;
- ajout ou modification d'une regle de preservation ;
- changement sur les noms patients, dates de naissance ou identifiants structurants ;
- nouvelle famille documentaire ;
- ecart constate sur le corpus synthetique complet ou le corpus reel annote ;
- demande explicite du responsable qualite ou du metier.

## 3. Entrees minimales requises

Avant la revue humaine, il faut disposer de :

- l'identifiant de version ou de commit ;
- la liste des changements ;
- les resultats des tests unitaires ;
- les resultats de la suite `tests/synthetic_regression/` ;
- les resultats de la suite `tests/synthetic_review/` ;
- les resultats du corpus reel annote si la modification est large ;
- pour chaque cas relu, le triplet :
  - source ;
  - attendu ;
  - produit reel.

## 4. Roles

### 4.1 Operateur de revue

Prepare les elements de preuve :

- sorties texte ;
- diffs ;
- rapport d'audit ;
- resume des ecarts ;
- liste des regles impactees.

### 4.2 Relecteur metier

Verifie que :

- les donnees sensibles ne fuient pas ;
- le document reste lisible ;
- l'information utile au controle est preservee.

### 4.3 Responsable qualite / referent

Prend la decision finale :

- accepte ;
- accepte avec reserve ;
- refuse ;
- renvoie en correction.

## 5. Corpus a relire

### 5.1 Revue minimale

Pour une correction locale :

- les cas synthetiques impactes ;
- les cas complets de `tests/synthetic_review/` impactes ;
- au moins 2 documents reels proches du probleme corrige.

### 5.2 Revue standard

Pour une evolution de regles :

- tous les cas complets de `tests/synthetic_review/` ;
- un sous-ensemble reel annote representatif ;
- un echantillon de documents non annotes mais proches de la production.

### 5.3 Revue renforcee

Pour une release importante :

- toutes les familles documentaires critiques ;
- un echantillon reel relu manuellement pour chaque famille ;
- une analyse des nouveaux faux positifs et faux negatifs.

## 6. Support de revue

### 6.1 Pour les cas synthetiques complets

Utiliser :

- `tests/synthetic_review/cases/<cas>/test.txt`
- `tests/synthetic_review/cases/<cas>/expected.txt`
- `tests/synthetic_review/actual/<cas>/actual.txt`
- `tests/synthetic_review/actual/<cas>/diff.txt`

### 6.2 Pour les cas reels

Utiliser :

- le document source autorise ;
- le texte pseudonymise ;
- le PDF de sortie si disponible ;
- l'audit JSON/JSONL ;
- le rapport de fuite ;
- le rapport d'evaluation si le document est annote.

## 7. Checklist de revue dossier par dossier

### 7.1 Fuites interdites

Verifier l'absence de :

- nom et prenom du patient ;
- date de naissance ;
- adresse, code postal, ville de residence ;
- telephone et email ;
- IPP, NDA, RPPS, FINESS, OGC, numero d'examen, numero interne ;
- identifiants visibles en en-tete, pied de page, tableau ou bloc structure ;
- identifiants coupes sur plusieurs lignes ;
- variantes compactes ou prefixees type `N°1234567`.

### 7.2 Preservation fonctionnelle

Verifier que restent lisibles :

- la structure du document ;
- les services, actes et formulations metier legitimes ;
- les dates non sensibles si elles doivent etre conservees ;
- les libelles utiles au controle ;
- les phrases metier explicitement preservees.

### 7.3 Exploitabilite

Verifier que le document reste :

- comprehensible ;
- utilisable par le controle ;
- pas sur-caviarde au point de perdre sa valeur.

## 8. Classification des anomalies

### 8.1 Bloquant

- fuite de PII patient ;
- fuite d'un identifiant administratif critique ;
- regression majeure sur plusieurs familles ;
- regle active sans preuve de validation.

Decision :

- pas de release ;
- correction obligatoire.

### 8.2 Majeur

- faux positif important qui rend le document difficilement exploitable ;
- preservation non respectee sur un bloc metier cle ;
- comportement instable ou non explicable.

Decision :

- correction avant activation large ;
- ou activation limitee a un perimetre test.

### 8.3 Mineur

- ecart de forme sans perte de conformite ;
- difference de rendu mineure ;
- bruit d'audit sans impact document.

Decision :

- peut etre accepte si documente.

## 9. Decision de validation

Chaque revue doit se conclure par une decision explicite :

- `ACCEPTE`
- `ACCEPTE_AVEC_RESERVE`
- `REFUSE`
- `A_CORRIGER_PUIS_REVOIR`

La decision doit citer :

- la version revue ;
- le nom du relecteur ;
- la date ;
- les cas relus ;
- les anomalies ouvertes ;
- la portee de la decision.

## 10. Preuves a conserver

Conserver a minima :

- identifiant de commit ;
- resultat des tests automatiques ;
- liste des cas relus ;
- fiche de validation humaine ;
- rapport de diff ;
- decision signee ou attribuee nominativement.

## 11. Workflow operationnel recommande

### Etape 1

Executer les tests automatiques :

- `pytest ...`
- `python3 tools/run_synthetic_review_corpus.py`

### Etape 2

Preparer le lot de revue :

- cas impactes ;
- textes attendus ;
- textes reels ;
- synthese des ecarts.

### Etape 3

Faire la revue humaine avec la fiche standard.

### Etape 4

Classer chaque anomalie :

- bloquant ;
- majeur ;
- mineur.

### Etape 5

Prendre une decision de version :

- go ;
- go limite ;
- no go.

## 12. Regle simple de gouvernance

Une regle nouvelle n'est **jamais** activee directement en production si :

- elle n'a pas de cas de test associe ;
- elle n'a pas ete simulee ;
- personne n'a valide ses effets visibles.

## 13. Fichier associe

Le modele de fiche a remplir est dans :

- [fiche-validation-humaine-modele.md](/home/dom/ai/anonymisation/docs/fiche-validation-humaine-modele.md:1)