Add human review protocol and admin rules contract
This commit is contained in:
263
docs/protocole-validation-humaine.md
Normal file
263
docs/protocole-validation-humaine.md
Normal file
@@ -0,0 +1,263 @@
|
||||
# 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)
|
||||
Reference in New Issue
Block a user