Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

backup: snapshot post-démo GHT 2026-05-19
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

Browse Source 
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>
This commit is contained in:
Dom
2026-05-19 14:55:06 +02:00
parent f2212e77e3
commit 5ea4960e65
627 changed files with 211348 additions and 169 deletions
Download Patch File Download Diff File Expand all files Collapse all files

348
archive/business_docs/ANALYSE_MOAT_RPA_VISION_V3.md Normal file
View File

@@ -0,0 +1,348 @@
# Analyse MOAT - RPA Vision V3
**Date:** 18 janvier 2026
**Version:** 1.0
**Objectif:** Photographie complète du projet pour valider les avantages concurrentiels défendables
---
## Résumé Exécutif
| MOAT | Score | Statut |
|------|-------|--------|
| **Techno** (Hard to Copy) | 85% | Point fort |
| **Data/Apprentissage** (Hard to Catch Up) | 60% | Infrastructure OK, capitalisation à améliorer |
| **Déploiement Santé** (Hard to Enter) | 50% | Technique OK, docs compliance manquantes |
---
## MOAT 1 : TECHNO (Hard to Copy)
### Capacités Implémentées
| Capacité | État | Détails |
|----------|------|---------|
| **Vision-native** | Implémenté | CLIP ViT-B-32 (512-dim) + OWL-v2 zero-shot + OpenCV + Qwen2.5-VL |
| **Matching hiérarchique** | Implémenté | 3 niveaux : fenêtre (20%) + région (30%) + élément (50%) |
| **Self-healing** | Implémenté | 4 stratégies actives |
| **Cascade fallbacks** | Implémenté | Circuit breaker + state machine 5 états |
| **Traces/Policies** | Implémenté | Audit JSONL rotatif, execution history, confidence scoring |
| **VDI/Citrix** | Conçu pour | Architecture vision-only compatible, tests à documenter |
### Self-Healing - 4 Stratégies
1. **Semantic Variants** - Variantes sémantiques des cibles
2. **Spatial Fallback** - Recherche éléments proches
3. **Timing Adaptation** - Ajustement des délais
4. **Format Transformation** - Transformation de formats
### Circuit Breaker - Seuils
| Condition | Action |
|-----------|--------|
| 3 échecs consécutifs | → DEGRADED |
| 10 échecs en 600s par workflow | → QUARANTINED |
| 30 échecs globaux en fenêtre | → GLOBAL_PAUSE |
| X succès consécutifs | → Reset |
### State Machine Exécution
```
RUNNING ↔ DEGRADED ↔ QUARANTINED
↕ ↕ ↕
PAUSED ROLLBACK (reset)
```
### Fichiers Clés
- `/core/execution/` - 12 fichiers (action_executor, target_resolver, error_handler, recovery_strategies)
- `/core/healing/` - 7 fichiers (healing_engine, learning_repository, 4 stratégies)
- `/core/matching/hierarchical_matcher.py` - Matching multi-niveau
- `/core/system/circuit_breaker.py` - Protection contre cascades d'erreurs
- `/core/system/auto_heal_manager.py` - Machine d'état
**Verdict : 85% validé** - La cascade fallbacks + healing + policies existe réellement.
---
## MOAT 2 : DATA / APPRENTISSAGE (Hard to Catch Up)
### Capacités Implémentées
| Capacité | État | Détails |
|----------|------|---------|
| **Cas d'écran** | Complet | 4 niveaux de stockage |
| **Learning states** | Implémenté | 4 états de progression |
| **Drift detection** | Implémenté | Création variantes automatique |
| **Corrections utilisateur** | Partiel | Stockées mais pas packagées |
| **Templates/Packs** | Basique | Statiques uniquement |
| **Corpus** | À construire | Structure prête |
### Format des Cas d'Écran (4 niveaux)
**Niveau 1 : Raw Capture (RawSession)**
```
data/sessions/YYYY-MM-DD/session_*.json
- events[] avec timestamps
- screenshots[] avec paths
- window context
```
**Niveau 2 : Perception (ScreenState)**
```
data/screen_states/YYYY-MM-DD/state_*.json
- raw_level (screenshot, capture_method)
- perception_level (embedding, detected_text, confidence)
- context_level (workflow_candidate, business_variables)
```
**Niveau 3 : Vector Index (FAISS)**
```
data/faiss_index/main.faiss + main_metadata.json
data/embeddings/YYYY-MM-DD/state_*.npy (512 dimensions)
```
**Niveau 4 : Training Dataset**
```
training_data/session_*.json
- screenshots, actions, user_corrections, success
```
### États d'Apprentissage
```
OBSERVATION → COACHING → AUTO_CANDIDATE → AUTO_CONFIRMED
↑ |
+------ (régression détectée) -------------+
```
- 5+ observations (conf > 0.90) → COACHING
- Drift detection : 3 matchs faibles → création variante
- Max 5 variantes par node
### Manques Identifiés
| Item | Impact |
|------|--------|
| Pas de "Correction Packs" | Corrections isolées par session |
| Pas d'héritage cross-workflow | Réapprentissage nécessaire |
| Pas d'export/import corrections | Difficile à partager |
### Fichiers Clés
- `/core/learning/` - 5 fichiers (learning_manager, continuous_learner, feedback_processor)
- `/core/training/` - 5 fichiers (offline_trainer, session_analyzer, training_data_collector)
- `/core/persistence/storage_manager.py` - Gestionnaire centralisé
- `/core/embedding/faiss_manager.py` - Index vectoriel
**Verdict : 60% validé** - Infrastructure OK, capitalisation cross-workflow manquante.
---
## MOAT 3 : DÉPLOIEMENT SANTÉ (Hard to Enter)
### Capacités Implémentées
| Capacité | État | Détails |
|----------|------|---------|
| **On-prem** | Ready | 100% local, pas de cloud obligatoire |
| **Sécurité** | Implémenté | IP allowlist, rate limiter, tokens, audit |
| **Traçabilité** | Implémenté | 8 types d'événements, rotation logs |
| **Encryption** | Implémenté | Sessions chiffrées |
| **Playbook DSI/RSSI** | À documenter | Pas de doc formelle |
| **Certifications** | À préparer | Pas de certifications |
### Sécurité - Détails
**Audit Log (8 types d'événements)**
- auth_success, auth_failure
- api_access
- rate_limit_exceeded
- security_violation
- permission_denied
- data_access
- admin_action
**Caractéristiques**
- Format JSONL pour parsing
- Hachage données sensibles optionnel
- Rotation auto (10MB max, 10 fichiers)
- Métadonnées : user_id, IP, endpoint, user_agent, token_hash
### Fichiers Clés
- `/core/security/audit_log.py` - Logging sécurisé
- `/core/security/api_tokens.py` - Gestion tokens
- `/core/security/ip_allowlist.py` - Whitelist IP
- `/core/security/rate_limiter.py` - Rate limiting
- `/server/storage_encrypted.py` - Encryption sessions
### Manques Identifiés
| Item | Priorité |
|------|----------|
| Documentation compliance santé | Haute |
| Playbook DSI/RSSI | Haute |
| Certifications (HDS, ISO 27001) | Moyenne |
| Tests VDI/Citrix documentés | Moyenne |
**Verdict : 50% validé** - Technique OK, documentation compliance à faire.
---
## Inventaire Fonctionnel Complet
### Composants Opérationnels
| Composant | Port | État | Fichiers |
|-----------|------|------|----------|
| Visual Workflow Builder Frontend | 3000 | Opérationnel | React 19, React Flow v12 |
| Visual Workflow Builder Backend | 5000 | Opérationnel | Flask, 24+ actions |
| Agent Chat (LLM) | 5002 | Opérationnel | Intent parsing + Ollama |
| Web Dashboard | 5004 | Opérationnel | Monitoring temps réel |
| Core Execution | - | Opérationnel | ActionExecutor, TargetResolver |
| Self-Healing Engine | - | Opérationnel | 4 stratégies |
| Analytics System | - | Opérationnel | SQLite + reporting |
### Catalogue d'Actions VWB (24+)
**vision_ui/** (14 actions)
- click_anchor, type_text, type_secret
- screenshot_evidence, wait_for_anchor
- scroll_to_anchor, focus_anchor, hotkey
- double_clic, clic_droit, glisser_deposer
- survol_element, extract_text
**navigation/** (2)
- navigate_to_url, browser_back
**data/** (2)
- telecharger_vers_dossier, extraire_tableau
**database/** (3)
- sauvegarder_donnees, charger_donnees, gestionnaire_db
**validation/** (2)
- verify_element_exists, verify_text_content
**intelligence/** (1)
- analyser_avec_ia
### Points de Friction Connus
| Item | Problème | Impact |
|------|----------|--------|
| FAISS dimension arg | Incompatibilité version | Apprentissage embeddings |
| Agent Chat exécution | Mode optionnel | Fallback simulation |
| Cross-workflow learning | Corrections isolées | Capitalisation limitée |
---
## Architecture Core (179 fichiers Python)
```
/core/
├── execution/ (12) - Exécution et robustesse
├── healing/ (7) - Self-healing et recovery
├── learning/ (5) - Apprentissage continu
├── training/ (5) - Entraînement offline
├── security/ (7) - Audit, tokens, validation
├── detection/ (5) - UI hybride OWL+OpenCV+VLM
├── embedding/ (8) - CLIP, FAISS, fusion
├── visual/ (8) - Gestion cibles visuelles
├── matching/ (2) - Matching hiérarchique
├── analytics/ (11) - Collection, engine, reporting
├── system/ (8) - Circuit breaker, auto-heal
├── monitoring/ (8) - Métriques, scheduling
├── persistence/ (1) - StorageManager centralisé
├── models/ (8) - Structures de données
└── evaluation/ (3) - Replay, simulation
```
---
## Actions Requises
### Court Terme (Semaines)
| Action | Priorité | Effort |
|--------|----------|--------|
| Documenter playbook DSI/RSSI | Haute | Faible |
| Corriger FAISS dimension error | Haute | Faible |
| Tester et documenter VDI/Citrix | Moyenne | Moyen |
### Moyen Terme (Mois)
| Action | Priorité | Effort |
|--------|----------|--------|
| Système de Correction Packs | Haute | Moyen |
| Export/Import corrections cross-workflows | Haute | Moyen |
| Documentation compliance santé | Haute | Moyen |
### Long Terme
| Action | Priorité | Effort |
|--------|----------|--------|
| Certifications santé (HDS, ISO 27001) | Variable | Élevé |
| Accumulation corpus production | Continue | - |
---
## Conclusion
**RPA Vision V3 est un moat technique solide** avec :
- Architecture vision-native défendable
- Self-healing réel avec 4 stratégies
- Infrastructure d'apprentissage complète
- Sécurité et traçabilité opérationnelles
**Pour un moat complet :**
1. Capitaliser les corrections cross-workflows (Correction Packs)
2. Documenter compliance santé (playbook DSI/RSSI)
3. Alimenter le corpus en production (vraie douve long terme)
---
## Références Techniques
### Ports par défaut
| Service | Port |
|---------|------|
| VWB Backend | 5000 |
| VWB Frontend | 3000 |
| Web Dashboard | 5004 |
| Agent Chat | 5002 |
| API Upload | 8000 |
| Ollama | 11434 |
### Commandes de démarrage
```bash
# Dashboard (avec service systemd)
sudo systemctl start rpa-dashboard
# → http://localhost:5004
# Agent Chat
./venv_v3/bin/python -m agent_chat.app
# → http://localhost:5002
# VWB
cd visual_workflow_builder/backend && ./start.sh
cd visual_workflow_builder/frontend && npm start
```
### Structure données
```
data/
├── sessions/YYYY-MM-DD/ # RawSession JSON
├── screen_states/YYYY-MM-DD/ # ScreenState JSON
├── embeddings/YYYY-MM-DD/ # NPY + métadonnées
├── faiss_index/ # Index vectoriel
├── workflows/ # Workflows JSON
├── templates/ # Templates statiques
└── analytics/ # Métriques SQLite
```

356
archive/business_docs/PITCH_INVESTISSEURS_RPA_VISION_V3.md Normal file
View File

@@ -0,0 +1,356 @@
# RPA VISION V3
## Plateforme d'Automatisation Intelligente par Vision
**Document Investisseurs - Janvier 2026**
---
## EXECUTIVE SUMMARY
**RPA Vision V3** est une plateforme d'automatisation de nouvelle génération qui révolutionne le marché RPA en remplaçant les sélecteurs fragiles par une **compréhension sémantique des interfaces** basée sur l'intelligence artificielle.
| Métrique | Valeur |
|----------|--------|
| Maturité produit | 77% (10/13 phases) |
| Performance | 500-6250x plus rapide que les standards |
| Lignes de code | 148,000+ |
| Marchés cibles | Défense, Santé, Finance, Administration |
**Proposition de valeur unique** : Automatiser ce que les concurrents ne peuvent pas - systèmes Citrix/VDI, applications legacy, environnements air-gapped.
---
## 1. LE PROBLÈME
### Les solutions RPA actuelles échouent dans 40% des cas
**Fragilité des sélecteurs** : UiPath, Automation Anywhere et Blue Prism utilisent des sélecteurs HTML/UI qui cassent dès qu'une interface change.
**Systèmes inaccessibles** :
- Environnements Citrix/VDI (30% du marché entreprise)
- Applications mainframe legacy (banques, gouvernement)
- Systèmes air-gapped (défense, santé)
**Coûts de maintenance** : 60-70% du budget RPA est consacré à la maintenance des robots existants.
**Résultat** : Les entreprises abandonnent leurs projets RPA ou limitent leur ambition.
---
## 2. NOTRE SOLUTION
### Automatisation 100% basée sur la Vision et l'IA
```
┌─────────────────────────────────────────────────────────┐
│ RPA VISION V3 │
├─────────────────────────────────────────────────────────┤
│ │
│ CAPTURE COMPRÉHENSION EXÉCUTION │
│ ─────── ───────────── ───────── │
│ Screenshots → IA Multi-Modale → Actions │
│ Événements Détection UI Self-Healing │
│ Multi-écrans Embeddings Anti-détection │
│ │
└─────────────────────────────────────────────────────────┘
```
**Ce qui nous différencie** :
| Aspect | Concurrents | RPA Vision V3 |
|--------|-------------|---------------|
| Détection UI | Sélecteurs HTML fragiles | Vision sémantique IA |
| Changement interface | Robot cassé | Adaptation automatique |
| Citrix/VDI | Non supporté | Natif |
| Self-healing | Basique/Aucun | 4 stratégies avancées |
| Apprentissage | Aucun | Continu sur 5 niveaux |
---
## 3. TECHNOLOGIE PROPRIÉTAIRE
### 3.1 Architecture Multi-Couches
```
Couche 5 │ Workflow Intelligent │ Composition & Orchestration
─────────┼─────────────────────────┼────────────────────────────
Couche 4 │ Graph d'Apprentissage │ États & Transitions
─────────┼─────────────────────────┼────────────────────────────
Couche 3 │ State Embedding │ Fusion Multi-Modale
─────────┼─────────────────────────┼────────────────────────────
Couche 2 │ Détection UI Sémantique │ VLM + Rôles + Contexte
─────────┼─────────────────────────┼────────────────────────────
Couche 1 │ Analyse d'Écran │ Screenshots + OCR
─────────┼─────────────────────────┼────────────────────────────
Couche 0 │ Capture Brute │ Événements + Images
```
### 3.2 Innovations Clés
**State Embedding Multi-Modal**
- Fusion de 4 modalités (image 50%, texte 30%, UI 10%, contexte 10%)
- Fingerprint unique ultra-robuste pour chaque état d'écran
- Performance : 0.02ms (contrainte : <100ms) = **500x plus rapide**
**Self-Healing Hybride**
- 4 stratégies en cascade : variantes sémantiques, fallback spatial, adaptation timing, transformation format
- Taux de récupération : >95% des erreurs transitoires
- Temps max : 30 secondes avec tentatives parallèles
**Apprentissage Progressif**
```
OBSERVATION → COACHING → AUTO_CANDIDATE → AUTO_CONFIRMÉ
(5+) (10+) (20+) (validé)
```
**Mode Shadow (Citrix/VDI)**
- Capture sans hooks système
- Anti-détection intégré
- Chiffrement bout-en-bout
### 3.3 Stack Technique
| Composant | Technologies |
|-----------|--------------|
| Core IA | PyTorch 2.0, OpenCLIP, FAISS, Qwen3-VL 8B |
| Vision | OpenCV, TorchVision, EasyOCR |
| Backend | Flask 3.0, FastAPI, WebSocket, Redis |
| Frontend | React 18, TypeScript, React Flow |
| Infrastructure | GPU scheduling, Load balancing, Multi-workers |
---
## 4. PERFORMANCES MESURÉES
### Benchmarks vs Standards Industrie
| Métrique | Standard | RPA Vision V3 | Avantage |
|----------|----------|---------------|----------|
| State Embedding | <100ms | 0.02ms | **500x** |
| Pipeline End-to-End | <500ms | 0.08ms | **6250x** |
| Recherche FAISS (10k) | <50ms | 0.05ms | **1000x** |
| Détection UI | <2s | <200ms | **10x** |
### Scalabilité Testée
- **1M+ embeddings** indexés dans FAISS
- **10K+ workflows** gérés simultanément
- **100+ exécutions** parallèles
- **<100ms latence** pour recherche similarité
### Optimisation Ressources
| Métrique | Amélioration |
|----------|--------------|
| Réduction mémoire (4K) | -76% |
| Cache hit rate | 30-50% |
| Temps traitement ROI | -70% |
---
## 5. MARCHÉ & OPPORTUNITÉ
### Marché RPA Global
```
2024: $13B ────────────────────────────────► 2030: $30B
CAGR 15%
```
### Notre Segment : "L'Impossible à Automatiser"
| Segment | Taille | Pourquoi nous |
|---------|--------|---------------|
| Citrix/VDI | $3.9B | Seule solution vision native |
| Legacy/Mainframe | $2.6B | Pas d'API = vision seule option |
| Air-gapped (Défense) | $1.3B | Souveraineté + sécurité |
| Santé (RGPD) | $1.8B | Conformité + systèmes complexes |
**TAM adressable** : $9.6B (segment sous-servi par UiPath/AA)
### Concurrence
| Acteur | Forces | Faiblesses vs Nous |
|--------|--------|-------------------|
| **UiPath** | Leader marché, écosystème | Sélecteurs fragiles, pas de Citrix natif |
| **Automation Anywhere** | Cloud-first | Vendor lock-in, coûts élevés |
| **Blue Prism** | Enterprise | Legacy, lent, pas d'IA avancée |
| **Microsoft Power Automate** | Intégration Office | Limité aux apps Microsoft |
**Notre avantage** : Nous capturons le marché que les géants ne peuvent pas servir.
---
## 6. CAS D'USAGE SECTORIELS
### Défense & Gouvernement
**Problème** : Systèmes classifiés sans API, environnements air-gapped, exigences de souveraineté.
**Solution RPA Vision** :
- Exécution 100% locale (pas de cloud)
- Mode Shadow pour Citrix sécurisé
- Audit trail complet pour conformité
- Chiffrement bout-en-bout
**Exemple** : Automatisation traitement renseignement - 80% réduction temps manuel
### Santé & Administration
**Problème** : Dossiers patients multi-systèmes, interfaces Citrix, conformité RGPD.
**Solution RPA Vision** :
- Compréhension formulaires complexes
- Self-healing pour zéro interruption
- Traçabilité complète actions
- Masquage automatique données sensibles
**Exemple** : Traitement dossiers allocations - 65% gain productivité
### Finance & Banque
**Problème** : Mainframes 30+ ans, réconciliation multi-systèmes, trading 24/7.
**Solution RPA Vision** :
- Vision fonctionne sur interfaces legacy
- Apprentissage des variations écrans
- Replay simulation pour audit
- Haute disponibilité
**Exemple** : Réconciliation trades - 40% réduction erreurs
### Industrie & Logistique
**Problème** : ERP variés (SAP, Oracle), temps réel, intégration IoT.
**Solution RPA Vision** :
- Multi-système natif
- Performance temps réel (<100ms)
- Roadmap IoT intégrée
**Exemple** : Gestion inventaire - 50% réduction temps cycles
---
## 7. MODÈLE ÉCONOMIQUE
### Stratégie de Pricing
| Tier | Cible | Modèle | Prix indicatif |
|------|-------|--------|----------------|
| **Starter** | PME | Par workflow | €500/mois |
| **Enterprise** | Grands comptes | Licence site | €50K-200K/an |
| **Sovereign** | Défense/Gouv | Licence perpétuelle | €500K-2M |
| **OEM** | Éditeurs logiciels | Revenue share | 15-25% |
### Avantage Coût vs Concurrence
| Poste | UiPath | RPA Vision V3 | Économie |
|-------|--------|---------------|----------|
| Licence/robot | €8K/an | €3K/an | -62% |
| Maintenance | 60% budget | 20% budget | -67% |
| Infrastructure | Cloud obligatoire | On-premise possible | -40% |
| **TCO 3 ans** | €100K | €35K | **-65%** |
### Projections Financières (Conservative)
| Année | ARR | Clients | Notes |
|-------|-----|---------|-------|
| Y1 | €500K | 5-10 | Pilots Enterprise |
| Y2 | €2M | 25-30 | Expansion secteurs |
| Y3 | €8M | 80-100 | Scale-up commercial |
| Y5 | €50M | 500+ | Marketplace + OEM |
---
## 8. ÉQUIPE & EXÉCUTION
### Compétences Clés
- **IA/ML** : Expertise PyTorch, Vision par ordinateur, VLM
- **RPA** : Connaissance profonde automatisation entreprise
- **Sécurité** : Chiffrement, conformité, audit
- **Produit** : UX/UI, React, design workflows
### Roadmap Produit
| Phase | Statut | Contenu |
|-------|--------|---------|
| 1-2 | ✅ 100% | Fondations + Embeddings FAISS |
| 4-6 | ✅ 100% | Détection UI + Workflows + Exécution |
| 7-8 | ✅ 100% | Learning System + Training |
| 10-12 | ✅ 100% | GPU + Performance + Monitoring |
| 3,9,13 | 🔄 70% | Tests + VWB Final + Documentation |
**Time to Market** :
- MVP fonctionnel : **Disponible**
- Production-ready : **Q1 2026**
- Enterprise features : **Q2 2026**
---
## 9. INVESTISSEMENT RECHERCHÉ
### Utilisation des Fonds
| Poste | Allocation | Objectif |
|-------|------------|----------|
| R&D | 50% | Finalisation produit, IA propriétaire |
| Commercial | 30% | Équipe vente, partenariats |
| Infrastructure | 15% | Cloud, sécurité, compliance |
| Juridique/IP | 5% | Brevets, certifications |
### Milestones
| Horizon | Objectif | KPI |
|---------|----------|-----|
| 6 mois | Produit GA | 3 clients production |
| 12 mois | Market fit | €1M ARR, NPS >50 |
| 24 mois | Scale | €5M ARR, 50 clients |
| 36 mois | Leadership | €15M ARR, présence EU |
---
## 10. POURQUOI MAINTENANT
### Convergence de Facteurs Favorables
1. **Maturité IA** : VLM (Vision-Language Models) atteignent le niveau requis
2. **Échec RPA traditionnel** : 40% des projets abandonnés = marché frustré
3. **Transformation digitale** : Accélération post-COVID
4. **Souveraineté** : Demande croissante solutions européennes
5. **Coûts main d'œuvre** : Pression sur l'automatisation
### Timing Compétitif
- UiPath/AA n'ont pas la technologie Vision native
- 2-3 ans d'avance technologique
- Fenêtre pour établir la marque avant réaction des géants
---
## SYNTHÈSE
**RPA Vision V3** représente une **opportunité d'investissement unique** dans le marché RPA de $30B :
| Force | Détail |
|-------|--------|
| **Technologie** | 500-6250x plus performant, innovations brevetables |
| **Marché** | $9.6B segment sous-servi par les leaders |
| **Timing** | 2-3 ans d'avance, maturité IA atteinte |
| **Équipe** | Expertise IA + RPA + Sécurité |
| **Produit** | 77% complet, production-ready Q1 2026 |
**L'automatisation intelligente par vision est l'avenir du RPA.**
---
## CONTACT
Pour plus d'informations, démonstration produit ou discussion investissement :
**[Coordonnées à compléter]**
---
*Document confidentiel - Janvier 2026*

695
archive/historical_recall/recall_2026-05-08.md Normal file
View File

@@ -0,0 +1,695 @@
Bonjour ! Aujourd'hui, nous devons réaliser la démo de bout en bout et sans accros. Il nous faut être précis pour ne pas avoir à refaire constamment le workflow, c'est long et
chronophaque. Il faut penser que l'on doit pouvoir "communiquer" avec Léa pour lui demander de faire le travail. Par exemple, traite moi les 3 premiers dossier (dans vwb on a un
outil de lescture de tableau ?). Il faut donc qu'elle soit capable de lire le tableau correctement et faire le traitement propre au fur et à mesure. On peut aussi, si c'est
nécessaire modifier l'interface de la maquette pour plus de simplicité. Pour finir, est ce que l'utilisation de vwb est suffisament solide pour faire l'exercice plutôt que
d'utiliser le mode d'apprentissage de lea ? Ne code rien, on discute.
● Bonjour. Avant de raisonner architecture, j'ai besoin de clarifier 3 choses :
Questions de cadrage
1. Quand exactement la démo ? La semaine est entamée — on parle de mardi-mercredi-jeudi ? Combien d'heures de prep on a réellement avant ?
2. Scénario souhaité : tu te projettes en quoi devant la DSI Carvella ?
- "Je dis à Léa : traite les 3 premiers dossiers. Léa lit le tableau, choisit, fait, rapporte" — pur pilotage vocal/chat
- Ou : "Je clique le bouton Léa qui lance le workflow A pour le dossier sélectionné" — démo de l'automatisation, pilotage visuel
- Ou les deux à des moments différents
3. Métier vs tech : Carvella vient en adversaire technique (RPA classique). Tu veux qu'il soit bluffé sur l'INTELLIGENCE de Léa (compréhension naturelle, lecture de tableau,
généralisation) ou sur la PROFONDEUR métier (preuves cliniques citées, gain ROI 100k€/mois) ? Les deux mais quel curseur ?
Maintenant mes réponses sur tes 4 points :
Outil de lecture de tableau dans VWB
À ma connaissance non, pas d'action spécifique extract_table. Ce qui existe :
- extract_text (OCR sur une zone) → renvoie du texte plat, pas une structure
- Import Excel via /api/v3/excel/upload (vu hier dans le code) — mais c'est pour DÉPOSER un Excel, pas lire un tableau à l'écran
- Les learned_workflows qui ont une notion de "boucle données → UI" (vu un commit 9da804bb6 feat: import Excel → SQLite + boucle données → UI dans le VWB)
→ Il faudrait que je vérifie learned_workflows.py et la logique de boucle pour voir si ça peut servir. Mais à ce jour, pour lire le tableau de patients à l'écran et boucler dessus,
il y a un trou. C'est probablement à construire ou à contourner.
VWB vs apprentissage Léa pour la démo
┌───────────────────────────────────────────┬───────────────────────────────────┬──────────────────────────────────┐
│ Critère │ Workflow VWB │ Apprentissage Léa │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Déterminisme (rejouable, pas de surprise) │ ✅ │ ⚠️ moins prévisible │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Robustesse aux variations UI │ ❌ (cf. nos 8h d'hier) │ ✅ │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Vitesse de mise au point │ Long, fragile (re-enregistrement) │ Court (Léa s'adapte) │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Crédibilité démo "IA vraie" │ ⚠️ (RPA classique +) │ ✅ (ce qui te démarque d'Evanov) │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Risque le jour J │ Modéré (si répété) │ Plus élevé (moins testé) │
├───────────────────────────────────────────┼───────────────────────────────────┼──────────────────────────────────┤
│ Prêt aujourd'hui │ Presque (re-enregistrement) │ Probablement pas │
└───────────────────────────────────────────┴───────────────────────────────────┴──────────────────────────────────┘
Mon avis honnête : pour la démo qui arrive cette semaine, workflow VWB pour le squelette + intelligence Léa pour la partie qui démarque est le bon mix.
Concrètement :
- Léa lit le tableau patients (étape "intelligente" qu'on met en avant)
- Léa choisit les N premiers (capacité de compréhension)
- Pour chaque patient, Léa lance le workflow VWB Urgence (mécanique fiable)
- Léa rapporte au humain (l'analyse PMSI, les preuves citées)
L'enveloppe est intelligente. Le moteur dedans est du VWB solide. C'est ce qui te démarque tout en étant fiable.
Communication avec Léa pour le scénario "traite les 3 premiers"
Architecturalement, ça implique :
1. Un endpoint chat Léa (déjà : rpa-agent-chat port 5004) qui reçoit "traite les 3 premiers dossiers"
2. Un NLP léger côté Léa qui interprète : action=process_patients, nombre=3, ordre=top
3. Une lecture du tableau : OCR de la zone tableau + parsing par lignes (le tableau est régulier : IPP | Nom | Prénom | … donc parser les colonnes par espaces multiples)
4. Une boucle : pour chaque IPP des 3 premiers, lancer le workflow Urgence avec ce dossier en paramètre (ce qui implique de variabiliser le by_text="{{patient_id}}")
5. Un retour utilisateur : "Dossier 25003284 codé en FORFAIT_URGENCE — Dossier 25003362 codé en FORFAIT — Dossier 25003364 codé en UHCD avec ces preuves : …"
L'élément manquant central : paramétrisation du workflow par variable d'entrée + mécanisme de boucle.
Modifier la maquette ? Oui mais avec discernement
Modifier pour SIMPLIFIER (rendre les anchors plus stables) = OK. Exemples acceptables :
- Compacter les 3 textareas pour tenir dans le viewport sans scroll
- Ajouter des bordures contrastées sur les zones cibles (template matching plus robuste)
- Mettre un placeholder unique dans chaque textarea (texte distinctif que template matching reconnaît)
Modifier pour TRICHER (afficher déjà la décision UHCD avant que Léa ait analysé) = NON, ça tue la crédibilité.
Question de précision et non-régression
C'est ton vrai point critique. Je propose qu'on :
1. Fige une procédure d'enregistrement documentée (config Chrome précise, étapes, validation)
2. Capture une fois proprement, et après on n'y touche plus
3. Crée un script de test E2E qui valide en 30 secondes que le workflow marche encore (à lancer avant chaque session, et avant la démo)
---
Bref, ma recommandation pour aujourd'hui : on construit dans cet ordre :
1. Discussion : tu réponds à mes 3 questions de cadrage → on aligne sur le scénario démo
2. Variabilisation du workflow Urgence : by_text="{{patient_id}}" + extension templating
3. Mécanisme Léa lit tableau + boucle sur N patients (enveloppe intelligente autour du workflow VWB)
4. Re-enregistrement précis des anchors dans config bureau standard
5. Procédure documentée + script de test E2E
Mais avant tout, je veux entendre tes réponses aux 3 questions de cadrage. Ça change radicalement l'angle.
✻ Cogitated for 1m 24s
❯ [Image #2] Il y a bien dans vwb un extracteur de tableau. La démo dans 4 jours. Je n'ai pas compris ta question : "Scénario souhaité : tu te projettes en quoi devant la DSI Carvella
?" Pour le 3) je dirais les deux. Pas simplement pour kervella, mais aussi pour les dim/tim/dg. Si je suis assez confiant sur la partie workflow, c'est surtout la partie analyse du
dossier qui m"interroge ?
⎿  [Image #2]
● OK, message reçu. L'enjeu majeur c'est la qualité de l'analyse, pas la mécanique. C'est exactement le point qui démarque Léa d'un RPA classique : un workflow qui clique, c'est
UiPath. Une Léa qui raisonne juste sur du texte clinique, c'est ton offre.
Reformulation de ma question scénario
Concrètement, ce que tes 4 minutes devant les DG vont ressembler. Je veux comprendre le déroulé pour caler le bon niveau de polish à chaque étape :
- Minute 0 : tu ouvres l'écran, qu'est-ce qui est affiché ? (Easily avec liste de 11 dossiers ? Chat Léa ? Les deux côte à côte ?)
- Minute 1 : tu dis quoi à voix / en chat à Léa ? Et qu'est-ce que Carvella+DG voient se passer à l'écran ?
- Minute 2-3 : Léa analyse et code 1 ou 3 dossiers. Que regardent-ils ? La maquette qui se remplit ? Léa qui parle ? Un dashboard qui synthétise ?
- Minute 4 : Léa rapporte le résultat. Sous quelle forme ? "J'ai codé 3 dossiers : 2 forfaits, 1 UHCD. Voici les preuves de l'UHCD : …". Vocal ? Texte ? Dashboard ?
Tu n'es pas obligé d'avoir une réponse précise — c'est ce qu'on doit décider ensemble. Mais c'est ce que je voulais dire par "scénario souhaité".
Sur ton inquiétude (l'analyse) — c'est le vrai sujet
Je propose un plan de durcissement de l'analyse LLM en 3 axes :
A. Bench complet sur tes 11 dossiers
- Lancer t2a_decision sur les 11 dossiers anonymisés (les 4 UHCD + les 4 forfaits + les 3 PE2/SU2/SU2)
- Vérifier la décision (vrai positif / vrai négatif)
- Vérifier la qualité des preuves (citations littérales vraiment du dossier ? pertinentes ? pas inventées ?)
- Vérifier la confiance (le LLM dit "elevee" quand il devrait dire "moyenne" ?)
- Tableau de scores : accuracy + qualité preuves + temps + VRAM
B. Comparer 2-3 modèles
On a déjà bench medgemma:4b (docs/BENCH_MEDGEMMA.md) et qwen2.5:7b. À tester aussi peut-être gemma3:12b pour voir la marge. Choix final selon : qualité, vitesse, VRAM, robustesse.
C. Renforcer le prompt si besoin
Selon le bench, on peut ajouter :
- Des exemples few-shot (1 exemple UHCD, 1 forfait, copiés en début de prompt)
- Une étape de raisonnement explicite ("Avant de décider, liste les 3 critères et pour chacun cite une preuve")
- Un garde-fou : si confiance="faible", Léa demande à l'humain au lieu de coder
Cela rend l'analyse défendable devant Carvella : tu peux dire "Léa cite le dossier mot pour mot, et quand elle doute, elle nous le dit."
Pour les 4 jours, je propose ce découpage
┌───────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Jour │ Focus │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Aujourd'hui (J-4) │ Cadrage scénario démo + bench analyse LLM sur 11 dossiers + identification des cas problématiques │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ J-3 │ Si bench OK : variabilisation workflow + Extraire tableau + boucle Léa. Si bench KO : amélioration prompt et/ou modèle │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ J-2 │ Re-enregistrement workflow propre + intégration mécanisme "Léa lit tableau et traite N dossiers" │
├───────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ J-1 │ Test E2E répété 5-10 fois sur scénario démo. Tweaks finaux. Préparation slides │
└───────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Ce que je propose maintenant (avant de coder)
1. Tu réponds aux questions scénario ci-dessus (ça cadre tout le reste)
2. Je vais voir le code de "Extraire tableau" pour comprendre ses capacités exactes (lecture seule, on discute ensuite)
3. Je propose un script de bench des 11 dossiers (qui ne touche pas le code prod, juste pour mesurer)
OK ?
✻ Crunched for 58s
❯ Alors, pour demarrer, chat lea. Je lui demande de traiter 3 dossiers.Elle se réduit (si ça doit être possible) Elle ouvre chrome, tape l'adresse de la maquette, elle lit le
tableau. Elle traite aprés dossier par dossier. A la fin, elle dis que c'est fini ! Tu en penses quoi ? Est ce que c'est complexe, ça demande beaucoup de changement ?
● Ce que tu décris est clair et faisable en 4 jours. Pas de révolution — on a les briques. Il faut surtout assembler et variabiliser.
Décomposition technique du scénario
┌────────────────────────────────────────┬─────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────┐
│ Étape │ Brique nécessaire │ Existe ? │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Chat Léa reçoit "traite 3 dossiers" │ NLP léger (regex ou mini-LLM) côté chat │ ⚠️ partiel — chat existe, NLP commande à coder │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Léa se réduit │ iconify() Tkinter ou raccourci Win+D │ 🟢 trivial │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Léa ouvre Chrome + tape URL │ Action launch_app ou raccourci Win + Chrome déjà ouvert │ ⚠️ à brancher │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Léa lit le tableau │ "Extraire tableau" VWB │ 🟢 existe (bouton vu) — à vérifier ce qu'il rend │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Léa boucle sur 3 IPP │ Mécanisme boucle workflow + variable {{patient_id}} │ ⚠️ "boucle données→UI" existe partiellement (commit 9da804bb6) — à confirmer │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Pour chaque dossier : workflow Urgence │ Workflow existant variabilisé │ ✏️ workflow OK, juste variabiliser le step 2 │
├────────────────────────────────────────┼─────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Léa dit "c'est fini + synthèse" │ Réponse chat + récap des décisions │ ⚠️ à coder simple │
└────────────────────────────────────────┴─────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────┘
Évaluation honnête
Pas complexe au sens "casse-tête". C'est de la plomberie d'assemblage :
- 4-5 modifs de code structurelles, chacune ~30 min à 2h
- 1 re-enregistrement de workflow (30 min si bien préparé)
- 1 jour de test E2E qu'il faut absolument répéter 10× pour la fiabilité
Le risque majeur : c'est qu'on découvre en cours de route que "Extraire tableau" ne renvoie pas ce qu'on espère, ou que le mécanisme de boucle VWB n'est pas mature, et qu'on doive
coder du contournement. Je propose qu'on fasse les 2 vérifications en premier (1h grand max).
Découpage 4 jours proposé
┌──────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────┐
│ Jour │ Focus │ Livrable │
├──────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ J-4 │ (1) Vérifier capacités "Extraire tableau" et boucle VWB. (2) Bench analyse LLM sur les 11 dossiers. (3) Cadrage │ Verdict bench LLM + go/no-go boucle VWB │
│ (aujourd'hui) │ final scénario │ │
├──────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ J-3 │ (1) Variabilisation workflow + extension templating. (2) NLP commande chat Léa. (3) Action minimiser + ouvrir │ Léa peut traiter 1 dossier sur commande │
│ │ Chrome │ chat │
├──────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ J-2 │ (1) Re-enregistrement workflow propre. (2) Intégration boucle (Léa traite N dossiers). (3) Synthèse fin │ Démo end-to-end fonctionne au moins 1 │
│ │ │ fois │
├──────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ J-1 │ Test E2E répété 5-10 fois. Polish. Procédure documentée. │ Démo robuste, reproductible │
└──────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────┘
Liste précise des changements (cumul sur 4 jours)
1. Variabiliser by_text du step "sélection patient" : 30 min
2. Étendre templating {{var}} au by_text et autres champs (aujourd'hui c'est sur text uniquement) : 1h
3. NLP commande chat Léa : regex simple "traite (\d+) dossiers?" + dispatch action : 2h
4. Action launch_url ou utilisation du Chrome déjà ouvert (selon préférence) : 30 min
5. Mécanisme boucle : à valider (peut-être 0, peut-être 4h)
6. Re-enregistrement workflow Urgence + test : 1h-2h
7. Synthèse fin de boucle envoyée au chat : 1h
8. Procédure et tests E2E : 1 journée
Total 1.5-2 jours de dev pur, 1 jour de re-enregistrement+test, 1 jour de polish/répétition. Confortable sur 4 jours.
Question pour décider maintenant
Avant que je vérifie quoi que ce soit, 2 décisions à prendre :
A. Sur "Léa ouvre Chrome + tape URL" : c'est un détail théâtral (ça impressionne) mais ça ajoute 1 step potentiellement fragile. Alternative : Chrome est déjà ouvert sur la maquette
quand la démo commence, et Léa enchaîne directement la lecture du tableau. Tu préfères ?
B. Sur "Léa se réduit" : tu veux qu'elle disparaisse de l'écran pendant le travail (ça augmente le côté "elle bosse toute seule"), ou qu'elle reste visible en petite popup (côté "je
vois ce qu'elle fait") ? Les deux marchent.
Une fois ces 2 réponses, je vais voir le code "Extraire tableau" et "boucle VWB" — et reviens avec un verdict en 30 min.
✻ Cooked for 1m 7s
❯ Pour le A j'ai déjà fait avec vwb sous linux, ça fonctionne bien et c'est rapide. Sous windows pas testé. Donc, on part sans que chrome soit ouvert. Oui, pendant la démo, léa se
réduit completement.
● OK, je vais voir les 4 capacités existantes en mode read-only et reviens avec un verdict.
Searched for 11 patterns, read 1 file (ctrl+o to expand)
● Voici mon verdict après vérification :
Bilan des briques existantes
┌───────────────────────────────────┬─────────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────┐
│ Brique │ État │ Verdict │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Action extract_table │ 🟡 Bouton frontend OK avec params │ Backend NON implémenté — coquille vide actuellement │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Mécanisme boucle db_foreach │ ✅ Codé dans dag_execute.py:274 │ Mais côté backend VWB Flask (Linux), pas côté serveur replay (PC Windows) │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Templating ${current_row.col} │ ✅ Existe pour db_foreach │ Réutilisable │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Templating {{var}} │ ⚠️ Existe mais uniquement sur le champ text │ À étendre au by_text │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Action launch_url / ouvrir Chrome │ ❌ Pas trouvée │ À coder ou contourner │
├───────────────────────────────────┼─────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────┤
│ Minimiser Léa Tkinter │ ✅ iconify() existe │ Trivial │
└───────────────────────────────────┴─────────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────┘
Ce qu'il faut construire pour ton scénario
┌─────┬─────────────────────────────────────────────────────────────────────────────────┬─────────────┐
│ # │ Brique │ Coût estimé │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 1 │ extract_table côté serveur replay (OCR + parsing par lignes) │ 3-4h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 2 │ Mécanisme boucle côté replay OU orchestration Python depuis chat Léa │ 3-4h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 3 │ Action launch_chrome_url pour PC Windows (subprocess.Popen Chrome.exe avec URL) │ 1h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 4 │ Étendre templating {{var}} au by_text du click_anchor │ 30 min │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 5 │ Variabiliser le step 2 du workflow Urgence │ 30 min │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 6 │ NLP commande chat ("traite N dossiers" → action structurée) │ 1-2h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 7 │ Action minimiser Léa │ 30 min │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 8 │ Synthèse fin de boucle envoyée au chat │ 1h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 9 │ Re-enregistrement workflow Urgence dans config bureau │ 1h │
├─────┼─────────────────────────────────────────────────────────────────────────────────┼─────────────┤
│ 10 │ Tests E2E répétés │ 1 jour │
└─────┴─────────────────────────────────────────────────────────────────────────────────┴─────────────┘
Total : ~2 jours de dev + 1 jour re-enregistrement + 1 jour de polish. Tient en 4 jours, mais sans marge pour les surprises.
Le seul vrai point d'incertitude
extract_table n'a pas d'implémentation serveur. Il faut la construire. C'est faisable proprement (EasyOCR + parsing par espaces multiples sur les colonnes IPP/Nom/Prénom) mais c'est
de l'OCR de tableau qui peut avoir des erreurs (caractères mal lus, alignement colonnes). À tester sur ta maquette pour mesurer la précision.
Plan de mitigation si OCR fragile : la maquette urgence.labs.laurinebazin.design est statique HTML — j'ai vu hier que le <table> est accessible via fetch GET. Si l'OCR rate, on peut
récupérer la liste IPP via une simple requête HTTP côté serveur (ce qui n'est pas "tricherie" puisque c'est UNE source de vérité du tableau, juste plus fiable que l'OCR). À garder en
filet de sécurité.
Décision à prendre maintenant
Option A — On code extract_table côté replay (vraie vision) : aligné feedback_100pct_visual, démontrable comme capacité visuelle de Léa. Risque OCR.
Option B — Léa lit la liste via fetch HTTP de la maquette : robuste, plus rapide à coder, mais on perd le côté "Léa lit visuellement le tableau" qui est un argument fort vs RPA
classique.
Option C — Hybride : on code extract_table (option A), si l'OCR rate > X%, on bascule auto sur fetch HTTP. Robuste ET visuel.
Pour la démo qui doit faire effet, C est probablement le bon choix. Mais c'est plus de boulot.
Mon recommandation : A pour démarrer (~3-4h), test rapide, si OCR donne > 90% de précision sur les 11 lignes c'est gagné. Sinon on bascule B avant la fin de la journée.
Tu valides A en premier essai ?
Et pour le chat Léa, tu confirmes que c'est bien rpa-agent-chat (port 5004) qu'on utilise, ou un autre bout d'interface ?
✻ Baked for 2m 50s
❯ Ok, il faut que tu me dise pour simplifier l'arbre décisionnel pour moins de "mouvement". On pourrait avoir 1 seul champs texte dans lequel on décompose l'arbre ?
● Très bonne idée, et je la pousserais même un cran plus loin. Voici ma proposition :
Maquette simplifiée — passer de 6 anchors à 2
Avant (actuel)
- 3 textareas séparées (preuve_critere1/2/3)
- 3 checkboxes (validation par critère)
- → 6 anchors visuels à enregistrer + 5 actions à mécaniquer
Après (proposition)
- 1 grande textarea "Analyse PMSI" avec un texte structuré multi-sections
- 1 sélecteur unique de décision : 2 boutons radio [ ] UHCD [ ] Forfait
- → 2 anchors visuels + 2 actions
Format texte unique structuré (rendu par le LLM)
══════════════════════════════════════════
DÉCISION : REQUALIFICATION_HOSPITALISATION (UHCD)
Durée passage : 14h | Confiance : élevée
CRITÈRE 1 — Pathologie potentiellement évolutive : ✓ VALIDÉ
« Asthme sévère avec FC 110 bpm, SpO2 92% en air ambiant »
Patient instable nécessitant titration salbutamol IV.
CRITÈRE 2 — Surveillance médicale prolongée : ✓ VALIDÉ
« Constantes itératives H+0, H+2, H+4, H+6 »
6h de surveillance documentée par IDE.
CRITÈRE 3 — Examens / actes : ✗ NON VALIDÉ
Aucun acte technique au compte-rendu hors aérosols.
JUSTIFICATION
2/3 critères validés → REQUALIFICATION HOSPITALISATION justifiée.
══════════════════════════════════════════
Ce qu'on gagne
1. Robustesse démo : 2 anchors au lieu de 6 → 3× moins de risques de panne
2. Re-enregistrement rapide : ~10 min au lieu de 30
3. Workflow plus court : ~20 actions au lieu de 25 (et surtout plus fiable)
4. LLM plus simple : 1 sortie narrative + 1 décision booléenne au lieu de 9 champs (3 preuves + 3 booléens + 3 méta)
5. Plus lisible pour DG/DIM : un rapport structuré qu'ils peuvent lire et défendre, pas du remplissage de formulaire
6. Plus rapide visuellement : 1 frappe + 1 clic au lieu de 3 frappes + 3 clics
Ce qu'on perd
1. Distinction "case cochée par critère" : le côté formel "Léa coche chaque case" parle au métier mais c'est aussi un peu bureaucratique. Le rapport unique structuré est plus
Ce qu'on gagne
1. Robustesse démo : 2 anchors au lieu de 6 → 3× moins de risques de panne
2. Re-enregistrement rapide : ~10 min au lieu de 30
3. Workflow plus court : ~20 actions au lieu de 25 (et surtout plus fiable)
4. LLM plus simple : 1 sortie narrative + 1 décision booléenne au lieu de 9 champs (3 preuves + 3 booléens + 3 méta)
5. Plus lisible pour DG/DIM : un rapport structuré qu'ils peuvent lire et défendre, pas du remplissage de formulaire
6. Plus rapide visuellement : 1 frappe + 1 clic au lieu de 3 frappes + 3 clics
Ce qu'on perd
1. Distinction "case cochée par critère" : le côté formel "Léa coche chaque case" parle au métier mais c'est aussi un peu bureaucratique. Le rapport unique structuré est plus consultatif.
2. Rigueur formelle PMSI : si Easily Assure final exige 3 champs séparés, la maquette diverge — mais c'est un MOCKUP de démo, pas l'outil cible. À argumenter aux DG : "en intégration prod,
on remplit les 3 champs métier".
Ma recommandation : encore mieux ?
Pour pousser le côté "Léa raisonne et propose" :
Format affiché en deux parties dans la maquette simplifiée :
1. Bloc gauche (auto par Léa) : la grande textarea avec le rapport structuré
2. Bloc droit (validation médecin) : les 2 boutons radio UHCD/Forfait
Léa remplit le bloc gauche (analyse) et coche le bloc droit (décision). Le médecin DIM valide ou corrige. C'est un message démo très fort : "Léa propose, le médecin reste maître". Cela
parle aux DG (gain de temps) et au DIM (contrôle métier).
Décisions à prendre consultatif.
2. Rigueur formelle PMSI : si Easily Assure final exige 3 champs séparés, la maquette diverge — mais c'est un MOCKUP de démo, pas l'outil cible. À argumenter aux DG : "en intégration
prod, on remplit les 3 champs métier".
Ma recommandation : encore mieux ?
Pour pousser le côté "Léa raisonne et propose" :
Format affiché en deux parties dans la maquette simplifiée :
1. Bloc gauche (auto par Léa) : la grande textarea avec le rapport structuré
2. Bloc droit (validation médecin) : les 2 boutons radio UHCD/Forfait
Léa remplit le bloc gauche (analyse) et coche le bloc droit (décision). Le médecin DIM valide ou corrige. C'est un message démo très fort : "Léa propose, le médecin reste maître".
Cela parle aux DG (gain de temps) et au DIM (contrôle métier).
Décisions à prendre
1. Tu valides la simplification maquette → 1 grande textarea + 2 radio UHCD/Forfait ?
2. Tu modifies la maquette toi-même (HTML statique) ou je te propose un patch que tu appliques ?
3. Le format texte structuré que j'ai donné en exemple te convient (ASCII frame, sections claires, citations entre « ») ou tu veux autre chose (JSON pretty-print, markdown, tableau)
?
Une fois ça calé, je peux mettre à jour le prompt LLM en conséquence (réécrire t2a_decision.py pour produire 1 rapport narratif + 1 décision au lieu de 9 champs). Et toi tu
modifies/me confirmes la maquette → on capture seulement 2 anchors et le workflow devient ultra-stable.
✻ Crunched for 57s
※ recap: Objectif : démo Léa "traite N dossiers" jeudi/vendredi en bouclant sur le tableau patients. Tâche actuelle : valider la simplification maquette (1 grande textarea + 2 radios
UHCD/Forfait) au lieu de 3 textareas + 3 cases. Prochaine action : ton go/no-go sur cette simplification.
❯ Pour la simplification de l'interface sur l'arbre de décision et ce ça t'irait ou trop complexe : [Image #3]
⎿  [Image #3]
● OUI excellente idée — cette interface est BEAUCOUP plus forte que ce que je proposais. Et techniquement elle simplifie radicalement la chaîne.
Ce que ça change positivement
┌───────────────────────────────┬───────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────┐
│ Aspect │ Avant (3 textareas + 3 checkboxes Easily) │ Après (aiva-vision) │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Anchors visuels à enregistrer │ 6 fragiles │ 2 robustes (textarea DPI + bouton Analyser) │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Actions de saisie │ 3 type_text + 3 click conditionnels │ 1 type_text + 1 click │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Risque de drift UI │ Élevé (formulaire formel) │ Faible (interface stable, contraste fort) │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Démontrabilité │ "Léa coche des cases" (RPA classique++) │ "Léa lit, analyse, propose une décision" (différenciation forte vs Evanov) │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Lisibilité pour DG/DIM │ Formulaire administratif │ Synthèse intelligente avec justification + critères + confiance + latence │
├───────────────────────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────┤
│ Crédibilité métier │ "C'est juste de la saisie" │ "C'est une vraie analyse motivée" │
└───────────────────────────────┴───────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────┘
Et plus subtil — le bandeau "Vérité-terrain"
Vérité-terrain : FORFAIT_URGENCE — concordance OK
→ ÇA, c'est génial pour la démo. Carvella va te demander "comment je sais que Léa ne se trompe pas ?". Tu pointes : "On a une vérité-terrain par dossier, on mesure la concordance.
Sur les 11 dossiers qu'on a benchés, on est à X% d'accuracy".
C'est l'argument anti-FUD parfait.
Le scénario démo redessiné
Minute 0 : Dom dans le chat Léa
« Léa, traite-moi 3 dossiers urgences »
Minute 0:10 : Léa se réduit. Chrome s'ouvre sur Easily Assure.
Minute 0:30 : Léa lit le tableau patients (extract_table)
et énumère : « 25003284, 25003362, 25003364 »
Minute 1 : pour chaque dossier :
- Ouvrir le dossier (click)
- Naviguer onglets, lire (extract_text × 6)
- Bascule sur aiva-vision
- Coller le DPI consolidé (1 type_text)
- Cliquer "Analyser" (1 click)
- Aiva affiche la décision en 3s
- Léa capture (screenshot d'évidence) + note la décision
Minute 4 : retour au chat Léa
« Terminé.
- Dossier 25003284 (MOREL, asthme) : FORFAIT URGENCES — confiance élevée
- Dossier 25003362 (LAFFONT, intoxication) : FORFAIT URGENCES — confiance moyenne
- Dossier 25003364 (LEROY, dyspnée) : REQUALIFICATION HOSPITALISATION (UHCD)
→ valorisation +1500€ (forfait 50€ → MCO 1k-5k€) »
C'est propre, démontrable, court, et surtout chaque action est fiable (interface aiva-vision stable).
Mes questions pour finaliser
1. Cette interface aiva-vision est-elle déjà déployée et accessible depuis le PC Windows ? Quelle URL ?
2. Le bouton "Analyser" déclenche le même backend t2a_decision.py côté serveur ou un autre endpoint ?
3. Le DPI à coller : tu attends quel format ? (concaténation brute des t0+t1+t2+t3+t5+t6 que les extract_text produisent ?)
4. Vérité-terrain : d'où vient-elle ? Stockée par dossier dans la maquette Easily ? Ou en base à part ?
5. Question d'orchestration : après l'analyse aiva, on revient sur Easily pour saisir la décision (geste "Léa boucle la boucle" administrativement) ou on reste sur aiva (Léa propose,
le médecin DIM saisira manuellement après) ? Les deux marchent, c'est un choix de narration.
Et la simplification qui découle
Avec cette interface, je peux supprimer de mon plan :
- ❌ Re-enregistrer 6 anchors → seulement 2 désormais (gain : 30 min vs 1h)
- ❌ Étendre templating au by_text (plus crucial puisque l'analyse se fait ailleurs)
- ❌ La complexité "3 cases conditionnelles"
Ce qui reste à faire (revu à la baisse) :
┌─────┬─────────────────────────────────────────────────────────────────┬─────────────────────────┐
│ # │ Brique │ Coût │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 1 │ extract_table côté serveur replay (OCR + parsing) │ 3-4h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 2 │ Boucle sur N IPP (orchestration Python OU mécanisme replay) │ 3h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 3 │ Action launch_chrome_url pour PC Windows │ 1h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 4 │ Variabiliser le step "sélection patient" │ 30 min │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 5 │ NLP commande chat "traite N dossiers" │ 1-2h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 6 │ Action minimiser Léa │ 30 min │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 7 │ Workflow "lecture aiva-vision après analyse" (capture décision) │ 1h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 8 │ Synthèse fin de boucle vers chat │ 1h │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 9 │ Re-enregistrement workflow Urgence simplifié │ 30 min (au lieu de 1h+) │
├─────┼─────────────────────────────────────────────────────────────────┼─────────────────────────┤
│ 10 │ Tests E2E │ 1 jour │
└─────┴─────────────────────────────────────────────────────────────────┴─────────────────────────┘
Total : ~1.5 jours de dev + 0.5 jour re-enregistrement + 1 jour test. 2 jours de marge sur les 4 pour les imprévus. Bien plus confortable.
OK pour partir là-dessus ? Réponds aux 5 questions et je peux commencer dès que tu valides.
✻ Baked for 1m 14s
❯ Ok, pour moi ! De mon coté, je m'ocuppe de reprendre l'interface. Question, pourquoi un nlp sur léa ? ça ne risque pas d'alourdir et ralentir le traitement ?
● Excellente question. Tu as raison de challenger.
"NLP" est un mot un peu fort pour ce qu'on a vraiment besoin
Pour interpréter « Léa, traite-moi 3 dossiers », on a 3 niveaux de complexité possibles :
┌──────────────────────────────────────────────┬───────────────────────────────┬───────────────────────────────────────────────────────────────┬─────────────────────────────────┐
│ Approche │ Coût │ Robustesse phrasing │ Effet démo │
├──────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────────────────────────────────────────┼─────────────────────────────────┤
│ A. Regex simple │ 0 ms, 0 GPU │ Comprend les variations clés (traite N, code N dossiers, │ Suffisant si Dom dit la phrase │
│ │ │ etc.) si on les anticipe │ prévue │
├──────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────────────────────────────────────────┼─────────────────────────────────┤
│ B. Mini-LLM local (qwen2.5:0.5b ou │ ~500 ms, faible GPU │ Très robuste à toute variation │ Crédible "on parle vraiment à │
│ llama3.2:1b, ~500 Mo) │ │ │ Léa" │
├──────────────────────────────────────────────┼───────────────────────────────┼───────────────────────────────────────────────────────────────┼─────────────────────────────────┤
│ C. Gros LLM (qwen2.5:7b déjà chargé pour │ 1-3 s, conflit GPU avec │ Excellente │ Sur-dimensionné, risque de swap │
│ t2a_decision) │ t2a_decision │ │ GPU │
└──────────────────────────────────────────────┴───────────────────────────────┴───────────────────────────────────────────────────────────────┴─────────────────────────────────┘
C est exclu — ça reproduirait le problème de hier soir (t2a_decision LLM + NLP LLM = swap VRAM, ralentissement).
Ma recommandation : A (regex) pour démo + bouton de secours
A — Regex :
# Patterns reconnus
"traite (\d+) dossiers?"
"code(?:-moi)? (?:les )?(\d+) (?:premiers )?dossiers?"
"(?:peux-tu )?(?:traiter|coder) (\d+) dossiers?"
Si la regex matche → action lancée immédiatement. Si elle matche pas → Léa répond « Je n'ai pas compris. Tu peux dire par exemple : "traite 3 dossiers" ».
Coût : ~0 ms, 0 GPU, ultra fiable.
Bouton de secours dans l'UI chat : à côté du champ texte, un bouton dédié [ Traiter N dossiers ▼ ] (avec un select 1/3/5/tous). Si le jour J Dom est stressé et tape mal, il a
toujours le bouton qui marche. Ceinture + bretelles.
Pour la démo, ça donne
[Dom dans le chat] : Léa, traite-moi 3 dossiers
[Léa] : Compris, je traite 3 dossiers... (commence à bosser)
Visuellement : pareil que si c'était un gros LLM. Mais 0 latence sur cette étape, 0 risque de mauvais parsing.
Et si tu veux vraiment l'effet "Léa comprend tout" pour la démo
Option B (mini-LLM) est viable : qwen2.5:0.5b ou llama3.2:1b font ~500 Mo de VRAM, latence ~500 ms, pas en conflit avec t2a_decision (qui est sur qwen2.5:7b). Mais ça ajoute :
- Une dépendance modèle de plus à gérer
- Une étape de classification d'intention (parser le naturel en JSON action)
- Un risque d'erreur d'interprétation que la regex n'a pas
Pour la démo, A est largement suffisant et te donne 100% de fiabilité. On garde B en bonus si on a 2h en J-1.
Et donc
Tu confirmes A (regex + bouton secours) ? C'est ~30 min de code au lieu de 1-2h, ça allège le plan.
Une fois que tu reviens avec aiva-vision côté interface, j'ai tout pour démarrer côté code. Réponds-moi en parallèle aux 5 questions techniques de mon précédent message (URL aiva,
format DPI, vérité-terrain, etc.) quand tu peux.
✻ Worked for 51s
❯ on va essayer B pour mini llm. La question concernant l'interface : "Cette interface aiva-vision est-elle déjà déployée et accessible depuis le PC Windows ? Quelle URL ?" On parle
bien de celle-la : [Image #4] ou c'est de celle là : [Image #5] Pour le dpi à coller, je te laisse le choix le plus "facileé. Mais [Image #6] ça serait pas trop mal. Attention, pour
qu'il n'y ai pas de confusion, le dpi doit être lu et traiter paendant la démo. On est d'accord ? ça devrait répondre à tes autres questions ?
⎿  [Image #4]
⎿  [Image #5]
⎿  [Image #6]
● C'est limpide, on tient la chaîne :
Easily (image 4) ──[Léa lit DPI via extract_text]──▶ aiva-vision (image 5)
↑ ↑
Source des données Cerveau d'analyse + affichage
Et oui sur le PENDANT — c'est ce qui fait la valeur démo. La promesse à Carvella & DG :
- Léa lit le dossier en direct (extraits OCR du DPI) → reformule → soumet à analyse → décision motivée.
- Pas de pré-remplissage caché. Tout est public à l'écran.
3 questions résiduelles avant de coder
1. URL de aiva-vision ? (j'imagine aiva.labs.laurinebazin.design ou similaire, mais je veux la vraie pour aller voir le DOM des 2 anchors textarea + bouton)
2. Vérité-terrain : sur ton image 5 c'est affiché concordance OK — d'où vient cette info ? Stockée dans aiva-vision (par dossier, étiquettes pré-faites) ou calculée à la volée ?
(Important : si la vérité-terrain est cachée dans aiva-vision, Léa peut la voir et un sceptique pourrait crier triche.)
3. Une fois l'analyse faite côté aiva : Léa s'arrête là (capture la décision et passe au dossier suivant) ou elle revient sur Easily pour saisir la décision dans le formulaire Codage
(boucle administrative complète) ?
- Stop à aiva = démo plus courte, message clair "Léa propose"
- Retour Easily = démo plus longue, message "Léa va jusqu'au bout"
- Mon avis : stop à aiva pour la démo (plus court, plus impactant). On dira "en intégration, Léa pourrait bien sûr remplir Easily aussi".
Sur le DPI à coller — choix simple et fidèle
Le format de l'image 6 est exactement ce que la concaténation brute des extract_text produit (Easily a déjà ses sections "Motif", "Constantes", "Examen", "Bio", etc., l'OCR retourne
ce texte tel quel). Donc :
dpi_complet = f"{t0}\n{t1}\n{t2}\n{t3}\n{t5}\n{t6}"
Pas besoin de LLM de reformulation, pas d'étape supplémentaire, fidèle à ce que dit le dossier. Si en pratique c'est mal mis en page, on insère un step minimal (regex de nettoyage
des doubles sauts de ligne).
Sur le mini-LLM B
Bon choix pour la démo. Mes candidats :
┌──────────────┬────────┬─────────────┬─────────┬──────────────────────────┐
│ Modèle │ Taille │ Latence │ VRAM │ Robustesse │
├──────────────┼────────┼─────────────┼─────────┼──────────────────────────┤
│ llama3.2:1b │ 1.3 GB │ ~300-500 ms │ ~1.5 GB │ Très bonne en français │
├──────────────┼────────┼─────────────┼─────────┼──────────────────────────┤
│ qwen2.5:0.5b │ 400 MB │ ~200 ms │ ~800 MB │ Bonne, plus léger │
├──────────────┼────────┼─────────────┼─────────┼──────────────────────────┤
│ gemma3:1b │ 800 MB │ ~400 ms │ ~1.2 GB │ Excellente compréhension │
└──────────────┴────────┴─────────────┴─────────┴──────────────────────────┘
Mon top : llama3.2:1b — meilleur compromis fr / latence / robustesse. ~500 ms pour parser "Léa, traite-moi 3 dossiers" → {action: "process_patients", count: 3, order: "first"}.
Imperceptible, et surtout pas en conflit avec qwen2.5:7b (t2a_decision) car charges séparées.
Tu veux que je parte sur llama3.2:1b pour le NLP, ou tu as une autre préférence ?
Plan d'action immédiat (dès que tu réponds aux 3 questions)
1. Je vais voir aiva-vision avec Chrome MCP pour cartographier les 2 anchors
2. Je pull llama3.2:1b côté Ollama si pas déjà là
3. Je commence par extract_table (3-4h) — la brique la plus risquée à dérisquer en premier
Toi en parallèle : tu reprends l'interface (modifier la maquette si besoin) et tu me confirmes l'URL aiva.
✻ Sautéed for 57s
❯ https://urgence.labs.laurinebazin.design/index.html. Concordance ok est géré comme le reste à la volé, tu le vera lors de l'exploration du dom. Pour l'intégration, je pense que l'on
pourrait faire boucle administrative complète. ça montre que l'on sait écrire aussi Pour le modéle, je pense qu'il faut faire des tests non ? tu peux dédier un agent dessus ? Si
les modéles ne sont pas présent telecharge les. c'est bon pour toi ? jepeux aller manger ?
● Vas-y, bon appétit ! Je m'occupe de tout pendant ce temps.
Mon programme pendant que tu manges :
1. Bench NLP via agent dédié (en background) — comparer llama3.2:1b, qwen2.5:0.5b, gemma3:1b sur des commandes types français + rapport comparatif
2. Cartographier le DOM aiva-vision (textarea, bouton, zone décision, vérité-terrain)
3. Préparer le terrain pour qu'on enchaîne sur le code à ton retour
● Bash(ollama list 2>&1 | head -30)
⎿  Running…
✻ Hatching… (22s · ↓ 752 tokens)
⎿  ◻ Diagnostiquer le pre-click qui ne prend pas le focus textarea
✔ Récupérer agent.log Windows pour replay 15:56
✔ Trouver le revert type_text x_pct/y_pct dans dag_execute.py
✔ Présenter diagnostic complet + recommandation chiffrée
✔ Élucider pourquoi 3 dispatch serveur, 1 reçu agent (3ᵉ)
… +8 completed