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](#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é)*