rpa_vision_v3/docs/plans/EVALUATION_BLOCS_VWB.md

Evaluation exhaustive des blocs VWB -- Demo 26 avril 2026

Date : 13 avril 2026 Objectif : Savoir exactement ce qui marche, ce qui est stub, ce qui manque.

---

Section A -- Inventaire complet des blocs (37 blocs)

SOURIS (7 blocs)

Bloc	action_type	Backend execute.py	Backend BaseVWBAction	Fonctionnel ?
Clic	click_anchor	OUI (basic + vision)	OUI (VWBClickAnchorAction)	OUI
Double-clic	double_click_anchor	OUI	OUI (VWBDoubleClickAnchorAction)	OUI
Clic droit	right_click_anchor	OUI	OUI (VWBRightClickAnchorAction)	OUI
Survol	hover_anchor	NON dans execute.py	OUI (VWBSurvolElementAction)	PARTIEL -- pas wire dans l'executeur lineaire
Glisser-deposer	drag_drop_anchor	NON dans execute.py	OUI (VWBGlisserDeposerAction)	PARTIEL -- idem
Defiler vers	scroll_to_anchor	NON dans execute.py	OUI (VWBScrollToAnchorAction)	PARTIEL -- idem
Focus	focus_anchor	NON dans execute.py	OUI (VWBFocusAnchorAction)	PARTIEL -- idem

Diagnostic : Seuls click, double-click, right-click sont cables dans execute_action(). Les 4 autres ont des classes backend mais ne sont pas dispatches a l'execution.

CLAVIER (3 blocs)

Bloc	action_type	Backend	Fonctionnel ?
Saisir texte	type_text	OUI (safe_type_text AZERTY)	OUI
Saisir secret	type_secret	OUI (VWBTypeSecretAction)	OUI (via credential_vault)
Raccourci clavier	keyboard_shortcut	OUI (pyautogui.hotkey)	OUI

Diagnostic : Les 3 fonctionnent. type_text supporte la substitution {{variable}}.

ATTENTE (1 bloc)

Bloc	action_type	Backend	Fonctionnel ?
Attendre element	wait_for_anchor	OUI (time.sleep)	PARTIEL -- fait un sleep, pas de detection visuelle d'apparition

Diagnostic : Fonctionne comme un timer, mais ne fait PAS de polling visuel "attendre que l'element apparaisse". Le DAGExecutor le traite comme un StepType.WAIT.

DONNEES (7 blocs)

Bloc	action_type	Backend	Fonctionnel ?
Extraire texte	extract_text	VWBExtractTextAction	STUB -- _find_visual_element retourne random, _perform_ocr_extraction retourne du texte hardcode
Extraire tableau	extract_table	VWBExtraireTableauAction	OPERATIONNEL -- appel Ollama reel avec prompt structurel, fallback OCR
Capture preuve	screenshot_evidence	VWBScreenshotEvidenceAction	OUI
Telecharger	download_to_folder	VWBTelechargerVersDossierAction	A verifier -- fichier existe
Sauvegarder BDD	db_save_data	VWBSauvegarderDonneesAction	OPERATIONNEL -- SQLite via GestionnaireDB
Lire BDD	db_read_data	VWBChargerDonneesAction	OPERATIONNEL -- SQLite via GestionnaireDB
Importer Excel	import_excel	ExcelImporter (core/data/)	OPERATIONNEL -- import .xlsx dans SQLite, detection de types

BOUCLE DONNEES (1 bloc)

Bloc	action_type	Backend	Fonctionnel ?
Pour chaque ligne	db_foreach	DBIterator + DAG sub-execution	OPERATIONNEL -- itere sur table SQLite, injecte ${current_row.colonne}, execute sous-DAG par ligne

Diagnostic : Le pipeline import_excel -> db_foreach est completement implemente dans dag_execute.py. C'est le mecanisme de boucle de donnees le plus mature du projet.

LOGIQUE (2 blocs)

Bloc	action_type	Backend	Fonctionnel ?
Condition visuelle	visual_condition	DAGExecutor (StepType.CONDITION)	PARTIEL -- le DAGExecutor evalue la condition via safe_eval_condition, mais le frontend n'a pas de vrai branchement visuel (edges on_found/on_not_found)
Boucle visuelle	loop_visual	AUCUN	NON IMPLEMENTE -- present dans la palette, aucun handler backend

