ASPIC/journal/ASPIC-Journal. 28. Ecran de fond.md

# 28. Écran de fond

*Section démarrée le 2 septembre 2026, dans le prolongement de la réflexion "bureau à l'ancienne" (voir Réflexions stratégiques, section 11) et du pilotage vocal multi-agents (section 27) — les couleurs par agent envisagées ici comme code couleur des post-its sont directement liées au champ couleur que Jean-Marc ajoute en parallèle à la table `ASP_Agents`.*

## Origine et objectif

Décision actée en cours de session : le futur écran d'accueil d'ASPIC n'ouvrira plus directement sur la ToDoList ni sur la liste des contacts (comportement actuel depuis la V1.004), mais sur un écran de fond visuel reprenant la métaphore du "bureau à l'ancienne" — un tableau en liège avec un post-it par agent IA nommé, et un bureau sur lequel sont posés les objets/raccourcis fonctionnels de l'application.

## Démarche suivie (maquette graphique, Claude Design)

Faute de pouvoir décrire précisément la composition attendue par écrit, Jean-Marc a fourni deux croquis papier photographiés, puis plusieurs photos trouvées sur le web comme références de style (texture de liège et punaises colorées, classeurs à levier avec trou de préhension, ambiance de bureau photographiée). Une première maquette a été construite avec l'outil de canevas de design de Claude (Claude Design), publiée sous forme d'Artifact éditable — ce n'est pas un livrable de code, seulement un support visuel de travail.

Une deuxième itération a corrigé la composition générale (liège en arrière-plan / bureau au premier plan, plutôt que le découpage gauche-droite de la toute première version) et redessiné les classeurs dans l'esprit "classeur à levier" (trou de préhension, pochette d'étiquette) à partir de photos de classeurs réels envoyées par Jean-Marc.

Une troisième itération, dans la même session, s'appuie sur une image trouvée par Jean-Marc (générée par l'outil DeeVid AI) qu'il a jugée très proche de ce qu'il avait en tête ("voilà ce à quoi je pensais"). Claude a reconstruit la maquette à partir de cette référence : liège et bureau réunifiés en une seule composition (le bureau occupe le premier plan sur toute la largeur, les objets hauts — classeurs, micro, boîte à archives — dépassant visuellement au-dessus de la ligne du bureau, devant le mur en liège), classeurs remis à **hauteur uniforme** (la version précédente avait des hauteurs différentes sans raison fonctionnelle, remarqué à juste titre par Jean-Marc), boîte à archives redessinée en gris avec coins métalliques et porte-étiquette, micro redessiné dans un style "micro de podcast sur pied" plus réaliste. Le logo de l'outil ayant généré l'image de référence (DeeVid AI, visible en haut à droite de la photo) n'a bien sûr pas été repris dans la maquette — utilisé uniquement comme inspiration de style, pas comme contenu.

**Composition envisagée à ce stade (maquette Claude Design, jamais codée telle quelle — voir plus bas le changement de cap) :** arrière-plan liège sur toute la largeur avec un post-it par agent actif (Viktor, Matilda, Léon, Nikita) ; bande basse bureau en bois clair avec 4 classeurs à levier ("Contacts", "Catalogue", "Affaires en cours", et un 4ᵉ "À faire" proposé par Claude, jamais confirmé), une pile d'enveloppes surmontée du logo Gmail, un agenda fermé surmonté du logo Google Agenda, un téléphone écran éteint, un micro physique à voyant pulsé, une boîte à archives. Point resté ouvert à l'issue de cette phase : garder ou non les enveloppes/Gmail, absentes de la dernière image de référence DeeVid AI mais demandées explicitement plus tôt par Jean-Marc.

## Changement de cap : d'une maquette stylisée à un essai fonctionnel sur photo réelle (2 septembre 2026, reprise en soirée)

