Files
rpa_vision_v3/docs/SYNTHESE_TECHNOS_REPLAY_2026-05-23.md

27 KiB
Raw Blame History

Synthèse croisée — Études techno RPA vision & méthodes de replay

Date : 2026-05-23 Auteur : Claude (session principale) à partir des docs/ du projet Périmètre : consolider, en un seul document, tout ce que rpa_vision_v3/docs/ contient sur (a) les techno externes étudiées pour faire avancer le RPA visuel et (b) les méthodes de replay testées/diagnostiquées. Destiné à être lu par un agent comme brief de mise à niveau.

Statut : lecture seule, pas d'action. Pas de proposition d'implémentation : on consolide ce qui est déjà documenté et on signale les liens.


0. Comment lire ce document

Le projet a accumulé sur marsmai 2026 :

  • Des explorations externes (5+4 frameworks computer-use / RPA visuel).
  • Des benchmarks internes (VLM grounding, LLM décision T2A, LLM safety checks).
  • Des diagnostics replay post-démo GHT très précis, qui révèlent que la cause des échecs récents n'est PAS la cascade de résolution UI, mais la couche transport et un bug OCR latent.

Les sections 1 à 4 sont organisées par thème (frameworks, VLM/grounding, LLM décisionnels, replay). La section 5 croise tout et signale les liens forts. La section 6 est la carte des documents de référence.


1. Frameworks externes étudiés (RPA visuel, GUI agents, computer-use)

Deux vagues d'exploration distinctes, à 5 jours d'écart, par 2 canaux différents — leur convergence est elle-même un signal.

1.1. Vague QW Suite Mai — 5 frameworks computer-use (2026-05-05)

Source : docs/superpowers/specs/2026-05-05-qw-suite-mai-design.md §1 + docs/QW_SUITE_MAI.md en-tête.

Framework Apport repéré Quick win extrait
Simular Agent-S architecture computer-use mature (pas de QW direct)
browser-use détection de boucle de stagnation QW2 LoopDetector composite (CLIP screen_static + action_repeat + retry_threshold)
OpenAI CUA (sample) pattern de validations humaines avant action QW4 Safety checks hybrides (declaratif + LLM contextuel local)
Coasty (open-cu) computer-use générique (pas de QW direct)
Showlab OOTB capture/grounding propre par moniteur QW1 Multi-écrans (monitor_index + fallback focus actif puis composite)

Livrables réels (commit en branche feature/qw-suite-mai) :

  • QW1 multi-écrans + MonitorRouter (screeninfo>=0.8 ajouté) — loop_detector.py, commits 6582a69d3, b1a3aa16f, 2d71e2a24, fix fc01afa59.
  • QW2 LoopDetector — commit 2a51a844b.
  • QW4 SafetyChecksProvider + endpoint /api/v3/replay/resume + <ChecklistPanel> VWB — commit 7c6945171, 0a02a6ec9 (sélection du LLM).
  • 24 tests QW + 89 baseline = 113 verts.
  • Kill-switches env vars : RPA_LOOP_DETECTOR_ENABLED, RPA_SAFETY_CHECKS_LLM_ENABLED, RPA_LOOP_SCREEN_STATIC_THRESHOLD, etc.

1.2. Vague Inspiration Frameworks — 4 projets RPA visuel (2026-05-10)

Source : docs/INSPIRATION_FRAMEWORKS_2026-05-10.md.

Framework Stars (mai 2026) Apport conceptuel
OpenAdapt (OpenAdaptAI) ~7k RPA générative VLM, "success traces become new training data" (Evaluation-Driven Feedback)
Skyvern (Skyvern-AI) ~12k browser RPA vision, Planner-Actor-Validator loop, Visual Workflow Builder, prompt caching, WebVoyager 85.85%
OmniParser (Microsoft) ~22k tokenisation d'écran (interactable elements + captions sémantiques) AVANT le VLM principal, OmniTool VM Windows
TagUI (AI Singapore) RPA cross-OS multilangue, moins LLM-first

