V1.010 préparation de la création d'une banque de dictées

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.