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").

Sommaire des sections (/journal sur GitHub)

• 0. Présentation
• 1. Contexte et décision d'architecture
• 2. Modèle de données
• 3. Architecture technique
• 4. Fichiers de l'application
• 5. Points de friction
• 6. Pistes pour la suite
• 7. Statut actuel
• 8. Écran d'identification
• 9. É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

(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. 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.)

Statut actuel (2-4 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.

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).
• 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) 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 et le pilotage vocal restent à documenter (mise à jour du 3 septembre limitée à l'écran d'accueil et à la liste des contacts) — l'outil de banque de dictées n'a volontairement pas vocation à y figurer, ce n'est pas un module utilisateur.
• Écran de fond : reconfirmer l'état de la "tranche du bureau" après le recadrage du 3 septembre (a pu déplacer le problème sans que ce soit son objet) ; décider si les autres objets photographiés (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.
• É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 aux couleurs de post-it par assistant (AGN_Couleur, à ajouter).
• É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é.