rpa_vision_v3/docs/AUDIT_20260404.md

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
2. Métriques clés
3. Architecture
4. Modules core — Analyse détaillée
5. Composants web
6. Agent V0/V1 — Streaming
7. Tests
8. Sécurité
9. Déploiement & Infrastructure
10. Qualité du code
11. Performances
12. Gestion des dépendances
13. Documentation
14. Espace disque
15. Points forts
16. Points faibles & Risques
17. Recommandations
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 :

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

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

# 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

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

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

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)

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

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

# 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

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é)