rpa_vision_v3/docs/CHALLENGE_PLANS_16AVRIL.md

Challenge des plans d'action — Dashboard & VWB

16 avril 2026 — critique transversale des deux plans du 15 avril, avant exécution. Lecture ciblée : 10 minutes. Aucune modification de code. Ton direct.

---

Section 0 — Verdict global

Les deux plans sont globalement justes, bien structurés, honnêtes sur la dette. Mais :

• Le plan Dashboard sous-estime le couplage avec l'audit trail backend (risque cascading), et pousse un onglet Audit un peu trop ambitieux pour un POC qui démarre dans 2 semaines.
• Le plan VWB a une bonne hiérarchie mais deux erreurs factuelles (B5 vise le mauvais frontend, et la "bibliothèque qui s'efface" peut avoir une cause simple non explorée) et rate une priorité réelle : le backup automatique des workflows n'existe pas.
• Aucun des deux plans ne parle à l'autre — ils pourraient se contredire sur correction_packs et sur l'audit.

Recommandation : exécuter VWB quick wins en priorité (impact immédiat pour Dom), puis Dashboard cleanup, puis audit MVP. PAS l'onglet Audit "DSI-ready complet" avant le POC Anouste.

---

Section 1 — Dashboard : ce qui tient, ce qui ne tient pas

1.1. Ce qu'on valide tel quel

• Retirer onglet 🧪 Tests (B1) — correct, la RCE implicite via pytest subprocess est réelle, à éjecter sans regret.
• Retirer onglet ⚡ Exécution (B4) — la logique Agent V1 a déprécié l'ancien SocketIO subscribe_execution, plus personne ne regarde ça.
• Retirer pages auxiliaires /chat, /gestures, /streaming, /extractions — doublons morts. Bonne décision.
• Section E (non-décisions) — tout est juste : pas de React, pas de SSO, pas de WebSocket Audit. Sagesse YAGNI.

1.2. Ce qu'on ajuste

B2 — Retirer onglet 🧠 Apprentissage Le plan dit "10 min". Challenge : l'onglet affiche statCorpusSize qui est peut-être câblé ailleurs (conftest, training worker, etc.). Avant de retirer, vérifier qu'aucun autre consommateur (jobs, scripts) ne dépend de ces routes. Budget réaliste : 20-30 min pour grep + vérifier, pas 10.

B5 — Retirer onglet 📊 Vue d'ensemble "30 min" pour retirer + "fusionner un mini-résumé (4 KPIs) en tête de Services" — la fusion n'est pas gratuite. Si Dom veut garder les 4 KPIs, compter 1 h (déplacement + CSS + test). Si on retire franc et net sans fusion, alors 15 min. Trancher maintenant.

Estimation onglet Audit MVP (0.75 j) C'est réaliste à condition que le proxy Flask /api/audit/* → 5005 soit vraiment du copy-paste du pattern /api/streaming/*. Mais le plan omet :

• Côté streaming server, le token RPA_API_TOKEN est requis → le dashboard doit le propager (fait par le pattern /api/streaming mais pas mentionné dans le plan Audit).
• Le volume de données est surestimé : "1 800 entrées aujourd'hui" faux — 18 entrées aujourd'hui dans audit_2026-04-15.jsonl, 430 le jour de test du 13 avril. Le volume réel est faible, la pagination serveur n'est pas critique pour le POC.

Rapport PDF DSI (0.5 j) Sous-estimé. ReportLab/WeasyPrint sur une page A4 avec tableau + signature d'intégrité, c'est plutôt 1 j, à cause du templating, de la gestion des polices, du tableau qui déborde, des caractères accentués (French), et surtout du hash chain (voir 1.3).

Signature d'intégrité journalière (SHA-256) Le plan dit "20 lignes". Réaliste côté code, mais il faut :

• décider quand la clôture journalière a lieu (minuit UTC ? heure locale ?),
• stocker les hashes quelque part (fichier .sig ? table audit_signatures ?),
• rejouer la vérification facilement (python -m tools.verify_audit YYYY-MM-DD). Compter 0.5 j honnête, pas 0.25.

1.3. Ce qu'on retire du plan

Alerting seuil d'échecs (0.5 j en Sprint 3) Pourquoi on le sort : le dashboard est un outil interne déjà bien chargé. Un "badge rouge si >N échecs/h" sans destinataire email configuré = gadget visuel. Si un jour il y a un vrai besoin RSSI, ça passe par n8n (déjà dans le stack) ou Prometheus alerting. Ne pas le coder ici.

