4f61741420
Some checks failed
security-audit / Bandit (scan statique) (push) Successful in 14s
security-audit / pip-audit (CVE dépendances) (push) Successful in 10s
security-audit / Scan secrets (grep) (push) Successful in 8s
tests / Lint (ruff + black) (push) Successful in 13s
tests / Tests unitaires (sans GPU) (push) Failing after 14s
tests / Tests sécurité (critique) (push) Has been skipped
Pipeline E2E complet validé : Capture VM → streaming → serveur → cleaner → replay → audit trail Mode apprentissage supervisé fonctionne (Léa échoue → humain → reprise) Dashboard : - Cleanup 14→10 onglets (RCE supprimée) - Fleet : enregistrer/révoquer agents, tokens, ZIP pré-configuré téléchargeable - Audit trail MVP (/audit) : filtres, tableau, export CSV, conformité AI Act/RGPD - Formulaire Fleet simplifié (nom + email, machine_id auto) VWB bridge Léa→VWB : - Compound décomposés en N steps (saisie + raccourci visibles) - Layout serpentin 3 colonnes (plus colonne verticale) - Badge OS 🪟/🐧, filtre OS retiré (admin Linux voit Windows) - Fix import SQLite readonly Cleaner intelligent : - Descriptions lisibles (UIA/C2) + détection doublons - Logique C2 : UIElement identifié = jamais parasite - Patterns parasites resserrés - Message Léa : "Je n'y arrive pas, montrez-moi comment faire" Config agent (INC-1 à INC-7) : - SERVER_URL + SERVER_BASE unifiés - RPA_OLLAMA_HOST séparé - allow_redirects=False sur POST - Middleware réécriture URL serveur CI Gitea : fix token + Flask-SocketIO + ruff propre Fleet endpoints : /agents/enroll|uninstall|fleet + agent_registry SQLite Backup : script quotidien workflows.db + audit Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
290 lines
13 KiB
Markdown
290 lines
13 KiB
Markdown
# FAQ — Questions des experts RPA (démo 26 avril 2026)
|
|
|
|
**Audience** : DG/DSI de groupements de cliniques, dont **plusieurs ont déjà
|
|
déployé UiPath, Automation Anywhere ou Power Automate**. Ils connaissent les
|
|
limites du RPA classique. Ils vont challenger.
|
|
|
|
**Posture de réponse** : factuelle, posée, ni défensive ni bravache. Quand
|
|
on n'a pas, on le dit. On finit toujours par ramener la conversation sur
|
|
**le cas métier urgences et le ROI chiffré**.
|
|
|
|
---
|
|
|
|
## Bloc TECHNO
|
|
|
|
### Q1. Pourquoi pas UiPath / Automation Anywhere / Power Automate ?
|
|
|
|
Les RPA classiques se cassent dès que l'UI change d'un pixel ou qu'on passe
|
|
par Citrix. Ils fonctionnent bien sur des processus répétitifs ultra-stables
|
|
(compta, RH), mal sur des métiers visuels variables comme les urgences.
|
|
Léa ne lit pas le DOM ni l'accessibility tree : elle **voit l'écran comme
|
|
un humain** et s'adapte quand l'UI bouge. On n'est pas un concurrent
|
|
généraliste d'UiPath : on est le bon outil pour **un métier précis où
|
|
UiPath échoue**.
|
|
|
|
### Q2. Comment Léa gère Citrix / RDP / VDI ?
|
|
|
|
C'est notre terrain principal, pas un cas dégradé. Léa capture l'écran
|
|
(image), comprend la structure via un modèle de vision, et interagit
|
|
via clavier/souris standard. Pas d'API, pas de tree, pas de crochet.
|
|
Citrix ou natif, c'est transparent. En contrepartie, la latence est
|
|
légèrement plus élevée (100-300 ms par action vs 50 ms en natif) —
|
|
acceptable pour du codage PMSI, pas pour du trading.
|
|
|
|
### Q3. Vous utilisez quel VLM ? Vos modèles sont open source ?
|
|
|
|
100 % modèles open source, tournant en local. Le stack actuel combine :
|
|
Qwen2.5-VL (grounding visuel), UI-TARS-1.5-7B (action sur UI), et des
|
|
prompts métier spécifiques par domaine (PMSI urgences, facturation, etc.).
|
|
Rien chez OpenAI, rien chez Anthropic au runtime client. Infrastructure
|
|
minimum pour un pilote : un serveur GPU (RTX 5070 ou équivalent) sur site
|
|
ou dans le cloud souverain.
|
|
|
|
### Q4. Que se passe-t-il quand l'UI change (mise à jour du DPI) ?
|
|
|
|
C'est la vraie question. Trois niveaux de réponse :
|
|
1. **Petit changement** (position d'un bouton, couleur) : Léa s'adapte
|
|
toute seule, parce qu'elle reconnaît sémantiquement "bouton Valider",
|
|
pas "bouton en x=420 y=180".
|
|
2. **Gros changement** (refonte UI) : Léa **détecte qu'elle ne comprend
|
|
plus**, se met en pause, et demande à l'humain. Pas de casse silencieuse.
|
|
3. **Réapprentissage** : la TIM refait le workflow une fois en mode
|
|
"apprends-moi", Léa se remet à jour. Temps typique : 15-30 minutes.
|
|
|
|
### Q5. Vous supportez quels OS ?
|
|
|
|
Agent client : **Windows 10/11** (cible principale, c'est ce que les
|
|
cliniques ont). Serveur : **Linux** (Ubuntu 22.04+). macOS et Linux
|
|
côté client ne sont pas prioritaires — la demande est marginale en milieu
|
|
hospitalier.
|
|
|
|
### Q6. Que faites-vous contre le drift d'écran entre deux sessions (taille de fenêtre, thème Windows) ?
|
|
|
|
Trois couches : (1) capture normalisée en résolution logique, (2)
|
|
invariance aux thèmes sombres/clairs via apprentissage multi-contextes,
|
|
(3) mémoire des cibles par signature sémantique plutôt que par coordonnées.
|
|
En pratique, sur nos tests chez Resurgences, le drift normal (thème,
|
|
multi-écran) ne casse pas l'exécution.
|
|
|
|
### Q7. Qu'est-ce qui se passe si le médecin ou la TIM tape au clavier pendant que Léa exécute ?
|
|
|
|
Détection d'interférence humaine : Léa met en pause dès qu'elle détecte une
|
|
activité clavier/souris non-Léa sur son fil d'exécution. L'humain reprend
|
|
la main, Léa reprend quand il a fini. Pas de conflit, pas de frappe
|
|
mélangée.
|
|
|
|
---
|
|
|
|
## Bloc SCALING / ROBUSTESSE
|
|
|
|
### Q8. Combien de postes Léa peut-on déployer en parallèle ?
|
|
|
|
Sur un serveur GPU mid-range (RTX 5070), on vise **10-20 postes en
|
|
parallèle** pour des workflows typiques (pas de vidéo temps réel 4K). Au-
|
|
delà, on scale horizontalement (plusieurs serveurs) ou on passe sur un GPU
|
|
plus costaud (A100, DGX). L'architecture est modulaire, le goulet
|
|
d'étranglement est le GPU, pas le code.
|
|
|
|
### Q9. Latence serveur ?
|
|
|
|
Action simple (clic, frappe) : 200-400 ms côté Léa (capture → inférence →
|
|
commande). Action complexe (compréhension d'écran + décision) : 1-3 s.
|
|
Pour du codage PMSI, ça passe largement. Pour du trading haute fréquence,
|
|
ce n'est pas le bon produit.
|
|
|
|
### Q10. Que fait Léa si le serveur est down ?
|
|
|
|
L'agent client bascule en **buffer local** : il continue à capturer ce que
|
|
l'utilisateur fait, stocke les sessions, et les envoie quand le serveur
|
|
revient. Pas de perte de données. L'exécution autonome, elle, se met en
|
|
pause — pas de fallback aveugle.
|
|
|
|
### Q11. Reprise après erreur ? Replay automatique ?
|
|
|
|
Trois niveaux :
|
|
1. **Reprise automatique** si l'erreur est transiente (popup, dialogue
|
|
inattendu reconnu par Léa).
|
|
2. **Pause + demande à l'humain** si Léa ne comprend pas ce qu'elle voit
|
|
("je vois un écran que je ne connais pas, merci de m'aider"). C'est la
|
|
règle : un échec devient un apprentissage, pas un crash.
|
|
3. **Replay à froid** du workflow complet depuis l'observation humaine
|
|
initiale, si on veut tout rejouer.
|
|
|
|
### Q12. Et si Léa fait une erreur qui a un impact réel (un mauvais code envoyé au PMSI) ?
|
|
|
|
Trois garde-fous : (1) **mode strict** où Léa ne valide jamais un envoi
|
|
final — toujours confirmation humaine, (2) **seuil de confidence** configurable
|
|
par workflow, (3) **log d'audit complet** (toutes les décisions Léa sont
|
|
tracées, replay vidéo possible). En 100 % autonomous, Léa agit seulement
|
|
sur des workflows **validés plusieurs fois** et avec un seuil de confidence
|
|
haut. Pour les urgences pilote, on démarre en mode "assistante" (copilote),
|
|
pas en 100 % autonome.
|
|
|
|
---
|
|
|
|
## Bloc SÉCURITÉ / CONFORMITÉ
|
|
|
|
### Q13. RGPD, AI Act, HDS — comment vous vous positionnez ?
|
|
|
|
- **RGPD** : 100 % local, aucune donnée patient ne sort du SI. L'agent
|
|
capture l'écran, traite sur un serveur **sur site ou en cloud souverain**
|
|
(3DS Outscale, OVH HDS). Pas de routing cloud US.
|
|
- **AI Act** : Léa est système IA au sens de l'article 50 (cf. LISEZMOI),
|
|
flag d'information utilisateur intégré. Classification "risque limité" en
|
|
copilote, "risque élevé" si autonome — documentation dans
|
|
`docs/RAPPORT_CONFORMITE_AI_ACT.md`.
|
|
- **HDS** : l'hébergement serveur doit être HDS-certifié. On accompagne le
|
|
pilote sur le choix de l'hébergeur si besoin.
|
|
|
|
### Q14. "100 % local", ça veut dire quoi concrètement ?
|
|
|
|
Deux niveaux d'installation possibles :
|
|
1. **Tout sur site** : serveur GPU dans le SI de la clinique, zéro sortie
|
|
réseau. Cas le plus sûr, le plus cher (hardware).
|
|
2. **Serveur en cloud souverain HDS** : données chiffrées en transit et au
|
|
repos, clés maîtrisées par le client. Aucun transit hors UE.
|
|
Dans les deux cas : **aucun appel cloud US**, aucun LLM propriétaire
|
|
externe (pas de ChatGPT, pas de Claude, pas de Gemini).
|
|
|
|
### Q15. Logs d'audit, traçabilité des décisions IA ?
|
|
|
|
Chaque décision de Léa (ce qu'elle a vu, ce qu'elle a décidé, sur quel
|
|
élément elle a cliqué) est loggée : screenshot avant/après, prompt soumis
|
|
au VLM, réponse, action exécutée. Rétention paramétrable (**minimum 180
|
|
jours** en config par défaut pour conformité). Replay vidéo d'un workflow
|
|
possible pour audit DIM ou ARS.
|
|
|
|
### Q16. Où est stocké le modèle ? Il apprend sur nos données ? Qui les possède ?
|
|
|
|
Modèles **open source** stockés sur le serveur client (poids Qwen, UI-TARS,
|
|
etc.). **Aucun apprentissage en ligne sur les données patient** par défaut —
|
|
on ne renvoie rien aux éditeurs des modèles. Un mode "fine-tuning local"
|
|
existe pour spécialiser Léa sur le vocabulaire d'une clinique, **exécuté
|
|
sur le serveur du client, poids gardés par le client**. Le client est
|
|
propriétaire de ses données ET de ses fine-tunings.
|
|
|
|
### Q17. Qui accède aux données chez vous ? Vos équipes ?
|
|
|
|
En prod chez un client : personne chez AIVANOV n'accède aux données sans
|
|
autorisation écrite. En pilote : un accès de debug peut être demandé avec
|
|
procédure documentée (lecture seule, logs anonymisés). **Les credentials
|
|
métier (compte DPI de la TIM) sont stockés dans un vault chiffré
|
|
Fernet/AES local** — jamais en clair côté serveur, jamais chez nous.
|
|
|
|
---
|
|
|
|
## Bloc BUSINESS
|
|
|
|
### Q18. Licensing ? C'est combien ?
|
|
|
|
**Modèle économique aligné sur la valeur**. Les postes utilisateurs ne
|
|
sont qu'une étape (Shadow puis Copilot) : une fois Léa entraînée, elle
|
|
tourne **en autonome** sur infrastructure dédiée — facturer "par poste"
|
|
reviendrait à facturer la phase d'apprentissage, pas la valeur créée.
|
|
|
|
**Notre proposition de valeur** : vous ne payez significativement **que
|
|
sur la valeur démontrée** (gains PMSI récupérés, mesurés via audit trail).
|
|
Plusieurs modèles possibles selon votre contexte (forfait établissement,
|
|
% de la valeur récupérée, volume traité, hybride) — **on cale ensemble
|
|
le modèle qui vous convient en one-to-one**.
|
|
|
|
Pour les **premiers pilotes** : accompagnement gratuit 2 mois
|
|
(infrastructure + setup + apprentissage), puis bascule sur le modèle
|
|
pérenne choisi ensemble.
|
|
|
|
*→ Rediriger vers one-to-one à la pause si question poussée — ne pas
|
|
annoncer un chiffre précis en plénière.*
|
|
|
|
### Q19. Support, maintenance, SLA ?
|
|
|
|
Pilote : accompagnement direct Dom + Amina, réponse < 4 h ouvrées.
|
|
Production : SLA à contractualiser (8 h ouvrées standard, 2 h premium).
|
|
Maintenance : mises à jour modèles trimestrielles, correctifs sur demande.
|
|
|
|
### Q20. Qui êtes-vous, votre équipe, vos références ?
|
|
|
|
AIVANOV, SAS française, fondée par Amina ETTORCHI (présidente,
|
|
ex-TIM/DIM, 15 ans d'expérience PMSI). Équipe technique lead Dom
|
|
(architecture vision + RPA). Projet Léa en développement depuis 2025,
|
|
version 1.0 déployable depuis avril 2026. **Premier pilote client à
|
|
démarrer** — pas de référence client public aujourd'hui, on est
|
|
transparent sur ce point et c'est une **opportunité pour les premiers
|
|
cliniques** (conditions pilote spécifiques).
|
|
|
|
### Q21. Combien de temps pour un pilote ? Pour une prod ?
|
|
|
|
- **Pilote** : 6-8 semaines (semaine 1-2 cadrage + capture workflow,
|
|
semaine 3-4 test en double avec la TIM, semaine 5-8 mesure ROI).
|
|
- **Mise en prod** : 2-3 mois après pilote validé, selon intégration SI
|
|
et HDS.
|
|
- **Rampe multi-clinique** : 1 clinique par mois en rythme raisonnable.
|
|
|
|
### Q22. Qu'est-ce qui n'est pas encore prêt, honnêtement ?
|
|
|
|
- Mode **autonomous 100 % non-supervisé** : en développement, pas
|
|
production-ready. En pilote, on démarre en **copilote** (Léa propose,
|
|
la TIM valide).
|
|
- **Fiche d'identité par DPI** : Resurgences et quelques autres sont
|
|
bien testés, les outils plus rares demandent une phase d'apprentissage
|
|
dédiée.
|
|
- **Support macOS / Linux côté client** : pas prioritaire, à la demande.
|
|
- **Multilingue** : français uniquement aujourd'hui. Anglais prévu S2 2026.
|
|
|
|
---
|
|
|
|
## Bloc URGENCES (spécifique)
|
|
|
|
### Q23. Pourquoi les urgences d'abord ? Pourquoi pas la facturation ou la pharmacie ?
|
|
|
|
Deux raisons : (1) **c'est là qu'Amina a prouvé 150 k€/mois de récupération
|
|
manuelle** — on bâtit sur une preuve terrain chiffrée. (2) C'est un
|
|
domaine à **forte douleur** (TIM sous pression, codage fait vite, DPI
|
|
variés). Le ROI est évident, la reproductibilité est haute. Facturation
|
|
et pharmacie suivront, après un premier carton aux urgences.
|
|
|
|
### Q24. Quels DPI urgences supportés aujourd'hui ?
|
|
|
|
**Testés et opérationnels** : Resurgences (Softway). **En cours de
|
|
validation** : Urqual, DxCare, CristalNet Urgences, Hôpital Manager.
|
|
**Non testés aujourd'hui** : Osiris, outils métier propriétaires
|
|
d'établissement. Le coût d'ajout d'un nouveau DPI est faible (5-10 jours
|
|
de capture/apprentissage TIM) grâce à l'approche 100 % vision.
|
|
|
|
### Q25. Quel ROI moyen sur les urgences ?
|
|
|
|
Borne basse prouvée (sans IA, Amina en manuel) : **150 k€/mois/clinique**.
|
|
Avec Léa, on **scale cette méthode sur des volumes que la TIM ne pouvait
|
|
pas traiter manuellement** — on couvre 100 % des dossiers au lieu de 10-20 %.
|
|
Projection prudente : **+30 à +70 % vs manuel**, soit **200-250 k€/mois/
|
|
clinique potentiel** pour des groupements avec volumes urgences élevés.
|
|
**À confirmer sur pilote.**
|
|
|
|
### Q26. Est-ce que Léa remplace la TIM ?
|
|
|
|
Non. Léa fait le travail répétitif à haute valeur/faible complexité (les
|
|
80 % des dossiers "évidents") et **libère la TIM pour les 20 % de cas
|
|
complexes** (dossiers longs, arbitrages médicaux, contrôle qualité). Le
|
|
discours pour la TIM : "on t'enlève les corvées, tu gardes le cœur du
|
|
métier". En pratique, on gagne du temps qualifié et on réduit le turn-over
|
|
TIM (douleur RH forte dans la plupart des cliniques).
|
|
|
|
### Q27. Comment vous convainquez un médecin urgentiste que Léa sait coder mieux que lui le soir à 23 h fatigué ?
|
|
|
|
On ne le convainc pas, **on lui montre sur son dossier d'hier soir** ce
|
|
qu'il a oublié, avec la justification ligne par ligne. L'adhésion médecin
|
|
se joue en démo, pas en réunion. Et ce n'est pas "Léa contre le médecin",
|
|
c'est "Léa filet de sécurité pour le médecin fatigué à 23 h".
|
|
|
|
---
|
|
|
|
## Ce qu'on ne dit JAMAIS devant cette audience
|
|
|
|
- "On n'a pas encore..." (à transformer en "c'est sur la roadmap S2 2026").
|
|
- "Notre produit est un prototype" (il est en v1.0, livrable).
|
|
- "Ça ne marche pas toujours" (on dit "il y a un mode supervisé pour les
|
|
cas où Léa doute").
|
|
- "UiPath c'est nul" (on dit "UiPath est excellent sur d'autres terrains,
|
|
nous on est spécialisés urgences").
|
|
- "On est une startup de 2 personnes" (on dit "une équipe ramassée, agile,
|
|
avec 15 ans d'expertise métier en lead").
|