V1.011 Tests de dictées vocales

journal/ASPIC-Journal. 27. Pilotage Vocal.md

@@ -104,3 +104,39 @@ Testé par Claude en navigateur headless avec un faux moteur de reconnaissance p
 - É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.
+
+## 3 septembre 2026 (nuit) : dictée d'adresses mail — diagnostic en plusieurs couches et deux bugs de robustesse trouvés grâce à un diagnostic en direct (V1.011)
+
+Reprise de session le même soir, Jean-Marc ayant commencé à utiliser réellement l'outil de banque de dictées (section précédente) pour s'entraîner sur le thème "Gestion des Contacts". Constat immédiat et sévère : la dictée d'une adresse mail échoue environ 49 fois sur 50 — bien au-delà de ce qu'un utilisateur tolérerait, quelle que soit la qualité du reste du pilotage vocal (Jean-Marc : *"si une dictée d'adresse mail pose problème dans plus de 10% des cas, la solution ne sera pas utilisée"*).
+
+**Diagnostic établi à partir d'exports réels de `ASP_DicteesTest`, pas d'hypothèses de table** (même méthode que celle qui avait permis de trouver le bug "les loups", voir plus haut) — trois causes distinctes, à ne pas confondre :
+- **Vocabulaire incohérent.** Les mots dictés pour la ponctuation ("point", "tiret", "arobase", "tiret du bas") ne sont convertis en symbole par le moteur gratuit du navigateur que de façon incohérente — parfois convertis, parfois laissés en toutes lettres, parfois avalés purement et simplement. "tiret" est en plus régulièrement confondu avec le verbe "tirer" (homophone). Vérifié auprès de la documentation officielle : Google propose bien une option dédiée à cette conversion (`enableSpokenPunctuation`) dans son API Cloud Speech-to-Text payante, mais elle n'est pas exposée dans l'API gratuite du navigateur (`webkitSpeechRecognition`) — l'application doit donc faire elle-même cette conversion.
+- **Segmentation non fiable.** Le moteur découpe parfois une même adresse dictée en plusieurs lignes indépendantes, sans qu'un délai de silence permette de distinguer fiablement "il continue la même adresse" de "il change de sujet" (des écarts de 3 à 4 secondes s'observent dans les deux cas sur un même export réel).
+- **Lettres avalées sur les mots inventés.** Distinct des deux points précédents et plus grave : sur un mot sans aucun support linguistique réel (ex. "mvl-tls", un sigle interne), le moteur perd parfois des lettres entières ("mvl-tls.fr" transcrit "mvtls.fr") — une perte acoustique pure, invisible dans le texte reçu et donc jamais rattrapable par un quelconque post-traitement. Explication retenue : les moteurs de reconnaissance actuels s'appuient sur un modèle de langage qui favorise les séquences ressemblant à quelque chose de connu (d'où la fiabilité, à l'inverse, de "gmail.com" — une chaîne quasi mémorisée tant elle est fréquente) ; un sigle inventé n'a aucun appui de ce genre.
+
+**Position actée avec Jean-Marc sur ce dernier point : aucune solution, gratuite ou payante, ne peut garantir un fonctionnement parfait en toute situation** sur un mot rare/inventé — dit explicitement pour ne pas laisser croire qu'une simple bascule vers une API payante réglerait tout. Le vrai levier pour ce cas précis serait le vocabulaire personnalisé ("boosting" — Google Cloud *speech adaptation*/*phrase hints*, Deepgram *keyterm prompting*), qui permet de fournir au moteur une liste de mots attendus (noms de domaine ASPIC, société, agents...) pour augmenter leur probabilité de reconnaissance — même principe que `AGN_Variantes` déjà en place pour les agents, appliqué cette fois au vocabulaire métier. Comparatif de prix et détail de la piste API conservés dans les réflexions stratégiques (section 12, addendum du même soir) plutôt que dans ce journal technique.
+
+**Décision : épuiser d'abord la piste gratuite avant d'envisager une API payante**, le coût en dollars étant négligeable à l'usage envisagé mais le changement d'architecture bien réel (audio à faire transiter par un serveur détenant une clé, fin de la solution 100% navigateur/sans serveur actuelle).
+
+**"Mode adresse" ajouté à `micro_test.js`.** Plutôt que de deviner où s'arrête une adresse dans un flux libre, reprise du principe déjà éprouvé du mode notation de `micro.js` (ouverture/clôture explicites) — ici au clic plutôt qu'à la phrase, pour ne pas dépendre d'un mot de clôture lui-même mal reconnaissable :
+- Activé/désactivé via un bouton dédié dans la fenêtre de test ; tant qu'il est actif, chaque fragment reconnu s'empile dans un buffer affiché en direct au lieu d'être enregistré comme une ligne indépendante — la segmentation du moteur n'a alors plus d'importance.
+- Le bouton "Valider" clôt le buffer : les fragments sont concaténés, passés dans un dictionnaire de conversion (point/tiret/tiret du bas/arobase → symboles, y compris l'alias "tirer"→"tiret" restreint à ce mode précis) qui retire aussi les espaces restants, puis comparés à une forme email/domaine attendue pour un simple retour visuel vert/orange — indicatif seulement, n'empêche jamais l'enregistrement (cohérent avec la règle "aucun essai raté supprimé" actée le 3 septembre après-midi).
+- Le texte brut (fragments concaténés tels que dictés) et le texte normalisé sont conservés tous les deux — nouvelle colonne `DCT_TexteNormalise` (ajoutée en base par Jean-Marc lui-même, `VARCHAR(255) NULL`), `NULL` pour toutes les lignes hors "mode adresse". Rien n'écrase la matière brute déjà actée comme précieuse pour la suite.
+- Un compteur simple (conforme/non conforme) affiché dans la fenêtre donne une lecture immédiate du taux d'échec au fil des essais.
+
+**Deux bugs de robustesse trouvés en cours de test réel, tous deux corrigés le même soir grâce à un bloc de diagnostic temporaire ajouté spécifiquement pour ça** (`DIAGNOSTIC_ACTIF`/`logDiag`, affichage en direct de chaque démarrage/arrêt/erreur du moteur avec horodatage précis — y compris les erreurs normalement masquées comme "no-speech") :
+1. **La fenêtre entière était vidée à chaque redémarrage automatique du moteur**, pas seulement à l'ouverture volontaire du micro — bug préexistant à ce soir, resté invisible tant que les dictées s'enchaînaient vite, devenu très visible avec une dictée hésitante (adresse mail, beaucoup de silences de réflexion → beaucoup de redémarrages automatiques → fenêtre effacée avant d'avoir pu être lue). Signalé côté utilisateur par l'indicateur micro de Chrome clignotant en continu. Corrigé en ne réinitialisant la fenêtre qu'au tout premier démarrage suivant un clic utilisateur réel, jamais lors d'une relance automatique.
+2. **Boucle de redémarrage incontrôlée**, révélée par le diagnostic une fois le premier bug corrigé : jusqu'à plus de 1800 cycles démarrage/arrêt en quelques secondes, avec des erreurs "aborted" au passage — le code d'origine relançait `reconnaissance.start()` immédiatement à chaque arrêt, sans aucun délai ni protection. Corrigé par un coupe-circuit : au-delà de 5 redémarrages consécutifs en moins de 800 ms, l'écoute s'arrête proprement avec un message explicite, plutôt que de boucler indéfiniment en silence.
+
+**Résultat après correctifs, sur un tout petit échantillon (4 essais passés par le mode adresse) :** 2 adresses parfaitement normalisées, 1 quasi-bonne (un mot parasite collé en tête, sans lien avec la ponctuation), 1 ratée — non pas à cause d'un bug, mais parce que deux adresses distinctes avaient été dictées à la suite sans clic "Valider" entre les deux, fusionnées en une seule chaîne par le buffer (comportement voulu du mode adresse, pas un défaut). Progrès net par rapport au ~1/50 de départ, mais échantillon bien trop petit pour trancher — Jean-Marc prévoit une campagne de tests en nombre le lendemain (4 septembre) et enverra les résultats.
+
+### Fichiers touchés (3 septembre, nuit)
+
+`micro_test.js` (mode adresse + diagnostic temporaire + deux correctifs de robustesse), `dictees_test.php` (colonne `DCT_TexteNormalise` optionnelle en entrée), `version.php` (`V1.011`). Colonne `DCT_TexteNormalise` ajoutée par Jean-Marc directement en base (`ALTER TABLE`, communiqué par Claude, jamais exécuté côté Claude — voir convention actée en tête de journal).
+
+**Reste à faire.**
+- Laisser Jean-Marc constituer un vrai volume d'essais d'adresses mail via le mode adresse (le 4 septembre) pour mesurer un taux de réussite fiable, plutôt que de statuer sur un échantillon de 4.
+- Retirer le bloc de diagnostic temporaire (`DIAGNOSTIC_ACTIF`/`logDiag`) une fois le comportement confirmé stable sur cette campagne — pas destiné à rester en l'état.
+- Décider si le cas "deux adresses dictées sans clic Valider entre les deux" (voir résultat ci-dessus) mérite un traitement automatique, ou reste une simple consigne d'usage.
+- Si le taux d'échec mesuré reste trop élevé après cette campagne : é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 (ex. "mvl-tls.fr") reste entier et sans solution de contournement identifiée à ce stade, y compris avec le mode adresse — à garder en tête pour la suite plutôt qu'à considérer comme résolu.