V1.012 Début du traitement par IA des retranscriptions des dictées

journal/ASPIC - Reflexions strategiques.md

@@ -160,3 +160,13 @@ Point explicitement acté avec Jean-Marc : **aucune solution, gratuite ou payant
 - **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.
+
+## 13. L'interprétation structurée passe l'épreuve du réel, et fait émerger un nouveau besoin : séparer les actions "humaines" des actions "vocales" (4 septembre 2026)
+
+**L'hypothèse de la section 12 est validée en conditions réelles, pas seulement sur le papier.** Premier outil réel d'interprétation d'une dictée par LLM à sortie structurée (voir journal de développement, section 29, pour le détail technique — `contact_ia_interprete.php`/`contact_ia_valide.php`/`contact_ia_panel.js`, jamais d'écriture dans les vraies tables de contacts, tout passe par une table à part `ASP_PropositionsContact`). Bilan de Jean-Marc sur un premier corpus réel de 11 essais, sans ambiguïté : *"c'est vraiment super ! Les tests sont vraiment encourageants."* Deux points restent ouverts (une adresse mail mal nettoyée d'un mot d'appel et d'un accent ; une possible troncature de fin de dictée par le nouveau minuteur de silence) mais ne remettent pas en cause l'approche elle-même — ce sont des réglages fins, pas un problème de méthode. Point vérifié explicitement avec Jean-Marc et à retenir comme garde-fou de confiance dans l'outil : la détection et le classement en premier de l'action "ajouter le contact" sont une vraie décision du LLM portée par le prompt, pas un cas particulier codé en dur côté Claude.
+
+**Décision architecturale actée en cours de session, à retenir comme principe général pour toute future couche d'interprétation vocale :** cette couche doit rester un enregistreur honnête de ce qui a été réellement dit, jamais un lieu où s'invitent des règles métier. Concrètement : l'attribution d'un assistant par défaut quand aucun n'est nommé dans la dictée n'est **pas** de son ressort — cette décision reviendra à un futur traitement n8n, au moment de transformer une proposition validée en vrai post-it. Mélanger les deux aurait fait perdre la trace de ce que Jean-Marc a réellement dicté derrière une interprétation déjà "arrangée".
+
+**Nouveau besoin architectural identifié par Jean-Marc à l'usage, non conçu ni codé — à reprendre dans une prochaine session.** En listant les actions qu'un contact peut porter (envoyer une doc, proposer un tarif...), Jean-Marc a réalisé que la création du contact lui-même mérite d'être une action à part entière au même titre que les autres — mais une action à double accès : le classement la place toujours en premier, elle est bien connue du LLM vocal (qui doit la détecter et la renvoyer classée), **et** l'utilisateur humain doit pouvoir la déclencher directement depuis un menu ou un raccourci clavier, sans passer par la voix. Jean-Marc souhaite généraliser ce principe à l'ensemble des actions d'ASPIC : une séparation formelle entre les actions utilisables par l'utilisateur humain (menu/écran classique) et celles utilisables par le LLM de saisie vocale, tout en gardant les deux voies d'accès parfaitement alignées sur un même vocabulaire d'actions et un même ordre. C'est précisément le motif qui structure sa satisfaction du jour : *"ce qui me plaît c'est que je vois bien que j'arrive à suivre ma logique : des fonctionnalités accessibles via des menus et écrans de façon tout à fait classique et ces mêmes fonctionnalités accessibles par des ordres vocaux fiables donnés à des assistants !"* — une confirmation, par la pratique, du principe de double accès déjà esquissé dans la vision "bureau à l'ancienne" (section 11) : mêmes fonctionnalités, deux portes d'entrée. Rien n'est conçu ni codé sur ce point à ce stade ; voir journal de développement, section 29, pour le détail du besoin tel que formulé.
+
+**Situation acceptée comme normale, pas un défaut à corriger : une profession peut être proposée "nouvelle" plusieurs fois avant traitement.** Deux dictées distinctes du corpus ont fait remonter deux fois la même profession ("Informaticien") comme nouvelle. Jean-Marc a tranché sans hésitation : c'est acceptable tant qu'un assistant n'a pas traité le post-it — il suffira, au moment du traitement, de vérifier si la profession n'a pas déjà été créée entre l'enregistrement de la note vocale et son traitement. Pas de mécanisme de déduplication à construire à ce stade.