Diagnostic : visual_condition a un squelette dans le DAGExecutor mais n'est pas connecte a la detection visuelle "est-ce que l'ancre est visible ?". loop_visual est un placeholder UI pur -- aucun code backend.

IA (6 blocs)

Bloc	action_type	Backend	Fonctionnel ?
OCR Intelligent	ai_ocr	Non cable	NON -- pas de handler
Resume IA	ai_summarize	Non cable	NON -- pas de handler
Extraction IA	ai_extract	Non cable	NON -- pas de handler
Classification IA	ai_classify	Non cable	NON -- pas de handler
Analyse complete	ai_analyze_text	OUI (execute_ai_analyze)	OPERATIONNEL -- appel Ollama reel, mode texte + mode image, variables {{}}
IA Personnalisee	ai_custom	Non cable	NON -- pas de handler

Diagnostic : Seul ai_analyze_text est cable et fonctionnel. Les 5 autres sont des placeholders. Ils pourraient tous passer par execute_ai_analyze avec des prompts differents -- c'est 1-2 jours de travail.

IA / LLM (4 blocs -- DAGExecutor)

Bloc	action_type	Backend	Fonctionnel ?
Analyser texte	llm_analyze	LLMActionHandler.analyze_text	OPERATIONNEL -- Ollama /api/chat
Traduire	llm_translate	LLMActionHandler.translate	OPERATIONNEL -- Ollama /api/chat
Extraire donnees	llm_extract_data	LLMActionHandler.extract_data	OPERATIONNEL -- JSON schema extraction
Generer texte	llm_generate	LLMActionHandler.generate_text	OPERATIONNEL -- Ollama /api/chat

Diagnostic : Les 4 blocs LLM/DAG sont completement operationnels. Execution parallele via ThreadPool. Injection de resultats ${step_id.result}.

FICHIERS (5 blocs)

Bloc	action_type	Backend	Fonctionnel ?
Lister dossier	file_list_dir	FileActionHandler._list_dir	OPERATIONNEL -- avec securite path traversal
Creer dossier	file_create_dir	FileActionHandler._create_dir	OPERATIONNEL
Deplacer fichier	file_move	FileActionHandler._move_file	OPERATIONNEL
Copier fichier	file_copy	FileActionHandler._copy_file	OPERATIONNEL
Classer par ext	file_sort_by_ext	FileActionHandler._sort_by_extension	OPERATIONNEL

