Document de référence avec : - Évaluation des 3 moats (Techno 85%, Data 60%, Déploiement 50%) - Inventaire fonctionnel complet (179 fichiers core) - Points de friction identifiés - Actions requises court/moyen/long terme - Références techniques (ports, commandes, structure) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
10 KiB
10 KiB
Analyse MOAT - RPA Vision V3
Date: 18 janvier 2026 Version: 1.0 Objectif: Photographie complète du projet pour valider les avantages concurrentiels défendables
Résumé Exécutif
| MOAT | Score | Statut |
|---|---|---|
| Techno (Hard to Copy) | 85% | Point fort |
| Data/Apprentissage (Hard to Catch Up) | 60% | Infrastructure OK, capitalisation à améliorer |
| Déploiement Santé (Hard to Enter) | 50% | Technique OK, docs compliance manquantes |
MOAT 1 : TECHNO (Hard to Copy)
Capacités Implémentées
| Capacité | État | Détails |
|---|---|---|
| Vision-native | Implémenté | CLIP ViT-B-32 (512-dim) + OWL-v2 zero-shot + OpenCV + Qwen2.5-VL |
| Matching hiérarchique | Implémenté | 3 niveaux : fenêtre (20%) + région (30%) + élément (50%) |
| Self-healing | Implémenté | 4 stratégies actives |
| Cascade fallbacks | Implémenté | Circuit breaker + state machine 5 états |
| Traces/Policies | Implémenté | Audit JSONL rotatif, execution history, confidence scoring |
| VDI/Citrix | Conçu pour | Architecture vision-only compatible, tests à documenter |
Self-Healing - 4 Stratégies
- Semantic Variants - Variantes sémantiques des cibles
- Spatial Fallback - Recherche éléments proches
- Timing Adaptation - Ajustement des délais
- Format Transformation - Transformation de formats
Circuit Breaker - Seuils
| Condition | Action |
|---|---|
| 3 échecs consécutifs | → DEGRADED |
| 10 échecs en 600s par workflow | → QUARANTINED |
| 30 échecs globaux en fenêtre | → GLOBAL_PAUSE |
| X succès consécutifs | → Reset |
State Machine Exécution
RUNNING ↔ DEGRADED ↔ QUARANTINED
↕ ↕ ↕
PAUSED ROLLBACK (reset)
Fichiers Clés
/core/execution/- 12 fichiers (action_executor, target_resolver, error_handler, recovery_strategies)/core/healing/- 7 fichiers (healing_engine, learning_repository, 4 stratégies)/core/matching/hierarchical_matcher.py- Matching multi-niveau/core/system/circuit_breaker.py- Protection contre cascades d'erreurs/core/system/auto_heal_manager.py- Machine d'état
Verdict : 85% validé - La cascade fallbacks + healing + policies existe réellement.
MOAT 2 : DATA / APPRENTISSAGE (Hard to Catch Up)
Capacités Implémentées
| Capacité | État | Détails |
|---|---|---|
| Cas d'écran | Complet | 4 niveaux de stockage |
| Learning states | Implémenté | 4 états de progression |
| Drift detection | Implémenté | Création variantes automatique |
| Corrections utilisateur | Partiel | Stockées mais pas packagées |
| Templates/Packs | Basique | Statiques uniquement |
| Corpus | À construire | Structure prête |
Format des Cas d'Écran (4 niveaux)
Niveau 1 : Raw Capture (RawSession)
data/sessions/YYYY-MM-DD/session_*.json
- events[] avec timestamps
- screenshots[] avec paths
- window context
Niveau 2 : Perception (ScreenState)
data/screen_states/YYYY-MM-DD/state_*.json
- raw_level (screenshot, capture_method)
- perception_level (embedding, detected_text, confidence)
- context_level (workflow_candidate, business_variables)
Niveau 3 : Vector Index (FAISS)
data/faiss_index/main.faiss + main_metadata.json
data/embeddings/YYYY-MM-DD/state_*.npy (512 dimensions)
Niveau 4 : Training Dataset
training_data/session_*.json
- screenshots, actions, user_corrections, success
États d'Apprentissage
OBSERVATION → COACHING → AUTO_CANDIDATE → AUTO_CONFIRMED
↑ |
+------ (régression détectée) -------------+
- 5+ observations (conf > 0.90) → COACHING
- Drift detection : 3 matchs faibles → création variante
- Max 5 variantes par node
Manques Identifiés
| Item | Impact |
|---|---|
| Pas de "Correction Packs" | Corrections isolées par session |
| Pas d'héritage cross-workflow | Réapprentissage nécessaire |
| Pas d'export/import corrections | Difficile à partager |
Fichiers Clés
/core/learning/- 5 fichiers (learning_manager, continuous_learner, feedback_processor)/core/training/- 5 fichiers (offline_trainer, session_analyzer, training_data_collector)/core/persistence/storage_manager.py- Gestionnaire centralisé/core/embedding/faiss_manager.py- Index vectoriel
Verdict : 60% validé - Infrastructure OK, capitalisation cross-workflow manquante.
MOAT 3 : DÉPLOIEMENT SANTÉ (Hard to Enter)
Capacités Implémentées
| Capacité | État | Détails |
|---|---|---|
| On-prem | Ready | 100% local, pas de cloud obligatoire |
| Sécurité | Implémenté | IP allowlist, rate limiter, tokens, audit |
| Traçabilité | Implémenté | 8 types d'événements, rotation logs |
| Encryption | Implémenté | Sessions chiffrées |
| Playbook DSI/RSSI | À documenter | Pas de doc formelle |
| Certifications | À préparer | Pas de certifications |
Sécurité - Détails
Audit Log (8 types d'événements)
- auth_success, auth_failure
- api_access
- rate_limit_exceeded
- security_violation
- permission_denied
- data_access
- admin_action
Caractéristiques
- Format JSONL pour parsing
- Hachage données sensibles optionnel
- Rotation auto (10MB max, 10 fichiers)
- Métadonnées : user_id, IP, endpoint, user_agent, token_hash
Fichiers Clés
/core/security/audit_log.py- Logging sécurisé/core/security/api_tokens.py- Gestion tokens/core/security/ip_allowlist.py- Whitelist IP/core/security/rate_limiter.py- Rate limiting/server/storage_encrypted.py- Encryption sessions
Manques Identifiés
| Item | Priorité |
|---|---|
| Documentation compliance santé | Haute |
| Playbook DSI/RSSI | Haute |
| Certifications (HDS, ISO 27001) | Moyenne |
| Tests VDI/Citrix documentés | Moyenne |
Verdict : 50% validé - Technique OK, documentation compliance à faire.
Inventaire Fonctionnel Complet
Composants Opérationnels
| Composant | Port | État | Fichiers |
|---|---|---|---|
| Visual Workflow Builder Frontend | 3000 | Opérationnel | React 19, React Flow v12 |
| Visual Workflow Builder Backend | 5000 | Opérationnel | Flask, 24+ actions |
| Agent Chat (LLM) | 5002 | Opérationnel | Intent parsing + Ollama |
| Web Dashboard | 5004 | Opérationnel | Monitoring temps réel |
| Core Execution | - | Opérationnel | ActionExecutor, TargetResolver |
| Self-Healing Engine | - | Opérationnel | 4 stratégies |
| Analytics System | - | Opérationnel | SQLite + reporting |
Catalogue d'Actions VWB (24+)
vision_ui/ (14 actions)
- click_anchor, type_text, type_secret
- screenshot_evidence, wait_for_anchor
- scroll_to_anchor, focus_anchor, hotkey
- double_clic, clic_droit, glisser_deposer
- survol_element, extract_text
navigation/ (2)
- navigate_to_url, browser_back
data/ (2)
- telecharger_vers_dossier, extraire_tableau
database/ (3)
- sauvegarder_donnees, charger_donnees, gestionnaire_db
validation/ (2)
- verify_element_exists, verify_text_content
intelligence/ (1)
- analyser_avec_ia
Points de Friction Connus
| Item | Problème | Impact |
|---|---|---|
| FAISS dimension arg | Incompatibilité version | Apprentissage embeddings |
| Agent Chat exécution | Mode optionnel | Fallback simulation |
| Cross-workflow learning | Corrections isolées | Capitalisation limitée |
Architecture Core (179 fichiers Python)
/core/
├── execution/ (12) - Exécution et robustesse
├── healing/ (7) - Self-healing et recovery
├── learning/ (5) - Apprentissage continu
├── training/ (5) - Entraînement offline
├── security/ (7) - Audit, tokens, validation
├── detection/ (5) - UI hybride OWL+OpenCV+VLM
├── embedding/ (8) - CLIP, FAISS, fusion
├── visual/ (8) - Gestion cibles visuelles
├── matching/ (2) - Matching hiérarchique
├── analytics/ (11) - Collection, engine, reporting
├── system/ (8) - Circuit breaker, auto-heal
├── monitoring/ (8) - Métriques, scheduling
├── persistence/ (1) - StorageManager centralisé
├── models/ (8) - Structures de données
└── evaluation/ (3) - Replay, simulation
Actions Requises
Court Terme (Semaines)
| Action | Priorité | Effort |
|---|---|---|
| Documenter playbook DSI/RSSI | Haute | Faible |
| Corriger FAISS dimension error | Haute | Faible |
| Tester et documenter VDI/Citrix | Moyenne | Moyen |
Moyen Terme (Mois)
| Action | Priorité | Effort |
|---|---|---|
| Système de Correction Packs | Haute | Moyen |
| Export/Import corrections cross-workflows | Haute | Moyen |
| Documentation compliance santé | Haute | Moyen |
Long Terme
| Action | Priorité | Effort |
|---|---|---|
| Certifications santé (HDS, ISO 27001) | Variable | Élevé |
| Accumulation corpus production | Continue | - |
Conclusion
RPA Vision V3 est un moat technique solide avec :
- Architecture vision-native défendable
- Self-healing réel avec 4 stratégies
- Infrastructure d'apprentissage complète
- Sécurité et traçabilité opérationnelles
Pour un moat complet :
- Capitaliser les corrections cross-workflows (Correction Packs)
- Documenter compliance santé (playbook DSI/RSSI)
- Alimenter le corpus en production (vraie douve long terme)
Références Techniques
Ports par défaut
| Service | Port |
|---|---|
| VWB Backend | 5000 |
| VWB Frontend | 3000 |
| Web Dashboard | 5004 |
| Agent Chat | 5002 |
| API Upload | 8000 |
| Ollama | 11434 |
Commandes de démarrage
# Dashboard (avec service systemd)
sudo systemctl start rpa-dashboard
# → http://localhost:5004
# Agent Chat
./venv_v3/bin/python -m agent_chat.app
# → http://localhost:5002
# VWB
cd visual_workflow_builder/backend && ./start.sh
cd visual_workflow_builder/frontend && npm start
Structure données
data/
├── sessions/YYYY-MM-DD/ # RawSession JSON
├── screen_states/YYYY-MM-DD/ # ScreenState JSON
├── embeddings/YYYY-MM-DD/ # NPY + métadonnées
├── faiss_index/ # Index vectoriel
├── workflows/ # Workflows JSON
├── templates/ # Templates statiques
└── analytics/ # Métriques SQLite