# Wireframes v2 : ce qui a changé

La v2 applique la revue de Tom sur la v1 ([RETOURS_TOM_WIREFRAMES_V1.md](../RETOURS_TOM_WIREFRAMES_V1.md)), qui prime sur [ECRANS.yaml](../ECRANS.yaml). La v1 reste dans [../wireframes/](../wireframes/index.html) pour comparer.

- **36 wireframes** : 15 écrans en téléphone (390 px) et en ordinateur (1440 px), dont la conversation en main humaine, plus 6 états sur téléphone seulement (brouillon ouvert, objectif modifié, carte de pipeline ouverte, alerte, liste du praticien, propositions après un appel). Une planche regroupe les 22 autres écrans.
- Tout est en HTML navigable (`ecrans/`) et en PNG (`png/`). La page d'entrée est [index.html](index.html).
- L'export vérifie chaque page : cibles tactiles de 44 px au moins sur téléphone, aucun débordement, aucune page plus large que son format. Résultat dans `_source/controles.json` : aucun écart.

## 1. Les règles appliquées partout

| Consigne de Tom | Ce que font les wireframes |
| --- | --- |
| Interface en français (D-048), turc plus tard | Tous les libellés en français, courts, pour que la traduction turque tienne dans les mêmes boutons |
| Base WhatsApp (D-049) | Liste de discussions, fil sur fond beige, bulles, barre de saisie en bas, en-tête avec avatar ; sur ordinateur, la disposition de WhatsApp Web |
| La vue ne change pas entre la liste et la discussion | Sur ordinateur, la boîte de réception et la conversation sont le même écran (liste à gauche, fil à droite) |
| Traduction en français quand on navigue | Chaque message du patient s'affiche en français, avec « traduit de l'allemand » en petit ; l'original est à un clic |
| Brouillon à la fin du fil, couleur brouillon | Bulle violette en pointillés, en réponse au message du patient, avec deux boutons : **Modifier** et **Approuver et envoyer** |
| Au clic : message du patient traduit et proposition | Une feuille s'ouvre : message du patient en français, réponse proposée, langue d'envoi ; les sources y restent repliées |
| Sources cachées | Plus aucune pastille de source dans le fil : « Sources (2) › » dans la feuille du brouillon |
| Séquence et langue très discrètes | La séquence disparaît du fil ; « langue du patient : allemand » figure en petit dans l'en-tête, sur ordinateur |
| Petits accusés | ✓ envoyé, ✓✓ reçu, ✓✓ en gras lu, et ✉ pour l'e-mail, dans le coin de la bulle |
| Liseré jaune quand l'agent gère, rien quand un humain a la main | Cadre jaune autour du fil et point jaune dans l'en-tête ; sans liseré, une ligne « Vous avez la main · Rendre la main à l'agent » au-dessus de la saisie |
| Plus d'écrans, moins chargés | Le dossier, l'objectif, le projet, la carte de pipeline et l'appel sont des écrans ou des panneaux séparés ; chacun porte une seule action principale |
| Informations secondaires au clic | Historique, réponses déjà données, versions précédentes, sources, injection d'événements : des liens « › » |