Diagnostic : Les 5 blocs fichiers sont implementes dans file_actions.py avec validation de securite. Mais ils ne sont pas dispatches dans execute_action() (executeur lineaire) -- seulement accessibles via le DAGExecutor (les types sont declares dans _FILE_ACTION_TYPES de dag_execute.py, mais le dispatch dans _execute_ui_step du DAG passe par le ui_handler qui n'a pas de logique pour les fichiers). Il faut cabler le dispatch.

VALIDATION (2 blocs)

Bloc	action_type	Backend	Fonctionnel ?
Verifier presence	verify_element_exists	VWBVerifyElementExistsAction	PARTIEL -- classe existe, pas cable dans execute_action
Verifier texte	verify_text_content	VWBVerifyTextContentAction	OPERATIONNEL -- OCR via Ollama + docTR, matching multi-mode

---

Section B -- Blocs operationnels (prets pour la demo)

Pret a l'emploi (17 blocs)

1. click_anchor -- Clic gauche (basic + vision intelligente + self-healing)
2. double_click_anchor -- Double-clic
3. right_click_anchor -- Clic droit
4. type_text -- Saisie texte (AZERTY, variables {{var}})
5. type_secret -- Saisie mot de passe (credential vault)
6. keyboard_shortcut -- Raccourci clavier
7. ai_analyze_text -- Analyse IA (Ollama, mode texte + image)
8. llm_analyze -- Analyse LLM parallele
9. llm_translate -- Traduction LLM
10. llm_extract_data -- Extraction structuree JSON
11. llm_generate -- Generation texte
12. import_excel -- Import Excel dans SQLite
13. db_foreach -- Boucle sur table (injection ${current_row.col})
14. db_save_data -- Sauvegarde BDD (cle-valeur + collections)
15. db_read_data -- Lecture BDD
16. extract_table -- Extraction tableau (Ollama VLM)
17. verify_text_content -- Verification texte (OCR Ollama + docTR)

Pipeline data-loop fonctionnel

Le chemin import_excel -> db_foreach -> (sous-workflow par ligne) est completement implemente et teste dans dag_execute.py :

• Upload Excel via /api/v3/upload-excel
• Import automatique dans SQLite
• Iteration avec injection de colonnes
• Sous-DAG execute par ligne (LLM parallele + UI sequentiel)

---

Section C -- Blocs a completer (effort estime)

Bloc	Ce qui manque	Effort
hover_anchor	Ajouter elif action_type == 'hover_anchor' dans execute_action() avec pyautogui.moveTo()	0.5h
drag_drop_anchor	Ajouter dispatch + pyautogui.moveTo + drag	1h
scroll_to_anchor	Ajouter dispatch + pyautogui.scroll()	0.5h
focus_anchor	Ajouter dispatch + pyautogui.click()	0.5h
wait_for_anchor	Remplacer sleep par boucle de detection visuelle (screenshot + match)	2-4h
extract_text	Remplacer le stub par un vrai appel OCR (Ollama VLM ou docTR) -- le pattern existe deja dans verify_text_content	2-4h
visual_condition	Connecter la detection visuelle (ancre trouvee ?) au branchement du DAG + gerer les edges on_found/on_not_found dans le frontend	1-2j
verify_element_exists	Cabler dans execute_action() -- la classe backend est prete	1h
file_* (5 blocs)	Cabler le dispatch dans execute_action() ou dans le ui_handler du DAGExecutor	2-4h
ai_ocr, ai_summarize, ai_extract, ai_classify, ai_custom	Creer des wrappers autour de execute_ai_analyze avec des prompts systeme specifiques	1-2j

---

Section D -- Blocs manquants (a creer)

Fonctionnalite	Description	Effort
loop_visual (boucle visuelle)	Repeter tant qu'une ancre est visible. Necessite : boucle de detection + condition de sortie + limite iterations + gestion dans le DAG	2-3j
set_variable / get_variable	Blocs explicites pour definir/lire des variables. Actuellement fait implicitement via output_variable dans les params -- pas de bloc dedie	0.5j (optionnel)
Export CSV/Excel	Exporter les resultats dans un fichier. Pas de bloc dedie.	1j
Envoyer email	Notification des resultats. Absent.	1-2j
Attente conditionnelle	wait_until_text("Chargement termine", timeout=30s). Combine wait + OCR.	1-2j

---

Section E -- Faisabilite des 3 cas d'usage

Cas A : "Traite toutes les factures du mois"

Besoins : variable mois, boucle sur factures, extraction montant

Composant	Bloc VWB	Statut
Importer la liste de factures	import_excel	VERT
Boucler sur chaque facture	db_foreach	VERT
Ouvrir chaque facture (clic)	click_anchor	VERT
Extraire le montant (OCR)	extract_text	ORANGE -- stub, mais extract_table + ai_analyze_text fonctionnent
Saisir dans le SI	type_text + {{current_row.montant}}	VERT
Sauvegarder le resultat	db_save_data	VERT

Verdict : ORANGE -- faisable avec 2-4h de travail pour remplacer le stub extract_text par un appel Ollama VLM (le pattern existe dans extract_table et verify_text_content).

Alternative immediate : utiliser ai_analyze_text avec un prompt "Extrait le montant de cette facture" au lieu de extract_text. Fonctionne aujourd'hui.

Cas B : "Recupere tous les CR de tous les dossiers de la journee"

Besoins : variable date_jour, iterateur sur dossiers, extraction CR, stockage

Composant	Bloc VWB	Statut
Importer la liste de dossiers	import_excel ou db_read_data	VERT
Boucler sur chaque dossier	db_foreach	VERT
Naviguer vers le dossier (clics)	click_anchor + type_text	VERT
Extraire le CR (texte)	ai_analyze_text (mode image)	VERT
Sauvegarder le CR	db_save_data	VERT
Variable date du jour	Pas de bloc dedie, mais {{date_jour}} dans type_text marche si variable initialisee	VERT (si pre-setee)

Verdict : VERT -- faisable avec l'existant. Le chemin complet import_excel -> db_foreach -> (navigation + extraction IA + sauvegarde) est operationnel. La variable date_jour doit etre initialisee au debut du workflow (via le VariableManager du frontend).

Cas C : "Code les diagnostics de ce dossier patient"

Besoins : extraction texte medical, appel LLM pour CIM-10, saisie dans le DPI

Composant	Bloc VWB	Statut
Ouvrir le dossier patient	click_anchor	VERT
Extraire le texte medical	ai_analyze_text (mode image, prompt: "Extrait le texte medical")	VERT
Suggerer codes CIM-10	llm_analyze (prompt: "Propose les codes CIM-10 pour ce texte")	VERT
Afficher/valider la suggestion	Pas de bloc "dialogue humain" -- necessite le mode supervised	ORANGE -- le mode paused_need_help existe dans l'executeur
Saisir les codes dans le DPI	type_text + clic	VERT

Verdict : ORANGE -- faisable pour la demo avec 1j de preparation. La chaine extraction -> LLM CIM-10 -> saisie fonctionne. Le maillon faible est la validation humaine intermediaire -- mais pour une demo, on peut le montrer en mode step-by-step (pause entre etapes).

---

Section F -- Recommandation pour la demo du 26 avril

A montrer en live (confiance haute)

1. Workflow record-and-replay basique : clic -> saisie texte -> raccourci clavier. Fonctionne deja.

2. Pipeline data-loop Excel : importer un fichier Excel de 5-10 lignes, boucler avec db_foreach, remplir un formulaire web par ligne. C'est le cas d'usage le plus impressionnant et le plus solide techniquement. Preparer un formulaire web simple ou utiliser un outil metier reel.

3. Extraction + IA : capturer un ecran d'application, lancer ai_analyze_text pour extraire des informations, montrer le resultat en temps reel. Parfait pour le cas "codage diagnostique".

4. Execution DAG parallele : montrer que pendant qu'un LLM analyse un texte (10-30s), le workflow continue a executer d'autres taches. Visuellement impressionnant quand on voit les etapes s'allumer en parallele.

A preparer avant la demo (effort minimal)

Tache	Effort	Impact demo
Cabler hover/scroll/focus dans execute_action	2h	Proprete (eviter un plantage si utilise par erreur)
Cabler les file_* dans le dispatch	2h	Permet de montrer la gestion de fichiers
Remplacer le stub extract_text par un vrai OCR	4h	Permet d'utiliser ce bloc au lieu du workaround ai_analyze_text
Preparer 2-3 workflows de demo pre-configures	4h	Indispensable
Tester E2E sur un outil metier reel (DPI, Excel, Webapp)	8h	Indispensable

A ne PAS montrer (risque de plantage)

• loop_visual : pas implemente, aucun backend
• ai_ocr, ai_summarize, ai_extract, ai_classify, ai_custom : pas cables -- utiliser ai_analyze_text ou les blocs llm_* a la place
• visual_condition : le branchement conditionnel n'est pas fiable -- le frontend ne gere pas les edges multiples proprement

A promettre comme roadmap

• Boucles visuelles intelligentes (loop_visual) : Q3 2026
• Conditions visuelles avec branchement dans le canvas : Q3 2026
• Export automatique CSV/Excel des resultats : Q2 2026 (facile)
• Notifications email en fin de workflow : Q2 2026
• Les 5 blocs IA manquants sont des variations de prompt -- livraison rapide apres la demo

Resumme

Sur 37 blocs dans la palette :

• 17 sont operationnels (46%)
• 10 sont partiellement implementes (27%) -- necessitent du cablage (heures)
• 10 sont des placeholders (27%) -- necessitent du developpement (jours)

Le pipeline le plus impressionnant pour la demo est le data-loop (import_excel + db_foreach + LLM parallele) -- c'est le seul qui est 100% fonctionnel de bout en bout pour un cas d'usage concret de type "traiter N dossiers".