diff --git a/dictees_test.php b/dictees_test.php new file mode 100644 index 0000000..094446b --- /dev/null +++ b/dictees_test.php @@ -0,0 +1,81 @@ + 'Non identifié — veuillez vous connecter.']); + exit; +} + +if ($_SERVER['REQUEST_METHOD'] !== 'POST') { + http_response_code(405); + echo json_encode(['error' => 'Méthode non autorisée']); + exit; +} + +$data = json_decode(file_get_contents('php://input'), true) ?? []; +$texte = trim((string) ($data['texte'] ?? '')); + +if ($texte === '') { + http_response_code(400); + echo json_encode(['error' => 'Rien à enregistrer']); + exit; +} + +try { + $pdo = getDbConnection(); +} catch (PDOException $e) { + http_response_code(500); + echo json_encode(['error' => 'Connexion base de données impossible']); + exit; +} + +// DCT_Texte est un TEXT (pas de contrainte de longueur pratique, contrairement +// à CVX_Consigne dans ASP_ConsignesVoix qui est un varchar(200)) : la dictée +// brute est conservée intégralement, sans troncature — un énoncé sur les +// contacts (nom, profession, ville, téléphone...) peut être plus long qu'une +// simple consigne de tâche. +try { + $stmt = $pdo->prepare( + 'INSERT INTO ASP_DicteesTest (DCT_Texte, DCT_Utilisateur) VALUES (?, ?)' + ); + $stmt->execute([$texte, $_SESSION['USR_Code']]); +} catch (PDOException $e) { + http_response_code(500); + echo json_encode(['error' => 'Erreur base de données : ' . $e->getMessage()]); + exit; +} + +echo json_encode(['success' => true]); diff --git a/ecran_fond.html b/ecran_fond.html index d651d2f..de06f26 100644 --- a/ecran_fond.html +++ b/ecran_fond.html @@ -110,8 +110,35 @@ d'origine, pour se fondre dans la grille plutôt que ressortir comme un autocollant. Fermé = glyphe micro en gris clair ; ouvert = barres façon vu-mètre en --rouge-micro, animées (voir @keyframes) — "les - barres qui bougent" demandé par Jean-Marc. Toggle en pur JS pour ce - test : ne déclenche pas encore la reconnaissance vocale de micro.js. */ + barres qui bougent" demandé par Jean-Marc. + Branché sur la reconnaissance vocale réelle le 3 septembre 2026 : + un script pilote désormais #micro-desk et bascule la classe "ecoute" + dessus (voir plus bas #micro-desk.ecoute ~ #micro-icone pour la + bascule visuelle des deux glyphes, via un combinateur de fratrie + puisque #micro-icone n'est pas un descendant de #micro-desk — voir + plus haut pourquoi ces deux éléments sont séparés). Le toggle JS + local qui existait ici pour le tout premier essai d'affichage (pur + visuel, sans reconnaissance vocale) est retiré. + + Mise à jour du même jour (suite de session) : ce micro est + temporairement détourné de son usage final. Plutôt que micro.js (le + vrai pilotage, agents nommés Viktor/Matilda/Léon/Nikita, mode + notation — resté inchangé et toujours utilisé tel quel sur + liste_contacts.html), c'est micro_test.js qui est chargé ici, le + temps de la phase de mise au point du pilotage vocal : outil de + constitution d'une banque de dictées réelles (table + ASP_DicteesTest, thème "Gestion des Contacts"), PAS un module + destiné aux futurs utilisateurs (voir le commentaire d'en-tête de + micro_test.js). Écoute continue, aucun mot déclencheur nécessaire + (le clic sur le micro fait déjà office de signal explicite), chaque + énoncé restitué au fur et à mesure dans une fenêtre dédiée puis + enregistré tel quel — y compris les essais ratés, jamais + supprimables depuis l'écran (décision explicite de Jean-Marc : ça + fera aussi partie de la vraie vie des futurs utilisateurs). Pour + reconnecter le vrai pilotage sur ce micro une fois cette phase + terminée : remettre + diff --git a/journal/ASPIC - Journal. Index.md b/journal/ASPIC - Journal. Index.md index 8adf9e3..320868a 100644 --- a/journal/ASPIC - Journal. Index.md +++ b/journal/ASPIC - Journal. Index.md @@ -80,13 +80,18 @@ Version incrémentée une seule fois pour l'ensemble de cette session (pastille **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**. + **Reste à faire, noté au passage :** - 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). -- Pilotage vocal, étape 2 : définir les règles d'interprétation du contenu dicté (aujourd'hui stocké tel quel), envisagée via n8n avec des règles modifiables par l'utilisateur. +- 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). +- 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). -- É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 ; brancher le micro du bureau (et celui de la barre de statut) sur la reconnaissance vocale réelle ; 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). +- 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. diff --git a/journal/ASPIC - Reflexions strategiques.md b/journal/ASPIC - Reflexions strategiques.md index e0c2b75..4cf9ea7 100644 --- a/journal/ASPIC - Reflexions strategiques.md +++ b/journal/ASPIC - Reflexions strategiques.md @@ -126,3 +126,27 @@ En marge de sa recherche d'un serveur Hostinger plus puissant, Jean-Marc a déco **Périmètre et statut.** Vision explicitement limitée à ASPIC lui-même à ce stade, pas un projet d'outillage plus large. Jean-Marc reconnaît que cette réflexion peut évoluer avec l'expérience acquise sur le terrain — voir justement le principe ci-dessous, tiré d'un premier retour d'expérience concret le jour même. Aucun développement engagé — pure réflexion à ce stade, capturée ici pour mémoire. **Principe de conception qui en découle, tiré de l'expérience réelle du pilotage vocal (2 septembre 2026) :** mieux vaut choisir des noms d'agents qui passent bien nativement à la reconnaissance vocale que d'empiler des tolérances pour rattraper un nom mal choisi — chaque tolérance ajoutée étant à la fois un risque de faux déclenchement (si elle recoupe un mot français courant) et un pari sur un seul accent/une seule prononciation testée, fragile face à la diversité réelle des utilisateurs. Deux agents (Lilou, Karl) ont été retirés sur cette base après des essais répétés peu concluants, plutôt que d'être maintenus à coups de correctifs successifs. Principe à garder en tête si le "bureau à l'ancienne" se concrétise un jour avec davantage d'assistants nommés. + +## 12. Interpréter le pilotage vocal sans s'effondrer à l'échelle — LLM à sortie structurée pour l'action, RAG réservé à la recherche (3 septembre 2026) + +**Origine — un enjeu concurrentiel identifié via un tiers.** Jean-Marc a montré les évolutions du pilotage vocal à sa compagne, qui a immédiatement fait le rapprochement avec sa propre expérience professionnelle : elle travaille dans une grosse PME équipée de SAP, confrontée au quotidien à une application qui rame pendant de longues minutes, des arrêts brutaux, et des procédures extrêmement lourdes pour la moindre intervention (créer un utilisateur, corriger un bug de saisie) — délai moyen de 2 à 3 jours via un prestataire externe. Jean-Marc en tire une conviction stratégique : le pilotage vocal, davantage qu'un simple confort, pourrait devenir un vrai argument différenciant face à ce type d'outil lourd, auprès de futurs clients de son agence. **Conséquence directe sur l'exigence de qualité :** cette perspective augmente la pression de fiabilité plutôt que de la relâcher — Jean-Marc redoute explicitement le scénario inverse ("sympa en démo, mais ça ne marche pas en vrai"), d'autant qu'il ne croit pas à la viabilité d'un empilement de règles/rustines au cas par cas une fois le pilotage vocal étendu bien au-delà de la ToDoList (contacts, catalogue, devis et affaires en cours, facturation). + +**Deux problèmes distincts, à ne pas confondre sous un seul chantier.** Discussion posée avec Claude pour trancher cette inquiétude : + +- **La reconnaissance du mot déclencheur** (l'épisode Lilou/"les loups", voir journal de développement section 27) est un problème de transcription audio, en amont de tout traitement — aucune base vectorielle, aucun RAG, aucun LLM n'y changerait quoi que ce soit, c'est une limite de la reconnaissance vocale elle-même (la même que rencontrent Alexa, Siri ou Google Home). Déjà traité par le choix de noms qui passent bien à l'oral et par `AGN_Variantes` piloté en base — et point rassurant pour la suite : cette surface d'erreur ne grandit pas avec le nombre de modules d'ASPIC, elle reste bornée au nombre d'agents nommés. +- **L'interprétation d'une dictée déjà bien captée** — transformer "il faut ajouter un contact, il s'appelle Pierre Chartier, il est plombier à Quimper..." en une action structurée (quel module, quelle opération, quels paramètres) — est un problème différent, qui se posera réellement une fois la ToDoList suivie par la gestion des contacts, du catalogue, des devis, de la facturation. + +**Pourquoi le RAG/pgvector n'est pas l'outil pour ce deuxième problème.** Un RAG/base vectorielle sert à retrouver de l'information pertinente par similarité sémantique dans un corpus large et non structuré — une recherche, pas un déclenchement d'action. C'est l'outil du **répondeur téléphonique intelligent** (section 10 ci-dessus), où le besoin est justement de chercher une réponse dans une base de connaissances ouverte, avec une contrainte de latence quasi temps réel. Le pilotage vocal d'ASPIC, même étendu à plusieurs modules, reste un ensemble d'actions **enumérable et borné** (créer un contact, ajouter une ligne de devis, appliquer une remise...) — la bonne réponse est un LLM à sortie structurée (function calling) : on lui fournit un catalogue d'actions disponibles (nom, paramètres attendus, endpoint concerné), il renvoie l'action reconnue et ses paramètres extraits du texte, sans deviner s'il n'est pas sûr. Chaque nouveau module ajoute des entrées à ce catalogue, pas du code d'interprétation nouveau — c'est ce qui évite l'empilement de règles redouté par Jean-Marc, bien mieux qu'une base vectorielle qui ne répond pas à ce besoin précis. Le RAG garde sa place légitime, mais ailleurs : recherche floue dans un futur catalogue produits ("quelle référence pour un connecteur étanche IP67 20A"), ou dans l'historique des devis/affaires — pas pour interpréter une commande. L'infrastructure (PostgreSQL/pgvector, n8n, LangFlow) tourne déjà sur le VPS de Jean-Marc, prête sans réinstallation le jour où un vrai besoin de ce type apparaîtra (voir section 10). + +**Modèle affiné pour le retour visuel à l'utilisateur : deux statuts distincts, pas un seul niveau de confiance.** Proposition initiale de Claude (un seuil de confiance unique) affinée par Jean-Marc, qui avait déjà anticipé le besoin d'une correction ou d'une validation propre à l'action demandée : + +- **"À corriger"** — l'IA n'a pas réussi à comprendre proprement la demande (information manquante, incohérente, ou dictée incompréhensible). Un problème d'interprétation, détecté par le LLM lui-même au moment de faire correspondre la dictée à une action du catalogue. +- **"À valider"** — l'IA a bien compris et préparé l'action, mais cette action précise exige toujours un accord humain avant de partir pour de vrai (ex. l'envoi d'un devis à un client), **indépendamment du niveau de confiance de l'interprétation** — une propriété portée par l'action elle-même dans le catalogue, pas un seuil réglé globalement. + +Jean-Marc a proposé un signe graphique sur le post-it de l'assistant pour identifier ce qui l'attend (un point d'interrogation, par exemple) — retenu pour "à corriger" (il doit apporter une information ou trancher une ambiguïté). Un second signe, distinct, est envisagé pour "à valider" (un geste plus simple, oui/non, sur quelque chose déjà prêt) — non choisi à ce stade, pour que les deux situations restent reconnaissables d'un coup d'œil sans ouvrir le post-it. + +**Rôle de n8n confirmé, dans les mots de Jean-Marc : un "agent de veille" réagissant à des déclencheurs programmés** — pas un outil interrogé à la demande. Concrètement, soit une surveillance périodique des nouvelles clôtures de notation, soit un appel direct dès la clôture d'une dictée pour plus de réactivité — un réglage à choisir plus tard, pas une contrainte d'architecture. + +**Décision pour la suite immédiate : ne pas concevoir les règles d'interprétation à l'avance, constituer d'abord un corpus réel.** Cohérent avec la leçon déjà tirée de Lilou/"les loups" — ce qui paraît naturel en le pensant seul se révèle différent une fois dicté réellement et de façon détendue. Jean-Marc en a fourni la preuve lui-même, avant même d'avoir l'outil en main : il a par exemple relevé qu'il commence souvent une instruction par "il faut"/"il faudrait" plutôt que par le prénom d'un agent, et utilise aussi bien "puis" que "ensuite" pour enchaîner deux idées — deux détails qu'aucune conception à la table n'aurait fait ressortir aussi vite. Voir journal de développement, section 27, pour l'outil concret construit ce soir-là (`micro_test.js`/`dictees_test.php`, table `ASP_DicteesTest`) : aucune règle d'interprétation n'y est codée, volontairement — l'objectif de cette phase est uniquement d'accumuler la matière première (dictées réelles, y compris les essais ratés) qui permettra, plus tard, de concevoir le catalogue d'actions et les règles d'extraction avec des exemples réels plutôt qu'hypothétiques. + +**Statut : orientation actée, aucun développement de la couche d'interprétation elle-même engagé.** Le développement immédiat porte uniquement sur la constitution du corpus (voir journal, section 27) — le catalogue d'actions, l'appel LLM à sortie structurée et les deux signes graphiques du post-it restent à concevoir, une fois ce corpus jugé suffisant. diff --git a/journal/ASPIC-Journal. 27. Pilotage Vocal.md b/journal/ASPIC-Journal. 27. Pilotage Vocal.md index 1fa5e05..0c4963e 100644 --- a/journal/ASPIC-Journal. 27. Pilotage Vocal.md +++ b/journal/ASPIC-Journal. 27. Pilotage Vocal.md @@ -53,8 +53,54 @@ CREATE TABLE `ASP_Agents` ( **État à la fin de cette session.** Fonctionnalité validée de bout en bout sur les quatre agents actifs (ouverture → contenu → clôture, y compris avec variantes de prononciation). Version applicative incrémentée une fois pour cette session, **V1.006**. -**Reste à faire.** +**Reste à faire (à la clôture de la session du 1-2 septembre).** - Étape 2 : règles d'interprétation du contenu dicté (aujourd'hui stocké tel quel, sans traitement), envisagées via n8n, avec des règles modifiables par l'utilisateur. - Continuer à observer les agents actifs en usage réel ; envisager d'autres retraits, ou l'ajout de nouvelles variantes via `AGN_Variantes`, si de nouvelles confusions apparaissent — sans jamais y ajouter un mot français courant. - Vérifier concrètement que le `.htaccess` du dossier `/journal` bloque bien l'accès direct (`curl -I` doit répondre `403`, pas `200`) — point resté en suspens depuis le 31 août, sans lien avec le pilotage vocal mais toujours ouvert. - Documentation utilisateur : pas encore mise à jour pour cette fonctionnalité, encore en phase d'essais techniques (choix des noms d'agents notamment) — à envisager une fois l'usage stabilisé. + +## 3 septembre 2026 (soirée) : vers l'étape 2 — constitution d'une banque de dictées réelles avant toute règle d'interprétation (V1.010) + +Reprise de session le même jour (voir aussi section 28, où le micro de l'écran de fond est branché sur la reconnaissance vocale réelle plus tôt dans cette même soirée). Discussion engagée par Jean-Marc après avoir montré les évolutions du pilotage vocal à sa compagne, qui a directement fait le lien avec son expérience de SAP dans une grosse PME (application qui rame, arrêts brutaux, procédures lourdes pour un simple changement — délai moyen de 2-3 jours via un prestataire externe pour créer un utilisateur ou corriger un bug de saisie). Jean-Marc en tire une conviction : l'aspect vocal sera vraisemblablement un atout concurrentiel important vis-à-vis de futurs clients, ce qui **augmente l'exigence de fiabilité** plutôt que de la relâcher — inquiétude explicite sur la capacité du projet à tenir cette fiabilité une fois le pilotage vocal étendu au-delà de la ToDoList (contacts, catalogue, devis et affaires en cours, facturation...), sans tomber dans un empilement de règles/rustines au cas par cas comme cela avait déjà été nécessaire pour Lilou/"les loups" (voir plus haut). + +**Distinction actée avec Claude, développée en détail dans les réflexions stratégiques (section 12) :** deux problèmes différents, à ne pas traiter par le même mécanisme. D'un côté, la confusion de reconnaissance en amont (mot déclencheur mal transcrit) — un problème de reconnaissance audio, déjà traité par `AGN_Variantes` et le choix de noms d'agents qui passent bien à l'oral, dont la surface d'erreur ne grandit pas avec le nombre de modules d'ASPIC. De l'autre, l'interprétation d'une dictée déjà bien captée — transformer "il faut ajouter un contact, il s'appelle Pierre Chartier, il est plombier à Quimper..." en une action structurée (quel module, quelle opération, quels paramètres). Conclusion : ni RAG ni base vectorielle pour ce deuxième problème (outil de recherche floue dans un corpus, pas de déclenchement d'action) — un LLM à sortie structurée (function calling) contre un catalogue d'actions par module est l'outil adapté, sans avoir besoin de pgvector avant qu'un vrai besoin de recherche floue (catalogue produits, historique de devis) n'apparaisse. Modèle affiné avec Jean-Marc pour le retour visuel sur le post-it : deux statuts distincts plutôt qu'un seul niveau de confiance — "à corriger" (information manquante/incohérente, l'IA n'a pas su comprendre) versus "à valider" (l'IA a bien compris et préparé l'action, mais cette action précise exige toujours un accord humain avant exécution réelle, par nature — ex. l'envoi d'un devis à un client — indépendamment du niveau de confiance de l'interprétation). Deux signes graphiques distincts envisagés sur le post-it (un point d'interrogation pour "à corriger", proposé par Jean-Marc ; un symbole différent, à définir, pour "à valider") plutôt qu'un seul, pour que Jean-Marc sache d'un coup d'œil ce qu'on attend de lui sans ouvrir le post-it. + +**Décision pour cette session : ne pas anticiper les règles, constituer d'abord un corpus réel.** Cohérent avec la leçon déjà tirée de Lilou/"les loups" — ce qui semble naturel en le pensant seul (ex. faire commencer chaque instruction par le prénom d'un agent) se révèle différent une fois dicté réellement et de façon détendue. Jean-Marc a d'ailleurs déjà relevé, avant même d'avoir l'outil, deux exemples concrets : il commence souvent une instruction par "il faut"/"il faudrait" plutôt que par le prénom d'un agent, et utilise aussi bien "puis" que "ensuite" pour marquer un enchaînement — points à garder tels quels dans le corpus plutôt qu'à corriger à la main, l'objectif de cette phase étant justement de laisser le vrai usage remonter ces variations plutôt que de les deviner. + +**Outil construit : `micro_test.js` + `dictees_test.php` + table `ASP_DicteesTest`.** Outil de mise au point interne, explicitement pas destiné aux futurs utilisateurs (précision de Jean-Marc). Table créée par Jean-Marc lui-même (voir convention actée en tête de journal) : + +```sql +CREATE TABLE `ASP_DicteesTest` ( + `DCT_Incr` int NOT NULL, + `DCT_Theme` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL DEFAULT 'Gestion des Contacts', + `DCT_Texte` text NOT NULL, + `DCT_Date` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, + `DCT_Utilisateur` varchar(3) NOT NULL +) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; +``` + +Choix de conception actés avec Jean-Marc, plusieurs à contre-courant du réflexe initial de Claude : +- **Aucun mot déclencheur.** Le clic sur le micro fait déjà office de signal explicite de début — contrairement à `micro.js` en écoute ambiante continue, qui doit filtrer une conversation de fond d'une vraie commande, ce problème ne se pose pas ici : tout ce qui est dit après le clic est un essai volontaire. Ça répond directement à la remarque de Jean-Marc sur le prénom d'agent en tête de phrase — cette contrainte est un artefact du filtrage en écoute ambiante, pas une exigence de l'interprétation elle-même. +- **Pas de segmentation "à la main".** Le "silence de x secondes" évoqué par Jean-Marc n'est pas un réglage exposé par l'application : c'est le moteur de reconnaissance du navigateur qui décide, en interne, quand un énoncé est terminé (chaque événement `result` avec `isFinal=true` correspond déjà à "ce qui a été dit avant une pause") — même mécanisme que celui déjà éprouvé en production dans `micro.js`, repris tel quel plutôt que réinventé. +- **Restitution au fur et à mesure.** Contrairement à `micro.js` (`interimResults=false`), ce script active `interimResults=true` : le texte apparaît progressivement dans une fenêtre dédiée (fond noir, texte blanc, `overflow-y:auto`) pendant la dictée, la ligne se fige (et s'enregistre) dès que le silence est détecté, puis une nouvelle ligne démarre. +- **Aucune suppression possible, y compris pour un essai raté.** Décision explicite de Jean-Marc, à contre-courant d'une première proposition de Claude (bouton de suppression pour nettoyer un essai avorté) : *"les dictées ratées feront partie de la vie des futurs utilisateurs"* — la banque doit refléter la réalité, pas une version nettoyée qui fausserait la conception des règles de correction à venir. +- **Fenêtre vidée à chaque fermeture du micro**, rouverte vide au prochain clic — purement un retour visuel immédiat, la table continue évidemment d'accumuler tous les essais d'une session à l'autre. +- **Thème fixé** à la valeur par défaut de la colonne (`'Gestion des Contacts'`), non transmis par le script — évite de dupliquer une valeur qui doit rester pilotée par la table. + +Branché, comme détaillé en section 28, sur le micro de l'écran de fond (`#micro-desk`) à la place de `micro.js`, le temps de cette phase — décision explicite de Jean-Marc de réutiliser ce micro plutôt que de construire un écran séparé, pour permettre des essais rapides et répétés en se décontractant sur le sujet. `micro.js` n'est pas modifié pour ça (seul le repli d'id ajouté plus tôt dans la soirée y reste, voir section 28) et continue de tourner normalement sur `liste_contacts.html`. + +Endpoint `dictees_test.php` : reçoit `{"texte": "..."}`, enregistre tel quel dans `ASP_DicteesTest` avec l'utilisateur de la session — même squelette que `agent_notes.php` (session requise, POST uniquement), sans logique de lot ni de type de ligne (chaque énoncé est indépendant ici, pas de notion d'ouverture/clôture). + +Testé par Claude en navigateur headless avec un faux moteur de reconnaissance piloté à la main (restitution en direct, figeage de ligne au bon moment, deuxième essai qui ne recouvre pas le premier, fenêtre bien vidée à la fermeture) avant livraison. **Premier essai réel le soir même, concluant** : micro laissé ouvert par Jean-Marc pour une session de dictées, une phrase dite par sa compagne dans la pièce correctement captée (voir section 28) — confirme que l'écoute continue et le redémarrage automatique tiennent la route en usage prolongé, pas seulement en essai bref. + +### Fichiers touchés (3 septembre, soirée) + +`micro_test.js` (nouveau), `dictees_test.php` (nouveau), `ecran_fond.html` (charge `micro_test.js` à la place de `micro.js`, voir section 28), `version.php` (`V1.010`). Table `ASP_DicteesTest` créée par Jean-Marc directement en base. + +**Reste à faire.** +- Laisser Jean-Marc constituer un vrai volume de dictées sur le thème "Gestion des Contacts" avant toute analyse — aucune règle d'interprétation à écrire tant que le corpus n'est pas jugé suffisant. +- Une fois ce corpus analysé : concevoir le catalogue d'actions pour le module Contacts (actions, paramètres attendus, lesquelles exigent une validation par nature) et le mécanisme d'appel LLM à sortie structurée correspondant (voir réflexions stratégiques, section 12). +- Reconnecter `micro.js` (vrai pilotage) sur le micro de l'écran de fond une fois cette phase de mise au point terminée — une seule ligne à changer dans `ecran_fond.html` (voir section 28). +- Étendre `MARQUEUR_FIN_LIGNE` dans `micro.js` pour accepter "puis" en plus de "ensuite" (retour d'usage de Jean-Marc, 3 septembre) — sans urgence, à faire quand on retouche `micro.js`. +- Concevoir les deux signes graphiques distincts pour les post-its "à corriger" / "à valider" évoqués plus haut — non codé, ni même définitivement choisi pour "à valider" (le point d'interrogation de "à corriger" est acté). +- Étendre l'outil de banque de dictées à d'autres thèmes (catalogue, devis...) le jour où ces modules existeront — `DCT_Theme` est déjà prévu pour ça, seule la valeur par défaut en base et le script de capture sont à dupliquer/adapter. diff --git a/journal/ASPIC-Journal. 28. Ecran de fond.md b/journal/ASPIC-Journal. 28. Ecran de fond.md index dce5806..c4c74cd 100644 --- a/journal/ASPIC-Journal. 28. Ecran de fond.md +++ b/journal/ASPIC-Journal. 28. Ecran de fond.md @@ -159,6 +159,20 @@ Après déploiement et test réel par Jean-Marc (*"tatillon, je sais"*), écart - Déploiement du correctif `.htaccess` de cache (voir ci-dessus) — à confirmer par Jean-Marc. - Documentation utilisateur : certains passages décrivant l'écran "Liste des contacts" comme écran d'accueil et le menu hamburger sont devenus obsolètes suite aux changements du 3 septembre — corrections ponctuelles apportées le jour même (voir document séparé), une repasse plus complète (écran de fond, panneau détail, ToDoList, pilotage vocal — aucun de ces écrans n'est encore documenté pour l'utilisateur) reste à faire un jour. +## 3 septembre 2026 (suite de soirée) : micro du bureau branché sur la reconnaissance vocale réelle, puis détourné temporairement (V1.010) + +Reprise de session le même jour, après la clôture ci-dessus. Premier point traité, en réponse à une question de Jean-Marc constatant l'écart de comportement entre les deux micros de l'application (celui de la liste des contacts déclenchait bien la demande d'autorisation Chrome et l'icône d'enregistrement du navigateur ; celui de l'écran de fond non) : confirmation que le micro du bureau (`#micro-desk`) n'avait effectivement jamais été branché sur `micro.js`, comme déjà noté dans "Reste à faire" ci-dessus — seul un toggle visuel local (`appliquerEtatMicroDesk()`, voir V1.007) y bascule l'icône, sans jamais appeler l'API de reconnaissance. + +**Branchement réel.** `micro.js` cherchait jusqu'ici le bouton par un seul identifiant fixe (`#bouton-micro`, structure du bandeau). Plutôt que de recalquer la structure DOM de l'écran de fond sur celle du bandeau (ce qui aurait cassé la séparation volontaire zone-cliquable/icône déjà en place, voir V1.007 sur la raison de cette séparation), `micro.js` a été modifié pour chercher `#bouton-micro` puis, à défaut, `#micro-desk` — un seul fichier de comportement continue de piloter les deux écrans, chacun gardant sa structure visuelle propre. Côté `ecran_fond.html` : le toggle JS local (visuel seul) est retiré, remplacé par une règle CSS qui réagit à la classe `ecoute` que `micro.js` pose désormais sur `#micro-desk` — combinateur de fratrie (`#micro-desk.ecoute ~ #micro-icone #glyphe-repos/#glyphe-ecoute`) puisque `#micro-icone` n'est pas un descendant du bouton (voir V1.007). Vérifié par un test en navigateur headless (Playwright) : clic déclenchant bien un vrai appel à l'API de reconnaissance vocale, bascule visuelle des deux glyphes correctement pilotée par la classe. + +**Détournement temporaire, le soir même.** Discussion engagée par Jean-Marc sur la fiabilité à long terme du pilotage vocal (voir réflexions stratégiques, section 12, pour le raisonnement complet) a abouti à la décision de constituer d'abord une banque de dictées réelles avant d'écrire la moindre règle d'interprétation — voir section 27 du journal pour le détail technique de cet outil (`micro_test.js`, `dictees_test.php`, table `ASP_DicteesTest`). Ergonomie proposée par Jean-Marc : réutiliser directement le micro de l'écran général plutôt qu'un écran séparé. Concrètement, `ecran_fond.html` charge désormais `micro_test.js` **à la place de** `micro.js` — `micro.js` lui-même n'est pas modifié pour ça, et reste utilisé tel quel sur `liste_contacts.html`. Pour reconnecter le vrai pilotage sur ce micro une fois la phase de mise au point terminée : remettre `