5ea4960e65
Backup état complet après enregistrement vidéo démo de bout en bout. À utiliser comme point de référence pour la consolidation post-démo. Changements majeurs de la session 18-19 mai : - AIVA-URGENCE : page autonome avec preset URL + auto-focus chain - Workflow Demo_urgence_3_db : merge linux_db + steps AIVA + pause humaine NoMachine - Bypass LLM (static_result / static_text) dans replay_engine pour démos déterministes sans appel Ollama - Fix api_stream:3013 — replay_paused au premier polling /next - dag_execute : lift duration_ms vers top-level pour wait runtime - NPM bypass auth /aiva-urgence/ via location ^~ (proxy_host/10.conf hors git) - scripts/cancel-replays.sh — workaround Stop VWB qui ne purge pas la queue Anchors visuels (468) forcés dans le commit pour garantir restorabilité. DB workflows actuelle + ~12 .bak DB de la journée incluses. Sujets identifiés pour consolidation post-démo (TODO) : 1. Bug VWB recapture anchor ne régénère pas le PNG 2. Léa client accumule état mémoire (restart périodique requis) 3. Stop VWB ne purge pas la queue serveur (lien manquant vers /replay/cancel) 4. Bug coord client mss tronqué 2560x60 → mapping Y cassé 5. delay_before/delay_after ignorés au runtime (fix partiel duration_ms) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
116 lines
6.2 KiB
Markdown
116 lines
6.2 KiB
Markdown
# Inspiration frameworks RPA visuels — état des lieux externe
|
|
|
|
**Date :** 2026-05-10
|
|
**Auteur :** Claude (chat) via Dom
|
|
**Statut :** à débattre post-démo, pas urgent
|
|
|
|
## 1. Ce qu'on cherchait
|
|
|
|
Identifier 2-3 patterns d'archi de projets RPA visuels open source qui pourraient inspirer rpa_vision_v3 SANS remettre en cause son existant. Posture : neutre, factuelle.
|
|
|
|
J'ai exploré 4 projets parmi les plus matures de l'écosystème RPA visuel / GUI agent open source en 2025-2026 :
|
|
|
|
1. **OpenAdapt** (OpenAdaptAI, GitHub ~7k stars) — RPA générative avec VLM, pensé pour démos humaines
|
|
2. **Skyvern** (Skyvern-AI, GitHub ~12k stars) — automation browser via vision + LLM, pas DOM
|
|
3. **OmniParser** (Microsoft Research, GitHub ~22k stars) — parsing structuré d'écrans pour GUI agents
|
|
4. **TagUI** (AI Singapore) — RPA cross-OS multilangue, plus mature mais moins LLM-first
|
|
|
|
Référence aux benchmarks : WindowsAgentArena, ScreenSpot et ScreenSpot-Pro, WebVoyager (Skyvern à 85.85%).
|
|
|
|
## 2. Convergences fortes avec rpa_vision_v3
|
|
|
|
### 2.1 Policy / Grounding Separation
|
|
|
|
> "The Policy decides what to do; Grounding determines where to do it."
|
|
|
|
Chez nous : le VWB (workflow déclaratif "il faut cliquer sur Notes médicales") = Policy. La cascade `_resolve_target` (OCR → template → grounding VLM) = Grounding.
|
|
|
|
Ce qu'on fait déjà bien : la séparation existe en pratique. Le Policy ne sait pas comment le Grounding fait son travail.
|
|
|
|
Suggestion : nommer ces deux composants comme tels dans la doc — c'est devenu un vocabulaire standard dans l'écosystème.
|
|
|
|
### 2.2 Safety Gate
|
|
|
|
> "Runtime validation layer before action execution (confirm mode for high-risk actions)."
|
|
|
|
Chez nous : Léa qui vérifie l'ancre visuelle avant de cliquer. Philosophie produit identique.
|
|
|
|
Pour le pitch démo : "Safety Gate" est un vocabulaire reconnu dans l'écosystème. Healthtech = parfait fit. À mettre en avant face à DG/DSI/médecins : "Léa ne clique jamais à l'aveugle, elle confirme visuellement avant chaque action — c'est notre Safety Gate."
|
|
|
|
### 2.3 Abstraction Ladder
|
|
|
|
> "Progressive generalization from literal replay to goal-level automation."
|
|
|
|
Chez nous : replay déclaratif (VWB workflow étape par étape), avec vision long-terme d'un agent autonome (ORA = observe_reason_act).
|
|
|
|
Suggestion : ne pas opposer les deux. Replay (low abstraction) et ORA (high abstraction) sont les deux extrémités d'une échelle.
|
|
|
|
## 3. Patterns Skyvern intéressants
|
|
|
|
### 3.1 Planner-Actor-Validator Loop
|
|
|
|
Skyvern décompose chaque tâche en 3 rôles : Planner, Actor, Validator (vérifie que le step a réussi avant de passer au suivant).
|
|
|
|
Chez nous : VWB ≈ Planner statique. Léa ≈ Actor + une partie de Validator (vérification ancre). Le VERIFY ≈ Validator post-action.
|
|
|
|
**Note critique 2026-05-10 :** le bug observé sur le step 10 (Imagerie cliqué dans le bandeau Edge mais REPORT success=True) révèle que notre Validator est laxiste (pHash global au lieu de vérification sémantique du tab actif). C'est exactement le type de défaillance que la formalisation Validator-as-component aiderait à diagnostiquer.
|
|
|
|
### 3.2 Visual Workflow Builder
|
|
|
|
Skyvern parle explicitement de "Visual workflow builder - Create automations without writing code through a point-and-click interface".
|
|
|
|
C'est exactement notre VWB. Convergence indépendante = bon signe qu'on est sur le bon design pattern.
|
|
|
|
## 4. Patterns OmniParser intéressants
|
|
|
|
### 4.1 Tokenizing UI screenshots
|
|
|
|
OmniParser transforme l'écran en éléments structurés (liste d'interactable elements + captions sémantiques) AVANT que le VLM principal ne soit appelé.
|
|
|
|
Suggestion modeste applicable rapidement : logger systématiquement, à chaque appel `_resolve_target`, la liste des candidats détectés par chaque étage de la cascade. On aurait une "vue parsée" implicite, sans changer l'archi. Utile pour debug, utile pour démo.
|
|
|
|
### 4.2 OmniTool : VM Windows + agent
|
|
|
|
OmniTool de Microsoft contrôle une VM Windows 11 entière, avec un VLM externe. Séparation "VM Windows distante / agent côté serveur".
|
|
|
|
Chez nous : machine Windows distante via NoMachine + agent côté Linux. Convergence indépendante.
|
|
|
|
Pour le pitch : "isolation forte entre poste utilisateur et moteur d'IA" est un argument healthtech / RGPD / sécurité hospitalière fort.
|
|
|
|
## 5. Ce que les autres font et qu'on ne fait pas (à creuser)
|
|
|
|
- **Evaluation-Driven Feedback (OpenAdapt)** : "Success traces become new training data". Nos runs réussis pourraient alimenter une banque de cas de référence. Pas urgent.
|
|
|
|
- **Prompt Caching (Skyvern)** : mémoriser les actions passées et les rejouer. On a déjà un `TargetMemoryStore` (cf. Phase 1 apprentissage). Concept similaire à comparer.
|
|
|
|
- **MCP server architecture** : Skyvern et d'autres exposent leur RPA comme un serveur MCP. Roadmap long-terme.
|
|
|
|
## 6. Questions pour la session de recul méthodologique post-démo
|
|
|
|
1. Formaliser Policy / Grounding / Safety Gate / Validator comme des composants nommés dans la doc et dans le code ?
|
|
2. L'écart Replay engine VWB vs ORA doit-il être réduit ou maintenu ?
|
|
3. L'ajout d'une couche "Screen Parser unifié" type OmniParser serait-elle utile à terme ?
|
|
4. L'archi Léa (agent contrôlé sur Windows distant) est un asset commercial fort dans le secteur healthtech. Devrait-on la mettre plus en avant dans le pitch ?
|
|
|
|
## 7. Convergence : on n'est pas seul
|
|
|
|
L'archi rpa_vision_v3 converge fortement avec ce que les meilleurs projets open source 2025-2026 formalisent comme bonnes pratiques.
|
|
|
|
Ce que les autres ont en plus :
|
|
- Formalisation explicite des composants → adoptable sans refonte
|
|
- Communication mainstream des concepts → utile pour le pitch
|
|
- Pre-built templates / use cases → maturité de marché
|
|
|
|
Ce qu'on a en plus :
|
|
- Spécialisation healthtech → moat naturel
|
|
- Agent contrôlé qui valide visuellement → philosophie produit forte
|
|
- VWB visuel → différenciateur UX par rapport au tout-LLM
|
|
- Stack on-premise complète → réponse RGPD / souveraineté que les SaaS américains ne peuvent pas donner
|
|
|
|
## 8. Liens
|
|
|
|
- OpenAdapt v1.0 : https://github.com/OpenAdaptAI/OpenAdapt
|
|
- OmniParser V2 : https://github.com/microsoft/OmniParser
|
|
- Skyvern : https://github.com/Skyvern-AI/skyvern
|
|
- WindowsAgentArena (benchmark)
|