À la reprise, Jean-Marc a mis de côté la maquette liège/post-its ci-dessus (non tranchée, non codée) au profit d'une approche plus directe pour un premier essai réel : une **photo** de scène de bureau (classeurs à levier colorés, micro de studio sur pied, carnet, téléphone, chevalet nominatif), qu'il a lui-même fournie, recadrée puis re-recadrée à deux reprises à ses propres proportions d'écran (image finale **1024×457**, `ecran_fond.jpg`). Ce choix remplace, pour ce premier essai, la voie "maquette Claude Design + post-its par agent" — cette dernière n'est pas abandonnée sur le fond (elle reste une piste pour une version plus élaborée), mais l'essai en cours ne s'appuie plus dessus.

**Objectif de ce test, explicitement cadré par Jean-Marc dès le départ : "c'est juste un test"** — comprendre le rendu réel après identification, avant d'aller plus loin, pas un livrable final. Nouvel écran `ecran_fond.html`, affiché en plein écran juste après l'identification (redirection modifiée dans `identification.html`, qui pointait auparavant vers `liste_todolist.html`).

### Choix techniques retenus

- **`background-size:contain`, pas `cover`.** Premier essai en `cover` : sur l'écran réel de Jean-Marc (proportions différentes de l'image), le bas de l'image était rogné. Passage à `contain` : l'image entière reste toujours visible quelle que soit la proportion d'écran, quitte à laisser une bande de la couleur du mur (échantillonnée sur la photo) de part et d'autre plutôt que de rogner.
- **Système de coordonnées calé sur l'image de référence.** Chaque élément cliquable/affiché est positionné en pixels de l'image de référence (`IMG_W`/`IMG_H`, constantes en tête de script), puis converti en position/taille réelle à l'écran par une fonction `positionner()` qui refait à la main le calcul de `background-size:contain` (comparaison du ratio image/fenêtre, calcul de la zone réellement affichée et des bandes vides). Appelée au chargement et à chaque redimensionnement. Ce pattern est appelé à être réutilisé pour tout futur objet ajouté sur ce bureau — et l'a effectivement été dès la nuit suivante pour la pastille du classeur et la grille de post-its (voir plus bas).
- **Zone cliquable large, séparée de l'icône visuelle précisément positionnée** (cas du micro, voir plus bas) : un premier essai avec une seule zone cliquable de la taille de l'icône s'est révélé trop étroit à l'usage réel (infobulle qui ne se déclenchait qu'en survolant précisément quelques pixels) — le pattern retenu sépare un grand bouton invisible (toute la silhouette de l'objet, pour le survol/clic/infobulle) d'un petit élément visuel `pointer-events:none` posé par-dessus, calé sur le détail précis à afficher (ici le rond noir du micro), reliés par un sélecteur de fratrie CSS (`~`) pour l'effet visuel au survol.
- **Aucune donnée figée en dur** : tout ce qui s'affiche vient d'un endpoint PHP réel de la session en cours (`preferences.php`, `version.php`), jamais de texte statique.

### Éléments livrés dans ce test

