rpa_vision_v3/docs/README_PROPOSED_2026-07-02.md

RPA Vision V3 — Automatisation basée sur la compréhension visuelle des interfaces

⚠️ Projet en phase POC clinique — déployé mais non production-ready. Voir docs/STATUS.md pour l'état réel par module. Certaines briques tournent en clinique de bout en bout, d'autres sont codées mais gated/dormantes (activation supervisée par Dom uniquement).

Dernière mise à jour : 2 juillet 2026 (brouillon proposé — remplace le README daté du 14 avril 2026)

Note de relecture : ce brouillon reflète la trajectoire mai→juillet 2026 (livraison DGX Spark, flotte clinique Wallerstein, PII, extraction, grounder Qwen3-VL, installeur EXE, MAJ silencieuse). L'ancien README/STATUS s'arrêtait au « premier replay Notepad du 13 avril 2026 » et ne reflétait plus la réalité.

Intention

Automatiser des workflows métier hospitaliers par compréhension sémantique de l'écran plutôt que par coordonnées de clic fixes. Le système observe le TIM, reconstruit un graphe d'états de l'interface, et cherche à rejouer intelligemment la procédure en reconnaissant visuellement les éléments cibles — y compris quand l'UI change légèrement. Objectif produit : Léa apprend un parcours et le généralise, ce n'est pas du record-and-replay.

Terrain cible : postes hospitaliers hétérogènes (vrais logiciels métier en mode web, RDP et Citrix), TIM sur 2 écrans → capture de la fenêtre active. C'est cette hétérogénéité qui justifie l'approche « 100 % vision ».

Contraintes fortes :

• 100 % vision : résolution de l'UI par la vue, pas par sélecteurs DOM/API.
• 100 % local : inférence sur GPU local (Ollama / vLLM). Aucun appel cloud dans le pipeline par défaut (passeport souverain santé).

Historique : la maquette « Easily Assure » a servi de banc de test jusqu'à mi-2026 ; elle est abandonnée comme cible (recadrage juin 2026). Ne plus raisonner « Easily ».

Architecture en couches

RawSession (couche 0) — capture événements + screenshots (Agent V1 Windows)
        ↓
ScreenState (couche 1) — états d'écran à plusieurs niveaux d'abstraction
        ↓
UIElement (couche 2) — détection sémantique (OCR / template / VLM)
        ↓
State Embedding (couche 3) — fusion multi-modale + index FAISS
        ↓
Workflow Graph (couche 4) — nœuds, transitions, résolution de cibles par la vue

Topologie runtime réelle (POC clinique)

[Léa — client Windows sur poste TIM]         ~15-19 postes enrôlés
        │  (HTTPS/Bearer, sortant uniquement)
        ▼
[DGX Spark — 192.168.1.178 — serveur clinique unique]
   ├─ Streaming server (5005)  — sessions live, pipeline core, replay
   ├─ Dashboard Fleet (5001)   — enrôlement + build installeur + supervision
   ├─ Agent Chat (5004)
   ├─ VWB backend/frontend (5002/3002) — admin
   └─ Grounder VLM (Qwen-VL, vLLM/Ollama)

Le serveur n'initie jamais de connexion vers les postes. Accès distant Dom via VPN clinique (Stormshield) + SSH cert ; déploiement code par scp/rsync (le DGX ne fait pas git pull).

État des fonctionnalités (synthèse)

Le détail par module est dans docs/STATUS.md. Légende : opérationnel (utilisé en clinique, sans régression connue) / alpha (fonctionnel sur cas de référence, peu généralisé) / gated (codé + testé mais désactivé par défaut, activation supervisée) / débranché (code présent mais jamais appelé au runtime) / en cours.

Opérationnel (tourne en clinique)

