Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a13d6d0052fab958eb3c4e48d99bc84c6ac2b9c2
rpa_vision_v3/docs/INSPIRATION_FRAMEWORKS_2026-05-10.md
Dom 5ea4960e65
Some checks failed
tests / Lint (ruff + black) (push) Successful in 1m50s
Details
tests / Tests unitaires (sans GPU) (push) Failing after 1m50s
Details
tests / Tests sécurité (critique) (push) Has been skipped
Details
backup: snapshot post-démo GHT 2026-05-19 
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>
2026-05-19 14:55:06 +02:00

6.2 KiB
Raw Blame History

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

Reference in New Issue View Git Blame Copy Permalink