# 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)