- Frontend v4 accessible sur réseau local (192.168.1.40) - Ports ouverts: 3002 (frontend), 5001 (backend), 5004 (dashboard) - Ollama GPU fonctionnel - Self-healing interactif - Dashboard confiance Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
8.6 KiB
8.6 KiB
Analyse Dashboard - Incohérences Identifiées
Date: 7 janvier 2026 - 22:40 Objectif: Identifier pourquoi le dashboard ne reflète pas l'activité réelle
📊 État Actuel des Données
Données RÉELLES sur le système
/opt/rpa_vision_v3/data/training/
├── sessions/ → 8 dossiers (sessions brutes, certaines non traitées)
├── screen_states/ → 236 fichiers JSON (données EXPLOITABLES après traitement)
│ └── 2026-01-07/
├── workflows/ → 2 fichiers JSON
├── embeddings/ → (vides en .npy, stockés dans FAISS)
├── faiss_index/ → Index vectoriel
├── chains/ → Chaînes de workflows
└── triggers/ → Déclencheurs automatiques
Ce que le dashboard AFFICHE actuellement
- Sessions count: 8 (compte les dossiers bruts dans sessions/)
- Workflows count: 2 ✅ (correct)
- Tests count: 56 ✅ (correct)
- Sessions list: Affiche sessions BRUTES avec
screenshots_count: 0❌
🔴 Problèmes Identifiés
Problème 1 - Chemin Screenshots Incorrect
Fichier: /opt/rpa_vision_v3/web_dashboard/app.py
Ligne: 207
Code actuel :
screenshots_dir = session_dir / "screenshots" # MAUVAIS !
screenshot_files = list(screenshots_dir.glob('*.png')) if screenshots_dir.exists() else []
Problème :
- Cherche dans
session_dir/screenshots/ - Mais les screenshots sont dans
session_dir/<session_id>/shots/*.png - Résultat :
screenshots_count: 0pour TOUTES les sessions
Impact :
- L'onglet "Sessions" affiche toujours 0 screenshots même avant le nettoyage
- L'utilisateur pense qu'il n'y a pas de données
Problème 2 - Screen States Invisibles
Situation :
- 236 screen_states créés et sauvegardés dans
/data/training/screen_states/2026-01-07/ - Ces fichiers JSON contiennent les données RÉELLES après traitement :
- Métadonnées des événements
- Références aux embeddings
- Contexte business
- Tags et workflow candidat
- AUCUNE route API pour les lister
- AUCUN onglet pour les visualiser
Impact :
- Les données traitées (qui sont les VRAIES données exploitables) sont invisibles
- L'utilisateur ne peut pas voir le résultat de l'apprentissage
- Impossible de valider que le traitement a fonctionné
Problème 3 - Sessions Count Trompeur
Fichier: /opt/rpa_vision_v3/web_dashboard/app.py
Ligne: 115
Code actuel :
sessions_count = len(list(SESSIONS_PATH.glob('*'))) if SESSIONS_PATH.exists() else 0
Problème :
- Compte les dossiers dans
sessions/(données BRUTES) - Après nettoyage post-apprentissage, ces dossiers sont SUPPRIMÉS
- Le compteur ne reflète PAS le nombre de sessions réellement traitées et exploitables
- Compte aussi des dossiers vides, en erreur, ou non traités (ex:
test_session_123,2025-11-29)
Impact :
- L'utilisateur voit "8 sessions" mais ne sait pas :
- Combien sont traitées ?
- Combien sont en attente ?
- Combien ont échoué ?
Problème 4 - Pas de Stats de Processing
Situation :
- Le
processing_pipeline.pygénère des statistiques détaillées :stats = { "session_id": session_id, "screen_states_created": 40, "embeddings_generated": 40, "ui_elements_detected": 15, "workflow_created": True, "patterns_detected": 3, "errors": [] } - Ces stats sont loguées mais JAMAIS affichées dans le dashboard
- L'utilisateur ne peut pas voir :
- Combien de sessions traitées aujourd'hui ?
- Combien d'embeddings générés au total ?
- Combien de patterns détectés ?
- Gain d'espace disque après cleanup ?
Impact :
- Impossible de monitorer l'apprentissage
- Pas de feedback sur l'efficacité du système
- Démo investisseurs moins impactante (pas de métriques visuelles)
Problème 5 - Confusion Raw vs Processed
Situation :
- Le dashboard montre les sessions RAW (avant traitement)
- Mais l'utilisateur veut voir les sessions TRAITÉES (après apprentissage)
- Aucune distinction visuelle entre :
- Sessions en attente de traitement
- Sessions en cours de traitement
- Sessions traitées avec succès
- Sessions en erreur
Impact :
- L'utilisateur ne sait pas si le système fonctionne
- Confusion entre données brutes et données exploitables
Problème 6 - Screenshots Deleted After Learning
Situation :
- Après traitement réussi, les screenshots sont supprimés (ligne 163-169 de processing_pipeline.py)
- C'est NORMAL et souhaité (gain d'espace ~99%)
- Mais le dashboard a :
- Bouton "📸 Screenshots" (ligne 620 de index.html)
- Route
/api/agent/sessions/<session_id>/screenshot/<filename>(ligne 285 de app.py) - Ces fonctions retournent 404 après cleanup
Impact :
- Bouton "Screenshots" ne fonctionne plus après traitement
- Erreur 404 frustrante pour l'utilisateur
- Pas d'indication que les screenshots ont été supprimés (normal) vs erreur
✅ Ce Qui Fonctionne Correctement
- ✅ Workflows count (2 workflows détectés)
- ✅ Tests count (56 tests)
- ✅ WebSocket temps réel
- ✅ Exécution de workflows
- ✅ Chains et Triggers
- ✅ Logs et métriques Prometheus
- ✅ Healthcheck endpoint
🎯 Objectifs de la Correction
1. Afficher les Screen States
- Nouvelle route API :
/api/screen_states - Nouveau tab "📊 Données Traitées" dans le dashboard
- Liste des screen_states par date
- Groupement par session_id
- Affichage des métadonnées (tags, workflow candidat, timestamp)
2. Stats de Processing
- Nouvelle route API :
/api/processing/stats - Affichage dans l'onglet "Vue d'ensemble" :
- Sessions traitées (vs brutes)
- Screen states créés
- Embeddings générés
- Patterns détectés
- Gain d'espace disque
- Historique par jour/semaine
3. Corriger le Chemin Screenshots
- Fixer ligne 207 de app.py :
screenshots_dir = session_dir / session_id / "shots" - Ajouter vérification : si screenshot n'existe plus (après cleanup), afficher message clair
4. Statut de Traitement
- Ajouter colonne "Statut" dans la liste des sessions :
- 🟡 En attente
- 🔵 En cours
- 🟢 Traité
- 🔴 Erreur
- Basé sur l'existence des screen_states correspondants
5. Clarifier Raw vs Processed
- Renommer l'onglet "Sessions" en "Sessions Brutes"
- Ajouter onglet "Sessions Traitées" (basé sur screen_states)
- Afficher les deux compteurs :
- Sessions brutes : X (en attente de traitement)
- Sessions traitées : Y (exploitables)
⚠️ Risques et Mitigation
Risque 1 - Casser l'API existante
Mitigation :
- AJOUTER de nouvelles routes SANS modifier les anciennes
- Garder
/api/agent/sessionsintact pour compatibilité - Nouvelles routes :
/api/screen_states,/api/processing/stats
Risque 2 - Frontend JavaScript cassé
Mitigation :
- AJOUTER de nouveaux tabs SANS modifier les existants
- Garder le code JavaScript existant fonctionnel
- Nouvelles fonctions JavaScript isolées
Risque 3 - Performance (236 screen_states)
Mitigation :
- Pagination sur
/api/screen_states(50 par page) - Cache côté serveur pour les stats
- Lazy loading dans le frontend
Risque 4 - Services externes cassés
Mitigation :
- Vérifier si d'autres services appellent
/api/agent/sessions - Tester l'API après modifications
- Garder les anciennes routes en parallèle
📋 Plan d'Action Recommandé
Phase 1 - Fix Critique (30 min)
- ✅ Corriger le chemin screenshots (ligne 207)
- ✅ Ajouter route
/api/screen_states - ✅ Tester sans casser l'existant
Phase 2 - Stats Processing (45 min)
- Créer
/api/processing/stats - Sauvegarder les stats du pipeline dans un fichier JSON
- Afficher dans le dashboard
Phase 3 - Interface Améliorée (1h)
- Ajouter onglet "Données Traitées"
- Afficher screen_states groupés par session
- Ajouter statut de traitement
Phase 4 - Tests et Validation (30 min)
- Tester toutes les routes API
- Vérifier que rien n'est cassé
- Valider avec une nouvelle session
📊 Métriques de Succès
Après les corrections, le dashboard devra afficher :
- ✅ 236 screen_states visibles et exploitables
- ✅ Statut de traitement pour chaque session
- ✅ Stats de processing en temps réel
- ✅ Distinction claire entre données brutes et traitées
- ✅ Pas de 404 sur les screenshots (message clair si supprimés)
- ✅ 0 régression sur les fonctionnalités existantes
Version : 1.0 - Analyse Complète Status : ⏳ En attente de validation utilisateur avant implémentation