Add project framing for anonymization
This commit is contained in:
558
docs/cadrage-projet-anonymisation.md
Normal file
558
docs/cadrage-projet-anonymisation.md
Normal file
@@ -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.
|
||||||
Reference in New Issue
Block a user