docs: add POC specs, handoffs, and research notes
This commit is contained in:
Dom
@@ -0,0 +1,474 @@
|
||||
# Cartographie des briques existantes — modèle Mandat / Protocoles
|
||||
|
||||
Date : 2026-05-25
|
||||
Statut : lecture structurelle, pas une spec d'implémentation
|
||||
|
||||
## Synthèse
|
||||
|
||||
Le projet contient déjà la plupart des briques nécessaires au modèle :
|
||||
|
||||
```text
|
||||
intention / mandat -> agent_chat + working_memory + ORA
|
||||
protocoles / gestes -> gesture_catalog + autonomous_planner + workflows VWB
|
||||
observation visuelle -> capturers + grounding + SomEngine + OCR/VLM
|
||||
scènes / dialogues -> DialogResolver + window guards + UI patterns
|
||||
action -> agent_v1 executor + replay engine
|
||||
vérification retour -> ReplayVerifier + Validator V2 + shadow validator
|
||||
apprentissage -> replay_learner + target_memory + correction packs + coaching
|
||||
évaluation -> LeaBench + tests replay + démo DPI
|
||||
supervision -> pause supervisée + UI Léa + confirmation loop
|
||||
```
|
||||
|
||||
La faiblesse principale n'est pas l'absence de composants. C'est leur absence de **contrat unificateur** autour de :
|
||||
|
||||
```text
|
||||
mandat -> intention -> scène -> affordance -> geste -> retour -> preuve apprenable
|
||||
```
|
||||
|
||||
## Briques runtime live
|
||||
|
||||
### Agent Windows live
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
agent_v0/agent_v1/core/executor.py
|
||||
agent_v0/agent_v1/core/grounding.py
|
||||
agent_v0/agent_v1/core/policy.py
|
||||
agent_v0/agent_v1/core/recovery.py
|
||||
agent_v0/agent_v1/core/system_dialog_guard.py
|
||||
agent_v0/agent_v1/ui/*
|
||||
```
|
||||
|
||||
Rôle actuel :
|
||||
|
||||
```text
|
||||
exécuter les actions ;
|
||||
résoudre les cibles visuelles ;
|
||||
faire les fallbacks ;
|
||||
pauser/demander de l'aide ;
|
||||
gérer certains dialogues ;
|
||||
remonter les résultats au serveur.
|
||||
```
|
||||
|
||||
Lien avec le modèle :
|
||||
|
||||
```text
|
||||
geste
|
||||
observation locale
|
||||
doute de localisation
|
||||
doute de scène
|
||||
retour action
|
||||
pause supervisée
|
||||
```
|
||||
|
||||
Manque conceptuel :
|
||||
|
||||
```text
|
||||
pas encore de trace causale complète ;
|
||||
pas de mandat/intention actif porté explicitement ;
|
||||
fallbacks encore trop locaux si non encadrés par le contrat ;
|
||||
pas de typage explicite du doute dans l'API résultat.
|
||||
```
|
||||
|
||||
### Serveur replay / coordination
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
agent_v0/server_v1/api_stream.py
|
||||
agent_v0/server_v1/stream_processor.py
|
||||
agent_v0/server_v1/replay_engine.py
|
||||
agent_v0/server_v1/replay_watchdog.py
|
||||
agent_v0/server_v1/replay_verifier.py
|
||||
agent_v0/server_v1/replay_learner.py
|
||||
agent_v0/server_v1/replay_memory.py
|
||||
agent_v0/server_v1/resolve_engine.py
|
||||
```
|
||||
|
||||
Rôle actuel :
|
||||
|
||||
```text
|
||||
construire/rejouer les actions ;
|
||||
distribuer les actions à l'agent ;
|
||||
résoudre les cibles côté serveur ;
|
||||
vérifier les retours ;
|
||||
planifier retries ou pauses ;
|
||||
enregistrer résultats et apprentissages.
|
||||
```
|
||||
|
||||
Lien avec le modèle :
|
||||
|
||||
```text
|
||||
protocole candidat sous forme workflow/replay ;
|
||||
résolution scène/affordance via resolve_engine ;
|
||||
retour via ReplayVerifier ;
|
||||
preuve potentielle via replay_learner/replay_memory ;
|
||||
pause supervisée ;
|
||||
temporalité via watchdog/retry.
|
||||
```
|
||||
|
||||
Manque conceptuel :
|
||||
|
||||
```text
|
||||
le workflow reste la structure dominante ;
|
||||
les expected_result existent mais ne forment pas encore une trace causale ;
|
||||
la vérification ne sait pas toujours quelle intention elle valide ;
|
||||
les retries ne sont pas encore arbitrés par doute typé.
|
||||
```
|
||||
|
||||
## Briques cognitives déjà présentes
|
||||
|
||||
### Mémoire de travail
|
||||
|
||||
Fichier :
|
||||
|
||||
```text
|
||||
core/cognition/working_memory.py
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
objective ;
|
||||
current_step ;
|
||||
observation courante ;
|
||||
historique d'actions ;
|
||||
faits appris ;
|
||||
expected_screen ;
|
||||
confidence ;
|
||||
needs_help ;
|
||||
timing.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
mandat/intention embryonnaire ;
|
||||
trace courte ;
|
||||
précondition attendue via expected_screen ;
|
||||
temporalité ;
|
||||
doute via confidence/needs_help.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
pas encore de scène d'intention typée ;
|
||||
pas de trace causale formelle geste/scène/intention/hypothèse/retour ;
|
||||
pas de distinction correction/démonstration/validation.
|
||||
```
|
||||
|
||||
### Boucle ORA
|
||||
|
||||
Fichier :
|
||||
|
||||
```text
|
||||
core/execution/observe_reason_act.py
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
observe -> reason -> act -> verify ;
|
||||
Decision avec expected_after ;
|
||||
VerificationResult ;
|
||||
mode instruction via VLM ;
|
||||
erreurs typées de base.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
base naturelle pour le contrat d'action ;
|
||||
hypothèse de retour via expected_after ;
|
||||
vérification post-geste.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
encore orienté step/workflow ;
|
||||
pas de protocole ouvert ;
|
||||
pas de preuve apprenable structurée ;
|
||||
pas d'opérateur d'extension de grammaire.
|
||||
```
|
||||
|
||||
## Briques intention / gestes / risque
|
||||
|
||||
### Agent chat et planification autonome
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
agent_chat/intent_parser.py
|
||||
agent_chat/autonomous_planner.py
|
||||
agent_chat/gesture_catalog.py
|
||||
agent_chat/confirmation.py
|
||||
agent_chat/urgences_orchestrator.py
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
parseur d'intentions utilisateur ;
|
||||
planner libre sans workflow pré-enregistré ;
|
||||
catalogue de gestes universels Windows/navigateur/édition ;
|
||||
évaluation de risque ;
|
||||
confirmation utilisateur ;
|
||||
orchestrateur urgence avec intentions nommées.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
mandat ;
|
||||
protocoles universels ;
|
||||
gestes types ;
|
||||
niveau de risque ;
|
||||
protocole métier urgence.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
cette couche semble parallèle au runtime live, pas intégrée au replay agent_v1 ;
|
||||
le risque est lexical et statique, pas encore tutoré par niveau de délégation ;
|
||||
les gestes ne sont pas encore reliés à scènes/affordances/retours qualifiés.
|
||||
```
|
||||
|
||||
## Briques scènes / dialogues
|
||||
|
||||
### DialogResolver
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
agent_v0/server_v1/core/dialog/catalog.py
|
||||
agent_v0/server_v1/core/dialog/resolver.py
|
||||
tests/unit/test_dialog_resolver.py
|
||||
tests/integration/test_dialog_resolver_endpoint.py
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
catalogue de dialogues connus ;
|
||||
policy auto/pause/skip ;
|
||||
protection modaux système ;
|
||||
pause conservative sans match ;
|
||||
evidence title + OCR/UIA.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
scènes d'intention simples ;
|
||||
affordances compatibles par dialogue ;
|
||||
affordances anti-intention potentielles ;
|
||||
rupture de scène.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
pas encore branché sur une intention active ;
|
||||
un dialogue est connu en absolu, pas encore "compatible avec ce mandat" ;
|
||||
les scènes composées métier restent hors catalogue.
|
||||
```
|
||||
|
||||
## Briques vérification / preuve
|
||||
|
||||
### ReplayVerifier et Validator V2
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
agent_v0/server_v1/replay_verifier.py
|
||||
core/validation/orchestrator.py
|
||||
core/workflow/shadow_validator.py
|
||||
tests/unit/test_replay_critic.py
|
||||
tests/integration/test_validator_step10.py
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
vérification pixel ;
|
||||
critic sémantique avec expected_result ;
|
||||
verdicts agrégés ;
|
||||
shadow validation.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
qualification du retour ;
|
||||
preuve apprenable potentielle ;
|
||||
doute d'effet ;
|
||||
temporalité post-action.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
le retour n'est pas toujours rattaché à intention/scène/affordance ;
|
||||
le "rien ne change" n'est pas encore qualifié par protocole ;
|
||||
la preuve apprenable n'est pas encore un objet explicite.
|
||||
```
|
||||
|
||||
## Briques apprentissage / correction
|
||||
|
||||
### Mémoire et corrections
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
core/learning/target_memory_store.py
|
||||
agent_v0/server_v1/replay_learner.py
|
||||
agent_v0/server_v1/replay_memory.py
|
||||
core/corrections/*
|
||||
core/coaching/*
|
||||
```
|
||||
|
||||
Points forts :
|
||||
|
||||
```text
|
||||
mémoire de cible persistante JSONL + SQLite ;
|
||||
résultats replay enregistrés ;
|
||||
correction packs versionnés ;
|
||||
statistiques succès/échec ;
|
||||
sessions de coaching avec accept/reject/correct/manual/skip.
|
||||
```
|
||||
|
||||
Correspondance modèle :
|
||||
|
||||
```text
|
||||
preuve apprenable ;
|
||||
correction ;
|
||||
démonstration ;
|
||||
validation ;
|
||||
désapprentissage par baisse confiance / failure_count ;
|
||||
niveau de délégation tutoré.
|
||||
```
|
||||
|
||||
Manque :
|
||||
|
||||
```text
|
||||
les preuves actuelles sont très orientées cible UI ;
|
||||
il manque intention/scène/affordance/retour dans la clé d'apprentissage ;
|
||||
correction et démonstration sont proches mais pas encore distinguées au niveau modèle ;
|
||||
le niveau de délégation par protocole/environnement n'est pas centralisé.
|
||||
```
|
||||
|
||||
## Briques évaluation / terrains d'essai
|
||||
|
||||
### LeaBench
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
core/evaluation/computer_use_bench.py
|
||||
core/evaluation/ollama_lea_bench_adapter.py
|
||||
tools/lea_bench.py
|
||||
tools/lea_bench_ollama.py
|
||||
benchmarks/computer_use/cases/*.jsonl
|
||||
```
|
||||
|
||||
Rôle :
|
||||
|
||||
```text
|
||||
mesurer décisions computer-use ;
|
||||
cas Bloc-notes/replay ;
|
||||
adapter modèles locaux ;
|
||||
scorer abstention/danger.
|
||||
```
|
||||
|
||||
Usage modèle :
|
||||
|
||||
```text
|
||||
tester scène/intention/affordance ;
|
||||
mesurer action fiable vs abstention ;
|
||||
convertir échecs réels en cas reproductibles.
|
||||
```
|
||||
|
||||
### Maquette DPI / urgence
|
||||
|
||||
Fichiers :
|
||||
|
||||
```text
|
||||
demo/facturation_urgences/*
|
||||
tests/e2e/test_urgence_aiva_demo.py
|
||||
tests/e2e/fixtures/urgence_aiva_demo/*
|
||||
```
|
||||
|
||||
Rôle :
|
||||
|
||||
```text
|
||||
terrain métier ;
|
||||
cas urgences synthétiques ;
|
||||
workflow démo existant ;
|
||||
stress test scènes composées et protocole métier.
|
||||
```
|
||||
|
||||
Usage modèle :
|
||||
|
||||
```text
|
||||
protocole métier générique ;
|
||||
adaptateur applicatif ;
|
||||
apprentissage sans contenu sensible réel ;
|
||||
validation de la généralisation hors Bloc-notes.
|
||||
```
|
||||
|
||||
## Diagnostic structurel
|
||||
|
||||
Le projet a déjà presque toutes les pièces, mais elles ne sont pas au même étage :
|
||||
|
||||
```text
|
||||
agent_chat sait raisonner intention/risque mais n'est pas le runtime live principal ;
|
||||
agent_v1 sait exécuter live mais raisonne encore action/cible ;
|
||||
server_v1 sait vérifier/apprendre mais pas sous trace causale complète ;
|
||||
core/cognition a la mémoire de travail mais elle n'est pas encore le fil commun ;
|
||||
core/learning sait mémoriser mais pas encore apprendre une grammaire d'action ;
|
||||
LeaBench sait mesurer mais doit recevoir des cas "mandat/protocole/scène".
|
||||
```
|
||||
|
||||
## Assemblage conceptuel recommandé
|
||||
|
||||
Sans parler encore de code, la bonne direction est d'utiliser :
|
||||
|
||||
```text
|
||||
core/cognition/working_memory.py
|
||||
comme fil de mandat/intention/trace causale ;
|
||||
|
||||
agent_chat/gesture_catalog.py
|
||||
comme base des protocoles universels ;
|
||||
|
||||
agent_v0/server_v1/core/dialog/*
|
||||
comme catalogue initial de scènes/dialogues ;
|
||||
|
||||
agent_v0/server_v1/replay_verifier.py + core/validation/*
|
||||
comme qualification du retour ;
|
||||
|
||||
core/learning + core/corrections + core/coaching
|
||||
comme apprentissage tutoré et désapprentissage ;
|
||||
|
||||
LeaBench + Bloc-notes + maquette DPI
|
||||
comme banc de validation progressif.
|
||||
```
|
||||
|
||||
## Point d'attention immédiat
|
||||
|
||||
Une correction technique est déjà en attente dans :
|
||||
|
||||
```text
|
||||
agent_v0/agent_v1/core/grounding.py
|
||||
```
|
||||
|
||||
Elle bloque le fallback texte local après rejet sémantique serveur. Elle correspond directement à la règle :
|
||||
|
||||
```text
|
||||
un rejet sémantique doit dominer les fallbacks opportunistes.
|
||||
```
|
||||
|
||||
Elle devra être testée et intégrée quand on repassera en exécution.
|
||||
@@ -0,0 +1,99 @@
|
||||
# Cartographie micro-apprentissage Lea - 2026-05-27
|
||||
|
||||
## But
|
||||
|
||||
Passer du replay metier fragile a une boucle courte ou Lea observe des gestes simples, les interprete, verifie leur effet, puis memorise ce qui marche.
|
||||
|
||||
On reutilise l'existant. On ne fabrique pas une boite a clic.
|
||||
|
||||
Premiere competence retenue: `ouvrir le menu Demarrer`. C'est plus atomique que "ouvrir Chrome" ou "ouvrir Word" et sert de base aux competences composees suivantes.
|
||||
|
||||
## Briques a reutiliser maintenant
|
||||
|
||||
| Besoin | Brique existante | Chemin |
|
||||
|---|---|---|
|
||||
| Demarrer une demonstration humaine | Bouton `Apprenez-moi` + `SharedState.start_recording()` | `agent_v0/agent_v1/ui/chat_window.py`, `agent_v0/agent_v1/ui/shared_state.py` |
|
||||
| Capturer clics/frappes/ecran | `AgentV1.start_session()` + `TraceStreamer` | `agent_v0/agent_v1/main.py`, `agent_v0/agent_v1/network/streamer.py` |
|
||||
| Recevoir les evenements | endpoint `/event` + `StreamProcessor.process_event()` | `agent_v0/server_v1/api_stream.py`, `agent_v0/server_v1/stream_processor.py` |
|
||||
| Construire une trace exploitable | `StreamProcessor.finalize_session()` + `GraphBuilder` | `agent_v0/server_v1/stream_processor.py`, `core/graph/graph_builder.py` |
|
||||
| Apprendre des corrections humaines | `ReplayLearner.record_human_correction()` | `agent_v0/server_v1/replay_learner.py` |
|
||||
| Memoriser les cibles fiables | `memory_record_success()` / `memory_lookup()` | `agent_v0/server_v1/replay_memory.py`, `core/learning/target_memory_store.py` |
|
||||
| Verifier qu'une action a eu un effet | `ReplayVerifier.verify_action()` | `agent_v0/server_v1/replay_verifier.py` |
|
||||
| Parler clairement a l'humain | contrat 4 champs | `agent_v0/agent_v1/ui/message_contract.py` |
|
||||
| Verifier le socle technique | preflight read-only | `tools/lea_micro_preflight.py` |
|
||||
|
||||
## Briques a eviter pour la V1 micro-learning
|
||||
|
||||
- Replay VWB/DAG comme moteur principal.
|
||||
- Coordonnees brutes comme verite finale.
|
||||
- Clipboard global Linux/Windows/NoMachine comme transport de donnees.
|
||||
- Scenarios metier longs.
|
||||
- Corrections injectees a la main dans un workflow pour faire passer une demo.
|
||||
|
||||
## Flux minimal
|
||||
|
||||
1. Observation
|
||||
Dom lance `Apprenez-moi`, nomme une micro-tache, puis montre 1 geste court.
|
||||
|
||||
2. Interpretation
|
||||
Le serveur conserve les evenements, les screenshots, les titres de fenetre, les indices UIA/OCR/SoM disponibles.
|
||||
|
||||
3. Generalisation prudente
|
||||
Lea derive une competence courte: intention, contexte d'ecran attendu, signaux visuels, postcondition observable.
|
||||
|
||||
4. Tentative encadree
|
||||
Lea ne tente en autonomie que si la cible est suffisamment decrite et verifiable.
|
||||
|
||||
5. Verification
|
||||
Pixel diff seul ne suffit pas. Il faut verifier un effet observable: fenetre ouverte, champ rempli, titre change, application fermee, texte present.
|
||||
|
||||
6. Memoire
|
||||
Les succes repetes alimentent `TargetMemoryStore`. Les echecs et corrections humaines alimentent `ReplayLearner`.
|
||||
|
||||
7. Demande humaine
|
||||
Si Lea ne sait pas, elle doit afficher:
|
||||
|
||||
```text
|
||||
J'essaie de : <INTENTION>
|
||||
J'attendais : <ATTENDU>
|
||||
Je vois : <VU>
|
||||
Peux-tu : <DEMANDE>
|
||||
```
|
||||
|
||||
## Etats d'une competence
|
||||
|
||||
| Etat | Sens |
|
||||
|---|---|
|
||||
| OBSERVATION | Lea a seulement vu le geste humain. |
|
||||
| COACHING | Lea peut proposer une tentative, mais demande confirmation/correction. |
|
||||
| AUTO_CANDIDATE | Lea a reussi plusieurs fois avec verification. |
|
||||
| AUTO | Lea peut executer seule avec garde-fous. |
|
||||
|
||||
## Fichiers a lire/modifier ensuite
|
||||
|
||||
Priorite 1:
|
||||
|
||||
- `agent_v0/agent_v1/ui/chat_window.py` : texte de lancement/fin d'apprentissage.
|
||||
- `agent_v0/agent_v1/ui/shared_state.py` : metadata de session micro-learning.
|
||||
- `agent_v0/agent_v1/main.py` : nommage session + mode capture.
|
||||
- `agent_v0/server_v1/stream_processor.py` : sortie de finalisation orientee competence courte.
|
||||
- `agent_v0/server_v1/replay_learner.py` : persistance des corrections et resultats.
|
||||
|
||||
Priorite 2:
|
||||
|
||||
- `agent_v0/server_v1/replay_memory.py` : fiabilite et collisions sur boutons generiques.
|
||||
- `agent_v0/server_v1/replay_verifier.py` : verifier des postconditions simples.
|
||||
- `agent_v0/agent_v1/core/executor.py` : mode correction humaine et messages visibles.
|
||||
|
||||
## Risques prioritaires
|
||||
|
||||
1. Confondre trace de demonstration et competence generalisable.
|
||||
2. Valider une action seulement parce que les pixels bougent.
|
||||
3. Apprendre une coordonnee dependante DPI/ecran.
|
||||
4. Produire un message conforme au contrat mais pauvre en contexte.
|
||||
5. Recharger le VLM au mauvais moment et ajouter une latence cold start.
|
||||
6. Melanger session de capture et replay actif.
|
||||
|
||||
## Regle de travail
|
||||
|
||||
Chaque micro-tache doit tenir en moins de deux minutes, avec une postcondition observable. Si on ne peut pas formuler la postcondition, on ne l'apprend pas encore.
|
||||
609
docs/architecture/MODELE_MANDAT_PROTOCOLS_LEA_2026-05-25.md
Normal file
609
docs/architecture/MODELE_MANDAT_PROTOCOLS_LEA_2026-05-25.md
Normal file
@@ -0,0 +1,609 @@
|
||||
# Modèle Mandat / Protocoles / Scènes pour Léa
|
||||
|
||||
Version : 0.1 brainstorming
|
||||
Date : 2026-05-25
|
||||
Statut : modèle conceptuel, pas une spec technique
|
||||
|
||||
## Thèse
|
||||
|
||||
Léa n'est pas une boîte à clics et ne doit pas rejouer un workflow. Léa est une collaboratrice visuelle mandatée.
|
||||
|
||||
Elle reçoit une fin à atteindre, choisit un chemin connu ou apprend un chemin nouveau, observe le retour de ses actions, qualifie réussite/échec/doute, puis adapte son comportement.
|
||||
|
||||
Formule centrale :
|
||||
|
||||
```text
|
||||
Un protocole est une grammaire d'action autour d'une intention.
|
||||
```
|
||||
|
||||
Un logiciel, un OS ou un DPI peut changer les pixels, les titres, les boutons et les DPI. Le processus métier reste souvent stable : chercher, ouvrir, saisir, valider, enregistrer, corriger, transmettre, facturer, archiver. Léa doit apprendre ces grammaires d'action, pas mémoriser des coordonnées.
|
||||
|
||||
## Vocabulaire
|
||||
|
||||
### Mandat
|
||||
|
||||
Un mandat est une fin déléguée à Léa.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Ecris ce texte et enregistre-le.
|
||||
Trouve une vidéo de jazz et lance-la.
|
||||
Ouvre le dossier patient de Mme X.
|
||||
Saisis cette information dans le logiciel métier.
|
||||
```
|
||||
|
||||
Le mandat n'est pas une suite de clics. Il donne le but, le contexte et éventuellement les limites.
|
||||
|
||||
### Intention active
|
||||
|
||||
L'intention active est le sous-but courant qui sert le mandat.
|
||||
|
||||
Exemple pour `Ecris ce texte et enregistre-le` :
|
||||
|
||||
```text
|
||||
ouvrir un outil de saisie
|
||||
écrire le texte
|
||||
déclencher la sauvegarde
|
||||
choisir ou confirmer le nom
|
||||
vérifier que le fichier existe
|
||||
```
|
||||
|
||||
### Protocole d'usage
|
||||
|
||||
Un protocole d'usage est un chemin connu, adaptable, pour accomplir une intention.
|
||||
|
||||
Exemples universels :
|
||||
|
||||
```text
|
||||
ouvrir une application
|
||||
chercher sur le web
|
||||
saisir du texte
|
||||
sauvegarder un fichier
|
||||
confirmer une boîte de dialogue
|
||||
fermer une fenêtre
|
||||
copier-coller
|
||||
```
|
||||
|
||||
Exemples métier :
|
||||
|
||||
```text
|
||||
ouvrir une fiche patient
|
||||
créer une ligne de facturation
|
||||
valider une commande de stock
|
||||
rapprocher une écriture comptable
|
||||
```
|
||||
|
||||
Un protocole n'est pas un workflow figé. Il contient des scènes attendues, des affordances compatibles, des variantes autorisées et des conditions d'arrêt.
|
||||
|
||||
### Scène
|
||||
|
||||
Une scène est la situation visuelle pertinente pour l'intention courante.
|
||||
|
||||
La scène active pertinente n'est pas forcément la fenêtre au focus OS. C'est la zone ou la boîte qui sert le mandat maintenant.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Bloc-notes prêt à recevoir du texte.
|
||||
Fenêtre Enregistrer sous.
|
||||
Dialogue "Voulez-vous enregistrer les modifications ?".
|
||||
Page de résultats Google.
|
||||
Page vidéo YouTube.
|
||||
Fiche patient ouverte.
|
||||
```
|
||||
|
||||
### Affordance
|
||||
|
||||
Une affordance est une action proposée par la scène.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
bouton Enregistrer
|
||||
bouton Annuler
|
||||
champ Nom du fichier
|
||||
barre d'adresse
|
||||
champ de recherche
|
||||
bouton Lecture
|
||||
onglet Patient
|
||||
bouton Valider
|
||||
```
|
||||
|
||||
Léa ne doit pas seulement reconnaître une affordance. Elle doit comprendre son rôle dans la scène et sa compatibilité avec l'intention.
|
||||
|
||||
### Geste
|
||||
|
||||
Un geste est l'action concrète décidée dans une scène.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
cliquer sur Enregistrer
|
||||
taper le nom du fichier
|
||||
appuyer sur Ctrl+S
|
||||
sélectionner un résultat de recherche
|
||||
cliquer sur Lecture
|
||||
```
|
||||
|
||||
### Retour
|
||||
|
||||
Un retour est tout changement ou non-changement observé après un geste.
|
||||
|
||||
```text
|
||||
Résultat attendu obtenu -> réussite.
|
||||
Résultat contraire -> échec.
|
||||
Rien ne change -> attente, latence ou échec à qualifier.
|
||||
Nouvelle fenêtre -> événement à interpréter.
|
||||
Erreur -> rupture ou branche prévue selon le protocole.
|
||||
```
|
||||
|
||||
### Doute
|
||||
|
||||
Le doute est un signal utile, pas une faiblesse.
|
||||
|
||||
Léa doute quand :
|
||||
|
||||
```text
|
||||
les sources visuelles divergent ;
|
||||
la scène observée ne correspond pas à l'intention ;
|
||||
aucun protocole connu ne s'applique ;
|
||||
un retour attendu n'arrive pas ;
|
||||
une action répétée ne produit aucun effet ;
|
||||
la scène est sensible ou irréversible sans mandat explicite.
|
||||
```
|
||||
|
||||
Le doute peut mener à une variante, une demande d'aide, ou une pause.
|
||||
|
||||
## Boucle cognitive minimale
|
||||
|
||||
```text
|
||||
1. Recevoir le mandat.
|
||||
2. Déduire l'intention active.
|
||||
3. Choisir le protocole connu le plus simple.
|
||||
4. Observer la scène active pertinente.
|
||||
5. Identifier les affordances disponibles.
|
||||
6. Choisir le geste compatible avec l'intention.
|
||||
7. Agir.
|
||||
8. Observer le retour.
|
||||
9. Qualifier : réussite, échec, attente, rupture, doute.
|
||||
10. Continuer, essayer une variante, demander de l'aide, ou apprendre.
|
||||
```
|
||||
|
||||
Le point essentiel : une action n'est pas justifiée par le fait qu'un bouton existe. Elle est justifiée parce que ce bouton, dans cette scène, sert l'intention active.
|
||||
|
||||
## Contrat d'action
|
||||
|
||||
Avant d'agir, Léa doit pouvoir répondre implicitement à cinq questions :
|
||||
|
||||
```text
|
||||
Quelle intention est-ce que je sers ?
|
||||
Dans quelle scène suis-je ?
|
||||
Quelle affordance est-ce que j'utilise ?
|
||||
Pourquoi cette affordance est-elle compatible avec mon intention ?
|
||||
Quel retour est-ce que j'attends ?
|
||||
```
|
||||
|
||||
Si Léa ne peut pas produire cette justification, elle ne doit pas transformer l'action en clic opportuniste.
|
||||
|
||||
Ce contrat n'impose pas de demander à l'humain à chaque doute. Il impose que toute tentative ait une hypothèse vérifiable.
|
||||
|
||||
## Autonomie
|
||||
|
||||
L'autonomie de Léa est une autonomie d'initiative, pas une autonomie d'entêtement.
|
||||
|
||||
Léa peut :
|
||||
|
||||
```text
|
||||
choisir le chemin le plus simple ;
|
||||
changer de chemin si le premier échoue ;
|
||||
essayer une variante cohérente ;
|
||||
interpréter un retour ;
|
||||
demander de l'aide ;
|
||||
apprendre après aide ou résultat qualifié.
|
||||
```
|
||||
|
||||
Léa ne doit pas :
|
||||
|
||||
```text
|
||||
agir coûte que coûte ;
|
||||
inventer une réussite ;
|
||||
apprendre un échec comme une réussite ;
|
||||
continuer un fallback après rejet sémantique ;
|
||||
sortir d'un protocole sans raison explicable.
|
||||
```
|
||||
|
||||
Le risque n'est pas interdit. Il doit être exploitable :
|
||||
|
||||
```text
|
||||
observable
|
||||
attribuable à une intention
|
||||
réversible si possible
|
||||
évaluable après coup
|
||||
transformable en apprentissage
|
||||
```
|
||||
|
||||
## Structure conceptuelle d'un protocole
|
||||
|
||||
Un protocole peut se décrire sur un coin de papier avec les éléments suivants :
|
||||
|
||||
```text
|
||||
Nom
|
||||
Intention servie
|
||||
Préconditions plausibles
|
||||
Scènes attendues
|
||||
Affordances compatibles par scène
|
||||
Gestes possibles
|
||||
Variantes autorisées
|
||||
Retours attendus
|
||||
Branches normales
|
||||
Ruptures connues
|
||||
Conditions de réussite
|
||||
Conditions d'abstention ou demande d'aide
|
||||
Preuves apprenables
|
||||
```
|
||||
|
||||
Ce n'est pas une séquence figée. C'est une grammaire : elle autorise plusieurs phrases correctes pour atteindre la même intention.
|
||||
|
||||
## Exemple 1 : ouvrir un logiciel
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Ouvre Bloc-notes.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
rendre disponible un outil de saisie texte simple
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
menu Démarrer / recherche Windows
|
||||
raccourci existant
|
||||
commande Exécuter
|
||||
barre de recherche système
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
bureau ou environnement de départ
|
||||
menu/recherche d'application
|
||||
résultat "Bloc-notes"
|
||||
fenêtre Bloc-notes ouverte
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
champ de recherche
|
||||
résultat d'application Bloc-notes
|
||||
zone de texte vide
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
une fenêtre de saisie texte apparaît
|
||||
elle accepte le focus
|
||||
elle permet de taper du texte
|
||||
```
|
||||
|
||||
Variantes :
|
||||
|
||||
```text
|
||||
si la recherche Windows échoue, essayer Exécuter/notepad
|
||||
si un autre éditeur texte est disponible et accepté par le mandat, l'utiliser
|
||||
si aucune scène d'édition texte n'apparaît, demander ou apprendre
|
||||
```
|
||||
|
||||
## Exemple 2 : saisir un texte
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Saisis "testtesttest".
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
placer le contenu texte dans une zone éditable
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
éditeur texte ouvert
|
||||
champ texte actif
|
||||
curseur visible ou zone éditable détectée
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
zone de saisie
|
||||
document vide ou modifiable
|
||||
```
|
||||
|
||||
Gestes :
|
||||
|
||||
```text
|
||||
focus zone éditable si nécessaire
|
||||
taper le texte
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
le texte apparaît
|
||||
le contenu correspond au mandat
|
||||
```
|
||||
|
||||
Ruptures :
|
||||
|
||||
```text
|
||||
zone non éditable
|
||||
fenêtre inattendue
|
||||
texte non apparu
|
||||
application fermée
|
||||
```
|
||||
|
||||
## Exemple 3 : enregistrer un fichier
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Enregistre le texte saisi.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
persister le contenu courant dans un fichier
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
Ctrl+S
|
||||
menu Fichier > Enregistrer
|
||||
bouton Enregistrer si visible
|
||||
Enregistrer sous si le fichier n'a pas encore de nom
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
éditeur texte avec contenu non sauvegardé
|
||||
dialogue Enregistrer sous
|
||||
dialogue "voulez-vous enregistrer les modifications ?"
|
||||
dialogue "le fichier existe déjà, voulez-vous le remplacer ?"
|
||||
retour à l'éditeur avec état sauvegardé
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
Enregistrer
|
||||
Oui
|
||||
Remplacer, si le mandat autorise l'écrasement
|
||||
champ Nom du fichier
|
||||
```
|
||||
|
||||
Affordances contraires :
|
||||
|
||||
```text
|
||||
Annuler
|
||||
Ne pas enregistrer
|
||||
Non, si la question porte sur la sauvegarde souhaitée
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
la boîte de sauvegarde se ferme
|
||||
le fichier existe à l'emplacement choisi
|
||||
le contenu est présent
|
||||
le document n'est plus en état non sauvegardé
|
||||
```
|
||||
|
||||
Règle clé :
|
||||
|
||||
```text
|
||||
Voir un bouton "Enregistrer" ne suffit pas.
|
||||
Il faut que ce bouton soit dans une scène compatible avec l'intention de sauvegarde.
|
||||
```
|
||||
|
||||
## Exemple 4 : regarder une vidéo de jazz
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Trouve et lance une vidéo de jazz.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
obtenir une vidéo en lecture correspondant au thème jazz
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
ouvrir navigateur -> YouTube -> chercher jazz -> lancer une vidéo
|
||||
ouvrir navigateur -> moteur de recherche -> "video jazz" -> ouvrir un résultat vidéo
|
||||
utiliser une application ou un favori connu si disponible
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
navigateur ouvert
|
||||
barre d'adresse ou champ de recherche
|
||||
page de résultats
|
||||
page vidéo
|
||||
lecteur avec bouton Lecture ou vidéo déjà en lecture
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
barre d'adresse
|
||||
champ de recherche
|
||||
résultat vidéo pertinent
|
||||
bouton Lecture
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
une vidéo démarre
|
||||
le contenu semble lié au jazz
|
||||
le son ou la lecture est active si observable
|
||||
```
|
||||
|
||||
Variantes :
|
||||
|
||||
```text
|
||||
si YouTube est inaccessible, utiliser le moteur de recherche
|
||||
si le premier résultat n'est pas pertinent, revenir et choisir un autre résultat
|
||||
si un consentement cookie bloque la scène, traiter le dialogue seulement s'il est compatible avec la navigation
|
||||
```
|
||||
|
||||
## Généralisation multi-environnements
|
||||
|
||||
Léa doit apprendre à plusieurs niveaux.
|
||||
|
||||
### Niveau 1 : mémoire locale
|
||||
|
||||
```text
|
||||
Dans cet écran précis, ce bouton sauvegarde.
|
||||
Dans ce DPI, cette scène ressemble à Save As.
|
||||
Dans ce logiciel, ce champ est le champ de recherche patient.
|
||||
```
|
||||
|
||||
### Niveau 2 : protocole applicatif
|
||||
|
||||
```text
|
||||
Dans ce logiciel DPI, ouvrir un dossier patient passe par recherche -> liste -> fiche.
|
||||
Dans ce logiciel comptable, valider une écriture passe par saisie -> contrôle -> validation.
|
||||
```
|
||||
|
||||
### Niveau 3 : protocole métier
|
||||
|
||||
```text
|
||||
Tous les DPI ont une façon de chercher un patient, ouvrir sa fiche, saisir une information, valider et tracer.
|
||||
Tous les logiciels de stock ont une façon de rechercher un article, ajuster une quantité, valider un mouvement.
|
||||
Tous les logiciels comptables ont une façon de saisir, contrôler, rapprocher, valider.
|
||||
```
|
||||
|
||||
### Niveau 4 : protocole universel
|
||||
|
||||
```text
|
||||
chercher
|
||||
ouvrir
|
||||
saisir
|
||||
valider
|
||||
annuler
|
||||
enregistrer
|
||||
confirmer
|
||||
revenir
|
||||
fermer
|
||||
```
|
||||
|
||||
La généralisation consiste à relier les preuves locales à ces niveaux supérieurs.
|
||||
|
||||
## Apprentissage
|
||||
|
||||
Léa apprend seulement à partir d'un résultat qualifié.
|
||||
|
||||
Apprentissage valide :
|
||||
|
||||
```text
|
||||
L'action a produit le retour attendu.
|
||||
L'humain a confirmé ou corrigé.
|
||||
La scène et l'intention sont connues.
|
||||
Le geste est attribuable au résultat.
|
||||
```
|
||||
|
||||
Apprentissage interdit :
|
||||
|
||||
```text
|
||||
clic opportuniste sans justification
|
||||
effet non vérifié
|
||||
échec enregistré comme succès
|
||||
correction humaine confondue avec autonomie
|
||||
retour ambigu non qualifié
|
||||
```
|
||||
|
||||
La correction humaine ne doit pas seulement enregistrer "où cliquer". Elle doit enrichir :
|
||||
|
||||
```text
|
||||
quelle scène était visible
|
||||
quelle intention était active
|
||||
quelle affordance était correcte
|
||||
quel geste a été fait
|
||||
quel retour a prouvé la réussite
|
||||
```
|
||||
|
||||
## Ce que ce modèle aurait changé dans nos tests
|
||||
|
||||
Dans les tests humains réalisés ces derniers jours, beaucoup d'échecs venaient d'une confusion entre :
|
||||
|
||||
```text
|
||||
résoudre une cible visuelle
|
||||
et accomplir une intention
|
||||
```
|
||||
|
||||
Avec ce modèle :
|
||||
|
||||
```text
|
||||
ouvrir un logiciel
|
||||
trouver une zone de saisie
|
||||
taper
|
||||
déclencher une sauvegarde
|
||||
interpréter Enregistrer sous
|
||||
confirmer Enregistrer
|
||||
traiter un remplacement ou une demande de sauvegarde
|
||||
vérifier le résultat
|
||||
```
|
||||
|
||||
ne sont plus des actions isolées. Ce sont des scènes normales dans un protocole connu.
|
||||
|
||||
Si une fenêtre inattendue apparaît, Léa ne demande pas "où cliquer ?". Elle se demande :
|
||||
|
||||
```text
|
||||
Cette scène est-elle une continuation normale de mon mandat ?
|
||||
Quelles affordances propose-t-elle ?
|
||||
Laquelle sert l'intention ?
|
||||
Quel retour dois-je attendre ?
|
||||
```
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
1. Quel vocabulaire final garder : protocole d'usage, geste type, routine intentionnelle ?
|
||||
2. Comment exprimer à l'utilisateur le mandat courant sans jargon ?
|
||||
3. Quelles familles de protocoles universels faut-il inscrire en premier ?
|
||||
4. Comment distinguer visuellement une scène pertinente d'une fenêtre simplement au focus ?
|
||||
5. Comment demander de l'aide sans transformer l'humain en téléopérateur ?
|
||||
6. Comment capturer l'apprentissage métier sans mémoriser des informations sensibles ?
|
||||
|
||||
## Synthèse courte
|
||||
|
||||
```text
|
||||
Léa reçoit un mandat.
|
||||
Elle choisit un protocole.
|
||||
Elle observe une scène.
|
||||
Elle interprète les affordances.
|
||||
Elle agit avec une hypothèse.
|
||||
Elle qualifie le retour.
|
||||
Elle apprend uniquement d'un résultat qualifié.
|
||||
```
|
||||
|
||||
Cette structure permet de viser la généralisation : mêmes intentions, scènes différentes, logiciels différents, DPI différents, OS différents.
|
||||
953
docs/architecture/MODELE_MANDAT_PROTOCOLS_LEA_2026-05-25_v0.2.md
Normal file
953
docs/architecture/MODELE_MANDAT_PROTOCOLS_LEA_2026-05-25_v0.2.md
Normal file
@@ -0,0 +1,953 @@
|
||||
# Modèle Mandat / Protocoles / Scènes pour Léa
|
||||
|
||||
Version : 0.2 brainstorming
|
||||
Date : 2026-05-25
|
||||
Statut : modèle conceptuel, pas une spec technique
|
||||
|
||||
## Thèse
|
||||
|
||||
Léa n'est pas une boîte à clics et ne doit pas rejouer un workflow. Léa est une collaboratrice visuelle mandatée.
|
||||
|
||||
Elle reçoit une fin à atteindre, choisit un protocole connu ou apprend un chemin nouveau, observe le retour de ses actions, qualifie réussite/échec/doute, puis adapte son comportement.
|
||||
|
||||
Formule centrale :
|
||||
|
||||
```text
|
||||
Un protocole est une grammaire d'action autour d'une intention.
|
||||
```
|
||||
|
||||
La différence essentielle :
|
||||
|
||||
```text
|
||||
Workflow = séquence fermée de gestes prévus.
|
||||
Protocole = grammaire ouverte qui autorise des phrases nouvelles si elles servent l'intention et sont vérifiables.
|
||||
```
|
||||
|
||||
Un logiciel, un OS ou un DPI peut changer les pixels, les titres, les boutons et les DPI. Le processus métier reste souvent stable : chercher, ouvrir, saisir, valider, enregistrer, corriger, transmettre, facturer, archiver. Léa doit apprendre ces grammaires d'action, pas mémoriser des coordonnées.
|
||||
|
||||
## Vocabulaire
|
||||
|
||||
### Mandat
|
||||
|
||||
Un mandat est une fin déléguée à Léa.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Ecris ce texte et enregistre-le.
|
||||
Trouve une vidéo de jazz et lance-la.
|
||||
Ouvre le dossier patient de Mme X.
|
||||
Saisis cette information dans le logiciel métier.
|
||||
```
|
||||
|
||||
Le mandat n'est pas une suite de clics. Il donne le but, le contexte et éventuellement les limites.
|
||||
|
||||
Un mandat peut être :
|
||||
|
||||
```text
|
||||
ponctuel : fais cette action précise maintenant ;
|
||||
de session : traite cette série de dossiers ;
|
||||
permanent : applique ce protocole dans ce périmètre habituel ;
|
||||
amendé : l'humain ajoute ou précise une intention en cours d'exécution.
|
||||
```
|
||||
|
||||
### Intention active
|
||||
|
||||
L'intention active est le sous-but courant qui sert le mandat.
|
||||
|
||||
Exemple pour `Ecris ce texte et enregistre-le` :
|
||||
|
||||
```text
|
||||
ouvrir un outil de saisie
|
||||
écrire le texte
|
||||
déclencher la sauvegarde
|
||||
choisir ou confirmer le nom
|
||||
vérifier que le fichier existe
|
||||
```
|
||||
|
||||
### Protocole d'usage
|
||||
|
||||
Un protocole d'usage est un chemin connu, adaptable, pour accomplir une intention.
|
||||
|
||||
Exemples universels :
|
||||
|
||||
```text
|
||||
ouvrir une application
|
||||
chercher sur le web
|
||||
saisir du texte
|
||||
sauvegarder un fichier
|
||||
confirmer une boîte de dialogue
|
||||
fermer une fenêtre
|
||||
copier-coller
|
||||
```
|
||||
|
||||
Exemples métier :
|
||||
|
||||
```text
|
||||
ouvrir une fiche patient
|
||||
créer une ligne de facturation
|
||||
valider une commande de stock
|
||||
rapprocher une écriture comptable
|
||||
```
|
||||
|
||||
Un protocole contient des scènes attendues, des affordances compatibles, des variantes autorisées, des conditions d'arrêt et un opérateur d'extension.
|
||||
|
||||
### Scène d'intention
|
||||
|
||||
Une scène d'intention est la situation visuelle pertinente pour l'intention courante.
|
||||
|
||||
La scène d'intention n'est pas forcément la fenêtre au focus OS. C'est la zone, fenêtre, boîte ou sous-zone qui sert le mandat maintenant.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Bloc-notes prêt à recevoir du texte.
|
||||
Fenêtre Enregistrer sous.
|
||||
Dialogue "Voulez-vous enregistrer les modifications ?".
|
||||
Page de résultats Google.
|
||||
Page vidéo YouTube.
|
||||
Fiche patient ouverte.
|
||||
Onglet "Facturation" dans une fiche patient.
|
||||
Table de mouvements dans un logiciel de stock.
|
||||
```
|
||||
|
||||
### Scène composée
|
||||
|
||||
Une scène peut contenir des sous-scènes.
|
||||
|
||||
Exemple DPI :
|
||||
|
||||
```text
|
||||
Fiche patient
|
||||
-> bandeau identité
|
||||
-> onglets séjour / facturation / documents
|
||||
-> liste des passages
|
||||
-> panneau de détail
|
||||
-> popup de validation
|
||||
```
|
||||
|
||||
Chaque sous-scène a ses affordances propres. Léa doit pouvoir focaliser sur la sous-scène qui sert l'intention active, au lieu de traiter toute la fenêtre comme un bloc plat.
|
||||
|
||||
### Affordance
|
||||
|
||||
Une affordance est une action proposée par la scène.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
bouton Enregistrer
|
||||
bouton Annuler
|
||||
champ Nom du fichier
|
||||
barre d'adresse
|
||||
champ de recherche
|
||||
bouton Lecture
|
||||
onglet Patient
|
||||
bouton Valider
|
||||
```
|
||||
|
||||
Léa ne doit pas seulement reconnaître une affordance. Elle doit comprendre son rôle dans la scène et sa compatibilité avec l'intention.
|
||||
|
||||
### Affordance anti-intention
|
||||
|
||||
Une affordance anti-intention est visible et actionnable, mais elle contredit l'intention active.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Annuler pendant une sauvegarde voulue.
|
||||
Ne pas enregistrer quand l'intention est de sauvegarder.
|
||||
Supprimer quand l'intention est de consulter.
|
||||
Fermer une fiche non sauvegardée quand l'intention est de valider.
|
||||
```
|
||||
|
||||
Identifier les affordances anti-intention est aussi important qu'identifier l'affordance correcte.
|
||||
|
||||
### Geste
|
||||
|
||||
Un geste est l'action concrète décidée dans une scène.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
cliquer sur Enregistrer
|
||||
taper le nom du fichier
|
||||
appuyer sur Ctrl+S
|
||||
sélectionner un résultat de recherche
|
||||
cliquer sur Lecture
|
||||
```
|
||||
|
||||
### Retour
|
||||
|
||||
Un retour est tout changement ou non-changement observé après un geste.
|
||||
|
||||
```text
|
||||
Résultat attendu obtenu -> réussite.
|
||||
Résultat contraire -> échec.
|
||||
Rien ne change -> attente, latence ou échec à qualifier.
|
||||
Nouvelle fenêtre -> événement à interpréter.
|
||||
Erreur -> rupture ou branche prévue selon le protocole.
|
||||
```
|
||||
|
||||
### Rupture
|
||||
|
||||
Une rupture est un changement de scène imprévu ou hors mandat.
|
||||
|
||||
Un échec se produit dans la scène attendue. Une rupture déplace Léa hors de la scène d'intention.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
UAC ou alerte sécurité pendant une sauvegarde.
|
||||
Popup de mise à jour navigateur pendant une saisie DPI.
|
||||
Léa Assistante prend le focus alors que l'intention porte sur Bloc-notes.
|
||||
```
|
||||
|
||||
## Doute typé
|
||||
|
||||
Le doute est un signal utile. Il doit être typé, car chaque doute appelle une réponse différente.
|
||||
|
||||
### Doute de localisation
|
||||
|
||||
```text
|
||||
Je sais quoi chercher, mais je ne sais pas où c'est.
|
||||
```
|
||||
|
||||
Réponse possible :
|
||||
|
||||
```text
|
||||
élargir la zone, changer de méthode visuelle, utiliser une ancre, explorer la sous-scène.
|
||||
```
|
||||
|
||||
### Doute d'identification
|
||||
|
||||
```text
|
||||
Je vois quelque chose, mais je ne sais pas si c'est le bon élément.
|
||||
```
|
||||
|
||||
Réponse possible :
|
||||
|
||||
```text
|
||||
vérifier le rôle dans la scène, comparer avec affordances voisines, demander si risque élevé.
|
||||
```
|
||||
|
||||
### Doute de scène
|
||||
|
||||
```text
|
||||
Je ne suis pas sûr d'être dans la bonne scène d'intention.
|
||||
```
|
||||
|
||||
Réponse possible :
|
||||
|
||||
```text
|
||||
requalifier la scène, revenir à une scène connue, demander.
|
||||
```
|
||||
|
||||
### Doute d'effet
|
||||
|
||||
```text
|
||||
Je sais quoi faire, mais je ne sais pas si ce geste produira l'effet attendu.
|
||||
```
|
||||
|
||||
Réponse possible :
|
||||
|
||||
```text
|
||||
agir si réversible et vérifiable, demander si irréversible ou sensible.
|
||||
```
|
||||
|
||||
### Doute d'intention
|
||||
|
||||
```text
|
||||
Je ne suis plus sûr du sous-but que je dois servir.
|
||||
```
|
||||
|
||||
Réponse possible :
|
||||
|
||||
```text
|
||||
arrêter la chaîne, demander à l'humain, ne pas improviser.
|
||||
```
|
||||
|
||||
## Boucle cognitive minimale
|
||||
|
||||
```text
|
||||
1. Recevoir le mandat.
|
||||
2. Déduire l'intention active.
|
||||
3. Choisir le protocole connu le plus simple.
|
||||
4. Observer la scène d'intention.
|
||||
5. Identifier les affordances et affordances anti-intention.
|
||||
6. Choisir le geste compatible avec l'intention.
|
||||
7. Formuler une hypothèse d'effet attendu.
|
||||
8. Agir.
|
||||
9. Observer le retour dans une fenêtre temporelle attendue.
|
||||
10. Qualifier : réussite, échec, attente, rupture, doute.
|
||||
11. Continuer, essayer une variante, demander de l'aide, oublier ou apprendre.
|
||||
```
|
||||
|
||||
Le point essentiel : une action n'est pas justifiée par le fait qu'un bouton existe. Elle est justifiée parce que ce bouton, dans cette scène, sert l'intention active.
|
||||
|
||||
## Contrat d'action
|
||||
|
||||
Avant d'agir, Léa doit pouvoir répondre implicitement à cinq questions :
|
||||
|
||||
```text
|
||||
Quelle intention est-ce que je sers ?
|
||||
Dans quelle scène suis-je ?
|
||||
Quelle affordance est-ce que j'utilise ?
|
||||
Pourquoi cette affordance est-elle compatible avec mon intention ?
|
||||
Quel retour est-ce que j'attends ?
|
||||
```
|
||||
|
||||
Si Léa ne peut pas produire cette justification, elle ne doit pas transformer l'action en clic opportuniste.
|
||||
|
||||
Ce contrat n'impose pas de demander à l'humain à chaque doute. Il impose que toute tentative ait une hypothèse vérifiable.
|
||||
|
||||
## Trace causale
|
||||
|
||||
Chaque geste devrait laisser une trace causale active :
|
||||
|
||||
```text
|
||||
J'ai fait G
|
||||
dans la scène S
|
||||
pour servir l'intention I
|
||||
avec l'hypothèse H
|
||||
et j'attendais le retour R
|
||||
```
|
||||
|
||||
Cette trace sert à :
|
||||
|
||||
```text
|
||||
qualifier le retour ;
|
||||
expliquer l'action à l'humain ;
|
||||
apprendre une preuve correcte ;
|
||||
éviter d'apprendre une corrélation fausse ;
|
||||
désapprendre une mauvaise leçon plus tard.
|
||||
```
|
||||
|
||||
Sans trace causale, Léa apprend des coïncidences. Avec trace causale, elle apprend des gestes situés.
|
||||
|
||||
## Temporalité attendue
|
||||
|
||||
Un protocole doit porter une attente temporelle approximative.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
un clic bouton local doit produire un changement en 100 ms à 2 s ;
|
||||
une ouverture d'application peut prendre plusieurs secondes ;
|
||||
une recherche web peut prendre plus longtemps selon le réseau ;
|
||||
une sauvegarde locale doit généralement fermer la boîte rapidement ;
|
||||
un DPI legacy peut avoir des latences longues et variables.
|
||||
```
|
||||
|
||||
`Rien ne change` n'est pas automatiquement un échec. C'est un retour à qualifier selon :
|
||||
|
||||
```text
|
||||
le protocole ;
|
||||
la scène ;
|
||||
le délai habituel ;
|
||||
les indicateurs de chargement ;
|
||||
les répétitions ;
|
||||
le risque du geste suivant.
|
||||
```
|
||||
|
||||
## Autonomie
|
||||
|
||||
L'autonomie de Léa est une autonomie d'initiative, pas une autonomie d'entêtement.
|
||||
|
||||
Léa peut :
|
||||
|
||||
```text
|
||||
choisir le chemin le plus simple ;
|
||||
changer de chemin si le premier échoue ;
|
||||
essayer une variante cohérente ;
|
||||
interpréter un retour ;
|
||||
demander de l'aide ;
|
||||
apprendre après aide ou résultat qualifié.
|
||||
```
|
||||
|
||||
Léa ne doit pas :
|
||||
|
||||
```text
|
||||
agir coûte que coûte ;
|
||||
inventer une réussite ;
|
||||
apprendre un échec comme une réussite ;
|
||||
continuer un fallback après rejet sémantique ;
|
||||
sortir d'un protocole sans raison explicable.
|
||||
```
|
||||
|
||||
Le risque n'est pas interdit. Il doit être exploitable :
|
||||
|
||||
```text
|
||||
observable
|
||||
attribuable à une intention
|
||||
réversible si possible
|
||||
évaluable après coup
|
||||
transformable en apprentissage
|
||||
```
|
||||
|
||||
## Extension de grammaire
|
||||
|
||||
Cette section distingue un protocole d'un workflow.
|
||||
|
||||
Si Léa trouve une affordance compatible avec l'intention mais absente du protocole connu, elle peut former une hypothèse :
|
||||
|
||||
```text
|
||||
Cette affordance A, dans la scène S, semble servir l'intention I.
|
||||
Si j'effectue le geste G, j'attends le retour R.
|
||||
```
|
||||
|
||||
Elle peut essayer si :
|
||||
|
||||
```text
|
||||
le geste est réversible ou faiblement risqué ;
|
||||
le retour attendu est observable ;
|
||||
la scène est compatible avec le mandat ;
|
||||
le doute n'est pas un doute d'intention ;
|
||||
le mandat n'exige pas confirmation explicite.
|
||||
```
|
||||
|
||||
Après essai :
|
||||
|
||||
```text
|
||||
si R arrive -> affordance candidate à apprentissage ;
|
||||
si R n'arrive pas -> affordance marquée incompatible ou incertaine ;
|
||||
si effet négatif -> correction / rollback / demande humaine ;
|
||||
si doute persiste -> ne pas apprendre comme réussite.
|
||||
```
|
||||
|
||||
Cette capacité d'extension empêche le protocole de devenir un workflow figé.
|
||||
|
||||
## Structure conceptuelle d'un protocole
|
||||
|
||||
Un protocole peut se décrire sur un coin de papier avec les éléments suivants :
|
||||
|
||||
```text
|
||||
Nom
|
||||
Intention servie
|
||||
Préconditions plausibles
|
||||
Scènes attendues
|
||||
Sous-scènes possibles
|
||||
Affordances compatibles par scène
|
||||
Affordances anti-intention
|
||||
Gestes possibles
|
||||
Variantes autorisées
|
||||
Retours attendus
|
||||
Temporalité attendue
|
||||
Branches normales
|
||||
Ruptures connues
|
||||
Doutes possibles et réponses associées
|
||||
Conditions de réussite
|
||||
Conditions d'abstention ou demande d'aide
|
||||
Opérateur d'extension de grammaire
|
||||
Preuves apprenables
|
||||
Conditions de désapprentissage
|
||||
```
|
||||
|
||||
## Preuve apprenable
|
||||
|
||||
Une preuve apprenable est un retour qui peut être conservé au-delà de la session parce qu'il est fiable et généralisable.
|
||||
|
||||
Une preuve apprenable doit être :
|
||||
|
||||
```text
|
||||
attribuable causalement à un geste ;
|
||||
observée dans une scène typée ;
|
||||
liée à une intention active ;
|
||||
qualifiée comme réussite, échec ou incompatibilité ;
|
||||
reproductible ou vérifiable dans une scène similaire ;
|
||||
non contredite par une correction humaine ou un rollback.
|
||||
```
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Dans cette boîte "Enregistrer sous", le bouton "Enregistrer" valide la sauvegarde.
|
||||
Dans ce DPI, le champ "IPP" sert à chercher un patient.
|
||||
Dans cette page YouTube, cliquer sur cette vignette ouvre une vidéo.
|
||||
Dans cette popup, "Ne pas enregistrer" contredit l'intention de sauvegarde.
|
||||
```
|
||||
|
||||
Une observation n'est pas forcément une preuve apprenable. Un effet peut être accidentel, ambigu ou causé par l'humain.
|
||||
|
||||
## Correction, démonstration, apprentissage
|
||||
|
||||
L'aide humaine peut avoir plusieurs statuts.
|
||||
|
||||
### Correction
|
||||
|
||||
L'humain corrige une erreur dans une situation précise.
|
||||
|
||||
```text
|
||||
Tu t'es trompée de bouton. Ici il fallait cliquer sur Enregistrer.
|
||||
```
|
||||
|
||||
Effet :
|
||||
|
||||
```text
|
||||
réparer ou invalider une preuve locale ;
|
||||
ne pas créer automatiquement un protocole générique.
|
||||
```
|
||||
|
||||
### Démonstration
|
||||
|
||||
L'humain enseigne une nouvelle compétence ou un nouveau chemin.
|
||||
|
||||
```text
|
||||
Regarde, dans ce DPI, pour ouvrir un patient, je fais recherche -> IPP -> entrée -> fiche.
|
||||
```
|
||||
|
||||
Effet :
|
||||
|
||||
```text
|
||||
créer ou enrichir un protocole applicatif ;
|
||||
capturer scènes, affordances, gestes, retours.
|
||||
```
|
||||
|
||||
### Validation
|
||||
|
||||
L'humain confirme qu'une hypothèse de Léa est correcte.
|
||||
|
||||
```text
|
||||
Oui, ce bouton Valider correspond bien à sauvegarder la fiche.
|
||||
```
|
||||
|
||||
Effet :
|
||||
|
||||
```text
|
||||
promouvoir une affordance candidate en preuve apprenable.
|
||||
```
|
||||
|
||||
## Désapprentissage
|
||||
|
||||
Léa doit pouvoir oublier ou dégrader une leçon.
|
||||
|
||||
Une preuve doit être invalidée si :
|
||||
|
||||
```text
|
||||
elle provoque un échec répété ;
|
||||
elle est contredite par l'humain ;
|
||||
elle ne marche que dans une scène plus étroite que prévu ;
|
||||
elle a été apprise après un retour ambigu ;
|
||||
elle a été associée à la mauvaise intention ;
|
||||
elle dépendait d'une correction humaine non identifiée.
|
||||
```
|
||||
|
||||
Désapprendre ne veut pas forcément supprimer. Cela peut vouloir dire :
|
||||
|
||||
```text
|
||||
réduire la confiance ;
|
||||
restreindre le périmètre ;
|
||||
marquer comme spécifique à une scène ;
|
||||
mettre en quarantaine jusqu'à validation ;
|
||||
supprimer si dangereux.
|
||||
```
|
||||
|
||||
## Mode exploration
|
||||
|
||||
Dans un environnement inconnu, Léa peut observer sans agir pour cartographier les scènes et affordances.
|
||||
|
||||
Objectif :
|
||||
|
||||
```text
|
||||
identifier les zones principales ;
|
||||
nommer les sous-scènes ;
|
||||
repérer les affordances ;
|
||||
relier les affordances à des intentions possibles ;
|
||||
détecter les actions sensibles ;
|
||||
préparer une démonstration ou un essai vérifiable.
|
||||
```
|
||||
|
||||
Le mode exploration évite deux excès :
|
||||
|
||||
```text
|
||||
agir sans cartographie ;
|
||||
se bloquer parce que rien n'est connu.
|
||||
```
|
||||
|
||||
## Adaptateurs métier
|
||||
|
||||
La généralisation métier ne supprime pas les spécificités éditeur.
|
||||
|
||||
Un DPI, un ERP, une comptabilité ou une gestion de stock exposent des processus semblables, mais chaque éditeur a ses scènes, libellés, latences, contraintes et pièges.
|
||||
|
||||
Le bon modèle est :
|
||||
|
||||
```text
|
||||
protocole métier générique
|
||||
-> adaptateur applicatif par éditeur/client
|
||||
-> preuves locales par écran/version/DPI
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```text
|
||||
Chercher un patient
|
||||
-> protocole métier DPI
|
||||
-> adaptateur Easily / Maincare / Cerner / autre
|
||||
-> preuves locales du site client
|
||||
```
|
||||
|
||||
## Carnet de bord narratif
|
||||
|
||||
Léa devrait conserver un fil narratif par mandat.
|
||||
|
||||
Ce fil n'est pas un log technique. C'est l'explication utilisateur :
|
||||
|
||||
```text
|
||||
J'ai ouvert Bloc-notes.
|
||||
J'ai saisi le texte demandé.
|
||||
J'ai déclenché la sauvegarde avec Ctrl+S.
|
||||
J'ai vu "Enregistrer sous".
|
||||
J'ai confirmé le nom du fichier.
|
||||
La sauvegarde a réussi car le fichier existe et le contenu est présent.
|
||||
```
|
||||
|
||||
En cas de blocage :
|
||||
|
||||
```text
|
||||
Je voulais enregistrer, mais une fenêtre inconnue est apparue.
|
||||
Je ne sais pas si elle appartient à la sauvegarde.
|
||||
J'ai besoin d'aide pour qualifier cette scène.
|
||||
```
|
||||
|
||||
Ce carnet sert à la confiance, au debug, à la formation et à l'amélioration continue.
|
||||
|
||||
## Exemple 1 : ouvrir un logiciel
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Ouvre Bloc-notes.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
rendre disponible un outil de saisie texte simple
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
menu Démarrer / recherche Windows
|
||||
raccourci existant
|
||||
commande Exécuter
|
||||
barre de recherche système
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
bureau ou environnement de départ
|
||||
menu/recherche d'application
|
||||
résultat "Bloc-notes"
|
||||
fenêtre Bloc-notes ouverte
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
champ de recherche
|
||||
résultat d'application Bloc-notes
|
||||
zone de texte vide
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
une fenêtre de saisie texte apparaît
|
||||
elle accepte le focus
|
||||
elle permet de taper du texte
|
||||
```
|
||||
|
||||
Variantes :
|
||||
|
||||
```text
|
||||
si la recherche Windows échoue, essayer Exécuter/notepad
|
||||
si un autre éditeur texte est disponible et accepté par le mandat, l'utiliser
|
||||
si aucune scène d'édition texte n'apparaît, demander ou apprendre
|
||||
```
|
||||
|
||||
## Exemple 2 : saisir un texte
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Saisis "testtesttest".
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
placer le contenu texte dans une zone éditable
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
éditeur texte ouvert
|
||||
champ texte actif
|
||||
curseur visible ou zone éditable détectée
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
zone de saisie
|
||||
document vide ou modifiable
|
||||
```
|
||||
|
||||
Gestes :
|
||||
|
||||
```text
|
||||
focus zone éditable si nécessaire
|
||||
taper le texte
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
le texte apparaît
|
||||
le contenu correspond au mandat
|
||||
```
|
||||
|
||||
Ruptures :
|
||||
|
||||
```text
|
||||
zone non éditable
|
||||
fenêtre inattendue
|
||||
texte non apparu
|
||||
application fermée
|
||||
```
|
||||
|
||||
## Exemple 3 : enregistrer un fichier
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Enregistre le texte saisi.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
persister le contenu courant dans un fichier
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
Ctrl+S
|
||||
menu Fichier > Enregistrer
|
||||
bouton Enregistrer si visible
|
||||
Enregistrer sous si le fichier n'a pas encore de nom
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
éditeur texte avec contenu non sauvegardé
|
||||
dialogue Enregistrer sous
|
||||
dialogue "voulez-vous enregistrer les modifications ?"
|
||||
dialogue "le fichier existe déjà, voulez-vous le remplacer ?"
|
||||
retour à l'éditeur avec état sauvegardé
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
Enregistrer
|
||||
Oui
|
||||
Remplacer, si le mandat autorise l'écrasement
|
||||
champ Nom du fichier
|
||||
```
|
||||
|
||||
Affordances anti-intention :
|
||||
|
||||
```text
|
||||
Annuler
|
||||
Ne pas enregistrer
|
||||
Non, si la question porte sur la sauvegarde souhaitée
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
la boîte de sauvegarde se ferme
|
||||
le fichier existe à l'emplacement choisi
|
||||
le contenu est présent
|
||||
le document n'est plus en état non sauvegardé
|
||||
```
|
||||
|
||||
Règle clé :
|
||||
|
||||
```text
|
||||
Voir un bouton "Enregistrer" ne suffit pas.
|
||||
Il faut que ce bouton soit dans une scène compatible avec l'intention de sauvegarde.
|
||||
```
|
||||
|
||||
## Exemple 4 : regarder une vidéo de jazz
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Trouve et lance une vidéo de jazz.
|
||||
```
|
||||
|
||||
Intention :
|
||||
|
||||
```text
|
||||
obtenir une vidéo en lecture correspondant au thème jazz
|
||||
```
|
||||
|
||||
Protocoles possibles :
|
||||
|
||||
```text
|
||||
ouvrir navigateur -> YouTube -> chercher jazz -> lancer une vidéo
|
||||
ouvrir navigateur -> moteur de recherche -> "video jazz" -> ouvrir un résultat vidéo
|
||||
utiliser une application ou un favori connu si disponible
|
||||
```
|
||||
|
||||
Scènes attendues :
|
||||
|
||||
```text
|
||||
navigateur ouvert
|
||||
barre d'adresse ou champ de recherche
|
||||
page de résultats
|
||||
page vidéo
|
||||
lecteur avec bouton Lecture ou vidéo déjà en lecture
|
||||
```
|
||||
|
||||
Affordances compatibles :
|
||||
|
||||
```text
|
||||
barre d'adresse
|
||||
champ de recherche
|
||||
résultat vidéo pertinent
|
||||
bouton Lecture
|
||||
```
|
||||
|
||||
Retours attendus :
|
||||
|
||||
```text
|
||||
une vidéo démarre
|
||||
le contenu semble lié au jazz
|
||||
le son ou la lecture est active si observable
|
||||
```
|
||||
|
||||
Variantes :
|
||||
|
||||
```text
|
||||
si YouTube est inaccessible, utiliser le moteur de recherche
|
||||
si le premier résultat n'est pas pertinent, revenir et choisir un autre résultat
|
||||
si un consentement cookie bloque la scène, traiter le dialogue seulement s'il est compatible avec la navigation
|
||||
```
|
||||
|
||||
## Exemple 5 : facturer un passage aux urgences
|
||||
|
||||
Mandat :
|
||||
|
||||
```text
|
||||
Facture le passage de Mme MOREL du 12/05 aux urgences.
|
||||
```
|
||||
|
||||
Intentions enchaînées :
|
||||
|
||||
```text
|
||||
ouvrir le logiciel métier
|
||||
chercher la patiente
|
||||
ouvrir la bonne fiche
|
||||
identifier le passage du 12/05
|
||||
ouvrir la scène de facturation
|
||||
contrôler les informations nécessaires
|
||||
valider la facturation
|
||||
vérifier que le statut est facturé ou prêt à transmettre
|
||||
```
|
||||
|
||||
Scènes composées :
|
||||
|
||||
```text
|
||||
écran d'accueil DPI
|
||||
recherche patient
|
||||
liste de résultats
|
||||
fiche patient
|
||||
liste des passages
|
||||
onglet facturation
|
||||
dialogue de validation
|
||||
```
|
||||
|
||||
Exemples de doutes :
|
||||
|
||||
```text
|
||||
doute d'identification patient si plusieurs homonymes ;
|
||||
doute de scène si l'onglet ouvert n'est pas la facturation ;
|
||||
doute d'effet si le bouton Valider ne précise pas ce qu'il valide ;
|
||||
doute d'intention si le mandat ne précise pas quoi faire en cas de données manquantes.
|
||||
```
|
||||
|
||||
## Généralisation multi-environnements
|
||||
|
||||
Léa doit apprendre à plusieurs niveaux.
|
||||
|
||||
### Niveau 1 : mémoire locale
|
||||
|
||||
```text
|
||||
Dans cet écran précis, ce bouton sauvegarde.
|
||||
Dans ce DPI, cette scène ressemble à Save As.
|
||||
Dans ce logiciel, ce champ est le champ de recherche patient.
|
||||
```
|
||||
|
||||
### Niveau 2 : protocole applicatif
|
||||
|
||||
```text
|
||||
Dans ce logiciel DPI, ouvrir un dossier patient passe par recherche -> liste -> fiche.
|
||||
Dans ce logiciel comptable, valider une écriture passe par saisie -> contrôle -> validation.
|
||||
```
|
||||
|
||||
### Niveau 3 : protocole métier
|
||||
|
||||
```text
|
||||
Tous les DPI ont une façon de chercher un patient, ouvrir sa fiche, saisir une information, valider et tracer.
|
||||
Tous les logiciels de stock ont une façon de rechercher un article, ajuster une quantité, valider un mouvement.
|
||||
Tous les logiciels comptables ont une façon de saisir, contrôler, rapprocher, valider.
|
||||
```
|
||||
|
||||
### Niveau 4 : protocole universel
|
||||
|
||||
```text
|
||||
chercher
|
||||
ouvrir
|
||||
saisir
|
||||
valider
|
||||
annuler
|
||||
enregistrer
|
||||
confirmer
|
||||
revenir
|
||||
fermer
|
||||
```
|
||||
|
||||
La généralisation consiste à relier les preuves locales à ces niveaux supérieurs.
|
||||
|
||||
## Questions ouvertes restantes
|
||||
|
||||
1. Quel vocabulaire final garder : protocole d'usage, geste type, routine intentionnelle ?
|
||||
2. Comment exprimer à l'utilisateur le mandat courant sans jargon ?
|
||||
3. Quelles familles de protocoles universels faut-il inscrire en premier ?
|
||||
4. Comment demander de l'aide sans transformer l'humain en téléopérateur ?
|
||||
5. Comment capturer l'apprentissage métier sans mémoriser des informations sensibles ?
|
||||
6. Comment arbitrer une affordance nouvelle compatible mais située dans une action sensible ?
|
||||
7. Comment représenter un mandat amendé sans perdre la trace causale initiale ?
|
||||
|
||||
## Synthèse courte
|
||||
|
||||
```text
|
||||
Léa reçoit un mandat.
|
||||
Elle choisit un protocole.
|
||||
Elle observe une scène d'intention.
|
||||
Elle interprète les affordances et les anti-affordances.
|
||||
Elle agit avec une hypothèse.
|
||||
Elle qualifie le retour dans le temps attendu.
|
||||
Elle apprend uniquement d'une preuve qualifiée.
|
||||
Elle peut étendre sa grammaire, corriger ou désapprendre.
|
||||
```
|
||||
|
||||
Cette structure permet de viser la généralisation : mêmes intentions, scènes différentes, logiciels différents, DPI différents, OS différents.
|
||||
@@ -0,0 +1,146 @@
|
||||
# Modèle Mandat / Protocoles / Scènes — v0.3 arbitrages Dom
|
||||
|
||||
Date : 2026-05-25
|
||||
Statut : cadrage conceptuel avec arbitrages utilisateur
|
||||
Base : `MODELE_MANDAT_PROTOCOLS_LEA_2026-05-25_v0.2.md`
|
||||
|
||||
## Arbitrage 1 — priorité entre protocoles
|
||||
|
||||
Quand plusieurs protocoles peuvent servir la même intention, Léa choisit le chemin le plus simple selon une priorité pondérée :
|
||||
|
||||
```text
|
||||
mieux connu
|
||||
-> moins risqué
|
||||
-> plus court
|
||||
```
|
||||
|
||||
Interprétation :
|
||||
|
||||
```text
|
||||
mieux connu = le protocole possède les preuves qualifiées les plus solides ;
|
||||
moins risqué = le geste est réversible, observable, et dans le niveau de délégation accordé ;
|
||||
plus court = moins de gestes ou moins de latence attendue.
|
||||
```
|
||||
|
||||
Exemple :
|
||||
|
||||
```text
|
||||
Pour sauvegarder :
|
||||
Ctrl+S est prioritaire si l'éditeur est connu et l'état attendu vérifié.
|
||||
Menu Fichier > Enregistrer reste une variante si Ctrl+S échoue ou n'est pas disponible.
|
||||
```
|
||||
|
||||
## Arbitrage 2 — préconditions plausibles
|
||||
|
||||
Dom reformule simplement :
|
||||
|
||||
```text
|
||||
Léa doit vérifier l'état qu'elle attend.
|
||||
```
|
||||
|
||||
Une précondition plausible est donc un état attendu vérifiable avant de tenter un protocole ou un geste.
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Pour saisir du texte :
|
||||
je dois voir ou déduire une zone éditable focusable.
|
||||
|
||||
Pour enregistrer :
|
||||
je dois être dans une application qui contient un contenu à sauvegarder,
|
||||
ou dans une boîte de dialogue qui appartient à la sauvegarde.
|
||||
|
||||
Pour cliquer "Enregistrer" :
|
||||
je dois être dans une scène d'intention compatible avec la sauvegarde,
|
||||
pas simplement voir le mot "Enregistrer" n'importe où.
|
||||
|
||||
Pour ouvrir une fiche patient :
|
||||
je dois être dans une scène de recherche/liste/fiche compatible avec le DPI.
|
||||
```
|
||||
|
||||
La précondition évite l'essai voué à l'échec. Elle ne rend pas Léa prudente par défaut ; elle lui donne un état de référence.
|
||||
|
||||
## Arbitrage 3 — niveau de risque et autonomie tutorée
|
||||
|
||||
Dom précise que le niveau de risque ne doit pas être uniquement une catégorie abstraite codée à l'avance. Il dépend aussi du niveau réel de Léa évalué par son collaborateur/tuteur.
|
||||
|
||||
Principe :
|
||||
|
||||
```text
|
||||
Léa devient autonome sur un périmètre quand le collaborateur estime qu'elle est au bon niveau.
|
||||
```
|
||||
|
||||
Cela rapproche Léa d'un humain en apprentissage :
|
||||
|
||||
```text
|
||||
au début, le tuteur laisse faire certaines actions simples ;
|
||||
puis il élargit le périmètre quand les preuves s'accumulent ;
|
||||
sur un protocole maîtrisé, le risque pratique devient très faible ;
|
||||
sur un nouveau logiciel métier, l'apprentissage recommence sur ce périmètre.
|
||||
```
|
||||
|
||||
Le risque doit donc être modélisé comme :
|
||||
|
||||
```text
|
||||
risque intrinsèque du geste
|
||||
+ sensibilité métier
|
||||
+ maturité de Léa sur ce protocole
|
||||
+ maturité de Léa dans cet environnement
|
||||
+ mandat explicitement donné par l'humain
|
||||
```
|
||||
|
||||
Exemples :
|
||||
|
||||
```text
|
||||
Cliquer dans une zone de texte : risque intrinsèque mineur.
|
||||
Valider une facture : risque métier majeur si Léa n'est pas tutorée sur ce protocole.
|
||||
Valider une facture dans un protocole déjà démontré, dans un mandat de session explicite : risque pratique réduit.
|
||||
Supprimer ou transmettre à l'extérieur : reste sensible, même avec maturité élevée.
|
||||
```
|
||||
|
||||
## Niveau de délégation
|
||||
|
||||
On remplace donc une vision statique `low/medium/high` par une notion de délégation tutorée :
|
||||
|
||||
```text
|
||||
Niveau 0 — observation : Léa regarde, cartographie, ne fait pas.
|
||||
Niveau 1 — proposition : Léa propose le geste, l'humain valide.
|
||||
Niveau 2 — exécution supervisée : Léa agit sur gestes réversibles, demande sur doute.
|
||||
Niveau 3 — autonomie de session : Léa agit dans un mandat explicite borné.
|
||||
Niveau 4 — autonomie habituelle : Léa agit seule sur protocole connu et environnement maîtrisé.
|
||||
```
|
||||
|
||||
Ce niveau peut être différent selon :
|
||||
|
||||
```text
|
||||
le protocole ;
|
||||
le logiciel ;
|
||||
le client ;
|
||||
le type de donnée ;
|
||||
le collaborateur/tuteur ;
|
||||
la période d'apprentissage.
|
||||
```
|
||||
|
||||
## Effet sur le modèle v0.2
|
||||
|
||||
La boucle devient :
|
||||
|
||||
```text
|
||||
Mandat
|
||||
-> intention active
|
||||
-> protocoles candidats
|
||||
-> choix : mieux connu / moins risqué / plus court
|
||||
-> vérification des préconditions attendues
|
||||
-> observation scène d'intention
|
||||
-> affordance compatible
|
||||
-> geste avec hypothèse de retour
|
||||
-> qualification du retour
|
||||
-> apprentissage ou désapprentissage
|
||||
-> ajustement du niveau de délégation
|
||||
```
|
||||
|
||||
## Point clé
|
||||
|
||||
L'autonomie n'est pas l'absence de risque. L'autonomie est la capacité de prendre des initiatives proportionnées à un mandat, un niveau de preuve et un niveau de délégation.
|
||||
|
||||
Le risque utile est celui qui produit de l'apprentissage qualifié.
|
||||
Reference in New Issue
Block a user