Files
rpa_vision_v3/docs/recherche/AXE_B4_ORA_VS_REPLAY.md

23 KiB
Raw Blame History

AXE B4 — Agents GUI autonomes vs replay déclaratif : où placer le curseur pour rpa_vision_v3 ?

Date : 2026-05-23 Auteur : Claude (agent dispatché, recherche prospective) Statut : Note de cadrage. Pas d'action de code. Décision Dom requise. Périmètre : état de l'art 2025-2026 des frameworks computer-use / GUI agents, en miroir de l'architecture actuelle (replay VWB déclaratif + Léa Windows + cascade OCR/template/VLM).


1. TL;DR et recommandation

Insight central : entre mars 2025 et mai 2026, l'autonomie GUI a fait un bond brutal. Les benchmarks de référence (OSWorld-Verified, WindowsAgentArena, ScreenSpot-Pro) sont passés de ~38 % (CUA d'OpenAI, fin 2024) à >80 % (Holo3, Claude Mythos Preview, Agent S3 Behavior Best-of-N) en moins d'un an, dépassant ou rivalisant avec le baseline humain expert (~72 %). Mais ces scores ne disent rien des deux contraintes qui dictent notre choix : latence par step (10-30 s pour les modèles autonomes contre <2 s pour le replay cache-hit) et coût d'inférence cloud (rédhibitoire pour un déploiement healthtech on-premise).

Recommandation 3-6 mois : rester sur l'axe replay déclaratif amélioré, mais ouvrir un bac à sable autonomous "Copilot" sur le pattern Skyvern "Planner-Actor-Validator" (cf. §3) câblé sur le module ORA existant. Concrètement :

  1. Fermer la dette transport (HTTP → SSE/WebSocket, cf. SYNTHESE_TECHNOS §5.1) avant toute escalade vers l'autonome — sinon on bâtit un agent autonome sur un transport qui perd 9 actions sur 33 s.
  2. Réactiver le pre-check ORA if False: ligne 1705 uniquement en mode "Copilot supervisé" (toggle par workflow), pas en autonome silencieux. C'est le pas le plus court vers l'échelle Skyvern niveau Validator-as-component, dont notre dette est explicite (feedback_phash_vs_dialog_in_vm.md).
  3. Adopter explicitement le vocabulaire Shadow → Copilot → Autonomous comme palier produit, avec des métriques de bascule mesurables (success rate ≥ 95 %, intervention rate < 1 step sur 20) issues de la littérature (Turian, SAFe-Copilot, cf. §5).
  4. Ne PAS courir derrière Holo3 ou Claude Mythos : ces modèles sont SOTA en autonomie mais cloud-only ou >35B params. Notre contrainte VRAM 12 GB et notre exigence on-premise les excluent.

Dépendances directes :

  • AXE B2 Validator : prérequis. Sans Validator sémantique solide, le mode Copilot ne peut pas détecter ses échecs → boucle d'erreur sans recovery. Le pattern Reflexion (§4) ne fonctionne que si l'évaluateur est fiable.
  • AXE C apprentissage : TargetMemoryStore (Phase 1 du PLAN_APPRENTISSAGE_LEA) devient le fondement d'une "memory tier" type Letta/MemGPT pour le mode Copilot. Brancher la mémoire AVANT toute escalade autonome.

2. Table comparative — frameworks GUI agents autonomes mai 2026