• Capture Windows (Agent V1) + streaming vers le DGX (JPEG + downscale, PII-safe).
• Client Léa autonome : installeur EXE Windows (python-embed 3.12.8, sans Python système, install per-user sans UAC), enrôlement via dashboard Fleet, démarrage auto (raccourci Bureau optionnel à l'install). Version client 1.0.2 (upgrade-safe).
• Résilience client RDP/Citrix : watchdog re-affiche le tray si Léa disparaît.
• Streaming server FastAPI (5005). Sessions live en mémoire (live_session_manager.py) ; persistances SQLite/JSONL en place à côté : registre d'agents enrôlés, store de logs clients par machine_id, mémoire de résolutions (replay_memory), DB workflows VWB.
• Assainissement PII couche 1 (regex + structurel, pii_sanitizer.py) : câblé au chokepoint stream_event, floute aussi les focus_*, text_input → token [SAISIE]. Déployé sur le DGX.
• Enrôlement flotte : dashboard construit à la volée le ZIP Léa complet autoportant avec config (URL serveur / token / machine_id).
• Grounding visuel : résolution par la vue au replay — stratégie VLM-first sur les éléments texte, ordre pré-compilé OCR → template → VLM (YOLO présent dans le code mais sans appelant au runtime). Les coords figées ne sont qu'ultime fallback. Grounder Qwen3-VL câblé (RPA_GROUNDING_ENGINE=qwen3vl_vllm) — activé en override runtime sur le DGX (défaut du repo = legacy Qwen2.5-VL).

Alpha

• Construction de workflow graph depuis une session ; matching heuristique.
• Replay E2E supervisé multi-étapes (bien au-delà du 1er succès Notepad d'avril).
• Mode apprentissage : pause + demande d'aide humaine quand la résolution échoue (l'échec est un signal d'apprentissage, pas un stop en erreur).
• Embeddings CLIP + index FAISS (construit ; lecture au replay débranchée).
• Extraction dossier patient (core/extraction/) : orchestrateur OCR(valeurs) → VLM(rôles, ancré sur ids OCR = 0 hallucination) → qualité, persistance en DB VWB. Handler extract_dossier dispatché côté serveur. Lecture écran→JSON prouvée sur vrai DPI urgences ; à confirmer en usage courant.
• Navigation visuelle (core/navigation/, nouveau) : login visuel, grounding OCR-first, verify_before/verify_after (vision = validateur). Handler navigate dispatché côté serveur. Naissant — à éprouver.
• Web Dashboard (5001), Agent Chat (5004), module auth (Fernet + TOTP), federation (LearningPack, export/import).
• Visual Workflow Builder (VWB) : catalogue d'actions, import d'anchors Léa, tests de compétence supervisés, Basic auth LAN. Les bugs DB runtime historiques ont été largement corrigés ; durcissement encore en cours.

Gated (codé + testé, OFF par défaut — activation supervisée)

• MAJ silencieuse client (canary par poste, DETTE-022) : résolveur canary serveur + orchestrateur client implémentés et testés. RPA_AUTO_UPDATE_ENABLED OFF ; swap atomique + rollback implémentés (Lea.bat, marqueur UPDATE_READY) mais jamais exercés en prod — revue humaine obligatoire avant activation.
• Import auto de l'appris → DB VWB rejouable (R1) : RPA_R1_AUTO_IMPORT OFF.
• Log shipper client (remontée auto des logs vers le serveur) : gated OFF.
• PII couche 2 (NER CamemBERT-bio, ONNX CPU côté DGX) : à embarquer, dormant.

Débranché / en cours

• Chaîne apprentissage non bouclée end-to-end : R1 (pont JSON appris ↔ DB VWB) et R3 (lecture FAISS au replay) manquants ; apprentissage incrémental débranché ; savoir siloté par machine_id.
• Self-healing / recovery global ; analytics / reporting.

Limitations connues

• Le replay est validé sur un nombre restreint d'applications ; robustesse grounding encore un sujet ouvert (dette DETTE-006/010).
• Chaîne apprentissage : capture→workflow marche, mais le bouclage observation→rejeu généralisé n'est pas câblé (R1/R3). FAISS construit mais jamais lu au replay.
• Combien de postes exercent réellement le geste complet est non vérifié (Phase 0 de mesure en attente). Postes possiblement muets sous RDP/Citrix.
• PII : couche 1 déployée ; couche 2 (NER) dormante. Historique de données capturées en clair — décision purge/assainissement en attente.
• Asymétrie connue : VWB direct utilise un détecteur d'UI au recording que le replay sur Léa n'utilise pas (sujet ouvert post-POC, à ne pas « fixer » là).
• 🔴 POST /api/v3/execute/instruction pilote l'écran X11 de l'hôte sans sandbox/kill-switch ; atteignable sur LAN clinique. Chantier sandbox (F8.4) identifié comme prioritaire.

Démarrage

Prérequis

• Python 3.10 à 3.12
• Serveur : GPU NVIDIA local. Cible clinique = DGX Spark (GB10, mémoire unifiée, ARM64, headless). Alternative dev = x86 RTX 5070.
• LLM local : Ollama (:11434) et/ou vLLM (grounder Qwen3-VL).
• Windows 10/11 pour le client Agent V1.

Installation (serveur / dev Linux)

python3 -m venv .venv          # venv unique du repo (svc.sh + unités systemd utilisent .venv)
source .venv/bin/activate      # (le DGX historique utilise venv_v3 ; réfs venv_v3 du Makefile = périmées en local)
pip install -r requirements.txt

# Ollama local + modèle VLM
ollama serve &
ollama pull gemma4:latest      # modèle VLM par défaut du repo (core/config.py, .env.example)
# Le grounder Qwen3-VL est servi par vLLM, pas par un pull Ollama — voir docs/STATUS.md

cp .env.example .env           # ajuster RPA_VLM_MODEL, VLM_ENDPOINT, ports

Lancer les services

Services pilotés par svc.sh (source de vérité : services.conf).

./svc.sh status
./svc.sh start boot        # groupe nominal (variantes : full, vwb, ou un service seul)
./svc.sh start streaming   # streaming server seul (5005)
./svc.sh stop boot

Port	Service
8000	API Server (upload / traitement core)
5001	Web Dashboard / Fleet (enrôlement, supervision)
5002	VWB Backend (Flask)
5003	Monitoring
5004	Agent Chat
5005	Streaming Server (Agent V1 → pipeline core) — canal principal Léa
5006	Session Cleaner
5099	Worker VLM (analyse sessions → workflows JSON) — lancé avec le groupe boot
3002	VWB Frontend (Vite/React)

Client Windows (Agent V1) — déploiement clinique

Le client capture souris/clavier/écran et envoie au serveur (sortant uniquement). Déploiement recommandé via le dashboard Fleet (enrôlement + ZIP autoportant), puis Installer-Lea.bat sur le poste (installeur EXE Python-embedded).

# Build du ZIP complet autoportant (python-embed + source à jour)
./deploy/build_package_full.sh
# Build de l'installeur EXE (Inno Setup, per-user)
./deploy/installer/build_installer.sh

Arborescence du dépôt

rpa_vision_v3/
├── agent_v0/
│   ├── agent_v1/            # Client Windows (capture, tray, MAJ, PII-safe logs)
│   └── server_v1/           # FastAPI streaming + pipeline (replay, resolve, PII, extraction)
├── core/
│   ├── detection/           # Cascade OCR / template / YOLO / VLM
│   ├── embedding/           # CLIP + FAISS
│   ├── graph/               # Workflow graphs
│   ├── extraction/          # Lecture écran→JSON (OCR→VLM→qualité)   [nouveau]
│   ├── navigation/          # Login visuel, grounding, verify         [nouveau]
│   ├── execution/, learning/, auth/, federation/, gpu/
├── server/                  # API upload / traitement core (8000)
├── visual_workflow_builder/ # VWB (Flask + React Vite)
├── web_dashboard/           # Dashboard + Fleet
├── tools/                   # Outils CLI (session cleaner 5006, POC lecture écran)
├── agent_chat/              # Interface conversationnelle + planner
├── deploy/                  # Build ZIP, installeur EXE, systemd, dgx/
├── data/                    # Sessions, embeddings, FAISS, apprentissage
├── docs/                    # Documentation technique (voir STATUS.md)
├── tests/                   # pytest (unit, integration, e2e)
├── services.conf, svc.sh, run.sh

Tests

source .venv/bin/activate
pytest -m "not slow" -q
pytest tests/integration/ -q

Quelques tests legacy sont connus comme cassés — voir docs/ et la mémoire projet.

Documentation

• docs/STATUS.md — état réel par module (⚠ à réaligner sur juillet 2026)
• docs/PLAN_ACTION_SUITE_2026-06-23.md — plan consolidé post-livraison clinique
• docs/PLAN_REMISE_AU_CARRE_APPRENTISSAGE_2026-06-27.md — pourquoi la chaîne apprentissage n'est pas câblée + plan
• docs/DESIGN_ANONYMISATION_TOKENS_TYPES_2026-06-28.md — PII par tokens typés
• docs/DESIGN_MAJ_SILENCIEUSE_CANARY_2026-07-01.md — MAJ silencieuse canary (gated)
• docs/POC/PORTAGE_DGX_SPARK_2026-05-28.md — portage DGX Spark
• docs/EXECUTION_LOOP_FLAGS.md, docs/CONFORMITE_AI_ACT.md

Concepts clés

• RPA 100 % vision : l'agent localise un élément par ce qu'il voit (label + contexte visuel), pas par x,y. La vision est source de vérité : les coords servent en exécution, mais l'écran est re-résolu si divergence.
• Léa apprend, comprend, généralise — pas record-and-replay.
• Apprentissage progressif : shadow → assisté → autonome, supervisé.
• LLM 100 % local : Ollama / vLLM sur GPU local. Aucun appel cloud dans le pipeline par défaut.

Licence

Propriétaire — tous droits réservés.