V1.011 Tests de dictées vocales

journal/ASPIC - Reflexions strategiques.md

@@ -150,3 +150,13 @@ Jean-Marc a proposé un signe graphique sur le post-it de l'assistant pour ident
 **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.
+
+**Addendum du 3 septembre 2026 (nuit) — la reconnaissance brute d'un mot rare/inventé est un problème à part, que ni le LLM d'interprétation ni le RAG ne résolvent.** Les premiers essais réels de Jean-Marc sur le thème "Gestion des Contacts" (voir journal, section 27) ont fait remonter, en marge de la constitution du corpus, un problème concret qui recoupe la distinction posée plus haut mais s'y ajoute : la dictée d'une adresse mail échoue très souvent, pour trois raisons distinctes — un vocabulaire de ponctuation dicté ("point", "tiret", "arobase") converti de façon incohérente par le moteur gratuit du navigateur, une segmentation de la dictée en plusieurs lignes non fiable, et surtout des lettres purement et simplement avalées sur des mots sans aucun support linguistique réel (ex. "mvl-tls.fr" transcrit "mvtls.fr") — cette dernière étant une perte acoustique en amont de tout traitement, jamais rattrapable par un post-traitement quel qu'il soit, contrairement aux deux premières.
+
+Point explicitement acté avec Jean-Marc : **aucune solution, gratuite ou payante, ne garantit un fonctionnement parfait en toute situation** sur ce genre de mot rare/inventé — à ne jamais présenter comme un problème que "changer de moteur" réglerait entièrement. Le levier le plus directement pertinent pour ce cas précis n'est pas le modèle d'interprétation (LLM à sortie structurée, voir plus haut) mais le **vocabulaire personnalisé côté reconnaissance elle-même** ("boosting") — un mécanisme distinct de celui décrit plus haut dans cette section, en amont de l'interprétation, pas à sa place :
+- **Google Cloud Speech-to-Text** (*speech adaptation* / *phrase hints*) et **Deepgram** (*keyterm prompting*, récemment étendu à plusieurs langues) permettent de fournir au moteur une liste de mots/expressions attendus (noms de domaine ASPIC, société, agents...) pour augmenter leur probabilité de reconnaissance au moment de la décision — conceptuellement la même idée que `AGN_Variantes`, déjà validée pour les prénoms d'agents, appliquée cette fois au vocabulaire métier.
+- **Non disponible côté gratuit :** l'API du navigateur (`webkitSpeechRecognition`) expose bien un paramètre `grammars` prévu à l'origine pour ce genre d'usage, mais Chrome ne l'exploite pas réellement en pratique (accepté sans effet) — ce levier suppose de passer par une vraie API payante.
+- **Prix vérifiés le 3 septembre 2026** (susceptibles d'évoluer) : Google Cloud Speech-to-Text v2, reconnaissance standard, environ 0,016 $/minute (dégressif au volume) — seul fournisseur à documenter une option dédiée à la conversion ponctuation dictée→symbole (`enableSpokenPunctuation`), sans confirmation que le français soit couvert par cette option précise. Deepgram Nova-3 multilingue, environ 0,005 $/minute, formatage automatique ("Smart Formatting") inclus sans supplément, 200 $ de crédit d'essai gratuit — couverture française du *keyterm prompting* spécifiquement non confirmée par la documentation à ce jour. OpenAI (gpt-transcribe), environ 0,0045 $/minute en asynchrone (plus cher en flux continu), sans fonction de ponctuation dictée documentée.
+- **Le coût en dollars est négligeable à l'usage envisagé** (quelques dollars par mois même à un usage quotidien soutenu) — ce n'est pas ce qui doit trancher. Ce qui coûte réellement, c'est le changement d'architecture : ces API ne s'utilisent pas depuis le navigateur comme aujourd'hui (gratuit, zéro serveur) — il faudrait capturer l'audio et le faire transiter par un point d'entrée serveur détenant une clé tenue secrète, fin de la solution 100% navigateur actuelle.
+
+**Décision : épuiser d'abord la piste gratuite (dictionnaire de conversion + segmentation explicite au clic, "mode adresse" de `micro_test.js`, voir journal section 27) avant d'investir dans une API.** Pas de décision définitive sur le recours à une API — dépendra du taux d'échec réellement mesuré sur la campagne de tests que Jean-Marc prévoit de mener le 4 septembre. Si le taux reste insuffisant, Deepgram est le candidat à tester en premier (le moins cher, formatage inclus), Google Cloud restant l'option la plus directement conçue pour le problème de ponctuation dictée mais à vérifier en vrai plutôt que sur la seule doc, notamment pour la couverture du français.