Framework / Modèle OSWorld-Verified WindowsAgentArena ScreenSpot-Pro Latence/step (estim.) On-prem ? Licence Notes
Claude Sonnet 5 (Anthropic CU) 88.3% n/a (CU générique) n/a 10-30 s (LLM agentic) cloud only propriétaire Dépasse human baseline 72.4 %. API "computer use" tool. Coût ~$5/$25 par MTok
Claude Opus 4.7 78.0% n/a n/a 10-30 s propriétaire Successeur 4.6 (72.7 %).
Holo3-122B-A10B (H Company) 78.85% (mars) n/a n/a n/a ⚠ Apache 2.0 mais 10B actifs / 122B totaux Apache 2.0 MoE desktop-spécialisé, sort proprio
Holo3-35B-A3B 82.6% (avril) n/a n/a n/a ⚠ 3B actifs / 35B totaux Apache 2.0 SOTA leaderboard fin avril 2026
GPT-5.4 / OpenAI CUA 75.0% n/a 85.4% (SS-Pro) 10-20 s cloud only propriétaire Computer Use tool API tiers 3-5, $3/$12 MTok
Agent S3 (Simular) 66% (100 steps) / 72.6% (Best-of-N) n/a n/a LLM-dépendant orchestrateur open Apache 2.0 Compose any VLM (Claude/GPT/local)
Agent S2 (Simular) 34.5% (50 steps) +52.8% vs SOTA prec. n/a LLM-dépendant Apache 2.0 Generalist-Specialist framework
UI-TARS-2 (ByteDance) 47.5% 50.6% n/a end-to-end, ~5 s GPU local open weights Apache 2.0 7B params, déployable local. Multi-turn RL
Magma (Microsoft) n/a (focus robotique + GUI) n/a n/a n/a open MIT Foundation model SoM/ToM, 39M samples. Pas de score OSWorld direct.
OS-Atlas-Pro-7B n/a n/a strong (focus grounding) <2 s GPU local open weights Apache 2.0 3 modes : Grounding / Action / Agent
Skyvern v2 n/a (browser-only) n/a (browser) n/a Agent: ~5 s/step ; Script: 10-100× plus rapide self-host AGPL-3.0 WebVoyager 85.85%. Dual mode agent/script
browser-use v2 n/a (browser) n/a n/a LLM-dépendant self-host MIT 78k★ GitHub. Reasoning loop pure
Cradle (BAAI) OSWorld testé n/a n/a élevé (6 modules) open Apache 2.0 6 modules : Info Gather, Self-Reflection, Task Inference, Skill Curation, Action Planning, Memory
AppAgent v2 (Tencent) mobile-focused n/a n/a n/a open MIT Combine parser + visuel, flexible action space
OS-Genesis (Shanghai AI Lab) training pipeline n/a n/a n/a open (ACL 2025) Apache 2.0 Reverse Task Synthesis — pertinent pour Shadow→Copilot, cf. §5

Lecture critique :

  • Le plafond verre des 85 % sur OSWorld est dépassé par les cloud SOTA (Claude Sonnet 5, Holo3). Mais on parle de tâches simples type ouvrir LibreOffice, modifier un fichier. RIEN sur OSWorld ne ressemble à Easily Assure (UI métier propriétaire dans Edge/Citrix, 22+ steps, T2A médical).
  • Les modèles vraiment on-premise <8B (UI-TARS-2, OS-Atlas-Pro) plafonnent à 47-50 % sur OSWorld — performance insuffisante pour de l'autonomie en production healthtech.
  • WindowsAgentArena reste le benchmark le plus proche de notre cible (154 tâches Windows multi-app). Score de référence UI-TARS-2 = 50.6 %. À retenir : aucun modèle <100B ne dépasse 60 % sur WAA en mai 2026.
  • OSWorld-Human (arxiv 2506.16042) montre que les meilleurs agents prennent 2.7 à 4.3× plus de steps que nécessaire, et que chaque step successif peut prendre 3× plus longtemps que le premier. Le coût latence n'est pas linéaire — il explose en fin de tâche.

3. L'échelle d'abstraction — 4 paliers, où on est, où aller

Reprise du §2.3 d'INSPIRATION_FRAMEWORKS_2026-05-10.md, instrumentée avec les benchmarks 2026.

