chore: sauvegarde complète avant factorisation executor

Point de sauvegarde incluant les fichiers non committés des sessions précédentes (systemd, docs, agents, GPU manager). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-20 17:03:44 +02:00
parent 623be15bfe
commit 447fbb2c6e
1869 changed files with 791438 additions and 324 deletions
--- a/docs/AUDIT_20260404.md
+++ b/docs/AUDIT_20260404.md
@@ -0,0 +1,897 @@
+# Audit Complet — RPA Vision V3
+
+**Date** : 4 avril 2026  
+**Auditeur** : Claude Sonnet 4.6 + 5 agents d'exploration spécialisés  
+**Périmètre** : Projet complet (code source, tests, sécurité, déploiement, qualité)  
+**Environnement** : Ubuntu 24.04, Python 3.12.3, NVIDIA RTX 5070 (12 Go VRAM)
+
+---
+
+## Table des matières
+
+1. [Synthèse exécutive](#1-synthèse-exécutive)
+2. [Métriques clés](#2-métriques-clés)
+3. [Architecture](#3-architecture)
+4. [Modules core — Analyse détaillée](#4-modules-core--analyse-détaillée)
+5. [Composants web](#5-composants-web)
+6. [Agent V0/V1 — Streaming](#6-agent-v0v1--streaming)
+7. [Tests](#7-tests)
+8. [Sécurité](#8-sécurité)
+9. [Déploiement & Infrastructure](#9-déploiement--infrastructure)
+10. [Qualité du code](#10-qualité-du-code)
+11. [Performances](#11-performances)
+12. [Gestion des dépendances](#12-gestion-des-dépendances)
+13. [Documentation](#13-documentation)
+14. [Espace disque](#14-espace-disque)
+15. [Points forts](#15-points-forts)
+16. [Points faibles & Risques](#16-points-faibles--risques)
+17. [Recommandations](#17-recommandations)
+18. [Score global](#18-score-global)
+
+---
+
+## 1. Synthèse exécutive
+
+RPA Vision V3 est un système d'automatisation RPA 100% basé sur la vision (pas d'accessibilité, pas de sélecteurs DOM). Il utilise CLIP, FAISS, Ollama (VLM local), SomEngine (YOLO + docTR) et le template matching pour identifier et interagir avec les éléments d'interface.
+
+**État** : Phase 0 complète, Phase 1 (streaming agent) en stabilisation.  
+**Maturité** : Prototype avancé / pré-production.  
+**Risque principal** : Tokens de production hardcodés dans le code source.
+
+Le projet est fonctionnel : le replay visuel fonctionne sur Windows, le VWB permet de construire des workflows, le dashboard de monitoring est opérationnel. Cependant, la dette technique s'accumule (fichiers monolithiques, 47 Go de venvs dupliqués, code mort) et des failles de sécurité critiques doivent être corrigées avant toute mise en production.
+
+---
+
+## 2. Métriques clés
+
+### Volume de code
+
+| Métrique | Valeur |
+|----------|--------|
+| Fichiers Python (hors venvs/archives) | 1 094 |
+| Lignes de code source | 190 382 |
+| Lignes de tests | 63 114 |
+| Lignes TypeScript/JavaScript (frontend) | 39 868 (103 fichiers) |
+| **Total lignes de code** | **~293 000** |
+| Ratio tests/source | 33,2% |
+| Commits | 123 |
+| Contributeur unique | Dom |
+| Période de développement | 7 jan → 4 avril 2026 (88 jours) |
+
+### Répartition du code source par module
+
+| Module | Lignes | % du total |
+|--------|--------|------------|
+| `core/` | 74 555 | 39,2% |
+| `visual_workflow_builder/` | 45 830 | 24,1% |
+| `agent_v0/` | 23 637 | 12,4% |
+| `scripts/` | 16 525 | 8,7% |
+| `deploy/` | 7 097 | 3,7% |
+| `agent_chat/` | 6 937 | 3,6% |
+| `examples/` | 4 510 | 2,4% |
+| `server/` | 2 897 | 1,5% |
+| `web_dashboard/` | 2 430 | 1,3% |
+| Autres (cli, gui, i18n, etc.) | 5 964 | 3,1% |
+
+### Sous-modules core/ (top 10 par taille)
+
+| Sous-module | Lignes | Rôle |
+|-------------|--------|------|
+| `execution/` | 12 503 | Exécution d'actions, DAG, target resolver |
+| `visual/` | 5 493 | Screen analyzer, SomEngine, visual matching |
+| `analytics/` | 5 230 | Métriques, rapports, statistiques |
+| `workflow/` | 4 328 | Gestion workflows, scheduler |
+| `detection/` | 4 202 | UI detector, Ollama client, VLM config |
+| `models/` | 3 492 | Modèles de données (workflow graph, etc.) |
+| `security/` | 3 365 | API tokens, rate limiting, audit trail |
+| `embedding/` | 2 914 | CLIP embedder, FAISS manager |
+| `system/` | 2 862 | Safety switch, auto-heal, hooks |
+| `corrections/` | 2 780 | Corrections BBOX, sniper mode |
+
+---
+
+## 3. Architecture
+
+### Architecture 5 couches
+
+```
+RawSession → ScreenState → UIElement → StateEmbedding → WorkflowGraph
+   (1)          (2)           (3)           (4)              (5)
+```
+
+1. **RawSession** : Capture brute (screenshots + événements souris/clavier)
+2. **ScreenState** : État d'écran analysé (éléments détectés, OCR)
+3. **UIElement** : Éléments d'interface identifiés (boutons, champs, menus)
+4. **StateEmbedding** : Vecteurs CLIP/FAISS pour recherche similaire
+5. **WorkflowGraph** : Graphe de workflow exécutable
+
+### Services (8 services, gérés par `svc.sh`)
+
+| Port | Service | Type | Framework |
+|------|---------|------|-----------|
+| 8000 | API Server (upload/processing) | required | FastAPI |
+| 5001 | Web Dashboard | required | Flask + SocketIO |
+| 5002 | VWB Backend | required | Flask + SQLAlchemy |
+| 5003 | Monitoring | optional | Flask |
+| 5004 | Agent Chat | optional | Flask + SocketIO |
+| 5005 | Streaming Server (Agent V1) | optional | FastAPI |
+| 5099 | Worker (polling) | optional | Python script |
+| 3002 | VWB Frontend | required | React 19 + Vite |
+
+### Points d'entrée
+
+| Fichier | Rôle |
+|---------|------|
+| `run.sh` | Chef d'orchestre — lance les composants selon les flags |
+| `svc.sh` | Gestionnaire de services (systemd + legacy PID) |
+| `cli.py` | CLI interactif (660 lignes) |
+| `services.conf` | Source de vérité des ports et commandes |
+
+### Diagramme de flux principal
+
+```
+[Agent V1 Windows]
+    ↓ (capture screenshots + events)
+    ↓ HTTP POST /upload_batch
+[Streaming Server :5005]
+    ↓ stream_processor.py
+    ↓ (ScreenAnalyzer → CLIP → FAISS → GraphBuilder)
+[Core Pipeline]
+    ↓ build_replay() → resolve_target()
+    ↓ (SomEngine → VLM grounding → template matching)
+[Replay Engine]
+    ↓ HTTP → Agent V1
+    ↓ executor.py
+[Agent V1 Windows]
+    ↓ PyAutoGUI (Bézier mouse + char-by-char typing)
+```
+
+---
+
+## 4. Modules core — Analyse détaillée
+
+### 4.1 Détection (`core/detection/` — 10 fichiers, 4 202 lignes)
+
+| Fichier | Lignes | Rôle |
+|---------|--------|------|
+| `ui_detector.py` | ~800 | Détecteur principal (CLIP + template matching) |
+| `ollama_client.py` | ~600 | Client Ollama pour VLM (gemma4:e4b) |
+| `vlm_config.py` | ~200 | Configuration VLM (modèle, endpoint) |
+| `screen_analyzer.py` | ~500 | Analyse complète d'un screenshot |
+| `som_engine.py` | ~315 | Set-of-Mark (YOLO + docTR), singleton thread-safe |
+| `owl_detector.py` | ~300 | OWL-ViT v2 pour détection zero-shot |
+| `template_matcher.py` | ~400 | Template matching OpenCV |
+
+**Stratégie de résolution** (cascade) :
+1. **Grounding VLM** (Qwen2.5-VL GPU) — pour éléments avec texte OCR
+2. **Template matching** (OpenCV) — pour icônes sans texte
+3. **SomEngine + VLM** — fallback multi-étapes
+
+**Imports lourds** : `torch`, `transformers`, `open_clip_torch`, `cv2`, `PIL`
+
+### 4.2 Exécution (`core/execution/` — 15 fichiers, 12 503 lignes)
+
+**Fichiers critiques** :
+
+| Fichier | Lignes | Rôle |
+|---------|--------|------|
+| `target_resolver.py` | 3 495 | Résolution multi-stratégie de cibles |
+| `execution_loop.py` | 1 361 | Boucle principale d'exécution |
+| `action_executor.py` | 1 171 | Exécuteur d'actions individuelles |
+| `dag_executor.py` | ~800 | Exécution de DAG (workflows parallèles) |
+| `llm_actions.py` | ~600 | Actions LLM (analyse, traduction, extraction) |
+| `memory_cache.py` | 1 059 | Cache mémoire pour optimisation |
+
+**⚠️ `target_resolver.py`** est le fichier le plus complexe du core. Il implémente 5+ stratégies de résolution : texte OCR, ancrage visuel, template matching, SomEngine, VLM grounding. À surveiller pour la maintenabilité.
+
+**⚠️ `dag_executor.py:532`** utilise `eval()` pour évaluer des conditions de workflow :
+```python
+result = bool(eval(condition, {"__builtins__": {}}, eval_context))
+```
+Le `__builtins__: {}` limite les risques mais ne les élimine pas (contournement possible via `type.__subclasses__`).
+
+### 4.3 GPU (`core/gpu/` — 6 fichiers, 1 735 lignes)
+
+| Fichier | Rôle |
+|---------|------|
+| `gpu_resource_manager.py` | Orchestrateur GPU (modes RECORDING/AUTOPILOT/IDLE) |
+| `ollama_manager.py` | Gestion cycle de vie modèles Ollama (async) |
+| `clip_manager.py` | Gestion modèle CLIP (lazy load, GPU↔CPU) |
+
+**Architecture GPU** :
+- Mode **RECORDING** : VLM sur GPU, CLIP sur CPU
+- Mode **AUTOPILOT** : VLM déchargé, CLIP sur GPU
+- Seuil VRAM CLIP : 1 024 Mo
+- Timeout inactivité : 300s
+
+### 4.4 Authentification (`core/auth/` — 5 fichiers, 1 223 lignes)
+
+| Fichier | Rôle |
+|---------|------|
+| `credential_vault.py` | Coffre-fort chiffré (Fernet AES + PBKDF2 600k itérations) |
+| `totp_generator.py` | TOTP RFC 6238 (30s, 6 digits) |
+| `auth_handler.py` | Orchestration authentification multi-facteur |
+
+**⚠️ Fallback non sécurisé** : si `cryptography` n'est pas installé, le vault utilise un simple encodage base64.
+
+### 4.5 Fédération (`core/federation/` — 3 fichiers, 1 339 lignes)
+
+Export/import de LearningPacks anonymisés entre instances. Merge FAISS global. Endpoints REST dédiés.
+
+### 4.6 Graph Builder (`core/graph/` — 4 fichiers, 1 949 lignes)
+
+Construit le WorkflowGraph à partir des sessions d'enregistrement. `graph_builder.py` (1 616 lignes) accepte `precomputed_states` pour skip ScreenAnalyzer.
+
+### 4.7 Autres modules notables
+
+| Module | Fichiers | Lignes | Rôle |
+|--------|----------|--------|------|
+| `healing/` | 13 | 2 343 | Auto-correction, learning packs |
+| `monitoring/` | 8 | 1 967 | Triggers, chain manager, scheduler |
+| `security/` | 10 | 3 365 | API tokens, rate limiting, audit trail |
+| `pipeline/` | 4 | 1 695 | Pipeline de traitement principal |
+| `training/` | 6 | 1 999 | Entraînement et adaptation |
+| `analytics/` | 25 | 5 230 | Reporting, métriques, dashboard data |
+
+---
+
+## 5. Composants web
+
+### 5.1 Visual Workflow Builder (VWB)
+
+**Backend** (`visual_workflow_builder/backend/`) :
+- Framework : Flask + SQLAlchemy + Flask-SocketIO
+- Base de données : `workflows.db` (SQLite)
+- Routes principales : `catalog_routes_v2_vlm.py` (2 836 lignes — **monolithique**)
+- API v3 : `dag_execute.py` (1 058 lignes), `execute.py` (1 173 lignes)
+- VLM Provider : `vlm_provider.py` — interface Ollama pour détection visuelle
+- Actions disponibles : 15+ catégories (data, intelligence, navigation, validation, vision_ui)
+
+**Frontend** :
+- Framework : React 19 + TypeScript + MUI 7 + Redux Toolkit
+- Flow editor : `@xyflow/react` v12
+- WebSocket : `socket.io-client`
+- 103 fichiers TS/TSX (39 868 lignes)
+- **⚠️ 2 dossiers frontend** : `frontend/` (1,3 Go avec node_modules) et `frontend_v4/` (79 Mo)
+
+### 5.2 Web Dashboard (`web_dashboard/`)
+
+- Framework : Flask + SocketIO
+- Fichier unique : `app.py` (2 430 lignes — **monolithique**)
+- 65 routes Flask
+- Fonctionnalités : monitoring sessions, replay, métriques, proxy streaming
+- **⚠️ `cors_allowed_origins="*"`** — pas de restriction CORS
+
+### 5.3 Agent Chat (`agent_chat/`)
+
+- Framework : Flask + SocketIO (6 937 lignes, 8 fichiers)
+- `app.py` (2 570 lignes — **monolithique**)
+- `autonomous_planner.py` — planification autonome de workflows
+- Interface conversationnelle pour le pilotage RPA
+
+---
+
+## 6. Agent V0/V1 — Streaming
+
+### 6.1 Client Agent V1 (`agent_v0/agent_v1/`)
+
+Déployé sur la machine Windows cible. Léger, sans GPU.
+
+| Fichier | Rôle |
+|---------|------|
+| `main.py` | Point d'entrée, configuration |
+| `core/executor.py` | Exécution actions (PyAutoGUI, Bézier, char-by-char) |
+| `vision/capturer.py` | Capture screenshots (mss) |
+| `network/streamer.py` | Streaming vers serveur (HTTP batch upload) |
+| `ui/notifications.py` | Notifications utilisateur |
+| `window_info_crossplatform.py` | Info fenêtre active (Windows/Linux) |
+
+### 6.2 Serveur Streaming (`agent_v0/server_v1/`)
+
+Tourne sur le serveur avec GPU (RTX 5070).
+
+| Fichier | Lignes | Rôle |
+|---------|--------|------|
+| `api_stream.py` | **5 612** | API FastAPI (27 endpoints) + replay + résolution + admin |
+| `stream_processor.py` | **4 656** | Orchestrateur central (analyse, CLIP, FAISS, graph) |
+| `live_session_manager.py` | ~600 | Gestion sessions en mémoire |
+| `worker_stream.py` | ~400 | Worker polling + API directe |
+| `replay_failure_logger.py` | ~200 | Logger d'échecs replay |
+| `vm_controller.py` | ~150 | Contrôle VM (virsh) |
+
+**⚠️ `api_stream.py` et `stream_processor.py`** totalisent **10 268 lignes** à eux deux. C'est le fichier le plus urgent à découper.
+
+---
+
+## 7. Tests
+
+### 7.1 Vue d'ensemble
+
+| Métrique | Valeur |
+|----------|--------|
+| Tests collectés (hors property) | 1 463 |
+| Tests passants | **1 401** |
+| Tests échoués | **9** |
+| Tests skippés | 43 |
+| Tests xfailed | 4 |
+| Tests xpassed | 1 |
+| Durée totale | 318s (~5min18) |
+| **Taux de succès** | **95,8%** (hors skips : 99,4%) |
+
+### 7.2 Répartition des fichiers de test
+
+| Catégorie | Fichiers | Rôle |
+|-----------|----------|------|
+| `unit/` | 70 | Tests unitaires isolés |
+| `integration/` | 47 | Tests d'intégration (services, API) |
+| `smoke/` | 1 | Smoke test E2E minimal |
+| `performance/` | 1 | Benchmarks |
+| `property/` | 7 | Tests basés sur propriétés (Hypothesis) — **CASSÉS** |
+| Racine `tests/` | 10 | Tests E2E pipeline, correction packs, coaching |
+| `utils/` | 1 | Utilitaires de test |
+
+### 7.3 Tests en échec (9 tests)
+
+| Test | Raison |
+|------|--------|
+| `test_diagnostic_actions_manquantes_vwb` (×3) | Actions VWB manquantes dans le catalogue |
+| `test_fiche11_multi_anchor_constraints` (×1) | Déterminisme tie-breaking non garanti |
+| `test_vwb_actions_09jan2026` (×5) | Mock executor obsolète |
+
+### 7.4 Tests non collectables (erreurs de collection)
+
+| Fichier | Erreur |
+|---------|--------|
+| `tests/property/*.py` (7 fichiers) | Imports cassés (modules supprimés/renommés) |
+| `tests/integration/test_visual_rpa_checkpoint.py` | Import `VisualMetadata` inexistant |
+
+### 7.5 Couverture par module core
+
+| Module | Couverture | Module | Couverture |
+|--------|-----------|--------|-----------|
+| `models/` | Excellente (129 imports) | `execution/` | Excellente (50 imports) |
+| `workflow/` | Excellente (49 imports) | `capture/` | Bonne (29 imports) |
+| `visual/` | Bonne (21 imports) | `detection/` | Bonne (19 imports) |
+| `embedding/` | Bonne (18 imports) | `pipeline/` | Bonne (23 imports) |
+| `healing/` | Modérée (10 imports) | `analytics/` | Modérée (11 imports) |
+| `auth/` | Faible (3 imports) | `security/` | Très faible (1 import) |
+| `gpu/` | Très faible (2 imports) | `extraction/` | Très faible (2 imports) |
+| **`supervision/`** | **AUCUNE** | **`matching/`** | **AUCUNE** |
+| **`variants/`** | **AUCUNE** | | |
+
+3 modules sur 31 n'ont **aucun test** : `supervision`, `matching`, `variants`.
+
+### 7.5 Configuration pytest
+
+```ini
+testpaths = tests
+addopts = -q --tb=short --strict-markers
+markers = unit, integration, performance, slow, smoke, fiche1..fiche10
+filterwarnings = ignore::DeprecationWarning
+```
+
+**⚠️ Le Makefile pointe vers `venv_v3/bin/pytest`** au lieu de `.venv/bin/pytest` (le venv actif).
+
+### 7.7 Marqueurs pytest sous-utilisés
+
+6 marqueurs `fiche` sur 10 sont réellement utilisés (fiche4, fiche6, fiche7, fiche8, fiche9, fiche10). Les marqueurs fiche1, fiche2, fiche3, fiche5 sont déclarés mais jamais appliqués à aucun test.
+
+---
+
+## 8. Sécurité
+
+### 8.1 Vulnérabilités CRITIQUES
+
+#### 🔴 Clés API cloud en clair dans `.env.local`
+
+**Fichier** : `.env.local` (gitignored mais sur disque)
+
+Le fichier contient en clair :
+- `ANTHROPIC_API_KEY=sk-ant-api03-...` (clé Anthropic complète)
+- `OPENAI_API_KEY=sk-proj-...` (clé OpenAI complète)
+- `GOOGLE_API_KEY=AIzaSy...` (clé Google complète)
+- `DEEPSEEK_API_KEY=3d7b...` (clé Deepseek complète)
+- `ENCRYPTION_PASSWORD`, `SECRET_KEY`, `RPA_TOKEN_ADMIN`, `AUTOHEAL_ADMIN_TOKEN`, `RPA_API_TOKEN`
+
+**Impact** : Si le disque est compromis ou si le fichier fuite (backup, copie), toutes les clés cloud sont exposées. Les clés Anthropic/OpenAI ont un coût financier direct.
+
+**Remédiation** :
+- Révoquer et régénérer toutes les clés cloud immédiatement
+- Utiliser un gestionnaire de secrets (Vault, systèmes de credentials)
+- A minima, permissions `chmod 600` et propriétaire `dom:dom` uniquement
+
+#### 🔴 Tokens de production hardcodés
+
+**Fichier** : `core/security/api_tokens.py:93-94`
+
+```python
+# Temporary fix: Add production tokens directly
+prod_admin_token = "73cf0db73f9a5064e79afebba96c85338be65cc2060b9c1d42c3ea5dd7d4e490"
+prod_readonly_token = "7eea1de415cc69c02381ce09ff63aeebf3e1d9b476d54aa6730ba9de849e3dc6"
+```
+
+Ces tokens **admin** sont dans le code source, visibles dans git. Ils donnent un accès complet à l'API de streaming (port 5005) exposé sur Internet via `lea.labs.laurinebazin.design`.
+
+**Impact** : Un attaquant peut prendre le contrôle total de l'agent RPA et exécuter des actions arbitraires sur la machine cible.
+
+**Remédiation immédiate** : Révoquer ces tokens, les déplacer dans `.env`, régénérer.
+
+#### 🔴 `eval()` dans le DAG executor
+
+**Fichier** : `core/execution/dag_executor.py:532`
+
+```python
+result = bool(eval(condition, {"__builtins__": {}}, eval_context))
+```
+
+Même avec `__builtins__: {}`, `eval()` est contournable via introspection Python. Si `condition` provient d'une entrée utilisateur (workflow JSON), c'est une injection de code.
+
+**Remédiation** : Remplacer par un parser AST sécurisé ou une grammaire restreinte.
+
+#### 🔴 Clé de chiffrement par défaut
+
+**Fichier** : `core/security/api_tokens.py:80`
+
+```python
+self.secret_key = os.getenv("TOKEN_SECRET_KEY", "dev-token-secret-change-in-production")
+```
+
+En production sans la variable d'environnement, la clé de signature des tokens est connue.
+
+### 8.2 Vulnérabilités HAUTES
+
+#### 🟠 Désérialisation `pickle.load()` non sécurisée
+
+**Fichiers** :
+- `core/embedding/faiss_manager.py:517,534`
+- `core/visual/visual_embedding_manager.py`
+
+```python
+with open(metadata_path, 'rb') as f:
+    pickle.load(f)  # Pas de restriction
+```
+
+`pickle.load()` sans restrictions permet l'exécution de code arbitraire si un fichier `.pkl` est compromis (fichier metadata FAISS). Si un attaquant peut placer un fichier `.pkl` malveillant dans `data/embeddings/`, il obtient une exécution de code.
+
+**Remédiation** : Migrer vers JSON/msgpack pour les métadonnées, ou valider l'intégrité des fichiers avec HMAC.
+
+#### 🟠 `shell=True` dans subprocess (11 occurrences)
+
+**Fichier** : `agent_v0/server_v1/vm_controller.py` (10 occurrences)
+
+```python
+subprocess.run(f"virsh start {self.domain_name}", shell=True, check=True)
+```
+
+Si `domain_name` est contrôlé par l'utilisateur, c'est une injection de commandes.
+
+**Autres occurrences** :
+- `web_dashboard/app.py:1851` — `lsof -ti :{port} | xargs -r kill`
+- `visual_workflow_builder/backend/catalog_routes_v2_vlm.py:2181` — `os.system('echo ...')`
+
+#### 🟠 `os.system()` avec variables non sanitisées
+
+- `agent_v0/agent_v1/ui/smart_tray.py:557` — `os.system(f'xdg-open "{sessions_path}"')`
+
+Si `sessions_path` contient des guillemets ou des caractères shell, injection possible.
+
+#### 🟠 CORS permissif
+
+- `web_dashboard/app.py:41` — `cors_allowed_origins="*"` (accepte toutes les origines)
+- Le streaming server a une liste blanche configurable (mieux)
+
+#### 🟠 Logs contenant des tokens partiels
+
+**Fichier** : `core/security/api_tokens.py:73-76`
+
+```python
+logger.info(f"RPA_TOKEN_ADMIN value: {admin_token[:8]}...")
+```
+
+Les 8 premiers caractères du token sont loggés. Insuffisant pour une compromission directe mais réduit l'entropie.
+
+### 8.3 Vulnérabilités MOYENNES
+
+| Problème | Fichiers | Impact |
+|----------|----------|--------|
+| `bare except:` (69 occurrences) | Tout le projet | Masque les erreurs, empêche le debugging |
+| `except Exception:` (191 occurrences) | Tout le projet | Trop large, capture des erreurs inattendues |
+| Fallback base64 dans credential vault | `core/auth/credential_vault.py` | Pas de chiffrement réel sans `cryptography` |
+| Bearer token fixe (pas de rotation) | `core/security/api_tokens.py` | Token compromis = accès permanent |
+| Logs partiels de tokens (8 premiers chars) | `core/security/api_tokens.py:73-76` | Réduit l'entropie |
+| Variables globales VLM non thread-safe | `core/detection/vlm_config.py` | Race condition possible |
+
+### 8.4 Points positifs sécurité
+
+- Credential Vault avec Fernet AES + PBKDF2 (600k itérations, conforme OWASP 2023)
+- TOTP RFC 6238 pour 2FA
+- Rate limiting configurable
+- Audit trail (retention 180 jours)
+- Floutage des données sensibles dans les replays
+- HTTPS via Let's Encrypt en production
+- Bearer token obligatoire sur les endpoints exposés
+
+---
+
+## 9. Déploiement & Infrastructure
+
+### 9.1 Gestion des services
+
+- **`svc.sh`** : Gestionnaire centralisé (systemd + fallback PID files)
+- **`services.conf`** : Source de vérité (8 services, ports, commandes)
+- **7 services systemd** dans `deploy/systemd/` (user-level)
+
+### 9.2 Packaging Windows
+
+- `deploy/build_package.sh` : Vérifie 26 fichiers requis
+- Package "Léa" pour collaborateurs non-techniques
+- Auto-stop enregistrement (1h max, notification à 50min)
+- DPI awareness (SetProcessDpiAwareness(2))
+
+### 9.3 Exposition Internet
+
+| URL | Service | Auth |
+|-----|---------|------|
+| `lea.labs.laurinebazin.design` | Streaming :5005 | Bearer token |
+| `vwb.labs.laurinebazin.design` | VWB frontend :3002 | HTTP Basic (lea/Medecin2026!) |
+
+Reverse proxy : NPM (Nginx Proxy Manager) via Docker.
+
+### 9.4 Duplication dans deploy/
+
+Le dossier `deploy/build/Lea/` contient une **copie complète** de l'agent V1 (executor.py, chat_window.py, etc.) qui **diverge** du code source :
+- `executor.py` : 1 576 lignes (deploy) vs 1 653 lignes (source) — manque le `NotificationManager`
+- `TARGETED_CROP_SIZE` : 400×400 (deploy) vs 80×80 (source)
+
+---
+
+## 10. Qualité du code
+
+### 10.1 Fichiers monolithiques (> 2 000 lignes)
+
+| Fichier | Lignes | Responsabilités mélangées |
+|---------|--------|---------------------------|
+| `api_stream.py` | 5 612 | API + replay + résolution + admin + healthcheck |
+| `stream_processor.py` | 4 656 | Orchestration + nettoyage + replay builder + enrichissement |
+| `target_resolver.py` | 3 495 | 5+ stratégies de résolution mélangées |
+| `catalog_routes_v2_vlm.py` | 2 836 | Routes API + logique VLM + actions |
+| `agent_chat/app.py` | 2 570 | Serveur Flask + logique chat + WebSocket |
+| `web_dashboard/app.py` | 2 430 | Dashboard + 65 routes + proxy |
+
+### 10.2 Debug print() en production
+
+| Zone | Nombre de `print()` |
+|------|---------------------|
+| `visual_workflow_builder/` | ~1 500 |
+| `scripts/` | ~800 |
+| `examples/` | ~600 |
+| `core/` | ~500 |
+| `agent_v0/` | ~400 |
+| `deploy/` | ~300 |
+| `agent_chat/` | ~150 |
+| `cli.py` | 130 |
+| **Total** | **~4 350** |
+
+La majorité provient de scripts de démonstration/diagnostic, mais ~500 sont dans le core et ~400 dans l'agent, utilisés en production.
+
+### 10.3 TODO / FIXME / HACK
+
+**50 marqueurs** dans le code actif (hors venvs) :
+
+| Fichier | Nombre | Exemple |
+|---------|--------|---------|
+| `stream_processor.py` | 12 | Nettoyage, refactoring, edge cases |
+| `auto_heal_manager.py` | 4 | Logique de récupération |
+| `cli.py` | 3 | Fonctionnalités manquantes |
+| `api_stream.py` | 3 | Optimisations pending |
+
+### 10.4 Cohérence du code
+
+#### Bug réel : `_MODIFIER_ONLY_KEYS` divergent
+
+```python
+# core/graph/graph_builder.py — 12 entrées
+_MODIFIER_ONLY_KEYS = {
+    "ctrl", "ctrl_l", "ctrl_r",
+    "alt", "alt_l", "alt_r",
+    "shift", "shift_l", "shift_r",
+    "win", "cmd", "cmd_l", "cmd_r",
+    "meta", "super", "super_l", "super_r",
+}
+
+# agent_v0/server_v1/stream_processor.py — 20 entrées
+_MODIFIER_ONLY_KEYS = {
+    "ctrl", "ctrl_l", "ctrl_r", "control", "control_l", "control_r",
+    "alt", "alt_l", "alt_r", "alt_gr",
+    "shift", "shift_l", "shift_r",
+    "win", "win_l", "win_r", "cmd", "cmd_l", "cmd_r",
+    "meta", "meta_l", "meta_r", "super", "super_l", "super_r",
+}
+```
+
+Le `graph_builder.py` ne reconnaît pas `control`, `control_l`, `control_r`, `alt_gr`, `win_l`, `win_r`, `meta_l`, `meta_r` comme des modificateurs. Cela peut causer des actions fantômes dans les workflows construits à partir des sessions enregistrées sur Windows.
+
+### 10.5 Imports circulaires
+
+**Aucun import circulaire détecté** entre les sous-modules de `core/`. C'est un point positif qui témoigne d'une bonne architecture en couches.
+
+### 10.6 Code mort
+
+- `_a_trier/` : **561 Mo**, 261 fichiers Python orphelins non triés
+- `archives/` : 21 Mo de code archivé
+- `scripts/` : 39 fichiers (16 525 lignes) de scripts de diagnostic/validation datés de janvier 2026, probablement obsolètes
+- `examples/` : 29 fichiers de démonstration, certains avec des imports cassés
+- 2 frontends VWB (`frontend/` 1,3 Go et `frontend_v4/` 79 Mo)
+- `visual_workflow_builder/backend/app_lightweight.py` (1 451 lignes) et `app_catalogue_simple.py` (1 370 lignes) — alternatives apparemment non utilisées
+
+---
+
+## 11. Performances
+
+### 11.1 Performances mesurées (31 mars 2026)
+
+| Méthode | Précision | Vitesse | Usage |
+|---------|-----------|---------|-------|
+| Template matching 80×80 | dist=0.000 (parfait) | 0,1s | Icônes sans texte |
+| Grounding Qwen2.5-VL GPU | dist<0.04 (exact) | 2-5s | Éléments avec texte OCR |
+| SomEngine CPU (build_replay) | 80% détection | 1,4s | Enrichissement enregistrement |
+
+### 11.2 Replay E2E Windows (meilleur résultat)
+
+- 19/20 actions correctes (Word ouvert, texte tapé, document enregistré)
+- 0 retries
+- Temps moyen : 2,4s/clic
+- Point faible : icônes sans texte OCR sur écrans différents
+
+### 11.3 Tests (durée d'exécution)
+
+- 1 457 tests en ~318s (5min18) avec `-m "not slow"`
+- 6 tests marqués `@slow` (GPU-dépendants)
+
+---
+
+## 12. Gestion des dépendances
+
+### 12.1 requirements.txt principal
+
+176 dépendances pinnées, incluant :
+
+| Catégorie | Packages clés |
+|-----------|--------------|
+| ML/IA | `torch==2.9.1`, `transformers==4.57.3`, `open_clip_torch==3.2.0`, `timm==1.0.24` |
+| Vision | `opencv-python==4.12.0.88`, `pillow==12.1.0`, `python-doctr==1.0.1` |
+| Recherche | `faiss-cpu==1.13.2`, `scikit-learn==1.8.0` |
+| Web | `fastapi==0.128.0`, `Flask==3.0.0`, `uvicorn==0.40.0` |
+| Automatisation | `PyAutoGUI==0.9.54`, `pynput==1.8.1`, `mss==10.1.0` |
+| GUI | `PyQt5==5.15.11` |
+| Sécurité | `cryptography==46.0.3` |
+| NVIDIA | `nvidia-cublas-cu12`, `nvidia-cudnn-cu12`, etc. (CUDA 12.8) |
+
+### 12.2 Fichiers requirements multiples
+
+7 fichiers `requirements*.txt` (hors archives) pour différents sous-projets. Risque de désynchronisation.
+
+### 12.3 setup.py minimal
+
+```python
+install_requires=["numpy", "pillow", "faiss-cpu", "scikit-learn", "open_clip_torch"]
+```
+
+Ne reflète pas les dépendances réelles (manque torch, transformers, fastapi, flask, etc.). Le `setup.py` est vestigial.
+
+### 12.4 Pas de pyproject.toml
+
+Le projet utilise `setup.py` + `pytest.ini` au lieu du standard moderne `pyproject.toml`. Pas de linter configuré (ruff, black, mypy ne sont pas dans la CI).
+
+---
+
+## 13. Documentation
+
+### 13.1 Volume
+
+- **136 fichiers** dans `docs/` (dont ~100 rapports de sessions/corrections de janvier 2026)
+- Documentation structurée dans `docs/reference/`, `docs/specs/`, `docs/fiches/`, `docs/guides/`
+- `docs/README.md` — index bien organisé
+
+### 13.2 Documents clés
+
+| Document | Contenu |
+|----------|---------|
+| `docs/reference/ARCHITECTURE_VISION_COMPLETE.md` | Architecture 5 couches complète |
+| `docs/specs/requirements.md` | 15 requirements, 89 critères d'acceptation |
+| `docs/specs/design.md` | Design détaillé, 20 correctness properties |
+| `docs/specs/tasks.md` | Plan d'implémentation 13 phases, 60+ tâches |
+| `docs/CONFORMITE_AI_ACT.md` | Conformité Règlement IA européen |
+| `docs/PLAYBOOK_DSI_RSSI.md` | Playbook pour DSI/RSSI |
+| `docs/DOSSIER_COMMISSAIRE_AUX_APPORTS.md` | Dossier d'évaluation financière |
+
+### 13.3 Points d'attention
+
+- ~100 fichiers de rapports de sessions datés (janvier 2026) polluent le dossier `docs/`
+- Pas de documentation API auto-générée (Swagger/OpenAPI non configuré malgré FastAPI)
+- Pas de CONTRIBUTING.md ou CHANGELOG.md formels
+- Les commentaires dans le code sont en français (cohérent avec la convention du projet)
+
+---
+
+## 14. Espace disque
+
+### 14.1 Taille totale : 61 Go
+
+| Élément | Taille | % |
+|---------|--------|---|
+| `.venv/` (principal) | 9,0 Go | 14,8% |
+| `visual_workflow_builder/backend/venv` | 8,3 Go | 13,6% |
+| `venv_v3/` (legacy) | 7,8 Go | 12,8% |
+| `venv/` (legacy) | 7,5 Go | 12,3% |
+| `visual_workflow_builder/venv` | 7,3 Go | 12,0% |
+| `agent_v0/.venv` | 7,1 Go | 11,6% |
+| **Total venvs** | **47,0 Go** | **77,0%** |
+| `data/` | 3,2 Go | 5,2% |
+| `frontend/node_modules` | 1,3 Go | 2,1% |
+| `.git/` | 633 Mo | 1,0% |
+| `_a_trier/` | 561 Mo | 0,9% |
+| `models/` | 511 Mo | 0,8% |
+| Code source + docs + reste | ~400 Mo | 0,7% |
+
+### 14.2 Venvs dupliqués — problème critique
+
+**6 environnements virtuels** pour un seul projet, totalisant **47 Go**. Chacun contient probablement PyTorch (~2 Go), transformers, etc. en doublon.
+
+**Venvs actifs** :
+- `.venv/` — principal (utilisé par pytest, svc.sh)
+- `visual_workflow_builder/backend/venv` — backend VWB
+
+**Venvs probablement inutiles** :
+- `venv/` — ancien, probablement jamais nettoyé
+- `venv_v3/` — ancien (référencé dans le Makefile mais plus utilisé)
+- `visual_workflow_builder/venv` — probablement remplacé par `backend/venv`
+- `agent_v0/.venv` — l'agent V1 est déployé séparément sur Windows
+
+**Recommandation** : Supprimer les venvs inutilisés pour gagner ~30 Go.
+
+---
+
+## 15. Points forts
+
+1. **Architecture 5 couches claire** : Séparation nette des responsabilités, 30 sous-modules core sans imports circulaires
+2. **100% vision** : Approche unique et cohérente, pas de raccourcis (accessibility API, DOM selectors)
+3. **Suite de tests conséquente** : 1 463 tests, 95,8% de succès, couverture des modules critiques
+4. **SomEngine bien conçu** : 315 lignes, singleton thread-safe, lazy loading, documentation
+5. **Gestion GPU sophistiquée** : Modes RECORDING/AUTOPILOT, arbitrage VRAM automatique
+6. **Sécurité crypto solide** : Fernet AES + PBKDF2 600k, TOTP RFC 6238
+7. **Conformité réglementaire** : Rétention 180j, floutage, audit trail, dossier AI Act
+8. **Packaging Windows robuste** : Vérification des 26 fichiers, auto-stop, DPI awareness
+9. **Anti-détection** : Bézier mouse movement + frappe caractère par caractère
+10. **Commits conventionnels** : Préfixes `feat:/fix:/refactor:/chore:` respectés
+11. **Infrastructure as Code** : systemd services, svc.sh, services.conf
+12. **Cascade de résolution intelligente** : VLM → template matching → SomEngine (fail-safe)
+
+---
+
+## 16. Points faibles & Risques
+
+### 16.1 Risques critiques (P0)
+
+| # | Risque | Impact | Fichier |
+|---|--------|--------|---------|
+| 1 | **Clés API cloud en clair** (Anthropic, OpenAI, Google, Deepseek) | Compromission financière + accès APIs | `.env.local` |
+| 2 | Tokens admin hardcodés dans le code | Compromission complète de l'API exposée sur Internet | `core/security/api_tokens.py:93-94` |
+| 3 | `eval()` sur conditions workflow | Injection de code arbitraire | `core/execution/dag_executor.py:532` |
+| 4 | Clé de signature par défaut | Forge de tokens en production | `core/security/api_tokens.py:80` |
+
+### 16.2 Risques hauts (P1)
+
+| # | Risque | Impact |
+|---|--------|--------|
+| 5 | `pickle.load()` sans restrictions | Exécution de code via fichiers `.pkl` malveillants |
+| 6 | 11 `subprocess(shell=True)` avec variables | Injection de commandes |
+| 7 | `_MODIFIER_ONLY_KEYS` divergent entre modules | Actions fantômes dans les workflows |
+| 8 | Executor dupliqué et divergent (source vs deploy) | Comportement différent en prod |
+| 9 | 36+ fichiers modifiés non commités | Perte de travail potentielle |
+
+### 16.3 Risques moyens (P2)
+
+| # | Risque | Impact |
+|---|--------|--------|
+| 8 | Fichiers monolithiques (api_stream.py : 5 612 lignes) | Maintenabilité, risque de régression |
+| 9 | 47 Go de venvs (77% de l'espace disque) | Espace disque, confusion |
+| 10 | 4 350 print() en production | Pas de logging structuré, debug en prod |
+| 11 | 69 bare except:, 191 except Exception: | Erreurs masquées |
+| 12 | 7 tests property cassés | Fausse couverture |
+| 13 | Makefile pointe vers mauvais venv | DX cassée |
+| 14 | `setup.py` ne reflète pas les vraies dépendances | Installation cassée |
+| 15 | CORS `*` sur le dashboard | Pas de restriction cross-origin |
+
+### 16.4 Dette technique (P3)
+
+| # | Problème | Volume |
+|---|----------|--------|
+| 16 | `_a_trier/` non trié | 561 Mo, 261 fichiers Python |
+| 17 | Scripts de diagnostic datés (jan 2026) | 39 fichiers, 16 525 lignes |
+| 18 | 2 frontends VWB | 1,3 Go vs 79 Mo |
+| 19 | ~100 rapports de sessions dans docs/ | Pollution documentation |
+| 20 | 50 TODO/FIXME dans le code actif | Travail non terminé |
+| 21 | Pas de CI/CD (linter, tests automatiques) | Qualité non vérifiée automatiquement |
+| 22 | Pas de pyproject.toml | Configuration fragmentée |
+
+---
+
+## 17. Recommandations
+
+### Immédiat (cette semaine) — Sécurité & Risque de perte
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 1 | **Révoquer toutes les clés API cloud** (Anthropic, OpenAI, Google, Deepseek dans `.env.local`) et régénérer | 1h | 🔴 Critique |
+| 2 | **Supprimer les tokens hardcodés** de `api_tokens.py`, les charger uniquement depuis `.env` | 30min | 🔴 Critique |
+| 3 | **Remplacer `eval()` par `ast.literal_eval`** ou un parser restreint | 2h | 🔴 Critique |
+| 4 | **Commiter les 36+ fichiers modifiés** ou les stasher | 15min | 🔴 Perte de travail |
+| 5 | **Supprimer la clé par défaut** dans `TOKEN_SECRET_KEY` | 15min | 🔴 Critique |
+| 6 | **Corriger `cors_allowed_origins="*"`** dans web_dashboard | 10min | 🟠 Haut |
+
+### Court terme (1-2 semaines) — Cohérence & Hygiène
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 7 | Unifier `_MODIFIER_ONLY_KEYS` dans un module partagé | 1h | 🟠 Bug réel |
+| 8 | Corriger le Makefile (`venv_v3` → `.venv`) | 5min | 🟡 DX |
+| 9 | Supprimer les 4 venvs inutilisés (~30 Go) | 10min | 🟡 Espace |
+| 10 | Remplacer `subprocess(shell=True)` par des listes d'arguments | 2h | 🟠 Injection |
+| 11 | Remplacer `pickle.load()` par JSON/msgpack dans faiss_manager | 2h | 🟠 Sécurité |
+| 12 | Supprimer la copie divergente dans `deploy/build/Lea/` | 1h | 🟠 Cohérence |
+| 13 | Corriger les 9 tests en échec | 4h | 🟡 Qualité |
+
+### Moyen terme (1-2 mois) — Maintenabilité
+
+| # | Action | Effort | Impact |
+|---|--------|--------|--------|
+| 12 | Découper `api_stream.py` (5 612L) en 4+ modules | 2j | 🟡 Maintenabilité |
+| 13 | Découper `stream_processor.py` (4 656L) | 2j | 🟡 Maintenabilité |
+| 14 | Remplacer les `print()` par `logging` (core + agent) | 1j | 🟡 Observabilité |
+| 15 | Nettoyer `_a_trier/` (561 Mo) | 2h | 🟡 Hygiène |
+| 16 | Supprimer/archiver les scripts de diagnostic de jan 2026 | 1h | 🟡 Hygiène |
+| 17 | Migrer vers `pyproject.toml` | 2h | 🟡 Standards |
+| 18 | Configurer CI (ruff + pytest + pre-commit) | 4h | 🟡 Qualité |
+| 19 | Activer Swagger/OpenAPI pour FastAPI | 1h | 🟡 Documentation |
+| 20 | Réparer ou supprimer les 7 tests property | 4h | 🟡 Couverture |
+
+### Long terme (3+ mois) — Scalabilité
+
+| # | Action | Effort |
+|---|--------|--------|
+| 21 | Containeriser avec Docker (multi-stage builds) |
+| 22 | Implémenter la rotation de tokens API |
+| 23 | Ajouter des health checks automatisés pour chaque service |
+| 24 | Mettre en place un pipeline CI/CD complet (build → test → deploy) |
+| 25 | Implémenter le monitoring Prometheus/Grafana |
+
+---
+
+## 18. Score global
+
+| Axe | Note | Commentaire |
+|-----|------|-------------|
+| **Fonctionnalité** | 8/10 | Pipeline complet, replay fonctionnel, VWB opérationnel |
+| **Architecture** | 7/10 | 5 couches bien séparées, mais fichiers monolithiques |
+| **Tests** | 7/10 | 1 463 tests, 95,8% succès, mais property tests cassés |
+| **Sécurité** | 2/10 | Clés API cloud en clair + tokens hardcodés + eval() + pickle + shell=True |
+| **Cohérence** | 5/10 | Duplication code, venvs multiples, divergences |
+| **Dette technique** | 4/10 | 4 350 print(), 561 Mo non trié, fichiers géants |
+| **Documentation** | 6/10 | Bonne structure mais polluée par les rapports de session |
+| **Déploiement** | 6/10 | systemd + svc.sh fonctionnels, mais pas de CI/CD |
+| **Performance** | 8/10 | 2,4s/clic, cascade intelligente, GPU bien géré |
+| **DX (Developer Experience)** | 5/10 | Makefile cassé, venvs confus, pas de linter |
+| **Global** | **5,7/10** | Solide fonctionnellement, sécurité et housekeeping urgents |
+
+### Verdict
+
+RPA Vision V3 est un projet ambitieux et techniquement impressionnant dans sa vision (100% basé sur la vision, pas de sélecteurs). Le pipeline fonctionne, le replay est opérationnel, et l'architecture 5 couches est bien pensée.
+
+Cependant, **la mise en production est bloquée** par les failles de sécurité critiques (tokens hardcodés, eval(), clé par défaut). Les actions P0 doivent être traitées **avant toute exposition supplémentaire sur Internet**.
+
+La dette technique (fichiers monolithiques, 47 Go de venvs, 4 350 print()) ne bloque pas le fonctionnement mais ralentira significativement le développement futur. Un sprint de nettoyage de 1-2 semaines apporterait un ROI important.
+
+---
+
+*Généré le 4 avril 2026 par Claude Sonnet 4.6 — Audit multi-agents (5 agents parallèles : architecture, core, tests, web, sécurité)*
--- a/docs/CHALLENGE_PLANS_16AVRIL.md
+++ b/docs/CHALLENGE_PLANS_16AVRIL.md
@@ -0,0 +1,291 @@
+# Challenge des plans d'action — Dashboard & VWB
+
+_16 avril 2026 — critique transversale des deux plans du 15 avril, avant exécution._
+_Lecture ciblée : 10 minutes. Aucune modification de code. Ton direct._
+
+---
+
+## Section 0 — Verdict global
+
+Les deux plans sont **globalement justes**, bien structurés, honnêtes sur la dette. Mais :
+- **Le plan Dashboard** sous-estime le couplage avec l'audit trail backend (risque cascading), et pousse un onglet Audit un peu trop ambitieux pour un POC qui démarre dans 2 semaines.
+- **Le plan VWB** a une bonne hiérarchie mais **deux erreurs factuelles** (B5 vise le mauvais frontend, et la "bibliothèque qui s'efface" peut avoir une cause simple non explorée) et rate une priorité réelle : **le backup automatique des workflows n'existe pas**.
+- **Aucun des deux plans ne parle à l'autre** — ils pourraient se contredire sur correction_packs et sur l'audit.
+
+Recommandation : exécuter VWB quick wins en priorité (impact immédiat pour Dom), puis Dashboard cleanup, puis audit MVP. PAS l'onglet Audit "DSI-ready complet" avant le POC Anouste.
+
+---
+
+## Section 1 — Dashboard : ce qui tient, ce qui ne tient pas
+
+### 1.1. Ce qu'on valide tel quel
+
+- **Retirer onglet 🧪 Tests (B1)** — correct, la RCE implicite via pytest subprocess est réelle, à éjecter sans regret.
+- **Retirer onglet ⚡ Exécution (B4)** — la logique Agent V1 a déprécié l'ancien SocketIO `subscribe_execution`, plus personne ne regarde ça.
+- **Retirer pages auxiliaires `/chat`, `/gestures`, `/streaming`, `/extractions`** — doublons morts. Bonne décision.
+- **Section E (non-décisions)** — tout est juste : pas de React, pas de SSO, pas de WebSocket Audit. Sagesse YAGNI.
+
+### 1.2. Ce qu'on ajuste
+
+**B2 — Retirer onglet 🧠 Apprentissage**
+Le plan dit "10 min". Challenge : l'onglet affiche `statCorpusSize` qui est peut-être câblé ailleurs (conftest, training worker, etc.). Avant de retirer, vérifier qu'aucun autre consommateur (jobs, scripts) ne dépend de ces routes. Budget réaliste : **20-30 min** pour grep + vérifier, pas 10.
+
+**B5 — Retirer onglet 📊 Vue d'ensemble**
+"30 min" pour retirer + "fusionner un mini-résumé (4 KPIs) en tête de Services" — la fusion n'est pas gratuite. Si Dom veut garder les 4 KPIs, compter **1 h** (déplacement + CSS + test). Si on retire franc et net sans fusion, alors **15 min**. Trancher maintenant.
+
+**Estimation onglet Audit MVP (0.75 j)**
+C'est réaliste **à condition** que le proxy Flask `/api/audit/*` → 5005 soit vraiment du copy-paste du pattern `/api/streaming/*`. Mais le plan omet :
+- Côté streaming server, le token `RPA_API_TOKEN` est requis → le dashboard doit le propager (fait par le pattern `/api/streaming` mais pas mentionné dans le plan Audit).
+- Le volume de données est surestimé : "1 800 entrées aujourd'hui" **faux** — 18 entrées aujourd'hui dans `audit_2026-04-15.jsonl`, 430 le jour de test du 13 avril. Le volume réel est faible, la pagination serveur n'est pas critique pour le POC.
+
+**Rapport PDF DSI (0.5 j)**
+Sous-estimé. ReportLab/WeasyPrint sur une page A4 avec tableau + signature d'intégrité, c'est plutôt **1 j**, à cause du templating, de la gestion des polices, du tableau qui déborde, des caractères accentués (French), et surtout du hash chain (voir 1.3).
+
+**Signature d'intégrité journalière (SHA-256)**
+Le plan dit "20 lignes". Réaliste côté code, mais il faut :
+- décider quand la clôture journalière a lieu (minuit UTC ? heure locale ?),
+- stocker les hashes quelque part (fichier `.sig` ? table `audit_signatures` ?),
+- rejouer la vérification facilement (`python -m tools.verify_audit YYYY-MM-DD`).
+Compter **0.5 j** honnête, pas 0.25.
+
+### 1.3. Ce qu'on retire du plan
+
+**Alerting seuil d'échecs (0.5 j en Sprint 3)**
+Pourquoi on le sort : le dashboard est un outil interne déjà bien chargé. Un "badge rouge si >N échecs/h" sans destinataire email configuré = gadget visuel. Si un jour il y a un vrai besoin RSSI, ça passe par n8n (déjà dans le stack) ou Prometheus alerting. **Ne pas le coder ici.**
+
+**Widgets graphiques (camembert + courbe 7j)**
+Pas avant validation MVP par un vrai DSI. Le tableau + filtres + export CSV suffisent pour 90 % des cas d'usage. Les graphiques, c'est du polish, à faire après retour client.
+
+### 1.4. Ce qu'on ajoute
+
+**Backup BDD workflows VWB dans l'onglet Sauvegardes**
+Aujourd'hui `/api/backup/*` côté dashboard ne touche probablement pas à `visual_workflow_builder/backend/instance/workflows.db`. Or c'est là que vivent les 3 workflows réels de Dom. À vérifier et intégrer au cron backup. **Critique pour le POC.**
+
+**Lien explicite Dashboard → VWB**
+Si on retire les onglets "Workflows" et "Corrections", il faut un bouton "Ouvrir VWB" visible. Le plan le mentionne en passant dans "Services" mais ne le tranche pas. À préciser.
+
+**Health check streaming server**
+L'onglet Streaming affiche les sessions, mais pas le statut du serveur 5005. Si le serveur tombe, Dom voit l'iframe vide sans message clair. Ajouter un check explicite côté dashboard.
+
+---
+
+## Section 2 — VWB : ce qui tient, ce qui ne tient pas
+
+### 2.1. Ce qu'on valide tel quel
+
+- **B2 (Unnamed Workflow)** — 20 min, impact immédiat, bon.
+- **B3 (supprimer vwb_v3.db fantôme)** — 15 min, risque réel identifié. Oui.
+- **B4 (double logging)** — confirmé dans les logs (chaque ligne présente 2×), 15 min, fait.
+- **B6 (nettoyer fichiers parasites)** — hygiène, 10 min.
+- **B7 (run.sh clarification)** — 20 min, évite que Dom et nous lancions le mauvais frontend.
+- **Sections D et E (non-décisions)** — toutes justifiées.
+
+### 2.2. Ce qu'on ajuste
+
+**B1 — Migrer sessionStorage → localStorage**
+Challenge fort : le plan dit "30 min → résout le bug principal". Je ne suis pas convaincu que `sessionStorage` soit la **seule** cause du bug "la bibliothèque s'efface tout le temps". Hypothèses alternatives à tester **avant** de coder :
+1. L'utilisateur ouvre un nouvel onglet (vrai effacement sessionStorage, OK).
+2. Un StrictMode React qui double-mount et écrase le state.
+3. Un `setCaptureLibrary([])` appelé par erreur dans un `useEffect` sans dépendance.
+4. Une exception silencieuse qui reset l'état (QuotaExceededError de sessionStorage si > 5 Mo de base64 PNG).
+
+**Le plan saute direct à la solution sans diagnostic.** Avant de migrer, **reproduire le bug 2 minutes avec la console ouverte** pour voir *quand* il se déclenche. Si c'est un quota, localStorage ne sauvera rien (même limite). **Ne pas coder avant de comprendre.**
+
+Sous réserve que ce soit bien sessionStorage, la migration localStorage est bonne, mais :
+- clé `captureLibrary_v3` : bien de ne PAS migrer les deux anciennes clés automatiquement (laisser Dom perdre l'historique mauvais, repartir propre).
+- cap 200 captures : OK mais thumbnails JPEG 200×150 q=0.7 au lieu de PNG base64 **impératif** sinon on fait sauter le quota en 15 captures.
+
+Budget réaliste : **1 h** (diagnostic 15 min + migration 30 min + compression thumbnail 15 min).
+
+**B5 — Supprimer 404 /api/correction-packs/stats**
+**Erreur factuelle dans le plan** : B5 dit que l'appel vient de `frontend/src/hooks/useCorrectionPacks.ts` (legacy). Confirmé par grep. Mais le plan n'explique pas **pourquoi on voit ces 404 aujourd'hui alors que seul frontend_v4 tourne**. Deux possibilités :
+1. Un onglet legacy resté ouvert dans le navigateur — triviale.
+2. Un proxy dashboard appelle la route — à vérifier.
+
+Si c'est (1), fermer l'onglet suffit, pas besoin de stubber. Si c'est (2), stubber. Mais **avant de coder, regarder qui appelle**. Budget : **10 min d'enquête + 10 min de fix éventuel**.
+
+**C1 — Finaliser flux Import Léa → review → replay (1 j)**
+Sous-estimé. Le plan liste 4 actions, dont "Bouton 'Valider et exécuter' qui passe `review_status='approved'` puis lance le replay via `/execute`". Mais :
+- Le `/execute` VWB utilise l'IRBuilder local, pas le replay server Agent V1 (port 5005). Divergence d'exécution.
+- Le flux "replay" réussi du 13 avril passe par Agent V1, pas par VWB. Le bouton "Valider et exécuter" dans VWB va donc **exécuter avec un autre moteur** que celui qui a produit le workflow.
+- Question non résolue : si Dom valide un workflow importé et que l'exécution VWB échoue, alors qu'Agent V1 l'avait réussi, c'est quoi la vérité ?
+
+Budget réaliste : **2 j**, avec obligation de clarifier "qui exécute quoi" avant de coder le bouton.
+
+**C5 — Lier step ↔ screenshot source (2 j)**
+C'est la vraie valeur. Le plan dit que les workflows Léa "contiennent déjà des `screenshot_hash` dans leurs nodes (à vérifier dans notepad_enriched.json)". Le "à vérifier" est critique. Si ce n'est pas le cas, il faut **d'abord modifier le format d'export Léa** avant de toucher VWB, ce qui triple la durée. **Prérequis à lever avant de s'engager sur cet item.**
+
+### 2.3. Ce qu'on retire du plan
+
+**C4 — Consolider les 3 app*.py (1 j)**
+Pas avant le POC. Zero impact utilisateur, risque de régression sur le seul endpoint VLM de `app_lightweight.py`. On garde en backlog "quand bande passante". Le plan le met en semaine 3+, correct, mais le listing en quick win serait une tentation.
+
+**C2 — Persister bibliothèque serveur (1.5 j)**
+Si B1 fait vraiment son job avec localStorage + compression thumbnails, le serveur n'est pas nécessaire pour le POC. **Ne démarrer C2 que si B1 échoue en usage réel.** Le plan le dit ("si B1 montre ses limites"), mais ne le chiffre pas comme optionnel dans la roadmap — le sortir explicitement.
+
+### 2.4. Ce qu'on ajoute
+
+**Backup quotidien de `workflows.db`**
+Le plan le liste dans "Risques" mais ne le met pas comme action. C'est la seule BDD qui contient le travail manuel de Dom. **1 ligne dans `backup_ssd.sh`** (ou cron local). Critique avant POC. **15 min.**
+
+**Versionnement simple des workflows**
+Aucun des 2 plans n'en parle. Scénario : Dom modifie un workflow importé, casse quelque chose, veut revenir en arrière. SQLAlchemy n'a pas de versioning natif. Proposition minimale : à chaque `PUT /api/v3/workflow/<id>`, dumper le JSON avant modification dans `data/vwb/workflow_history/<id>/<timestamp>.json`. **30 min**, zero dépendance, ROI fort.
+
+**Nom clair du projet dans la liste VWB**
+Si Dom importe 28 workflows du poste DESKTOP-58D5CAC, il va se noyer. Ajouter un filtre par machine + status (pending_review / approved / rejected) dans `WorkflowList.tsx`. **45 min**, grande valeur UX.
+
+---
+
+## Section 3 — Vision système transverse
+
+### 3.1. Dépendances oubliées entre les deux plans
+
+**Audit trail parle à VWB ?**
+Le plan Dashboard mentionne `workflow_id` et `workflow_name` dans les colonnes Audit. Or :
+- Côté Agent V1, le `workflow_id` est celui du JSON disque.
+- Côté VWB, les workflows ont un `id` SQLAlchemy distinct.
+- Quand un workflow est importé dans VWB (source='learned_import'), le mapping entre les deux IDs n'est pas explicite.
+
+Conséquence : un DSI qui filtre "workflow = X" dans l'Audit risque de ne pas retrouver le workflow correspondant dans VWB. **À clarifier** avant le sprint Audit MVP.
+
+**Correction packs : 2 plans, 2 décisions contradictoires**
+- Plan Dashboard : "supprimer onglet Corrections, les packs sont gérés dans VWB."
+- Plan VWB section E3 : "Ne PAS porter CorrectionPacksDashboard sur le v4 — fermer proprement correction_packs."
+
+Les deux disent "on ne fait plus de correction packs ici", mais personne ne dit **où ils vivent maintenant**. Si la réponse est "plus nulle part", il faut archiver proprement les données historiques (packs déjà produits) et le déclarer explicitement.
+
+**Frontend legacy partagé ?**
+Le 404 `/api/correction-packs/stats` vient du frontend legacy VWB. Mais il ne serait pas impossible qu'un iframe du dashboard (onglet Corrections) l'ait aussi chargé. Si on retire l'onglet Dashboard **avant** de retirer le frontend legacy VWB, on ne supprime qu'une moitié du problème.
+
+### 3.2. Ordre d'attaque recommandé
+
+**VWB quick wins AVANT Dashboard cleanup.** Raisons :
+1. Dom utilise VWB quotidiennement, le bug captures le bloque tout de suite.
+2. VWB a des erreurs factuelles à résoudre en amont (diagnostic B1, source des 404).
+3. Un Dashboard cleanup, ça se fait en 1 push, le VWB nécessite diagnostic → étaler.
+
+### 3.3. Points d'intégration critiques
+
+- **Token RPA_API_TOKEN** — doit être propagé Dashboard → streaming 5005 (audit) et VWB → streaming 5005 (replay). Fragile si Dom modifie `.env`. **Ajouter un check au démarrage.**
+- **Base `workflows.db`** — partagée entre backend VWB et (potentiellement) Agent V1. Vérifier qu'aucune écriture concurrente n'existe (locks SQLite).
+- **Volumes `data/audit/` et `data/training/sessions/`** — doivent être dans le backup quotidien. À vérifier dans `backup_ssd.sh`.
+
+---
+
+## Section 4 — Ce qui n'est pas dans les plans mais devrait y être
+
+Par ordre de priorité pour le POC Anouste :
+
+1. **Backup quotidien de `workflows.db` et `data/audit/`**
+   Aujourd'hui un seul backup du 23/01 dans `backend/instance/backups/`. Si un disque meurt, Dom perd ses 3 workflows de démo + 10 jours d'audit. **Bloquant POC.** 15 min.
+
+2. **Versionnement basique des workflows VWB**
+   Snapshot à chaque PUT. 30 min. Zero dépendance. Fort ROI dès le 2e client.
+
+3. **Mode dégradé "streaming server indisponible"**
+   Aujourd'hui si port 5005 tombe, VWB et Dashboard affichent des erreurs cryptiques. Ajouter un badge "Streaming KO — Léa en pause" partout. 1 h.
+
+4. **Isolation multi-client**
+   Le jour où Anouste + un second client tournent sur la même instance, il n'y a aucune séparation (BDD, audit, sessions). Avant le POC DGX, décider : 1 instance par client ou tag `client_id` partout ? À trancher avec Dom **avant** de coder l'onglet Audit (sinon on refait le schéma).
+
+5. **Observabilité unifiée**
+   Prometheus existe côté dashboard (`/metrics`), mais pas côté VWB ni streaming server. Pour un hôpital, "pourquoi c'est lent aujourd'hui" = question fréquente. Ajouter 3 métriques clés (replay_duration_ms, vlm_call_ms, faiss_search_ms) exposées en Prometheus sur les 3 services. 2 h.
+
+6. **Documentation d'installation POC**
+   Ni DEV_SETUP.md ni README n'expliquent comment déployer l'ensemble chez un client. `run.sh --full` suppose l'environnement Dom. Pour Anouste il faut une procédure, sinon c'est Dom qui installe à la main. 2 h.
+
+7. **Anonymisation des logs pour export**
+   Si un DSI exporte le CSV Audit, il récupère `user_name = "Marie Dupont"`. Fine pour un audit interne, problématique pour une démo publique. Prévoir un flag `--anonymize` sur l'export. 30 min.
+
+8. **Concurrence dashboard**
+   Aucune protection : 2 onglets ouverts = 2 actions possibles en parallèle. Pour le POC mono-utilisateur ça passe, à tracer pour multi-TIM.
+
+---
+
+## Section 5 — Roadmap recommandée révisée (4 jours)
+
+**Contexte** : POC Anouste dans ~2 semaines. DGX pas encore arrivé. Fenêtre technique ouverte mais finie.
+
+### Jour 1 (4 h) — Sécuriser le quotidien de Dom
+
+- VWB B3 (vwb_v3.db fantôme) : 15 min
+- VWB B4 (double logging) : 15 min
+- VWB B6 (fichiers parasites) : 10 min
+- VWB B7 (run.sh) : 20 min
+- **NOUVEAU** — backup quotidien `workflows.db` + `data/audit/` : 15 min
+- VWB B2 (Unnamed Workflow) : 20 min
+- **Diagnostic B1** (bibliothèque captures, pas de code) : 30 min
+- VWB B1 (localStorage + thumbnails JPEG) : 1 h
+- Reste : commit + test manuel + pause café.
+
+**Sortie** : Dom ne perd plus ses captures, ses workflows sont sauvegardés, les logs sont lisibles.
+
+### Jour 2 (4-6 h) — Dashboard cleanup + audit MVP backend
+
+- Dashboard B1→B6 (retirer 5 onglets + pages mortes) : 2 h
+- **NOUVEAU** — vérifier proxy `workflow_id` VWB ↔ Audit : 30 min
+- Dashboard — onglet Audit MVP (proxy + tableau + filtres + export CSV) : 3 h
+- **NON** : pas de PDF, pas de patient_ref_hash, pas d'alerting, pas de graphiques.
+
+**Sortie** : dashboard à 9 onglets propres, onglet Audit fonctionnel pour démo POC.
+
+### Jour 3 (4-6 h) — Flux Léa → VWB → replay (C1)
+
+- Diagnostic source des 404 correction-packs/stats : 15 min, fix si nécessaire
+- **NOUVEAU** — versionnage workflows VWB (snapshot avant PUT) : 30 min
+- **NOUVEAU** — filtre machine + status dans WorkflowList : 45 min
+- C1 étape 1 : vérifier `pendingReviewCount` + banner : 1 h
+- C1 étape 2 : warnings visuels sur steps importés : 1 h
+- C1 étape 3 : bouton "Valider et exécuter" **avec clarification** qui exécute (Agent V1 ou VWB) : 2 h
+
+**Sortie** : Dom peut importer un workflow Léa, voir les étapes floues, corriger, relancer.
+
+### Jour 4 (4 h) — Hardening POC Anouste
+
+- **NOUVEAU** — mode dégradé streaming KO (3 services) : 1 h
+- **NOUVEAU** — 3 métriques Prometheus sur VWB + streaming : 2 h
+- **NOUVEAU** — doc installation POC (README_DEPLOY_POC.md) : 1 h
+
+**Sortie** : POC déployable chez Anouste, observable, résilient aux pannes.
+
+### Ce qu'on garde en backlog (pas avant POC)
+
+- VWB C3 (retirer frontend legacy), C4 (consolider app*.py), C5 (screenshot source par step), C2 (captures serveur)
+- Dashboard Sprint 3 complet (PDF DSI, patient_ref_hash, signature intégrité, widgets, alerting)
+- Dashboard Sprint 4 (améliorations Services, Sessions, Logs, Config)
+
+---
+
+## Section 6 — Risques à surveiller pendant l'exécution
+
+| # | Risque | Probabilité | Impact | Mitigation |
+|---|---|---|---|---|
+| R1 | B1 localStorage ne résout pas le vrai bug (cause racine différente) | Moyenne | Moyen | Diagnostic avant code. 15 min budgétées. |
+| R2 | Suppression d'un onglet Dashboard casse un script externe qui appelait la route | Faible | Moyen | Grep workspace complet avant suppression. `n8n`, `agent_chat`, `core` peuvent consommer. |
+| R3 | Proxy dashboard→streaming 5005 échoue sur token RPA_API_TOKEN | Moyenne | Moyen | Reproduire le pattern `/api/streaming/*` à la lettre. Tester avec `curl` direct avant UI. |
+| R4 | Workflow importé non rejouable (format Léa incompatible bridge) | Moyenne | Fort | Tester C1 sur le workflow `notepad_enriched.json` en premier. Si KO, pivoter sur C5 avant C1. |
+| R5 | `workflow_id` Audit ≠ `id` VWB → filtre DSI casse | Forte | Faible (hors POC) | Documenter dans l'export CSV : "workflow_id = source disque, voir VWB pour UI". Fix propre post-POC. |
+| R6 | Backup `workflows.db` oublié, crash disque avant POC | Faible | Critique | Backup manuel aujourd'hui, automatisation demain. |
+| R7 | Cleanup Dashboard supprime une route consommée par Agent V1 | Faible | Fort | Routes retirées : `/api/automation/*`, `/api/tests/*`, `/api/gestures`, `/api/chat/*`. Grep avant. |
+| R8 | Onglet Audit "demi-fonctionnel" montré à Anouste produit plus de méfiance que rien | Moyenne | Fort | MVP uniquement (tableau + filtres + CSV). Pas de widgets creux. |
+| R9 | Régression frontend v4 après suppression legacy (C3 reporté, donc risque faible immédiat) | Faible | Moyen | C3 **pas en roadmap 4 jours**. Post-POC. |
+| R10 | Exécution VWB diverge de replay Agent V1 → incohérence démo | Forte | Fort | Clarifier quel moteur exécute en bouton "Valider et exécuter". Préférer Agent V1 via appel 5005. |
+| R11 | AI Act / RGPD — absence de patient_ref_hash repérée par DSI Anouste | Faible (POC early) | Moyen | Documenter la limitation dans DOSSIER_COMMISSAIRE_AUX_APPORTS. Planifier Sprint 3 post-POC. |
+| R12 | 2 personnes éditent workflows.db simultanément (Dom + un TIM pendant démo) | Faible (POC mono) | Fort | SQLite verrou exclusif = erreur propre. Documenter "VWB mono-utilisateur pour l'instant". |
+
+---
+
+## Résumé exécutif pour Dom
+
+1. **Commence par VWB B3+B4+B6+B7+backup (1 h 30)** — hygiène, zéro risque, gains immédiats.
+2. **Puis diagnostic B1 AVANT de coder** — 15 min pour éviter de coder une fausse solution.
+3. **Dashboard cleanup + Audit MVP (1 journée)** — retire les onglets morts, ajoute l'onglet Audit minimal. Pas de PDF ni d'alerting avant retour client.
+4. **Flux C1 (1 journée)** — la vraie valeur visible de ton idée "importer Léa, corriger".
+5. **Hardening POC (demi-journée)** — backups, métriques, doc deploy. Sinon le POC Anouste sera douloureux.
+6. **Tout le reste (C2, C3, C4, C5, Dashboard Sprint 3-4) : après POC.**
+
+Les deux plans sont solides. Ils manquent juste de **connexions entre eux** et sous-estiment **le hardening POC**. Ce document les relie et priorise pour la fenêtre de 2 semaines avant Anouste.
+
+---
+
+_Fin du challenge — 16 avril 2026._
--- a/docs/DOSSIER_COMMISSAIRE_AUX_APPORTS.md
+++ b/docs/DOSSIER_COMMISSAIRE_AUX_APPORTS.md
@@ -0,0 +1,658 @@
+# Dossier de Présentation Technique — Apport en Nature
+
+## Logiciel RPA Vision V3
+
+**Document destiné au Commissaire aux Apports**
+
+---
+
+| | |
+|---|---|
+| **Projet** | RPA Vision V3 — Plateforme d'automatisation intelligente par vision |
+| **Auteur principal** | Dom — Architecte / Expert principal |
+| **Profil** | 32 ans d'expérience en informatique de pointe (sécurité, IA, infrastructure, robotique, direction de projet, industrialisation) |
+| **Historique du projet** | Premier jet il y a ~5 ans (V1). Version actuelle (V3) développée sur ~12 mois (préparation + développement actif) |
+| **Date du présent document** | 25 février 2026 |
+| **Nature de l'apport** | Logiciel, code source, propriété intellectuelle associée |
+
+---
+
+## Table des matières
+
+1. [Résumé exécutif](#1-résumé-exécutif)
+2. [Description fonctionnelle](#2-description-fonctionnelle)
+3. [Architecture technique](#3-architecture-technique)
+4. [Stack technologique](#4-stack-technologique)
+5. [Métriques de développement](#5-métriques-de-développement)
+6. [Fonctionnalités clés et innovations](#6-fonctionnalités-clés-et-innovations)
+7. [État d'avancement](#7-état-davancement)
+8. [Positionnement concurrentiel](#8-positionnement-concurrentiel)
+9. [Marché adressable](#9-marché-adressable)
+10. [Inventaire des dépendances open-source et licences](#10-inventaire-des-dépendances-open-source-et-licences)
+11. [Éléments de valorisation](#11-éléments-de-valorisation)
+
+---
+
+## 1. Résumé exécutif
+
+**RPA Vision V3** est une plateforme d'automatisation robotisée des processus (RPA) de nouvelle génération. Contrairement aux solutions existantes (UiPath, Automation Anywhere, Blue Prism) qui reposent sur des sélecteurs HTML/UI fragiles, RPA Vision V3 utilise la **vision par ordinateur et l'intelligence artificielle multimodale** pour comprendre sémantiquement les interfaces utilisateur.
+
+Cette approche résout un problème fondamental du marché RPA : **40 % des robots échouent** lorsque les interfaces changent, et **30 % du marché entreprise** (environnements Citrix/VDI, mainframes, systèmes air-gapped) reste inaccessible aux solutions conventionnelles.
+
+Le logiciel est le fruit d'un travail intensif de conception, développement et intégration mené par l'auteur principal, combinant expertise en intelligence artificielle, vision par ordinateur et ingénierie logicielle.
+
+---
+
+## 2. Description fonctionnelle
+
+### Problème résolu
+
+Les solutions RPA traditionnelles présentent trois faiblesses majeures :
+
+- **Fragilité** — Les sélecteurs CSS/XPath cassent dès qu'une interface est mise à jour, entraînant 60 à 70 % des budgets RPA en maintenance
+- **Inaccessibilité** — Les environnements Citrix/VDI, mainframes legacy et systèmes air-gapped (défense, santé) restent hors de portée
+- **Rigidité** — Aucune capacité d'adaptation autonome aux changements d'interface
+
+### Solution apportée
+
+RPA Vision V3 automatise les processus métier en :
+
+- **Voyant l'écran** comme un humain (aucun sélecteur, aucune coordonnée fixe)
+- **Comprenant sémantiquement** les éléments d'interface (bouton, champ de texte, menu, etc.)
+- **S'auto-réparant** lorsqu'une interface change (4 stratégies de récupération)
+- **Apprenant continuellement** des exécutions passées pour améliorer sa fiabilité
+- **Fonctionnant en local** (aucune donnée envoyée dans le cloud — conformité RGPD/défense)
+
+### Composants fonctionnels
+
+| Composant | Rôle |
+|-----------|------|
+| **Visual Workflow Builder (VWB)** | Interface web de conception visuelle de workflows (drag & drop) |
+| **Moteur d'exécution** | Exécute les workflows avec gestion d'erreurs et auto-réparation |
+| **Agent de capture** | Capture cross-plateforme des événements et screenshots |
+| **Moteur de détection UI** | Détection hybride des éléments d'interface (IA + vision classique) |
+| **Système d'embeddings** | Empreintes multimodales des états d'écran (FAISS, CLIP) |
+| **Système d'apprentissage** | Apprentissage progressif et détection de dérive |
+| **Dashboard de monitoring** | Tableau de bord temps réel des exécutions et analytics |
+| **Catalogue d'actions** | 24+ actions prêtes à l'emploi (clic, saisie, navigation, OCR, IA, etc.) |
+
+---
+
+## 3. Architecture technique
+
+### Architecture en 5 couches
+
+```
+Couche 0 : RawSession          — Capture brute (événements + screenshots)
+    ↓
+Couche 1 : ScreenState         — Analyse multi-modale (4 niveaux d'abstraction)
+    ↓
+Couche 2 : UIElement Detection  — Détection sémantique des éléments UI
+    ↓
+Couche 3 : State Embedding      — Fusion multimodale (empreinte digitale d'écran)
+    ↓
+Couche 4 : Workflow Graph       — Graphe de nœuds + apprentissage
+```
+
+### Structure du projet
+
+```
+rpa_vision_v3/
+├── core/                           # Moteur IA (192 fichiers Python)
+│   ├── analytics/                  # Collecte et reporting d'analytics
+│   ├── capture/                    # Capture d'écran et d'événements
+│   ├── detection/                  # Détection UI hybride (OWL-v2 + OpenCV + VLM)
+│   ├── embedding/                  # Embeddings CLIP, FAISS, fusion multimodale
+│   ├── execution/                  # Exécution des actions et robustesse
+│   ├── healing/                    # Auto-réparation (4 stratégies)
+│   ├── learning/                   # Apprentissage continu
+│   ├── matching/                   # Matching hiérarchique
+│   ├── monitoring/                 # Métriques et ordonnancement
+│   ├── security/                   # Audit, tokens, validation
+│   ├── system/                     # Circuit breaker, auto-heal manager
+│   └── training/                   # Entraînement offline
+│
+├── visual_workflow_builder/        # Application web full-stack
+│   ├── frontend_v4/               # React 18 + TypeScript + Vite
+│   └── backend/                   # Flask + SocketIO + SQLAlchemy
+│       ├── actions/               # Catalogue de 24+ actions
+│       ├── api/                   # Endpoints REST et WebSocket
+│       ├── contracts/             # Contrats d'interface
+│       └── services/              # Services métier (OCR, détection, etc.)
+│
+├── agent_v0/                      # Agent de capture cross-plateforme
+├── server/                        # API de traitement (FastAPI)
+├── web_dashboard/                 # Dashboard de monitoring
+├── gui/                           # Interface desktop (PyQt5)
+├── models/                        # Modèles IA pré-entraînés
+└── tests/                         # Suite de tests
+```
+
+---
+
+## 4. Stack technologique
+
+### Intelligence artificielle et Machine Learning
+
+| Technologie | Rôle | Licence |
+|-------------|------|---------|
+| PyTorch 2.x | Framework de deep learning | BSD-3-Clause |
+| OpenCLIP (ViT-B-32) | Embeddings vision-langage (512 dimensions) | MIT |
+| FAISS | Recherche vectorielle (1M+ embeddings, <100ms) | MIT / BSD-3-Clause |
+| Qwen3-VL 8B (via Ollama) | Modèle de vision-langage local | Apache-2.0 |
+| OWL-v2 | Détection d'objets zero-shot | Apache-2.0 |
+| HuggingFace Transformers | Pipeline de modèles IA | Apache-2.0 |
+| docTR (Mindee) | OCR (reconnaissance de caractères) | Apache-2.0 |
+
+### Vision par ordinateur
+
+| Technologie | Rôle | Licence |
+|-------------|------|---------|
+| OpenCV 4.x | Traitement d'image | Apache-2.0 |
+| Pillow | Manipulation d'images | MIT-CMU |
+| MSS | Capture d'écran rapide | MIT |
+
+### Backend
+
+| Technologie | Rôle | Licence |
+|-------------|------|---------|
+| Python 3.12 | Langage principal | PSF |
+| Flask 3.0 | Framework web (VWB) | BSD |
+| FastAPI | API de traitement (serveur) | MIT |
+| Flask-SocketIO | Communication temps réel | MIT |
+| SQLAlchemy 2.0 | ORM base de données | MIT |
+| Redis | Cache et files d'attente | MIT |
+| Pydantic | Validation de données | MIT |
+
+### Frontend
+
+| Technologie | Rôle | Licence |
+|-------------|------|---------|
+| React 18 | Framework UI | MIT |
+| TypeScript 5.x | Typage statique | Apache-2.0 |
+| Vite 5 | Build tool | MIT |
+| @xyflow/react 12 | Graphes visuels de workflows | MIT |
+
+### Sécurité et infrastructure
+
+| Technologie | Rôle | Licence |
+|-------------|------|---------|
+| AES-256-GCM | Chiffrement des sessions | (standard cryptographique) |
+| Authentification par tokens | Contrôle d'accès | Développement interne |
+| Audit JSONL | Journalisation sécurisée | Développement interne |
+
+---
+
+## 5. Métriques de développement
+
+### Volume de code source (hors dépendances, hors tests)
+
+| Composant | Fichiers | Lignes de code | Langage |
+|-----------|----------|----------------|---------|
+| Core (moteur IA) | 192 | ~63 800 | Python |
+| VWB Backend | 115 | ~42 100 | Python |
+| VWB Frontend | 24 | ~6 260 | TypeScript/React |
+| Server API | 8 | ~2 900 | Python |
+| Agent V0 | 25 | ~7 700 | Python |
+| Tests | 177 | ~66 900 | Python |
+| **Total** | **~541** | **~189 660** | |
+
+### Historique de développement
+
+Le logiciel RPA Vision V3 est le résultat de **trois itérations majeures** sur une période de 5 ans :
+
+| Version | Période | Rôle |
+|---------|---------|------|
+| **V1** (premier jet) | ~2021 | Preuve de concept — exploration de l'approche vision pour le RPA |
+| **V2** (évolution) | 2022-2024 | Prototypage avancé — validation des choix architecturaux |
+| **V3** (version actuelle) | mars 2025 — février 2026 | Développement complet — architecture 5 couches, production-ready |
+
+**Dépôt git V3** (code source livré) :
+
+| Métrique | Valeur |
+|----------|--------|
+| Nombre de commits | 52 |
+| Premier commit V3 | 7 janvier 2026 |
+| Dernier commit | 18 février 2026 |
+| Contributeur principal | Dom |
+| Insertions totales (git) | ~479 000 lignes |
+
+> **Note** : Le dépôt git ne reflète que la phase finale de codage de la V3. Le travail de conception, de R&D et les itérations V1/V2 qui ont fondé l'architecture ne figurent pas dans l'historique de commits mais constituent une part essentielle de la valeur intellectuelle du projet.
+
+### Effort réel de développement
+
+| Phase | Durée | Intensité | Heures estimées |
+|-------|-------|-----------|-----------------|
+| R&D initiale / V1 et V2 (~5 ans) | ~3 ans cumulés | Variable | Non quantifié — valeur de savoir-faire accumulé |
+| Travail préparatoire V3 (conception, veille, architecture) | ~4 mois | ~6 h/jour | ~530 h |
+| Développement actif V3 | ~8 mois | ~10-12 h/jour | ~1 760 à 2 100 h |
+| **Total effort V3** | **~12 mois** | | **~2 300 à 2 600 h** |
+
+### Profil de l'auteur
+
+- **58 ans**, 32 ans d'expérience en informatique de pointe
+- Spécialisations : sécurité, intelligence artificielle (tous niveaux), infrastructure, robotique
+- Capacité démontrée à créer des systèmes from scratch, du POC au MVP puis à l'industrialisation
+- Direction d'entreprise, direction de projet, développement
+- Créateur d'un framework de gestion de projets faisant appel aux nouvelles technologies
+- Profil équivalent marché : **Architecte / Expert principal IA** — TJM de référence : 1 200 €/jour
+
+---
+
+## 6. Fonctionnalités clés et innovations
+
+### 6.1 Fusion multimodale d'états d'écran
+
+Chaque état d'écran est résumé en une empreinte vectorielle combinant 4 modalités :
+- 50 % Image (screenshot complet via CLIP)
+- 30 % Texte (texte détecté)
+- 10 % Titre (fenêtre active)
+- 10 % UI (éléments détectés)
+
+**Performance** : 0,02 ms par embedding (contrainte : <100 ms) — **500x** plus rapide que le standard.
+
+### 6.2 Auto-réparation en 4 stratégies
+
+Lorsqu'un élément d'interface n'est plus trouvé, le système applique en cascade :
+
+1. **Variantes sémantiques** — Essai de variations visuelles/textuelles
+2. **Fallback spatial** — Recherche dans le voisinage
+3. **Adaptation temporelle** — Ajustement des temps d'attente
+4. **Transformation de format** — Transformation des données d'entrée
+
+Taux de récupération : >95 % des erreurs transitoires, en <30 secondes.
+
+### 6.3 Apprentissage progressif
+
+```
+OBSERVATION (5+ exécutions)
+    ↓
+COACHING (10+ assistances, >90 % de succès)
+    ↓
+AUTO_CANDIDATE (20+ exécutions, >95 % de succès)
+    ↓
+AUTO_CONFIRMED (validation utilisateur)
+```
+
+Le système détecte automatiquement les dérives d'interface et crée des variantes.
+
+### 6.4 Détection UI hybride
+
+Combine trois approches complémentaires :
+- **OWL-v2** : Détection zero-shot (aucun entraînement nécessaire)
+- **OpenCV** : Techniques de vision classique
+- **VLM (Qwen3-VL)** : Compréhension sémantique via modèle de vision-langage
+
+Détecte 10+ types d'éléments UI avec rôles sémantiques (primary_action, form_input, etc.).
+
+### 6.5 Circuit breaker et résilience
+
+Système de disjoncteur à 5 états (RUNNING, DEGRADED, QUARANTINED, PAUSED, ROLLBACK) inspiré des patterns de production enterprise, avec journalisation d'audit complète.
+
+### 6.6 Exécution 100 % locale
+
+Aucune dépendance cloud. Tous les modèles IA tournent en local (GPU), garantissant la conformité RGPD et l'utilisation en environnements classifiés/air-gapped.
+
+---
+
+## 7. État d'avancement
+
+### Phases complétées (10/13 — 77 %)
+
+| Phase | Description | Statut |
+|-------|-------------|--------|
+| 1-2 | Fondations + Embeddings FAISS | Terminé |
+| 4-6 | Détection UI + Graphes Workflow + Exécution | Terminé |
+| 7-8 | Système d'apprentissage + Entraînement | Terminé |
+| 10-12 | Gestion GPU + Performance + Monitoring | Terminé |
+
+### Phases restantes (3/13 — 23 %)
+
+| Phase | Description | Statut |
+|-------|-------------|--------|
+| 3 | Checkpoint final (tests de stockage) | En cours |
+| 9 | Visual Workflow Builder (90 % → 100 %) | En cours |
+| 13 | Tests end-to-end + Documentation finale | À faire |
+
+### Composants prêts pour la production
+
+- Agent de capture cross-plateforme avec chiffrement AES-256
+- Pipeline de traitement serveur + dashboard web
+- Système d'analytics et monitoring temps réel
+- Auto-réparation et adaptation automatique
+
+---
+
+## 8. Positionnement concurrentiel
+
+### Comparaison avec les solutions existantes
+
+| Critère | UiPath / AA / BluePrism | RPA Vision V3 |
+|---------|------------------------|---------------|
+| Méthode de détection | Sélecteurs CSS/XPath | Vision par IA |
+| Robustesse aux changements UI | Faible (cassure fréquente) | Forte (auto-réparation) |
+| Environnements Citrix/VDI | Support limité/payant | Natif |
+| Mainframes / Legacy | Non supporté | Supporté |
+| Systèmes air-gapped | Non | Oui (100 % local) |
+| Apprentissage autonome | Non | Oui (4 niveaux) |
+| Coût de maintenance | 60-70 % du budget | Réduit par auto-réparation |
+| Cloud requis | Souvent | Jamais |
+
+### Avance technologique estimée
+
+- **2 à 3 ans** d'avance sur l'approche vision-native par rapport aux acteurs traditionnels
+- Architecture conçue dès le départ pour la vision (pas un ajout a posteriori)
+- Score de moat technique : **85/100** (analyse détaillée disponible)
+
+---
+
+## 9. Marché adressable
+
+### Segments cibles (sous-servis par les solutions existantes)
+
+| Segment | Taille estimée | Problème |
+|---------|---------------|----------|
+| Citrix / VDI | 3,9 Mds $ | Interfaces sans DOM accessible |
+| Legacy / Mainframe | 2,6 Mds $ | Aucun sélecteur disponible |
+| Défense / Air-gapped | 1,3 Mds $ | Exigence 100 % local, pas de cloud |
+| Santé (RGPD) | 1,8 Mds $ | Données sensibles, conformité stricte |
+| **Total adressable** | **~9,6 Mds $** | |
+
+### Marché RPA global
+
+- **2024** : 13 milliards $ — **2030** : 30 milliards $ (CAGR 15 %)
+- La transition vers l'IA/vision est un mouvement de fond du secteur
+
+---
+
+## 10. Inventaire des dépendances open-source et licences
+
+Le logiciel RPA Vision V3 est un **développement propriétaire original** qui s'appuie sur des bibliothèques open-source. La propriété intellectuelle réside dans :
+- L'architecture 5 couches et sa conception
+- Les algorithmes de fusion multimodale
+- Le système d'auto-réparation en 4 stratégies
+- Le système d'apprentissage progressif
+- Le catalogue d'actions et l'intégration complète
+- Le Visual Workflow Builder
+
+### 10.1 Dépendances Python directes (requirements.txt)
+
+| Package | Version | Licence | Usage |
+|---------|---------|---------|-------|
+| numpy | 2.2.x | BSD | Calcul numérique |
+| torch | 2.9+ | BSD-3-Clause | Deep learning |
+| torchvision | 0.24+ | BSD | Utilitaires vision |
+| transformers | 4.57+ | Apache-2.0 | Modèles HuggingFace |
+| open_clip_torch | 3.2.x | MIT | Embeddings CLIP |
+| faiss-cpu | 1.13.x | MIT / BSD-3-Clause | Recherche vectorielle |
+| Pillow | 12.x | MIT-CMU | Manipulation d'images |
+| PyQt5 | 5.15.x | **GPL v3** | Interface desktop (GUI) |
+| requests | 2.32.x | Apache-2.0 | Requêtes HTTP |
+| scikit-learn | 1.7.x | BSD-3-Clause | Machine learning classique |
+| opencv-python | 4.12.x | Apache-2.0 | Vision par ordinateur |
+| mss | 10.1.x | MIT | Capture d'écran |
+| python-doctr | 1.0.x | Apache-2.0 | OCR (reconnaissance de texte) |
+| pytest | 9.x | MIT | Tests unitaires |
+| hypothesis | 6.x | MPL-2.0 | Tests property-based |
+
+### 10.2 Dépendances VWB Backend
+
+| Package | Version | Licence | Usage |
+|---------|---------|---------|-------|
+| Flask | 3.0.x | BSD | Framework web |
+| Flask-SocketIO | 5.3.x | MIT | WebSocket temps réel |
+| Flask-CORS | 4.0.x | MIT | Cross-origin |
+| SQLAlchemy | 2.0.x | MIT | ORM base de données |
+| Flask-SQLAlchemy | 3.1.x | BSD-3-Clause | Intégration Flask/SQLAlchemy |
+| marshmallow | 3.20.x | MIT | Sérialisation |
+| redis | 5.0.x | MIT | Cache |
+| pydantic | 2.5.x | MIT | Validation de données |
+| jsonschema | 4.20.x | MIT | Validation JSON |
+| python-dotenv | 1.0.x | BSD-3-Clause | Variables d'environnement |
+| black | 23.x | MIT | Formatage de code |
+| flake8 | 6.x | MIT | Linting |
+| mypy | 1.7.x | MIT | Vérification de types |
+
+### 10.3 Dépendances Server (FastAPI)
+
+| Package | Version | Licence | Usage |
+|---------|---------|---------|-------|
+| fastapi | 0.115+ | MIT | API REST |
+| uvicorn | 0.30+ | BSD-3-Clause | Serveur ASGI |
+| python-multipart | 0.0.6+ | Apache-2.0 | Upload de fichiers |
+| cryptography | 41+ | Apache-2.0 / BSD-3-Clause | Chiffrement AES-256 |
+
+### 10.4 Dépendances JavaScript/Frontend (package.json)
+
+| Package | Version | Licence | Usage |
+|---------|---------|---------|-------|
+| react | 18.3.x | MIT | Framework UI |
+| react-dom | 18.3.x | MIT | Rendu DOM |
+| @xyflow/react | 12.10.x | MIT | Éditeur visuel de graphes |
+| typescript | 5.x | Apache-2.0 | Typage statique |
+| vite | 5.x | MIT | Build tool |
+| @vitejs/plugin-react | 4.x | MIT | Plugin React pour Vite |
+| @mui/material | 7.x | MIT | Composants UI Material Design |
+| @reduxjs/toolkit | 2.x | MIT | Gestion d'état |
+| axios | 1.x | MIT | Client HTTP |
+| socket.io-client | 4.x | MIT | WebSocket client |
+
+### 10.5 Dépendances transitives notables
+
+| Package | Licence | Catégorie |
+|---------|---------|-----------|
+| huggingface-hub | Apache-2.0 | IA / téléchargement de modèles |
+| safetensors | Apache-2.0 | Sérialisation de modèles |
+| tokenizers | Apache-2.0 | Tokenisation NLP |
+| timm | Apache-2.0 | Modèles de vision |
+| scipy | BSD | Calcul scientifique |
+| networkx | BSD | Manipulation de graphes |
+| tqdm | MIT / MPL-2.0 | Barres de progression |
+| protobuf | BSD-3-Clause | Sérialisation de données |
+| PyYAML | MIT | Parsing YAML |
+| certifi | MPL-2.0 | Certificats SSL |
+
+### 10.6 Bibliothèques NVIDIA CUDA (15 packages)
+
+| Package | Licence |
+|---------|---------|
+| nvidia-cublas-cu12, nvidia-cuda-cupti-cu12, nvidia-cuda-nvrtc-cu12, nvidia-cuda-runtime-cu12, nvidia-cudnn-cu12, nvidia-cufft-cu12, nvidia-cufile-cu12, nvidia-curand-cu12, nvidia-cusolver-cu12, nvidia-cusparse-cu12, nvidia-cusparselt-cu12, nvidia-nccl-cu12, nvidia-nvjitlink-cu12, nvidia-nvshmem-cu12, nvidia-nvtx-cu12 | **NVIDIA Proprietary** (usage gratuit, redistribution encadrée) |
+
+### 10.7 Synthèse des licences
+
+| Type de licence | Nombre de packages | Compatibilité commerciale |
+|----------------|-------------------|--------------------------|
+| MIT | ~40 | Permissive — usage commercial libre |
+| Apache-2.0 | ~18 | Permissive — usage commercial libre |
+| BSD / BSD-3-Clause | ~22 | Permissive — usage commercial libre |
+| MPL-2.0 | 2 | Permissive (fichier par fichier) |
+| **GPL v3** | **1 (PyQt5)** | **Copyleft — voir note ci-dessous** |
+| LGPL v3 | 1 (PyQt5-Qt5) | Copyleft faible |
+| NVIDIA Proprietary | 15 | Gratuit, redistribution encadrée |
+
+### 10.8 Notes de conformité
+
+1. **PyQt5 (GPL v3)** — Utilisé uniquement pour l'interface desktop optionnelle (`gui/`, 3 fichiers). L'application principale (Visual Workflow Builder) utilise React et n'est pas concernée. Option : migration vers PySide6 (LGPL) ou licence commerciale Qt si distribution du composant GUI.
+
+2. **NVIDIA CUDA** — Les bibliothèques CUDA sont propriétaires mais gratuites. Leur usage est conforme aux conditions de la licence NVIDIA pour le développement et le déploiement.
+
+3. **Majorité permissive** — Plus de 80 % des dépendances utilisent des licences permissives (MIT, Apache-2.0, BSD), pleinement compatibles avec un usage commercial et une distribution propriétaire.
+
+4. **Code propriétaire** — L'intégralité du code source développé spécifiquement pour RPA Vision V3 (architecture, algorithmes, intégrations) est propriétaire et constitue l'essentiel de la valeur de l'apport.
+
+---
+
+## 11. Éléments de valorisation
+
+### 11.1 Coût de développement réel (méthode des coûts historiques)
+
+Investissement effectivement consenti par l'auteur pour la version 3 :
+
+| Poste | Calcul | Montant |
+|-------|--------|---------|
+| Travail préparatoire (conception, veille, architecture) | ~530 h × 150 €/h (TJM 1 200 € ÷ 8h) | 79 500 € |
+| Développement actif V3 | ~2 100 h × 150 €/h | 315 000 € |
+| **Sous-total main-d'œuvre V3** | **~2 630 h** | **394 500 €** |
+| Matériel — station de travail (AMD Ryzen 9, 128 Go RAM, RTX 5070) | | 3 000 € |
+| Matériel — Jetson Nano (tests embarqués) | | 400 € |
+| Coûts IA (API, modèles, inférence) | | 200 € |
+| **Total coût historique V3** | | **~398 100 €** |
+
+> **Note** : Ce calcul ne valorise pas les ~3 ans de R&D cumulés sur les versions 1 et 2, qui ont directement alimenté la conception de la V3 (choix d'architecture, sélection des modèles IA, retours d'expérience). Ce savoir-faire accumulé est inclus dans la valeur de l'apport mais non chiffré séparément.
+
+### 11.2 Coût de reproduction par un tiers (méthode recommandée)
+
+Le coût de reproduction estime l'investissement qu'une entreprise tierce devrait consentir pour développer un logiciel **fonctionnellement équivalent** en partant de zéro, sans bénéficier des 5 ans d'itérations V1/V2.
+
+#### Scénario A — Profil unique équivalent (improbable)
+
+| Poste | Calcul | Montant |
+|-------|--------|---------|
+| Architecte IA senior multi-compétences | 2 630 h × 150 €/h | 394 500 € |
+
+> Ce scénario suppose l'existence d'un profil aussi polyvalent (IA + full-stack + sécurité + infra + vision). Ce type de profil est extrêmement rare sur le marché.
+
+#### Scénario B — Équipe spécialisée (réaliste)
+
+Une entreprise devrait constituer une équipe de 3-4 personnes sur 12 à 18 mois :
+
+| Poste | Durée | TJM | Montant |
+|-------|-------|-----|---------|
+| Lead architect / Chef de projet IA | 12 mois × 22 j | 1 200 €/j | 316 800 € |
+| Ingénieur ML / Vision par ordinateur | 10 mois × 22 j | 900 €/j | 198 000 € |
+| Développeur full-stack senior (React + Python) | 10 mois × 22 j | 700 €/j | 154 000 € |
+| DevOps / Infra GPU (temps partiel) | 4 mois × 22 j | 650 €/j | 57 200 € |
+| **Sous-total main-d'œuvre** | | | **726 000 €** |
+| Matériel et infrastructure (GPU, serveurs de dev) | | | 5 000 € |
+| Coûts IA (API, modèles, calcul) | | | 2 000 € |
+| Marge d'incertitude technique (+15 %) | | | 109 950 € |
+| **Total coût de reproduction** | | | **~843 000 €** |
+
+> **Justification de la marge** : Un tiers ne bénéficierait pas des retours d'expérience des V1/V2 et devrait absorber des cycles de recherche supplémentaires (choix de modèles, benchmarks, impasses techniques).
+
+#### Synthèse des valorisations
+
+| Méthode | Montant | Commentaire |
+|---------|---------|-------------|
+| Coût historique (V3 seule) | ~398 000 € | Plancher — ne valorise pas la R&D V1/V2 |
+| Reproduction par un tiers (équipe) | ~843 000 € | Estimation réaliste — inclut marge d'incertitude |
+| **Fourchette de valorisation recommandée** | **400 000 € — 850 000 €** | Selon la méthode retenue par le commissaire |
+
+### 11.3 Actifs incorporels composant l'apport
+
+| Actif | Description | Quantification |
+|-------|-------------|---------------|
+| **Code source propriétaire** | Moteur IA, VWB, Agent, Server, Dashboard | ~190 000 lignes (Python, TypeScript) |
+| **Architecture logicielle** | Conception originale 5 couches, documentation | 14 modules architecturaux |
+| **Algorithmes propriétaires** | Fusion multimodale, auto-réparation 4 stratégies, apprentissage progressif 4 niveaux | Développements originaux |
+| **Catalogue d'actions** | Actions prêtes à l'emploi pour l'automatisation | 24+ actions |
+| **Suite de tests** | Tests unitaires, intégration, property-based | ~67 000 lignes |
+| **Savoir-faire accumulé** | 5 ans d'itérations (V1 → V3), intégration de modèles IA en pipeline local | Non quantifiable — valeur intrinsèque |
+| **Documentation technique** | Architecture, API, guides, spécifications | Corpus documentaire complet |
+
+### 11.3 Comparables marché
+
+| Solution | Valorisation | CA / ARR | Source |
+|----------|-------------|----------|--------|
+| **UiPath** (NYSE: PATH) | ~8,8 Mds $ (capitalisation déc. 2025) | CA : 1,43 Md $ / ARR : 1,67 Md $ (FY2025) | [UiPath IR — FY2025 Results](https://ir.uipath.com/news/detail/381/uipath-reports-fourth-quarter-and-full-year-fiscal-2025-financial-results) |
+| **Automation Anywhere** | 6,8 Mds $ (Series D, oct. 2025) | Non divulgué (privé) | [Tracxn — AA Funding](https://tracxn.com/d/companies/automation-anywhere/__tre2zh_F5voAIrD5MmsvheJ0drmtTXyaT3m8-w_KaZ0/funding-and-investors) |
+| **SS&C Blue Prism** | 1,6 Md $ (acquisition par SS&C, 2022) | ~211 M$ (post-acquisition) | [SS&C Blue Prism Acquisition](https://info.ssctech.com/blue-prism-acquisition) |
+| **Sema4.ai** (ex-Robocorp) | 30,5 M$ levés (2024) | Early stage | [Sema4.ai — PR Newswire](https://www.prnewswire.com/news-releases/sema4-ai-raises-30-5-million-to-bring-open-source-powered-ai-to-mission-critical-enterprise-work-302047158.html) |
+
+**Contexte** : UiPath, Automation Anywhere et SS&C Blue Prism sont identifiés comme « Leaders » dans le [Gartner Magic Quadrant for RPA 2025](https://www.gartner.com/en/documents/6632834) (publié juin 2025, 7e année consécutive pour les trois). RPA Vision V3 se positionne dans le segment des solutions IA-natives pour RPA, avec une approche différenciante (vision pure, 100 % local) ciblant les segments inaccessibles aux leaders actuels.
+
+---
+
+## 12. Références et sources
+
+### 12.1 Marché RPA — Taille et prévisions
+
+| Source | Donnée | Lien |
+|--------|--------|------|
+| **Grand View Research** | Marché RPA mondial : 4,68 Mds $ (2025) → 35,84 Mds $ (2033), CAGR 29,0 % | [Grand View Research — RPA Market](https://www.grandviewresearch.com/industry-analysis/robotic-process-automation-rpa-market) |
+| **Precedence Research** | Marché RPA : 28,31 Mds $ (2025) → 247,34 Mds $ (2035), CAGR 24,2 % | [Precedence Research — RPA Market](https://www.precedenceresearch.com/robotic-process-automation-market) |
+| **Gartner** | Marché RPA : 3,79 Mds $ (2024) → 30,85 Mds $ (2030), CAGR 43,9 % | [Gartner — Market Share Analysis RPA 2024](https://www.gartner.com/en/documents/6842834) |
+| **Statista** | Prévision marché RPA mondial jusqu'en 2030 | [Statista — RPA Market Size](https://www.statista.com/statistics/1259903/robotic-process-automation-market-size-worldwide/) |
+
+> **Note** : Les écarts entre sources reflètent des périmètres de définition différents (RPA strict vs. hyperautomation). Le consensus est un CAGR de 24 à 44 % selon le périmètre.
+
+### 12.2 Produits concurrents — Données financières
+
+| Acteur | Donnée | Source |
+|--------|--------|--------|
+| **UiPath** — CA FY2025 : 1,43 Md $, croissance +9 %, ARR 1,67 Md $, 2 292 clients >100k$ ARR | [UiPath — Q4 & FY2025 Results](https://ir.uipath.com/news/detail/381/uipath-reports-fourth-quarter-and-full-year-fiscal-2025-financial-results) |
+| **UiPath** — Capitalisation boursière ~8,8 Mds $ (déc. 2025) | [MacroTrends — UiPath Market Cap](https://www.macrotrends.net/stocks/charts/PATH/uipath/market-cap) |
+| **Automation Anywhere** — Série D : 290 M$ levés, valorisation 6,8 Mds $ (oct. 2025), total levé : 840 M$ | [Tracxn — AA Funding](https://tracxn.com/d/companies/automation-anywhere/__tre2zh_F5voAIrD5MmsvheJ0drmtTXyaT3m8-w_KaZ0/funding-and-investors) |
+| **SS&C Blue Prism** — Acquis par SS&C Technologies pour 1,6 Md $ (mars 2022) | [SS&C — Blue Prism Acquisition](https://info.ssctech.com/blue-prism-acquisition) |
+| **Sema4.ai** (acquéreur de Robocorp) — 30,5 M$ levés, Robocorp acquis janv. 2024 | [PR Newswire — Sema4.ai](https://www.prnewswire.com/news-releases/sema4-ai-raises-30-5-million-to-bring-open-source-powered-ai-to-mission-critical-enterprise-work-302047158.html) |
+
+### 12.3 Analystes et classements sectoriels
+
+| Source | Donnée | Lien |
+|--------|--------|------|
+| **Gartner Magic Quadrant for RPA 2025** | Leaders : UiPath, Automation Anywhere, SS&C Blue Prism (7e année consécutive). 13 éditeurs évalués. | [Gartner — MQ RPA 2025](https://www.gartner.com/en/documents/6632834) |
+| **UiPath** — Communiqué leader MQ 2025 | Reconnu leader pour la 7e année, meilleur score « Ability to Execute » | [UiPath — MQ 2025 Press Release](https://ir.uipath.com/news/detail/400/uipath-recognized-as-a-leader-in-the-2025-gartner-magic-quadrant-for-robotic-process-automation) |
+
+### 12.4 Problématique du marché — Fragilité et échecs RPA
+
+| Source | Donnée | Lien |
+|--------|--------|------|
+| **Ernst & Young** | 30 à 50 % des projets RPA échouent initialement | [Flobotics — RPA Statistics](https://flobotics.io/blog/rpa-statistics/) |
+| **Blueprint Software** | Le coût de licence ne représente que 25-30 % du coût total RPA ; la maintenance et le support représentent 15-20 % de l'investissement initial par an | [Blueprint — RPA Cost](https://www.blueprintsys.com/blog/rpa/how-much-does-robotic-process-automation-really-cost) |
+| **Blueprint Software** | Les bots cassent régulièrement lors de changements d'interface (break-fix cycles) ; la maintenance est le premier poste de coût récurrent | [Blueprint — Reduce RPA Maintenance](https://www.blueprintsys.com/blog/rpa/reduce-rising-costs-rpa-maintenance-and-support) |
+| **Worksoft** | La fragilité des bots face aux changements UI est le principal défi technique du RPA (« bot fragility ») | [Worksoft — Solving Bot Fragility](https://www.worksoft.com/corporate-blog/solving-bot-fragility-with-change-resilient-rpa) |
+| **Deloitte** | Enquête mondiale sur l'adoption RPA : 62 % citent l'intégration comme barrière principale, 55 % le manque de compétences | [Deloitte — Global RPA Survey](https://www2.deloitte.com/us/en/pages/operations/articles/global-robotic-process-automation-report.html) |
+
+### 12.5 Problématique Citrix/VDI — Marché sous-servi
+
+| Source | Donnée | Lien |
+|--------|--------|------|
+| **PwC India** | Livre blanc : « Robotic Process Automation in a Virtual Environment » — les environnements VDI ne fournissent aucun objet DOM exploitable, l'automatisation repose uniquement sur la reconnaissance d'image | [PwC — RPA in Virtual Environment (PDF)](https://www.pwc.in/assets/pdfs/publications/2018/robotic-process-automation-in-a-virtual-environment.pdf) |
+| **Accelirate** | « Challenges of RPA in Citrix Environment » — absence totale d'Object IDs, le bot ne voit qu'une image pixel | [Accelirate — RPA & Citrix](https://www.accelirate.com/challenges-of-rpa-in-citrix-environment/) |
+| **Ultima (IA Connect)** | Solution spécialisée RPA pour Citrix/VDI — confirme le besoin non couvert par les plateformes standard | [Ultima — IA Connect for Citrix](https://ultima.com/ia-connect/) |
+| **Leapwork** | « Overcoming Common Citrix Automation Challenges » — les outils RPA classiques échouent en environnement Citrix | [Leapwork — Citrix Challenges](https://www.leapwork.com/blog/overcoming-common-citrix-automation-challenges-with-the-right-tool) |
+
+### 12.6 Technologies IA utilisées — Publications et documentation
+
+| Technologie | Référence |
+|-------------|-----------|
+| **CLIP** (OpenAI, 2021) | Radford et al., « Learning Transferable Visual Models From Natural Language Supervision » — [arXiv:2103.00020](https://arxiv.org/abs/2103.00020) |
+| **FAISS** (Meta AI) | Johnson et al., « Billion-scale similarity search with GPUs » — [arXiv:1702.08734](https://arxiv.org/abs/1702.08734) |
+| **OWL-v2** (Google, 2023) | Minderer et al., « Scaling Open-Vocabulary Object Detection » — [arXiv:2306.09683](https://arxiv.org/abs/2306.09683) |
+| **docTR** (Mindee) | OCR open-source — [GitHub: mindee/doctr](https://github.com/mindee/doctr) |
+| **Qwen2.5-VL** (Alibaba) | Modèle vision-langage — [HuggingFace: Qwen](https://huggingface.co/Qwen) |
+| **PyTorch** (Meta AI) | Framework de deep learning — [pytorch.org](https://pytorch.org/) |
+| **OpenCV** | Bibliothèque de vision par ordinateur — [opencv.org](https://opencv.org/) |
+
+---
+
+## Annexes
+
+### A. Liste des modules du moteur Core (192 fichiers)
+
+Les modules couvrent : analytics, capture, detection, embedding, execution, graph, healing, learning, matching, models, monitoring, security, system, training.
+
+### B. Catalogue des 24 actions VWB
+
+Vision UI (14) : click_anchor, type_text, screenshot_evidence, extract_text, hover, drag_drop, select_option, scroll, wait_element, verify_element, double_click, right_click, keyboard_shortcut, focus_element
+
+Navigation (2) : navigate_to_url, browser_back
+
+Data (2) : download_to_folder, extraire_tableau
+
+Database (3) : save_data, load_data, db_manager
+
+Validation (2) : verify_element_exists, verify_text_content
+
+Intelligence (1) : analyze_with_ai
+
+### C. Références documentaires internes
+
+- `ARCHITECTURE_VISION_COMPLETE.md` — Architecture complète 5 couches
+- `PITCH_INVESTISSEURS_RPA_VISION_V3.md` — Pitch investisseurs
+- `ANALYSE_MOAT_RPA_VISION_V3.md` — Analyse concurrentielle détaillée
+- `QUICK_START.md` — Guide de démarrage rapide
+
+---
+
+*Document généré le 25 février 2026 — RPA Vision V3*
--- a/docs/EXECUTION_LOOP_FLAGS.md
+++ b/docs/EXECUTION_LOOP_FLAGS.md
@@ -0,0 +1,192 @@
+# Flags d'exécution vision-aware (C1) — ExecutionLoop
+
+> Introduit dans la série de correctifs **C1** (avril 2026).
+> Référence code : [`core/execution/execution_loop.py`](../core/execution/execution_loop.py) (classe `ExecutionLoop`, constructeur lignes ~177-237).
+
+Cette page décrit les quatre flags ajoutés à `ExecutionLoop` pour piloter
+finement la construction de `ScreenState` pendant le replay. Ils permettent de
+dégrader volontairement le pipeline de perception quand un composant est en
+panne ou quand on veut gagner de la latence.
+
+## Contexte
+
+Depuis C1, chaque itération de la boucle d'exécution construit un
+`ScreenState` enrichi via `ScreenAnalyzer` (OCR + détection UI + embedding),
+avec un cache perceptuel pour éviter de recalculer deux fois sur le même
+screenshot.
+
+Cela coûte cher (~200 ms – 2 s selon la machine). Les flags ci-dessous
+permettent de désactiver ou contraindre ces étapes.
+
+Le `StepResult` expose désormais :
+
+| Champ | Type | Sens |
+|---|---|---|
+| `ocr_ms` | float | Temps OCR pour ce step |
+| `ui_ms` | float | Temps détection UI pour ce step |
+| `analyze_ms` | float | Temps total analyse ScreenState |
+| `total_ms` | float | Temps total du step (alias `duration_ms`) |
+| `cache_hit` | bool | True si le ScreenState vient du cache perceptuel |
+| `degraded` | bool | True si on est retombé en mode dégradé |
+
+Ces champs remontent automatiquement dans le module analytics
+(table SQLite `step_metrics`, voir
+[`core/analytics/storage/timeseries_store.py`](../core/analytics/storage/timeseries_store.py)).
+
+## Flags
+
+### `enable_ui_detection: bool = True`
+
+Active/désactive la détection UI (YOLO + SomEngine + VLM de grounding).
+
+**Pourquoi le désactiver** :
+- Le serveur VLM (Ollama) est down ou surchargé
+- On cible un workflow très simple où seul l'OCR suffit
+- On debugge un problème de détection et on veut isoler la cause
+
+**Impact performance** : gain ~100-1500 ms par step selon modèle VLM.
+
+**Exemple** :
+
+```python
+from core.execution.execution_loop import ExecutionLoop, ExecutionMode
+
+loop = ExecutionLoop(
+    pipeline=pipeline,
+    enable_ui_detection=False,   # VLM down → on coupe la détection UI
+)
+loop.start(workflow_id="wf_notepad", mode=ExecutionMode.AUTOMATIC)
+```
+
+### `enable_ocr: bool = True`
+
+Active/désactive l'OCR (Tesseract/docTR).
+
+**Pourquoi le désactiver** :
+- Gains de performance sur un workflow piloté uniquement par templates/embeddings
+- Environnement CPU-only où l'OCR est trop lent
+- Les textes ne sont pas utilisés par la stratégie de matching
+
+**Impact performance** : gain ~80-500 ms par step.
+
+**Exemple** :
+
+```python
+loop = ExecutionLoop(
+    pipeline=pipeline,
+    enable_ocr=False,
+)
+```
+
+> Note : si `enable_ui_detection=False` **et** `enable_ocr=False`, la boucle
+> renvoie un `ScreenState` stub (sans texte ni éléments) et force
+> `degraded=True`. Le matching retombera sur les embeddings CLIP seuls.
+
+### `analyze_timeout_ms: int = 8000`
+
+Seuil soft en millisecondes au-delà duquel on considère que l'analyse a été
+trop lente et on bascule **tous les steps suivants** en mode dégradé
+(pas de recalcul OCR/UI, réutilisation du cache ou stub direct).
+
+**Pourquoi le modifier** :
+- Machines lentes (CPU, VM, Citrix) → augmenter à `15000` ou `20000`
+- Serveurs dédiés GPU → réduire à `3000` pour détecter plus tôt
+- Tests / profiling → utiliser `999999` pour désactiver le basculement
+
+**Exemple** :
+
+```python
+loop = ExecutionLoop(
+    pipeline=pipeline,
+    analyze_timeout_ms=15000,    # environnement lent (RDP/Citrix)
+)
+```
+
+Le mode dégradé est porté par `ExecutionLoop._degraded_mode` et affiché dans
+`StepResult.degraded`. Voir
+[`_build_screen_state`](../core/execution/execution_loop.py) (~ligne 920).
+
+### `window_info_provider: Optional[Callable[[], Optional[Dict]]] = None`
+
+Callable renvoyant un `dict` décrivant la fenêtre active. Par défaut, la
+boucle appelle `screen_capturer.get_active_window()`.
+
+**Pourquoi fournir un provider custom** :
+- **Citrix / RDP** : le client Windows local voit un seul process (le client
+  Citrix). L'info de fenêtre utile vient de l'agent distant, on doit donc la
+  passer explicitement.
+- **Environnements headless** : pas de gestionnaire de fenêtres natif.
+- **Tests** : injecter une fenêtre mockée sans toucher au capturer.
+
+**Format attendu du dict** (au minimum) :
+
+```python
+{
+    "title": str,       # Titre de la fenêtre
+    "app_name": str,    # Nom de l'application
+    # champs optionnels utilisés par ScreenAnalyzer
+    "x": int, "y": int, "width": int, "height": int,
+}
+```
+
+**Exemple Citrix** :
+
+```python
+def citrix_window_info():
+    # L'agent dans la session Citrix distante publie ces infos
+    # (par ex. via un fichier partagé ou une websocket)
+    return remote_agent.get_current_window_info()
+
+loop = ExecutionLoop(
+    pipeline=pipeline,
+    window_info_provider=citrix_window_info,
+)
+```
+
+## Combinaisons recommandées
+
+| Cas d'usage | Flags |
+|---|---|
+| Production standard (GPU local) | `enable_ui_detection=True, enable_ocr=True, analyze_timeout_ms=8000` (défaut) |
+| VLM down — mode fallback | `enable_ui_detection=False, enable_ocr=True` |
+| Machine lente / VM | `analyze_timeout_ms=15000` |
+| Citrix / RDP | `window_info_provider=<custom>` + valeurs par défaut |
+| Benchmark CLIP-only | `enable_ui_detection=False, enable_ocr=False` |
+
+## Remontée analytics
+
+Les timings et flags dégradés persistent dans la table SQLite
+`step_metrics` (colonnes `ocr_ms`, `ui_ms`, `analyze_ms`, `total_ms`,
+`cache_hit`, `degraded`) via
+[`AnalyticsExecutionIntegration.on_step_result`](../core/analytics/integration/execution_integration.py).
+
+Exemple de requête d'analyse :
+
+```sql
+-- Steps avec OCR lent (>300 ms)
+SELECT node_id, action_type, ocr_ms, analyze_ms
+FROM step_metrics
+WHERE ocr_ms > 300
+ORDER BY ocr_ms DESC;
+
+-- Taux de cache hit par workflow
+SELECT workflow_id,
+       SUM(cache_hit) * 1.0 / COUNT(*) AS cache_hit_ratio
+FROM step_metrics
+GROUP BY workflow_id;
+
+-- Steps ayant basculé en mode dégradé
+SELECT execution_id, node_id, analyze_ms
+FROM step_metrics
+WHERE degraded = 1
+ORDER BY started_at DESC;
+```
+
+## Voir aussi
+
+- [`core/execution/execution_loop.py`](../core/execution/execution_loop.py) — implémentation
+- [`core/pipeline/screen_analyzer.py`](../core/pipeline/screen_analyzer.py) — pipeline d'analyse
+- [`core/pipeline/screen_state_cache.py`](../core/pipeline/screen_state_cache.py) — cache perceptuel
+- [`tests/unit/test_execution_loop_vision_aware.py`](../tests/unit/test_execution_loop_vision_aware.py) — tests C1
+- [`tests/unit/test_analytics_vision_metrics.py`](../tests/unit/test_analytics_vision_metrics.py) — tests analytics C1
+- [docs/STATUS.md](STATUS.md) — état général du projet
--- a/docs/PLAN_ACTION_DASHBOARD.md
+++ b/docs/PLAN_ACTION_DASHBOARD.md
@@ -0,0 +1,267 @@
+# Plan d'action — Dashboard Web RPA Vision V3
+
+_Date : 2026-04-15 — périmètre : `web_dashboard/` (port 5001). Auteur : audit technique (lecture seule, aucune modif de code)._
+
+Objectifs :
+1. faire le ménage dans un dashboard qui a grossi par sédimentation,
+2. préparer l'onglet **Audit & Traçabilité** attendu par les clients (AI Act / RGPD),
+3. donner à Dom une roadmap actionnable et priorisée.
+
+---
+
+## Section A — Inventaire
+
+Le dashboard a aujourd'hui **14 onglets** déclarés dans `web_dashboard/templates/index.html` (3 455 lignes) plus des pages auxiliaires (`chat.html`, `gestures.html`, `extractions.html`, `streaming.html`). Le backend Flask (`web_dashboard/app.py`, 2 665 lignes) expose **~65 routes HTTP** + 4 events SocketIO.
+
+| # | Onglet (label UI) | Routes backend principales | État | MAJ estimée | Utile ? |
+|---|---|---|---|---|---|
+| 1 | 🎛️ Services | `/api/services*`, `/api/version*` | **OK** — fonctionne, utilisé quotidiennement | avril 2026 | **oui, cœur** |
+| 2 | 📊 Vue d'ensemble | `/api/system/status`, SocketIO | **OK partiel** — `statTests` et `statExecution` remplis par legacy | mars 2026 | doublonne avec Services |
+| 3 | ⚡ Exécution | `/api/automation/*`, SocketIO `subscribe_execution` | **Douteux** — branché sur le moteur v1 core, pas sur Agent V1 streaming (5005). Le replay réel passe par VWB ou `/api/v1/traces/stream/replay*` | janv. 2026 | **non en l'état** — obsolète face au flux replay actuel |
+| 4 | 🔄 Workflows | `/api/workflows*`, `/api/chains*`, `/api/triggers*` | **OK liste**, exécution via `/api/workflows/<id>/execute` redondante avec VWB et Agent V1 | janv.-mars 2026 | partiel — la liste oui, l'exécution non |
+| 5 | 📦 Sessions | `/api/agent/sessions*` | **OK** — affiche bien les sessions dans `data/training/sessions/` | avril 2026 | **oui** mais se recoupe avec le cleaner (5006) |
+| 6 | 📈 Performance | `/api/system/performance`, `/api/system/faiss/test`, `/metrics` | **OK** — FAISS + Prometheus + cache hit | mars 2026 | **oui, utile debug/benchmark** |
+| 7 | 📡 Streaming | proxy vers `http://localhost:5005/api/v1/traces/stream/*` | **OK** — lecture seule, bonne visibilité live sessions | mars 2026 | **oui, cœur Agent V1** |
+| 8 | 📄 Logs | `/api/logs`, `/api/logs/download` | **OK minimaliste** — lit `logs/*.log`, pas de filtre/tail | nov. 2025 | utile ponctuel, pourrait disparaître si Audit bien fait |
+| 9 | 🧪 Tests | `/api/tests*` (subprocess `pytest`) | **Cassé en prod** — pytest non dispo sur cible packagée, timeout 120s bloque l'UI, **aucun droit d'exécuter pytest depuis une UI exposée sur Internet** | mars 2026 | **NON — à retirer** |
+| 10 | 💾 Sauvegardes | `/api/backup/*` | **OK** — exports fonctionnels | janv. 2026 | **oui**, valeur clairement réglementaire |
+| 11 | 🔧 Corrections (packs) | routes ailleurs (VWB / API core) — onglet affiche des stats | **Cassé** — `refreshCorrectionPacks` appelle une route qui n'existe plus côté dashboard, données via VWB | févr. 2026 | à supprimer côté dashboard, garder côté VWB |
+| 12 | 🧠 Apprentissage | idem : placeholders `statCorpusSize`, charts Chart.js non alimentés | **Cassé/placeholder** — aucune route backend ne nourrit les 4 stat-cards ni les 2 canvas | janv. 2026 | **NON — à retirer ou refaire sérieusement** |
+| 13 | 🔧 Configuration | `/api/config*`, `/api/config/ollama-models`, `/api/config/test-connection` | **OK** — édition ports/modèles/DB/sécurité/logs | avril 2026 | **oui** (utile admin) |
+| 14 | 🧹 Nettoyage | iframe → `http://localhost:5006` | **OK** — ajouté hier, dépend du service session_cleaner | avril 2026 | **oui** |
+
+Pages auxiliaires (templates séparés, non liées aux onglets) :
+
+| Page | Route | État | Verdict |
+|---|---|---|---|
+| `/chat` | `chat.html` + `/api/chat/*` | **OK expérimental** — utilisé en dev | doublonne Agent Chat (5004), à supprimer ici |
+| `/gestures` | `gestures.html` + `/api/gestures` | **Mort** — aucune donnée, concept abandonné | **à supprimer** |
+| `/extractions` | `extractions.html` + `/api/extractions*` | **Douteux** — fonctionnalité concurrente au plan Data Extraction prévu via VWB | à geler/archiver |
+| `/streaming` | `streaming.html` | **Doublon** — remplacé par l'onglet Streaming intégré dans `index.html` | **à supprimer** |
+
+SocketIO : 4 events (`connect`, `disconnect`, `subscribe_execution`, `get_performance`). Seul `connect/disconnect` sert aujourd'hui — le reste alimente l'onglet Exécution qui va disparaître.
+
+---
+
+## Section B — À virer (cleanup)
+
+Dans cet ordre, à faire en un seul coup (effort total estimé : **2 à 3 heures**).
+
+1. **Onglet 🧪 Tests** (lignes 67, 499-517 de `index.html` ; routes 1006-1094 de `app.py`)
+   - Pourquoi : exécuter `pytest` depuis une UI auth Basic exposée sur Internet est une RCE déguisée. Et ça plante en prod. Les tests se lancent en CLI.
+   - Effort : 20 min.
+
+2. **Onglet 🧠 Apprentissage** (lignes 70, 665-720)
+   - Pourquoi : placeholders, aucune route backend, induit le client en erreur.
+   - Alternative : soit on le refait proprement dans l'onglet **Audit & Traçabilité** (stats globales sur trace d'exécution), soit on l'enlève.
+   - Effort : 10 min (retrait).
+
+3. **Onglet 🔧 Corrections** (lignes 69, 603-664)
+   - Pourquoi : les correction packs sont gérés dans VWB, pas ici. L'onglet affiche des cartes qui ne se remplissent plus. Ajouter un simple bouton "Ouvrir VWB" dans l'onglet Services suffit.
+   - Effort : 10 min.
+
+4. **Onglet ⚡ Exécution** (lignes 61, 197-233)
+   - Pourquoi : branché sur l'ancien moteur core via SocketIO `subscribe_execution`. Aujourd'hui le replay passe par l'Agent V1 et VWB. L'onglet Streaming couvre déjà le live.
+   - Effort : 15 min (retrait + supprimer les 4 routes `/api/automation/*`).
+
+5. **Onglet 📊 Vue d'ensemble** (lignes 60, 162-194)
+   - Pourquoi : 4 stat-cards dupliquées depuis Services + Sessions + Workflows. Un `perfChart` qui duplique ce qui est dans Performance.
+   - Alternative : fusionner un mini-résumé (4 KPIs) en tête de l'onglet Services, ce qui fait gagner un clic. Puis supprimer l'onglet.
+   - Effort : 30 min.
+
+6. **Pages auxiliaires `/chat`, `/gestures`, `/streaming`, `/extractions`**
+   - Pourquoi : concurrence avec services dédiés (Agent Chat 5004, VWB, plan Data Extraction) ou fonctionnalités mortes (gestures).
+   - Effort : 15 min (supprimer templates + routes Flask).
+
+7. **Code mort résiduel**
+   - `execution_state`, `performance_metrics` (globales module) : utiles uniquement si Exécution / Overview subsistent.
+   - `chain_manager`, `trigger_manager`, `automation_scheduler` : à évaluer, probablement à garder côté moteur mais retirer l'UI.
+   - Effort : 30 min.
+
+**Résultat visé** : de 14 onglets à **8 onglets** (Services, Sessions, Performance, Streaming, Logs, Sauvegardes, Config, Nettoyage) **+ 1 nouveau** (Audit). Soit **9 onglets utiles et alimentés**.
+
+---
+
+## Section C — À garder mais améliorer
+
+Par priorité.
+
+1. **🎛️ Services** — ajouter un bandeau "santé globale" (somme du statut des 6 services critiques + streaming server + session cleaner) et rapatrier les 4 stat-cards de "Vue d'ensemble" en tête. Effort : **1 h**.
+
+2. **📦 Sessions** — ajouter un filtre par statut (pending/processing/completed/failed — la donnée existe déjà dans `PROCESSING_STATUS_FILE`). Ajouter un bouton "Voir dans le cleaner" qui ouvre l'onglet Nettoyage pré-filtré sur la session. Effort : **1 h**.
+
+3. **📄 Logs** — passer en lecture "tail -f" WebSocket plutôt que polling d'un fichier entier. Filtrer par niveau (INFO/WARN/ERROR) côté serveur. Effort : **2 h**. Faible priorité : une fois l'onglet Audit en place, 90 % de l'usage métier disparaît.
+
+4. **📈 Performance** — la section FAISS est bonne. Retirer les deux graphiques Chart.js `cacheChart` et `faissChart` : ils se redessinent toutes les 5s avec un tableau vide au reload, c'est du bruit visuel. Effort : **20 min**.
+
+5. **🔧 Configuration** — documenter dans un tooltip chaque champ (DASHBOARD_PASSWORD, RPA_API_TOKEN, etc.) et signaler clairement les secrets. Ajouter un bouton "Recharger les modèles Ollama" déjà présent mais discret. Effort : **1 h**.
+
+Aucune amélioration pour Streaming, Sauvegardes, Nettoyage : ils sont récents et suffisants.
+
+---
+
+## Section D — Nouvel onglet "⚖️ Audit & Traçabilité"
+
+### Ce que l'utilisateur voit
+
+Une table paginée des actions Léa, précédée de filtres, avec export CSV.
+
+**Bandeau haut** — 4 KPIs aujourd'hui :
+
+- Actions totales (24 h)
+- Taux de succès global
+- Nombre de TIMs actifs
+- Applications cibles touchées
+
+**Zone de filtres** (ligne horizontale) :
+
+- Période (preset : Aujourd'hui / 7j / 30j / personnalisée via deux date pickers)
+- Collaborateur (dropdown peuplé via `/api/v1/audit/summary` → `by_user`)
+- Application métier (dropdown, peuplé via le champ `target_app` des entrées)
+- Type d'action (click, type, key_combo, wait)
+- Résultat (success / failed / recovered / skipped)
+- Mode d'exécution (autonomous / assisted / shadow)
+- Workflow (dropdown si < 50, sinon champ texte)
+- Recherche libre (matche `action_detail`)
+
+**Boutons d'action** (à droite du bandeau) :
+
+- 📥 Exporter CSV (respecte les filtres courants)
+- 📄 Rapport PDF pour DSI (génération simple, voir ci-dessous)
+- 🔄 Actualiser
+
+**Tableau principal** (colonnes dans cet ordre) :
+
+| Colonne | Source `AuditEntry` | Remarque |
+|---|---|---|
+| Horodatage | `timestamp` | affichage local `HH:mm:ss · JJ/MM` |
+| Collaborateur | `user_name` ou fallback `user_id` | |
+| Poste | `machine_id` | utile multi-sites |
+| Application | `target_app` | DPI, Orbis, DxCare, navigateur… |
+| Action | `action_type` + badge | icône par type |
+| Détail | `action_detail` | tronqué à 80 car., tooltip complet |
+| Mode | `execution_mode` | badge coloré |
+| Résultat | `result` | vert/rouge/orange |
+| Récup. | `recovery_action` | uniquement si `result != success` |
+| Durée | `duration_ms` | ms → s si > 1 s |
+| Workflow | `workflow_name` ou `workflow_id` tronqué | lien vers détail workflow |
+
+Ligne cliquable → panneau latéral avec le JSON complet (+ `critic_result`, `resolution_method`, session_id, action_id). Ce panneau sert aux audits techniques.
+
+**Pagination** serveur (limit 100, offset) — le backend `/api/v1/audit/history` gère déjà.
+
+**Widgets complémentaires** (en dessous du tableau) :
+
+- Camembert "répartition par application" (utile DSI pour visualiser le périmètre Léa)
+- Courbe "taux d'échec sur 7 j" (seuil d'alerte ajustable)
+- Liste "Top 10 échecs récents" — pour qu'un TIM/RSSI identifie vite les workflows à retoucher
+
+### Sources de données — ce qui existe déjà
+
+Tout le backend est **déjà là** côté streaming server (port 5005) :
+
+- Module `agent_v0/server_v1/audit_trail.py` — `AuditTrail` avec `record()`, `query()`, `get_summary()`, `export_csv()`.
+- Endpoints FastAPI déjà en place :
+  - `GET /api/v1/audit/history` — historique filtrable paginé
+  - `GET /api/v1/audit/summary?date=YYYY-MM-DD` — résumé du jour
+  - `GET /api/v1/audit/export` — export CSV
+- Données réelles présentes dans `data/audit/audit_YYYY-MM-DD.jsonl` (7 fichiers, ~500 ko sur les 10 derniers jours, ~1 800 entrées aujourd'hui).
+
+### Ce qu'il manque
+
+1. **Proxy Flask côté dashboard (5001 → 5005)** — sur le modèle de `/api/streaming/<path:endpoint>` qui existe déjà (`app.py:2505`). Coût : ~30 lignes.
+2. **Template HTML + JS** — nouvel onglet dans `index.html`, ~300 lignes. Pas de framework : réutiliser le style et Chart.js existant.
+3. **Champ patient pseudonymisé** : actuellement **pas présent** dans `AuditEntry`. Décision nécessaire :
+   - Option A (recommandée) : ajouter un champ optionnel `patient_ref_hash` (SHA-256 tronqué du n° patient), alimenté quand Léa extrait ou saisit un identifiant patient. Coût : ajout d'un champ dataclass + propagation dans 2-3 endroits au niveau exécuteur.
+   - Option B : n'en pas mettre pour le POC Anouste, préciser dans la doc DSI.
+4. **Rapport PDF DSI** — simple template ReportLab ou WeasyPrint, une page A4 avec en-tête (client, période, nombre d'actions, signature hash des logs source pour intégrité), puis le tableau filtré. Coût : ~150 lignes + 1 dép.
+
+### Effort estimé
+
+| Lot | Jours·homme |
+|---|---|
+| Proxy Flask + nouvel onglet (MVP : tableau + filtres + export CSV) | **0.5** |
+| Widgets graphiques (camembert + courbe 7j) | 0.25 |
+| Rapport PDF DSI | 0.5 |
+| Champ `patient_ref_hash` (option A) | 0.5 |
+| Alerting (si > N échecs consécutifs sur 1 h → badge rouge + email optionnel) | 0.5 |
+| **Total MVP (sans PDF ni patient)** | **0.75 j** |
+| **Total version "complète DSI-ready"** | **~2.25 j** |
+
+### Réglementaire — ce qui est adressé
+
+- **AI Act, article 12 — "Record-keeping"** : les systèmes d'IA à haut risque doivent **automatiquement enregistrer** les événements pertinents. L'onglet rend visibles et exportables les logs qui existent déjà côté serveur. Respect du critère _traçabilité permanente_.
+- **AI Act, article 14 — "Human oversight"** : le champ `execution_mode` (`shadow/assisted/autonomous`) documente le niveau de supervision humaine pour chaque action.
+- **RGPD, article 30 — registre des traitements** : champ `target_app` + `domain` permettent de produire un inventaire des traitements par application métier.
+- **RGPD, article 32 — intégrité** : ajouter un hash SHA-256 du fichier JSONL signé à la clôture journalière (coût marginal, 20 lignes) garantit la non-falsification.
+- **RGPD, article 33 — notification de violation** : l'alerting (> N échecs sur fenêtre glissante) est la brique technique qui permet à un RSSI d'être notifié.
+
+### Exemple concret — "un DSI hospitalier demande un audit"
+
+**Scénario** : le DSI du CH d'Auch veut montrer à son directeur que Léa n'a jamais validé seule une codification CIM-10 sur le patient X pendant la semaine 15.
+
+1. Il ouvre le dashboard → onglet Audit.
+2. Filtre : période = 2026-04-06 → 2026-04-12, application = `DxCare`, action = `click`.
+3. Il saisit dans la recherche libre le hash pseudo du patient (fourni par le TIM responsable).
+4. Il voit 3 lignes, toutes en mode `assisted`, toutes avec `user_name = "Marie Dupont"`.
+5. Il clique sur "📄 Rapport PDF DSI" → reçoit un PDF d'une page avec les 3 lignes, la signature d'intégrité, le tampon Léa, la période.
+6. Il remonte ça à sa direction. Dossier clos en 4 minutes.
+
+C'est exactement le cas d'usage qui manque aujourd'hui et qui fera la différence en appel d'offres CHU.
+
+---
+
+## Section E — Non-décisions (ce qu'on ne fait pas)
+
+- **Dashboard mobile / responsive** : le dashboard est un outil admin, pas un produit grand public. Les TIMs n'en ont pas besoin sur téléphone. **Non.**
+- **Multi-thème (clair/sombre)** : sombre tout le temps. **Non.**
+- **Internationalisation du dashboard** : tout est en français, cible FR. i18n prévu côté produit Léa, pas côté dashboard admin. **Non pour 2026.**
+- **Refonte complète en framework (React/Vue)** : le HTML vanilla + Chart.js tient la route. Une refonte coûterait 2 semaines pour zéro gain utilisateur. **Non.**
+- **Authentification OAuth / SSO** : HTTP Basic suffit sur usage interne. SSO hôpital = chantier en soi, ne pas le mélanger avec ce cleanup. **Pas maintenant.**
+- **Temps réel sur l'onglet Audit** : le polling toutes les 30 s est largement suffisant. WebSocket = complexité inutile ici. **Non.**
+
+---
+
+## Section F — Roadmap recommandée
+
+Ordre **non négociable** : on fait le ménage **avant** d'ajouter du neuf. Un onglet Audit brillant au milieu d'un dashboard bruité envoie un signal d'amateurisme.
+
+### Sprint 1 — Cleanup (0.5 jour)
+
+- Section B points 1 à 7 (retirer Tests, Apprentissage, Corrections, Exécution, Vue d'ensemble, pages mortes, code orphelin).
+- **Livrable** : dashboard à 8 onglets fonctionnels, zéro placeholder, zéro 404 silencieuse.
+- **Critère de sortie** : un client invité voit l'interface sans jamais tomber sur une page vide ou une erreur JS.
+
+### Sprint 2 — Onglet Audit MVP (0.75 jour)
+
+- Proxy Flask `/api/audit/*` → `http://localhost:5005/api/v1/audit/*` (réutilise le pattern `/api/streaming/<path>`).
+- Nouvel onglet "⚖️ Audit & Traçabilité" : bandeau 4 KPIs + filtres + tableau paginé + export CSV.
+- **Livrable** : un DSI peut filtrer, visualiser, exporter.
+- **Critère de sortie** : scénario CH Auch (voir Section D) exécutable en < 5 min par un utilisateur non technique.
+
+### Sprint 3 — Audit complet DSI-ready (1.5 jour, à chaud si appel d'offres)
+
+- Rapport PDF DSI.
+- Champ `patient_ref_hash` dans `AuditEntry` + propagation executor.
+- Signature d'intégrité journalière (hash du JSONL en clôture).
+- Widgets graphiques (camembert + courbe 7 j).
+- Alerting seuil d'échecs.
+- **Livrable** : conformité démontrable AI Act art. 12 + 14 + RGPD art. 30 + 32.
+
+### Sprint 4 — Améliorations ciblées (1 à 2 jours, au fil de l'eau)
+
+- Section C (santé globale Services, filtres Sessions, tail logs WebSocket, retrait graphiques vides Performance, tooltips Config).
+- À faire **seulement** quand un TIM ou un DSI remonte un manque précis, pas en préventif.
+
+---
+
+## Annexe — Justification du cleanup
+
+Pourquoi on supprime plutôt qu'on "met en veille" ?
+
+1. Chaque onglet coûte en maintenance (CSS, JS, tests manuels, support client).
+2. Chaque route Flask morte est une surface d'attaque (surtout `/api/tests/run` qui exécute `pytest` en subprocess).
+3. Chaque placeholder visuel dégrade la perception client : "pourquoi il y a un onglet 🧠 Apprentissage qui n'affiche rien ?"
+4. Git garde tout. Aucune donnée n'est perdue. Revert possible.
+
+Principe général : **moins de surface, plus de valeur**. Un dashboard de 9 onglets pleins bat un dashboard de 14 onglets dont 5 creux, tous les jours.
--- a/docs/PLAN_ACTION_MARS_2026.md
+++ b/docs/PLAN_ACTION_MARS_2026.md
@@ -0,0 +1,194 @@
+# Plan d'action RPA Vision V3 — Mars 2026
+
+**Date** : 10 mars 2026
+**Auteur** : Dom + Claude
+**Statut** : En cours de validation
+
+---
+
+## Diagnostic du projet
+
+### Objectif du projet
+
+Système RPA **100% basé sur la vision** (pas de sélecteurs DOM/accessibility) capable d'**apprendre par observation** des workflows utilisateur et de les rejouer de manière autonome.
+
+**Philosophie** : "Observer → Comprendre → Apprendre → Agir"
+
+**Cas d'usage cible** : milieu médical (facturation T2A, logiciels hospitaliers type HIS) — applications legacy sans API.
+
+**Progression d'apprentissage** : OBSERVATION → COACHING → AUTO_CANDIDATE → AUTO_CONFIRMED
+
+### Architecture 5 couches
+
+```
+Couche 0: RawSession       — Capturer clics/clavier/screenshots
+Couche 1: ScreenState      — Analyser l'écran (image + texte + UI + contexte métier)
+Couche 2: UIElement         — Détecter boutons/champs/tableaux sémantiquement
+Couche 3: StateEmbedding    — Créer un "fingerprint" fusionné de l'état d'écran
+Couche 4: WorkflowGraph     — Modéliser en graphe (nodes = écrans, edges = actions)
+```
+
+### Etat réel du code vs la vision documentée
+
+| Composant | Statut | Notes |
+|---|---|---|
+| Modèles de données (5 couches) | **Complet** | Dataclasses/Pydantic bien structurées |
+| Pipeline de détection UI (OWL-v2 + OpenCV + VLM) | **Fonctionnel** | |
+| Embedding multi-modal (CLIP + FAISS) | **Fonctionnel** | BUG: composant texte toujours None |
+| Learning States (4 niveaux + transitions) | **Implémenté** | |
+| ActionExecutor + TargetResolver | **Très complet** | ~2800 lignes, multi-stratégie |
+| ExecutionLoop multi-modes | **Implémenté** | |
+| Self-healing (4 stratégies) | **Implémenté** | |
+| GraphBuilder (RawSession → Workflow) | **Partiel** | Clustering OK, templates incomplets |
+| Capture d'événements (clavier/souris) | **Absent du core** | Délégué à agent_v0 (séparé) |
+| Construction auto des 4 niveaux ScreenState | **Absent** | OCR jamais peuplé |
+| Visual Workflow Builder (éditeur web) | **Fonctionnel** | React + Flask, 20+ composants |
+
+### Enrichissements documentés (8 concepts)
+
+| # | Concept | Statut code |
+|---|---|---|
+| 1 | Grammaire du temps (épisodes) | Partiel — boost temporel, pas de patterns |
+| 2 | Marquage du bruit | Manquant — implicite dans DBSCAN, non persisté |
+| 3 | Layout signature | Implémenté — `screen_signature.py` |
+| 4 | Identité stable | Partiel — target_memory, pas de StableIdentity formelle |
+| 5 | Actionnabilité (scores) | Partiel — `is_interactable` bool, pas de score numérique |
+| 6 | Versioning des espaces | Implémenté — PrototypeVersion |
+| 7 | Variables métier | Partiel — champ présent, intégration non automatisée |
+| 8 | Noeuds d'erreur | Manquant — pas de ErrorNode dans le graphe |
+
+### Problèmes identifiés
+
+#### Bug critique silencieux
+`core/embedding/state_embedding_builder.py` accède à `detected_texts` (avec 's') alors que le champ réel s'appelle `detected_text`. Le composant texte de l'embedding (30% du poids) est **toujours None**. La qualité du matching est silencieusement dégradée.
+
+#### Pipeline end-to-end non bouclé
+La chaîne complète "observer un utilisateur → construire un workflow → le rejouer" n'est pas opérationnelle. La capture d'événements est dans agent_v0 (séparé), le GraphBuilder laisse des TODOs dans les templates, l'OCR ne peuple jamais le ScreenState.
+
+#### Dette technique massive
+- ~660K lignes Python, ~25 000 fichiers
+- Centaines de scripts one-shot (classés dans `_a_trier/`)
+- 3 frontends VWB abandonnés (classés dans `_a_trier/`)
+- agent_v0 de 7.9 Go
+- Ratio signal/bruit faible
+
+#### Dispersion de l'effort
+Beaucoup de modules sophistiqués (coaching, analytics, monitoring, sécurité, i18n, training, précision) développés en parallèle, mais la boucle fondamentale n'est pas fiable.
+
+---
+
+## Programme d'action
+
+### Phase 0 — Stabiliser les fondations (1-2 semaines)
+
+**Objectif : un pipeline minimal qui tourne de A à Z**
+
+- [x] **P0-1** Corriger le bug `detected_texts` → `detected_text` dans `state_embedding_builder.py`
+- [x] **P0-2** Intégrer la capture d'événements dans le core (`core/capture/event_listener.py` — pynput)
+- [x] **P0-3** Implémenter le Screen Analyzer (`core/pipeline/screen_analyzer.py` — ScreenState complet 4 niveaux)
+- [x] **P0-4** Compléter le GraphBuilder — `_create_screen_template()` + alignement modèles + fix import circulaire
+- [x] **P0-5** Test E2E (`tests/test_pipeline_e2e.py` — 20 tests, pipeline validé avec embeddings mock)
+
+**Critère de succès** : une démo qui enregistre un workflow simple et le rejoue correctement.
+
+### Phase 1 — Valider sur un cas réel (2-3 semaines)
+
+**Objectif : prouver que ça fonctionne sur un vrai logiciel**
+
+**Prérequis (complétés) :**
+- [x] SessionRecorder (`core/capture/session_recorder.py`) — orchestre EventListener + ScreenCapturer
+- [x] Script CLI (`scripts/record_and_build.py`) — record / build / full / list
+- [x] Fix `_extract_node_vector` dans WorkflowPipeline (support metadata prototypes)
+- [x] Nettoyage code mort dans `execute_workflow_step`
+- [x] Validation pipeline sur session réelle (66 screenshots → 1 node "Calculatrice")
+
+**Tâches :**
+- [ ] **P1-1** Choisir un workflow simple sur une application réelle (ex : 3 boutons + 1 saisie)
+- [ ] **P1-2** Enregistrer 5 sessions de ce workflow (`python scripts/record_and_build.py record`)
+- [ ] **P1-3** Vérifier que le GraphBuilder crée un workflow cohérent (`python scripts/record_and_build.py build`)
+- [ ] **P1-4** Passer en COACHING → valider les suggestions
+- [ ] **P1-5** Passer en AUTO_CANDIDATE → vérifier l'exécution supervisée
+- [ ] **P1-6** Mesurer : précision matching, taux succès, temps exécution
+
+**Critère de succès** : taux de succès > 80% en mode AUTO_CANDIDATE sur le workflow choisi.
+
+### Phase 2 — Consolider le core (3-4 semaines)
+
+**Objectif : fiabilité et robustesse**
+
+- [ ] **P2-1** Implémenter les enrichissements manquants prioritaires : noeuds d'erreur, identité stable formelle, score d'actionnabilité
+- [ ] **P2-2** Tests d'intégration sur le pipeline complet
+- [ ] **P2-3** Nettoyage `_a_trier/` — décider quoi garder/supprimer/archiver
+- [ ] **P2-4** Documentation code core (modules clés uniquement)
+
+**Critère de succès** : couverture de tests > 60% sur le pipeline core, zéro bug silencieux connu.
+
+### Phase 3 — Produit utilisable (4-6 semaines)
+
+**Objectif : le VWB comme outil complet**
+
+- [ ] **P3-1** Intégrer le pipeline core dans le VWB (aligner les services VWB sur core/)
+- [ ] **P3-2** Supprimer l'ancien frontend VWB (garder uniquement frontend_v4)
+- [ ] **P3-3** Workflow complet dans le VWB : enregistrer → éditer → tester → déployer
+- [ ] **P3-4** Mode démo pour présentation (prospects/investisseurs)
+
+**Critère de succès** : un utilisateur non technique peut enregistrer et rejouer un workflow via le VWB.
+
+### Ce qu'on ne fait PAS maintenant
+
+- Ajouter de nouvelles fonctionnalités (analytics avancé, coaching amélioré, multi-écran)
+- Refactorer la structure des 28 sous-modules
+- Migrer vers un autre framework web
+- Développer agent_v1 tant que le pipeline core n'est pas bouclé
+
+---
+
+## Métriques de suivi
+
+| Métrique | Cible Phase 0 | Cible Phase 1 | Cible Phase 3 |
+|---|---|---|---|
+| Pipeline end-to-end fonctionnel | Oui (cas simple) | Oui (cas réel) | Oui (multi-cas) |
+| Taux de succès AUTO_CANDIDATE | N/A | > 80% | > 90% |
+| Temps enregistrement → workflow | < 5 min | < 5 min | < 2 min |
+| Bugs silencieux connus | 0 | 0 | 0 |
+| Couverture tests pipeline | Smoke test | > 40% | > 60% |
+
+---
+
+## Fichiers clés à connaître
+
+### Core — Modèles
+- `core/models/raw_session.py` — RawSession, Event, Screenshot
+- `core/models/screen_state.py` — ScreenState (4 niveaux)
+- `core/models/ui_element.py` — UIElement, BBox, VisualFeatures
+- `core/models/state_embedding.py` — StateEmbedding, EmbeddingComponent
+- `core/models/workflow_graph.py` — Workflow, WorkflowNode, WorkflowEdge, LearningState
+
+### Core — Pipeline
+- `core/capture/screen_capturer.py` — Capture screenshots (mss)
+- `core/detection/ui_detector.py` — Pipeline OWL-v2 + OpenCV + VLM
+- `core/embedding/state_embedding_builder.py` — Construction StateEmbedding (**BUG ligne ~216**)
+- `core/embedding/clip_embedder.py` — OpenCLIP ViT-B-32
+- `core/embedding/faiss_manager.py` — Index FAISS
+- `core/graph/graph_builder.py` — RawSession → Workflow (DBSCAN, **TODOs templates**)
+
+### Core — Exécution
+- `core/execution/action_executor.py` — Exécution des actions
+- `core/execution/target_resolver.py` — Résolution multi-stratégie (~2800 lignes)
+- `core/execution/execution_loop.py` — Orchestration des modes
+- `core/healing/healing_engine.py` — Self-healing (4 stratégies)
+- `core/learning/learning_manager.py` — Machine à états d'apprentissage
+
+### Points d'entrée
+- `run.sh` — Chef d'orchestre (--full, --gui, --server, etc.)
+- `Makefile` — Tests (make test, make test-fast, make check)
+- `visual_workflow_builder/run_v4.sh` — VWB frontend_v4
+
+### Documentation de référence
+- `docs/reference/ARCHITECTURE_VISION_COMPLETE.md` — Architecture 5 couches
+- `docs/reference/ARCHITECTURE_ENRICHISSEMENTS.md` — 8 enrichissements
+- `docs/PLAN_ACTION_MARS_2026.md` — Ce fichier
+
+---
+
+**Priorité absolue : Phase 0 — Boucler le pipeline end-to-end.**
--- a/docs/PLAN_ACTION_VWB.md
+++ b/docs/PLAN_ACTION_VWB.md
@@ -0,0 +1,273 @@
+# Plan d'action VWB — 13 avril 2026
+
+Audit ciblé du **Visual Workflow Builder** (`visual_workflow_builder/`) — backend Flask port 5002, frontend React+Vite port 3002 — suite aux retours flous de Dom : « la bibliothèque s'efface tout le temps » + idée d'importer les workflows Léa pour les corriger.
+
+---
+
+## Section A — État des lieux
+
+### Stack réelle en production (PIDs live)
+
+- **Backend 5002** → `backend/app.py` (Flask complet, blueprints v3, SQLAlchemy) — **c'est celui qui sert le VWB**
+- **Backend 5003** → `backend/app_lightweight.py` (serveur HTTP natif fallback, 1451 lignes, mode quasi-inutile aujourd'hui)
+- **Frontend 3002** → `frontend_v4/` (Vite + React 18, `@xyflow/react`, TypeScript) — actif
+- **BDD utilisée** → `backend/instance/workflows.db` (via `.env DATABASE_URL=sqlite:///workflows.db`) — **3 workflows** dedans (« Classement de dossier », « bloc notes », « Onlyoffice »), tous `source='manual'`, aucun `review_status`
+- **BDD fantôme** → `backend/instance/vwb_v3.db` (schema identique, **0 workflows**) — zombie de `app.py` ligne 47 (`'sqlite:///vwb_v3.db'` en défaut)
+
+### Ce qui marche bien
+
+- **API v3** est complète et propre : 44 routes réparties (`session`, `workflow`, `capture`, `execute`, `match`, `review`, `learned_workflows`, `dag_execute`). Modèles SQLAlchemy avec champs review (`source`, `review_status`, `review_feedback`, `reviewed_at`).
+- **Pont Léa ↔ VWB déjà implémenté et câblé** :
+  - Backend : `api_v3/learned_workflows.py` (459 l.) + `services/learned_workflow_bridge.py` (604 l.)
+  - Frontend : `services/api.ts` expose `getLearnedWorkflows`, `importLearnedWorkflow`, `exportForLea` ; `components/WorkflowSelector.tsx` charge et propose d'importer les workflows non-importés
+  - Endpoints fonctionnels : logs du 15 avril montrent `GET /api/v3/learned-workflows?os=linux → 200`
+- **Système de review** : composants `ReviewModal.tsx`, `WorkflowValidation.tsx`, `WorkflowManagerModal.tsx` + backend `api_v3/review.py` prêt. Un workflow importé arrive en `review_status='pending_review'`.
+- Tests backend localisés : `backend/tests/` (test_models.py, test_coaching_api.py). Workflow CRUD complet.
+- Logs rotatifs propres (`backend/logs/vwb.log`, 5 MB × 3).
+
+### Ce qui est cassé / douteux
+
+1. **BUG CRITIQUE — Bibliothèque de captures qui s'efface**
+   Fichier : `frontend_v4/src/components/CaptureLibrary.tsx` lignes 25-62
+   - Stockage dans **`sessionStorage`** (clé `captureLibrary_v2`) → purgé à chaque fermeture d'onglet ou redémarrage du navigateur
+   - Cap arbitraire à **50 captures** max (`slice(0, 49)`)
+   - Les captures sont des base64 PNG → sessionStorage ne tient pas plus de quelques dizaines de Mo au total
+   - C'est très probablement **le bug** que Dom décrit
+
+2. **BUG — Deux composants concurrents pour la même bibliothèque**
+   - `CaptureLibrary.tsx` écrit dans `sessionStorage['captureLibrary_v2']`
+   - `CapturePanel.tsx` lignes 51-62 écrit dans `sessionStorage['captureLibrary']` (ancienne clé, jamais migrée à l'envers)
+   - Résultat : deux listes de captures tenues en parallèle, désynchronisées, invisibles l'une pour l'autre
+
+3. **Base fantôme `vwb_v3.db`**
+   - `app.py` l.47 : `'sqlite:///vwb_v3.db'` en défaut
+   - Si un jour `.env` n'est pas chargé (ex : systemd mal configuré), le VWB passe silencieusement sur l'autre BDD **vide** et Dom voit ses workflows disparaître
+   - Dette : deux fichiers `instance/` (`backend/instance/` et `visual_workflow_builder/instance/`) créent de la confusion
+
+4. **404 en prod — `/api/correction-packs/stats`**
+   - Logs récents : deux 404 à chaque chargement
+   - La route n'existe pas côté backend, elle est appelée par le **frontend legacy** (`frontend/src/hooks/useCorrectionPacks.ts`)
+   - Dom voit sans doute des erreurs CORS/404 dans la console réseau selon quel frontend il ouvre
+
+5. **Double logging (tous les logs en double)**
+   - `app.py` attache un handler au **root logger** + Flask attache le sien → chaque ligne loguée deux fois
+   - Bruit dans les logs, rend le debug plus dur
+
+6. **Confusion run.sh vs run_v4.sh**
+   - `run.sh` lance frontend legacy port 3000 (via webpack react-scripts) + app.py
+   - `run_v4.sh` lance frontend_v4 port 3002 + app.py
+   - Les deux coexistent, Dom peut cliquer sur l'un ou l'autre sans savoir
+   - `launch.sh` mentionné dans le README **n'existe pas** (README obsolète)
+
+7. **Workflow « Unnamed Workflow »**
+   - Les JSON Léa ont souvent `"name": "Unnamed Workflow"` (cf. `notepad_enriched.json`)
+   - L'import les reprend tel quel — la liste du VWB devient illisible vite
+
+8. **Tests d'intégration VWB datent de janvier**
+   - `tests/integration/test_vwb_*.py` : 6 fichiers
+   - `tests/property/test_vwb_frontend_v2_*` : 14 fichiers — ciblent `frontend/` (v2), pas `frontend_v4/`
+   - Aucun test cible le pont learned_workflows → pas de garde-fou pour C2
+
+### Dette technique identifiable
+
+- **3 backends Flask** (`app.py`, `app_lightweight.py`, `app_catalogue_simple.py`) pour 403 + 1451 + 1370 lignes = 3224 lignes. Un seul tourne.
+- **2 frontends** (`frontend/` = react-scripts v2, `frontend_v4/` = Vite v4) avec duplication partielle des composants — seul le v4 est vivant
+- **2 bases SQLite** nommées différemment, schéma identique
+- **`catalog_routes.py.backup_20260122_163105`** (127 Ko) traîne dans le repo
+- Screenshots `.screenshot2026-*.png` (8 fichiers × ~220 Ko) traînent à la racine backend
+- Migrations Alembic présentes mais **un seul fichier** (`001_initial_schema.py`) alors que le schéma a évolué (`review_status` ajouté après)
+
+---
+
+## Section B — Quick wins (< 1 jour chacun)
+
+Classés par ratio impact/effort décroissant :
+
+### B1. 🔥 Migrer la bibliothèque de captures de `sessionStorage` vers `localStorage`
+**Effort** : 30 min
+**Impact** : résout le bug principal rapporté par Dom
+- Remplacer `sessionStorage.*` par `localStorage.*` dans `CaptureLibrary.tsx` et `CapturePanel.tsx`
+- Unifier sur une seule clé `captureLibrary_v3` (migration ascendante depuis les deux anciennes)
+- Augmenter le cap à 200 captures + ajouter un bouton « vider la bibliothèque »
+- Attention : `localStorage` plafonne ~5 Mo, les PNG base64 saturent vite — **meilleure option** : persister côté backend via `/api/v3/capture/library` (ajout d'une petite table) et ne garder que des IDs+thumbnails en localStorage
+
+### B2. 🔥 Renommer le fichier « Unnamed Workflow » à l'import
+**Effort** : 20 min
+**Impact** : moyen (lisibilité immédiate dans la liste)
+- `api_v3/learned_workflows.py` l.210 : si `wf_meta["name"] == "Unnamed Workflow"` → `f"Appris {datetime:%d/%m %H:%M}"`
+- Idem exposer ce nom dans `WorkflowSelector.tsx` ligne 120 quand on affiche la liste learned
+
+### B3. Supprimer la BDD fantôme
+**Effort** : 15 min
+**Impact** : élimine un foot-gun discret
+- Modifier `app.py` l.47 : défaut `'sqlite:///workflows.db'` (aligné sur `.env`)
+- Supprimer `backend/instance/vwb_v3.db` + `visual_workflow_builder/instance/workflows.db` (vestige)
+- Documenter dans le `.env.example` le chemin absolu recommandé
+
+### B4. Corriger le double logging
+**Effort** : 15 min
+**Impact** : faible (quality-of-life debug)
+- `app.py` l.40 : remplacer `logging.getLogger().addHandler(...)` par `app.logger.addHandler(...)` et `logging.getLogger('werkzeug').addHandler(...)`, puis `propagate = False`
+
+### B5. Supprimer le 404 `/api/correction-packs/stats`
+**Effort** : 20 min
+**Impact** : faible (erreurs dans la console navigateur)
+- Option A (propre) : stubber la route dans `api/correction_packs.py` qui retourne `{"success": true, "stats": {"total": 0}}`
+- Option B : retirer l'appel côté `frontend/src/hooks/useCorrectionPacks.ts` ligne 229
+- Option B préférable si le frontend legacy est condamné (voir E1)
+
+### B6. Nettoyer les fichiers parasites
+**Effort** : 10 min
+**Impact** : cosmétique + réduire la confusion
+- Supprimer `backend/catalog_routes.py.backup_20260122_163105` (127 Ko)
+- Supprimer les 8 screenshots `.screenshot2026-*.png` à la racine backend
+- `.gitignore` : ajouter `*.screenshot*.png`, `*.backup_*`
+
+### B7. Clarifier run.sh
+**Effort** : 20 min
+**Impact** : moyen (Dom et moi perdons du temps sur quel frontend lancer)
+- Renommer `run.sh` → `run_legacy.sh` avec bandeau warning
+- Mettre à jour `README.md` du VWB pour refléter `run_v4.sh` comme canonique
+- Supprimer la mention `launch.sh` qui n'existe pas
+
+**Total Quick Wins : ~2h30 de dev** pour résoudre la douleur principale + 4 dettes visibles.
+
+---
+
+## Section C — Chantiers moyens (1-3 jours)
+
+### C1. Finaliser le flux « Import Léa → review VWB → replay »
+**Effort** : 1 jour
+**Contexte** : toute la plomberie existe (backend+frontend), mais la boucle n'est pas testée end-to-end depuis le premier replay réussi du 13 avril. Actuellement `source='learned_import'` déclenche bien `review_status='pending_review'`, mais :
+- Le frontend n'a **pas de banner** « ⚠ 2 workflows importés en attente de review » visible au démarrage (il y a bien un `pendingReviewCount` dans `App.tsx` mais je n'ai pas vérifié son affichage)
+- Quand Dom ouvre un workflow en `pending_review`, aucun indicateur visuel sur les étapes automatiquement générées par le bridge (ex: warning sur les `compound` décomposés, warning sur les `by_position` convertis en `x_pct/y_pct`)
+- Pas de bouton « rejouer le workflow tel quel sans review » pour tester vite
+
+**Actions** :
+1. Vérifier l'affichage `pendingReviewCount` dans le header + ajouter un badge coloré
+2. Dans `StepNode.tsx`, afficher un ⚠️ quand `step.parameters.compound_steps` existe ou quand `metadata.core_edge_id` manque d'info
+3. Exposer les `warnings` retournés par l'import dans un panneau dépliant sur le workflow importé
+4. Bouton « Valider et exécuter » qui passe `review_status='approved'` puis lance le replay via `/execute`
+
+### C2. Persister la bibliothèque de captures côté serveur
+**Effort** : 1,5 jour
+**Contexte** : extension de B1 si on veut une bibliothèque réellement persistante et partagée entre sessions/machines
+- Nouvelle table `captures_library(id, screenshot_b64, timestamp, label, favorite, workflow_id NULL)`
+- Endpoints `GET/POST/DELETE /api/v3/captures/library`
+- `CaptureLibrary.tsx` : fetch initial + mutations, plus de localStorage
+- Bonus : associer une capture à un step (fav pour référence future)
+
+### C3. Unifier les deux frontends — retirer `frontend/` (legacy)
+**Effort** : 2 jours (avec vérif de non-régression)
+**Contexte** : `frontend/` (v2 React 19 + MUI + Redux) n'est plus maintenu, `frontend_v4/` (Vite + xyflow) est la cible. 14 tests `tests/property/test_vwb_frontend_v2_*` pointent vers le v2.
+- Auditer ce que le v4 ne fait pas encore (CorrectionPacksDashboard, CoachingPanel, etc.) → décider si on porte ou si on abandonne
+- Archiver `frontend/` dans `_archives/` ou le supprimer
+- Désactiver `run.sh` ou le refaire pointer sur v4
+- Porter ou supprimer les tests `test_vwb_frontend_v2_*`
+
+### C4. Consolider les 3 `app*.py`
+**Effort** : 1 jour
+**Contexte** : `app.py` est le seul utilisé pour le VWB. `app_lightweight.py` sert uniquement à l'endpoint catalogue VLM sur 5003 (un seul endpoint utile). `app_catalogue_simple.py` n'est plus référencé.
+- Supprimer `app_catalogue_simple.py`
+- Déplacer le seul endpoint utile de `app_lightweight.py` dans `app.py` + retirer le port 5003 de `services.conf`
+- Supprimer `app_lightweight.py`
+- Gain : -2800 lignes, un seul point d'entrée
+
+### C5. Lier étape VWB ↔ screenshot source du workflow Léa
+**Effort** : 2 jours
+**Contexte** : actuellement quand on importe un workflow Léa, les steps sont **des actions sans contexte visuel**. Pour pouvoir « corriger visuellement » (idée Dom), il faut que chaque step affiche :
+- Le screenshot `from_node` (état avant l'action)
+- Le screenshot `to_node` (état après)
+- Les bbox cliquées (target)
+- Les workflows Léa contiennent déjà des `screenshot_hash` dans leurs nodes (à vérifier dans `notepad_enriched.json`)
+- Modifier `convert_learned_to_vwb_steps` pour persister les screenshots en tant que `VisualAnchor` + `anchor_id` sur le step
+- Enrichir `StepNode.tsx` pour afficher la vignette
+
+**Note** : c'est ce qui donne du sens à l'idée de Dom. Sans ça, l'import Léa→VWB donne des étapes abstraites « click(x=42%, y=68%) » que personne ne peut corriger visuellement.
+
+---
+
+## Section D — Chantiers lourds (>1 semaine)
+
+### D1. Refonte du stockage workflow : un seul format canonique
+**Effort** : 1-2 semaines
+**Justification** : aujourd'hui on a 2 formats (core JSON de Léa vs SQLite VWB) avec un bridge. Le bridge perd de l'information (ex: `compound` décomposé, metadata core/screenshots abandonnés en route). À chaque nouvelle feature du core (C2 aujourd'hui, grounding, extraction, etc.) il faut mettre à jour le bridge.
+
+**Proposition** : VWB stocke directement le format core JSON (ou un surset strict). Les « steps » VWB deviennent une **vue dérivée** du graphe core, pas une copie. Les corrections humaines modifient le JSON core.
+
+**À faire seulement si** l'import Léa→VWB devient un flux majeur et que le bridge montre ses limites. Pour l'instant, le bridge fait le job.
+
+### D2. Mode collaboratif / multi-utilisateurs
+**Effort** : 2-3 semaines
+**Justification** : aucune pour aujourd'hui. Dom est seul à utiliser le VWB. À garder dans le coin de la tête pour quand les premiers clients testeront.
+
+---
+
+## Section E — Non-décisions
+
+Choses qu'on **ne fera pas**, pour se prémunir des tentations.
+
+### E1. Ne PAS réécrire le frontend en v5
+Pourquoi : le v4 Vite+xyflow est récent (mars 2026), propre, bien structuré. Pas de raison architecturale. La migration v3→v4 a déjà coûté cher (cf. nombreux `CORRECTION_TYPESCRIPT_*.md` en janvier).
+
+### E2. Ne PAS unifier `instance/*.db` en PostgreSQL
+Pourquoi : SQLite convient pour un outil desktop mono-utilisateur. PostgreSQL ajoute une dépendance runtime sans valeur tangible tant qu'on est seul. Le `.env` mentionne déjà l'option, gardée pour plus tard.
+
+### E3. Ne PAS porter CorrectionPacksDashboard sur le v4
+Pourquoi : la fonctionnalité « correction packs » est en doublon conceptuel avec le nouveau flux `review_status` + `learned_workflow_bridge`. Autant fermer proprement correction_packs (C4 bis) plutôt que le migrer.
+
+### E4. Ne PAS rajouter de tests property pour le v4 tout de suite
+Pourquoi : 14 tests `test_vwb_frontend_v2_*` existent déjà et ne tournent plus (pointent vers le v2). Avant de recréer des tests property, il faut décider si on garde le v2 ou pas (C3). Refaire 14 tests pour les jeter dans 2 semaines = gâchis.
+
+### E5. Ne PAS implémenter le mode WebSocket realtime pour le VWB
+Pourquoi : le polling actuel (500 ms dans `App.tsx`) suffit pour l'usage. WebSocket existe déjà (`socketio`) mais n'est câblé nulle part dans le v4. On peut l'ajouter quand une vraie feature le demande (ex: collaborative editing = E1/D2 → pas maintenant).
+
+---
+
+## Section F — Recommandation d'ordre
+
+**Semaine 1 — quick wins utilisateur (jour J)**
+1. B1 — localStorage pour CaptureLibrary (30 min) → résout le bug principal
+2. B2 — nom lisible à l'import (20 min) → la liste devient utilisable
+3. B3 — supprimer BDD fantôme (15 min) → évite un bug futur
+4. B6 — nettoyer les fichiers parasites (10 min) → hygiène
+5. B7 — clarifier run.sh (20 min) → moins de confusion
+
+Total : ~2h de dev pour un retour utilisateur net dès demain.
+
+**Semaine 1 — chantier moyen utile (jours J+1 à J+3)**
+6. C1 — finaliser le flux « Import Léa → review → replay ». C'est la VALEUR DIRECTE de l'idée de Dom : « importer les workflows Léa pour les corriger visuellement ».
+
+**Semaine 2 — étendre la valeur (si C1 tient la route)**
+7. C5 — lier step ↔ screenshot source. C'est ce qui transforme le VWB en **vrai outil de correction visuelle**. Sans ça, l'import Léa est abstrait.
+
+**Semaine 3+ — consolidation (quand bande passante)**
+8. C3 — retirer frontend legacy (gain de clarté)
+9. C4 — consolider les 3 `app*.py` (gain dette)
+10. C2 — bibliothèque captures serveur (si B1 montre ses limites)
+
+**Justification globale** :
+- **Les 2h de quick wins** donnent à Dom une expérience visible et immédiate (bibliothèque qui ne s'efface plus, liste lisible, moins de bruit).
+- **C1** capitalise sur l'investissement existant (le pont Léa/VWB est déjà codé à 80%, il faut juste finir le dernier kilomètre — les warnings visuels et le bouton « valider et exécuter »).
+- **C5** est le vrai game-changer pour l'idée de Dom, mais ne vaut le coup que si C1 a confirmé que le flux globalement fonctionne. Si C1 révèle que le bridge perd trop d'info, on saute direct à D1 (refonte).
+- **C3/C4** sont de la dette : on s'en occupe quand on a quelqu'un sous la main pour pas ralentir les features.
+
+**À éviter** : commencer par C3 ou C4 (dette) parce qu'aucun impact utilisateur visible → pas de ROI court terme.
+
+---
+
+## Risques identifiés
+
+- **Backup BDD** : `backend/instance/backups/` contient un seul backup du 23/01. Aucune rotation automatique. Risque de perte : 3 workflows seulement mais ce sont ceux de Dom → ajouter un backup quotidien via `backup_ssd.sh` (déjà existant à la racine `~/ai/`).
+- **`localStorage` quota** : B1 seul ne suffira pas à long terme. Prévoir C2 si Dom fait plus de 50-100 captures en PNG base64.
+- **Modèle `Workflow` sans cascade sur source='learned_import'** : si Dom supprime un workflow importé, rien ne met à jour le JSON core sur disque → divergence. Acceptable tant que l'import est monodirectionnel (disque → VWB) mais à surveiller.
+
+---
+
+## Métriques de succès
+
+- Bibliothèque persiste après reload navigateur : testable manuellement en 30 s
+- Liste de workflows ne contient plus « Unnamed Workflow » : testable via SQL
+- Un workflow Léa importé a un badge « à réviser » visible, et le bouton « Valider et exécuter » le fait tourner sans quitter le VWB
+- 0 warning 404 dans `backend/logs/vwb.log` après B5
+- `run_v4.sh` unique script documenté dans README
--- a/docs/PLAN_TEST_HUMAIN_16AVRIL.md
+++ b/docs/PLAN_TEST_HUMAIN_16AVRIL.md
@@ -0,0 +1,566 @@
+# Plan de test humain — 16 avril 2026 matin
+
+**Cible** : valider le nouveau ZIP Léa (Lea_v1.0.0.zip reconstruit avec C2 + enrichissement UI + fail-safe UAC + enrollment fleet) sur la VM Windows 11.
+
+**Durée estimée** : 45 min si tout passe, 1h30 si un test bloque.
+**Principe général** : tests du plus simple au plus complexe. Ne pas sauter d'étape, chaque test dépend du précédent.
+
+---
+
+## Section 1 — Pré-requis (checklist 5 min)
+
+### 1.1 — Côté serveur Linux (poste Dom)
+
+Ouvrir un terminal et vérifier dans l'ordre :
+
+```bash
+cd /home/dom/ai/rpa_vision_v3
+
+# 1) Services up (systemd user)
+./svc.sh status
+
+# On doit voir actifs au minimum :
+#   streaming (5005) — OBLIGATOIRE
+#   dashboard (5001) — OBLIGATOIRE
+#   api (8000)       — utile mais pas bloquant
+#   vwb-backend (5002), vwb-frontend (3002) — pour regarder les workflows enrichis
+
+# 2) Ollama tourne avec le modèle VLM attendu
+curl -s http://localhost:11434/api/tags | grep -E "gemma4|ui-tars|qwen" | head -5
+
+# 3) Token API effectif (doit correspondre à celui de config.txt sur la VM)
+grep -E "^RPA_API_TOKEN" .env .env.local 2>/dev/null | head -2
+# Attendu : 86031addb338e449fccdb1a983f61807aec15d42d482b9c7748ad607dc23caab
+
+# 4) Endpoint streaming répond
+curl -s http://localhost:5005/health | head
+# Attendu : {"status":"ok",...}
+
+# 5) Dashboard répond (401 attendu sans auth — c'est la preuve que l'auth est active)
+curl -sI http://localhost:5001/ | head -3
+# Attendu : HTTP/1.1 401 Unauthorized + WWW-Authenticate: Basic
+
+# 6) Endpoint fleet accessible (sans auth — c'est un endpoint API_TOKEN)
+curl -s http://localhost:5005/api/v1/agents/fleet | head -200
+# Attendu : JSON avec active/uninstalled/total_active/total_uninstalled
+```
+
+**Si un service est down** : `./svc.sh start <nom>` puis `./svc.sh logs <nom>` pour vérifier.
+
+### 1.2 — Accès exposé Internet (à tester depuis la VM)
+
+- `https://lea.labs.laurinebazin.design/health` → doit renvoyer 200 OK (proxy NPM → streaming 5005)
+- `https://vwb.labs.laurinebazin.design/` → challenge auth Basic `lea` / `Medecin2026!`
+
+### 1.3 — Côté VM Windows
+
+- VM démarrée, session Windows 11 ouverte (compte local, pas domaine)
+- Accès RDP ou console (Spice) fonctionnel
+- Internet OK sur la VM : ouvrir Edge, faire `https://lea.labs.laurinebazin.design/health`, doit renvoyer `ok`
+- **Si aucune instance Léa précédente installée** : rien à faire.
+- **Si une instance Léa précédente est déjà installée** : noter le chemin (`C:\rpa_vision\` ou `C:\Lea\`) et **conserver `config.txt`** à portée de main pour restaurer le token.
+
+### 1.4 — Fichiers à avoir sous la main
+
+Sur le poste Dom, dans `~/ai/rpa_vision_v3/deploy/` :
+
+- `Lea_v1.0.0.zip` (ZIP fraîchement reconstruit — vérifier la date : `ls -la deploy/Lea_v1.0.0.zip`)
+- `lea_package/config.txt` (référence si on veut vérifier le contenu attendu)
+- `lea_package/LISEZMOI.txt` (pour référence utilisateur)
+
+**Commande utile** pour vérifier la fraîcheur du ZIP :
+```bash
+ls -la /home/dom/ai/rpa_vision_v3/deploy/Lea_v1.0.0.zip
+unzip -l /home/dom/ai/rpa_vision_v3/deploy/Lea_v1.0.0.zip | head -20
+```
+
+---
+
+## Section 2 — Déploiement du nouveau ZIP sur la VM (10 min)
+
+### 2.1 — Transférer le ZIP sur la VM
+
+**Option A — Drag & drop VirtualBox/VMware** : déposer `Lea_v1.0.0.zip` dans `C:\Users\<user>\Downloads\`.
+
+**Option B — scp (si SSH actif sur la VM)** :
+```bash
+scp /home/dom/ai/rpa_vision_v3/deploy/Lea_v1.0.0.zip user@192.168.x.x:/C:/Users/<user>/Downloads/
+```
+
+**Option C — navigateur** : depuis la VM, aller sur `https://vwb.labs.laurinebazin.design/downloads/Lea_v1.0.0.zip` (si exposé — sinon utiliser A ou B).
+
+### 2.2 — Arrêter l'instance Léa existante (si présente)
+
+Sur la VM, ouvrir un terminal PowerShell ou cmd :
+
+```cmd
+:: Chercher le lock de l'ancienne instance
+type C:\rpa_vision\lea_agent.lock
+:: Si un PID apparaît, le tuer proprement :
+taskkill /F /PID <PID_affiché>
+
+:: Vérifier qu'aucun pythonw.exe Lea ne tourne plus
+tasklist | findstr pythonw
+```
+
+Ne JAMAIS faire `taskkill /F /IM pythonw.exe` (tuerait Jupyter, Anaconda, etc.).
+
+### 2.3 — Sauvegarder l'ancien config.txt
+
+```cmd
+copy C:\rpa_vision\config.txt C:\Users\<user>\Desktop\config.txt.backup
+```
+
+### 2.4 — Extraire le nouveau ZIP
+
+```cmd
+:: Renommer l'ancien dossier (rollback si besoin)
+ren C:\rpa_vision C:\rpa_vision_old_16avril
+
+:: Extraire le ZIP via l'explorateur (clic droit → Extraire tout → C:\rpa_vision)
+:: OU via PowerShell :
+powershell -command "Expand-Archive -Path C:\Users\<user>\Downloads\Lea_v1.0.0.zip -DestinationPath C:\rpa_vision -Force"
+```
+
+### 2.5 — Restaurer le token dans config.txt
+
+Ouvrir `C:\rpa_vision\config.txt` dans Notepad et vérifier :
+
+```
+RPA_SERVER_URL=https://lea.labs.laurinebazin.design/api/v1
+RPA_API_TOKEN=86031addb338e449fccdb1a983f61807aec15d42d482b9c7748ad607dc23caab
+RPA_SERVER_HOST=lea.labs.laurinebazin.design
+RPA_BLUR_SENSITIVE=false
+```
+
+**Important** : le token doit correspondre à celui du serveur (cf. Section 1.1 étape 3).
+
+### 2.6 — Premier lancement
+
+Double-cliquer sur `C:\rpa_vision\install.bat` (si premier déploiement — crée `.venv`).
+
+Puis lancer `C:\rpa_vision\Lea.bat`. Une console s'ouvre 3 secondes, puis une icône apparaît dans la zone de notification Windows (près de l'horloge).
+
+**Preuve que ça tourne** :
+- Fichier `C:\rpa_vision\lea_agent.lock` contient un PID
+- `tasklist | findstr pythonw` retourne au moins une ligne
+
+Si rien n'apparaît, voir Section 4 (diagnostic).
+
+---
+
+## Section 3 — Tests fonctionnels (ordre important)
+
+### Test 1 — Baseline + streaming + enrollment (objectifs 1, 2, 8)
+
+**Pré-conditions** : Léa vient de démarrer sur la VM, icône visible dans systray.
+
+**Actions** :
+1. Côté Dom, lancer un watch sur les logs streaming :
+   ```bash
+   ./svc.sh logs streaming -f
+   ```
+2. Côté VM, clic droit sur l'icône Léa → "Apprenez-moi une tâche" (ou équivalent dans le menu).
+3. Faire une action triviale : ouvrir le menu Démarrer, taper `notepad`, valider.
+4. Clic droit sur Léa → "C'est terminé".
+
+**Observations attendues** côté serveur :
+- `[STREAM] register session_id=...` dès le démarrage
+- `[STREAM] event ...` pour chaque click/touche
+- `[STREAM] image ...` pour chaque screenshot (un par action)
+- `[FLEET] Agent enrolé (created) : machine_id=...` au premier lancement uniquement
+
+**Critères de succès** :
+- La session apparaît dans :
+  ```bash
+  curl -s http://localhost:5005/api/v1/traces/stream/sessions | python3 -m json.tool | head -40
+  ```
+- L'agent apparaît dans `/fleet` :
+  ```bash
+  curl -s http://localhost:5005/api/v1/agents/fleet | python3 -m json.tool
+  ```
+  → `total_active >= 1`, avec `machine_id`, `hostname`, `version`, `enrolled_at` récent.
+
+**Critères d'échec** :
+- Aucun log streaming → voir Section 4 lignes "Token invalide" / "Agent ne démarre pas"
+- Événements reçus mais pas d'image → voir Section 4 "images non streamées"
+
+---
+
+### Test 2 — Auth dashboard (objectif 7)
+
+**Pré-conditions** : dashboard service up (cf. 1.1).
+
+**Actions depuis la VM** :
+1. Ouvrir `https://vwb.labs.laurinebazin.design/` → challenge Basic Auth → saisir `lea` / `Medecin2026!`
+2. Ouvrir le dashboard local (si exposé) ou tester en direct depuis Dom :
+   ```bash
+   curl -s -u lea:changeme-dashboard-Medecin2026! http://localhost:5001/ | head -20
+   ```
+
+**Critère de succès** : page HTML renvoyée (pas de 401).
+
+**Critère d'échec** : 401 persistant → vérifier `DASHBOARD_PASSWORD` dans l'env systemd :
+```bash
+systemctl --user show rpa-vision-v3-dashboard | grep DASHBOARD_PASSWORD
+```
+
+---
+
+### Test 3 — Enrichissement UI côté serveur (objectif 3, C2)
+
+**Pré-conditions** : Test 1 exécuté, session créée et finalisée.
+
+**Actions** :
+```bash
+# Récupérer l'ID de la dernière session
+SESS=$(curl -s http://localhost:5005/api/v1/traces/stream/sessions | \
+       python3 -c "import json,sys; d=json.load(sys.stdin); print(d[-1]['session_id'])")
+echo "Session : $SESS"
+
+# Récupérer la session détaillée (doit contenir les ScreenStates enrichis)
+curl -s "http://localhost:5005/api/v1/traces/stream/session/$SESS" \
+  | python3 -m json.tool > /tmp/sess_16avril.json
+wc -l /tmp/sess_16avril.json
+```
+
+**Vérifier le contenu des ScreenStates persistés** :
+```bash
+# Les ScreenStates JSON sont sauvegardés sous data/screen_states/<YYYY-MM-DD>/
+find /home/dom/ai/rpa_vision_v3/data/screen_states -name "state_*.json" -newer /tmp/sess_16avril.json -type f 2>/dev/null | head -5
+
+# Pour un fichier donné, vérifier ui_elements ET detected_text non vides
+LAST_STATE=$(find /home/dom/ai/rpa_vision_v3/data/screen_states -name "state_*.json" -type f -printf '%T@ %p\n' | sort -n | tail -1 | awk '{print $2}')
+python3 -c "
+import json
+d = json.load(open('$LAST_STATE'))
+print('ui_elements count:', len(d.get('ui_elements', [])))
+print('detected_text len:', len(d.get('detected_text', '')))
+print('sample ui_element:', d.get('ui_elements', [{}])[0] if d.get('ui_elements') else 'NONE')
+"
+```
+
+**Critères de succès** :
+- `ui_elements count >= 3` sur un écran normal (Notepad ouvert ~5-15 éléments)
+- `detected_text len > 20` (le texte OCR doit contenir des mots lisibles)
+- Au moins un `ui_element` avec un `role` rempli (`button`, `textbox`, `menu`, etc.)
+
+**Critère d'échec** : `ui_elements count == 0` partout → C2 ne tourne pas côté serveur. Vérifier logs `./svc.sh logs streaming | grep -iE "detect|ocr|screen_analyzer"`.
+
+---
+
+### Test 4 — Target resolution (objectifs 4, C1 + Lot E)
+
+**Pré-conditions** : une session Test 1 réussie, avec au moins 2-3 actions.
+
+**Actions** — demander un replay via l'endpoint :
+```bash
+curl -s -X POST http://localhost:5005/api/v1/traces/stream/replay \
+  -H "Authorization: Bearer 86031addb338e449fccdb1a983f61807aec15d42d482b9c7748ad607dc23caab" \
+  -H "Content-Type: application/json" \
+  -d "{\"session_id\": \"$SESS\", \"mode\": \"dry_run\"}" \
+  | python3 -m json.tool > /tmp/replay_plan.json
+```
+
+**Vérifications** :
+```bash
+# Le plan doit contenir des TargetSpec avec by_role / by_text, pas juste des coordonnées
+grep -E "\"by_role\"|\"by_text\"" /tmp/replay_plan.json | head -10
+grep -E "\"unknown_element\"" /tmp/replay_plan.json | wc -l
+```
+
+**Critères de succès** :
+- Au moins 50% des `TargetSpec` ont un `by_role` OU un `by_text` non null
+- Moins de 20% des cibles sont marquées `unknown_element`
+
+**Critère d'échec** : 100% `unknown_element` → target_resolver ne lit pas les `ui_elements`. Relire logs streaming pour erreurs d'import.
+
+---
+
+### Test 5 — Cache context-aware (objectif 5, Lot D)
+
+**But** : s'assurer que deux workflows différents sur le même écran ne partagent pas le cache de target resolution.
+
+**Actions** (simplifié — pas de test unitaire ici, juste observation) :
+1. Côté VM, enregistrer une session 1 : ouvrir Bloc-notes, cliquer sur menu "Fichier" → "Nouveau".
+2. Arrêter l'enregistrement ("C'est terminé").
+3. Redémarrer un enregistrement (session 2) : même écran Bloc-notes, mais cliquer "Fichier" → "Enregistrer".
+4. Arrêter.
+
+**Vérifications côté serveur** :
+```bash
+./svc.sh logs streaming | grep -iE "cache_key|cache hit|context_hints" | tail -20
+```
+
+**Critère de succès** : les `cache_key` des deux sessions diffèrent même si le ScreenState est similaire (le `context_hints` dans la clé fait la différence).
+
+**Critère d'échec** : même `cache_key`, même résultat → bug Lot D. Pas bloquant pour la démo mais à noter.
+
+---
+
+### Test 6 — Fail-safe UAC (objectif 6, P0-D)
+
+**But** : un popup UAC bloque le replay proprement.
+
+**Actions** :
+1. Côté VM, lancer un replay d'une session existante (Test 4 ci-dessus).
+2. **Pendant l'exécution**, faire clic droit sur un `.exe` nécessitant élévation → "Exécuter en tant qu'administrateur" → le popup UAC apparaît.
+3. **Ne pas cliquer** sur le UAC.
+
+**Observations attendues** :
+- Côté VM : Léa arrête toute action (pas de clic sur UAC)
+- Côté serveur, logs :
+  ```bash
+  ./svc.sh logs streaming | grep -iE "UAC|CredUI|SmartScreen|paused_need_help" | tail -5
+  ```
+  → messages du type `paused_need_help` ou `élévation de privilèges (UAC) détectée`
+
+**Critère de succès** :
+- Aucun clic envoyé sur la fenêtre UAC
+- Le replay passe en `status: paused_need_help`
+- Un appel `curl .../replay/<replay_id>` montre bien ce statut
+
+**Critère d'échec critique** : Léa clique sur "Oui" / "Non" de l'UAC → **arrêter immédiatement les tests**, c'est une régression de sécurité.
+
+**Cleanup** : fermer manuellement le popup UAC (clic sur Non).
+
+---
+
+### Test 7 — Blur PII côté serveur (objectif 9)
+
+**But** : vérifier que les screenshots contenant des noms/mails sont bien floutés côté serveur.
+
+**Actions côté VM** :
+1. Ouvrir Bloc-notes, écrire :
+   ```
+   Patient : Jean Dupont
+   Né le 12/03/1980
+   Tél : 06 12 34 56 78
+   Email : jean.dupont@test.fr
+   ```
+2. Lancer un enregistrement court via le menu Léa.
+3. Faire 2-3 clics dans Bloc-notes (scroll, sélection).
+4. Arrêter.
+
+**Vérifications côté serveur** :
+```bash
+# Chercher les paires _raw / _blurred dans la session
+SESS_DIR=$(find /home/dom/ai/rpa_vision_v3/data -type d -name "$SESS*" 2>/dev/null | head -1)
+ls -la "$SESS_DIR"/*.png 2>/dev/null | grep -E "_blurred|_raw" | head -10
+
+# Comparer les tailles — le _blurred doit exister
+find /home/dom/ai/rpa_vision_v3/data -name "*_blurred.png" -newer /tmp/sess_16avril.json 2>/dev/null | head -5
+```
+
+**Critères de succès** :
+- Au moins un fichier `*_blurred.png` présent pour cette session
+- Ouvert dans un viewer, les zones "Jean Dupont", "06 12 34...", "jean.dupont@..." sont floutées/boxées
+- Le fichier `*_raw.png` reste net (destiné à l'entraînement)
+
+**Critère d'échec** : aucun `_blurred.png` généré → module `core/anonymisation/pii_blur.py` pas appelé. Vérifier les logs avec `grep -i "pii_blur\|anonymisation"`.
+
+---
+
+### Test 8 — Logs d'audit (objectif 10)
+
+**Actions** :
+```bash
+# Vérifier que le fichier JSONL du jour existe et se remplit
+ls -la /home/dom/ai/rpa_vision_v3/data/audit/audit_2026-04-16.jsonl
+tail -5 /home/dom/ai/rpa_vision_v3/data/audit/audit_2026-04-16.jsonl | python3 -m json.tool
+
+# Endpoint d'audit (API_TOKEN requis si sécurisé — ici en dev)
+curl -s "http://localhost:5005/api/v1/audit/history?limit=5" \
+  | python3 -m json.tool | head -60
+
+# Summary du jour
+curl -s "http://localhost:5005/api/v1/audit/summary?date=2026-04-16" \
+  | python3 -m json.tool
+```
+
+**Critères de succès** :
+- Fichier `audit_2026-04-16.jsonl` existe
+- Chaque ligne contient `timestamp`, `session_id`, `action_id`, `machine_id`, `action_type`, `result`
+- Le `machine_id` correspond à la VM (pas "Unknown")
+
+**Critère d'échec** : fichier inexistant → `AuditTrail` pas initialisé. Vérifier logs streaming au démarrage.
+
+---
+
+### Test 9 (bonus si temps) — Replay E2E complet sur Bloc-notes
+
+**But** : valider la chaîne complète apprentissage → replay réussi.
+
+**Actions** :
+1. Sur la VM, enregistrer : ouvrir Bloc-notes depuis le menu Démarrer → taper "Hello Lea 16 avril" → Fichier → Enregistrer sous → Bureau → Nom "test_lea.txt" → Enregistrer.
+2. Arrêter l'enregistrement.
+3. Fermer Bloc-notes et supprimer le fichier créé.
+4. Lancer le replay depuis le menu Léa (ou via API curl Test 4 sans `dry_run`).
+
+**Critères de succès** :
+- Bloc-notes s'ouvre tout seul
+- Le texte est tapé (attention AZERTY : si c'est Qwerty côté VM, possible que "Lea" sorte en "Léq" — noter mais pas bloquant)
+- Le fichier `test_lea.txt` est créé sur le Bureau
+- Statut replay final : `completed`
+
+---
+
+## Section 4 — Diagnostic rapide
+
+| # | Symptôme | Cause probable | Comment vérifier | Fix rapide |
+|---|----------|----------------|------------------|------------|
+| 1 | Léa ne démarre pas (pas d'icône systray) | `.venv` absent ou install interrompue | `dir C:\rpa_vision\.venv\Scripts\python.exe` | Relancer `install.bat` |
+| 2 | Léa démarre puis crash (console ferme) | Erreur Python au boot | Lancer à la main : `C:\rpa_vision\.venv\Scripts\python.exe C:\rpa_vision\run_agent_v1.py` → lire la stack trace | Selon l'erreur : check deps, check `config.txt`, check `RPA_SERVER_URL` |
+| 3 | Agent tourne mais rien n'arrive côté serveur | Mauvais `RPA_SERVER_URL` / firewall / DNS | Sur la VM : `curl https://lea.labs.laurinebazin.design/health` | Corriger URL dans `config.txt`, relancer `Lea.bat` |
+| 4 | 401 Unauthorized côté serveur | Token différent entre VM et serveur | `grep RPA_API_TOKEN C:\rpa_vision\config.txt` vs `grep RPA_API_TOKEN /home/dom/ai/rpa_vision_v3/.env.local` | Aligner les deux, relancer `Lea.bat` et `./svc.sh restart streaming` |
+| 5 | Popup UAC → Léa clique dessus | **RÉGRESSION CRITIQUE** | Voir logs `grep -i UAC` côté serveur | **Arrêter le test**, remonter à Dom |
+| 6 | `total_active == 0` dans /fleet | Enrollment jamais déclenché ou échoué | Logs streaming : `grep FLEET` | Vérifier que le build contient `agent_registry.py` côté client + relancer |
+| 7 | `ui_elements = []` dans les ScreenStates | C2 pas appelé ou Ollama down | `curl http://localhost:11434/api/tags` + logs streaming `grep -i detector` | Relancer Ollama : `systemctl --user restart ollama` |
+| 8 | `by_role`/`by_text` tous null | TargetSpecBuilder ne lit pas les UIElements | Logs streaming `grep -i target_spec` | Bug code — noter et passer au test suivant |
+| 9 | Aucun `_blurred.png` | `pii_blur.py` pas appelé | Logs : `grep -i "blur\|anonymisation"` | Vérifier que les imports côté serveur passent |
+| 10 | Replay planté sans erreur claire | Session incomplète, pas de workflow compilé | `curl .../workflow/compile` en direct | Re-enregistrer une nouvelle session plus courte |
+
+### Commandes debug utiles (à garder sous la main)
+
+```bash
+# État global
+./svc.sh status
+./status.sh
+
+# Logs live streaming
+./svc.sh logs streaming -f
+
+# Dernière session streamée
+curl -s http://localhost:5005/api/v1/traces/stream/sessions | python3 -m json.tool | tail -30
+
+# Dernier screenshot reçu (ordre décroissant)
+ls -lt /home/dom/ai/rpa_vision_v3/data/streaming_sessions/*.json | head -3
+
+# Audit du jour
+tail -f /home/dom/ai/rpa_vision_v3/data/audit/audit_2026-04-16.jsonl
+
+# Base fleet
+sqlite3 /home/dom/ai/rpa_vision_v3/data/databases/rpa_data.db \
+  "SELECT machine_id, user_name, hostname, version, status, enrolled_at FROM enrolled_agents;"
+```
+
+---
+
+## Section 5 — Grille d'observation C2 (enrichissement UI)
+
+### Comment vérifier concrètement que C2 fonctionne
+
+**Niveau 1 — ScreenState persisté** :
+```bash
+LAST_STATE=$(find /home/dom/ai/rpa_vision_v3/data/screen_states -name "state_*.json" -type f -printf '%T@ %p\n' 2>/dev/null | sort -n | tail -1 | awk '{print $2}')
+
+python3 <<EOF
+import json
+d = json.load(open("$LAST_STATE"))
+print("screen_state_id:", d.get("screen_state_id"))
+print("ui_elements count:", len(d.get("ui_elements", [])))
+print("detected_text length:", len(d.get("detected_text", "")))
+if d.get("ui_elements"):
+    el = d["ui_elements"][0]
+    print("first element keys:", list(el.keys()))
+    print("first element role:", el.get("role"))
+    print("first element text:", el.get("text"))
+    print("first element bbox:", el.get("bbox"))
+EOF
+```
+
+**Niveau 2 — TargetSpec dans le workflow compilé** :
+```bash
+# Récupérer un workflow compilé
+WF=$(curl -s http://localhost:5005/api/v1/traces/stream/workflows | \
+     python3 -c "import json,sys; d=json.load(sys.stdin); print(d[-1]['workflow_id'])")
+curl -s "http://localhost:5005/api/v1/traces/stream/workflow/$WF" \
+  | python3 -m json.tool > /tmp/wf.json
+
+# Compter les TargetSpec qualitatifs
+python3 <<'EOF'
+import json
+d = json.load(open("/tmp/wf.json"))
+nodes = d.get("nodes", [])
+total = len(nodes)
+with_role = sum(1 for n in nodes if (n.get("target_spec") or {}).get("by_role"))
+with_text = sum(1 for n in nodes if (n.get("target_spec") or {}).get("by_text"))
+unknown = sum(1 for n in nodes if (n.get("target_spec") or {}).get("by_role") in (None, "unknown_element"))
+print(f"Total nodes   : {total}")
+print(f"With by_role  : {with_role} ({100*with_role/max(total,1):.0f}%)")
+print(f"With by_text  : {with_text} ({100*with_text/max(total,1):.0f}%)")
+print(f"Unknown       : {unknown} ({100*unknown/max(total,1):.0f}%)")
+EOF
+```
+
+**Exemple de TargetSpec attendu (succès C2)** :
+```json
+{
+  "by_role": "button",
+  "by_text": "Enregistrer",
+  "by_position": {"x": 0.52, "y": 0.89},
+  "context_hints": {"near_text": "Nom du fichier"}
+}
+```
+
+**Exemple de TargetSpec dégradé (C2 ne tourne pas)** :
+```json
+{
+  "by_role": "unknown_element",
+  "by_text": null,
+  "by_position": {"x": 1024, "y": 768}
+}
+```
+
+---
+
+## Section 6 — Ce qu'on veut éviter
+
+1. **Ne pas lancer deux instances Léa en même temps sur la VM** — le lock PID suffit normalement, mais vérifier manuellement : une seule ligne `pythonw` dans `tasklist`.
+2. **Ne pas exposer le dashboard sur Internet pendant les tests** — rester sur `http://localhost:5001/` côté Dom. Le VWB exposé est OK (auth Basic), le dashboard non.
+3. **Ne jamais tester avec des données patient réelles** — c'est un POC. Utiliser uniquement des noms/codes de test ("Jean Dupont", "TestPatient01", etc.).
+4. **Ne pas interrompre un replay en cours avec Ctrl+C dans la console** — utiliser le menu Léa "Stop" pour arrêt propre (sinon le lock reste et il faut le tuer à la main).
+5. **Ne pas modifier `config.txt` pendant que Léa tourne** — la config est lue au démarrage uniquement. Redémarrer après modif.
+6. **Ne pas supprimer `C:\rpa_vision_old_16avril\`** avant d'avoir validé que la nouvelle version marche (rollback possible).
+7. **Ne pas cliquer sur le popup UAC pendant le Test 6** — c'est le but du test, le laisser apparaître et attendre que Léa s'arrête.
+8. **Ne pas toucher aux services systemd côté Dom pendant qu'un test tourne** — attendre la fin du test avant `./svc.sh restart`.
+9. **Ne pas déployer le ZIP sur la VM "prod"** — uniquement VM de test. Ce build contient des fonctionnalités non validées.
+10. **Ne pas committer le contenu de `data/audit/` ou `data/screen_states/`** — ce sont des données de test locales (screenshots + PII éventuelles).
+
+---
+
+## Annexe — URLs et chemins de référence
+
+| Ressource | URL / chemin |
+|-----------|--------------|
+| Streaming API (local) | http://localhost:5005 |
+| Streaming API (Internet) | https://lea.labs.laurinebazin.design |
+| Dashboard (local) | http://localhost:5001 (Basic auth `lea` / `changeme-dashboard-Medecin2026!` ou env `DASHBOARD_PASSWORD`) |
+| VWB (Internet) | https://vwb.labs.laurinebazin.design (Basic auth `lea` / `Medecin2026!`) |
+| Token API | `86031addb338e449fccdb1a983f61807aec15d42d482b9c7748ad607dc23caab` |
+| ZIP client | `/home/dom/ai/rpa_vision_v3/deploy/Lea_v1.0.0.zip` |
+| Sessions streaming | `/home/dom/ai/rpa_vision_v3/data/streaming_sessions/` |
+| ScreenStates persistés | `/home/dom/ai/rpa_vision_v3/data/screen_states/YYYY-MM-DD/` |
+| Audit logs | `/home/dom/ai/rpa_vision_v3/data/audit/audit_YYYY-MM-DD.jsonl` |
+| Base fleet SQLite | `/home/dom/ai/rpa_vision_v3/data/databases/rpa_data.db` (table `enrolled_agents`) |
+| Logs services | `./svc.sh logs <service>` ou `/home/dom/ai/rpa_vision_v3/logs/` |
+
+---
+
+## Checklist finale (à cocher au fur et à mesure)
+
+- [ ] 1.1 — Services Linux up
+- [ ] 1.2 — Endpoints Internet OK
+- [ ] 1.3 — VM prête, internet OK
+- [ ] 2.x — ZIP déployé, Léa démarre
+- [ ] Test 1 — Streaming + enrollment OK
+- [ ] Test 2 — Auth dashboard OK
+- [ ] Test 3 — ScreenStates enrichis (C2)
+- [ ] Test 4 — TargetSpec qualitatifs (C1 + Lot E)
+- [ ] Test 5 — Cache context-aware (Lot D)
+- [ ] Test 6 — Fail-safe UAC (P0-D)
+- [ ] Test 7 — Blur PII serveur
+- [ ] Test 8 — Logs audit
+- [ ] Test 9 (bonus) — Replay E2E Bloc-notes
+
+Bonne session ! En cas de blocage, revenir à la Section 4 avant de plonger dans le code.
--- a/docs/POC_ANOUST_PAS.md
+++ b/docs/POC_ANOUST_PAS.md
@@ -0,0 +1,293 @@
+# 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)
+
+```bash
+# 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 | ☐ |
--- a/docs/POC_ANOUST_QUESTIONS_DSI.md
+++ b/docs/POC_ANOUST_QUESTIONS_DSI.md
@@ -0,0 +1,130 @@
+# Questions pour le DSI — Clinique Anoust
+## Rendez-vous du 14 avril 2026
+
+---
+
+## A. DPI et système d'information
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 1 | **Quel logiciel DPI utilisez-vous ?** (Cariatides, Cortexte, Osiris, Hopital Manager, Mediboard, autre ?) | Détermine toute l'approche d'extraction et les connecteurs possibles | |
+| 2 | **Quelle version ?** Depuis quand déployé ? | Les anciennes versions ont moins d'API | |
+| 3 | **Quelle base de données sous-jacente ?** (Oracle, SQL Server, PostgreSQL ?) | Si accès direct possible, c'est un plan B en parallèle de Léa | |
+| 4 | **L'éditeur propose-t-il des API ou exports programmés ?** | Alternative ou complément au RPA | |
+| 5 | **Y a-t-il un contrat de support interdisant l'accès direct à la BDD ?** | Risque contractuel à évaluer | |
+| 6 | **Quels modules DPI sont déployés ?** (prescription, observations, agenda, urgences, RIM-P ?) | Périmètre de données disponibles | |
+| 7 | **Le RIM-P est-il géré par le DPI ou un outil tiers ?** | Le RIM-P est notre point d'entrée le plus rapide | |
+| 8 | **Des mises à jour DPI sont-elles prévues ?** | Risque de casser les parcours Léa pendant le POC | |
+
+---
+
+## B. Infrastructure technique
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 9 | **Infrastructure serveurs ?** (on-premise, cloud privé, hybride, infogéré ?) | Si on-premise → dispense HDS. Si tiers → certification HDS obligatoire | |
+| 10 | **Quel hyperviseur ?** (VMware, Proxmox, Hyper-V ?) | Pour provisionner la VM du POC | |
+| 11 | **Pouvez-vous provisionner une VM dédiée POC ?** (idéal : 8 vCPU, 32 Go RAM, 500 Go SSD) | Hébergement EDS + Léa serveur | |
+| 12 | **Quel OS serveur ?** (Ubuntu, RHEL, Windows Server ?) | Compatibilité stack technique | |
+| 13 | **Architecture réseau ?** VLAN santé isolé ? DMZ ? | Isolation nécessaire pour l'EDS | |
+| 14 | **Accès VPN ou bastion pour maintenance à distance ?** | Interventions sans déplacement | |
+| 15 | **Politique de backup ?** (fréquence, rétention, stockage) | Protection des données EDS | |
+| 16 | **Bande passante réseau interne ?** (Gigabit ? 10G ?) | Performance extraction | |
+
+---
+
+## C. Volumétrie et données
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 17 | **Combien de patients en file active annuelle ?** | Dimensionnement EDS | |
+| 18 | **Volume total de dossiers 2024-2025 à traiter ?** | Estimation charge de travail Léa | |
+| 19 | **Types de documents dans les dossiers ?** (CR hospitalisation, observations infirmières, courriers, prescriptions, résultats labo ?) | Périmètre d'extraction | |
+| 20 | **Volume estimé de texte libre par patient ?** (observations, entretiens) | La psy a beaucoup de texte → impact anonymisation | |
+| 21 | **Les données RIM-P / PMSI sont-elles exportables ?** Format ? Qui gère ? | Point d'entrée le plus rapide pour le POC | |
+| 22 | **Y a-t-il des données structurées codées ?** (CIM-10, EDGAR, CSARR ?) | Qualité de base pour l'EDS | |
+
+---
+
+## D. Sécurité et conformité
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 23 | **Avez-vous un DPO ?** Qui ? Interne ou externe ? | Obligatoire. Interlocuteur clé pour l'AIPD | |
+| 24 | **Existe-t-il une PSSI ?** (Politique de Sécurité des SI) | Cadre à respecter | |
+| 25 | **Avez-vous un RSSI ?** | Interlocuteur sécurité | |
+| 26 | **Quel niveau de certification ?** (HOP'EN, ISO 27001 ?) | Maturité sécurité | |
+| 27 | **Chiffrement en place ?** (au repos, en transit) | Prérequis EDS | |
+| 28 | **Gestion des accès ?** (AD, LDAP, SSO ?) | Intégration authentification | |
+| 29 | **Programme CaRE : où en êtes-vous ?** (BIA fait ? Plans de continuité ?) | Échéance juin 2026 | |
+| 30 | **Conformité Ségur du Numérique : quels référentiels implémentés ?** | Maturité interopérabilité | |
+
+---
+
+## E. Gouvernance et organisation
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 31 | **Y a-t-il un médecin DIM motivé et disponible ?** | **Facteur n°1 de succès** — sans DIM, le POC échoue | |
+| 32 | **La CME est-elle informée / favorable ?** | Gouvernance médicale | |
+| 33 | **Y a-t-il déjà des projets de recherche sur les données patients ?** | Si oui, formalités CNIL déjà en place | |
+| 34 | **Base légale envisagée pour l'EDS ?** (mission d'intérêt public, intérêt légitime ?) | Détermine la procédure CNIL | |
+| 35 | **La clinique participe-t-elle au service public hospitalier ?** (convention ARS ?) | Si oui → mission d'intérêt public → référentiel CNIL EDS applicable | |
+| 36 | **Quel est le positionnement de la direction sur l'innovation ?** | Soutien stratégique | |
+
+---
+
+## F. Budget, timeline et ambition
+
+| # | Question | Pourquoi c'est important | Notes |
+|---|----------|-------------------------|-------|
+| 37 | **Budget disponible pour le POC ?** (matériel, prestation, jours/homme) | Cadrage financier | |
+| 38 | **Timeline souhaitée ?** (notre estimation : 3 mois) | Aligner les attentes | |
+| 39 | **Ressources mobilisables ?** (DIM dédié, admin sys, médecin référent) | Charge côté clinique | |
+| 40 | **Financements identifiés ?** (AAP ARS, DGOS, ANR, programme CaRE ?) | Possibilité de co-financement | |
+| 41 | **Ambition post-POC ?** (production, extension, publication, multi-sites ?) | Dimensionner la suite | |
+| 42 | **D'autres établissements du groupe sont-ils intéressés ?** | Potentiel de déploiement | |
+
+---
+
+## G. Points d'attention à aborder (nous)
+
+### Ce que nous devons expliquer au DSI
+
+1. **Léa est 100% locale** — aucune donnée ne quitte le réseau. Pas de cloud, pas d'API externe. Argument massue en psychiatrie.
+
+2. **Supervision humaine permanente** — Léa n'est pas autonome, elle apprend sous supervision d'un humain. Conforme AI Act.
+
+3. **Anonymisation intégrée** — le pipeline dé-identifie AVANT tout stockage dans l'EDS. On ne stocke jamais de données nominatives dans l'EDS de recherche.
+
+4. **Notes personnelles du psychiatre** — nous sommes conscients de cette particularité légale et l'avons intégrée dans la conception (exclusion automatique).
+
+5. **OMOP CDM** — standard international du Health Data Hub. L'EDS sera nativement interopérable si la clinique souhaite participer à des projets de recherche nationaux.
+
+6. **Open source** — pas de coût de licence. Le coût est 100% en temps humain et infrastructure.
+
+### Points à valider absolument avant de partir
+
+- [ ] Le DPI utilisé (nom + version)
+- [ ] La base légale pour l'EDS (mission d'intérêt public ou pas)
+- [ ] La disponibilité d'un médecin DIM
+- [ ] La capacité à provisionner une VM
+- [ ] L'accord de principe pour un accès au DPI (même en lecture écran)
+- [ ] Le calendrier de la prochaine étape
+
+---
+
+## H. Checklist de conformité EDS (référentiel CNIL 2021-118)
+
+Pour référence — à parcourir avec le DPO :
+
+- [ ] Finalité déterminée de l'EDS
+- [ ] Base légale identifiée (art. 6 + art. 9 RGPD)
+- [ ] AIPD réalisée
+- [ ] Information des patients
+- [ ] Exercice des droits (accès, rectification, opposition)
+- [ ] Mesures de sécurité (chiffrement, accès, audit trail)
+- [ ] Pseudonymisation des données
+- [ ] Gouvernance (comité, responsable, charte d'accès)
+- [ ] Durée de conservation définie
+- [ ] Procédure pour les réutilisations (recherche)
--- a/docs/STATUS.md
+++ b/docs/STATUS.md
@@ -32,6 +32,7 @@ Les fonctionnalités ci-dessous sont documentées sans minimiser les limites.
 | Embedding & FAISS (`core/embedding/`) | alpha | CLIP ViT-B/32 + index Flat, pas testé à grande échelle |
 | Workflow Graph (`core/graph/`) | alpha | Construction depuis sessions, matching heuristique |
 | Replay E2E (`agent_v0/server_v1/api_stream.py`) | alpha | Premier succès le 13 avril 2026 sur Notepad, asymétries strict/legacy connues |
+| ExecutionLoop vision-aware (C1) | alpha | ScreenState enrichi + cache perceptuel + flags `enable_ui_detection`/`enable_ocr`/`analyze_timeout_ms`/`window_info_provider` — voir [EXECUTION_LOOP_FLAGS.md](EXECUTION_LOOP_FLAGS.md) |
 | Mode apprentissage supervisé | alpha | Pause sur échec répété, demande d'intervention humaine |
 | TargetMemoryStore (Phase 1 apprentissage) | alpha | Schéma SQLite en place, DB vide jusqu'au premier replay complet |
 | Grounding visuel (UI-TARS, gemma4, qwen3-vl) | alpha | Switch de modèle via `.env` (`RPA_VLM_MODEL`) |
@@ -43,7 +44,7 @@ Les fonctionnalités ci-dessous sont documentées sans minimiser les limites.
 | Federation (`core/federation/`) | alpha | Export/import de LearningPacks, pas de test terrain |
 | GPU Resource Manager (`core/gpu/`) | alpha | Gestion Ollama + warmup modèles, code utilisé mais peu testé |
 | Self-healing / recovery | en cours | Heuristiques présentes, comportement global non stabilisé |
-| Analytics / reporting | en cours | Prototype, pas de frontend finalisé |
+| Analytics / reporting | en cours | Prototype, pas de frontend finalisé. SQLite `step_metrics` étendue avec timings vision-aware C1 (`ocr_ms`, `ui_ms`, `analyze_ms`, `cache_hit`, `degraded`). |
 | Tests end-to-end | en cours | 1 replay E2E réussi, 56 tests d'intégration verts hors cas connus |
 | Deploy Windows (`deploy/build_package.sh`) | opérationnel | Produit `Lea_v<version>.zip`, vérification des fichiers requis |
 | Conformité AI Act (journalisation, floutage, rétention logs) | alpha | Mécanismes en place, audit formel non fait |
--- a/docs/SYNTHESE_11AVRIL_MATIN.md
+++ b/docs/SYNTHESE_11AVRIL_MATIN.md
@@ -0,0 +1,336 @@
+# Synthèse — 11 avril 2026 (préparée pendant ton absence)
+
+Ce document résume ce qui s'est passé pendant ton absence. Lecture : ~10 minutes.
+
+## 🎯 À lire en premier (60 secondes)
+
+**Score global guardian : 6.8/10** — direction bonne, 5 commits du jour propres sans régression, mais **3 points critiques** à adresser.
+
+### Les 3 actions à faire en rentrant (ordre de priorité)
+
+1. **🔴 P0 — Committer `replay_failure_logger.py`** (fichier utilisé partout mais pas tracké git, un fresh clone ne démarre plus). 15 minutes. Bloquant absolu. Guardian item C1.
+2. **🔴 P0 — Corriger l'asymétrie `Fenêtre incorrecte` strict → pause apprentissage** (même pattern que `no_screen_change strict` du commit `7cc03f6f1`, mais sur une autre branche). 1-2h. C'est exactement le bug qui a cassé ton test chirurgical ce matin (tu vas voir la timeline dans Partie 1). Guardian item C2.
+3. **🔴 P1 — Premier replay Notepad E2E réussi pour activer Phase 1 apprentissage**. La DB `data/learning/target_memory.db` est **vide** (0 entrée). La greffe est câblée mais Léa n'a pas encore appris une seule fois en conditions réelles. Tu pourras l'activer dès que #2 est fait. Guardian item E4.
+
+### Les 3 choses à savoir absolument
+
+- **Test chirurgical** : échec propre au premier clic parce que Bloc-notes n'était plus au premier plan sur la VM (focus perdu). La chaîne stricte a fait exactement son job de protection (3 retries puis stop), mais elle est retombée dans la branche retry+stop legacy au lieu de la pause d'apprentissage. **C'est la preuve vivante du bug #2 ci-dessus.**
+- **VWB est un piège** pour le nettoyage de workflows — bug DB runtime + bridge Léa→VWB qui perd 90% de l'info. **Recommandation agent VWB** : écrire un petit outil dédié (200 lignes, 1 jour) plutôt que réparer VWB (4-5 jours). Détails en Partie 4.
+- **Code agent en 3 copies divergentes** : source à jour, deploy copy très en retard (sans UIA), worktree migration sans `replay_failure_logger.py`. Merger le worktree EN L'ÉTAT casserait le démarrage. C4 du guardian.
+
+### Ce qui va vraiment bien 🟢
+
+- Les 5 commits de la journée (`b92cb9db0`, `f82753deb`, `9188bd7df`, `a21f1ea9f`, `7cc03f6f1`) sont tous propres, bien documentés, testés et sans régression
+- L'instrumentation `[REPLAY]` permet un debug multi-étages lisible
+- La Phase 1 apprentissage est une greffe minimale et non-intrusive (exactement comme prévu dans le plan)
+- Le fix de C (`7cc03f6f1`) montre la rigueur post-correction : re-lecture des feedbacks mémoire, pas de rustine
+- Tests E2E + unit (hors VWB) toujours verts : 56/56
+
+Le détail complet ci-dessous, partie par partie.
+
+---
+
+## Partie 1 — Résultat du test chirurgical
+
+### Protocole
+- Replay `replay_free_3935cd0b` lancé sur la session `sess_20260411T084629_2d588e`
+- 3 actions injectées : click `Fichier` → wait 800ms → click `Enregistrer`
+- Chaque click en mode `success_strict=True`, `expected_before='test.txt – Bloc-notes'`
+- Les gardes B (score + drift) et C (pause apprentissage) sont en place
+
+### Timeline
+```
+09:31:09  DISPATCH   test_chir_1_fichier (click Fichier)
+09:31:11  REPORT     success=False error="Fenêtre incorrecte: 'Program Manager' (attendu: 'test.txt – Bloc-notes')"
+09:31:11  VERIFY     final_success=False
+09:31:11  DISPATCH   retry1
+09:31:12  REPORT     success=False error="Fenêtre incorrecte: 'Program Manager' ..."  (identique)
+09:31:13  DISPATCH   wait_retry (2s)
+09:31:16  DISPATCH   retry2
+09:31:17  REPORT     success=False error="Fenêtre incorrecte: 'Program Manager' ..."  (identique)
+09:31:18  DISPATCH   retry3
+09:31:19  REPORT     success=False error="Fenêtre incorrecte: 'Program Manager' ..."  (identique)
+09:31:19  Replay échoué à test_chir_1_fichier_retry3 après 3 retries: status=error
+```
+
+### Analyse critique
+
+**Ce qui a BIEN fonctionné** (à conserver) :
+- `_validate_match_context` côté agent Windows : a détecté le mismatch de fenêtre active (`Program Manager` vs `test.txt – Bloc-notes`)
+- **Pas de clic dans le vide** : la pré-vérif stricte refuse de cliquer quand la fenêtre active n'est pas celle attendue, exactement comme prévu
+- Instrumentation `[REPLAY]` parfaitement lisible : chaque étape, chaque erreur, chaque retry
+- Retry automatique × 3 avec wait interleaved
+
+**Ce qui a MAL fonctionné** (à corriger) :
+
+1. **`Bloc-notes` n'était plus au premier plan** quand le test a démarré. La fenêtre active sur la VM était `Program Manager` (= le bureau Windows). Hypothèses :
+   - Tu as fermé Bloc-notes avant de partir
+   - Un événement Windows a volé le focus (notification, chat Léa, etc.)
+   - Bloc-notes était minimisé
+
+2. **L'erreur `Fenêtre incorrecte` en mode strict retombe dans la branche retry+stop** (réflexe RPA classique), **pas** dans la pause apprentissage. C'est une **incohérence** avec le correctif C que j'ai fait pour `no_screen_change` : les deux devraient avoir le même traitement.
+
+### Ce qu'il aurait fallu faire
+
+Dans `api_stream.py`, la branche qui traite l'erreur `Fenêtre incorrecte` devrait :
+- En mode **strict** : `status = "paused_need_help"` avec `pause_message = "Je m'attendais à voir 'test.txt – Bloc-notes' mais je vois 'Program Manager'. Peux-tu me montrer la bonne fenêtre ?"` → queue intacte, attente d'intervention humaine
+- En mode **legacy** (non strict) : retry × 3 puis continue (comportement actuel)
+
+C'est **symétrique** au correctif C (`no_screen_change strict → pause apprentissage`). À faire dans un prochain commit.
+
+### Ce que ça valide quand même
+
+Malgré l'échec sur un problème environnemental (focus perdu), **la chaîne stricte complète fonctionne** :
+- Pré-vérif stricte ✅
+- Retry automatique ✅
+- Arrêt propre après retries ✅
+- Instrumentation lisible ✅
+- Pas de clic "aveugle" dans le désordre ✅
+
+On a juste besoin d'aligner le traitement d'erreur sur la philosophie d'apprentissage.
+
+---
+
+## Partie 2 — Dettes techniques connues (pré-audit)
+
+En attendant le rapport du project-quality-guardian, voici ce que je sais déjà :
+
+### Dettes hautes (connues et documentées)
+
+1. **`agent_v0/deploy/windows_client/agent_v1/core/executor.py`** : 1302 lignes de divergence non committée avec le dev copy. Risque à chaque nouveau packaging Windows.
+2. **Module `replay_failure_logger.py`** : importé dans `api_stream.py` mais PAS tracké dans git. Bug pré-existant signalé par le subagent VWB tout à l'heure. À vérifier : soit le fichier existe sur disque (ignoré par gitignore), soit l'import est cassé silencieusement.
+3. **Migration `agent_v0/` → top-level** : non mergée, dans un worktree (`.claude/worktrees/agent-a0ebc90f/`). Trois commits prêts mais en attente de ton review.
+4. **`visual_workflow_builder/backend/instance/workflows.db`** : modifié non committé depuis le début de la session. Probablement des données de test.
+5. **`live_session_manager.py`** : modifié non committé. Dans l'état initial de la session, devrait être committé séparément ou ignoré.
+
+### Dettes moyennes
+
+6. **`_a_trier/`** : dossier de code/scripts à trier, jamais nettoyé. Grande taille, pollue les grep.
+7. **`archives/`** : ancien code archivé dans le dépôt. Grossit le repo.
+8. **Phase 1 apprentissage activable mais non testée en conditions réelles** : `TargetMemoryStore` est branché mais aucune session n'a encore déclenché un `memory_record_success` ni un `memory_lookup HIT`. Attend le premier replay complet qui réussit.
+9. **Agent Windows dev vs deploy vs build/Lea/** : trois copies parallèles du code agent, avec divergences possibles à chaque modification.
+
+### Dettes basses
+
+10. **Clics parasites d'arrêt d'enregistrement** : systématiquement capturés dans les sessions (clic sur systray, icône Léa, bouton Arrêter). À filtrer côté captor (ex: ignorer les N dernières secondes, ou tout clic sur fenêtre Léa).
+11. **Phrases types non externalisées** : `pause_message`, `error_description`, etc. sont hardcodées dans le code. Doivent passer en JSON/YAML i18n-ready.
+12. **Service `worker` (port 5099)** : toujours inactif. Le worker VLM qui compile les sessions en workflows n'est pas lancé. Résultat : les sessions enregistrées ne sont jamais compilées automatiquement en ExecutionPlan.
+
+---
+
+## Partie 3 — Ce que j'ai fait pendant ton absence (commits)
+
+Aucun commit pendant ton absence. Juste :
+- Lancement du test chirurgical (échec propre comme analysé)
+- Lancement de 2 agents d'audit en background
+- Création de ce document de synthèse
+
+---
+
+## Partie 4 — Résultat des agents d'audit
+
+### Audit projet global — **TERMINÉ** ✅
+
+**Score global** : **6.8/10** — direction technique bonne, 5 commits du jour propres et sans régression, mais **incohérence philosophique non corrigée** + dette de cohérence multi-copies.
+
+#### 🔴 Les 3 choses à savoir en rentrant (synthèse exécutive du guardian)
+
+1. **Phase 1 apprentissage est techniquement branchée MAIS `data/learning/target_memory.db` est VIDE (0 entrée).** Aucun replay n'a encore survécu au post-cond strict pour cristalliser. Ça veut dire que **tu n'as pas encore vu Léa apprendre**, tu as juste câblé l'apprentissage. Le premier replay qui passe en entier déclenchera la boucle.
+
+2. **Asymétrie strict pré-vérif vs post-vérif** (gros point) : le fix `7cc03f6f1` corrige `no_screen_change strict → paused_need_help`, mais **la branche `Fenêtre incorrecte` en pré-vérif strict retombe toujours en retry+stop legacy**. C'est une **violation directe de `feedback_failure_is_learning.md` sur un chemin différent**. Même pattern, même oubli. C'est exactement ce qui a cassé ton test chirurgical ce matin.
+
+3. **Trois copies divergentes du code agent** :
+   - `agent_v0/agent_v1/` (source à jour avec UIA, grounding, policy, recovery)
+   - `agent_v0/deploy/windows_client/agent_v1/` (1303 lignes non committées, **sans `uia_helper.py`**)
+   - `.claude/worktrees/agent-a0ebc90f/` (migration top-level, **sans `replay_failure_logger.py`**)
+   
+   Tout packaging Windows depuis la deploy copy manque UIA + tous les fix du 10-11 avril. Si tu merges le worktree EN L'ÉTAT, ça casse le démarrage serveur.
+
+#### Cohérence vision / implémentation
+
+5 principes directeurs de la mémoire :
+| # | Principe | Statut | Remarque |
+|---|---|---|---|
+| A1 | 100% visuel (pas de raccourcis inventés) | ✅ Respecté | Grep OK côté replay V4 |
+| A2 | LLM 100% local (Ollama) | ⚠️ **Violé dans VWB** | `vlm_provider.py` priorise OpenAI/Gemini/Anthropic avant Ollama, 3 clés cloud dans `.env.local` |
+| A3 | Léa n'est pas une boîte à clic | ⚠️ Partiel | Infra en place mais DB vide + asymétrie pré-vérif |
+| A4 | Échec = apprentissage, pas arrêt | ⚠️ Partiel | Fix `no_screen_change` OK, pas `Fenêtre incorrecte` |
+| A5 | Citrix / 100% vision | ✅ Cohérent | UIA est accélérateur local VM, cascade visuelle reste le core |
+
+**Violation critique découverte** : `visual_workflow_builder/backend/vlm_provider.py` ligne 53-72 — la classe `VisionHub` priorise `OpenAI (gpt-4o) → Gemini → Anthropic → Ollama en dernier`. Importé par `app.py:165`. **Un client déployé avec les mêmes clés d'env enverrait ses écrans médicaux à OpenAI.** Grave.
+
+#### État des fonctionnalités (14 fonctions)
+
+| # | Fonctionnalité | Statut | Preuve |
+|---|---|---|---|
+| B1 | Agent V1 streaming (capture Windows) | ✅ OK | `executor.py` 2177L, /replay/next pollé |
+| B2 | Streaming server `api_stream.py` | ✅ OK | 4401L, rpa-streaming active running |
+| B3 | SomEngine (YOLO + docTR + VLM) | ✅ OK (dormant dans cascade) | `_resolve_by_som` défini mais appelé seulement en V4 resolve_order |
+| B4 | Resolve cascade (OCR/template/VLM/grounding/SoM) | ✅ OK | `_resolve_target_sync:1530` |
+| B5 | Contrôle strict étapes (title_match) | ⚠️ OK post, **incohérent pré** | Cf point #2 ci-dessus |
+| B6 | UIA local (lea_uia.exe) | ⚠️ **OK source, ABSENT deploy** | `deploy/windows_client/.../core/` n'a pas `uia_helper.py` |
+| B7 | TargetMemoryStore Phase 1 | ⚠️ Greffe OK, **DB vide** | `SELECT COUNT(*) FROM target_memory` → 0 |
+| B8 | Instrumentation `[REPLAY]` | ✅ OK | 13 logs structurés |
+| B9 | Garde qualité résolution | ✅ OK | 7 tests unitaires inline |
+| B10 | `no_screen_change strict → pause` | ✅ OK | commit `7cc03f6f1` |
+| B11 | VWB | ⚠️ Audit séparé — BROKEN en écriture | Voir section VWB ci-dessous |
+| B12 | Fédération (`core/federation/`) | ✅ Import OK, non testée | |
+| B13 | Module auth (`core/auth/`) | ✅ Partiellement branché | |
+| B14 | Workers systemd | ⚠️ Mixte | streaming/agent-chat/api OK, dashboard inactive, worker 5099 NOT LISTENING, healthcheck failed |
+
+#### Dettes techniques — 20 items priorisés (rapport complet)
+
+**🔴 Priorité haute** (5 items) :
+
+| # | Lieu | Nature | Effort |
+|---|---|---|---|
+| **C1** | `agent_v0/server_v1/replay_failure_logger.py` | **Fichier ni tracké ni gitignoré**, importé à `api_stream.py:29`. **Un `git clone` ne peut plus démarrer le serveur.** | < 15 min (git add) |
+| **C2** | `api_stream.py` branche `Fenêtre incorrecte` | Asymétrie avec fix `7cc03f6f1` — bloquer avec `paused_need_help` au lieu de retry+stop | 1-2h |
+| **C3** | `deploy/windows_client/agent_v1/core/executor.py` | 1303 insertions non committées, manque `uia_helper.py` + `grounding.py` + `policy.py` + `recovery.py` | Demi-journée |
+| **C4** | `.claude/worktrees/agent-a0ebc90f/` | Worktree ne contient pas `replay_failure_logger.py` → merge cassera l'import | 1-2h |
+| **C5** | `tests/unit/test_som_integration.py::test_resolve_success` | Mock cassé par refactoring, cible `api_stream._get_som_engine_api` au lieu de `resolve_engine.*` | 30 min |
+
+**🟡 Priorité moyenne** (7 items) :
+
+- **C6** : `vlm_provider.py` cloud-first (violation A2) — 1-2h
+- **C7** : `live_session_manager.py` 118 lignes non committées (code propre utile) — 30 min
+- **C8** : Worker port 5099 inactif (sessions jamais compilées en ExecutionPlan) — 1-2h
+- **C9** : Services systemd healthcheck + artifact-retention failed — 30 min
+- **C10** : Scaffold vide `agent_v1/` top-level — < 15 min
+- **C11** : 22 fichiers en `M` non committés (diffus) — demi-journée triage
+- **C12** : `core/detection/vlm_config.py` non tracké — 10 min
+
+**🟢 Priorité basse** (8 items) :
+
+- **C13** : `_a_trier/` 561 Mo + `visual_workflow_builder/_a_trier/` 7.6 Go
+- **C14** : 2 venvs VWB → 15.6 Go disque
+- **C15** : `core/execution/target_resolver.py` (3495L V3 dormant)
+- **C16** : README.md obsolète (décembre 2024)
+- **C17** : `web_dashboard/app.py.bak_20260304_2225`
+- **C18** : `archives/` 21 Mo committé dans le repo
+- **C19** : 53 TODO/FIXME/HACK dans Python
+- **C20** : `data/training/live_sessions/` 5.1 Go sans rotation
+
+#### Régressions potentielles depuis le matin
+
+**Aucune nouvelle régression** introduite par les 5 commits du jour. L'incohérence `Fenêtre incorrecte` est **pré-existante** (branche legacy qui aurait dû être corrigée en même temps). Guardian a vérifié les 4 branches de `/replay/result` (lignes 3090-3330) — elles s'enchaînent proprement, pas d'interaction non triviale entre D1-D5.
+
+#### Recommandations priorisées du guardian
+
+| # | Priorité | Action | Effort | Justification vision |
+|---|---|---|---|---|
+| **E1** | **P0** | Committer `replay_failure_logger.py` | < 15 min | Empêche tout fresh clone/deploiement |
+| **E2** | **P0** | Corriger asymétrie `Fenêtre incorrecte` → `paused_need_help` | 1-2h | Respect `feedback_failure_is_learning.md` + débloque test chirurgical |
+| **E3** | **P1** | Sync deploy copy avec source + ajouter uia_helper/grounding/policy/recovery | Demi-journée | Sans ça Léa n'a pas accès à ses propres progrès sur VM |
+| **E4** | **P1** | **Premier replay E2E réussi** pour activer Phase 1 (Notepad propre, 2 fois, vérifier target_memory.db) | 1-2h | **Seule façon de prouver que Léa apprend vraiment** |
+| **E5** | **P1** | Décider du sort du worktree (compléter ou refaire) | 1-2h | Éviter dette multi-copies |
+| **E6** | **P2** | Gater `vlm_provider.py` derrière env var (violation 100% local) | 1-2h | Respect `feedback_local_only.md` |
+| **E7** | **P2** | Relancer worker 5099 + vérifier compilation sessions | 1-2h | Pipeline apprentissage cassé en bout |
+| **E8** | **P2** | Committer `live_session_manager.py` | 30 min | Dette git |
+| **E9** | **P3** | Réparer test_som_integration | 30 min | Suite unit verte |
+| **E10** | **P3** | Nettoyer 2 venvs VWB | 30 min | 15.6 Go disque |
+
+### Audit VWB — **TERMINÉ** ✅
+
+**TL;DR : VWB est un piège pour notre besoin. Recommandation = Option A (petit outil dédié 1 jour).**
+
+#### État global
+Partiellement fonctionnel en **lecture**, **CASSÉ en écriture** (bug runtime trivial), et **gravement amputé en contenu** (bridge Léa→VWB perd 90% de l'information). Le scaffolding est là, la chaîne end-to-end ne fonctionne pas.
+
+#### Bug bloquant immédiat
+Le processus 1800738 (vwb-backend:5002) tient un handle sur une version **supprimée** de `workflows.db` (6 file descriptors sur `(deleted)`). Toute écriture → `sqlite3.OperationalError: attempt to write a readonly database`. Un `systemctl --user restart rpa-vwb-backend` règle ce point — mais les vrais problèmes restent.
+
+#### Ambiguïtés structurelles (dette)
+| Problème | Impact |
+|---|---|
+| `frontend/` (vieux, inactif) vs `frontend_v4/` (actif) | Confusion à chaque lecture code |
+| `app.py` (5002, avec api_v3) vs `app_lightweight.py` (5003, SANS api_v3) | Deux backends parallèles |
+| `db/models.py` (legacy) vs `instance/workflows.db` SQLAlchemy (api_v3) | **Deux DB parallèles** — workflows visibles ici ≠ workflows visibles là |
+
+#### Ce qui marche côté code (vérifié)
+- `GET /api/v3/learned-workflows` : liste 126 workflows Léa sur disque
+- Routes CRUD Step : add/update/delete/reorder (existent backend + client TS)
+- PropertiesPanel 1415 lignes — édite délais, texte, direction, hover_duration
+- UI drag-and-drop ajout step via tool palette → React Flow
+- `POST /api/v3/execute-windows` : proxy vers streaming server, fonctionnel
+
+#### Ce qui manque (critique pour le nettoyage)
+
+1. **Import compound = coquille vide** : 95% des edges Léa sont des actions `type: compound` avec 10-40 sous-étapes (clic + waits + text_input lettre par lettre). Le bridge crée **UN seul step VWB** pour toute la compound → *"Impossible de nettoyer ce qu'on ne voit pas"*
+2. **Pas d'auth VWB → streaming server** : `requests.get(...)` sans header Authorization, donc `streaming_server_available: false`. VWB ne voit que les workflows déjà compilés (max 4 avril), pas les sessions récentes
+3. **Pas de screenshots attachés** : les `shots/*.png` de session ne sont jamais liés aux steps importés
+4. **Pas de réordonnancement UI** : `reorderSteps` existe backend + client, mais **aucun composant React ne l'appelle**
+5. **Édition target_spec absente** : PropertiesPanel n'a **aucun champ** `x_pct`, `y_pct`, `target_role`, `target_text`, `vlm_description`. Impossible de corriger un faux positif
+6. **Pas d'ingestion raw events** : `live_events.jsonl`, `build_replay_from_raw_events`, `execution_plan_to_actions` ne sont pas importés dans VWB
+7. **Pas de liste "sessions récentes"** : aucun endpoint VWB qui liste les `sess_*` sur disque
+8. **Zéro test** sur le pont Léa ↔ VWB
+
+#### Effort de réparation estimé
+
+| Item | Effort |
+|---|---|
+| Restart service (fix DB readonly) | 5 min |
+| Ajouter auth Bearer VWB → :5005 | 30 min |
+| Décomposer actions compound en N steps VWB | **1 jour** |
+| Attacher screenshots aux steps | **1 jour** |
+| Édition target_spec dans PropertiesPanel | 0.5 jour |
+| Drag-to-reorder UI | 0.5 jour |
+| Endpoint `/live-sessions` + importer raw | **1-2 jours** |
+| Tests minimal | 0.5 jour |
+| **Total** | **4-5 jours** |
+
+Et encore, **on hériterait de la dette** (deux DB, deux backends, zéro test, frontend abandonné).
+
+#### Recommandation — 3 options
+
+**Option A (recommandée) — Outil dédié léger, 1 jour** ⭐
+Écrire un petit Flask (200 lignes) qui :
+1. Liste les sessions `live_sessions/*/sess_*` sur disque
+2. Charge `live_events.jsonl` via `build_replay_from_raw_events` (existe déjà dans `stream_processor.py:1279`)
+3. Affiche la liste linéaire des actions + screenshots `shots/` correspondants
+4. Checkbox "supprimer cette étape" + édition texte simple
+5. Re-sérialise et POST vers `/api/v1/traces/stream/replay/raw`
+
+**Évite toute la complexité VWB** et cible exactement le besoin : "supprimer 3 clics parasites et relancer".
+
+**Option B — Réparer VWB minimalement (2 jours)** — restart + auth + décomposer compound. Hérite de toute la dette UX.
+
+**Option C — Abandonner VWB** — suggéré par l'accumulation de dette (126 workflows "pending_review", zéro test sur le pont, deux backends, frontend abandonné)
+
+**Vote de l'agent VWB** : *"Option A. Le besoin réel est 'supprimer 3 clics parasites et relancer' — c'est 30 secondes d'UX, pas un Visual Workflow Builder."*
+
+**Mon vote aussi** : **A**. Parce que ça sert directement notre prochain test replay. B prend plus de temps qu'il ne nous fait gagner. C laisse la dette pourrir.
+
+---
+
+## Partie 5 — Actions recommandées quand tu rentres
+
+Par ordre de priorité :
+
+### P0 — À faire dans les 10 premières minutes de ton retour
+
+1. **Vérifier sur la VM** que Bloc-notes est bien fermé (ou pas), et si possible ce qui a volé le focus
+2. **Lire la partie 1** de cette synthèse (résultat test chirurgical)
+3. **Lire les rapports des 2 agents** (sections 4)
+
+### P1 — À discuter avec moi
+
+4. **Corriger l'incohérence `Fenêtre incorrecte strict → pause apprentissage`** (même pattern que C)
+5. **Décider** : on continue à stabiliser le replay avec des tests manuels, OU on passe à l'intégration d'OS-Atlas-Base-7B comme grounder, OU on attaque VWB comme outil de correction ?
+6. **Externaliser les phrases types** en JSON i18n (petit commit)
+
+### P2 — Plus tard dans la journée
+
+7. Merger la migration `agent_v0/` → top-level (worktree déjà prêt)
+8. Investiguer le fichier `replay_failure_logger.py` (importé, pas tracké)
+9. Démarrer le worker VLM pour que les sessions soient compilées en workflows
+
+### P3 — Semaine prochaine
+
+10. Nettoyer `_a_trier/` et `archives/`
+11. Sync de l'agent deploy copy avec le dev
+12. Implémenter le filtre "ignore clics de fin d'enregistrement" côté captor
+
+---
+
+*Document généré automatiquement pendant l'absence de Dom. Sera mis à jour avec les rapports des agents d'audit.*