ASPIC/journal/ASPIC - Journal. Index.md

# ASPIC — Journal de développement (index)

*CRM sur mesure — PHP + MySQL + JavaScript vanilla*

**Le détail complet du journal est désormais tenu dans le dépôt GitHub `JMP-MS/ASPIC`, dossier `/journal`** (28 fichiers `.md`, un par grande section, protégés en accès web direct par un `.htaccess`). Ce document ne garde plus qu'un sommaire et l'état actuel, pour une vue d'ensemble rapide sans avoir à cloner le dépôt. Pour toute question qui touche à l'historique détaillé d'une section, demander sa lecture — Claude ira la chercher sur GitHub avec le token transmis en session (jamais stocké).

## Consigne de travail (Claude) — à partir du 2 septembre 2026

Pour les trois documents de ce projet (ce journal — résumé/index —, les Réflexions stratégiques, la Documentation utilisateur), **ainsi que pour les fichiers de section individuels du journal détaillé** (`/journal` sur GitHub, 28 sections numérotées 00 à 27 au 2 septembre 2026) : les mises à jour de contenu ne sont faites qu'**en toute fin de session**, jamais au fil de l'eau pendant les essais — pour éviter d'enregistrer un état intermédiaire ou instable. À ce moment-là, en plus d'écrire la mise à jour dans le document du projet le cas échéant, Claude fournit systématiquement une **copie téléchargeable** (fichier `.md`) de chaque document ou section modifié(e), pour que Jean-Marc puisse la sauvegarder de son côté et la déposer dans le dépôt GitHub. Pour une section du journal détaillé, le fichier téléchargeable reprend le nom exact utilisé dans `/journal` sur GitHub, pour un dépôt direct sans renommage.

**Cas particulier des fichiers de code livrés en session (2 septembre 2026) :** un fichier `.js` n'est pas téléchargeable tel quel depuis le client utilisé par Jean-Marc. Pour tout fichier JavaScript livré (`micro.js` et les suivants), fournir systématiquement, en plus du fichier `.js` normal, une copie strictement identique au format `.txt` (même nom, extension changée — ex. `micro.js.txt`), pour qu'elle soit récupérable.

**Précision du 2 septembre 2026 (fin de session) sur les exports SQL transmis par Jean-Marc :** un `CREATE TABLE`/`INSERT` envoyé par Jean-Marc est le compte-rendu d'une modification déjà faite à la main côté base (il travaille en éditant directement, puis exporte pour informer Claude) — jamais une commande à exécuter côté Claude. Claude peut donc lire ces exports comme l'état réel de la base au moment de l'envoi, sans jamais chercher à les "lancer".

**Précision du 2 septembre 2026 (soir) sur la continuité entre fenêtres de conversation :** chaque nouvelle fenêtre de conversation démarre un environnement cloud entièrement neuf, sans mémoire du fil précédent ni accès aux fichiers de travail locaux de la session précédente (ex. le clonage temporaire du dépôt GitHub fait dans `/tmp` pour éditer du code) — seuls les documents de ce projet (ce journal, les Réflexions stratégiques, la Documentation utilisateur) traversent d'une fenêtre à l'autre. C'est pour cette raison que la consigne ci-dessus (mise à jour en fin de session, pas au fil de l'eau) compte particulièrement : c'est le seul filet de continuité entre deux sessions. Point déjà noté dans les Réflexions stratégiques, section 2. Un résumé automatique de conversation trop longue (fait par Claude Code en cours de fil, différent d'un changement de fenêtre) est en revanche censé préserver les faits essentiels de la session en cours — dans les faits, une erreur de mesure de pixels a bien eu lieu le 2 septembre après un tel résumé, mais elle provenait d'une méthode de mesure imprécise, pas d'une perte d'information liée au résumé lui-même (voir section 28, le centrage de l'étiquette "Contacts").

**Consigne du 6 septembre 2026 — numérotation de version à trois niveaux (`version.php`) et son partage de responsabilité.** Après une session de réflexion stratégique ayant fait évoluer la conception même d'ASPIC sans toucher une ligne de code (voir Réflexions stratégiques, section 14), Jean-Marc a fait évoluer le format du numéro de version pour que ce type d'avancée soit tracé au même titre qu'une évolution de code, sans jamais mélanger les deux :

- Format : `V<majeur>.<code>.<conception>` (ex. `V1.12.14`), sans zéro de tête sur aucun des trois nombres — pas de largeur fixe supposée à l'avance.
- `<code>` : inchangé par rapport à la règle déjà en place depuis le début (incrémenté à la main une seule fois par session avec du code réellement livré et poussé, jamais à chaque fichier reçu).
- `<conception>` : reprend le numéro de la dernière section **créée** dans les Réflexions stratégiques — jamais un simple complément apporté à une section déjà existante. Critère de Jean-Marc pour ouvrir une nouvelle section plutôt qu'un addendum : le jugement qu'une évolution de la conception est **majeure**, y compris sur un sujet déjà effleuré auparavant (auquel cas la nouvelle section peut reprendre l'ancien titre suivi de *"[Évolutions majeures]"*) — une évolution mineure ou un abandon reste un addendum dans la section existante, sans faire avancer ce compteur. Les "trous" de numérotation que ça peut produire (ex. de 10 à 28) sont acceptés sciemment par Jean-Marc, ce n'est pas une anomalie à corriger.
- `<majeur>` : change uniquement quand Jean-Marc juge qu'ASPIC franchit un cap de maturité important — décision, pas calcul. À cette occasion, `<code>` repart à 1 (V1.58 → V2.1, jamais V2.59) tandis que `<conception>` continue sa suite normale sans saut ni retour à 1 (V1.58.67 → V2.1.68), puisque franchir ce cap est lui-même consigné comme une nouvelle section des Réflexions stratégiques.

**Partage de responsabilité pour signaler un changement de version, en début ou en fin de session :** si Jean-Marc sait dès le début d'une session que le code va évoluer, il peut demander à Claude de faire évoluer `<code>` immédiatement plutôt que d'attendre la fin de session. Pour `<conception>`, par défaut c'est à Claude de juger et de signaler en fin de session si l'évolution a été assez majeure pour justifier une nouvelle section — sauf si Jean-Marc sait déjà en début de session que ce sera le cas, auquel cas il le dit d'emblée (c'est par exemple déjà acté pour la session suivant celle du 6 septembre 2026).

