# 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.