# 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".