Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(audit): README honnête + STATUS + DEV_SETUP + cleanup build

Browse Source 
- README.md : bandeau POC, date 14 avril 2026, retrait claims
  "production-ready 77%" (alignement code/doc post-audit)
- docs/STATUS.md : état réel par module (opérationnel/alpha/en cours)
- docs/DEV_SETUP.md : gestion worktrees Claude
- QUICK_START.md : gemma4:latest au lieu de qwen3-vl:8b
- deploy/build_package.sh : +9 fichiers dans REQUIRED_FILES
  (system_dialog_guard.py, persistent_buffer.py, grounding.py, etc.)
- agent_v0/deploy_windows.py : marqué OBSOLÈTE (legacy)
- .gitignore : ajout data/, .hypothesis, .deps_installed, buffer/,
  instance/*.db, caches SQLite

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
2026-04-14 16:49:29 +02:00
parent 36737cfe9d
commit 42f571d496
7 changed files with 438 additions and 172 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
.gitignore vendored
View File

@@ -83,3 +83,30 @@ backups/
# === Legacy / Triage === # === Legacy / Triage ===
_a_trier/ _a_trier/
archives/ archives/
# === Claude Code — worktrees et données locales ===
# Worktrees générés par la CLI Claude Code lors d'exécutions d'agents
# parallèles. Peuvent atteindre plusieurs centaines de Mo chacun.
# Ne jamais committer — gérer via `git worktree list` / `git worktree remove`.
.claude/
.kiro/
.mcp.json
.snapshots/
# === Données runtime (sessions, learning, buffer, config local) ===
data/
.hypothesis/
.deps_installed
# Buffers SQLite locaux (streamer, cache)
**/buffer/
**/pending_events.db
# Databases applicatives (instance Flask)
**/instance/*.db
**/instance/*.sqlite
**/instance/*.sqlite3
# Caches et index locaux
*.sqlite
*.sqlite3
*.db-journal
*.db-wal
*.db-shm

7
QUICK_START.md
View File

@@ -21,7 +21,12 @@ ollama serve
### 3. Télécharger le modèle VLM ### 3. Télécharger le modèle VLM
```bash ```bash
ollama pull qwen3-vl:8b # Modèle par défaut du projet (voir .env.example)
ollama pull gemma4:latest
# Alternatives supportées
# ollama pull qwen3-vl:8b
# ollama pull 0000/ui-tars-1.5-7b-q8_0:7b # grounder visuel
``` ```
## Utilisation ## Utilisation

338
README.md
View File

@@ -1,207 +1,203 @@
# RPA Vision V3 - 100% Vision-Based Workflow Automation # RPA Vision V3 — Automatisation basée sur la compréhension visuelle des interfaces
## 📊 Status > ⚠️ **Projet en phase POC** — voir [`docs/STATUS.md`](docs/STATUS.md) pour l'état
> réel par module. Certaines briques sont opérationnelles bout en bout,
> d'autres sont en cours de stabilisation. Ce dépôt n'est pas production-ready.
🚀 **PRODUCTION-READY** - Phase 12 Complete (77% System Completion) ✅ *Dernière mise à jour : 14 avril 2026*
**Latest Update**: 14 Décembre 2024 ## Intention
- ✅ **10/13 Phases Complétées** - Système mature et fonctionnel
- ✅ **Performance Exceptionnelle** - 500-6250x plus rapide que requis
- ✅ **Architecture Entreprise** - 148k+ lignes, 19 modules, 6 specs complètes
- ✅ **Innovations Techniques** - Self-healing, Multi-modal, GPU management
- 📊 **Audit Complet** - [Rapport détaillé](AUDIT_COMPLET_SYSTEME_RPA_VISION_V3.md)
**Quick Test**: `bash test_clip.sh` Automatiser des workflows métier par **compréhension sémantique de l'écran**
plutôt que par coordonnées de clic fixes. Le système observe l'utilisateur,
reconstruit un graphe d'états de l'interface, et cherche à rejouer la
procédure en reconnaissant visuellement les éléments cibles — y compris
quand l'UI change légèrement.
## 🎯 Vision Terrain cible principal : postes hospitaliers (Citrix, applications métier
web et desktop). Contrainte forte : **100 % local**, pas d'appel à un LLM
cloud dans le pipeline par défaut.
RPA basé sur la **compréhension sémantique** des interfaces, pas sur des coordonnées de clics. ## Architecture en couches
Le système apprend des workflows en observant l'utilisateur et les automatise de manière robuste grâce à une architecture en 5 couches.
## 🏗️ Architecture en 5 Couches
``` ```
RawSession (Couche 0) RawSession (couche 0) — capture événements + screenshots
↓ ↓
ScreenState (Couche 1) - 4 niveaux d'abstraction ScreenState (couche 1) — états d'écran à plusieurs niveaux d'abstraction
↓ ↓
UIElement Detection (Couche 2) - Types + Rôles sémantiques UIElement (couche 2) — détection sémantique (cascade OCR + templates + VLM)
↓ ↓
State Embedding (Couche 3) - Fusion multi-modale State Embedding (couche 3) — fusion multi-modale + index FAISS
↓ ↓
Workflow Graph (Couche 4) - Nodes + Edges + Learning States Workflow Graph (couche 4) — nœuds, transitions, résolution de cibles
``` ```
## 📁 Structure ## État des fonctionnalités (synthèse)
``` Le détail par module est dans [`docs/STATUS.md`](docs/STATUS.md).
rpa_vision_v3/
├── core/
│ ├── models/ # Couches 0-4 : Structures de données
│ ├── capture/ # Couche 0 : Capture événements + screenshots
│ ├── detection/ # Couche 2 : Détection UI sémantique
│ ├── embedding/ # Couche 3 : Fusion multi-modale + FAISS
│ ├── graph/ # Couche 4 : Construction + Matching + Exécution
│ └── persistence/ # Sauvegarde/Chargement
├── data/
│ ├── sessions/ # RawSessions
│ ├── screen_states/ # ScreenStates
│ ├── embeddings/ # Vecteurs .npy
│ ├── faiss_index/ # Index FAISS
│ └── workflows/ # Workflow Graphs
└── tests/ # Tests unitaires + intégration
```
## 🚀 Démarrage Rapide **Opérationnel**
- Capture Windows (Agent V1) + streaming vers serveur Linux
- Stockage des sessions brutes (screenshots + événements)
- Streaming server FastAPI, sessions en mémoire
- Build du package Windows (`deploy/build_package.sh`)
**Alpha (fonctionnel sur un cas de référence, encore peu généralisé)**
- Détection UI par cascade VLM + OCR + templates
- Construction de workflow graph depuis une session
- Replay E2E supervisé — premier succès sur Notepad le 13 avril 2026
- Mode apprentissage : pause et demande d'aide humaine quand la résolution échoue
- Embeddings CLIP + index FAISS
- Module auth (Fernet + TOTP), federation (LearningPack)
- Web Dashboard, Agent Chat
**En cours**
- Visual Workflow Builder (VWB) — bugs DB runtime connus
- Self-healing / recovery global
- Analytics / reporting
- Worker de compilation sessions → ExecutionPlan
- Tests E2E multi-applications
## Limitations connues
- Le pipeline de replay est validé sur un nombre très restreint d'applications.
- `TargetMemoryStore` (apprentissage Phase 1) est câblé mais sa base reste
vide tant qu'un replay complet n'a pas été cristallisé.
- Certaines asymétries entre chemins stricts et legacy dans le serveur de
streaming peuvent provoquer des arrêts au lieu de pauses d'apprentissage.
- VWB n'est pas encore stable en écriture ; un outil dédié plus simple est
envisagé.
## Démarrage
### Prérequis
- Python 3.10 à 3.12
- [Ollama](https://ollama.ai) installé et démarré localement
- Recommandé : GPU NVIDIA pour l'inférence VLM
- Windows 10/11 uniquement pour le client Agent V1
### Installation ### Installation
```bash ```bash
# 1. Installer Ollama # 1) Cloner puis créer le venv
curl -fsSL https://ollama.ai/install.sh | sh # Linux python3 -m venv .venv
# ou source .venv/bin/activate
brew install ollama # macOS
# 2. Démarrer Ollama
ollama serve
# 3. Télécharger le modèle VLM
ollama pull qwen3-vl:8b
# 4. Installer dépendances Python
pip install -r requirements.txt pip install -r requirements.txt
# 2) Démarrer Ollama et récupérer le modèle VLM par défaut
ollama serve &
ollama pull gemma4:latest # défaut du projet
# Alternatives supportées :
# ollama pull qwen3-vl:8b
# ollama pull 0000/ui-tars-1.5-7b-q8_0:7b # grounder visuel
# 3) Copier et ajuster la configuration
cp .env.example .env
# éditer .env pour vérifier RPA_VLM_MODEL, VLM_ENDPOINT, ports, etc.
``` ```
### Test Rapide ### Lancer les services
Tous les services sont pilotés par `svc.sh` (source de vérité des ports :
`services.conf`).
```bash ```bash
# Diagnostic système ./svc.sh status # État de tous les services
python3 rpa_vision_v3/examples/diagnostic_vlm.py ./svc.sh start # Tout démarrer
./svc.sh start streaming # Streaming server uniquement (port 5005)
# Test de détection ./svc.sh restart api # Redémarrer l'API (port 8000)
./rpa_vision_v3/test_quick.sh ./svc.sh stop # Tout arrêter
``` ```
### Utilisation - Détection UI | Port | Service |
|---|---|
| 8000 | API Server (upload / traitement core) |
| 5001 | Web Dashboard |
| 5002 | VWB Backend (Flask) |
| 5003 | Monitoring |
| 5004 | Agent Chat |
| 5005 | Streaming Server (Agent V1 → pipeline core) |
| 5006 | Session Cleaner |
| 5099 | Worker de compilation (optionnel) |
| 3002 | VWB Frontend (Vite/React) |
```python ### Client Windows (Agent V1)
from rpa_vision_v3.core.detection import create_detector
# Créer le détecteur Le client capture souris, clavier et écran sur le poste Windows et envoie
detector = create_detector() les données au streaming server Linux.
# Détecter les éléments UI
elements = detector.detect("screenshot.png")
# Utiliser les résultats
for elem in elements:
print(f"{elem.type:15s} | {elem.role:20s} | {elem.label}")
```
### Utilisation - Workflow (Phase 4 - À venir)
```python
from rpa_vision_v3.core.models import RawSession, ScreenState, Workflow
from rpa_vision_v3.core.graph import GraphBuilder, NodeMatcher
# 1. Capturer une session
session = RawSession(...)
# ... capturer événements et screenshots
# 2. Construire workflow automatiquement
builder = GraphBuilder(...)
workflow = builder.build_from_session(session)
# 3. Matcher état actuel
matcher = NodeMatcher(...)
current_state = ScreenState(...)
match = matcher.match(current_state, workflow)
# 4. Exécuter action
if match:
edge = workflow.get_outgoing_edges(match.node.node_id)[0]
executor.execute_edge(edge, current_state)
```
## 📚 Documentation
### Guides Principaux
- **Quick Start** : `QUICK_START.md` - Démarrage rapide
- **Prochaines Étapes** : `NEXT_STEPS.md` - Roadmap et Phase 4
- **Phase 3 Complète** : `PHASE3_COMPLETE.md` - Résumé Phase 3
### Documentation Technique
- **Spec complète** : `.kiro/specs/workflow-graph-implementation/`
- **Architecture** : `docs/reference/ARCHITECTURE_VISION_COMPLETE.md`
- **Détection Hybride** : `HYBRID_DETECTION_SUMMARY.md`
- **Intégration Ollama** : `docs/OLLAMA_INTEGRATION.md`
## 🎓 Concepts Clés
### RPA 100% Vision
- ❌ Pas de coordonnées (x, y) fixes
- ✅ Rôles sémantiques (primary_action, form_input, etc.)
- ✅ Matching par similarité visuelle et textuelle
- ✅ Robuste aux changements d'UI
### Apprentissage Progressif
```
OBSERVATION (5+ exécutions)
↓
COACHING (10+ assistances, succès >90%)
↓
AUTO_CANDIDATE (20+ exécutions, succès >95%)
↓
AUTO_CONFIRMÉ (validation utilisateur)
```
### State Embedding
Fusion multi-modale :
- 50% Image (screenshot complet)
- 30% Texte (texte détecté)
- 10% Titre (fenêtre)
- 10% UI (éléments détectés)
## 🧪 Tests
```bash ```bash
# Tests unitaires # Build du package Windows depuis le repo Linux
pytest tests/unit/ ./deploy/build_package.sh
# produit deploy/Lea_v<version>.zip
# Tests d'intégration
pytest tests/integration/
# Tests de performance
pytest tests/performance/ --benchmark-only
``` ```
## 📈 Roadmap - 77% Complété (10/13 Phases) Voir [`docs/DEV_SETUP.md`](docs/DEV_SETUP.md) pour la maintenance du dépôt
(worktrees, build, services).
### ✅ **Phases Complétées** ## Arborescence du dépôt
- [x] **Phase 1-2** : Fondations + Embeddings FAISS ✅
- [x] **Phase 4-6** : Détection UI + Workflow Graphs + Action Execution ✅
- [x] **Phase 7-8** : Learning System + Training System ✅
- [x] **Phase 10-12** : GPU Management + Performance + Monitoring ✅
### 🎯 **Phases Restantes** ```
- [ ] **Phase 3** : Checkpoint Final (tests storage) rpa_vision_v3/
- [ ] **Phase 9** : Visual Workflow Builder (90% → 100%) ├── agent_v0/ # Agent V1 (client Windows) + serveur de streaming
- [ ] **Phase 13** : Tests End-to-End + Documentation finale │ ├── agent_v1/ # Source de l'agent (capture, UI tray, exécution)
│ └── server_v1/ # FastAPI streaming + processeurs
├── core/ # Pipeline core
│ ├── detection/ # Cascade VLM + OCR + templates
│ ├── embedding/ # CLIP + FAISS
│ ├── graph/ # Construction / matching de workflow graphs
│ ├── execution/ # Résolution de cibles, actions LLM
│ ├── learning/ # TargetMemoryStore (apprentissage)
│ ├── auth/ # Vault Fernet + TOTP
│ └── federation/ # Export/import de LearningPacks
├── visual_workflow_builder/ # VWB (backend Flask + frontend React Vite)
├── web_dashboard/ # Dashboard Flask + SocketIO
├── agent_chat/ # Interface conversationnelle + planner
├── deploy/ # Scripts de build et unités systemd
├── data/ # Sessions, embeddings, index FAISS, apprentissage
├── docs/ # Documentation technique
├── tests/ # pytest (unit, integration, e2e)
├── services.conf # Source de vérité des ports
├── svc.sh # Orchestrateur des services
└── run.sh # Démarrage tout-en-un (legacy, préférer svc.sh)
```
### 🚀 **Composants Production-Ready** ## Tests
- **Agent V0** : Capture cross-platform + Encryption ✅
- **Server API** : Processing pipeline + Web dashboard ✅
- **Analytics System** : Monitoring + Insights + Reporting ✅
- **Self-Healing** : Automatic adaptation + Recovery ✅
## 🤝 Contribution ```bash
source .venv/bin/activate
Voir `.kiro/specs/workflow-graph-implementation/tasks.md` pour les tâches en cours. # Tests rapides (hors marqueur slow)
pytest -m "not slow" -q
## 📄 Licence # Tests d'intégration (streaming, pipeline)
pytest tests/integration/ -q
Propriétaire - Tous droits réservés # Tests E2E
pytest tests/test_pipeline_e2e.py -q
```
Quelques tests legacy sont connus comme cassés — voir la mémoire projet et
`docs/` pour la liste.
## Documentation
- [`docs/STATUS.md`](docs/STATUS.md) — état réel par module
- [`docs/DEV_SETUP.md`](docs/DEV_SETUP.md) — tâches d'administration (worktrees, build)
- [`docs/VISION_RPA_INTELLIGENT.md`](docs/VISION_RPA_INTELLIGENT.md) — cahier des charges
- [`docs/PLAN_ACTEUR_V1.md`](docs/PLAN_ACTEUR_V1.md) — architecture 3 niveaux (Macro / Méso / Micro)
- [`docs/CONFORMITE_AI_ACT.md`](docs/CONFORMITE_AI_ACT.md) — journalisation, floutage, rétention
## Concepts clés
- **RPA 100 % vision** : pas de coordonnées fixes ; l'agent localise un
élément par ce qu'il voit (label + contexte visuel), pas par `x,y`.
- **Apprentissage progressif** : mode shadow → assisté → autonome, validé
par supervision humaine sur les échecs.
- **LLM 100 % local** : Ollama sur la machine. Aucun appel cloud dans le
pipeline par défaut (cf. feedback projet `feedback_local_only.md`).
## Licence
Propriétaire — tous droits réservés.

11
agent_v0/deploy_windows.py
View File

@@ -2,6 +2,17 @@
""" """
deploy_windows.py — Script de packaging du client Windows pour Agent V1. deploy_windows.py — Script de packaging du client Windows pour Agent V1.
⚠️ OBSOLÈTE (avril 2026)
Le build officiel du package Windows passe par ``deploy/build_package.sh``
(à la racine du repo) qui lit directement ``agent_v0/agent_v1/`` et évite
les clones intermédiaires. Ce script est conservé pour référence mais son
manifeste ``FILE_MANIFEST`` est incomplet : il n'inclut pas
``system_dialog_guard.py``, ``persistent_buffer.py``, ``recovery.py``,
``uia_helper.py``, ``grounding.py``, ``policy.py``,
``vision/blur_sensitive.py``, ``vision/system_info.py``,
``ui/chat_window.py``, ``ui/capture_server.py``, ``ui/shared_state.py``.
Ne PAS l'utiliser pour un packaging réel.
Copie uniquement les fichiers nécessaires au fonctionnement de l'agent Copie uniquement les fichiers nécessaires au fonctionnement de l'agent
sur le PC cible (Windows), sans le serveur ni les dépendances lourdes. sur le PC cible (Windows), sans le serveur ni les dépendances lourdes.

8
deploy/build_package.sh
View File

@@ -146,8 +146,14 @@ REQUIRED_FILES=(
"agent_v1/core/__init__.py" "agent_v1/core/__init__.py"
"agent_v1/core/captor.py" "agent_v1/core/captor.py"
"agent_v1/core/executor.py" "agent_v1/core/executor.py"
"agent_v1/core/grounding.py"
"agent_v1/core/policy.py"
"agent_v1/core/recovery.py"
"agent_v1/core/system_dialog_guard.py"
"agent_v1/core/uia_helper.py"
"agent_v1/network/__init__.py" "agent_v1/network/__init__.py"
"agent_v1/network/streamer.py" "agent_v1/network/streamer.py"
"agent_v1/network/persistent_buffer.py"
"agent_v1/session/__init__.py" "agent_v1/session/__init__.py"
"agent_v1/session/storage.py" "agent_v1/session/storage.py"
"agent_v1/ui/__init__.py" "agent_v1/ui/__init__.py"
@@ -156,6 +162,8 @@ REQUIRED_FILES=(
"agent_v1/ui/chat_window.py" "agent_v1/ui/chat_window.py"
"agent_v1/ui/capture_server.py" "agent_v1/ui/capture_server.py"
"agent_v1/ui/notifications.py" "agent_v1/ui/notifications.py"
"agent_v1/ui/activity_panel.py"
"agent_v1/ui/messages.py"
"agent_v1/vision/__init__.py" "agent_v1/vision/__init__.py"
"agent_v1/vision/capturer.py" "agent_v1/vision/capturer.py"
"agent_v1/vision/blur_sensitive.py" "agent_v1/vision/blur_sensitive.py"

107
docs/DEV_SETUP.md Normal file
View File

@@ -0,0 +1,107 @@
# DEV_SETUP — Guide développeur
Ce document recense les tâches d'administration du dépôt qui ne sont pas couvertes
par `README.md` (destiné aux utilisateurs) mais nécessaires au quotidien.
## Sommaire
- [Environnement Python](#environnement-python)
- [Services locaux](#services-locaux)
- [Worktrees Claude Code](#worktrees-claude-code)
- [Build du package Windows](#build-du-package-windows)
---
## Environnement Python
- Venv du projet : `.venv/` (à la racine du repo)
- Python supporté : 3.10 à 3.12
```bash
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```
## Services locaux
Utiliser `./svc.sh` pour piloter tous les services. La carte des ports est
dans `services.conf`.
```bash
./svc.sh status # État de tous les services
./svc.sh start streaming # Démarrer le serveur Agent V1 (port 5005)
./svc.sh restart api # Redémarrer l'API (port 8000)
./svc.sh stop # Tout arrêter
```
## Worktrees Claude Code
La CLI Claude Code peut créer des worktrees git dans `.claude/worktrees/` pour
exécuter des agents parallèles sur des branches isolées. Ces dossiers peuvent
occuper plusieurs centaines de Mo chacun et polluer les grep.
### Vérifier l'état des worktrees
```bash
# Worktrees actifs vs branches git
git worktree list
git branch | grep worktree
# Espace disque consommé
du -sh .claude/worktrees/* 2>/dev/null
```
### Supprimer un worktree proprement
```bash
# 1) Retirer l'entrée git (libère le lock dans .git/worktrees/)
git worktree remove .claude/worktrees/agent-<hash>
# 2) Si le dossier persiste (worktree orphelin), forcer le retrait
git worktree remove --force .claude/worktrees/agent-<hash>
# 3) Supprimer les branches worktree abandonnées
git branch -D worktree-agent-<hash>
```
### Nettoyage global
```bash
# Supprimer TOUS les worktrees et leurs branches associées
for wt in .claude/worktrees/*/; do
hash=$(basename "$wt")
git worktree remove --force "$wt" 2>/dev/null
done
git branch | grep worktree-agent- | xargs -r git branch -D
git worktree prune -v
# Nettoyer les branches orphelines (worktree supprimé mais branche subsiste)
git branch | grep worktree-agent- | xargs -r git branch -D
```
Le dossier `.claude/` est gitignoré — il ne sera jamais committé.
## Build du package Windows
Le package de déploiement pour le PC Windows des utilisateurs est généré par
`deploy/build_package.sh`. Il embarque `agent_v0/agent_v1/` directement (pas
de staging intermédiaire).
```bash
./deploy/build_package.sh # Build standard
./deploy/build_package.sh --clean # Nettoyer avant de builder
```
Le script vérifie la présence de tous les fichiers Python requis via la liste
`REQUIRED_FILES`. Si vous ajoutez un nouveau module Python critique côté agent
(ex: dans `agent_v1/core/` ou `agent_v1/network/`), **ajoutez-le à
`REQUIRED_FILES`** pour qu'un fichier manquant fasse échouer le build plutôt
que de produire un zip incomplet.
### Note historique : `agent_v0/deploy/windows_client/`
Ce dossier a été créé par `agent_v0/deploy_windows.py` comme staging de build
et s'est désynchronisé. Il a été supprimé en avril 2026 — le build officiel
passe désormais par `deploy/build_package.sh` qui lit directement
`agent_v0/agent_v1/`.

112
docs/STATUS.md Normal file
View File

@@ -0,0 +1,112 @@
# 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 |
| 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é |
| 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