# Parcours dans les wireframes d'AMI Care

Trois parcours pas à pas, qui renvoient aux wireframes de ce dossier (`png/` pour les images, `ecrans/` pour les pages HTML navigables, `index.html` pour la vue d'ensemble). Ils reprennent les journées de la section 3 d'[APP_GESTION.md](../APP_GESTION.md) ; les patients (Lena M., Marco R., Sofia K., Ana P.…) et le Dr Deniz Aksoy sont fictifs. En fin de document : les frictions et les incohérences relevées dans [ECRANS.yaml](../ECRANS.yaml).

## 1. Sibel, commerciale

| Étape | Ce que fait Sibel | Écran | Ce que le wireframe règle |
| --- | --- | --- | --- |
| 1 | 07:45, elle ouvre l'application depuis la notification « 6 drafts to validate » (sans nom ni texte de santé). | [E-02 My work](png/E-02-my-work-mobile.png) | Tout ce qui l'attend sur un écran, par urgence ; « Review all drafts (6) » en action principale. |
| 2 | Elle enchaîne les brouillons : message de Lena traduit en français et original allemand, réponse proposée en français, aperçu allemand, sources, contrôles. Elle valide d'un geste ; « Sending in 8 s · Undo » lui laisse le temps de se raviser. | [E-06 Validation queue](png/E-06-validation-queue-mobile.png) · [ordinateur](png/E-06-validation-queue-desktop.png) | Pas besoin d'ouvrir chaque conversation ; le repère « Context changed: goal edited by Sibel at 08:12 · draft refreshed » dit que le brouillon tient compte de sa dernière modification. |
| 3 | Sur le relais de prix de Sofia, elle ouvre le fil : historique e-mail et WhatsApp, repères du dossier, brouillon dans le fil. Pour répondre elle-même, « Take over ». | [E-04 Conversation](png/E-04-conversation-mobile.png) · [ordinateur](png/E-04-conversation-desktop.png) | Qui a la main se lit en haut du fil (« Agent drives ») ; la fenêtre WhatsApp restante aussi. |
| 4 | Après son appel à Sofia, elle dicte quarante secondes ; l'agent propose le résumé et trois mises à jour, qu'elle accepte ou corrige. | [E-37 Log a call](png/E-37-log-a-call-mobile.png) | Aucune ressaisie ; chaque mise à jour s'accepte séparément. |
| 5 | Sur le dossier de Lena, elle corrige l'objectif (« two implants, lower jaw »). | [E-07 / E-09 Case](png/E-09-case-goal-mobile.png) · [ordinateur](png/E-09-case-goal-desktop.png) | Trois temps annotés : édition sur place, « Saved · Undo », puis la confirmation de l'agent (« Noted: … »), avec l'ancienne valeur et sa provenance dans l'historique. |
| 6 | Elle crée la version 2 du projet de Sofia : les accords de la version 1 sont barrés, le praticien a déjà approuvé la v2, le réceptif pas encore. | [E-11 Proposal](png/E-11-proposal-approvals-mobile.png) · [ordinateur](png/E-11-proposal-approvals-desktop.png) | « Order sending » reste grisé tant que les trois accords ne portent pas sur la même version, et l'écran dit lequel manque. |
| 7 | Midi, elle filtre « Mine · inactive > 3 days » sur le kanban et veut passer Lena en « Case ready ». | [E-17 Pipelines](png/E-17-pipelines-mobile.png) · [ordinateur](png/E-17-pipelines-desktop.png) | La transition refusée dit ce qui manque (photo de profil gauche) et propose d'attendre, de déclarer la pièce « not required » avec motif, ou de le suggérer au responsable. |
| 8 | L'après-midi, elle trie la boîte par vues enregistrées. | [E-03 Inbox](png/E-03-inbox-mobile.png) · [ordinateur](png/E-03-inbox-desktop.png) | Une ligne par contact : aperçu en français, état, qui a la main, brouillon ou relais, fenêtre ; « templates only » quand la fenêtre est fermée. |

## 2. Ayşenur et Hülya, réceptif

| Étape | Ce qu'elles font | Écran | Ce que le wireframe règle |
| --- | --- | --- | --- |
| 1 | 06:30, la journée : arrivée de Marco (vol retardé de 35 min, porte B4, chauffeur), consultation de Lena, contrôle de Sofia, message de veille d'Ana à 18:00. | [E-19 Today in Istanbul](png/E-19-today-mobile.png) · [ordinateur](png/E-19-today-desktop.png) | Tout part de la frise du jour ; chaque carte a ses gestes (Call, Map, Open stay, Send now). |
| 2 | Elle décale le transfert et ouvre la fiche séjour de Marco. | [E-20 Stay sheet](png/E-20-stay-sheet-mobile.png) | Listes de contrôle en ordre libre (A8) ; le solde « awaiting finance » se voit avant l'aéroport. |
| 3 | 10:25, à l'aéroport, « Mark arrived ». | [E-20 Stay sheet](png/E-20-stay-sheet-mobile.png) | Le solde n'est pas confirmé : le fait est enregistré tout de suite et la dérogation part à Alexis et Olivier (EX-220), qui la décident depuis [E-23](png/E-23-dashboard-mobile.png). |
| 4 | 11:30, Hülya répond à Marco : la conversation passe en main humaine ; hors réseau, le message reste « pending » avec Retry ; le message programmé de l'agent propose Send, Postpone ou Skip. Le soir, elle rend la main avec une note. | [E-04 human control](png/E-04-human-control-mobile.png) | La main humaine est affichée en permanence ; la note pour l'agent se saisit au moment de rendre la main. |
| 5 | 15:10, alerte sur Sofia : acquitter, appeler, noter la conduite tenue, clore. | [E-16 Alert](png/E-16-alert-mobile.png) | « Acknowledge » en premier ; résumé en français et traduction automatique en anglais ; « Close alert » grisé tant que la conduite tenue n'est pas notée. |

## 3. Le praticien

| Étape | Ce que fait le Dr Aksoy | Écran | Ce que le wireframe règle |
| --- | --- | --- | --- |
| 1 | Il ouvre la notification « New case to review » par son lien personnel. | [E-21 My cases](png/E-21-my-cases-mobile.png) | Cinq sections seulement (à revoir, projets, interventions, alertes, photos de suivi), avec l'échéance. |
| 2 | Il lit la synthèse traduite et le point d'attention (anticoagulant déclaré), regarde les pièces en grand et les compare. | [E-22 Case review](png/E-22-case-review-mobile.png) · [ordinateur](png/E-22-case-review-desktop.png) | Seul ce qui sert à décider ; pièces en plein écran, sans téléchargement. |
| 3 | Il demande une imagerie 3D, puis approuve la version 1 du projet. | [E-22 Case review](png/E-22-case-review-mobile.png) | « Request document » crée la note d'équipe ; l'avis sur le projet tient en un geste ; « Not eligible… » reste discret et demande un motif. |

Les autres rôles ont leur écran d'accueil dessiné : Alexis sur [E-23 Dashboard](png/E-23-dashboard-desktop.png), Tom sur [E-26 Agent supervision](png/E-26-supervision-desktop.png) et, pendant les tests, [E-38 Test console](png/E-38-test-console-desktop.png). Les 21 autres écrans sont sur la [planche récapitulative](png/planche-autres-ecrans.png).

## 4. Frictions et incohérences relevées dans ECRANS.yaml

Classées par effet sur le parcours. Chacune est une proposition, à trancher avec Tom.

1. **Le réceptif n'a pas d'accès direct à sa file de validation.** E-05 et E-06 lui donnent le droit de valider les messages des séquences 5 et 6 (QA-05), mais ses onglets (Today, Inbox, Cases, Alerts, More) ne mènent ni à E-02 ni à E-06, et E-19 ne montre que les messages programmés. Proposition : une section « Drafts to validate » dans E-19, ou un compteur sur l'onglet Inbox qui ouvre E-06 filtrée.
2. **L'onglet « Cases » du réceptif ne correspond à aucun écran.** La navigation le prévoit, les 39 écrans n'en définissent pas. Proposition : E-17 filtré sur les tableaux Receptive, On site et Follow-up, ou une liste dédiée.
3. **E-20 n'a pas les gestes d'état.** La fiche séjour est « tout ce qu'il faut à l'aéroport », mais « Mark arrived », « Procedure done » et « Returned » ne figurent que dans E-12 et E-19. Le wireframe E-20 ajoute « Mark arrived » ; à reporter dans le YAML.
4. **Boîte de réception sur ordinateur.** E-03 y est défini comme « colonne de gauche de E-04 » : 300 px ne suffisent pas pour trier 100 à 200 contacts (état, main, fenêtre, responsable). Le wireframe propose une vue tableau pleine largeur, qui ouvre E-04 en trois colonnes.
5. **Brouillon dans le fil.** E-05 liste toujours le message du patient dans la carte ; dans E-04, ce message est juste au-dessus. Le wireframe l'affiche en entier dans E-06 et le réduit à « Replying to Lena's message of 23:14 » dans le fil.
6. **Jugement d'une pièce par le praticien.** E-22 propose « Accept / Insufficient » sans dire sur quelle pièce ; au téléphone, le geste doit se faire pièce par pièce dans la visionneuse (C27), avec le motif d'« Insufficient ».
7. **Ordre des trois accords.** D-012 fait de Sibel l'« accord final », mais E-11 laisse les trois rôles approuver dans n'importe quel ordre. À décider : Sibel peut-elle approuver avant le réceptif et le praticien ? Le wireframe marque « Sibel (final) » sans bloquer.
8. **« Move to… » sur le kanban mobile.** Rien ne dit que la liste ne montre que les transitions permises au rôle. Proposition : ne lister que les états atteignables, les autres grisés avec leur raison, comme la fenêtre C16.
9. **Arrêt d'urgence sur l'accueil.** La zone « status » d'E-02 mentionne l'arrêt d'urgence, mais E-02 ne définit ni l'action, ni ses rôles, ni sa confirmation (qui existent dans E-23 et E-26). Au pouce, un arrêt mal placé se déclenche par erreur : bouton secondaire, confirmation et nouvelle authentification, comme dans E-26.
10. **Niveaux d'autonomie.** E-26 affiche trois niveaux par séquence ; un sélecteur direct laisserait croire qu'un clic suffit, alors que « Change level » exige une décision `D` et une nouvelle authentification. Le wireframe garde le niveau en lecture et passe par « Change level… ».
11. **Langue de l'interface.** Les libellés anglais côtoient le français de l'agent partout où Sibel travaille (« Draft to validate » au-dessus d'une réponse en français) : c'est lisible, mais la locale française de l'interface (QA-07) réduirait la charge pour Sibel.
12. **Plusieurs envois en attente.** Avec un délai d'annulation de 10 s par envoi, une validation rapide empile plusieurs « Sending in… » ; le toast ne montre que le dernier. Proposition : un compteur « 2 sending · Undo last ».
13. **« Take over » depuis la liste.** E-03 permet de prendre la main sans ouvrir le fil (take_over_row) ; sans confirmation, un geste involontaire retire les brouillons. Proposition : confirmation ou « Undo ».
14. **Testeurs visibles.** E-38 donne à Sibel un accès « L E (test) », alors que le YAML précise que le champ Tester ne lui est jamais montré ; la colonne « Actors » de la console doit alors être masquée pour elle.
15. **« Log a call » pour le praticien.** E-37 lui ouvre l'écriture, mais son seul point d'entrée prévu est E-04 ou E-07, auxquels il n'a pas accès ; à ajouter dans E-22 ou à retirer de ses droits.
16. **Détail des données d'exemple.** Dans APP_GESTION (3.2), Sofia K., Polonaise, écrit en français au moment de l'alerte ; sans importance pour les écrans, mais à harmoniser si les parcours servent de scénarios de test.

## 5. Fabrication

- `_source/generer.py` écrit les pages de `ecrans/` (29 wireframes : 12 écrans en mobile et en ordinateur, 5 variantes mobiles) et la planche des 21 autres écrans, tirée d'ECRANS.yaml ; `_source/index_source.py` écrit `index.html`.
- `_source/export.cjs` exporte les PNG avec Chromium (`/opt/claude-code/paf-heavy node _source/export.cjs`) et vérifie chaque page : cibles tactiles de 44 px au moins sur mobile, aucun débordement de texte, aucune page plus large que 390 px ou 1440 px. Résultat dans `_source/controles.json` : aucun écart.
- Style volontairement basse fidélité : gris, une seule couleur d'accent (bleu) pour les actions principales et les états de l'agent, noir pour la main humaine, les alertes et les relais ; police Liberation Sans. Le style final revient à la designer.