Palier Description Exemples framework Robustesse cible Latence/step Coût LLM Notre position
L1 — Replay déclaratif pur Workflow recorded → rejoué step par step. Aucun raisonnement runtime. UiPath classique, TagUI, Skyvern Script Mode (cache) Très haute si UI stable, fragile sur changement <500 ms (resolve memory hit) à ~2 s (VLM grounding) ~0 (un appel VLM si miss) C'est ici qu'on opère. VWB = Planner statique, cascade = Grounding
L2 — Replay avec runtime fallback Replay déclaratif + fallback intelligent quand un step échoue : retry visuel, re-grounding, escalade VLM Skyvern dual mode (script + agent fallback), Anthropic Computer Use en mode "tool" Haute, dégradation gracieuse 2-5 s en moyenne, pic 15 s au fallback Faible (fallback rare) Cible 3-6 mois. Le pre-check ORA if False: ligne 1705 est l'opportunité d'amorçage
L3 — Autonomous avec checkpoint Plan dynamique + Validator post-step + ability de re-planifier. Human-on-the-Loop. Skyvern Agent Mode v2 (Planner-Actor-Validator), Cradle (6 modules), Agent S2/S3, MGA observation-centric Moyenne, dépend du Validator 5-15 s/step Significatif (validator + replan) Cible 12-18 mois, après AXE B2 Validator solide
L4 — Autonomous full Goal → décomposition + exécution + recovery sans intervention humaine. Human-out-of-the-Loop. Claude CU, OpenAI CUA, Holo3 end-to-end Variable — SOTA 88 % sur tâches simples, chute sur UI métier propriétaire 10-30 s/step Élevé (cloud) ou très VRAM-gourmand (local 35B+) Hors périmètre POC santé. Risque juridique RGPD/AI Act, coût cloud, instabilité UI Easily

Position critique : OpenAdapt, Skyvern, OmniParser et toute la littérature 2026 convergent sur l'idée que L1 → L2 est le saut le plus rentable. L'écart L2 → L3 demande un Validator robuste qui n'existe pas encore chez nous (pHash global insuffisant, cf. bug step 10 du diagnostic 8 mai). L'écart L3 → L4 demande des modèles qu'on n'a pas (cloud only) ou qu'on ne peut pas servir (>35B params).


4. Recovery patterns 2026 — lequel adopter

Quatre familles de patterns dominent en 2026. Classés par robustesse vs effort d'implémentation chez nous.

