docs: add POC specs, handoffs, and research notes

docs/recherche/AXE_C_LEARNING_SHADOW.md

@@ -0,0 +1,352 @@
+# AXE C — Shadow learning, Fine-tuning VLM grounding, Memory store visuel
+
+**Date :** 2026-05-23
+**Auteur :** Claude (agent recherche prospective)
+**Statut :** lecture seule, recherche externe + croisement avec dette interne (DETTE-005, DETTE-009). Aucune modif de code. Sources web < 6 mois priorisées.
+**Périmètre :** 3 sous-axes prospectifs sur l'apprentissage et la mémoire visuelle pour rpa_vision_v3.
+
+---
+
+## 1. TL;DR + recommandation priorisée
+
+**Insight central :** les 3 axes (C1 Shadow, C2 Fine-tuning, C3 Memory) ne sont **pas substituables** mais **séquentiels** :
+
+- **C3 (memory)** est l'**investissement le plus immédiatement rentable** : `VisualEmbeddingManager` est déjà écrit, le pattern Skyvern (cache + fallback IA) est éprouvé à 10–100× speed-up, et ça réduit la latence de la démo SANS toucher au grounding.
+- **C1 (shadow)** est la **collecte de carburant** pour C2 : sans traces propres (DETTE-009), pas de dataset de fine-tuning Easily Assure. `ShadowLearningHook` orphelin = blocage prioritaire à lever.
+- **C2 (fine-tuning)** est le **différenciateur à 6–12 mois** : la littérature 2025–2026 (Visual-RFT, UI-R1, GUI-R1, SE-RFT, GUI-Actor) prouve qu'on peut atteindre SOTA avec **3k–10k exemples** via GRPO sur Qwen2.5-VL-3B/7B, pour quelques dizaines d'euros HF Jobs. Mais ça suppose un dataset propre, donc C1 d'abord.
+
+**Séquence recommandée :**
+
+1. **Vague courte (1–2 semaines)** : activer `VisualEmbeddingManager` (C3) en cache opportuniste devant la cascade `_resolve_target` + activer `ShadowLearningHook` (C1) sur les replays réussis. Aucun ML, juste du câblage.
+2. **Vague moyenne (1–2 mois)** : collecter ≥ 1k traces Shadow propres sur Easily Assure via la démo récurrente, formaliser le format de trace inspiré OpenAdapt (SQLite trajectoires).
+3. **Vague longue (3–6 mois post-démo client)** : fine-tuning GRPO Qwen2.5-VL-3B sur 3k–5k exemples Easily Assure spécifiques, via HF Jobs ou DGX Spark. Coût attendu < 50 €.
+
+**Dépendance critique avec AXE_B2 Validator** : un Shadow learning sur traces sales (replay qui croit avoir réussi mais a cliqué à côté — cf. bug step 10 Imagerie/bandeau Edge) injecte du poison dans la mémoire. **Le Validator sémantique doit précéder l'activation de C1**, sinon `SignatureStore` accumule des faux positifs.
+
+---
+
+## 2. C1 — Shadow learning : OpenAdapt + ShadowLearningHook orphelin
+
+### 2.1 OpenAdapt — pipeline détaillé
+
+**Repo :** [github.com/OpenAdaptAI/OpenAdapt](https://github.com/OpenAdaptAI/OpenAdapt) (~7k★ mai 2026)
+
+**Architecture meta-package modulaire** (refonte récente vs monorepo initial) :
+
+| Sous-paquet | Rôle |
+|---|---|
+| `openadapt-capture` | Enregistrement actions utilisateur + screenshots → SQLite. Paires **observation/action** = "trajectoires". |
+| `openadapt-privacy` | Scrub PII/PHI avant stockage (intérêt direct pour notre démo médicale). |
+| `openadapt-retrieval` | Index sémantique (FAISS-like) sur les démonstrations stockées. |
+| `openadapt-ml` | Moteur ML : charge trajectoires, fine-tune VLM, génère templates automation. |
+| `openadapt-grounding` | Mappe intention → coords UI au runtime. |
+| `openadapt-evals` | Bench sur benchmarks publics. |
+
+**Pipeline complet :** `Demonstrate → Learn → Execute`. La devise "**success traces become new training data**" (citée `INSPIRATION_FRAMEWORKS_2026-05-10.md` §5) est instanciée par : `openadapt-capture` (Demonstrate) → `openadapt-ml` (Learn fine-tune VLM) → `openadapt-grounding` (Execute conditionné sur les démos via retrieval ET fine-tuning, combinés).
+
+**Format de trace** (déduit du repo, pas accessible en détail sans cloner) : table SQLite `recordings` + tables `screenshots`, `action_events`, `window_events`, chaînées par `recording_id`. Chaque clic = ligne `action_events` avec coords + screenshot lié + window title. **Schéma très proche** de notre `data/runner_captures/` actuel + métadonnées agent_v0.
+
+**Différenciateur** : OpenAdapt **conditionne au runtime** l'agent sur des démos humaines récupérées via retrieval sémantique. C'est la combo cache + fine-tuning + grounding que rpa_vision_v3 a en pièces détachées (TargetMemoryStore Phase 1 = retrieval embryonnaire, ShadowLearningHook = capture, fine-tuning = TODO).
+
+### 2.2 Comment activer `ShadowLearningHook` orphelin (DETTE-009)
+
+Constat investigation `INVESTIGATION_MEMOIRE_VISUELLE_ORPHELINE_2026-05-09.md` :
+
+- Fichier : `core/grounding/shadow_learning_hook.py` (156 lignes, commit `73cea2385` du 2026-04-25, "Phase 6").
+- **0 site d'instanciation** au runtime.
+- Attend un callback `on_click_observed(x, y, screenshot, window_title, target_label)` qui n'est jamais appelé.
+- Le `ShadowObserver` (`core/workflow/shadow_observer.py`) ne configure aucun callback de ce type.
+- Phase 5 (`e2046837c`) câble FAST→SMART→THINK dans ORA mais oublie d'instancier la Phase 6.
+
+**Hooks d'activation envisageables** (à valider avec Dom avant code) :
+
+| Point d'accroche | Avantage | Risque |
+|---|---|---|
+| Callback dans `ShadowObserver._on_mouse_click` | Apprentissage en temps réel sur démo humaine | Pollution si Validator absent (cf. dépendance B2) |
+| Hook post-success dans `replay_engine.py` (après REPORT success=True) | Apprentissage uniquement sur traces "vérifiées" | Faux positifs si pHash global laxiste (bug step 10 connu) |
+| Job offline batch sur `data/runner_captures/<session>/events.jsonl` | Aucun risque runtime, repassable | Pas de boucle d'amélioration continue |
+
+**Recommandation :** commencer par le **job batch offline** (sécurisé), puis migrer vers post-success hook quand AXE_B2 Validator sémantique sera en place. Ne PAS activer sur `ShadowObserver` direct tant que Validator pHash global est en vigueur — c'est précisément ce que `feedback_phash_vs_dialog_in_vm.md` reproche.
+
+### 2.3 Autres frameworks — patterns Shadow 2025–2026
+
+- **Skyvern** : pattern "**explore → replay**" déterministe. Quand un agent réussit une tâche, le sélecteur (ou la coord visuelle) est mémorisé dans un cache indexé par `cache_key` Jinja2 rendu à partir des paramètres du workflow. Réutilisation 10–100× plus rapide. Si le cache miss ou si replay échoue, fallback IA + mise à jour du cache. ([deepwiki](https://deepwiki.com/Skyvern-AI/skyvern/1-overview))
+- **browser-use** : tableau `learned_skills` avec `success_rate`, `usage_count`, `last_used`. Modèle de skills nommés réutilisables. ([source](https://lobehub.com/skills/saik0s-mcp-browser-use-browser-use))
+- **AGUVIS** : 4.2M trajectoires GUI multimodales (grounding + planning). Format normalisé multi-OS. ([aguvis-project](https://aguvis-project.github.io/))
+- **UGround** : 10M éléments / 1.3M screenshots, ~95% web. Dataset le plus volumineux du domaine. ([osu-nlp-group](https://osu-nlp-group.github.io/UGround/))
+
+### 2.4 Datasets RPA traces publiquement disponibles
+
+Repérés via [Computer-Browser-Phone-Use-Agent-Datasets](https://github.com/Khang-9966/Computer-Browser-Phone-Use-Agent-Datasets) :
+
+- **AGUVIS** — 4.2M sample elements + 1.3M trajectoires (license à vérifier).
+- **UGround** — 10M GUI elements, ~95% web (license à vérifier).
+- **ScreenSpot / ScreenSpot-v2 / ScreenSpot-Pro** — benchmarks d'évaluation, pas vraiment training (mais utilisables en few-shot).
+- **AndroidControl** — mobile, utilisé par UI-R1.
+- **Mind2Web** — web tasks.
+- **WebVoyager** — Skyvern à 85.85%, benchmark.
+
+**Aucun de ces datasets ne couvre Easily Assure ni le domaine hospitalier français**. Ils servent de **base pré-entraînement**, pas de **dataset cible**. Notre asset : les traces internes de la démo MOREL Catherine et autres.
+
+### 2.5 Recommandation d'intégration C1
+
+**Court terme (1–2 semaines)** :
+1. Job batch offline : itérer sur `data/runner_captures/<session>/events.jsonl` post-démo réussie, appeler `ShadowLearningHook.on_click_observed` rétrospectivement → enrichit `SignatureStore`.
+2. Mesurer le hit-rate de `SignatureStore` au replay suivant.
+
+**Moyen terme (1 mois)** :
+3. Définir notre **format de trace canonique** (inspirer du schéma OpenAdapt SQLite + privacy scrub avant tout).
+4. Brancher le hook sur `ShadowObserver._on_mouse_click` UNIQUEMENT après merge du Validator sémantique (B2).
+
+**Anti-pattern à éviter** : activer le hook sur des replays VWB sans Validator. Cf. bug step 10 mai : on apprendrait à cliquer dans le bandeau Edge au lieu du tab Imagerie.
+
+---
+
+## 3. C2 — Fine-tuning VLM grounding 2025–2026
+
+### 3.1 Table comparée des techniques
+
+| Méthode | Modèle base | Données | Gain vs SFT | Source |
+|---|---|---|---|---|
+| **Visual-RFT** (mars 2025) | Qwen2-VL-2B / 7B | **239 images** (LISA few-shot) à 500 steps | +24.3% classif, +21.9 mAP COCO 2-shot | [arxiv 2503.01785](https://arxiv.org/html/2503.01785v1) |
+| **UI-R1** (AAAI 2026, mars 2025) | Qwen2.5-VL-3B | **2k–3k exemples** | +22.1% ScreenSpot, +6.0% ScreenSpot-Pro, +12.7% AndroidControl | [github UI-R1](https://github.com/lll6gg/UI-R1) |
+| **GUI-R1** (avril 2025) | Qwen2.5-VL | **3k exemples** (0.02% du training OS-Atlas) | Bat OS-Atlas-7B SFT sur tous les bench | [arxiv 2504.10458](https://www.emergentmind.com/papers/2504.10458) |
+| **GUI-G1** (mai 2025) | Qwen2.5-VL | R1-Zero style | Analyse théorique R1 grounding | [openreview](https://openreview.net/forum?id=1XLjrmKZ4p) |
+| **SE-GUI / SE-RFT** (mai 2025) | 7B | **3k samples** | SOTA ScreenSpot-Pro auto-supervisé | [arxiv 2505.12370](https://arxiv.org/html/2505.12370) |
+| **GUI-Actor** (NeurIPS 2025) | Qwen2.5-VL-7B | Coordinate-free grounding | 42.2/44.6 ScreenSpot-Pro | [microsoft/GUI-Actor](https://github.com/microsoft/GUI-Actor) |
+| **GUI-CURSOR** (2025) | Qwen2.5-VL-7B | — | 88.8→93.9 SS-v2, 26.8→56.5 SS-Pro | [arxiv 2509.21552](https://arxiv.org/pdf/2509.21552) |
+| **POINTS-GUI-G** (2026) | 8B | — | 59.9 SS-Pro, 66.0 OSWorld-G | [arxiv 2602.06391](https://arxiv.org/pdf/2602.06391) |
+| **GUI-AIMA** (2025) | 3B | **509k samples / 101k screenshots** | SOTA data-efficient | [arxiv 2511.00810](https://arxiv.org/pdf/2511.00810) |
+
+**Convergence claire** :
+- **GRPO** (Group Relative Policy Optimization, originaire de DeepSeek-R1) > SFT pour le grounding GUI.
+- **Reward function rule-based** : IoU pour box, accuracy 0/1 pour clic point, format compliance JSON.
+- **Quelques milliers d'exemples suffisent** (3k–10k) pour un gain SOTA sur Qwen2.5-VL-3B/7B base.
+- Le **base model Qwen2.5-VL** domine la littérature (vs UI-TARS, vs InfiGUI).
+
+### 3.2 Datasets et licences
+
+| Dataset | Volume | License | Utilisable commercialement ? |
+|---|---|---|---|
+| ScreenSpot | 1.2k instructions | À vérifier (paperswithcode) | Probable academic only |
+| ScreenSpot-v2 | corrigé v1 | OS-Copilot/ScreenSpot-v2 HF | À vérifier |
+| ScreenSpot-Pro | high-res pro | likaixin2000/ScreenSpot-Pro-GUI-Grounding | À vérifier |
+| UGround | 10M elements | OSU-NLP-Group | Academic, vérifier CC-BY-NC |
+| AGUVIS | 4.2M | aguvis-project | Académique, vérifier |
+| UI-R1 (modèle + data) | 2k–3k | **Apache-2.0** ✅ | Commercial OK |
+| GUI-Actor | — | Microsoft, MIT-like | Commercial OK |
+
+**Action immédiate** : **lire chaque LICENSE avant entraînement commercial**. La conclusion forte est qu'**aucun dataset public ne couvre Easily Assure**. La valeur sera dans **notre propre dataset interne** dérivé des traces démo.
+
+### 3.3 Plan concret pour fine-tuner sur Easily Assure
+
+**Hypothèse de travail** : on cible un fine-tuning **complémentaire** au modèle de base (Qwen2.5-VL-3B ou Qwen3-VL-8B), spécifique au domaine Easily Assure (UI typique, fonts, layout, vocabulaire médical FR).
+
+**Étapes proposées (à valider Dom)** :
+
+1. **Collecte** (C1) : 100 sessions Shadow réussies × ~30 clics utiles = **3 000 paires (screenshot, target_text, click_xy)**. Ratio compatible UI-R1 / GUI-R1.
+2. **Format** : JSONL `{image_path, instruction, bbox_xyxy_or_point, screen_resolution}`. Pré-process via `smart_resize` officiel (DETTE-014 résolue d'abord).
+3. **Anonymisation** : appliquer `core/anonymize/*` (déjà existant t2a) sur chaque crop avant export. Critique pour healthtech.
+4. **Méthode** : **GRPO + LoRA** sur Qwen2.5-VL-3B base.
+   - Reward function : IoU > 0.5 (cible 1.0, sinon 0) + format JSON valide.
+   - 500–1000 steps suffisent (cf. Visual-RFT 200 steps + 500 grounding).
+5. **Hardware** : **HF Jobs / DGX Cloud H100** (8.25 $/h, [source](https://huggingface.co/blog/train-dgx-cloud) — ATTENTION : service deprecated avril 2025, vérifier alternative HF Jobs actuel). Ou **DGX Spark** Dom roadmap (`memory/project_roadmap_vision.md`).
+   - Alternative cloud GPU 2026 : H100 $4.50–$36/h AWS, $2.99/h en marketplace ([spendark](https://spendark.com/blog/machine-learning-cloud-cost/)).
+6. **Durée estimée** : 8–12h sur 1× H100 (basé sur QLoRA 7B), ou 4–6h sur 8× H100 parallèle.
+7. **Coût estimé** : **30–80 €** (1 run complet) ou **< 10 €** si A100 marketplace + QLoRA 3B.
+8. **Évaluation** : split 80/20 sur les traces internes + non-régression sur ScreenSpot-Pro public.
+
+### 3.4 LoRA vs Full Fine-Tuning — recommandation
+
+**Source clé :** [arxiv 2410.21228 "LoRA vs Full Fine-tuning: An Illusion of Equivalence"](https://arxiv.org/pdf/2410.21228) — LoRA introduit des "intruder dimensions" qui réduisent la généralisation hors-domaine.
+
+**Mais pour notre cas (spécialisation Easily Assure)** :
+- **On NE VEUT PAS généraliser** — on veut sur-fit (sainement) une UI spécifique.
+- LoRA / QLoRA suffisent : Qwen2.5-VL-3B + LoRA tient sur **RTX 4070 12 GB** ([source](https://datature.io/blog/how-to-fine-tune-qwen2-5-vl)).
+- Full FT sur 3B "hit practical limits with unstable loss curves and VRAM pressure" ([kaitchup](https://kaitchup.substack.com/p/qwen25-qlora-lora-and-full-fine-tuning)).
+
+**Reco :** **QLoRA 4-bit sur Qwen2.5-VL-3B**, rang 16–64. Iteration locale possible sur le RTX 5070 du Dom. Pas besoin HF Jobs pour le prototype. HF Jobs uniquement pour les runs de production.
+
+**À éviter** : full FT 7B+ pour un usage Easily Assure. ROI insuffisant face à la complexité ops.
+
+---
+
+## 4. C3 — Memory store visuel
+
+### 4.1 Skyvern prompt caching — architecture détaillée
+
+**Sources :** [skyvern deepwiki](https://deepwiki.com/Skyvern-AI/skyvern/1-overview), [skyvern blog MCP](https://www.skyvern.com/blog/mcp-server-architecture-explained/), [zread optimization](https://zread.ai/Skyvern-AI/skyvern/29-optimization-strategies)
+
+**Mécanisme** :
+1. **Cache key** : template Jinja2 rendu à partir des paramètres du workflow (URL cible, valeurs de form, etc.).
+2. **Stockage** : quand une action AI réussit, Skyvern stocke le `selector_path` (DOM) ou la coord visuelle.
+3. **Replay** : runs suivants avec mêmes paramètres → match cache_key → exécute le script pré-généré (Python ou JS), **sans appeler le LLM**.
+4. **Fallback** : si replay échoue (UI a changé), AI re-engage automatiquement et **met à jour le cache**.
+
+**Gain mesuré :** **10–100× speed-up** sur runs cachés. "Deterministic replay flags if a price or SKU changes" — Skyvern utilise les changements détectés comme signal d'invalidation.
+
+**Différence vs Anthropic/OpenAI "prompt caching" classique** : Skyvern cache **les artefacts d'exécution** (scripts/sélecteurs), pas les tokens du prompt. C'est plus proche de notre `TargetMemoryStore` que d'un cache LLM.
+
+**Transposable à rpa_vision_v3** :
+- Cache key = `(workflow_id, step_id, target_label, target_description, screen_context_hash)`.
+- Cache value = `(click_xy, source: ocr|template|vlm, confidence, last_validated_at)`.
+- Invalidation = pHash zone d'intérêt change OU REPORT failure récent.
+
+### 4.2 FAISS + CLIP/DINOv2 vs ColPali/ColQwen — comparaison
+
+| Approche | Index size | Latence query | Granularité | Pertinence UI |
+|---|---|---|---|---|
+| **CLIP global + FAISS** | 1 vec/image (512–768d) | < 1 ms | Image entière | Bonne pour "ai-je déjà vu cet écran" |
+| **DINOv2 + FAISS** | 1 vec/image (768–1536d) | < 1 ms | Image entière | Meilleur que CLIP en self-sup, robuste aux occlusions ([source](https://medium.com/aimonks/image-similarity-with-dinov2-and-faiss-741744bc5804)) |
+| **DINOv2 crops + FAISS** | 1 vec/widget (768d) | 1–5 ms | Par widget | Cas idéal pour "ai-je déjà vu ce bouton dans CE contexte" |
+| **ColPali / ColQwen** | N patches × 128d | 5–50 ms (late interaction) | Patches × tokens query | SOTA documents visuels, plus lourd, [Nemotron ColEmbed V2](https://arxiv.org/html/2602.03992v1) NDCG@10=63.42 sur Vidore V3 |
+| **UISearch** ([arxiv 2511.19380](https://arxiv.org/pdf/2511.19380)) | Graph attributé | 47.5 ms median | Hiérarchie + spatial | 0.92 Top-5 sur 20k UIs financières |
+
+**Recommandation pour rpa_vision_v3 :**
+
+- **Niveau 1 (cache exact)** — `pHash` zone d'intérêt (déjà partiellement utilisé). Latence < 1 ms.
+- **Niveau 2 (cache flou widget)** — **DINOv2-base crops + FAISS** indexé par widget. Réutilise `VisualEmbeddingManager` (déjà écrit, DETTE-005) mais swap CLIP → DINOv2 (gain mesuré sur déduplication, [encord](https://encord.com/blog/dinov2-self-supervised-learning-explained/)).
+- **Niveau 3 (recherche sémantique cross-screens)** — différé. ColPali/ColQwen attrayants mais lourd à déployer ; UISearch très prometteur mais code non-public.
+
+**Verdict :** **FAISS + DINOv2** = bon compromis pragmatique 2026. ColPali = différé si besoin de retrieval cross-écrans riches.
+
+### 4.3 Comment activer `VisualEmbeddingManager` orphelin (DETTE-005)
+
+Constat investigation 2026-05-09 :
+
+- `core/visual/visual_embedding_manager.py` — 651 lignes, commit `a27b74cf2` (2026-01-29).
+- `core/visual/screenshot_validation_manager.py` — 571 lignes, idem.
+- **0 site d'instanciation runtime**, ni VEM ni SVM.
+- Investigation recommandait **ARCHIVE** sauf cas d'usage prod identifié, **car redondant avec `SignatureStore` + `fusion_engine.embedding_cache`**.
+
+**Réévaluation à la lumière de l'AXE_C :**
+
+Le verdict "archivage" du 9 mai était correct dans le cadre étroit "ce composant est-il actuellement utile ?". Mais l'AXE_C ouvre un cas d'usage clair :
+
+- **VEM = couche cache widget visuel** devant la cascade `_resolve_target`.
+- **SVM = validation continue** des targets stockées (cache invalidation par re-validation périodique).
+
+**Recommandation révisée (à statuer Dom)** :
+
+| Option | Pro | Contra |
+|---|---|---|
+| **A. Archiver VEM/SVM (verdict initial), refaire propre dans `core/grounding/`** | Pas de dette de réécriture, unifié avec `SignatureStore` | Perd 1200 lignes + tests existants |
+| **B. Réactiver VEM/SVM en swappant backbone CLIP → DINOv2** | Tests existants, archi serializer HMAC déjà signée | Architecture dupliquée avec `SignatureStore`, risque incohérence |
+| **C. Hybride : extraire la logique de cache HMAC + serializer signé de VEM dans `SignatureStore`, archiver le reste** | Best-of-both, signature crypto réutilisée | 1 jour de refactor |
+
+**Mon vote** : **C**, après livraison démo client. Mais **acter B comme MVP rapide** si la fenêtre est < 1 semaine et qu'on veut tester C3 sans refactor lourd.
+
+### 4.4 Cache invalidation — quand la mémoire devient stale
+
+**Stratégies observées dans la littérature 2025–2026 :**
+
+1. **Re-validation périodique** (SVM ScreenshotValidationManager prévoit ça) — recapture le widget, vérifie embedding similarity > seuil, sinon `STATUS=WARNING`.
+2. **Invalidation sur échec** — Skyvern : si replay déterministe échoue, fallback IA + update cache.
+3. **TTL versionné** — invalidation forcée à chaque changement de version du logiciel cible (Easily Assure update).
+4. **Watermark pHash** — pHash du widget au moment du cache. Si match au runtime → réutilise. Sinon → re-grounding.
+5. **Counter d'échecs** — `success_rate`, `usage_count` (pattern browser-use). Si `success_rate < 0.6` après N usages → purge.
+
+**Recommandation pour rpa_vision_v3 :**
+
+- Combo **pHash watermark** (rapide) + **counter d'échecs glissant** (robuste). Pas de SVM périodique au runtime (coût pour bénéfice douteux).
+- TTL nominal 7 jours, reset sur chaque succès vérifié par Validator sémantique (B2).
+- **Hard requirement** : ne JAMAIS écrire dans le cache sans Validator sémantique OK. Sinon poison cache cf. bug step 10 mai.
+
+---
+
+## 5. Recommandation séquence — 3 vagues d'effort
+
+### Vague 1 — Court terme (1–2 semaines, post-démo client)
+
+**Objectif :** quick wins sans toucher ML.
+
+1. **C3 niveau 1** : étendre le cache `pHash` existant aux widgets résolus avec succès. Storage SQLite simple.
+2. **C1 batch offline** : script ad-hoc qui rejoue `data/runner_captures/<session>/events.jsonl` post-réussite, appelle `ShadowLearningHook.on_click_observed` rétroactivement. Mesure hit-rate `SignatureStore` au replay suivant.
+3. **Définir le format de trace canonique** (inspirer OpenAdapt SQLite + anonymisation t2a-style).
+
+**Coût :** ~3–5 j-h. **Risque :** très bas.
+**Dépendance :** aucune (offline, hors chemin chaud).
+
+### Vague 2 — Moyen terme (1–2 mois)
+
+**Objectif :** collecter du dataset et fiabiliser le cache.
+
+1. **Attendre AXE_B2 Validator sémantique** (cf. dépendance critique §1).
+2. Une fois B2 livré : activer `ShadowLearningHook` sur callback post-success replay (PAS sur Shadow direct).
+3. **C3 niveau 2** : prototyper DINOv2 + FAISS sur 100 widgets démo. Option B (VEM réactivé) ou C (refactor propre).
+4. **Collecter ≥ 1k traces** Easily Assure propres via démos répétées + anonymisation.
+
+**Coût :** ~5–10 j-h. **Risque :** moyen (Validator semantic = chemin critique).
+**Dépendance forte :** AXE_B2 Validator sémantique merged.
+
+### Vague 3 — Long terme (3–6 mois post-démo client)
+
+**Objectif :** fine-tuning VLM spécifique Easily Assure.
+
+1. Dataset 3k–5k paires propres + anonymisées + smart_resize correct.
+2. **GRPO + QLoRA 4-bit sur Qwen2.5-VL-3B** (méthode UI-R1 / Visual-RFT). 500–1000 steps.
+3. Run local RTX 5070 ou cloud H100 marketplace. **Coût attendu : 10–80 €**.
+4. Évaluation : split interne 80/20 + non-régression ScreenSpot-Pro.
+5. Déploiement progressif : modèle fine-tuné en fallback du modèle base, A/B test sur démo.
+
+**Coût :** ~10–15 j-h + budget cloud < 100 €. **Risque :** moyen (succès très dépendant qualité dataset C1).
+**Dépendance forte :** AXE_A1 (choix modèle base finalisé : Qwen2.5-VL-3B vs Qwen3-VL-8B vs UI-R1-3B comme nouveau base déjà fine-tuné).
+
+---
+
+## 6. Dépendances avec autres AXEs
+
+- **AXE_B2 Validator** (collecte de traces propres) : **bloquant pour C1 sur replay live** + **prérequis pour cache C3 sans poison**. Tant que Validator pHash global laxiste (bug step 10) → C1 et C3 sur traces démo seulement.
+- **AXE_A1 (modèles à fine-tuner)** : choix base entre Qwen2.5-VL-3B (UI-R1 le valide), Qwen3-VL-8B (`memory/reference_vlm_models.md` retient), InfiGUI-G1-3B (production actuelle). À trancher avant C2.
+- **DETTE-014 smart_resize** : doit être résolue avant fine-tuning sinon coords mal calées dans le dataset.
+
+---
+
+## 7. Sources
+
+### C1 — Shadow learning
+- [OpenAdaptAI/OpenAdapt — GitHub](https://github.com/OpenAdaptAI/OpenAdapt)
+- [Skyvern-AI/skyvern — DeepWiki overview](https://deepwiki.com/Skyvern-AI/skyvern/1-overview)
+- [Skyvern optimization strategies — zread.ai](https://zread.ai/Skyvern-AI/skyvern/29-optimization-strategies)
+- [browser-use skills tracking — lobehub](https://lobehub.com/skills/saik0s-mcp-browser-use-browser-use)
+- [Computer-Browser-Phone-Use-Agent-Datasets](https://github.com/Khang-9966/Computer-Browser-Phone-Use-Agent-Datasets)
+- [15 Datasets for Training and Evaluating AI Agents — ODSC, avril 2026](https://odsc.medium.com/15-datasets-for-training-and-evaluating-ai-agents-c171dde4e0ce)
+
+### C2 — Fine-tuning VLM grounding
+- [Visual-RFT — arxiv 2503.01785](https://arxiv.org/html/2503.01785v1)
+- [UI-R1 (AAAI 2026) — GitHub lll6gg/UI-R1](https://github.com/lll6gg/UI-R1)
+- [UI-R1 — arxiv 2503.21620](https://arxiv.org/html/2503.21620)
+- [GUI-R1 — arxiv 2504.10458](https://www.emergentmind.com/papers/2504.10458)
+- [GUI-G1 R1-Zero training — openreview](https://openreview.net/forum?id=1XLjrmKZ4p)
+- [SE-RFT Self-Evolutionary — arxiv 2505.12370](https://arxiv.org/html/2505.12370)
+- [GUI-Actor NeurIPS 2025 — microsoft/GUI-Actor](https://github.com/microsoft/GUI-Actor)
+- [GUI-CURSOR — arxiv 2509.21552](https://arxiv.org/pdf/2509.21552)
+- [POINTS-GUI-G — arxiv 2602.06391](https://arxiv.org/pdf/2602.06391)
+- [GUI-AIMA — arxiv 2511.00810](https://arxiv.org/pdf/2511.00810)
+- [ScreenSpot-Pro — arxiv 2504.07981](https://arxiv.org/html/2504.07981v1)
+- [UGround — OSU NLP Group](https://osu-nlp-group.github.io/UGround/)
+- [AGUVIS Project](https://aguvis-project.github.io/)
+- [FocusUI CVPR 2026 — github.com/showlab/FocusUI](https://github.com/showlab/FocusUI)
+- [LoRA vs Full Fine-tuning — arxiv 2410.21228](https://arxiv.org/pdf/2410.21228)
+- [Qwen2.5 QLoRA / LoRA / Full FT comparison — kaitchup](https://kaitchup.substack.com/p/qwen25-qlora-lora-and-full-fine-tuning)
+- [How to Fine-Tune Qwen2.5-VL — Datature](https://datature.io/blog/how-to-fine-tune-qwen2-5-vl)
+- [HF Jobs / Train on DGX Cloud — HF blog](https://huggingface.co/blog/train-dgx-cloud) (⚠ deprecated avril 2025, vérifier alt)
+- [GPU Cloud Pricing 2026 — spendark](https://spendark.com/blog/machine-learning-cloud-cost/)
+- [How to Fine-Tune LLMs in 2026 — Spheron](https://www.spheron.network/blog/how-to-fine-tune-llm-2026/)
+
+### C3 — Memory store visuel
+- [Skyvern cache_key Jinja2 — deepwiki](https://deepwiki.com/Skyvern-AI/skyvern)
+- [Skyvern MCP architecture — blog](https://www.skyvern.com/blog/mcp-server-architecture-explained/)
+- [Late Interaction Retrieval (ColBERT, ColPali, ColQwen) — Weaviate](https://weaviate.io/blog/late-interaction-overview)
+- [ColPali — arxiv 2407.01449](https://arxiv.org/pdf/2407.01449)
+- [illuin-tech/colpali — GitHub](https://github.com/illuin-tech/colpali)
+- [Nemotron ColEmbed V2 — arxiv 2602.03992](https://arxiv.org/html/2602.03992v1)
+- [DINOv2 — Encord blog](https://encord.com/blog/dinov2-self-supervised-learning-explained/)
+- [DINOv2 + FAISS image similarity — Medium](https://medium.com/aimonks/image-similarity-with-dinov2-and-faiss-741744bc5804)
+- [UISearch graph embeddings UI screenshots — arxiv 2511.19380](https://arxiv.org/pdf/2511.19380)
+- [State of AI Agent Memory 2026 — mem0.ai](https://mem0.ai/blog/state-of-ai-agent-memory-2026)
+- [Best Vector Databases For Multimodal 2026 — acecloud](https://acecloud.ai/blog/best-vector-databases-for-multimodal-genai/)
+
+---
+
+*Document destiné à être lu en complément de `SYNTHESE_TECHNOS_REPLAY_2026-05-23.md`, `INSPIRATION_FRAMEWORKS_2026-05-10.md`, et `INVESTIGATION_MEMOIRE_VISUELLE_ORPHELINE_2026-05-09.md`. Toute action à prendre nécessite décision Dom.*