a2b82d3e76
Some checks failed
security-audit / Bandit (scan statique) (push) Successful in 14s
security-audit / pip-audit (CVE dépendances) (push) Successful in 12s
security-audit / Scan secrets (grep) (push) Successful in 9s
tests / Lint (ruff + black) (push) Successful in 15s
tests / Tests sécurité (critique) (push) Has been cancelled
tests / Tests unitaires (sans GPU) (push) Has been cancelled
Vrais bugs corrigés :
- core/execution/target_resolver.py : suppression de 5 lignes de dead code
après return (vestige de refacto incomplète référençant des params
jamais assignés à self : similarity_threshold, use_spatial_fallback)
- agent_v0/agent_v1/core/executor.py:2180 : variable `prefill` référencée
mais jamais définie. Initialisation explicite ajoutée en amont
(conditionnée sur _is_thinking_popup, cohérent avec l'append du message)
Fichier supprimé :
- core/security/input_validator_new.py : contenu corrompu (texte inversé,
artefact de copier-coller), jamais importé nulle part, 550 erreurs ruff
à lui seul
Workflow CI :
- Exclusions ajoutées pour dossiers legacy connus cassés :
- agent_v0/deploy/windows_client/ (clone obsolète)
- tests/property/ (cf. MEMORY.md — imports cassés)
- tests/integration/test_visual_rpa_checkpoint.py (VisualMetadata
inexistant, déjà documenté)
Résultat : "ruff All checks passed!" sur core/ agent_v0/ tests/
(avec E9,F63,F7,F82 — syntax + undefined critiques).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
13 KiB
13 KiB
Plan d'Assurance Sécurité (PAS)
Logiciel : Léa — RPA Vision V3 Version : 3.x Date : 14 avril 2026 Client : Clinique Anoust (psychiatrie) Objet : Extraction automatisée de dossiers patients 2024-2025 + constitution d'un Entrepôt de Données de Santé (EDS)
I. Introduction et cadre réglementaire
1.1 Finalité du système
Léa est un système RPA (Robotic Process Automation) basé sur la vision, déployé intégralement en local sur l'infrastructure de l'établissement. Sa finalité est exclusivement administrative :
- Extraction automatisée de données depuis le DPI (OSIRIS)
- Structuration et anonymisation des données extraites
- Alimentation d'un Entrepôt de Données de Santé (EDS)
Le système ne prend aucune décision clinique. Il reproduit les gestes d'un opérateur humain naviguant dans les écrans du DPI.
Lettre de Non-Qualification : Léa n'est pas un dispositif médical au sens du Règlement (UE) 2017/745. Une lettre de non-qualification est fournie.
1.2 Réglementation applicable
| Texte | Applicabilité | Obligations clés |
|---|---|---|
| RGPD (art. 9) | Données de santé mentale = catégorie spéciale | AIPD obligatoire, DPO, base légale art. 6.1.e ou 6.1.f |
| Référentiel CNIL EDS (2021-118) | Entrepôt de données de santé | Déclaration de conformité ou autorisation individuelle |
| AI Act (Règlement UE 2024/1689) | Système IA en contexte de santé | Évaluation du niveau de risque (art. 6(3)), documentation écrite |
| NIS2 (transposition FR juillet 2026) | Établissement de santé = entité importante | Notification incidents 24h, plan de gestion risques cyber |
| HDS (L.1111-8 CSP) | Dispensé si on-premise | Le déploiement sur l'infrastructure de la clinique ne nécessite pas de certification HDS |
| PGSSI-S | Données de santé à caractère personnel | Conformité au palier minimal des référentiels ANS |
| Programme CaRE | Établissements de santé | BIA pour services critiques (échéance juin 2026) |
1.3 Spécificités psychiatrie
- Les notes personnelles du psychiatre (hypothèses, réflexions non formalisées) sont exclues du périmètre d'extraction (art. R4127-45 CSP)
- Anonymisation renforcée : risque de re-identification élevé en psychiatrie (pathologies rares, situations uniques)
- Secret médical renforcé (art. 226-13 Code pénal)
1.4 AI Act — Évaluation du niveau de risque
Léa invoque l'exception de l'art. 6(3) du AI Act :
- (a) Tâche procédurale étroite : extraction de champs depuis des écrans
- (d) Tâche préparatoire : alimentation d'un EDS pour analyse humaine ultérieure
- Aucune décision clinique automatisée
- Supervision humaine permanente (mode supervisé)
Cette évaluation est documentée conformément à l'art. 6(4).
II. Architecture et déploiement
2.1 Principe : déploiement 100% local
┌─────────────────────────────────────────────────────────┐
│ RÉSEAU CLINIQUE ANOUST │
│ │
│ ┌──────────┐ ┌──────────────────────────────┐ │
│ │ Poste │ │ SERVEUR LÉA (VM/bare) │ │
│ │ DPI │◄───────►│ │ │
│ │ (OSIRIS) │ écran │ - Moteur RPA (extraction) │ │
│ └──────────┘ │ - Pipeline anonymisation │ │
│ │ - EDS (PostgreSQL + OMOP) │ │
│ │ - Dashboard (monitoring) │ │
│ └──────────────────────────────┘ │
│ │
│ ⛔ AUCUNE CONNEXION INTERNET SORTANTE │
│ ⛔ AUCUNE DONNÉE NE QUITTE L'ÉTABLISSEMENT │
└─────────────────────────────────────────────────────────┘
2.2 Prérequis infrastructure — à fournir par la clinique
| Élément | Spécification | Notes |
|---|---|---|
| VM ou serveur dédié | 8 vCPU, 32 Go RAM, 500 Go SSD minimum | GPU optionnel (accélère l'OCR mais pas requis) |
| OS | Ubuntu Server 22.04 LTS ou 24.04 LTS | L'établissement gère les MAJ de sécurité OS |
| Adresse IP fixe | 1 IP sur le VLAN santé | Pour le serveur Léa |
| VLAN | VLAN dédié ou VLAN santé existant | Isolation réseau des données patients |
| Accès réseau au DPI | Connectivité vers le poste/serveur OSIRIS | Léa navigue dans l'interface comme un utilisateur |
| Accès SSH | Port 22, limité à 1 IP source (notre maintenance) | Ou VPN site-to-site |
| DNS interne | Résolution des noms internes | Si OSIRIS est accessible par nom |
| Compte utilisateur DPI | Compte OSIRIS dédié "Léa" (lecture seule) | Avec les droits d'accès aux dossiers du périmètre |
| Sauvegarde | Intégration au plan de sauvegarde de l'établissement | VM snapshots ou backup du volume données |
| Certificat TLS | Certificat interne pour HTTPS (ou auto-signé) | Pour le dashboard de monitoring |
2.3 Ports et services
| Port | Protocole | Direction | Usage | Sécurité |
|---|---|---|---|---|
| 443 | HTTPS/TLS | Interne uniquement | Dashboard monitoring + consultation logs | Authentification forte (AD/LDAP clinique) |
| 22 | SSH | Entrant, 1 IP source | Maintenance par nos équipes uniquement | Clé SSH, pas de mot de passe. IP source unique |
| 5432 | TCP | Localhost uniquement | PostgreSQL (EDS) | Écoute 127.0.0.1 uniquement, pas d'accès réseau |
Ports bloqués : tout le reste. Aucun port ouvert vers Internet.
2.4 Règles de firewall (ufw)
# Politique par défaut : tout bloquer
ufw default deny incoming
ufw default deny outgoing
# SSH maintenance (IP source unique fournie par la clinique)
ufw allow from <IP_MAINTENANCE> to any port 22 proto tcp
# HTTPS dashboard (VLAN interne uniquement)
ufw allow from <VLAN_SANTE> to any port 443 proto tcp
# DNS interne (si nécessaire)
ufw allow out to <DNS_INTERNE> port 53
# Bloquer explicitement Internet
ufw deny out to 0.0.0.0/0
2.5 Hardening serveur
- Service RPA sous compte non-root à privilèges limités (
lea-svc) - Chiffrement intégral du disque (LUKS) — protection PI et données
- AppArmor activé avec profil dédié
- Fail2ban sur SSH
- Logs système centralisés (journald)
- Pas de serveur X / interface graphique sur le serveur
III. Sécurité des données et anonymisation
3.1 Cycle de vie des données
Écran DPI (OSIRIS)
│
▼ capture en RAM uniquement
Extraction RPA
│
▼ destruction immédiate des captures écran
Données structurées brutes (RAM)
│
▼ pipeline anonymisation
Données pseudonymisées
│
▼ chargement
EDS (PostgreSQL, disque chiffré LUKS)
│
▼ requêtage
Dashboard (lecture seule, HTTPS)
3.2 Traitement des captures d'écran
- Les images sont traitées en RAM uniquement
- Destruction immédiate après analyse (pas de stockage sur disque)
- Aucune capture d'écran dans les logs
- Les traces d'audit ne contiennent que des métadonnées (horodatage, action, résultat), jamais de contenu patient
3.3 Pipeline d'anonymisation
| Étape | Technologie | Fonction |
|---|---|---|
| NER (détection entités) | EDS-NLP (AP-HP, open source) | Détection noms, dates, lieux, numéros dans le texte clinique français |
| Dé-identification | Remplacement systématique | Noms → pseudonymes, dates → décalage cohérent, lieux → généralisés |
| Validation | Échantillonnage + relecture clinicien | Contrôle qualité sur un échantillon de dossiers |
| Exécution | ONNX Runtime (CPU) | Pas de GPU requis, pas de dépendance cloud |
Exclusions automatiques :
- Notes personnelles du psychiatre (détection par métadonnées OSIRIS)
- Données d'identification directe (NIR, IPP) jamais stockées dans l'EDS
3.4 Entrepôt de Données de Santé (EDS)
| Aspect | Détail |
|---|---|
| SGBD | PostgreSQL 15+ |
| Modèle de données | OMOP CDM v5.4 (standard Health Data Hub) |
| Chiffrement au repos | LUKS (disque) + TDE PostgreSQL optionnel |
| Chiffrement en transit | TLS 1.3 pour toute connexion |
| Accès | Localhost uniquement (pas d'accès réseau direct) |
| Sauvegarde | Intégrée au plan de backup de l'établissement |
| Rétention | Selon politique de l'établissement (max 20 ans, R.1112-7 CSP) |
IV. Traçabilité et audit
4.1 Journal d'audit (RPA traçable)
Toutes les actions du robot sont enregistrées :
| Donnée enregistrée | Exemple |
|---|---|
| Horodatage | 2026-04-14T09:32:15+02:00 |
| Action | extraction_dossier, navigation_ecran, saisie_champ |
| Résultat | succès, échec, pause_supervisée |
| Utilisateur superviseur | dr.martin (via AD) |
| Session ID | sess_20260414_a3f2b1 |
| Durée | 2.3s |
Ce qui n'est JAMAIS enregistré : contenu patient, captures d'écran, données de santé.
4.2 Consultation des logs
- Accès via dashboard web sécurisé (HTTPS/443)
- Authentification via l'annuaire de l'établissement (AD/LDAP)
- Lecture seule — aucun accès direct aux fichiers du serveur
- Rétention des logs : 1 an (configurable)
4.3 Supervision humaine (AI Act)
- Léa fonctionne en mode supervisé : un opérateur peut interrompre, corriger ou stopper le système à tout moment
- En cas d'échec d'une action, Léa se met en pause et attend l'intervention humaine (pas de retry aveugle)
- Toutes les interventions humaines sont tracées
V. Sécurité du code et des modèles IA
5.1 Gouvernance du modèle IA
- Entraînement en vase clos : le modèle apprend exclusivement sur les données d'activité interne, sans export
- Aucune donnée ni modèle transmis à l'extérieur
- Intégrité du modèle : chaque version est signée numériquement — l'application vérifie la signature au démarrage
- Modèles VLM : exécutés localement via Ollama (pas d'API cloud)
5.2 Supply chain logicielle
- SBOM (Software Bill of Materials) : liste complète des composants open source fournie
- Engagement à patcher les vulnérabilités connues (CVE) sous 30 jours (critique) / 90 jours (autres)
- Dépendances auditées : PyTorch, ONNX Runtime, PostgreSQL, Flask, FastAPI
5.3 Protection de la propriété intellectuelle
Le serveur est traité comme une "Boîte Noire" :
- L'établissement n'a pas accès au code source ni aux modèles
- Consultation des logs uniquement via l'interface web (lecture seule)
- Pas d'accès direct au système de fichiers
VI. Maintenance et gestion des incidents
6.1 Maintenance
| Aspect | Détail |
|---|---|
| Accès | SSH, limité à 1 IP source, clé SSH uniquement |
| Intervenant | Exclusivement nos équipes certifiées |
| Fenêtre | En dehors des heures d'extraction (nuit/week-end) |
| Mises à jour | Planifiées, testées en pré-production, validées par le DSI |
| SLA | Intervention sous 4h (critique) / 24h (normal) |
6.2 Gestion des incidents de sécurité
Conformément à NIS2 (transposition FR juillet 2026) :
| Délai | Action |
|---|---|
| < 1h | Détection et containment (isolement du serveur si nécessaire) |
| < 24h | Notification à l'établissement + ANSSI si incident significatif |
| < 72h | Notification CNIL si violation de données personnelles |
| < 30j | Rapport d'incident complet |
6.3 Plan de continuité
- En cas de panne Léa : aucun impact sur le DPI — le robot n'écrit rien dans OSIRIS
- L'extraction peut être reprise là où elle s'est arrêtée (sessions persistantes)
- Les données déjà chargées dans l'EDS restent accessibles
VII. Checklist de conformité
À réaliser avant le démarrage du POC
| # | Action | Responsable | Statut |
|---|---|---|---|
| 1 | Désigner le DPO (si pas déjà fait) | Clinique | ☐ |
| 2 | Réaliser l'AIPD (Analyse d'Impact) | Conjoint (nous + DPO) | ☐ |
| 3 | Valider la base légale (mission intérêt public ou intérêt légitime) | DPO + direction | ☐ |
| 4 | Déclaration CNIL (conformité référentiel EDS ou autorisation) | DPO | ☐ |
| 5 | Créer le compte OSIRIS dédié "Léa" (lecture seule) | DSI | ☐ |
| 6 | Provisionner la VM (specs §II.2) | DSI | ☐ |
| 7 | Configurer le réseau (VLAN, IP, firewall §II.4) | DSI | ☐ |
| 8 | Configurer l'accès SSH maintenance (1 IP source) | DSI | ☐ |
| 9 | Intégrer la VM au plan de sauvegarde | DSI | ☐ |
| 10 | Signer l'accord de confidentialité | Les deux parties | ☐ |
| 11 | Valider le périmètre des dossiers avec le médecin DIM | Clinique | ☐ |
| 12 | Documenter l'évaluation AI Act art. 6(3) | Nous | ☐ |