Pattern Principe Effort impl. Robustesse Recommandé pour rpa_vision_v3 ?
Retry immédiat Refaire la même action 1-3 fois avec back-off Trivial Faible (n'aide pas si cause structurelle) déjà partiellement en place, OK
Backtrack agent (BacktrackAgent arxiv 2505.20660) Verifier + Judger en pipeline. Si fail détecté → rollback step n, retry avec stratégie alternative Moyen Haute si Verifier solide ⚠ utile, mais nécessite Verifier sémantique = AXE B2
Reflexion (NeurIPS 2023, Shinn et al.) Verbal RL : LLM observe son échec, génère feedback texte stocké en mémoire épisodique, ré-essaie en lisant ce feedback Élevé (Actor + Evaluator + Self-Reflection) Très haute en long-horizon, surcoût LLM élevé pas avant L3. Surcoût LLM rédhibitoire sur démo répétitive
Checkpoint + idempotency (Agent DR 2026) Checkpoint après chaque step validé, replay depuis le dernier checkpoint sain. Idempotency keys au scope task Moyen Très haute pour tâches state-mutating Pertinent pour T2A : checkpoint après chaque ord validé, reprise depuis là si crash
Pause supervisée (Human-on-the-Loop) À la moindre détection d'anomalie : pause, demande validation humaine, reprend ou abandonne Faible Très haute (humain = oracle) Cohérent avec feedback_failure_is_learning.md ("échec clic = pause supervisée, pas stop avec error"). DÉJÀ NOTRE PATTERN
Observation-centric (MGA) Closed loop observe-plan-act-verify ; "occlusion signals + failure clusters" déclenchent replan explicite Moyen-élevé Bonne en GUI dynamique ⚠ pertinent pour Citrix/popups mais nécessite OmniParser-like

Recommandation : combiner (1) Pause supervisée (déjà notre devise) + (2) Checkpoint+idempotency au niveau workflow VWB (chaque ord T2A = un checkpoint, reprise possible sans réexécution amont). Bonus : ces deux patterns sont vendables au pitch healthtech (sécurité, traçabilité). Reflexion et Backtrack agent restent en R&D pour AXE C.


5. Cycle Shadow → Copilot → Autonomous — état de la littérature

5.1 Qui le formalise ?

Le triptyque est largement adopté en 2026 mais sous des noms variables :

  • Microsoft Copilot vs Agent vs Autonomous (Microsoft 2026 Copilot Update, mai 2026) : trois layers explicites — "human-in-the-loop AI", "supervised agent AI", "autonomous agent AI". Microsoft Agent 365 = control plane de cette progression.
  • 5 levels of AI autonomy (Turian.ai) : Manual → Assisted → Augmented → Autonomous → Fully Autonomous. Très repris en blogs entreprise.
  • HITL / HOTL / Human-out-of-the-loop (autonomous-systems-explained.com) : trois niveaux canoniques en robotique appliqués à l'IA.
  • SAFe-Copilot (arxiv 2511.04664) : unified shared autonomy framework — formalise les seuils de bascule.
  • AI Autonomy Coefficient α (arxiv 2512.11295) : tente une formalisation quantitative.

Aucun papier ne propose exactement notre triptyque "Shadow → Copilot → Autonomous" mais tous les frameworks 2026 ont 3 paliers équivalents. Notre vocabulaire produit (cf. memory/project_vision.md) est cohérent avec le mainstream.

5.2 Métriques de bascule entre paliers

Synthèse littérature + nos contraintes :

Bascule Métrique Seuil indicatif littérature Adaptation rpa_vision_v3
Shadow → Copilot Précision de la suggestion shadow validée par l'humain 80-90 % d'acceptation des suggestions Workflow VWB construit en Shadow accepté ≥ 80 % par le TIM sans modif majeure
Copilot → Autonomous Success rate replay sans intervention ≥ 95 % sur N runs consécutifs (N≥50) 50 runs MOREL Catherine successifs sans intervention humaine. Aucun aujourd'hui.
Recul Autonomous → Copilot Intervention rate > seuil >5 % des steps requièrent humain Tableau de bord temps réel intervention rate par workflow

Pratique concrète : OS-Genesis (Shanghai AI Lab) propose un pipeline "Reverse Task Synthesis" qui est conceptuellement Shadow → Copilot inverse : l'agent explore d'abord, dérive ensuite les tâches. Pertinent pour notre vision TargetMemoryStore → généralisation (PLAN_APPRENTISSAGE_LEA Phase 2-3).


6. MCP (Model Context Protocol) — place dans une archi RPA on-premise

Statut MCP : standard ouvert Anthropic 2024, adopté largement en 2026. Architecture client-serveur. Anthropic, OpenAI, Microsoft Agent 365 le supportent.

Pertinence pour rpa_vision_v3 :

  1. Notre serveur RPA pourrait s'exposer en MCP server — déjà signalé dans INSPIRATION_FRAMEWORKS §5 et CLAUDE.md memory (reference_mcp_servers.md, on a 13 MCP actifs côté outillage). Cela permettrait à Claude Desktop / Cursor / VS Code d'invoquer nos workflows.
  2. Le serveur on-prem peut exposer en MCP : tables PostgreSQL T2A, dossiers DPI, modèles VLM locaux, dashboards. Pas de cloud requis pour la couche MCP elle-même.
  3. Risque : si on expose Léa en MCP, on rentre dans l'écosystème "shadow AI agents" pointé par les analyses Microsoft RSAC 2026 (gouvernance, traçabilité). Acceptable seulement avec audit log strict.
  4. Pas de blocage RGPD spécifique : MCP est juste un protocole, la souveraineté dépend de qui héberge le serveur.

Recommandation MCP : horizon 12+ mois. Pas de valeur immédiate démo. Mais positionnement commercial fort (« notre RPA est un MCP server consommable par n'importe quel agent IA, on-premise et conforme »).


7. Trois scénarios pour rpa_vision_v3

Scénario A — Rester replay déclaratif amélioré (RECOMMANDÉ)

Description : on consolide L1, on ferme les 5 bugs P0, on adopte le vocabulaire Skyvern (Policy/Grounding/Validator) dans la doc et le code, on garde la cascade actuelle.

Effort : 4-6 semaines (clôture dette transport + Validator pHash → sémantique + smart_resize DETTE-014).

Risque : faible. On capitalise sur l'existant.

Bénéfice : démo robuste, vendable POC clinique. Pas de saut techno.

Coût : ne répond pas à l'objectif "Léa apprend / Léa comprend" du memory/project_vision.md.


Scénario B — Hybride L2 + Copilot ORA (BAC À SABLE PARALLÈLE)

Description : Scénario A + on rebranche _verify_pre_click dans ORA (DETTE-008, ligne 1705), uniquement en mode toggle "Copilot supervisé" sur un workflow expérimental. Le pre-check VLM devient le Validator-as-component du pattern Skyvern.

Effort : 8-10 semaines (B2 Validator sémantique + un workflow expérimental en Copilot mode + métriques d'intervention rate).

Risque : moyen. Risque d'éparpillement entre L1 stable et L2 expérimental. Nécessite discipline forte (toggle ENV, pas de mélange runtime).

Bénéfice : on prépare AXE C apprentissage et AXE B2 Validator, on a un POC démontrable de "Léa qui vérifie avant de cliquer". Vendable au pitch healthtech.

Coût : double surface de maintenance.


Scénario C — Sauter vers Autonomous L4 avec Holo3 ou Claude CU

Description : on abandonne progressivement VWB déclaratif, on bascule sur un modèle SOTA (Holo3-35B-A3B en open weights, ou Claude Sonnet 5 cloud) qui décompose le goal "T2A patient X" en steps autonomes.

Effort : 6-12 mois minimum. Recodage majeur. Infrastructure GPU >70 GB VRAM (Holo3) ou cloud bill significatif (Claude).

Risque : très élevé. Easily Assure n'est pas dans le set d'entraînement de ces modèles. Performance OSWorld 80 % ne se transfère pas à UI métier propriétaire. Risque RGPD si Claude (envoi screenshots à Anthropic). Risque hallucination en production médicale.

Bénéfice : narrative "vraiment agentique". Compétitif vs Skyvern/UiPath agentic.

Coût : casse la démo, désaligne avec contrat "100% vision" on-premise, casse l'asset commercial healthtech RGPD.

Rejeté pour 2026. Reconsidérer en 2027 si Holo3-7B (hypothétique) sort, ou si on a un client GPU H100 sur site.


8. Recommandation finale

Adopter Scénario A en main track, Scénario B en bac à sable parallèle, avec ces étapes ordonnées :

  1. S1-S2 : SSE/WebSocket transport (clôt §4 de SYNTHESE_TECHNOS, sans ça rien d'autre n'est crédible).
  2. S3-S4 : Validator sémantique (AXE B2) — remplacer pHash global par vérification texte attendu présent dans zone visée. C'est aussi la condition d'AXE C.
  3. S5-S6 : Sur un workflow expérimental, toggle RPA_ORA_PRECHECK=true → mode Copilot. Mesurer intervention rate.
  4. S7-S8 : Brancher TargetMemoryStore Phase 1 (PLAN_APPRENTISSAGE_LEA) — bascule "Léa apprend" mesurable.
  5. Post-S8 : décision Dom autonomous L3 oui/non, sur base métriques réelles.

Dépendances explicites :

  • AXE B2 Validator → débloque Copilot et toute progression L2 → L3.
  • AXE C apprentissage (TargetMemoryStore) → débloque la mémoire long-terme nécessaire à Copilot+.
  • Clôture dette transport → prérequis dur, indépendant des autres axes.

9. Sources (priorité < 6 mois)

Benchmarks et leaderboards

Frameworks autonomes

Patterns recovery / autonomie

Mémoire long-terme

MCP

Autonomy frameworks (Shadow → Copilot → Autonomous)

Healthcare RPA / agents


Document à débattre avec Dom. Pas d'action de code engagée. Le scénario retenu doit aussi être croisé avec les conclusions d'AXE B2 (Validator) et d'AXE C (apprentissage) avant arbitrage final.