docs(coordination): protocole de coordination + décisions + inbox + log + vision
- docs/coordination/ : README, decisions (no-ui, pivots MVP), inbox Claude/Qwen/Dom, archive, log, etat-projet - docs/installation/ : procédure SmartScreen - docs/reflexions/ : vision fonctionnelle avant prod Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
154
docs/reflexions/2026-05-28_vision_fonctionnelle_avant_prod.md
Normal file
154
docs/reflexions/2026-05-28_vision_fonctionnelle_avant_prod.md
Normal file
@@ -0,0 +1,154 @@
|
||||
# Vision fonctionnelle — avant remise en production
|
||||
|
||||
**Date :** 2026-05-28
|
||||
**Auteur :** Réflexion Claude, à challenger
|
||||
**Contexte :** Point avant remise en production. Cette note prend du recul sur les fonctionnalités attendues d'un produit de pseudonymisation médicale local, et compare avec l'état actuel du programme.
|
||||
|
||||
---
|
||||
|
||||
## 1. Modèle mental du produit
|
||||
|
||||
Le produit, tel qu'il se dessine aujourd'hui, c'est **un outil de pseudonymisation locale, autonome, multi-établissements, pour des données médicales sensibles**.
|
||||
|
||||
- Déploiement **on-premise** (pas de cloud) → contrainte RGPD/santé forte
|
||||
- Opérateur **humain métier** (pas un développeur) → exigence d'UX
|
||||
- Chaque établissement a ses **spécificités** : mises en page, terminologie, professionnels locaux, codes internes
|
||||
- L'output doit être **utilisable en aval** (publication, partage inter-établissements, recherche, archivage) sans risque de ré-identification
|
||||
|
||||
---
|
||||
|
||||
## 2. Ce qui est déjà aligné avec cette vision
|
||||
|
||||
| Fonctionnalité | État |
|
||||
|---|---|
|
||||
| Détection multi-signal (NER EDS-Pseudo + GLiNER + CamemBERT-bio + regex + gazetteers INSEE/FINESS/BDPM) | ✅ Robuste |
|
||||
| Support multi-formats (PDF, DOCX, ODT, RTF, TXT, HTML, images→OCR) — 14 formats | ✅ Pas de friction |
|
||||
| PDF redaction visuelle (rastérisation + blackout) | ✅ Indispensable pour publier |
|
||||
| Profils + export/import JSON par email | ✅ Bon levier multi-établissements |
|
||||
| Whitelist / blacklist / admin_rules | ✅ Personnalisation sans toucher au code |
|
||||
| Audit JSONL + score qualité automatique | ✅ Traçabilité technique |
|
||||
| Externalisation des dictionnaires (data/, YAML) | ✅ Modifiable sans recompiler |
|
||||
|
||||
---
|
||||
|
||||
## 3. Ce qui semble manquer ou faible pour un vrai produit "prêt"
|
||||
|
||||
### 3.1 Validation humaine intégrée
|
||||
|
||||
**Aujourd'hui :** tout-ou-rien. Le programme tourne, sort des fichiers anonymisés, et l'opérateur fait confiance.
|
||||
|
||||
**Manque :** un mode "review" où l'opérateur valide les détections **incertaines** (confidence < seuil) avant écriture finale.
|
||||
|
||||
**Pourquoi c'est critique en santé :** un faux négatif (PII manqué) = leak RGPD. Un humain dans la boucle sur les cas limites change la donne.
|
||||
|
||||
**Note :** `protocole-validation-humaine.md` et `fiche-validation-humaine-modele.md` existent déjà → la pensée est là, l'implémentation pas encore.
|
||||
|
||||
### 3.2 Rapport de campagne
|
||||
|
||||
**Aujourd'hui :** après un batch, l'opérateur a un dossier de fichiers, sans synthèse globale.
|
||||
|
||||
**Manque :** un rapport PDF/HTML par campagne :
|
||||
- X documents traités, Y entités masquées par type (NOM, TEL, DATE, FINESS…)
|
||||
- Z anomalies à vérifier
|
||||
- Documents en quarantaine (OCR raté, basse confiance)
|
||||
- Signature : version du code + version des règles + horodatage + opérateur
|
||||
|
||||
**Pourquoi c'est critique en santé :** indispensable pour la responsabilité RGPD et la communication avec le DPO.
|
||||
|
||||
**Note :** `rapport-analyse-campagne-gui-2026-04-21.md` existe → réflexion entamée, mais pas d'implémentation détectée.
|
||||
|
||||
### 3.3 Pré-flight / quarantaine automatique
|
||||
|
||||
**Aujourd'hui :** un doc qui passe mal (OCR dégradé, basse confiance globale, format inattendu) sort quand même comme "anonymisé".
|
||||
|
||||
**Manque :** isoler ces documents dans un dossier `quarantaine/` avec un fichier d'explication. Le pire scénario, c'est qu'un opérateur croie qu'un doc est anonymisé alors que l'OCR n'a rien capté.
|
||||
|
||||
### 3.4 Versioning d'audit (métadonnées de sortie)
|
||||
|
||||
**Aujourd'hui :** les fichiers de sortie n'ont pas de métadonnées vérifiables prouvant avec quelle config ils ont été anonymisés.
|
||||
|
||||
**Manque :** chaque sortie devrait porter :
|
||||
- `version_code` (commit SHA ou build_info)
|
||||
- `version_règles` (hash du YAML actif)
|
||||
- `horodatage`
|
||||
- `opérateur` (Windows user ? compte applicatif ?)
|
||||
- `profil_appliqué`
|
||||
|
||||
**Pourquoi c'est critique en santé :** si dans 2 ans on doit prouver qu'une anonymisation a été faite avec quelle config, c'est crucial. Demande type d'un audit DPO ou CNIL.
|
||||
|
||||
### 3.5 Réversibilité contrôlée — question fondamentale
|
||||
|
||||
**Aujourd'hui :** le programme s'appelle "Pseudonymisation" mais remplace par `[NOM]` non réversible → techniquement, c'est de l'**anonymisation**.
|
||||
|
||||
**Différence légale (RGPD) :**
|
||||
- **Pseudonymisation** : les données restent personnelles (Art. 4.5 RGPD), une table de correspondance chiffrée existe → ré-identification autorisée possible
|
||||
- **Anonymisation** : irréversible, sort du périmètre RGPD
|
||||
|
||||
**À trancher :**
|
||||
- Soit on renomme le produit "Anonymisation" et on assume l'irréversibilité
|
||||
- Soit on ajoute une **table de correspondance chiffrée** (clé locale par établissement) qui permet la ré-identification autorisée — fonctionnellement plus puissant, mais ajoute une surface d'attaque
|
||||
|
||||
**Indication métier requise :** que veulent réellement faire les établissements avec les documents anonymisés ? Publication scientifique (anon. pure) ou suivi inter-services (pseudo. avec ré-identification) ?
|
||||
|
||||
---
|
||||
|
||||
## 4. Questions ouvertes qui orienteraient la roadmap
|
||||
|
||||
### 4.1 Cible utilisateur réelle
|
||||
|
||||
- **DSI hospitalier** qui livre des batches mensuels ? → focus sur le throughput, l'audit, la gouvernance, le pré-flight
|
||||
- **Médecin / secrétaire** qui anonymise au cas par cas avant publication ? → focus sur l'UX simple, le drag-and-drop, la prévisualisation
|
||||
- **Les deux** ? → modes utilisateur distincts (Expert / Simple)
|
||||
|
||||
L'UX et les garde-fous changent radicalement selon la cible.
|
||||
|
||||
### 4.2 Sortie attendue / cas d'usage en aval
|
||||
|
||||
- **Publication scientifique** → masquage agressif, irréversible, format texte
|
||||
- **Partage inter-établissements** → masquage modéré, certificat d'anonymisation
|
||||
- **Archivage long terme** → versioning fort, métadonnées complètes
|
||||
- **Recherche / études internes** → pseudonymisation réversible
|
||||
|
||||
Chaque cas implique des **réglages par défaut** et un **niveau d'agressivité** différents.
|
||||
|
||||
### 4.3 Responsabilité — qui signe ?
|
||||
|
||||
- L'outil (auto-validation par score qualité) ?
|
||||
- L'opérateur (validation manuelle obligatoire) ?
|
||||
- Le DPO (workflow d'approbation) ?
|
||||
|
||||
Cela impacte directement :
|
||||
- Le besoin d'audit trail
|
||||
- L'existence d'une UI de validation
|
||||
- La signature numérique (?) des fichiers de sortie
|
||||
|
||||
### 4.4 GUI v6 — re-skin ou refonte fonctionnelle ?
|
||||
|
||||
La maquette HTML v6 est validée (06/05) avec 3 onglets + 4 sous-onglets + éditeur de masques + 4 thèmes. Mais elle conserve la logique fonctionnelle actuelle.
|
||||
|
||||
**Question :** profite-t-on de v6 pour intégrer les fonctions manquantes (validation humaine, rapport campagne, quarantaine, métadonnées) ? Ou est-ce un v6.0 cosmétique suivi d'un v7.0 fonctionnel ?
|
||||
|
||||
---
|
||||
|
||||
## 5. Priorisation suggérée (à challenger)
|
||||
|
||||
| Priorité | Fonction | Effort | Impact prod santé |
|
||||
|---|---|---|---|
|
||||
| 🔴 Critique | Métadonnées de sortie (versioning d'audit) | Faible | Élevé — audit RGPD |
|
||||
| 🔴 Critique | Pré-flight / quarantaine automatique | Moyen | Élevé — évite faux positifs de "doc anonymisé" |
|
||||
| 🟠 Important | Rapport de campagne | Moyen | Élevé — gouvernance |
|
||||
| 🟠 Important | Validation humaine intégrée (mode review) | Élevé | Élevé — qualité finale |
|
||||
| 🟡 À trancher | Réversibilité chiffrée (vraie pseudonymisation) | Élevé | Dépend du besoin métier |
|
||||
| 🟢 Cosmétique | GUI v6 thèmes / éditeur masques | Moyen | Modéré — UX |
|
||||
|
||||
---
|
||||
|
||||
## 6. Décisions à prendre avant de continuer
|
||||
|
||||
1. **Pseudonymisation vs Anonymisation** : trancher le positionnement
|
||||
2. **Cible utilisateur** : DSI batch / médecin individuel / les deux
|
||||
3. **Cas d'usage en aval** : publication / partage / archive / recherche
|
||||
4. **Modèle de responsabilité** : qui signe l'anonymisation
|
||||
5. **Stratégie GUI v6** : cosmétique seul ou refonte fonctionnelle
|
||||
|
||||
Sans ces réponses, la roadmap technique reste un best-effort. Avec elles, on peut prioriser intelligemment.
|
||||
Reference in New Issue
Block a user