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

journal/ASPIC - Journal. Index.md

@@ -45,10 +45,11 @@ Pour les trois documents de ce projet (ce journal — résumé/index —, les R
 - 26. ToDoList
 - 27. Pilotage vocal
 - 28. Écran de fond
+- 29. Interprétation vocale des contacts par LLM
 
-*(Numérotation et titres repris du découpage fait par Jean-Marc le 31 août 2026, légèrement reformulés par lui à cette occasion — se référer aux fichiers eux-mêmes pour le libellé exact. Section 27 (Pilotage vocal) validée de bout en bout et son fichier définitif déposé dans `/journal` le 2 septembre 2026. Section 28 (Écran de fond) ouverte le 2 septembre 2026, toujours **en cours** — passée d'une maquette graphique exploratoire à un premier essai fonctionnel réel, puis (soirée du 2 au 3 septembre) à une pastille de comptage sur le classeur Contacts et à un premier affichage réel des post-its personnels sur le tableau de liège ; fichier de section mis à jour à déposer par Jean-Marc, voir Statut actuel.)*
+*(Numérotation et titres repris du découpage fait par Jean-Marc le 31 août 2026, légèrement reformulés par lui à cette occasion — se référer aux fichiers eux-mêmes pour le libellé exact. Section 27 (Pilotage vocal) validée de bout en bout et son fichier définitif déposé dans `/journal` le 2 septembre 2026. Section 28 (Écran de fond) ouverte le 2 septembre 2026, toujours **en cours** — passée d'une maquette graphique exploratoire à un premier essai fonctionnel réel, puis (soirée du 2 au 3 septembre) à une pastille de comptage sur le classeur Contacts et à un premier affichage réel des post-its personnels sur le tableau de liège. Section 29 (Interprétation vocale des contacts par LLM) ouverte et son fichier définitif déposé le 4 septembre 2026 après validation de bout en bout sur un premier corpus réel ; fichiers de section à déposer par Jean-Marc, voir Statut actuel.)*
 
-## Statut actuel (2-3 septembre 2026)
+## Statut actuel (2-4 septembre 2026)
 
 **Écrans "Identification" et "Liste des contacts"** (avec panneau détail intégré) : aboutis depuis le 25 août 2026, testés en production. **Prospection** (formulaire externe, vérification mail, envoi de doc) : livrée et testée en conditions réelles le 26 août 2026 (section 18). **Dépôt Git** en place depuis le 27-28 août (section 20), avec circuit de livraison FileZilla → SSH VPS → `git push` (section 23) — l'écriture directe par Claude reste bloquée côté proxy Anthropic, contournement adopté sans gêne. **MIRADOR** (authentification centralisée multi-bases, identifiant = email) branché et validé à deux utilisateurs le 30 août 2026, déployé sur `aspic.mvl-tls.fr` (développement) et `crm.aspic.bzh` (test), chacun avec son propre environnement Docker (sections 21, 24, 25).
 
@@ -84,7 +85,12 @@ Version incrémentée une seule fois pour l'ensemble de cette session (pastille
 
 **3 septembre 2026 (nuit) : dictée d'adresses mail — diagnostic et deux bugs de robustesse corrigés dans l'outil de banque de dictées (V1.011).** Détail complet en section 27 du journal ; comparatif de prix des API de reconnaissance vocale en réflexions stratégiques, section 12 (addendum du même soir). Résumé : les premiers essais réels de Jean-Marc ont montré un taux d'échec très élevé (~1/50) sur la dictée d'une adresse mail. Diagnostic à partir d'exports réels de `ASP_DicteesTest` : trois causes distinctes — vocabulaire de ponctuation dicté ("point", "tiret", "arobase") converti de façon incohérente par le moteur gratuit du navigateur, segmentation de la dictée en plusieurs lignes non fiable, et des lettres purement avalées sur des mots sans support linguistique réel (ex. "mvl-tls.fr" → "mvtls.fr", perte acoustique jamais rattrapable après coup). Ajout d'un "mode adresse" dans `micro_test.js` : buffer explicite (activé/désactivé au clic, pour s'affranchir de la segmentation) + dictionnaire de conversion + validation de forme + compteur de conformité en direct ; nouvelle colonne `DCT_TexteNormalise` (ajoutée en base par Jean-Marc). En testant, deux bugs de robustesse préexistants découverts grâce à un bloc de diagnostic temporaire ajouté en direct (affichage de chaque démarrage/arrêt/erreur du moteur) : la fenêtre de test était entièrement vidée à chaque redémarrage automatique du moteur (invisible jusqu'ici, devenu très gênant avec une dictée hésitante) ; et une boucle de redémarrage incontrôlée pouvant atteindre plus de 1800 cycles en quelques secondes, sans aucune protection dans le code d'origine. Les deux corrigés le même soir (réinitialisation de fenêtre restreinte à l'ouverture volontaire ; coupe-circuit après 5 redémarrages rapides consécutifs). Sur un tout petit échantillon (4 essais) après correctifs : 2 adresses parfaitement normalisées, 1 quasi-bonne, 1 ratée par oubli de cliquer "Valider" entre deux adresses distinctes — encourageant, mais échantillon trop petit pour conclure. Piste d'une API payante avec vocabulaire personnalisé (Google Cloud, Deepgram) documentée et chiffrée en réserve, non retenue pour l'instant (coût en dollars négligeable, mais changement d'architecture réel). Version incrémentée une seule fois pour l'ensemble de cette session : **V1.011**. Jean-Marc prévoit une campagne de tests en nombre le 4 septembre et enverra les résultats.
 
+**4 septembre 2026 : interprétation vocale des contacts par un LLM à sortie structurée (V1.012).** Détail complet en section 29 du journal. Résumé : premier outil réel d'interprétation, dans le prolongement de la banque de dictées "Gestion des Contacts" — `contact_ia_interprete.php` (appel OpenAI `gpt-5.6-luna`, JSON Schema strict construit à partir des tables réelles ASP_Statuts/ASP_Professions/ASP_Agents/ASP_Actions, re-validation défensive après réponse), `contact_ia_valide.php` (seul point d'écriture, table à part `ASP_PropositionsContact` — ne crée jamais de contact ni de profession réels), `contact_ia_panel.js` (panneau flottant sur le micro de l'écran de fond, remplace `micro_test.js`). Décision architecturale actée : l'attribution d'un assistant par défaut quand aucun n'est nommé relève d'un futur traitement n8n, pas de cette couche d'interprétation qui doit rester un enregistreur honnête de ce qui est réellement dit. Détection de l'action "ajouter le contact" (libellé fixe, toujours classée en premier) confirmée comme une vraie décision du LLM porté par le prompt, pas un cas codé en dur — vérifié avec Jean-Marc. Zone actions simplifiée en 3 champs de texte libre (au lieu d'un motif dynamique existant/nouveau par ligne, jugé trop lourd pour cet essai). Nombreuses itérations d'ergonomie du panneau : dimensionnement immédiat à la taille maximale disponible avec défilement unique, lisibilité des listes déroulantes, arrêt automatique du micro après 3,5s de silence, redémarrage automatique du micro et panneau qui reste ouvert après validation (pour dicter plusieurs contacts à la suite), bouton "Abandonner" retiré au profit d'Échap seul. Relecture d'un premier corpus réel (11 essais) : résultats globalement encourageants, un bug d'extraction identifié (adresse mail non nettoyée d'un mot d'appel et d'un accent) et une possible troncature de fin de dictée par le minuteur de silence restent des points ouverts, non corrigés à la clôture. Jean-Marc a par ailleurs formulé une réflexion pour une prochaine session : séparer formellement les actions utilisables par l'utilisateur humain (menu/clavier) de celles utilisables par le LLM vocal, avec un vocabulaire d'actions unique et cohérent entre les deux voies d'accès. Version incrémentée une seule fois pour l'ensemble de cette session : **V1.012**.
+
 **Reste à faire, noté au passage :**
+- Décider s'il faut renforcer le prompt d'extraction pour neutraliser les mots parasites/formules de politesse dictés autour d'une adresse mail (bug identifié le 4 septembre sur le corpus réel, correction non encore actée par Jean-Marc).
+- Clarifier l'origine de la coupure de fin de dictée observée sur un essai du 4 septembre (minuteur de silence à 3,5s vs interruption réelle) avant de décider si `DUREE_SILENCE_ARRET_MS` (`contact_ia_panel.js`) doit être allongée.
+- Concevoir la séparation entre actions utilisables par l'utilisateur humain (menu/clavier) et actions utilisables par le LLM de saisie vocale, avec "création du contact" formalisée comme action à part entière toujours classée en premier et connue des deux voies d'accès — réflexion actée par Jean-Marc le 4 septembre, non conçue, non codée (voir section 29).
 - 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).
 - 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).

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.

journal/ASPIC-Journal. 29. Interprétation Vocale des Contacts par LLM.md

@@ -0,0 +1,68 @@
+# 29. Interprétation vocale des contacts par LLM
+
+*Section démarrée le 4 septembre 2026, dans le prolongement direct de la section 27 (Pilotage vocal) et de la banque de dictées constituée sur "Gestion des Contacts" (`micro_test.js`/`dictees_test.php`, table `ASP_DicteesTest`, voir V1.010-V1.011). Objectif de cette session : passer de la dictée brute enregistrée à une première interprétation réelle par LLM, sans jamais créer de contact réel — c'est le chantier annoncé en réflexions stratégiques, section 12.*
+
+## Principe retenu et périmètre volontairement restreint
+
+Jean-Marc a validé dès le départ le principe déjà posé en réflexions stratégiques : un LLM à sortie structurée (JSON Schema strict), pas de RAG/pgvector pour cet usage (réservé à la recherche floue), catalogue d'actions comparé explicitement en prompt plutôt que deviné. Nouvel outil de mise au point, dans la continuité de `contact_ia_test.html`/`.js` (test antérieur, conservé tel quel, aujourd'hui largement dépassé par ce qui suit) : `contact_ia_interprete.php` (appel LLM), `contact_ia_valide.php` (enregistrement), `contact_ia_panel.js` (panneau flottant, remplace `micro_test.js` sur `#micro-desk`).
+
+**Garde-fou explicite, rappelé plusieurs fois en session et documenté en tête de chaque fichier : cette chaîne n'écrit jamais dans `ASP_Contacts` ni `ASP_Professions`.** Tout passe par une table à part, `ASP_PropositionsContact` (`PCT_Incr`, `PCT_TexteBrut`, `PCT_Extraction` JSON, `PCT_Valide` JSON, `PCT_Utilisateur`, `PCT_Date`, créée par Jean-Marc directement en base, jamais par Claude). `PCT_Extraction` est la sortie brute et honnête du LLM, jamais retouchée après coup ; `PCT_Valide` est ce que Jean-Marc valide réellement après relecture — les deux ont vocation à diverger dans leur forme, c'est voulu, rien n'est perdu silencieusement (voir plus bas, redesign des actions).
+
+## `contact_ia_interprete.php` — extraction structurée
+
+Lit à chaque appel `ASP_Statuts`, `ASP_Professions`, `ASP_Agents` (`AGN_Incr, AGN_Nom, AGN_Fonction, AGN_Variantes`, dans cet ordre — voir plus bas pourquoi `AGN_Defaut` n'y figure pas) et `ASP_Actions`, pour construire un JSON Schema strict envoyé à OpenAI (`gpt-5.6-luna`, choisi pour son coût — modèle plus capable `gpt-5.6-terra` documenté en réserve si la qualité d'extraction se révèle insuffisante à l'usage réel, non activé pour l'instant). Le schéma couvre les champs classiques d'un contact, `profession_existante_id`/`profession_nouvelle_libelle`, `assistant_id`, et un tableau `actions[]` (voir ci-dessous). Re-validation défensive côté PHP après réponse du LLM : `CNT_Statut`, `assistant_id` et chaque `action_existante_code` sont revérifiés contre les valeurs réelles de la base avant renvoi au client — le LLM ne peut jamais faire accepter une valeur qui n'existe pas vraiment.
+
+**Décision architecturale actée en session : l'attribution d'un assistant par défaut n'est pas le rôle de cette couche.** Premier réflexe de Claude : pré-sélectionner l'assistant par défaut (`AGN_Defaut`, aujourd'hui Matilda) côté serveur ou côté panneau quand aucun nom n'est dicté. Correction de Jean-Marc : cette couche doit rester un enregistreur honnête de ce qui a été réellement dit ; les règles métier (à qui attribuer une tâche sans assistant nommé) relèvent d'un futur traitement n8n qui transformera les propositions validées en vrais post-its, pas de cette interprétation. Revert : colonne `AGN_Defaut` retirée de la requête SQL (redevenue identique à celle d'`agents.php`), toute logique de pré-sélection retirée de `contact_ia_panel.js`, décision documentée en commentaire dans les deux fichiers.
+
+**Détection et classement de l'action "ajouter le contact" — confirmée comme une vraie décision du LLM, pas un cas codé en dur** (question posée explicitement par Jean-Marc en fin de session, vérifiée avec lui dans le prompt réel). La consigne du prompt système précise que la création du contact lui-même ("ajoute ce contact", "crée-le", "enregistre ce contact"...) est une action à part entière, sans code dans `ASP_Actions`, à retourner avec le libellé fixe `"Ajouter le contact"` dans `action_nouvelle_libelle` (formulation figée, pour rester comparable d'une dictée à l'autre) — et que, lorsqu'elle est demandée, elle doit toujours être placée en premier dans le tableau `actions`, avant les autres actions éventuelles, car c'est en général la première chose voulue chronologiquement. Un tri côté client dans `contact_ia_panel.js` (voir plus bas) sert uniquement de filet de sécurité si le LLM ne respectait pas l'ordre, pas de mécanisme de détection.
+
+## `contact_ia_valide.php` — le seul point d'écriture
+
+`INSERT` unique dans `ASP_PropositionsContact`, POST JSON `{texteBrut, extraction, valide}`. Ne relit ni ne valide le contenu de `valide` (colonne JSON opaque). En-tête mis à jour en session pour documenter un changement de forme sans conséquence de schéma : `valide.actions` est passé, le même soir, d'un tableau d'objets `{action_existante_code, action_nouvelle_libelle}` à un simple tableau de libellés texte, suite au redesign de la zone actions (voir ci-dessous) — point à connaître pour qui construira plus tard le consommateur n8n de cette table.
+
+## `contact_ia_panel.js` — le panneau flottant, nombreuses itérations dans la session
+
+Remplace `micro_test.js` sur `#micro-desk` (`ecran_fond.html`). Construit un panneau flottant (`#panneau-contact-ia`) avec une prompt terminal en deux temps ("attente" curseur clignotant, puis "prêt" — micro ouvert, parlez), la restitution de la dictée brute, et un formulaire d'analyse (identité, statut, profession avec repli "nouvelle profession", coordonnées, assistant, actions, bouton Valider unique).
+
+**Simplification de la zone actions.** Premier essai avec un motif complexe (une ligne par action détectée, choix dynamique existant/nouveau par ligne) jugé trop lourd pour un essai vocal rapide — objectif de cette phase étant justement de repérer les actions non encore couvertes par `ASP_Actions`, pas de construire une UI de gestion aboutie. Remplacé par 3 zones de texte libre, pré-remplies avec le texte résolu de chaque action détectée (code existant → son libellé, ou libellé nouveau du LLM), triées pour que "Ajouter le contact" arrive toujours en premier (filet de sécurité, voir plus haut) ; au-delà de 3 actions détectées, les suivantes restent intactes dans `PCT_Extraction` mais non éditables dans l'UI pour cet essai. `collecterActionsValidees()` renvoie désormais un simple tableau de chaînes.
+
+**Dimensionnement et défilement du panneau.** Demande de Jean-Marc : que la fenêtre prenne tout de suite sa taille maximale disponible (jusqu'au bas de l'écran sous le bouton micro), l'ascenseur apparaissant ensuite si besoin, sur toute la hauteur de la fenêtre — y compris au prix de faire disparaître les deux premières lignes de prompt en cas de défilement. Résolu en fusionnant l'en-tête de prompt, la zone de restitution et le formulaire de résultat en une seule région scrollable (`.contenu-scrollable`, `flex:1; min-height:0; overflow-y:auto`) à l'intérieur d'une colonne flex de hauteur fixe, celle-ci calculée immédiatement à l'ouverture par `ajusterHauteurPanneau()` (hauteur, pas max-height, basée sur la position réelle du bouton micro moins une marge), recalculée au redimensionnement de fenêtre. Ascenseur discret personnalisé (fin, sombre) sur cette même zone.
+
+**Lisibilité des `<option>` des listes déroulantes.** Signalé par Jean-Marc : texte blanc sur fond blanc, et blanc sur fond bleu pour l'option survolée/sélectionnée, sur le statut comme sur la profession. Corrigé par un style explicite (`option{background:#1a1a1a;color:#999}`, `option:checked,option:hover{background:#999;color:#111}`) — réserve honnête : Chrome conserve nativement sa propre surbrillance de survol pour l'option "active" quelle que soit la CSS appliquée (Firefox la respecte mieux), donc le résultat n'est pas identique à 100% d'un navigateur à l'autre, mais le cas bloquant (texte invisible) est bien résolu partout.
+
+**Micro fermé après Valider, panneau qui se fermait aussi.** Deux frictions remontées ensemble par Jean-Marc en test réel : *"valider sort de la fenêtre ce qui n'est pas pratique pour en dicter plusieurs à la suite"*, puis *"on revient en écran vierge, mais il ne se passe rien et je pense que le micro est fermé"* (diagnostic confirmé exact). Corrigé en deux temps : le panneau ne se ferme plus jamais après un Valider réussi (retrait de l'appel qui masquait `#panneau-contact-ia`) ; une nouvelle fonction partagée `demarrerEcoute()` (factorisée depuis le clic du bouton micro) est désormais appelée automatiquement 1,8s après un Valider réussi si le micro n'a pas déjà été redémarré manuellement entre-temps — le panneau reste ouvert, prêt pour la dictée suivante, sans manipulation.
+
+**Bouton "Abandonner" retiré.** Faisait double emploi avec la touche Échap (déjà en place pour fermer le panneau) — retiré (bouton, CSS, variable, gestionnaire), `abandonnerPanneau()` conservée telle quelle, appelée uniquement par le gestionnaire Échap.
+
+**Arrêt automatique sur silence.** Ajout d'un minuteur de silence (`DUREE_SILENCE_ARRET_MS = 3500`, "3-4 secondes" demandées par Jean-Marc), armé seulement après le premier résultat de reconnaissance (pas dès l'ouverture du micro), réinitialisé à chaque nouveau résultat, traité comme un arrêt volontaire propre au bout de 3,5s sans nouvelle parole. Coexiste avec le coupe-circuit anti-boucle déjà en place (5 redémarrages en moins de 800ms) et l'arrêt d'inactivité absolue à 10 minutes (hérités de `micro_test.js`).
+
+**Garde défensive ajoutée suite à une erreur en test réel.** Jean-Marc a rencontré `Cannot read properties of undefined (reading 'forEach')` en cours d'essai. Revue statique du code n'a pas permis d'isoler une cause certaine (PDO en `ERRMODE_EXCEPTION`, requête agents identique à celle, déjà fiable, d'`agents.php`) — protection ajoutée par prudence : gardes `(x || [])` sur `remplirStatuts`, `remplirProfessions` et `remplirAssistant`, sur le même principe que celui déjà en place dans `remplirActions`. Aucune récidive rapportée depuis.
+
+**Fausse alerte : dropdown assistant vide.** Investigation engagée après un signalement de liste déroulante d'assistants vide malgré une base réellement peuplée (6 agents, 4 actifs) — hypothèse un temps envisagée d'un mauvais routage MIRADOR entre bases. Une option de diagnostic *"(aucun assistant en base)"* a été ajoutée dans `remplirAssistant()` en cours d'investigation (conservée, coût nul). Conclusion de Jean-Marc lui-même : *"c'est une erreur de copier/coller"* de son côté, pas un bug — refermé sans autre correction.
+
+### Version applicative
+
+`V1.012` pour l'ensemble de cette session (une seule incrémentation, conformément à la règle du journal).
+
+## Relecture du corpus réel (11 premiers essais, fin de session)
+
+Jean-Marc a transmis un export SQL de `ASP_PropositionsContact` (11 lignes) pour un premier bilan qualité. Constat global positif — Jean-Marc : *"les tests sont vraiment encourageants."* Points relevés par Claude à cette relecture :
+
+- **"Ajouter le contact" confirmée fonctionnelle et bien classée** à partir de l'essai n°7 (les tout premiers essais précédaient la mise en place de la règle de classement).
+- **Bug d'extraction identifié, non corrigé** : sur l'essai n°2, l'adresse mail extraite est `"Monsieur Paul lefébure@gmail.com"` — le LLM n'a ni retiré le mot d'appel dicté avant l'adresse ("Monsieur Paul"), ni supprimé l'accent sur "lefébure" pourtant couvert par une consigne explicite du prompt sur les adresses mail sans accent. Jean-Marc a dû corriger à la main. **Piste proposée par Claude, pas encore mise en œuvre** : renforcer la consigne du prompt pour aussi neutraliser les mots parasites/formules de politesse autour d'une adresse dictée, en plus de la règle d'accents déjà en place — en attente d'un feu vert explicite de Jean-Marc.
+- **Coupure possible en fin de dictée** : le texte brut de l'essai n°7 se termine en plein mot ("...aspic son"), ce qui pourrait indiquer une troncature par le nouveau minuteur de silence (3,5s). Question posée à Jean-Marc ; sa réponse évoque une autre piste possible (le chat venant parfois le déranger à son bureau pendant qu'il dicte) sans trancher explicitement si ce cas précis vient du chat ou du minuteur, ni donner d'instruction de changer la valeur. **Point resté ouvert**, `DUREE_SILENCE_ARRET_MS` non modifiée dans l'attente d'un diagnostic plus net.
+- **Profession "Informaticien" apparue deux fois comme nouvelle profession** sur des dictées différentes du corpus. Jean-Marc, interrogé, a confirmé que c'est une situation acceptable et attendue en l'état : une profession peut être marquée "nouvelle" plusieurs fois tant qu'un assistant n'a pas traité le post-it correspondant ; le traitement du post-it devra simplement 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 changement de code nécessaire pour ce point.
+- Différences ponctuelles `null` vs chaîne vide entre `PCT_Extraction` et `PCT_Valide` : jugées normales et sans gravité (simplification attendue au passage par le formulaire de validation).
+
+## Point de conception pour une prochaine session (noté par Jean-Marc, non conçu ni codé)
+
+En clôture, Jean-Marc a formulé une réflexion architecturale à reprendre plus tard : la notion d'action sur un contact devra probablement évoluer pour intégrer formellement "création du contact" comme une action à part entière — dont le classement la place toujours en premier — mais qui ne serait pas accessible **que** par le LLM : l'utilisateur humain doit aussi pouvoir la déclencher depuis un menu ou un raccourci clavier. Il faut cependant que cette action reste connue du LLM, et que le retour de celui-ci vienne s'insérer dans le même classement ordonné, pour que les ordres passés à l'assistant vocal restent cohérents avec ceux disponibles par les écrans classiques. Jean-Marc souhaite généraliser ce principe à l'ensemble des autres actions : une séparation claire entre les actions utilisables par l'utilisateur humain (menu/clavier) et celles utilisables par le LLM de saisie vocale, tout en gardant un vocabulaire d'actions unique et cohérent entre les deux voies d'accès — écho direct du constat de satisfaction qu'il tire de cette journée : *"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 !"* Non conçu, non codé — à reprendre dans une prochaine session.
+
+## Reste à faire, noté au passage
+
+- Décider (avec l'accord explicite de Jean-Marc, pas encore donné) s'il faut renforcer le prompt d'extraction pour neutraliser les mots parasites/formules de politesse dictés autour d'une adresse mail, en plus de la règle d'accents déjà en place.
+- Clarifier l'origine de la coupure en fin de dictée observée sur l'essai n°7 (minuteur de silence à 3,5s vs interruption réelle) avant de décider si `DUREE_SILENCE_ARRET_MS` doit être allongée.
+- Concevoir la séparation "actions utilisables par l'utilisateur humain (menu/clavier)" / "actions utilisables par le LLM de saisie vocale", avec une notion de "création du contact" formalisée comme action à part entière toujours classée en premier, connue des deux voies d'accès et cohérente entre elles (voir ci-dessus) — réflexion actée par Jean-Marc, non conçue, non codée.
+- Poursuivre la constitution du corpus réel sur "Gestion des Contacts" (Jean-Marc prévoit de réutiliser ce même écran dès le lendemain pour des demandes de modification/suppression de contact) et suivre si le taux de doublons de nouvelles professions reste gérable en pratique au fil du volume.
+- Étendre progressivement, comme annoncé par Jean-Marc, ce même principe d'écran (dictée + interprétation LLM + panneau de validation) aux autres applications d'ASPIC.
+- Rappel toujours valable (sections 26/27/28) : `ASP_ToDoList`/`todolist.php` doivent être étendus pour qu'une tâche puisse être réellement attribuée à un assistant avant qu'un vrai post-it puisse être généré à partir d'une proposition validée de cette table — prérequis explicitement posé par Jean-Marc avant d'aller plus loin sur le traitement n8n.