Convergences fortes mises en évidence dans le doc :

  1. Policy / Grounding Separation — chez nous VWB = Policy, cascade _resolve_target (OCR → template → VLM) = Grounding. Existe en pratique, à formaliser dans la doc.
  2. Safety Gate — Léa vérifie l'ancre visuelle avant de cliquer. Vocabulaire reconnu → atout pitch healthtech.
  3. Abstraction Ladder — replay déclaratif VWB (low) ↔ ORA observe_reason_act (high). À ne PAS opposer.
  4. Planner-Actor-Validator (Skyvern) — VWB ≈ Planner statique, Léa ≈ Actor + Validator partiel. Le bug du step 10 démontre que notre Validator est laxiste (pHash global au lieu de vérification sémantique).
  5. Tokenizing UI screenshots (OmniParser) — pas en place chez nous. Suggestion modeste : logger la liste des candidats à chaque appel _resolve_target (vue parsée implicite).
  6. OmniTool VM Windows + agent côté serveur — convergence indépendante avec notre archi Léa Windows + agent Linux.

Repères benchmarks externes mentionnés : WindowsAgentArena, ScreenSpot, ScreenSpot-Pro, WebVoyager.

1.3. Convergences et différentiels nets

Ce qu'ils ont en plus Ce qu'on a en plus
Formalisation explicite des composants Spécialisation healthtech (moat)
Communication mainstream Validation visuelle (Safety Gate) côté agent Windows
Pre-built templates / use cases VWB visuel = différenciateur UX
Stack on-premise complète (RGPD / souveraineté)

2. VLM et grounding — historique implémentations + benchmarks

Source maître : docs/HISTORIQUE_VLM_IMPLEMENTATIONS_2026-05-08.md (audit branche feature/qw-suite-mai HEAD 731b5bcae).

2.1. Modèles VLM passés ou en place

Modèle Période Backend(s) Statut
qwen2.5-vl:7b 2026-03 → encore présent Ollama + vLLM actif (mais déborde VRAM, voir 2.3)
qwen3-vl:8b 2026-04 → Ollama fallback dans vlm_config.FALLBACK_VLM_MODELS
UI-TARS-1.5-7B 2026-04-25 (commit 9da589c8c) Transformers Flask server.py 4-bit NF4 remplacé par InfiGUI (commit 77faa03ec)
InfiGUI-G1-3B 2026-04-26 → Transformers (Flask server.py + worker subprocess + daemon Unix socket) principal grounding aujourd'hui (3.9 GB VRAM, _smart_resize complet)
SeeClick (Qwen-VL) 2026-01 → ? HuggingFace direct exporté mais "cassé" — commit d1b556b6c retire de l'executor
OWL-v2 (Google) Transformers direct (OwlDetector) détecteur open-vocabulary, câblé dans ui_detector.py mais aucun bench récent
medgemma:4b Ollama retenu QW4 par défaut puis évincé au bench (cf. 2.4)
gemma4:e4b / gemma4:latest Ollama usage VLM et safety_checks
Cloud opt-in OpenAI/Gemini/Anthropic HTTP VLM_ALLOW_CLOUD=true dans visual_workflow_builder/backend/vlm_provider.py

3 entry-points distincts coexistent pour la même logique Transformers : core/grounding/server.py (Flask :8200), core/grounding/infigui_server.py (Unix socket, service systemd rpa-grounding.service), core/grounding/infigui_worker.py (subprocess one-shot). Le pipeline FAST→SMART→THINK + ThinkArbiter + ShadowLearningHook a été câblé en avril (commits Phase 1→6 entre ea36bba5c et 73cea2385).

2.2. Backends testés

Ollama HTTP, vLLM HTTP OpenAI-compat, Transformers in-process (3 entry-points), HuggingFace direct (SeeClick, OWL-v2), Cloud opt-in.

vLLM a été ajouté en mars (commit 394342be7 du 2026-03-31), positionné comme essai principal AVANT fallback Ollama dans resolve_engine.py:785-816. Modèle hardcodé par défaut Qwen/Qwen2.5-VL-7B-Instruct-AWQ, switchable via env VLLM_MODEL.

2.3. Bench grounding bbox_2d (2026-05-08)

Source : docs/MIGRATION_VLM_PLAN_2026-05-09.md §2.

Screenshot fixture : data/training/live_sessions/bg_DESKTOP-58D5CAC_windows/shots/heartbeat_1773792436.png (2560×1600, dialog OK/Cancel).