Widgets graphiques (camembert + courbe 7j) Pas avant validation MVP par un vrai DSI. Le tableau + filtres + export CSV suffisent pour 90 % des cas d'usage. Les graphiques, c'est du polish, à faire après retour client.

1.4. Ce qu'on ajoute

Backup BDD workflows VWB dans l'onglet Sauvegardes Aujourd'hui /api/backup/* côté dashboard ne touche probablement pas à visual_workflow_builder/backend/instance/workflows.db. Or c'est là que vivent les 3 workflows réels de Dom. À vérifier et intégrer au cron backup. Critique pour le POC.

Lien explicite Dashboard → VWB Si on retire les onglets "Workflows" et "Corrections", il faut un bouton "Ouvrir VWB" visible. Le plan le mentionne en passant dans "Services" mais ne le tranche pas. À préciser.

Health check streaming server L'onglet Streaming affiche les sessions, mais pas le statut du serveur 5005. Si le serveur tombe, Dom voit l'iframe vide sans message clair. Ajouter un check explicite côté dashboard.

---

Section 2 — VWB : ce qui tient, ce qui ne tient pas

2.1. Ce qu'on valide tel quel

• B2 (Unnamed Workflow) — 20 min, impact immédiat, bon.
• B3 (supprimer vwb_v3.db fantôme) — 15 min, risque réel identifié. Oui.
• B4 (double logging) — confirmé dans les logs (chaque ligne présente 2×), 15 min, fait.
• B6 (nettoyer fichiers parasites) — hygiène, 10 min.
• B7 (run.sh clarification) — 20 min, évite que Dom et nous lancions le mauvais frontend.
• Sections D et E (non-décisions) — toutes justifiées.

2.2. Ce qu'on ajuste

B1 — Migrer sessionStorage → localStorage Challenge fort : le plan dit "30 min → résout le bug principal". Je ne suis pas convaincu que sessionStorage soit la seule cause du bug "la bibliothèque s'efface tout le temps". Hypothèses alternatives à tester avant de coder :

1. L'utilisateur ouvre un nouvel onglet (vrai effacement sessionStorage, OK).
2. Un StrictMode React qui double-mount et écrase le state.
3. Un setCaptureLibrary([]) appelé par erreur dans un useEffect sans dépendance.
4. Une exception silencieuse qui reset l'état (QuotaExceededError de sessionStorage si > 5 Mo de base64 PNG).

Le plan saute direct à la solution sans diagnostic. Avant de migrer, reproduire le bug 2 minutes avec la console ouverte pour voir quand il se déclenche. Si c'est un quota, localStorage ne sauvera rien (même limite). Ne pas coder avant de comprendre.

Sous réserve que ce soit bien sessionStorage, la migration localStorage est bonne, mais :

• clé captureLibrary_v3 : bien de ne PAS migrer les deux anciennes clés automatiquement (laisser Dom perdre l'historique mauvais, repartir propre).
• cap 200 captures : OK mais thumbnails JPEG 200×150 q=0.7 au lieu de PNG base64 impératif sinon on fait sauter le quota en 15 captures.

Budget réaliste : 1 h (diagnostic 15 min + migration 30 min + compression thumbnail 15 min).

B5 — Supprimer 404 /api/correction-packs/stats Erreur factuelle dans le plan : B5 dit que l'appel vient de frontend/src/hooks/useCorrectionPacks.ts (legacy). Confirmé par grep. Mais le plan n'explique pas pourquoi on voit ces 404 aujourd'hui alors que seul frontend_v4 tourne. Deux possibilités :

1. Un onglet legacy resté ouvert dans le navigateur — triviale.
2. Un proxy dashboard appelle la route — à vérifier.

Si c'est (1), fermer l'onglet suffit, pas besoin de stubber. Si c'est (2), stubber. Mais avant de coder, regarder qui appelle. Budget : 10 min d'enquête + 10 min de fix éventuel.

C1 — Finaliser flux Import Léa → review → replay (1 j) Sous-estimé. Le plan liste 4 actions, dont "Bouton 'Valider et exécuter' qui passe review_status='approved' puis lance le replay via /execute". Mais :

• Le /execute VWB utilise l'IRBuilder local, pas le replay server Agent V1 (port 5005). Divergence d'exécution.
• Le flux "replay" réussi du 13 avril passe par Agent V1, pas par VWB. Le bouton "Valider et exécuter" dans VWB va donc exécuter avec un autre moteur que celui qui a produit le workflow.
• Question non résolue : si Dom valide un workflow importé et que l'exécution VWB échoue, alors qu'Agent V1 l'avait réussi, c'est quoi la vérité ?

Budget réaliste : 2 j, avec obligation de clarifier "qui exécute quoi" avant de coder le bouton.

C5 — Lier step ↔ screenshot source (2 j) C'est la vraie valeur. Le plan dit que les workflows Léa "contiennent déjà des screenshot_hash dans leurs nodes (à vérifier dans notepad_enriched.json)". Le "à vérifier" est critique. Si ce n'est pas le cas, il faut d'abord modifier le format d'export Léa avant de toucher VWB, ce qui triple la durée. Prérequis à lever avant de s'engager sur cet item.

2.3. Ce qu'on retire du plan

C4 — Consolider les 3 app.py (1 j)* Pas avant le POC. Zero impact utilisateur, risque de régression sur le seul endpoint VLM de app_lightweight.py. On garde en backlog "quand bande passante". Le plan le met en semaine 3+, correct, mais le listing en quick win serait une tentation.

C2 — Persister bibliothèque serveur (1.5 j) Si B1 fait vraiment son job avec localStorage + compression thumbnails, le serveur n'est pas nécessaire pour le POC. Ne démarrer C2 que si B1 échoue en usage réel. Le plan le dit ("si B1 montre ses limites"), mais ne le chiffre pas comme optionnel dans la roadmap — le sortir explicitement.

2.4. Ce qu'on ajoute

Backup quotidien de workflows.db Le plan le liste dans "Risques" mais ne le met pas comme action. C'est la seule BDD qui contient le travail manuel de Dom. 1 ligne dans backup_ssd.sh (ou cron local). Critique avant POC. 15 min.

Versionnement simple des workflows Aucun des 2 plans n'en parle. Scénario : Dom modifie un workflow importé, casse quelque chose, veut revenir en arrière. SQLAlchemy n'a pas de versioning natif. Proposition minimale : à chaque PUT /api/v3/workflow/<id>, dumper le JSON avant modification dans data/vwb/workflow_history/<id>/<timestamp>.json. 30 min, zero dépendance, ROI fort.

Nom clair du projet dans la liste VWB Si Dom importe 28 workflows du poste DESKTOP-58D5CAC, il va se noyer. Ajouter un filtre par machine + status (pending_review / approved / rejected) dans WorkflowList.tsx. 45 min, grande valeur UX.

---

Section 3 — Vision système transverse

3.1. Dépendances oubliées entre les deux plans

Audit trail parle à VWB ? Le plan Dashboard mentionne workflow_id et workflow_name dans les colonnes Audit. Or :

• Côté Agent V1, le workflow_id est celui du JSON disque.
• Côté VWB, les workflows ont un id SQLAlchemy distinct.
• Quand un workflow est importé dans VWB (source='learned_import'), le mapping entre les deux IDs n'est pas explicite.

Conséquence : un DSI qui filtre "workflow = X" dans l'Audit risque de ne pas retrouver le workflow correspondant dans VWB. À clarifier avant le sprint Audit MVP.

Correction packs : 2 plans, 2 décisions contradictoires

• Plan Dashboard : "supprimer onglet Corrections, les packs sont gérés dans VWB."
• Plan VWB section E3 : "Ne PAS porter CorrectionPacksDashboard sur le v4 — fermer proprement correction_packs."

Les deux disent "on ne fait plus de correction packs ici", mais personne ne dit où ils vivent maintenant. Si la réponse est "plus nulle part", il faut archiver proprement les données historiques (packs déjà produits) et le déclarer explicitement.

Frontend legacy partagé ? Le 404 /api/correction-packs/stats vient du frontend legacy VWB. Mais il ne serait pas impossible qu'un iframe du dashboard (onglet Corrections) l'ait aussi chargé. Si on retire l'onglet Dashboard avant de retirer le frontend legacy VWB, on ne supprime qu'une moitié du problème.

3.2. Ordre d'attaque recommandé

VWB quick wins AVANT Dashboard cleanup. Raisons :

1. Dom utilise VWB quotidiennement, le bug captures le bloque tout de suite.
2. VWB a des erreurs factuelles à résoudre en amont (diagnostic B1, source des 404).
3. Un Dashboard cleanup, ça se fait en 1 push, le VWB nécessite diagnostic → étaler.

3.3. Points d'intégration critiques

• Token RPA_API_TOKEN — doit être propagé Dashboard → streaming 5005 (audit) et VWB → streaming 5005 (replay). Fragile si Dom modifie .env. Ajouter un check au démarrage.
• Base workflows.db — partagée entre backend VWB et (potentiellement) Agent V1. Vérifier qu'aucune écriture concurrente n'existe (locks SQLite).
• Volumes data/audit/ et data/training/sessions/ — doivent être dans le backup quotidien. À vérifier dans backup_ssd.sh.

---

Section 4 — Ce qui n'est pas dans les plans mais devrait y être

Par ordre de priorité pour le POC Anouste :

1. Backup quotidien de workflows.db et data/audit/ Aujourd'hui un seul backup du 23/01 dans backend/instance/backups/. Si un disque meurt, Dom perd ses 3 workflows de démo + 10 jours d'audit. Bloquant POC. 15 min.

2. Versionnement basique des workflows VWB Snapshot à chaque PUT. 30 min. Zero dépendance. Fort ROI dès le 2e client.

3. Mode dégradé "streaming server indisponible" Aujourd'hui si port 5005 tombe, VWB et Dashboard affichent des erreurs cryptiques. Ajouter un badge "Streaming KO — Léa en pause" partout. 1 h.

4. Isolation multi-client Le jour où Anouste + un second client tournent sur la même instance, il n'y a aucune séparation (BDD, audit, sessions). Avant le POC DGX, décider : 1 instance par client ou tag client_id partout ? À trancher avec Dom avant de coder l'onglet Audit (sinon on refait le schéma).

5. Observabilité unifiée Prometheus existe côté dashboard (/metrics), mais pas côté VWB ni streaming server. Pour un hôpital, "pourquoi c'est lent aujourd'hui" = question fréquente. Ajouter 3 métriques clés (replay_duration_ms, vlm_call_ms, faiss_search_ms) exposées en Prometheus sur les 3 services. 2 h.

6. Documentation d'installation POC Ni DEV_SETUP.md ni README n'expliquent comment déployer l'ensemble chez un client. run.sh --full suppose l'environnement Dom. Pour Anouste il faut une procédure, sinon c'est Dom qui installe à la main. 2 h.

7. Anonymisation des logs pour export Si un DSI exporte le CSV Audit, il récupère user_name = "Marie Dupont". Fine pour un audit interne, problématique pour une démo publique. Prévoir un flag --anonymize sur l'export. 30 min.

8. Concurrence dashboard Aucune protection : 2 onglets ouverts = 2 actions possibles en parallèle. Pour le POC mono-utilisateur ça passe, à tracer pour multi-TIM.

---

Section 5 — Roadmap recommandée révisée (4 jours)

Contexte : POC Anouste dans ~2 semaines. DGX pas encore arrivé. Fenêtre technique ouverte mais finie.

Jour 1 (4 h) — Sécuriser le quotidien de Dom

• VWB B3 (vwb_v3.db fantôme) : 15 min
• VWB B4 (double logging) : 15 min
• VWB B6 (fichiers parasites) : 10 min
• VWB B7 (run.sh) : 20 min
• NOUVEAU — backup quotidien workflows.db + data/audit/ : 15 min
• VWB B2 (Unnamed Workflow) : 20 min
• Diagnostic B1 (bibliothèque captures, pas de code) : 30 min
• VWB B1 (localStorage + thumbnails JPEG) : 1 h
• Reste : commit + test manuel + pause café.

Sortie : Dom ne perd plus ses captures, ses workflows sont sauvegardés, les logs sont lisibles.

Jour 2 (4-6 h) — Dashboard cleanup + audit MVP backend

• Dashboard B1→B6 (retirer 5 onglets + pages mortes) : 2 h
• NOUVEAU — vérifier proxy workflow_id VWB ↔ Audit : 30 min
• Dashboard — onglet Audit MVP (proxy + tableau + filtres + export CSV) : 3 h
• NON : pas de PDF, pas de patient_ref_hash, pas d'alerting, pas de graphiques.

Sortie : dashboard à 9 onglets propres, onglet Audit fonctionnel pour démo POC.

Jour 3 (4-6 h) — Flux Léa → VWB → replay (C1)

• Diagnostic source des 404 correction-packs/stats : 15 min, fix si nécessaire
• NOUVEAU — versionnage workflows VWB (snapshot avant PUT) : 30 min
• NOUVEAU — filtre machine + status dans WorkflowList : 45 min
• C1 étape 1 : vérifier pendingReviewCount + banner : 1 h
• C1 étape 2 : warnings visuels sur steps importés : 1 h
• C1 étape 3 : bouton "Valider et exécuter" avec clarification qui exécute (Agent V1 ou VWB) : 2 h

Sortie : Dom peut importer un workflow Léa, voir les étapes floues, corriger, relancer.

Jour 4 (4 h) — Hardening POC Anouste

• NOUVEAU — mode dégradé streaming KO (3 services) : 1 h
• NOUVEAU — 3 métriques Prometheus sur VWB + streaming : 2 h
• NOUVEAU — doc installation POC (README_DEPLOY_POC.md) : 1 h

Sortie : POC déployable chez Anouste, observable, résilient aux pannes.

Ce qu'on garde en backlog (pas avant POC)

• VWB C3 (retirer frontend legacy), C4 (consolider app*.py), C5 (screenshot source par step), C2 (captures serveur)
• Dashboard Sprint 3 complet (PDF DSI, patient_ref_hash, signature intégrité, widgets, alerting)
• Dashboard Sprint 4 (améliorations Services, Sessions, Logs, Config)

---

Section 6 — Risques à surveiller pendant l'exécution

#	Risque	Probabilité	Impact	Mitigation
R1	B1 localStorage ne résout pas le vrai bug (cause racine différente)	Moyenne	Moyen	Diagnostic avant code. 15 min budgétées.
R2	Suppression d'un onglet Dashboard casse un script externe qui appelait la route	Faible	Moyen	Grep workspace complet avant suppression. n8n, agent_chat, core peuvent consommer.
R3	Proxy dashboard→streaming 5005 échoue sur token RPA_API_TOKEN	Moyenne	Moyen	Reproduire le pattern /api/streaming/* à la lettre. Tester avec curl direct avant UI.
R4	Workflow importé non rejouable (format Léa incompatible bridge)	Moyenne	Fort	Tester C1 sur le workflow notepad_enriched.json en premier. Si KO, pivoter sur C5 avant C1.
R5	workflow_id Audit ≠ id VWB → filtre DSI casse	Forte	Faible (hors POC)	Documenter dans l'export CSV : "workflow_id = source disque, voir VWB pour UI". Fix propre post-POC.
R6	Backup workflows.db oublié, crash disque avant POC	Faible	Critique	Backup manuel aujourd'hui, automatisation demain.
R7	Cleanup Dashboard supprime une route consommée par Agent V1	Faible	Fort	Routes retirées : /api/automation/*, /api/tests/*, /api/gestures, /api/chat/*. Grep avant.
R8	Onglet Audit "demi-fonctionnel" montré à Anouste produit plus de méfiance que rien	Moyenne	Fort	MVP uniquement (tableau + filtres + CSV). Pas de widgets creux.
R9	Régression frontend v4 après suppression legacy (C3 reporté, donc risque faible immédiat)	Faible	Moyen	C3 pas en roadmap 4 jours. Post-POC.
R10	Exécution VWB diverge de replay Agent V1 → incohérence démo	Forte	Fort	Clarifier quel moteur exécute en bouton "Valider et exécuter". Préférer Agent V1 via appel 5005.
R11	AI Act / RGPD — absence de patient_ref_hash repérée par DSI Anouste	Faible (POC early)	Moyen	Documenter la limitation dans DOSSIER_COMMISSAIRE_AUX_APPORTS. Planifier Sprint 3 post-POC.
R12	2 personnes éditent workflows.db simultanément (Dom + un TIM pendant démo)	Faible (POC mono)	Fort	SQLite verrou exclusif = erreur propre. Documenter "VWB mono-utilisateur pour l'instant".

---

Résumé exécutif pour Dom

1. Commence par VWB B3+B4+B6+B7+backup (1 h 30) — hygiène, zéro risque, gains immédiats.
2. Puis diagnostic B1 AVANT de coder — 15 min pour éviter de coder une fausse solution.
3. Dashboard cleanup + Audit MVP (1 journée) — retire les onglets morts, ajoute l'onglet Audit minimal. Pas de PDF ni d'alerting avant retour client.
4. Flux C1 (1 journée) — la vraie valeur visible de ton idée "importer Léa, corriger".
5. Hardening POC (demi-journée) — backups, métriques, doc deploy. Sinon le POC Anouste sera douloureux.
6. Tout le reste (C2, C3, C4, C5, Dashboard Sprint 3-4) : après POC.

Les deux plans sont solides. Ils manquent juste de connexions entre eux et sous-estiment le hardening POC. Ce document les relie et priorise pour la fenêtre de 2 semaines avant Anouste.

---

Fin du challenge — 16 avril 2026.