**Couleurs.** Elles ne servent plus qu'à quatre usages :
- le violet pour le brouillon ;
- le jaune pour le liseré de l'agent ;
- le rouge pour une alerte (alerte médicale, arrêt d'urgence) ;
- le vert pour l'action principale.

Un point à gérer tout de suite (vol retardé, pièce manquante, dérogation à décider) est signalé par un cadre foncé et « ⚠ », sans rouge : le rouge garde sa force pour les alertes.

## 2. Écran par écran

| Écran | Retiré | Déplacé | Simplifié |
| --- | --- | --- | --- |
| **Mon travail** (E-02) | Sections « suggestions », « décisions à confirmer » et bandeau d'état détaillé | Liste des brouillons dans la file de validation | Quatre lignes ; « 6 réponses à valider » et le bouton « Commencer » d'abord |
| **Discussions** (E-03) | Vues enregistrées, filtres par langue, canal, séquence, responsable et fenêtre ; colonnes du tableau v1 | Tri et recherche derrière 🔍 | Liste façon WhatsApp avec trois filtres (Tout, À valider, Main humaine) ; point jaune ou cercle pour savoir qui gère ; une étiquette d'état |
| **Conversation** (E-04, E-05) | Bandeau « Agent drives », pastilles de séquence et de contrôles, carte de brouillon chargée, ligne d'actions secondaires | Sources, original, langue d'envoi et autres actions dans la feuille du brouillon ; fiche du dossier dans un panneau à ouvrir | Liseré jaune, brouillon en bulle, deux boutons |
| **Main humaine** (variante E-04) | Carte « Hand back », bandeaux | Note pour l'agent : demandée au moment de rendre la main | Même écran sans liseré ; saisie à deux onglets « Répondre / Note interne » |
| **File de validation** (E-06) | Colonne de contexte, statistiques du jour, raccourcis clavier affichés | Les statistiques vers le tableau de bord | La file est une suite de conversations : bandeau « Réponse 2 sur 6 · Passer › », puis la suivante s'ouvre après l'envoi ; « Envoyé à Lena · Annuler » pendant 10 s |
| **Dossier** (E-07) | Onglets, cartes de suggestions, transitions | Rubriques (objectif, pièces, projet, voyage et paiements) au clic | « Où en est-on », résumé de 3 lignes, chronologie des événements clés et « Tout l'historique › » |
| **Objectif** (E-09) | Liste des réponses, provenance sous chaque valeur, jauge de complétude, historique en ligne | Réponses déjà données au clic ; historique dans le dossier | Refait : un encadré dit à quoi sert la page. Viennent ensuite « Ce que veut Lena » (une phrase), « Soins concernés » (suggestion de l'agent : Ajouter ou Non) et « Ce que l'agent va encore demander ». Après une modification, l'agent confirme en une phrase |
| **Projet et accords** (E-11) | Éditeur de champs, aperçu PDF permanent, accords barrés de la v1, conditions d'envoi détaillées | PDF derrière « Ouvrir le PDF » ; versions précédentes au clic | Une carte (version, montant, validité), trois accords à cocher, un bouton, l'envoi grisé tant qu'il manque un accord |
| **Pipelines** (E-17) | Onze colonnes commerciales, « Move to… » sur chaque carte, filtres multiples | Action et transition dans la carte ouverte (feuille ou panneau) | Six colonnes lisibles, cartes à trois informations (nom, soin, durée) et qui gère ; la carte ouverte dit ce qui manque pour avancer |
| **Aujourd'hui à Istanbul** (E-19) | Boutons sur chaque carte, statut du vol détaillé, compteurs | Détail d'un patient (vol, coches, « Marquer arrivé ») au clic | Ce qui est à gérer maintenant en haut, puis la journée heure par heure |
| **Alerte** (E-16) | Signe reconnu, liste des personnes alertées, numéros d'urgence affichés | Numéros et détails au clic | Une carte rouge, « Je prends en charge », deux appels, « Ce qui a été fait », « Clore » |
| **Praticien** (E-21, E-22) | Réponses détaillées, notes, actions sur chaque pièce | Réponses du patient, jugement d'une pièce (dans la visionneuse) | Résumé, un point à noter, vignettes, « Approuver » ou « Demander une modification » |
| **Tableau de bord** (E-23) | Six tuiles, préparation à l'autonomie, coûts détaillés, export | Autres indicateurs au clic | Ce qu'il faut décider, quatre chiffres, du contact à l'accord, pourquoi ça n'aboutit pas |
| **Supervision** (E-26) | Sélecteurs de niveau dans le tableau, préparation à l'autonomie, routage des modèles | Changement de niveau dans une page à part (décision datée) | Arrêt d'urgence, sept séquences avec leur niveau, la journée, le coût du mois |
| **Console de test** (E-38) | Tableau des séries avec colonnes, assertions et signalements sur la page d'accueil | Injection d'événements et signalements au clic | Séries, horloge, un bouton « Aller à la prochaine échéance » |
| **J'ai fait un appel** (E-37) | Enregistrement audio, transcription, bouton rond d'enregistrement | Les mises à jour proposées sur un second écran | Un champ « Ce qui s'est dit, en quelques mots », puis trois propositions cochées que Sibel garde ou décoche |

La v2 lève trois frictions relevées dans la v1 ([PARCOURS.md](../wireframes/PARCOURS.md), section 4) :
- le réceptif retrouve ses brouillons dans « Discussions › À valider » ;
- l'onglet « Cases » disparaît : le réceptif a les onglets Aujourd'hui, Discussions, Alertes et Plus ;
- le praticien juge une pièce dans la visionneuse, plus depuis la galerie.

## 3. Les appels (d'après [RAPPORT_APPELS_WHATSAPP.md](../RAPPORT_APPELS_WHATSAPP.md))

- **Appel passé par l'API WhatsApp.** Il remonte seul dans le fil, sous forme d'une ligne d'événement « 📞 Appel de Sibel · 12 min · 10:31 », sans l'audio. La ligne porte un bouton « Ajouter un résumé » (écran *Conversation, vous avez la main*, et panneau *Résumé de l'appel* sur ordinateur).
- **Appel passé depuis le téléphone, hors application.** Il ne remonte pas. Sibel ouvre « J'ai fait un appel » depuis le menu ⋮ et écrit en quelques mots ce qui s'est dit. L'agent propose ensuite des mises à jour qu'elle garde ou refuse.
- **Permission.** Pour appeler un patient par l'API, il faut d'abord sa permission, avec une demande par jour et deux par semaine au plus. Le bouton 📞 de l'en-tête doit donc devenir « Demander la permission d'appeler » quand elle n'est pas donnée, et dire quand la prochaine demande est possible. Cet état n'est pas dessiné.
- **Enregistrement audio.** Aucun : c'est un chantier séparé.

## 4. Règles de concision proposées pour les textes de l'agent

Limites en caractères, à contrôler par l'orchestrateur avant l'affichage. Au-delà, le texte est refusé et l'agent le réécrit une fois ; ensuite on l'affiche tronqué avec « Voir plus ». Un plafond de jetons en sortie sert de filet de sécurité (environ 4 caractères par jeton en français).

| Texte | Limite | Forme |
| --- | --- | --- |
| Résumé du dossier | 3 lignes, 280 caractères (≈ 70 jetons) | Faits seulement : qui, quoi, quand, ce qui manque ; pas de formule de politesse |
| Réponse proposée au patient (WhatsApp) | 3 phrases, 320 caractères (≈ 80 jetons) ; une seule question par message | Ce qu'on lui répond, puis ce qu'on attend de lui |
| Réponse par e-mail | 5 phrases, 600 caractères | Même contenu, avec une formule d'ouverture |
| Prochaine action | 1 ligne, 80 caractères | Qui, verbe, objet, quand : « L'agent demande la photo de profil gauche, aujourd'hui » |
| Proposition de mise à jour (après un appel, suggestion) | 1 ligne par champ, 90 caractères, preuve à un clic | Champ, nouvelle valeur |
| Confirmation après une modification humaine | 1 phrase, 120 caractères | Ce que l'agent change dans sa conduite : « Il ne posera plus de question sur la mâchoire du haut » |
| Alerte | 2 lignes, 160 caractères | Ce que signale le patient, puis ce qui a déjà été fait |
| Résumé d'appel | 2 phrases, 240 caractères | Ce qui a été dit, puis ce qui a été décidé |
| Synthèse pour le praticien | 3 lignes et un seul « à noter » | Objectif, pièces, point médical déclaré |
| Relais vers un humain | 2 lignes, 200 caractères | La question du patient, puis ce qui manque pour répondre |

## 5. Sources d'inspiration

Ergonomie seulement : aucun code, aucune image, aucun élément graphique n'a été copié.

**Chatwoot**, messagerie d'équipe open source. [github.com/chatwoot/chatwoot](https://github.com/chatwoot/chatwoot), [chatwoot.com/features](https://www.chatwoot.com/features/). Licence MIT, sauf le dossier `enterprise/`, sous licence propre (voir [RAPPORT_CHATWOOT.md](../RAPPORT_CHATWOOT.md), section 2.1). Aucun composant Enterprise n'est repris.
- Trois volets sur ordinateur (liste, fil, panneau du contact repliable), qui deviennent liste, fil et panneau « Dossier ».
- Zone de réponse à deux onglets « Répondre / Note interne ». Les notes privées s'affichent dans le fil, visibles de l'équipe seulement ([API des messages, `private`](https://developers.chatwoot.com/api-reference/messages/create-new-message)).
- Peu de filtres dans la liste, trois onglets comme Mine, Unassigned et All.
- Statuts pending et open pour la main du bot et de l'humain ([changement de statut](https://developers.chatwoot.com/api-reference/conversations/toggle-status)), rendus ici par le liseré.
- Réponses préenregistrées appelées par « / » dans la saisie : proposées, non dessinées.

**Nuxt AI Chatbot**, modèle Vercel. [vercel.com/templates/other/nuxt-ai-chatbot](https://vercel.com/templates/other/nuxt-ai-chatbot), code sur [github.com/nuxt-ui-templates/chat](https://github.com/nuxt-ui-templates/chat), démonstration sur [chat-template.nuxt.dev](https://chat-template.nuxt.dev/). Licence MIT.
- Barre latérale d'historique repliable, qui devient le rail d'icônes et la liste.
- Saisie avec pièce jointe et dictée (＋ et 🎤).
- Résultats d'outils et sources rendus sous le message et repliables, d'où « Sources (2) › ».
- Palette de commandes, qui devient la recherche.
- Vue et Nuxt : non réutilisable dans le front React d'ami-workspace.

**assistant-ui**, bibliothèque React d'interfaces de chat avec l'IA. [github.com/assistant-ui/assistant-ui](https://github.com/assistant-ui/assistant-ui), [documentation](https://www.assistant-ui.com/docs). Licence MIT.
- Approbation humaine d'une proposition de l'IA avant exécution, avec accepter ou refuser ([Tool UI, approval gates](https://www.assistant-ui.com/docs/tools/tool-ui)) : c'est notre brouillon, « Approuver et envoyer » ou « Modifier ».
- Édition d'un message sur place : « Modifier » édite la bulle.
- Barre d'actions sous un message.
- Pièces jointes et sources comme parties d'un message ([pièces jointes](https://www.assistant-ui.com/docs/guides/attachments)).
- Suggestions proposées en un clic, qui deviennent « L'agent propose 3 mises à jour ».
- **Candidat pour le développement : oui, à valider par un essai d'un ou deux jours.** C'est du React avec un thème shadcn fourni, comme ami-workspace, et ses primitives Thread, Message, Composer et ActionBar sont non stylées. Deux adaptations sont nécessaires :
  - la bibliothèque suppose une conversation entre un utilisateur et une IA, alors que notre fil a trois voix (patient, agent, humain), deux canaux (WhatsApp et e-mail) et des lignes d'événement : il faut un rendu de message à nous et un runtime branché sur l'API d'AMI ;
  - le brouillon correspond à une approbation en attente.

**NextCRM**, CRM open source en Next.js et shadcn. [github.com/pdovhomilja/nextcrm-app](https://github.com/pdovhomilja/nextcrm-app). Licence MIT.
- Fiche d'entité avec vue d'ensemble, fil d'activités (notes, appels, e-mails, réunions, tâches) et onglet d'historique à part : c'est le dossier (résumé et chronologie des événements clés, « Tout l'historique › »).
- Kanban des affaires ([`crm/dashboard/_components/CRMKanban.tsx`](https://github.com/pdovhomilja/nextcrm-app/blob/main/app/%5Blocale%5D/(routes)/crm/dashboard/_components/CRMKanban.tsx)) : des cartes courtes.
- Formulaire en panneau latéral (Sheet) pour créer ou modifier sans quitter la page : c'est la carte ouverte, « Faire avancer », et le panneau « Résumé de l'appel ».
- Tableaux filtrables à facettes (TanStack Table) pour les listes longues de la planche (finance, tâches, droits).
- Tableau de bord en compteurs cliquables.
- **Réutilisable au développement, avec la mention de licence MIT :**
  - le jeu de composants de tableau (`table-components/data-table*.tsx` : tableau, barre d'outils, filtre à facettes, pagination, actions de ligne) ;
  - le fil d'activités (`components/ActivitiesSection.tsx`) ;
  - la frise d'historique (`AuditTimeline` et `AuditEntry`, citées dans son README) ;
  - le kanban.

  Ces composants sont à reprendre un par un et à brancher sur l'API d'AMI. Ne pas forker l'application : c'est un CRM complet sur Prisma, dont le modèle de données n'est pas le nôtre.

## 6. Points à trancher avec Tom

1. **Couleur du brouillon.** Violet en pointillés, pour ne pas le confondre avec le jaune de l'agent. Un autre choix est possible, pourvu qu'il reste distinct du jaune.
2. **Prendre la main sans écrire.** Écrire prend la main. « Prendre la main » sans écrire est rangé dans le menu ⋮. Faut-il l'afficher aussi dans le liseré ?
3. **Délai d'annulation.** « Approuver et envoyer » part après 10 secondes, pendant lesquelles « Annuler » reste possible (réglage E-31). Faut-il garder ce délai dans la file de validation, où il ralentit l'enchaînement ?
4. **Patient sans WhatsApp.** Le fil est tout en e-mail et la saisie passe sur l'e-mail avec un objet. Cet état n'est pas dessiné.
5. **Longueurs de la section 4.** Les limites sont à valider sur de vrais échanges pendant les tests robotiques.