Modèle / config Latence bbox_2d Parse regex prod Coords cohérentes
qwen2.5vl:7b Ollama (prod) 11.0 s {"bbox_2d":[422,604,462,624]} oui non (cx ≈ 0.17, top-left)
qwen3-vl:8b Ollama (prod strict) 8.0 s vide (thinking absorbe les 50 tokens) non n/a
qwen3-vl:8b Ollama (think:false, num_predict=256) 1.7 s liste nue [332,487,362,507] non (regex attend objet) n/a
qwen3-vl:8b Ollama (prompt JSON explicite) 1.8 s {"bbox_2d":[...]} oui non (même bug d'échelle)

Deux problèmes structurels relevés :

  1. VRAM saturée : qwen2.5vl:7b = 14 GB en mémoire totale, RTX 5070 = 12 GB. Ollama bascule split CPU/GPU 42/58 → 11s par appel. qwen3-vl:8b (6 GB) tient full GPU à 1.7 s.
  2. Bug d'échelle bbox_2d : Qwen2.5-VL retourne les coords dans la résolution post-smart_resize, pas l'orig. Ollama applique son propre smart_resize sans exposer la taille → prod divise par orig_w au lieu de resized_w → coords toutes shiftées top-left. Présent dans 4 occurrences de resolve_engine.py + _locate_popup_button (L:2576). Source : HF discussion #13 Qwen2.5-VL-7B-Instruct. Cité mainteneur : « bbox_2d coordinates will be relative to your resized image size » + « resized dimensions parameter is not supported in OLLAMA ».

Conclusion plan migration : tant qu'on passe par Ollama le fix n'est qu'une rustine. Cible = vLLM ou Transformers direct avec passage explicite de resized_width/resized_height. Modèle pressenti qwen3-vl:8b. Module smart_resize officiel commité (0d7bcd18a) mais DETTE-014 : calé sur mauvaise référence (patch_size=16 Qwen3-VL → factor 32, pas 28).

2.4. Bench safety_checks (2026-05-06)

Source : docs/BENCH_SAFETY_CHECKS_2026-05-06.md. Méthodo : 5 scénarios anomalies × 5 modèles, cold + 3 runs warm, métriques (JSON valide, détection, latence).

Modèle Cold (s) Warm avg (s) JSON Détection
gemma4:latest 10.6 2.9 92% 46% retenu
qwen3-vl:8b 5.6 0% 0% (ignore format=json Ollama)
qwen2.5vl:7b 9.4 6.6 100% 23%
qwen2.5vl:3b 6.0 2.0 100% 8% (vérifie pour vérifier)
medgemma:4b 2.0 0.5 100% 0% (renvoie systématiquement [])

Enseignement : medgemma:4b malgré son nom est mauvais choix par défaut (trop obéissant au "rien à signaler"). gemma4:latest gagne sur cohérence motif/diagnostic. qwen3-vl:8b à écarter tant qu'il ignore format=json Ollama.

Aucun modèle ne détecte les 5 scénarios — IPP corrompu et forfait incohérent ratés par tous.

2.5. Code potentiellement utilisable pour la migration

Repris de HISTORIQUE_VLM_IMPLEMENTATIONS_2026-05-08.md §6 :

  • Transformers clé en main : core/grounding/server.py (loader + _smart_resize complet MIN/MAX_PIXELS) et core/grounding/infigui_worker.py (load_model, infer). Il suffit de changer MODEL_ID (env GROUNDING_MODEL déjà supporté).
  • vLLM clé en main : resolve_engine.py:785-816 contient déjà l'appel HTTP OpenAI-compat avec image_url: data:image/jpeg;base64. Il manque le passage de resized_width/resized_height (extension OpenAI vLLM).
  • Socket persistant + fallback subprocess : infigui_server.py + ui_tars_grounder.py réutilisables tels quels.
  • Prompt UI-TARS officiel récupérable via git show 9da589c8c:core/grounding/server.py.

3. LLM décisionnels (T2A) — bench 18 modèles

Source : docs/BENCH_T2A_DECISION_11DOSSIERS.md (2026-05-05). 18 modèles × 11 DPI GHT Sud 95 (5 UHCD / 6 Forfait, vérité-terrain corrigée le 2026-05-05).

Top 5 :

# Modèle Acc p50 Verdict
1 gemma3:27b-cloud 8/11 (73%) 10.6s 🟢 retenu démo
2 qwen3:8b 7/11 (64%) 7.6s 🟡 backup local (5 GB)
3 qwen2.5:7b 7/11 (64%) 10.0s 🟡
4 qwen3-vl:235b-instruct-cloud 7/11 (64%) 20.3s 🟡
5 qwen3.5:9b 7/11 (64%) 25.8s 🟡

Échecs notables :

  • gemma4:latest 6/11 (55%) — insuffisant sur décision T2A (mais OK sur safety_checks, cf. §2.4).
  • medgemma:4b 4/11 (36%) — JSON cassé via Ollama, PAS le LLM médical magique que son nom suggère.
  • gpt-oss:20b-cloud 0% — format JSON cassé.
  • 3 cas universellement ratés (Pneumo VRS, Aura migr., Salpingite) → soit DPI à enrichir, soit vérité-terrain à rediscuter avec Pauline.

Pendant la démo réelle (cf. LESSONS_LEARNED_GHT_2026-05.md) : gemma4:31b-cloud retenu pour T2A MOREL (qualité clinique propre, run 8 du 12 mai). Test ponctuel de qwen3-next:80b-cloud OK aussi mais pas durable. Ollama Cloud 503 vécue le 12 mai → robustesse non couverte. gemma3:27b confabule sur PMSI français (invente GEMSA), à NE PAS utiliser en fallback.


4. Replay — méthodes, blocages observés, options

4.1. Architecture replay actuelle (rappel)

VWB Flask + SQLite édite un workflow déclaratif. Le serveur (api_stream.py) dispatche step par step à un client Léa V1 sur Windows distant, qui exécute via la cascade de résolution UI (OCR → template → VLM/grounding). Transport = HTTP pull / long-poll GET /replay/next.

Trois engines pertinents :

  • agent_v0/server_v1/replay_engine.py — pilotage côté serveur
  • agent_v0/server_v1/replay_verifier.py — vérification post-action
  • agent_v0/server_v1/replay_learner.py + replay_memory.py — apprentissage (import cassé sur get_target_memory_store)

4.2. Diagnostic phare — Replay bloqué 8 mai 2026

Source : docs/REPLAY_BLOCAGE_NOTES_MEDICALES_2026-05-08.md. Replay replay_free_68ca51ab sur Urgence_aiva_demo cancellé à 10:34.

Deux causes simultanées :

  1. Cause primaire — désync HTTP : Client Léa V1 utilise read_timeout=5 s sur GET /replay/next (agent_v1/core/executor.py:1786). Le serveur exécute parfois extract_text (57 s) PUIS dispatch un click dans le même appel HTTP. Le client coupe avant la réponse. L'action click est déjà poppée de la queue serveur et stockée dans _retry_pending mais jamais re-dispatchée (pas de watchdog). 9 actions sautées en 33 s sur les steps 10/12/14/17.

  2. Cause aggravante — OCR-DIRECT center-of-line : _resolve_by_ocr_text (resolve_engine.py:1447-1527) retourne le centre de la ligne docTR entière quand le target_text est un sous-fragment (score 0.8). La barre de tabs Easily est détectée comme UNE ligne → Imagerie / Notes médicales / Synthèse Urgences renvoient tous (0.23, 0.28). Confirmé par e2e_singleshot du même jour.

4.3. Hypothèses systématiquement testées (≠ rustinées)

Cf. §2 du diagnostic. Sur 6 hypothèses :

  • Hyp #1 (cascade serveur foire) : infirmée — la cascade n'est même jamais invoquée pour ces tabs.
  • Hyp #2 (cascade locale Léa) : infirmée — client n'a rien reçu.
  • Hyp #3 (coords brutes obsolètes) : infirmée — strict mode bypass la bbox. Anomalie cosmétique restante : ancres anchor_0438bd2d9bdd_1778161174 et anchor_6a2591e7c51c_1778229076 ont des bboxes décalées d'un cran à gauche.
  • Hyp #4 (offset écran live vs record) : partiellement vraie — offset ±10-30 px, gérable, dégradé par le bug OCR-DIRECT.
  • Hyp #5 (event onclick JS de la maquette) : infirméeaddEventListener('click') propre sur <a class="tab">, aucun overlay.
  • Hyp #6 (cache client/serveur) : infirmée — aucun from_memory=True, TargetMemoryStore pas hit.

4.4. Quatre correctifs proposés (gradués)

Repris du diagnostic §5 :

Correctif Effort Risque Effet
Quick fix 1timeout=5 → 30 côté client 510 min très bas Plus aucun click perdu sur extract_text/t2a_decision lents
Quick fix 2 — OCR-DIRECT center-of-span 1015 min moyen Chaque tab résolu à son propre centre. À NE PAS appliquer à chaud démo
Fix moyen terme — watchdog _retry_pending côté serveur 3060 min moyen Toute action dispatchée sans REPORT depuis > 30s repush en tête de queue, lea:dispatch_orphan_resent
Fix structurel — SSE ou WebSocket 12 j Push ack-based, suppression du bug timeout pour de bon, détection immédiate de déconnexion

4.5. État post-démo (19 mai) — 5 bugs racines P0 non résolus

Source : docs/LESSONS_LEARNED_GHT_2026-05.md §🔴.

Bug Cause Contournement actuel
VWB recapture anchor ne régénère pas le PNG capture.py réutilise PNG existant ou écrit avant screenshot recapture inutile
Stop VWB ne purge pas la queue serveur pas d'appel POST /api/v1/traces/stream/replay/<id>/cancel au clic Stop ./scripts/cancel-replays.sh manuel
Coord client Léa Y cassé (÷ ~27) mss.monitors[1] retourne intermittemment 2560×60 aucun
Bug skip ord 13 orchestration non identifiée, transition serveur→visuel→serveur aucun, NOT REPRO 100%
Bug échelle pixel grounding Ollama DETTE-006/010/014, Qwen2VLImageProcessorFast patch_size=16 factor 32 ≠ 28 non posé

Démo livrée grâce à Demo_urgence_3_db (46 steps, MOREL Catherine, UHCD 1750 €) et bypass LLM static_result/static_text (replay_engine.py steps 12-14). Pas réutilisable client.

4.6. Contournements actifs côté replay (à survoler avant tout déploiement)

Repris de LESSONS_LEARNED_GHT_2026-05.md (§⚠ Contournements actifs) :

  • Drift exemption template ≥ 0.95 / hybrid ≥ 0.80 (resolve_engine.py:2367-2390)
  • Fallback heartbeat sur capture < 1200×800 (api_stream.py:4422)
  • Flag pré-check OCR off par défaut (RPA_ENABLE_TEXT_PRECHECK=false)
  • RPA_VLM_MODEL=gemma4:e4b hardcodé Léa (tag inexistant) — exporter qwen2.5vl:7b
  • Mot de passe loli en clair dans scripts SSH/sudo
  • Bypass Ctrl+V via ydotool au lieu de NoMachine clipboard

4.7. Code orphelin/débranché côté replay (audit 8 mai)

  • _resolve_by_yolo défini, importé, jamais appelé (DETTE-004)
  • _fuzzy_match import mort api_stream.py:4372
  • VisualEmbeddingManager + ScreenshotValidationManager définis non instanciés (DETTE-005)
  • ShadowLearningHook défini non instancié (DETTE-009)
  • _handle_possible_popup côté client, 0 site d'appel
  • Pre-check VLM par-clic désactivé par if False: dans observe_reason_act.py:1704-1713 (DETTE-008)
  • Trois implémentations smart_resize coexistent (DETTE-007)
  • pause_for_human ignorée silencieusement en mode autonome (api_stream.py:3011-3017)

4.8. Smoke test finalize → replay (2026-05-20)

Source : docs/SMOKE_TEST_FINALIZE_REPLAY_2026-05-20.md.

Le flux finalize → proposition utilisateur → replay-session est déjà câblé côté agent :

  • streamer.py:96-103, 627-635set_on_finalize_result + invocation
  • main.py:31, 222, 445-448 — wire callback dans start_session
  • finalize_contract.py (untracked) — dispatch_finalize_result(ui, payload, replay_name)
  • smart_tray.py:577-599offer_finalize_replay + dialog consent Article 14

Contrat serveur attendu : replay_launch.status (started/failed), replay_ready, replay_request.

4 fichiers à SCP manuellement vers Léa Windows (finalize_contract.py en premier, c'est un nouveau fichier, ImportError garanti sinon).


5. Croisements et liens forts

5.1. Le replay actuel échoue avant même que le grounding entre en scène

Le diagnostic 8 mai est explicite : le bug primaire est transport (HTTP pull/long-poll, timeout client trop court, pas de watchdog), pas vision. Tous les efforts d'amélioration VLM (vLLM, InfiGUI, Qwen3-VL, smart_resize) sont nécessaires mais ne corrigeront RIEN tant que les actions sont perdues entre serveur et client.

Lien fort : QW2 LoopDetector + QW4 SafetyChecksProvider (sprint mai) traitent les symptômes (UI bloquée, validation humaine) mais pas la cause racine (HTTP fragile). Une refonte SSE/WebSocket est citée comme "fix structurel" par le diagnostic 8 mai et n'apparaît dans aucun plan post-démo.

5.2. Le pattern Planner-Actor-Validator de Skyvern décrit littéralement notre dette

  • VWB = Planner statique → mais inflexible, pas de re-planification au runtime.
  • Léa = Actor → fonctionnel.
  • Validator = absent ou laxiste → le bug step 10 (Imagerie cliqué dans bandeau Edge, REPORT success=True) en est l'illustration.

Le pHash global utilisé pour VERIFY post-action est connu insuffisant (feedback_phash_vs_dialog_in_vm.md). Un Validator-as-component avec vérification sémantique (texte attendu présent dans la zone visée, par exemple) éliminerait toute la classe de bugs "j'ai cliqué quelque part mais pas où je voulais".

5.3. OmniParser ↔ notre cascade

OmniParser tokenise l'écran en éléments structurés AVANT le VLM principal. UI-DETR-1 fait quelque chose d'analogue mais SEULEMENT côté VWB recording, pas en replay runtime — asymétrie connue (cf. CLAUDE.md). Logger systématiquement la liste des candidats à chaque appel _resolve_target (suggestion §4.1 du doc inspiration) donnerait une "vue parsée" implicite sans refonte.

5.4. medgemma:4b — l'illusion du modèle médical

Apparaît avec un nom prometteur dans 2 benchs distincts (BENCH_SAFETY_CHECKS_2026-05-06.md §résultats, BENCH_T2A_DECISION_11DOSSIERS.md #12). Mauvais aux deux : [] systématique en safety_checks, 4/11 (36%) en T2A avec JSON cassé. Le nom suggère plus que la performance.

5.5. Le bug d'échelle bbox_2d est la racine documentée d'un problème encore actif

MIGRATION_VLM_PLAN_2026-05-09.md documente précisément la cause (smart_resize Ollama opaque). Le module officiel a été commité (0d7bcd18a) mais DETTE-014 signale qu'il est mal calé. Trois implémentations coexistent (DETTE-007). Le bench bbox cible (§5 du plan) n'a pas été refait post-migration — checkpoint manquant pour valider la trajectoire.

5.6. Les frameworks externes valident notre direction

OpenAdapt + Skyvern + OmniParser + TagUI = 4 projets matures qui formalisent ce qu'on fait déjà en pratique. Convergence indépendante = signal fort.

Mais ce qu'ils ont en plus n'est pas trivial à rattraper :

  • Vocabulaire normé (Policy/Grounding/Safety Gate/Validator) → adoptable sans refonte, gain pitch.
  • Pre-built templates / use cases → maturité de marché, on n'a que la démo GHT.
  • Evaluation-Driven Feedback (OpenAdapt) — on a TargetMemoryStore (Phase 1 apprentissage Léa) mais sans pipeline d'entraînement.

6. Carte des documents de référence (à charger dans le contexte selon le sujet)

Étude techno externe

  • docs/INSPIRATION_FRAMEWORKS_2026-05-10.md — OpenAdapt / Skyvern / OmniParser / TagUI, patterns à adopter
  • docs/QW_SUITE_MAI.md — synthèse livraison QW1+QW2+QW4 (5 frameworks computer-use)
  • docs/superpowers/specs/2026-05-05-qw-suite-mai-design.md — spec design détaillée, décisions architecturales
  • docs/superpowers/plans/2026-05-05-qw-suite-mai.md — plan d'exécution

VLM, grounding, modèles

  • docs/HISTORIQUE_VLM_IMPLEMENTATIONS_2026-05-08.md — audit complet implémentations, commits, code potentiellement perdu (rien d'irrécupérable)
  • docs/MIGRATION_VLM_PLAN_2026-05-09.md — plan migration qwen2.5vl Ollama → vLLM/Transformers Qwen3-VL, bench bbox_2d
  • docs/VLM_DETECTION_IMPLEMENTATION.md — implémentation initiale (22 nov 2025)
  • docs/OLLAMA_INTEGRATION.md — intégration Ollama
  • docs/reference/QWEN3_VL_CONFIGURATION.md — config Qwen3-VL

Benchmarks

  • docs/BENCH_T2A_DECISION_11DOSSIERS.md — 18 modèles × 11 DPI, gemma3:27b-cloud retenu
  • docs/BENCH_SAFETY_CHECKS_2026-05-06.md — 5 modèles × 5 scénarios, gemma4:latest retenu
  • docs/BENCH_MEDGEMMA.md + .json — medgemma:4b CIM-10 (écarté pour safety/T2A)
  • docs/BENCH_MINI_LLM_NLP.md — 14 commandes NLP fr pour Léa
  • docs/QW_SMOKE_TESTS_2026-05-06.md — smoke tests QW Suite

Replay — diagnostic et méthodes

  • docs/REPLAY_BLOCAGE_NOTES_MEDICALES_2026-05-08.md — diagnostic complet replay_free_68ca51ab, 4 correctifs proposés, le doc le plus instructif sur les méthodes
  • docs/LESSONS_LEARNED_GHT_2026-05.md — 15 jours de bug-chasing, 5 bugs P0, contournements actifs
  • docs/SMOKE_TEST_FINALIZE_REPLAY_2026-05-20.md — flux finalize → replay câblé, fichiers à SCP
  • docs/AUDIT_FINALIZE_CONTRACT_INTEGRATION_2026-05-20.md — audit contrat finalize
  • docs/CR_AUDIT_PAUSED_RESUME_BUS_2026-05-22.md — audit pause/resume bus de replay
  • docs/CR_AUDIT_SETUP_VISUAL_GUARDS_2026-05-22.md — audit guards visuels au replay
  • docs/AUDIT_LEA_FIRST_RUNTIME_2026-05-19.md — audit runtime Léa-first post-démo
  • docs/EXECUTION_LOOP_FLAGS.md — flags boucle d'exécution
  • docs/DETTE_TECHNIQUE.md — 14 entrées (DETTE-001 à DETTE-014)

Audits transversaux 8-10 mai

  • docs/AUDIT_CONTROLES_DEBRANCHES_2026-05-08.md — 50+ findings serveur+client
  • docs/AUDIT_DIM_TIM_DEMO_GHT_2026-05-08.md — audit médecin DIM + TIM
  • docs/AUDIT_BDD_WORKFLOW_2026-05-10.md — audit BDD workflows
  • docs/BUG_PRECHECK_SPATIAL_BLINDNESS_2026-05-08.md — DETTE-001
  • docs/INVESTIGATION_MEMOIRE_VISUELLE_ORPHELINE_2026-05-09.md — DETTE-005, DETTE-009
  • docs/CARTE_FONCTIONNELLE_2026-05-08.md — carte fonctionnelle système

Vision/architecture de fond

  • docs/VISION_RPA_INTELLIGENT.md — vision produit (CLAUDE.md feedback_follow_spec : à lire AVANT toute proposition)
  • docs/ROADMAP_RPA_100_VISION.md — roadmap 100% vision
  • docs/REFERENCE_VISION_RPA.md — référence VWB Vision RPA (jan 2026)
  • docs/CARTOGRAPHY.md — cartographie d'exécution
  • docs/PLAN_ACTEUR_V1.md / docs/PLAN_APPRENTISSAGE_LEA.md / docs/PLAN_AGENT_RUST.md — plans cibles

7. Projets et benchmarks externes nommément cités

À reprendre dans un brief ou un mail (sourcing déjà fait dans INSPIRATION_FRAMEWORKS_2026-05-10.md §8) :


8. Ce que cette synthèse n'aborde pas (à demander à Dom si besoin)

  • Estimation chiffrée du coût d'une refonte SSE/WebSocket dans api_stream.py.
  • Comparaison vLLM vs Transformers direct pour le grounding (le plan migration laisse la question ouverte).
  • État d'OpenAdapt Evaluation-Driven Feedback vis-à-vis de notre TargetMemoryStore actuel.
  • Tests des modèles candidats à un fine-tuning GUI (GUI-R1, OS-Atlas, ShowUI, SE-GUI) cités dans memory/project_finetuning_vlm_plan.md mais hors périmètre des bench mai.
  • Bench de UI-DETR-1 standalone (utilisé au recording VWB, pas évalué isolément).

Document destiné à être consommé en lecture seule par un agent ou un humain qui doit se mettre à niveau sur l'état des études techno et du replay au 23 mai 2026. Toute action à prendre est hors-périmètre de ce doc et nécessite une décision explicite de Dom.