**Sur la pérennité des trois documents, précisé le 6 septembre 2026 :** Jean-Marc prévoit qu'un jour ce journal de développement (résumé/index, et les sections détaillées de `/journal`) sera repris et expurgé de ce qui sera devenu inutile — en conservant les anciennes versions via l'historique Git, projet non commencé et pas à l'ordre du jour. **Les Réflexions stratégiques, en revanche, ne seront jamais expurgées** : la méthode d'écriture qu'on vient d'adopter (addendum sur une évolution mineure, nouvelle section sur une évolution majeure, jamais de réécriture de l'existant) fait de ce document une trace chronologique complète et volontairement définitive de l'évolution de la pensée stratégique — utile en particulier pour retrouver, en relecture, des pistes un moment abordées puis laissées de côté qui mériteraient d'être reprises.

## Sommaire des sections (`/journal` sur GitHub)

- 00. Présentation
- 01. Contexte et décision d'architecture
- 02. Modèle de données
- 03. Architecture technique
- 04. Fichiers de l'application
- 05. Points de friction
- 06. Pistes pour la suite
- 07. Statut actuel
- 08. Écran d'identification
- 09. Écran liste des contacts
- 10. Écran détail du contact
- 11. Traitements de données de l'écran détail
- 12. Notion de session utilisateur
- 13. Prochaines étapes côté frontend
- 14. Pivot sur le modèle de prospection
- 15. Implémentation session utilisateur
- 16. Panneau de détail du contact — création/suppression
- 17. Panneau détail redimensionnable
- 18. Formulaire de prospect externe
- 19. Navigation entre contacts en panneau détail
- 20. Dépôt GitHub et mirroir Gitea
- 21. MIRADOR — base d'authentification centralisée
- 22. Badge société et avatar utilisateur
- 23. Push GitHub en SSH depuis le VPS
- 24. MIRADOR branché
- 25. MIRADOR validé à deux utilisateurs
- 26. ToDoList
- 27. Pilotage vocal
- 28. Écran de fond
- 29. Interprétation vocale des contacts par LLM
- 30. Chantier des consignes — moteur générique

*(Numérotation et titres repris du découpage fait par Jean-Marc le 31 août 2026, légèrement reformulés par lui à cette occasion — se référer aux fichiers eux-mêmes pour le libellé exact. Section 27 (Pilotage vocal) validée de bout en bout et son fichier définitif déposé dans `/journal` le 2 septembre 2026. Section 28 (Écran de fond) ouverte le 2 septembre 2026, toujours **en cours** — passée d'une maquette graphique exploratoire à un premier essai fonctionnel réel, puis (soirée du 2 au 3 septembre) à une pastille de comptage sur le classeur Contacts et à un premier affichage réel des post-its personnels sur le tableau de liège, puis (8 septembre 2026, matin) à un bureau à trois fonds interchangeables (liège actuel, futur écran assistants, futur tableau de bord) navigables par deux flèches, avant-plan désormais séparé du code des fonds, puis (9-10 septembre 2026) à un écran 2 ("assistants") réellement présenté (portraits, couleurs, rôles) et à une nouvelle répartition des 9 classeurs suivant le cycle de vie d'une affaire, puis (10 septembre 2026, soir) au renommage "collaborateurs" et à deux outils plein écran intégrés à cet écran 2 pour construire et tester l'identité de chaque collaborateur, avec un premier dialogue réel dans ASPIC via l'API Anthropic — fichier de section mis à jour ce jour-là, à déposer par Jean-Marc, voir Statut actuel. Section 29 (Interprétation vocale des contacts par LLM) ouverte et son fichier définitif déposé le 4 septembre 2026 après validation de bout en bout sur un premier corpus réel ; fichiers de section à déposer par Jean-Marc, voir Statut actuel. Section 30 (Chantier des consignes — moteur générique) ouverte le 6 septembre 2026, fichier définitif rédigé le soir même après validation de bout en bout du mécanisme sur des cas réels ; **substantiellement complétée le 7 septembre 2026** (hiérarchisation cohérence/Tests/IA, traçabilité de l'agent, `REA_NomAffiche`, premier appel IA réel dans une consigne avec avertissement bloquant) ; **complétée à nouveau le 8 septembre 2026** (unicité mail/portable, retrait des points sur les numéros, échecs de `consigne_completer_code_postal()` rendus non-silencieux) — fichier de section mis à jour à déposer par Jean-Marc, voir Statut actuel.)*

## Statut actuel (2-10 septembre 2026)

**Écrans "Identification" et "Liste des contacts"** (avec panneau détail intégré) : aboutis depuis le 25 août 2026, testés en production. **Prospection** (formulaire externe, vérification mail, envoi de doc) : livrée et testée en conditions réelles le 26 août 2026 (section 18). **Dépôt Git** en place depuis le 27-28 août (section 20), avec circuit de livraison FileZilla → SSH VPS → `git push` (section 23) — l'écriture directe par Claude reste bloquée côté proxy Anthropic, contournement adopté sans gêne. **MIRADOR** (authentification centralisée multi-bases, identifiant = email) branché et validé à deux utilisateurs le 30 août 2026, déployé sur `aspic.mvl-tls.fr` (développement) et `crm.aspic.bzh` (test), chacun avec son propre environnement Docker (sections 21, 24, 25).

**31 août 2026 : ToDoList.** Nouvel écran, devenu l'écran d'accueil post-connexion (la liste des contacts passe dans le menu hamburger). Table `ASP_ToDoList`, trois indicateurs d'urgence par pastille (rouge = à faire sans date ou en retard, orange = à faire dans les temps, vert = réalisé), tri par urgence calculé côté PHP. Nouveaux endpoints `todolist.php` et `utilisateurs.php`, nouvel écran `liste_todolist.html`. Livré, testé (Playwright) et déployé — version **V1.004**.

**1er septembre 2026 : migration du sous-domaine de bêta test.** L'environnement de test bascule de `aspic.bzh` vers `crm.aspic.bzh`, pour libérer la racine du domaine en vue d'un futur site de promotion de la solution (voir réflexions stratégiques, section 7). Aucun changement fonctionnel côté application.

**1er-2 septembre 2026 : pilotage vocal — de "Lilou" à un système multi-agents (V1.005 puis V1.006).** Détail complet en section 27 du journal (`/journal` sur GitHub), fichier définitif déposé le 2 septembre après validation de bout en bout. Résumé : nouveau bouton micro dans le bandeau, comportement centralisé dans `micro.js`, reconnaissance vocale réelle (API Web Speech, écoute continue). Un "mode notation" capture une dictée libre entre une phrase d'ouverture et une phrase de clôture/annulation, sans interprétation à ce stade (corpus brut, interprétation prévue plus tard via n8n). Stockage pivoté d'un fichier texte défaillant vers une table `ASP_ConsignesVoix`, avec un type par ligne (`CVX_Type` : ouverture/contenu/cloture/annulation) pour qu'un futur automatisme sache exploiter un lot sans ré-analyser le texte brut.

Le système, initialement à agent unique ("Lilou"), a été généralisé le 2 septembre à plusieurs assistants IA nommés (table `ASP_Agents`, endpoint `agents.php`, `lilou_notes.php` renommé `agent_notes.php`) — chaque agent portant ses propres graphies alternatives tolérées (`AGN_Variantes`, pilotable en base sans code) et un agent par défaut (`AGN_Defaut`) pour ne plus jamais figer un nom précis dans le code. Un incident de confidentialité (bribes d'un appel téléphonique captées par un traçage de débogage resté actif) a conduit au retrait immédiat de ce traçage et à l'ajout d'une coupure automatique du micro après quelques minutes d'inactivité. Après plusieurs essais réels montrant des confusions de reconnaissance récurrentes, Jean-Marc a retiré deux agents (Lilou, Karl) plutôt que d'empiler des tolérances risquant de créer de faux déclenchements ou de mal vieillir face à la diversité des accents/prononciations — liste active : Viktor, Matilda (par défaut), Léon, Nikita. Version incrémentée une fois pour cette session, **V1.006**.

**2 septembre 2026 (suite) : écran de fond — d'une maquette graphique à un premier essai fonctionnel (V1.007).** Dans le prolongement de la réflexion "bureau à l'ancienne" (Réflexions stratégiques, section 11), Jean-Marc a d'abord engagé une maquette graphique (tableau en liège, post-it par agent IA, outil Claude Design) — non tranchée, jamais codée. En reprise de session le même jour, changement de cap : plutôt qu'une maquette stylisée, un premier **essai fonctionnel réel** ("c'est juste un test"), bâti sur une photo de scène de bureau fournie et recadrée par Jean-Marc lui-même (`ecran_fond.jpg`, 1024×457), affichée en plein écran juste après l'identification (`background-size:contain`). Un système de coordonnées calé sur l'image de référence (converties en position réelle par une fonction `positionner()`) permet de superposer des éléments interactifs précisément sur les objets photographiés. Livré dans ce premier essai : classeur "Contacts" cliquable, étiquette tournée, chevalet avec le prénom réel de l'utilisateur (`USR_Prenom`), micro cliquable en test d'affichage seul, numéro de version affiché. Version **V1.007**.

**2-3 septembre 2026 (nuit) : pastille du classeur, conception et premier affichage réel du tableau de post-its (V1.008).** Session enchaînée sur la même soirée, au départ pour une petite correction avant d'ouvrir le vrai chantier du tableau de liège.

*Pastille de comptage sur le classeur Contacts.* À la demande de Jean-Marc, une pastille ronde affiche désormais, sous le trou cerclé de métal du classeur "Contacts", le nombre réel de contacts actifs de la table (nouveau paramètre `contacts.php?compte=1`, comptage seul sans charger la liste complète). Couleur de fond calculée par assombrissement (×0,55) de la teinte réelle du classeur mesurée sur la photo, chiffre blanc gras, liseré blanc. Réduite en taille et le liseré adouci après premier retour de Jean-Marc sur son écran ("trop présente") — diamètre 22→17px (référentiel image), liseré 2px/85%→1,5px/40% d'opacité.

*Conception du tableau de liège (vision actée, partiellement codée).* Reprise du principe "bureau à l'ancienne" : le mur de la photo est confirmé être du **vrai liège** (texture visible au zoom, pas une couleur unie) — ça a orienté le choix graphique des post-its vers une punaise ronde en haut, cohérente avec la matière réelle. Principe de répartition de l'écran retenu : 70% de la largeur pour les assistants IA (Viktor, Matilda, Léon, Nikita), 30% fixe pour Jean-Marc lui-même — logique assumée : les assistants traitent vite (peu de post-its en attente à tout instant), l'humain accumule davantage avant de traiter, donc plus de place. Règles actées pour la part "assistants" (**non codées ce soir**, la ToDoList des assistants n'existant pas encore réellement) : part de chacun = (ses tâches en attente ÷ total tâches en attente tous assistants) × 70% ; l'assistant par défaut (Matilda) toujours le plus à gauche s'il a des tâches, puis les autres classés par charge décroissante ; un assistant sans tâche en attente disparaît entièrement du tableau (pas de colonne vide) ; couleur de post-it personnalisée par assistant (`AGN_Couleur`, à faire). Jean-Marc a fait remarquer, et Claude a vérifié dans le code, que la gestion de tâches par assistant n'est pas une nouvelle architecture à inventer : `TDL_ToDoUser`/`TDL_RealUser` dans `ASP_ToDoList` sont déjà des champs génériques non restreints à un humain (le commentaire d'en-tête de `todolist.php` anticipait déjà qu'un agent IA puisse assigner une tâche à un autre utilisateur) — il suffira d'ajouter un discriminant humain/agent le jour venu. Les écrans de gestion actuels (`liste_todolist.html`, `todolist.php`) sont conservés tels quels et **pas encore reliés à la navigation** depuis l'écran de fond (clic sur un post-it actuellement sans effet).

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 + assistants) — repéré comme déjà largement couvert par les champs existants `TDL_RealDate`/`TDL_RealUser`/`TDL_RealText` de `ASP_ToDoList` (une tâche marquée faite porte déjà qui, quand, avec quel commentaire), donc pas besoin a priori d'une nouvelle table pour un premier jet, seulement d'un écran de consultation à construire un jour.

*Capacité du tableau — refus explicite d'un ascenseur.* Jean-Marc a explicitement écarté toute idée de défilement/ascenseur sur le tableau ("ça casserait la logique du vrai bureau, et surtout m'inciterait à cumuler les post-its") au profit d'une capacité finie avec message de blocage. Ajout dans `todolist.php` : constante `CAPACITE_TABLEAU_PAR_UTILISATEUR = 20` (valeur provisoire, posée avant d'avoir les vrais pixels, à faire évoluer) et vérification à la création (POST) — au-delà de la capacité, refus (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 n'est jamais bloquée (elle n'occupe pas de post-it). Posée dans `todolist.php` plutôt que côté écran, donc valable aussi le jour où la voix créera des tâches directement.

*Premier affichage réel des post-its personnels.* Dans `ecran_fond.html` : zone occupant 30% de la largeur depuis le bord droit de l'écran, du haut de l'image jusqu'à juste au-dessus du chevalet, avec une grille de 4 colonnes × 5 lignes = 20 cases — volontairement alignée sur `CAPACITE_TABLEAU_PAR_UTILISATEUR`. Données réelles de `todolist.php`, filtrées côté client sur l'utilisateur connecté (`TDL_ToDoUser`) et sur les tâches non réalisées (une tâche marquée faite libère sa place immédiatement). Chaque post-it reste dans sa propre case (léger jitter de rotation/décalage calculé de façon déterministe à partir de `TDL_Incr`, donc stable d'un rechargement à l'autre) — Jean-Marc a autorisé un chevauchement partiel entre post-its mais a explicitement refusé tout empilement en tas (illisible, imprécis au clic) ; rester dans sa case garantit qu'on ne recrée jamais ce cas. Punaise ronde, pastille d'urgence rouge/orange bien visible en coin haut-droit (jamais verte : le vert quitte le tableau dès qu'une tâche est réalisée), infobulle au survol avec le texte de la tâche, pas de texte visible sur le post-it lui-même, clic sans effet pour l'instant. Testé avec des données simulées (9 puis 23 tâches, plusieurs groupes d'urgence, tâches d'un autre utilisateur et déjà réalisées pour vérifier le filtrage) — rendu confirmé conforme par Jean-Marc sur image de synthèse avant dépôt.

Point relevé par Jean-Marc en toute fin de session, à traiter plus tard : les règles actuelles de calcul des pastilles rouge/orange/vert (`calculerGroupe()` dans `todolist.php`) risquent de donner un tableau surchargé de rouge/orange puisque le vert disparaît désormais immédiatement du tableau — à revoir, non traité ce soir.

Version incrémentée une seule fois pour l'ensemble de cette session (pastille classeur + capacité tableau + affichage post-its), conformément à la règle d'une incrémentation par session : **V1.008**.

**3 septembre 2026 : homogénéisation liste des contacts / écran de fond, adaptation à la nouvelle photo de bureau (V1.009).** Détail complet en section 28 du journal (`/journal` sur GitHub). Résumé : nettoyage des bandeaux de `liste_contacts.html` (hamburger, avatar, badge société et micro retirés du haut, regroupés avec le logo et la version dans la barre du bas désormais commune aux deux écrans) ; icône Mévélia Solutions ajoutée devant le logo ASPIC (et en favicon) avec infobulle ; bug corrigé où Échap sur l'écran de fond ouvrait par erreur la ToDoList ; correctif `.htaccess` livré pour un problème récurrent de cache navigateur (déploiement non encore confirmé) ; nouvelle photo `ecran_fond.jpg` fournie par Jean-Marc (chevalet physiquement retiré de la scène, 13px de bureau en moins / de liège en plus), tous les positionnements calés sur l'image repris avec un décalage de +13px mesuré par analyse de pixels ; bloc identité (société/prénom/logo/version) reconstruit en position fixe de viewport, identique sur les deux écrans, après une première tentative erronée de le caler sur les coordonnées de la photo ; bug d'alignement horizontal entre les deux écrans corrigé (résidu de calcul `--sb-width` sans rapport avec cette barre). Version incrémentée une seule fois pour l'ensemble de cette session : **V1.009**. Documentation utilisateur mise à jour en fin de session pour refléter le nouvel écran d'accueil et la disparition du hamburger.

**3 septembre 2026 (soirée) : micro du bureau branché sur la reconnaissance vocale réelle, puis détourné pour constituer une banque de dictées de test (V1.010).** Détail complet en sections 27 et 28 du journal. Résumé : `micro.js` cherche désormais le bouton micro par `#bouton-micro` (bandeau) ou, à défaut, `#micro-desk` (écran de fond) — un seul comportement partagé, sans dupliquer la logique — et le micro du bureau déclenche bien la reconnaissance vocale réelle depuis ce soir. Discussion stratégique dans la foulée (Réflexions stratégiques, section 12) : Jean-Marc, après avoir montré l'application à sa compagne (confrontée à SAP dans son travail), s'inquiète de la fiabilité du pilotage vocal une fois étendu aux contacts, au catalogue, aux devis, à la facturation — distinction actée avec Claude entre le problème de reconnaissance du mot déclencheur (déjà traité, sa surface d'erreur ne grandit pas avec les modules) et celui de l'interprétation d'une dictée bien captée (à traiter via un LLM à sortie structurée contre un catalogue d'actions, le RAG/pgvector restant réservé à la recherche floue dans un corpus, pas au déclenchement d'action). Décision : constituer d'abord un vrai corpus de dictées avant d'écrire la moindre règle. Micro du bureau temporairement détourné vers un nouvel outil de mise au point (`micro_test.js`/`dictees_test.php`, table `ASP_DicteesTest`, thème "Gestion des Contacts") — écoute continue sans mot déclencheur, restitution au fur et à mesure dans une fenêtre dédiée, aucune suppression possible même pour un essai raté (décision explicite de Jean-Marc : la banque doit refléter la réalité). Premier essai réel concluant le soir même. Version incrémentée une seule fois pour l'ensemble de cette session (branchement réel + outil de test) : **V1.010**.

**3 septembre 2026 (nuit) : dictée d'adresses mail — diagnostic et deux bugs de robustesse corrigés dans l'outil de banque de dictées (V1.011).** Détail complet en section 27 du journal ; comparatif de prix des API de reconnaissance vocale en réflexions stratégiques, section 12 (addendum du même soir). Résumé : les premiers essais réels de Jean-Marc ont montré un taux d'échec très élevé (~1/50) sur la dictée d'une adresse mail. Diagnostic à partir d'exports réels de `ASP_DicteesTest` : trois causes distinctes — vocabulaire de ponctuation dicté ("point", "tiret", "arobase") converti de façon incohérente par le moteur gratuit du navigateur, segmentation de la dictée en plusieurs lignes non fiable, et des lettres purement avalées sur des mots sans support linguistique réel (ex. "mvl-tls.fr" → "mvtls.fr", perte acoustique jamais rattrapable après coup). Ajout d'un "mode adresse" dans `micro_test.js` : buffer explicite (activé/désactivé au clic, pour s'affranchir de la segmentation) + dictionnaire de conversion + validation de forme + compteur de conformité en direct ; nouvelle colonne `DCT_TexteNormalise` (ajoutée en base par Jean-Marc). En testant, deux bugs de robustesse préexistants découverts grâce à un bloc de diagnostic temporaire ajouté en direct (affichage de chaque démarrage/arrêt/erreur du moteur) : la fenêtre de test était entièrement vidée à chaque redémarrage automatique du moteur (invisible jusqu'ici, devenu très gênant avec une dictée hésitante) ; et une boucle de redémarrage incontrôlée pouvant atteindre plus de 1800 cycles en quelques secondes, sans aucune protection dans le code d'origine. Les deux corrigés le même soir (réinitialisation de fenêtre restreinte à l'ouverture volontaire ; coupe-circuit après 5 redémarrages rapides consécutifs). Sur un tout petit échantillon (4 essais) après correctifs : 2 adresses parfaitement normalisées, 1 quasi-bonne, 1 ratée par oubli de cliquer "Valider" entre deux adresses distinctes — encourageant, mais échantillon trop petit pour conclure. Piste d'une API payante avec vocabulaire personnalisé (Google Cloud, Deepgram) documentée et chiffrée en réserve, non retenue pour l'instant (coût en dollars négligeable, mais changement d'architecture réel). Version incrémentée une seule fois pour l'ensemble de cette session : **V1.011**. Jean-Marc prévoit une campagne de tests en nombre le 4 septembre et enverra les résultats.

**4 septembre 2026 : interprétation vocale des contacts par un LLM à sortie structurée (V1.012).** Détail complet en section 29 du journal. Résumé : premier outil réel d'interprétation, dans le prolongement de la banque de dictées "Gestion des Contacts" — `contact_ia_interprete.php` (appel OpenAI `gpt-5.6-luna`, JSON Schema strict construit à partir des tables réelles ASP_Statuts/ASP_Professions/ASP_Agents/ASP_Actions, re-validation défensive après réponse), `contact_ia_valide.php` (seul point d'écriture, table à part `ASP_PropositionsContact` — ne crée jamais de contact ni de profession réels), `contact_ia_panel.js` (panneau flottant sur le micro de l'écran de fond, remplace `micro_test.js`). Décision architecturale actée : l'attribution d'un assistant par défaut quand aucun n'est nommé relève d'un futur traitement n8n, pas de cette couche d'interprétation qui doit rester un enregistreur honnête de ce qui est réellement dit. Détection de l'action "ajouter le contact" (libellé fixe, toujours classée en premier) confirmée comme une vraie décision du LLM porté par le prompt, pas un cas codé en dur — vérifié avec Jean-Marc. Zone actions simplifiée en 3 champs de texte libre (au lieu d'un motif dynamique existant/nouveau par ligne, jugé trop lourd pour cet essai). Nombreuses itérations d'ergonomie du panneau : dimensionnement immédiat à la taille maximale disponible avec défilement unique, lisibilité des listes déroulantes, arrêt automatique du micro après 3,5s de silence, redémarrage automatique du micro et panneau qui reste ouvert après validation (pour dicter plusieurs contacts à la suite), bouton "Abandonner" retiré au profit d'Échap seul. Relecture d'un premier corpus réel (11 essais) : résultats globalement encourageants, un bug d'extraction identifié (adresse mail non nettoyée d'un mot d'appel et d'un accent) et une possible troncature de fin de dictée par le minuteur de silence restent des points ouverts, non corrigés à la clôture. Jean-Marc a par ailleurs formulé une réflexion pour une prochaine session : séparer formellement les actions utilisables par l'utilisateur humain (menu/clavier) de celles utilisables par le LLM vocal, avec un vocabulaire d'actions unique et cohérent entre les deux voies d'accès. Version incrémentée une seule fois pour l'ensemble de cette session : **V1.012**.

**6 septembre 2026 : chantier des consignes — un moteur générique pour sortir du code en dur (V1.14.15).** Détail complet en section 30 du journal, fil conceptuel complet en Réflexions stratégiques, section 15. Résumé : reprise le soir même, sous forme concrète, de la distinction règles/consignes esquissée le matin — première mise en œuvre volontairement circonscrite à la fiche Contacts (création/modification). Deux tables créées par Jean-Marc (`ASP_Fonctions` : catalogue de fonctions génériques ; `ASP_Consignes` : instructions actives par contexte/champ), un moteur générique unique (`moteur_consignes.php`, fonction `appliquerConsignes()`) qui lit ces tables à l'exécution et applique traitements (mise en forme silencieuse) puis tests (validation, avec message d'erreur personnalisé), et une bibliothèque de fonctions du catalogue (`consignes_fonctions.php` : `MAJUSCULE`, `NON_VIDE`, `PREMIERE_LETTRE_MAJUSCULE`). `contacts.php` réduit à un seul appel au moteur, plus aucun contrôle de champ écrit en dur. Détour initial corrigé par Jean-Marc (Claude avait d'abord codé en dur un contrôle par champ au lieu du moteur générique demandé), puis abandon délibéré de la validation en temps réel côté écran au profit de la robustesse — révélant au passage un bug préexistant (message d'erreur générique affiché au lieu du message réel du serveur), corrigé. Ajustements d'interface demandés en cours de test : toast d'erreur centré et rouge sur le panneau de saisie, rendu correct des retours à la ligne saisis dans un message d'erreur. Preuve de concept validée par Jean-Marc en fin de session : ajout de nouvelles consignes (`NON_VIDE` sur Prénom et Ville) sans la moindre modification de fichier PHP/JS, comportement immédiatement actif avec les fichiers déjà livrés. Version incrémentée une seule fois pour l'ensemble de cette session, sur les deux compteurs anticipés dès le début (code et conception) : **V1.14.15**.

**7 septembre 2026 : chantier des consignes — hiérarchisation, traçabilité et premier appel IA réel dans une consigne [Évolutions majeures] (V1.15.17).** Détail complet en section 30 du journal, fil stratégique en Réflexions stratégiques, section 17. Résumé : reprise le lendemain matin par une session dédiée au lien entre Claude et l'ordinateur de Jean-Marc (voir Réflexions stratégiques, section 16 — chantier finalement clos, sans suite), puis, le soir, extension substantielle du chantier des consignes ouvert le 6 septembre. Un badge de chargement générique (`consignes_apercu.php`, convention de fonction jumelle `_seraitDeclenchee`) prévient désormais l'utilisateur qu'un appel IA va réellement se produire avant qu'il ne soit lancé. Bug de coût découvert par Jean-Marc et corrigé structurellement : une soumission vouée à échouer sur un Test déclenchait quand même, en pure perte, un Traitement IA coûteux — le moteur exécute désormais trois phases strictement séquentielles (Traitements de cohérence, puis Tests, puis seulement si tout est passé les Traitements IA), sur la base d'un seul attribut déjà présent au catalogue (`FON_VisuelAttenteIA`). Traçabilité renforcée : un nom d'agent resté codé en dur ("Mat") a été remplacé par une source unique de vérité (`CNS_Agent`, la consigne elle-même) ; nouvelle colonne `REA_NomAffiche` sur `ASP_Realisations`, un instantané écrit une seule fois à la création (session utilisateur côté humain, nom d'agent côté IA) plutôt qu'une jointure recalculée à la lecture — écartée pour sa complexité et son incompatibilité avec une future architecture multi-bases (MIRADOR). Renommage `ASP_Agents.AGN_Nom` → `AGN_Prenom` à l'origine d'une régression du pilotage vocal (cinq fichiers pré-existants non mis à jour, "aucun impact" affirmé à tort par Claude sans avoir vérifié) — corrigée le soir même, leçon actée pour la suite (grep systématique avant d'affirmer l'absence d'impact d'un changement de schéma). Nouveau Test générique `consigne_sans_chiffre()`, appliqué par Jean-Marc sur Nom/Prénom/Ville sans retoucher un seul fichier. Premier vrai appel IA dans une consigne : `consigne_completer_code_postal()` journalise désormais un échec (ville ambiguë, ex. Paris) au lieu de rester silencieuse, via une nouvelle clé réservée générique `_avertissement` affichée immédiatement à l'écran — trois itérations d'affinage de ce retour visuel dans la soirée, jusqu'à un message réellement bloquant (bouton "Valider" explicite, pas de disparition automatique) qui ne fait que finaliser l'affichage sans jamais redéclencher un enregistrement. Version incrémentée deux fois au fil de cette même journée de travail (code en tout début, conception en fin de session, section 17 des Réflexions stratégiques étant jugée majeure) : **V1.15.17**.

**8 septembre 2026 : session de réflexion stratégique — concept de "Mission" et faisabilité d'un dialogue simulé avec Claude (V1.15.18).** Aucune ligne de code applicative touchée ce jour — premier cas réel d'une session faisant avancer uniquement la partie `<conception>` du numéro de version depuis l'instauration du format à trois niveaux (voir consigne du 6 septembre 2026 ci-dessus). Détail complet en section 18 des Réflexions stratégiques : clarification du fonctionnement général d'un "agent" IA (prompt, contexte, outils, boucle) ; conception d'un nouveau concept — la **Mission** — pour structurer les objectifs confiés à un agent dans la durée (trois niveaux de mémoire, clôture décidée par Jean-Marc, tags en nuage envisagés pour retrouver des missions similaires, RAG gardé en réserve) ; et confirmation de la faisabilité technique d'un dialogue simulé avec Claude intégré à ASPIC via l'API Anthropic (même schéma d'intégration que l'appel IA déjà en place pour l'interprétation vocale, prompt système gardé secret côté serveur, bulles de dialogue façon SMS). Chantier à ouvrir prochainement, rien conçu ni codé à ce stade.

**8 septembre 2026 (matin) : écran de fond — trois fonds interchangeables derrière un avant-plan désormais séparé du décor (V1.16.18).** Détail complet en section 28 du journal. Résumé : Jean-Marc a constaté que l'écran de fond, limité à un seul décor (le tableau de liège), ne suffira pas à tout gérer, et a posé le principe de trois fonds navigables par deux flèches, derrière un même avant-plan (bureau, classeurs, micro, carnet, téléphone) qui ne change jamais — l'écran 1 restant l'actuel tableau de liège, l'écran 2 un futur écran "assistants" (fond en tasseaux de bois gris, présentation encore à concevoir), l'écran 3 un futur tableau de bord (fond tableau blanc). Décisions actées avant codage : code de l'avant-plan et code des fonds séparés ; les trois fonds codés en dur plutôt qu'en liste extensible ("il faut s'autoriser à coder ça en dur") ; animation de glissement au changement de fond, dont le sens dépend de la flèche pressée (l'écran n+1 entre par la droite en chassant l'écran actuel vers la gauche, et inversement) ; l'avant-plan reste visible sur les trois écrans, y compris le futur tableau de bord ; aucune mémorisation du fond choisi d'une session à l'autre (toujours l'écran 1 à l'ouverture) ; flèches posées sur le bureau à droite. Point corrigé en cours de route : les post-its, d'abord traités par erreur comme un élément fixe de l'avant-plan, doivent en réalité rester solidaires du panneau de liège et disparaître/réapparaître avec lui — résolu par une technique de réattachement du même nœud DOM de post-its à la bonne "diapositive" de fond, sans dupliquer sa logique de position. Le nouvel avant-plan fourni par Jean-Marc étant un dessin recomposé (pas la même photo que l'ancienne), l'ensemble des repères (classeurs, micro, pastille, zone de post-its) a dû être entièrement remesuré par analyse de pixels plutôt qu'ajusté par simple décalage — remesure reconduite une seconde fois après qu'une version corrigée de l'avant-plan (traces blanches et halo du micro retouchés) s'est révélée légèrement décalée par rapport à la première. Nombreux réglages fins en fin de session à partir des retours directs de Jean-Marc sur son propre écran (taille et position des flèches, position de l'icône du micro, position de la pastille de comptage des contacts). Version incrémentée une seule fois pour cette session : **V1.16.18** (`<code>` avancé dès le début à la demande de Jean-Marc, `<conception>` inchangé — évolution jugée comme une continuation du chantier de l'écran de fond, pas une nouvelle section des Réflexions stratégiques).

**8 septembre 2026 (après-midi) : petits chantiers de finition — position du micro, unicité mail/portable, retrait des points, robustesse du code postal auto, toast bloquant sans bouton (V1.17.18).** Aucune réflexion stratégique nouvelle (`<conception>` inchangé, pas de nouvelle section des Réflexions stratégiques) ; `<code>` avancé dès le début de session à la demande de Jean-Marc. Résumé, dans l'ordre traité :

- *Position de l'icône micro sur l'écran de fond.* Le dernier réglage du 8 septembre au matin (`ICONE_CENTRE_X = 522`) allait trop loin vers la droite — repéré par Jean-Marc en testant. Ramené à `515` dans `ecran_fond.html` après essai réel. L'icône en état "écoute" reste masquée par un panneau superposé sur l'écran de test actuel de Jean-Marc — signalé, volontairement non traité (pas prioritaire).
- *Unicité mail/portable (chantier des consignes, section 30).* Deux nouveaux Tests dans `ASP_Fonctions`/`consignes_fonctions.php` : `MAIL_UNIQUE` et `PORTABLE_UNIQUE`, deux fonctions dédiées (`consigne_mail_unique()`, `consigne_portable_unique()`) plutôt qu'une seule fonction générique paramétrable par champ — décision explicite de Jean-Marc pour qu'un futur opérateur du catalogue ne puisse pas appliquer par erreur une contrainte d'unicité à un champ où elle n'a pas de sens (ex. Prénom, où deux homonymes sont normaux). Les deux s'appuient en interne sur un même utilitaire privé (`valeurDejaUtilisee()`, hors catalogue) pour ne pas dupliquer la requête SQL. A nécessité une première extension du contrat des Tests à un champ dans `moteur_consignes.php` : ces fonctions peuvent désormais recevoir deux paramètres de plus, `$pdo` et `$idExclusion` (identifiant de la fiche en cours de modification, pour qu'une consigne d'unicité ne se bloque jamais elle-même en retrouvant sa propre valeur déjà enregistrée — null en Création) — sans effet sur les Tests existants, qui ignorent simplement ces arguments en trop. `contacts.php` (PUT) transmet désormais cet identifiant au moteur.
- *Retrait des points dans les numéros de téléphone.* Nouveau Traitement générique `RETIRER_POINTS` (`consigne_retirer_points()`), sur le même principe que `SANS_CHIFFRE` (7 septembre) : une seule fonction réutilisable, appliquée par Jean-Marc à `CNT_Portable` et `CNT_Tel` via deux lignes dans `ASP_Consignes`, sans aucune fonction par champ.
- *Bug corrigé : échecs silencieux de `consigne_completer_code_postal()`.* Jean-Marc a repéré qu'une ville inconnue de l'IA n'aboutissait à aucune trace dans les réalisations, contrairement au cas "ville ambiguë" (type Paris) déjà traité le 7 septembre. Diagnostic : deux sorties anticipées de la fonction (clé API absente ; échec réseau/HTTP) renvoyaient les valeurs inchangées sans jamais poser ni `_realisation` ni `_avertissement`. Corrigé : l'échec réseau/HTTP pose désormais les deux (un appel a réellement été tenté, donc journalisé comme le cas "ville ambiguë") ; la clé API absente pose seulement l'avertissement écran (aucun appel réellement tenté, rien à journaliser comme coût engagé).
- *Toast bloquant du code postal : bouton "Valider" retiré, Échap seul.* Le bouton du toast bloquant (avertissement IA, 7 septembre) fonctionnait, mais Échap sur ce même toast fermait EN PLUS le panneau détail en dessous — le gestionnaire clavier global ne savait pas qu'un toast bloquant était ouvert. Corrigé dans `liste_contacts.html` : bouton retiré, le toast mémorise son rappel de fermeture (`toastValidationEnCours`) et le gestionnaire Échap global le vérifie désormais EN TOUT PREMIER, avant le menu contextuel du panneau détail — Échap referme alors le toast seul.
- *Ménage à prévoir sur `ASP_Consignes`.* Jean-Marc a repéré des champs qui lui semblent redondants dans la structure de cette table (`CNS_TexteDefinition`/`CNS_TexteAffiche` en particulier) — à examiner ensemble, rien fait ce jour.
- *Confusion résolue en cours de session :* un doute initial de Jean-Marc sur la persistance du correctif "Échap" (le bouton "Valider" restait visible après un premier essai) provenait du cache navigateur, pas d'un problème de déploiement — confirmé après rechargement forcé.

Version incrémentée une seule fois pour l'ensemble de cette session (uniquement `<code>`) : **V1.17.18**.

**9-10 septembre 2026 : écran 2 ("assistants") — portraits des assistants, nouvelle texture de fond, et réorganisation des 9 classeurs (V1.18.19).** Détail technique complet en section 28 du journal ; fil stratégique de la réorganisation des classeurs en Réflexions stratégiques, section 19. Résumé : nouvelle texture de fond pour l'écran 2 (tasseaux de bois, filigrane retiré) ; conception puis intégration réelle de la présentation des assistants sur cet écran — portraits recadrés en photo d'identité, couleurs pastel par assistant (`AGN_Couleur`), rôle affiché en gras sous le nom (`AGN_Fonction`), colonnes calculées dynamiquement depuis le nombre réel d'agents de `ASP_Agents` (jamais un nombre codé en dur), panneau "Bureau des assistants" dimensionné à son texte dans l'espace restant. Nouvelles colonnes `AGN_Photo` (nom de fichier de la photo, éditée à la main comme `AGN_Variantes`) et `AGN_OrdreAffichage` (tri de l'écran, indépendant de `AGN_Incr`) ajoutées par Jean-Marc à `ASP_Agents`. En parallèle, Jean-Marc a revu la classification des 9 classeurs du bureau pour suivre le cycle de vie réel d'une affaire (Catalogue, Documents, Contacts, Missions, Propositions, Livraisons, Factures, Journalier, Gestion) — mêmes 9 positions physiques, seuls les libellés changent ; un point de vigilance (la pastille de comptage des contacts, positionnée indépendamment du tableau des classeurs) a été identifié et corrigé avant livraison pour continuer à suivre "Contacts" à sa nouvelle position. `<code>` avancé dès le début de session à la demande de Jean-Marc (V1.17.18 → V1.18.18) ; `<conception>` avancé en fin de session (18 → 19), la réorganisation des classeurs étant jugée par Jean-Marc suffisamment structurante pour justifier une nouvelle section des Réflexions stratégiques. Version : **V1.18.19**.

**10 septembre 2026 (soir) : "collaborateurs" — construire et tester l'identité de chaque assistant, premier dialogue réel avec l'API Anthropic (V1.19.21).** Détail technique complet en section 28 du journal ; fil stratégique en Réflexions stratégiques, sections 20 (identité des collaborateurs) et 21 (stockage de documents PDF, discussion architecturale indépendante, non codée). Résumé : dernière étape terminologique "assistants" → "collaborateurs" (habillage seul, `ASP_Agents`/`AGN_*`/`agents.php` inchangés) ; deux outils plein écran ajoutés sous le panneau des collaborateurs — "Construire une identité" (terminal de saisie sur un nouveau champ `AGN_Identite`, endpoint `collaborateurs_identite.php`) et "Tester l'identité" (vraie fenêtre de dialogue, premier appel réel à l'API Anthropic dans ASPIC via le nouvel endpoint `collaborateur_dialogue.php`, modèle `claude-sonnet-5`, prompt système construit à partir de l'identité du collaborateur avec garde-fous explicites — jamais de récitation verbatim de l'identité, avis pouvant diverger de ceux de Jean-Marc). Un bug critique de cascade CSS (`[hidden]` toujours perdant face à une règle d'auteur `display:flex`, quelle que soit la spécificité) a été détecté par test automatisé avant toute livraison — l'overlay serait resté en permanence visible et aurait intercepté tous les clics du bureau dès le chargement de la page — et corrigé par deux règles `[hidden]{display:none}` explicites. Incident de production réel diagnostiqué et résolu le soir même : clé API Anthropic non scopée à un espace de travail (HTTP 400), résolu en recréant la clé correctement scopée. Après validation en conditions réelles par Jean-Marc, resserrement de mise en page demandé point par point (titre remonté, boutons descendus, zone de dialogue agrandie à deux lignes, boutons Envoyer/Fermer côte à côte). Discussion sur la capacité du champ `AGN_Identite` : colonne élargie de `TEXT` à `MEDIUMTEXT` en base par Jean-Marc, l'intention étant que l'identité d'un collaborateur s'enrichisse avec l'usage réel de l'application (missions, réunions) plutôt que de rester figée — indicateur d'occupation en octets réels (UTF-8) ajouté à l'écran de saisie, avec seuil d'avertissement et blocage à l'approche de la limite. `<code>` avancé en tout début de session (V1.18.19 → V1.19.20) ; `<conception>` avancé deux fois au cours de la même session (19 → 21) pour l'ouverture des sections 20 et 21 des Réflexions stratégiques — nouvelle version **V1.19.21**.

**Prochain chantier annoncé par Jean-Marc : gérer les attributions de tâches des assistants.** L'écran 2 ("assistants"/"collaborateurs") est désormais présenté (portraits, couleurs, rôles, identité) mais ne porte encore aucune action réelle de répartition de tâches — à rapprocher des points déjà notés plus bas dans "Reste à faire" (discriminant humain/agent sur `ASP_ToDoList`, répartition dynamique des 70% par charge de tâches, exploitation réelle d'`AGN_Couleur`) — rien de plus précisé à ce stade sur le périmètre exact.

**Reste à faire, noté au passage :**
- Décider s'il faut renforcer le prompt d'extraction pour neutraliser les mots parasites/formules de politesse dictés autour d'une adresse mail (bug identifié le 4 septembre sur le corpus réel, correction non encore actée par Jean-Marc).
- Clarifier l'origine de la coupure de fin de dictée observée sur un essai du 4 septembre (minuteur de silence à 3,5s vs interruption réelle) avant de décider si `DUREE_SILENCE_ARRET_MS` (`contact_ia_panel.js`) doit être allongée.
- Concevoir la séparation entre actions utilisables par l'utilisateur humain (menu/clavier) et actions utilisables par le LLM de saisie vocale, avec "création du contact" formalisée comme action à part entière toujours classée en premier et connue des deux voies d'accès — réflexion actée par Jean-Marc le 4 septembre, non conçue, non codée (voir section 29).
- Vérifier concrètement que le `.htaccess` du dossier `/journal` bloque bien l'accès direct (`curl -I` sur un fichier du dossier doit répondre `403`, pas `200` — point en suspens depuis le 31 août).
- Confirmer le déploiement du correctif `.htaccess` de cache livré le 3 septembre (fichier `htaccess-racine-aspic.txt`, à renommer et déposer à la racine de l'application) — distinct du cache navigateur simple rencontré le 8 septembre (résolu par un rechargement forcé), toujours en suspens.
- Laisser Jean-Marc constituer un vrai volume de dictées sur "Gestion des Contacts" (nouvel outil, voir ci-dessus) avant toute analyse ; puis concevoir le catalogue d'actions et le mécanisme LLM à sortie structurée correspondant (voir réflexions stratégiques, section 12, et journal section 27).
- Récupérer les résultats de la campagne de tests d'adresses mail que Jean-Marc prévoit de mener le 4 septembre (mode adresse de `micro_test.js`) pour mesurer un vrai taux de réussite, sur un échantillon plus significatif que les 4 essais du 3 septembre.
- Retirer le bloc de diagnostic temporaire (`DIAGNOSTIC_ACTIF`/`logDiag`) de `micro_test.js` une fois son comportement confirmé stable sur cette campagne.
- Décider si le cas "deux adresses dictées sans clic Valider entre les deux" (mode adresse) mérite un traitement automatique, ou reste une simple consigne d'usage.
- Si le taux d'échec mesuré début septembre reste trop élevé : évaluer en conditions réelles (pas seulement sur la documentation) Google Cloud Speech-to-Text (phrase hints/boost) et Deepgram (keyterm prompting) avec le vocabulaire métier d'ASPIC — voir réflexions stratégiques, section 12.
- Le problème des lettres avalées sur les mots inventés/sigles (ex. "mvl-tls.fr") reste entier, sans solution de contournement identifiée à ce stade — à garder en tête, pas à considérer comme résolu par le mode adresse.
- Reconnecter `micro.js` (vrai pilotage) sur le micro de l'écran de fond une fois la phase de mise au point terminée — une ligne à changer dans `ecran_fond.html`.
- Étendre `MARQUEUR_FIN_LIGNE` dans `micro.js` pour accepter "puis" en plus de "ensuite" (retour d'usage de Jean-Marc, 3 septembre) — sans urgence.
- Continuer à observer les agents actifs (Viktor, Matilda, Léon, Nikita, Sophia) en usage réel ; ajuster `AGN_Variantes` en base si de nouvelles confusions apparaissent.
- Documentation utilisateur : le panneau de détail du contact, la ToDoList, le pilotage vocal et l'écran des collaborateurs restent à documenter (mise à jour du 3 septembre limitée à l'écran d'accueil et à la liste des contacts ; l'écran des collaborateurs volontairement laissé de côté pour l'instant, tant qu'il ne porte aucune action réelle de gestion, voir 9-10 septembre) — l'outil de banque de dictées, le chantier des consignes et les outils de construction/test d'identité n'ont volontairement pas vocation à y figurer pour l'instant, ce sont des chantiers internes, pas des modules utilisateur finalisés.
- **Gérer réellement les attributions de tâches des assistants (Matilda et les autres)** — chantier annoncé par Jean-Marc le 8 septembre, toujours pas commencé (voir plus haut). Contenu réel de l'écran 3 (tableau de bord) toujours entièrement à concevoir ; décider si les autres objets de l'avant-plan (carnet, téléphone) doivent devenir cliquables ; trancher un jour le sort de la piste "maquette liège + post-its par agent" (Claude Design, mise de côté pour cet essai, pas explicitement abandonnée).
- Concevoir les deux signes graphiques distincts pour les post-its "à corriger"/"à valider" (réflexions stratégiques, section 12) — le premier acté (point d'interrogation), le second encore à choisir.
- Tableau de liège : coder la répartition dynamique des 70% entre assistants par charge de tâches (formule actée, voir Statut actuel) — bloqué tant que la ToDoList des assistants n'existe pas réellement. **À rapprocher du chantier des attributions des assistants.**
- Étendre `ASP_ToDoList`/`todolist.php` pour qu'un assistant puisse être attributaire d'une tâche (discriminant humain/agent à définir) — préalable à la répartition dynamique et à l'exploitation réelle des couleurs de post-it par assistant (`AGN_Couleur`, déjà ajoutée à `ASP_Agents` mais encore inutilisée par aucun écran). **À rapprocher du chantier des attributions des assistants.**
- Écran "journalier" (trace des réalisations, humain + assistants) — donnée déjà quasi disponible (`TDL_RealDate`/`TDL_RealUser`/`TDL_RealText`), écran de consultation à construire.
- Revoir les règles de calcul des pastilles rouge/orange/vert (`calculerGroupe()`) pour éviter un tableau trop chargé en rouge/orange maintenant que le vert quitte le tableau immédiatement.
- Décider du comportement du clic sur un post-it (aujourd'hui inerte) : ouvrir `liste_todolist.html` sur la tâche précise, ou afficher un détail directement sur l'écran de fond.
- Capacité du tableau (20) et taille de la grille (4×5) dans `ecran_fond.html`/`todolist.php` sont des valeurs provisoires posées avant d'avoir les vrais pixels de la version finale — à ajuster ensemble après usage réel prolongé.
- Concevoir le contrat de retour complet à trois issues (silencieux / besoin de précision / question à poser) pour les consignes à appel IA — le 7 septembre n'en a construit qu'un premier incrément à deux issues (succès silencieux / échec avec avertissement bloquant), voir section 30. À généraliser le jour où un second cas concret en montrera le besoin réel, pas par anticipation.
- Écran de gestion des consignes par le boss (au lieu d'`INSERT`/`UPDATE` SQL à la main) — à construire après stabilisation du contrat ci-dessus, pour ne pas le refaire (chantier des consignes, section 30).
- Réflexion sur un catalogue restreint de consignes/fonctions avancées à proposer aux futurs utilisateurs de l'agence, sans leur ouvrir la création libre de A à Z — argument commercial identifié par Jean-Marc le 6 septembre (voir réflexions stratégiques, section 15).
- Accumulation de plusieurs messages d'erreur à la fois dans le moteur de consignes (aujourd'hui, seul le premier test en échec est remonté).
- Gestion des consignes transverses à toute la fiche (`CNS_Champ` NULL, ex. contrôle de doublon) — non traitée par le moteur de consignes actuel.
- Distinction Saisie/Validation réellement exploitée un jour dans le moteur de consignes (temps réel), si le besoin redevient assez fort pour justifier la complexité écartée le 6 septembre.
- Ouvrir le chantier du dialogue simulé avec Claude intégré à ASPIC (bulles de dialogue façon SMS, mission dédiée) — faisabilité confirmée le 8 septembre 2026 (réflexions stratégiques, section 18), premier dialogue réel désormais opérationnel côté outil interne de test (10 septembre, voir ci-dessus) mais rien conçu ni codé côté écran utilisateur final.
- **Ménage dans la structure de `ASP_Consignes`** (8 septembre 2026) : Jean-Marc a repéré des champs qui lui semblent redondants (`CNS_TexteDefinition`/`CNS_TexteAffiche` en particulier) — à examiner ensemble avant de toucher au schéma, pour ne pas supprimer un champ qui sert ailleurs sans qu'on l'ait vérifié.
- Contenu réel des classeurs Missions, Propositions, Livraisons et Gestion (nouvelle classification du 9-10 septembre, voir réflexions stratégiques section 19) — aucun écran ni donnée derrière à ce stade, seule la classification cible est fixée.
- Rédaction des cinq textes d'identité des collaborateurs — Jean-Marc les écrit lui-même, à la première personne (Matilda déjà saisie via l'outil réel du 10 septembre) — à intégrer aux `EBAUCHES_IDENTITE` de secours dans `ecran_fond.html` une fois reçus, si besoin.
- Lien concret entre une Mission close et l'enrichissement réel de `AGN_Identite` au fil du temps (réflexions stratégiques, section 20) — intention actée, rien conçu ni codé à ce stade.
- Stockage de documents utilisateur (PDF) — architecture actée par anticipation (réflexions stratégiques, section 21 : stockage hors racine servie par le serveur web, endpoint PHP dédié, sous-dossier opaque par client en défense en profondeur), aucun développement engagé, pas de besoin immédiat.