Files
rpa_vision_v3/docs/STATUS.md
Dom a2b82d3e76
Some checks failed
security-audit / Bandit (scan statique) (push) Successful in 14s
security-audit / pip-audit (CVE dépendances) (push) Successful in 12s
security-audit / Scan secrets (grep) (push) Successful in 9s
tests / Lint (ruff + black) (push) Successful in 15s
tests / Tests sécurité (critique) (push) Has been cancelled
tests / Tests unitaires (sans GPU) (push) Has been cancelled
fix(lint): ruff passe propre — 2 vrais bugs + suppression fichier corrompu
Vrais bugs corrigés :
- core/execution/target_resolver.py : suppression de 5 lignes de dead code
  après return (vestige de refacto incomplète référençant des params
  jamais assignés à self : similarity_threshold, use_spatial_fallback)
- agent_v0/agent_v1/core/executor.py:2180 : variable `prefill` référencée
  mais jamais définie. Initialisation explicite ajoutée en amont
  (conditionnée sur _is_thinking_popup, cohérent avec l'append du message)

Fichier supprimé :
- core/security/input_validator_new.py : contenu corrompu (texte inversé,
  artefact de copier-coller), jamais importé nulle part, 550 erreurs ruff
  à lui seul

Workflow CI :
- Exclusions ajoutées pour dossiers legacy connus cassés :
    - agent_v0/deploy/windows_client/ (clone obsolète)
    - tests/property/ (cf. MEMORY.md — imports cassés)
    - tests/integration/test_visual_rpa_checkpoint.py (VisualMetadata
      inexistant, déjà documenté)

Résultat : "ruff All checks passed!" sur core/ agent_v0/ tests/
(avec E9,F63,F7,F82 — syntax + undefined critiques).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-15 19:00:16 +02:00

6.1 KiB

STATUS — État réel du projet RPA Vision V3

Dernière mise à jour : 14 avril 2026

Ce document remplace les affirmations marketing du README historique. Il décrit l'état réel des modules, sans embellissement.

Positionnement

POC avancé — certaines briques sont fonctionnelles de bout en bout (capture, streaming, premier replay E2E sur Notepad), d'autres sont en cours de stabilisation ou à l'état d'ébauche. Le projet n'est pas « production-ready ».

Les fonctionnalités ci-dessous sont documentées sans minimiser les limites.

Légende

  • opérationnel : testé, utilisé régulièrement, pas de régression récente connue
  • alpha : branché et fonctionnel sur un cas d'usage de référence, manque de recul sur la généralisation
  • en cours : en développement actif, comportement instable
  • non démarré : planifié, pas encore de code significatif

Vue d'ensemble par module

Module / fonctionnalité État Commentaire
Capture d'écran + événements (Agent V1 Windows) opérationnel agent_v0/agent_v1/ — systray, streaming vers serveur
Streaming server (agent_v0/server_v1/) opérationnel FastAPI port 5005, sessions en mémoire
Stockage sessions (RawSession) opérationnel JSON + screenshots, rotation manuelle
Détection UI (core/detection/) alpha Cascade VLM + OCR + templates, sensible au modèle choisi
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
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)
SomEngine (YOLO + docTR + VLM) alpha Intégré, dormant dans la cascade par défaut
Web Dashboard (port 5001) alpha Flask + SocketIO, fonctionnel mais non durci
Visual Workflow Builder (VWB, ports 5002 + 3002) en cours Catalogue d'actions, UI React. Bugs DB runtime connus
Agent Chat (port 5004) alpha Planner autonome, basé LLM local
Module auth (core/auth/) alpha Vault Fernet + TOTP, CLI seul, pas d'intégration UI
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é. 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

Limites connues (non exploitables comme failles)

  • Plusieurs copies parallèles du code agent ont existé (source, staging Windows, worktrees) avec risque de divergence. Le staging Windows obsolète a été supprimé ; le build officiel passe par deploy/build_package.sh.
  • La base data/learning/target_memory.db reste vide tant qu'un replay complet n'a pas été cristallisé — l'apprentissage est câblé mais pas encore éprouvé.
  • Certaines asymétries entre chemins « strict » et « legacy » dans api_stream.py peuvent faire retomber une erreur en mode strict vers le retry+stop legacy au lieu de la pause d'apprentissage.
  • Le worker de compilation sessions → ExecutionPlan (port 5099) n'est pas lancé par défaut — les sessions enregistrées ne sont pas compilées automatiquement.
  • Le VWB présente des bugs en écriture DB identifiés et documentés.
  • La détection VLM est sensible au choix de modèle ; le défaut est gemma4:latest (cf. .env.example).

Modèles utilisés

Définis dans .env (voir .env.example) :

Variable Valeur par défaut Rôle
RPA_VLM_MODEL gemma4:latest Modèle VLM principal (Ollama)
VLM_MODEL gemma4:latest Alias de compatibilité
CLIP_MODEL ViT-B-32 Embeddings visuels
CLIP_PRETRAINED openai Poids pré-entraînés
VLM_ENDPOINT http://localhost:11434 Ollama local

Modèles alternatifs testés : qwen3-vl:8b, ui-tars (grounding direct). Aucun appel cloud par défaut — tout passe par Ollama local.

Infrastructure

  • OS cible serveur : Linux (Ubuntu 24.04 testé)
  • GPU recommandé : NVIDIA (ex. RTX 5070) pour l'inférence VLM locale
  • OS cible client : Windows 10/11 (Agent V1)
  • Python : 3.10 à 3.12
  • Ollama : service local obligatoire

Ports utilisés (source : services.conf)

Port Service
8000 API Server (core upload)
5001 Web Dashboard
5002 VWB Backend (Flask)
5003 Monitoring
5004 Agent Chat
5005 Streaming Server (Agent V1)
5006 Session Cleaner
5099 Worker de compilation (optionnel)
3002 VWB Frontend (Vite/React)

Prochaines étapes prioritaires

  1. Stabiliser le replay E2E sur 3 applications métier différentes
  2. Alimenter TargetMemoryStore via des replays réussis réels
  3. Harmoniser les branches strict / legacy dans api_stream.py
  4. Durcir VWB ou pivoter vers un outil dédié plus simple
  5. Activer le worker de compilation sessions → ExecutionPlan