- **Classeur "Contacts" cliquable.** Zone calée sur la tranche visible (face plate) du premier classeur (bleu-vert sur la photo), lien vers `liste_contacts.html`, infobulle "Ouvrir le classeur des contacts", léger liseré blanc au survol.
- **Étiquette "Contacts" sur la tranche**, texte tourné (`rotate(-90deg)`, lecture bas → haut, comme demandé — "il faudra tourner la tête sur le côté pour le lire"). Centrage horizontal corrigé à deux reprises après retours de Jean-Marc : une première mesure (encadrement min/max brut des pixels clairs) donnait un centre décalé ; une deuxième mesure par moyenne ligne par ligne a **mélangé par erreur l'étiquette du classeur voisin** (bleu), collée visuellement à celle du classeur "Contacts" — d'où un texte qui débordait cette fois dans le mauvais sens, vers le classeur voisin. Centrage définitif obtenu en isolant la seule plage claire du classeur "Contacts" (x < 80 sur l'image de référence) sur plusieurs lignes avant d'en prendre le centre. **Point de méthode à garder pour la suite** : sur cette photo, deux étiquettes voisines ont une couleur de fond quasi identique (blanc/gris clair) — toute mesure automatique par simple seuil de luminosité doit borner la zone de recherche à l'objet visé, sous peine de capter l'objet d'à côté.
- **Chevalet nominatif** (en bas à droite du bureau) : affiche le prénom de l'utilisateur connecté (`USR_Prenom`, nouvelle colonne ajoutée par Jean-Marc à `ASP_Users`, exposée par `preferences.php`). Une seule ligne (le nom de la société, initialement envisagé en 2ᵉ ligne, retiré à la demande de Jean-Marc — "l'utilisateur la connaît déjà"), ellipsis de sécurité si le prénom est long.
- **Micro cliquable**, icône logée dans le rond noir de la grille du micro photographié. Bascule ouvert/fermé au clic (test d'affichage seulement — ne déclenche pas encore la reconnaissance vocale réelle de `micro.js`) : fermé = glyphe micro gris clair, infobulle "Le micro est fermé, cliquez pour l'ouvrir" ; ouvert = barres façon vu-mètre animées en rouge (couleur proche de `--rouge-micro` de `liste_contacts.html`), infobulle "Le micro est ouvert, cliquez pour le fermer". Icônes redessinées en SVG à partir de `mic_repos.png`/`mic_ecoute.png` (déjà utilisées pour le bouton micro du bandeau). Position verticale de l'icône ajustée après retour de Jean-Marc ("icônes trop basses") par mesure précise du profil de la calotte du micro sur la photo (pointe du dôme, puis passage à un cylindre à largeur constante) pour recentrer l'icône dans la partie haute du dôme sans déborder au-dessus.
- **Numéro de version affiché sur le bureau**, même source que `#statut-version` de `liste_contacts.html` (`version.php`). Couleur et position ajustées après retour de Jean-Marc : couleur assombrie et rendue opaque (au lieu d'une transparence à 62 %), texte en gras, repositionné bord droit de l'écran, juste au-dessus de la bande claire de la tranche avant du bureau.
- **Touche Échap** conservée comme échappatoire silencieuse vers `liste_todolist.html`, le temps que cet écran ne porte pas encore d'objet fonctionnel complet.
- **Version applicative incrémentée à `V1.007`** pour l'ensemble de ce lot (première modification livrée dans cette étape du travail).

### Fichiers touchés (essai initial)

`identification.html` (redirection post-connexion), `ecran_fond.html` (nouveau), `ecran_fond.jpg` (nouveau, image de référence 1024×457 fournie et recadrée par Jean-Marc), `preferences.php` (ajout de `USR_Prenom` en lecture), `version.php` (`V1.007`). Côté base : colonne `USR_Prenom` ajoutée à `ASP_Users` par Jean-Marc directement (voir convention actée en tête de journal sur les exports SQL transmis).

## Nuit du 2 au 3 septembre 2026 : pastille du classeur, conception et premier affichage du tableau de post-its (V1.008)

Session enchaînée directement après l'essai initial ci-dessus (même soirée, Jean-Marc n'a pas fermé la fenêtre), à l'aide du token GitHub transmis en session pour relire l'état réel du dépôt avant de reprendre — token utilisé uniquement pour cloner/consulter, jamais stocké, conformément à la consigne en tête de journal.

### Pastille "nombre de contacts" sur le classeur

Avant d'ouvrir le chantier du tableau de liège, petite demande de Jean-Marc : afficher, sous le trou cerclé de métal du classeur "Contacts", une pastille ronde avec le nombre réel de contacts de la table, dans un esprit "collée sur le classeur" — couleur homogène avec le classeur (plus foncée), chiffre blanc, liseré pour ressortir.

Mesure précise du trou et de son anneau métallique sur `ecran_fond.jpg` (centre à x=58, y=354 dans le référentiel image, anneau jusqu'à y≈365) pour caler la pastille juste en dessous, sur le même axe. Couleur de fond calculée par assombrissement (×0,55) de la teinte réelle du classeur mesurée sur la photo (rgb≈3,79,99, plus sombre en photo qu'à l'écran) plutôt que choisie arbitrairement — donne `#022b36`. Nouveau paramètre `?compte=1` sur `contacts.php` : renvoie `{"total": N}` (comptage seul, `COUNT(*)` sur `ASP_Contacts` actifs) sans charger la liste complète, pour ne pas gaspiller un appel lourd juste pour une pastille. Taille de police du chiffre adaptative selon le nombre de chiffres (2/3/4+), pour continuer à tenir dans le rond si la table grossit.

Premier rendu jugé "un peu trop présent" par Jean-Marc à l'usage réel sur son écran : diamètre réduit de 22 à 17px (référentiel image 1024×457), liseré blanc adouci (épaisseur 2px→1,5px, opacité 85%→40%). Centre de la pastille recalé à (58, 381) pour rester au milieu de l'espace disponible entre l'anneau et le bas du classeur avec la nouvelle taille, plutôt que de garder l'ancien centrage. Validé ensuite par Jean-Marc ("c'est parfait").

### Conception du tableau de liège — vision actée, partiellement codée

Confirmation importante de Jean-Marc en cours de discussion : le mur représenté sur `ecran_fond.jpg` est bien du **vrai liège** (vérifié par Claude en zoomant sur la photo — texture organique/granuleuse nette, pas une couleur unie comme l'écran le laissait presque penser à taille normale). Ce point a tranché en faveur d'un post-it avec punaise ronde plutôt qu'un simple carré posé : sur du vrai liège, la punaise est l'objet qui va avec la matière, pas une fantaisie graphique.

**Répartition de l'écran, principe retenu :** 70% de la largeur pour les 4 assistants IA (Viktor, Matilda, Léon, Nikita — voir section 27), 30% fixe pour Jean-Marc lui-même, en bande verticale partant du bord droit de l'écran (juste au-dessus du chevalet, qui porte déjà son prénom — cohérence visuelle du "coin" qui le représente). Logique assumée par Jean-Marc : les assistants doivent traiter leurs tâches très rapidement (donc peu de post-its en attente à un instant T), l'humain — "le vilain petit canard" — accumule davantage avant de traiter, donc mérite plus de place. Jean-Marc a explicitement refusé d'appliquer à lui-même une répartition dynamique par charge, préférant garder ses 30% fixes pour l'instant.

**Règles actées pour la part "assistants" (70%), non codées ce soir faute de ToDoList assistants réelle :**
- Part de chaque assistant affiché = (ses tâches en attente ÷ somme des tâches en attente de tous les assistants) × 70%.
- L'assistant par défaut (`AGN_Defaut`, aujourd'hui Matilda) est toujours le plus à gauche parmi les colonnes affichées, s'il a au moins une tâche en attente.
- Les autres assistants ayant des tâches sont classés à sa suite par charge décroissante (le plus chargé juste après le défaut).
- Un assistant sans tâche en attente **disparaît entièrement** du tableau (pas de colonne vide) — permet d'intégrer les assistants un par un sans "zone vide" frustrante à l'écran.
- Chaque assistant aura une couleur de post-it personnalisée (`AGN_Couleur`, champ déjà en cours d'ajout par Jean-Marc à `ASP_Agents` en parallèle du pilotage vocal — voir section 27). Jean-Marc, lui, garde toujours le jaune classique du post-it, jamais personnalisé.

**Clarification importante actée en discussion, vérifiée dans le code par Claude :** Jean-Marc a fait remarquer que la gestion de tâches par assistant n'est pas une nouvelle mécanique à inventer — le champ `TDL_ToDoUser` de `ASP_ToDoList` (et `TDL_RealUser`) n'a jamais été restreint à un humain ; le commentaire d'en-tête de `todolist.php` anticipait déjà qu'un agent IA puisse ajouter une tâche pour un autre utilisateur, et l'endpoint renvoie déjà toutes les tâches actives quel que soit `TDL_ToDoUser`. Il suffira, le jour venu, d'ajouter un discriminant humain/agent (pour savoir quel nom et quelle couleur afficher) plutôt que de reconstruire un système. Les écrans de gestion actuels (`liste_todolist.html`, `todolist.php` pour la consultation/ajout/modification) sont conservés tels quels — pensés pour un usage humain (formulaire), pas forcément adaptés tels quels à un usage agent le jour venu, mais ce sujet est explicitement remis à plus tard. Ils ne sont **pas reliés à la navigation** depuis l'écran de fond pour l'instant (clic sur un post-it sans effet, voir plus bas).

**Nouveau besoin identifié en cours de réflexion (non traité ce soir) :** un écran "journalier", traçant ce qui a été réalisé par chacun (humain et assistants), une fois plusieurs acteurs actifs sur la même ToDoList. Repéré par Claude comme déjà largement couvert par les champs existants de `ASP_ToDoList` — `TDL_RealDate`/`TDL_RealUser`/`TDL_RealText` donnent déjà, pour chaque tâche réalisée, qui l'a faite, quand, et un commentaire de réalisation. Une première version de ce journalier pourrait donc être une simple requête "tâches où `TDL_RealDate` n'est pas vide, triées par date décroissante", sans nouvelle table. À noter : le commentaire d'en-tête de `todolist.php` mentionnait explicitement qu'un système d'audit avait été volontairement écarté à l'origine ("non demandé à ce stade... pas de sur-ingénierie") — le besoin de ce soir est justement le moment où ce choix mérite d'être révisité, ce qui valide plutôt bien le principe.

**Conception visuelle du post-it.** Deux options proposées par Claude (image de synthèse envoyée à Jean-Marc) : carré simple avec coin corné, ou même carré avec punaise ronde en haut. La confirmation que le fond est du vrai liège a tranché en faveur de la punaise. Première proposition d'agencement en petit tas chevauché, explicitement rejetée par Jean-Marc — pas pour le principe de chevauchement (qu'il n'a jamais exclu), mais pour l'empilement en tas qui rend le survol/clic imprécis ("il faudrait une précision de tireur d'élite"). Solution retenue : chaque post-it reste dans une case de grille qui lui est propre, avec un léger jitter de rotation/décalage à l'intérieur de sa case (jamais à cheval sur la case voisine) — donne un rendu "punaisé à la main" sans jamais recréer un tas ambigu au clic.

**Capacité du tableau — refus explicite d'un ascenseur.** En discutant de ce qui se passerait si le nombre de post-its dépassait la place disponible (taille fixe, pas de plafond souhaité par Jean-Marc au départ), Claude a proposé un défilement vertical à l'intérieur de la seule bande personnelle. Jean-Marc s'y est fermement opposé : un ascenseur casserait la métaphore du vrai bureau et, pire, l'inciterait lui-même à cumuler les post-its sans jamais être poussé à les traiter ("je me connais"). Décision retenue à la place : une capacité finie et un message de blocage à la création, une fois le tableau plein — la contrainte physique du vrai bureau étant vue comme une qualité (elle force à traiter), pas un défaut à contourner.

Implémentation dans `todolist.php` : constante `CAPACITE_TABLEAU_PAR_UTILISATEUR = 20` (valeur ronde provisoire, posée avant d'avoir les vrais pixels de la grille codée — "mets-le où tu veux, il faudra le faire évoluer", dixit Jean-Marc), et vérification au POST : si le nombre de tâches actives non réalisées de l'attributaire (`TDL_ToDoUser`) atteint cette capacité, la création est refusée (HTTP 409) avec le message exact demandé par Jean-Marc : *"Ton tableau est plein, tu ne peux plus ajouter de post-it !"*. Une tâche créée déjà réalisée (cas de la journalisation rétroactive d'une tâche déjà faite, prévu de longue date dans `todolist.php`) n'est jamais bloquée — elle n'occupe jamais de post-it sur le tableau. Posée dans `todolist.php` plutôt que dans l'écran de fond : la règle vaudra donc aussi le jour où la voix créera des tâches directement, sans rien à reprendre.

### Premier affichage réel des post-its personnels

Implémenté dans `ecran_fond.html`, en s'appuyant sur le pattern `positionner()` déjà en place pour les autres éléments (voir plus haut).

- **Zone :** 30% de la largeur de l'écran depuis le bord droit (soit x:[717,1024] sur l'image de référence 1024×457), du haut de l'image (y=6) jusqu'à juste au-dessus du chevalet (y=352, chevalet à partir de y=362).
- **Grille :** 4 colonnes × 5 lignes = 20 cases, volontairement alignée sur `CAPACITE_TABLEAU_PAR_UTILISATEUR` de `todolist.php` — les deux constantes devront évoluer ensemble si l'une change. Taille d'un post-it : ~60% de la plus petite dimension de case, pour laisser de la marge au jitter.
- **Source des données :** `todolist.php` (déjà utilisé par `liste_todolist.html`), filtré côté client sur l'utilisateur connecté (`TDL_ToDoUser` comparé au `USR_Code` renvoyé par `preferences.php`) et sur les tâches non réalisées (`TDL_RealDate` vide) — l'API elle-même reste volontairement non filtrée par utilisateur (voir plus haut), le tri "ce sont MES post-its" se fait donc à l'affichage. L'ordre renvoyé par l'API (rouge avant orange, sous-trié par échéance) est conservé pour remplir la grille case par case : les tâches les plus urgentes arrivent toujours en premier, en haut à gauche de la zone.
- **Jitter déterministe :** rotation et décalage d'un post-it calculés à partir de son `TDL_Incr` (petit générateur pseudo-aléatoire "mulberry32" simplifié), et non d'un hasard pur — la disposition reste stable d'un rechargement de l'écran à l'autre, pas de "saut" visuel à chaque retour sur l'écran de fond.
- **Habillage du post-it :** punaise ronde en haut, coin corné bas-droit (léger dégradé simulant le papier qui se soulève), pastille d'urgence rouge/orange bien visible en coin haut-droit (jamais verte : une tâche réalisée quitte immédiatement le tableau, voir filtre ci-dessus), jaune classique fixe pour Jean-Marc. Pas de texte visible sur le post-it (choix explicite de Jean-Marc) : le texte de la tâche (`TDL_ToDoTxt`) n'apparaît qu'en infobulle au survol. Clic sans effet pour l'instant — navigation vers `liste_todolist.html` volontairement pas encore branchée (voir plus haut).
- **Test :** rendu vérifié par Claude avec des jeux de données simulés (9 puis 23 tâches, groupes rouge/orange mélangés, une tâche appartenant à un autre utilisateur et une tâche déjà réalisée pour confirmer que le filtrage fonctionne bien) avant envoi à Jean-Marc. Rendu confirmé "conforme à la réalité" par Jean-Marc sur les images envoyées.

**Point relevé par Jean-Marc en toute fin de session, à traiter plus tard :** les règles actuelles de calcul du groupe d'urgence (`calculerGroupe()` dans `todolist.php` — rouge/orange/vert) risquent de donner un tableau surchargé de rouge et d'orange, puisque le vert (réalisé) quitte désormais le tableau immédiatement. Pas retouché ce soir, noté pour une prochaine session.

### Fichiers touchés (nuit du 2-3 septembre)

`contacts.php` (paramètre `?compte=1`), `ecran_fond.html` (pastille classeur + zone et grille de post-its), `todolist.php` (constante et vérification de capacité), `version.php` (`V1.008`).

## Point ouvert, non tranché

- La question enveloppes/Gmail (voir plus haut) portait sur la maquette liège/post-its, mise de côté par le changement de cap ci-dessus — à retrancher le jour où cette piste sera reprise, pas urgent pour l'essai en cours.
- Confirmer un jour le libellé du 4ᵉ classeur envisagé dans la maquette liège ("À faire" / ToDoList) — question qui ne se pose plus dans l'immédiat : l'essai en cours n'a pour l'instant qu'un seul classeur fonctionnel ("Contacts").
- La "tranche du bureau" (bord avant du plan de travail, en bas de l'image) n'est pas visible à l'écran chez Jean-Marc. Il précise que ça ne le gêne pas dans l'immédiat, mais que ça pourrait poser problème plus tard — à revoir un jour. Cause non investiguée à ce stade.
- Répartition dynamique des 70% entre assistants par charge de tâches (formule actée, voir ci-dessus) — pas codée, bloquée tant que la ToDoList des assistants n'existe pas réellement.
- Discriminant humain/agent à ajouter à `ASP_ToDoList`/`todolist.php` pour qu'un assistant puisse être attributaire d'une tâche — préalable à la répartition dynamique et aux couleurs de post-it par assistant (`AGN_Couleur`).
- Écran "journalier" (trace des réalisations, humain + assistants) — donnée déjà quasi disponible, écran à construire.
- Règles de calcul des pastilles rouge/orange/vert à revoir (voir remarque de Jean-Marc ci-dessus).
- Comportement du clic sur un post-it à décider (aujourd'hui inerte) : ouvrir `liste_todolist.html` sur la tâche précise, ou détail affiché directement sur l'écran de fond.
- Capacité du tableau (20) et taille de la grille (4×5) sont des valeurs provisoires posées avant d'avoir les vrais pixels de la version aboutie — à ajuster ensemble après usage réel prolongé.

## Statut et suite

**Deux livraisons réelles sur la même soirée du 2 septembre, la seconde se prolongeant après minuit (3 septembre) :** l'essai fonctionnel initial (classeur Contacts, chevalet, micro test d'affichage, version — V1.007), puis la pastille de comptage sur le classeur et un premier affichage réel, fonctionnel et testé, du tableau de post-its personnels de Jean-Marc (V1.008). Plusieurs allers-retours de correction fine à chaque étape, à partir des retours directs de Jean-Marc sur son propre écran ou sur des rendus envoyés par Claude — la mesure de position sur une photo réelle (plutôt que sur un dessin vectoriel) continue de demander une vérification fine à chaque retour.

Séance close sur un bilan explicitement positif de Jean-Marc ("très satisfait du travail accompli"), après une séance précédente terminée sur une note plus mitigée. Fin de session actée à sa demande, sans blocage — dépôt des fichiers sur GitHub prévu par ses soins le lendemain matin.

**Reste à faire, noté au passage :**
- Revoir un jour le sujet de la "tranche du bureau" non visible chez Jean-Marc (voir ci-dessus).
- Décider si les autres objets photographiés sur le bureau (carnet, téléphone) doivent devenir cliquables/fonctionnels dans une prochaine étape, ou rester un habillage visuel statique pour l'instant.
- Brancher réellement le micro du bureau sur la reconnaissance vocale de `micro.js` (aujourd'hui : bascule d'affichage seule, sans effet sur l'écoute réelle).
- Trancher, un jour, le sort de la piste "maquette liège + post-its par agent" (Claude Design) : mise de côté pour les essais en cours, mais pas explicitement enterrée pour une version plus aboutie.
- Artifact de travail de la maquette liège (dernière version, non utilisée dans l'essai actuel) : https://claude.ai/code/artifact/a647369f-d320-4b21-9f8c-11b20f2ad353 — lien privé à Jean-Marc, à ne pas considérer comme un livrable définitif.
- Répartition dynamique par charge, discriminant humain/agent, écran journalier, règles de pastilles, comportement du clic sur un post-it, calibrage capacité/grille : voir "Point ouvert, non tranché" ci-dessus.