V1.006 Suite de l'intégration de la voix

This commit is contained in:
2026-09-02 14:25:33 +00:00
parent 3126ef9403
commit 95424b2dce
9 changed files with 665 additions and 193 deletions
+17 -5
View File
@@ -105,12 +105,24 @@ En marge de sa recherche d'un serveur Hostinger plus puissant, Jean-Marc a déco
## 10. Répondeur téléphonique intelligent — projet distinct, exploration initiale (1er-2 septembre 2026)
*Section volontairement séparée de tout ce qui précède : ce n'est pas un chantier ASPIC, mais un projet à part que Jean-Marc envisage de développer en parallèle — capturé ici parce que la discussion en est partie d'un point technique abordé côté ASPIC (le pilotage vocal "Lilou", voir journal de développement section 27) mais dépasse largement ce cadre.*
*Section volontairement séparée de tout ce qui précède : ce n'est pas un chantier ASPIC, mais un projet à part que Jean-Marc envisage de développer en parallèle — capturé ici parce que la discussion en est partie d'un point technique abordé côté ASPIC (le pilotage vocal, voir journal de développement section 27) mais dépasse largement ce cadre.*
**Origine de la discussion :** en travaillant sur le pilotage vocal d'ASPIC, Jean-Marc s'est demandé si la reconnaissance de commandes allait rapidement nécessiter des bases de données vectorielles (PostgreSQL/pgvector), redoutant que ça complique sérieusement le sujet. Réponse apportée : pas pour Lilou dans sa forme actuelle — un ensemble borné et restreint de commandes/intentions relève d'une simple classification par mots-clés/regex, pas d'une recherche sémantique ; une base vectorielle serait de la sur-ingénierie pour ce cas précis. Jean-Marc a alors précisé que ce besoin allait en revanche réellement se poser pour un autre projet qu'il envisage : un **répondeur téléphonique intelligent**, branché sur une ligne téléphonique.
**Origine de la discussion :** en travaillant sur le pilotage vocal d'ASPIC, Jean-Marc s'est demandé si la reconnaissance de commandes allait rapidement nécessiter des bases de données vectorielles (PostgreSQL/pgvector), redoutant que ça complique sérieusement le sujet. Réponse apportée : pas pour le pilotage vocal d'ASPIC dans sa forme actuelle — un ensemble borné et restreint de commandes/intentions relève d'une simple classification par mots-clés/regex, pas d'une recherche sémantique ; une base vectorielle serait de la sur-ingénierie pour ce cas précis. Jean-Marc a alors précisé que ce besoin allait en revanche réellement se poser pour un autre projet qu'il envisage : un **répondeur téléphonique intelligent**, branché sur une ligne téléphonique.
**Compréhension du principe, confirmée par Jean-Marc :** l'assemblage de plusieurs briques distinctes — transformation de la voix de l'appelant en texte (un peu comme le fait Lilou côté ASPIC ce soir), interrogation d'une base de connaissances via recherche vectorielle (pour retrouver l'information ou la réponse pertinente dans un corpus potentiellement large et ouvert, contrairement au jeu de commandes fermé de Lilou), puis transformation de la réponse en voix de synthèse — le tout avec une contrainte de latence forte et explicitement nommée par Jean-Marc : l'interlocuteur humain au bout du fil ne doit à aucun moment se demander si "la personne en face s'est endormie". C'est cette contrainte de réactivité en temps quasi réel, combinée à un corpus de connaissances potentiellement vaste et évolutif (contrairement à la liste fermée de commandes de Lilou), qui justifie cette fois le recours à une base vectorielle — la nuance posée par Claude étant que le besoin vient de la nature du problème (recherche sémantique sur corpus ouvert) et pas de la voix en tant que telle.
**Compréhension du principe, confirmée par Jean-Marc :** l'assemblage de plusieurs briques distinctes — transformation de la voix de l'appelant en texte (un peu comme le fait le pilotage vocal côté ASPIC), interrogation d'une base de connaissances via recherche vectorielle (pour retrouver l'information ou la réponse pertinente dans un corpus potentiellement large et ouvert, contrairement au jeu de commandes fermé d'ASPIC), puis transformation de la réponse en voix de synthèse — le tout avec une contrainte de latence forte et explicitement nommée par Jean-Marc : l'interlocuteur humain au bout du fil ne doit à aucun moment se demander si "la personne en face s'est endormie". C'est cette contrainte de réactivité en temps quasi réel, combinée à un corpus de connaissances potentiellement vaste et évolutif (contrairement à la liste fermée de commandes du pilotage vocal ASPIC), qui justifie cette fois le recours à une base vectorielle — la nuance posée par Claude étant que le besoin vient de la nature du problème (recherche sémantique sur corpus ouvert) et pas de la voix en tant que telle.
**Infrastructure déjà disponible sur le VPS de Jean-Marc, repérée en marge du débogage de ce soir** (`docker ps -a`, 2 septembre 2026) : une instance **PostgreSQL avec l'extension pgvector** (`pgvector/pgvector:pg16-trixie`) tourne déjà, aux côtés de **n8n** (déjà utilisé et évoqué comme brique d'orchestration possible pour l'interprétation des dictées Lilou, section 27 du journal) et de **LangFlow** (outil de composition de flux IA, potentiellement pertinent pour assembler les briques voix→texte→recherche→texte→voix de ce futur répondeur). Rien n'indique que ces instances aient été mises en place spécifiquement pour ce projet — probablement des briques déjà expérimentées pour d'autres besoins — mais elles constituent une base technique déjà en place le jour où Jean-Marc voudra vraiment démarrer ce chantier, sans avoir à réinstaller quoi que ce soit.
**Infrastructure déjà disponible sur le VPS de Jean-Marc, repérée en marge du débogage du pilotage vocal** (`docker ps -a`, 2 septembre 2026) : une instance **PostgreSQL avec l'extension pgvector** (`pgvector/pgvector:pg16-trixie`) tourne déjà, aux côtés de **n8n** (déjà utilisé et évoqué comme brique d'orchestration possible pour l'interprétation des dictées du pilotage vocal, section 27 du journal) et de **LangFlow** (outil de composition de flux IA, potentiellement pertinent pour assembler les briques voix→texte→recherche→texte→voix de ce futur répondeur). Rien n'indique que ces instances aient été mises en place spécifiquement pour ce projet — probablement des briques déjà expérimentées pour d'autres besoins — mais elles constituent une base technique déjà en place le jour où Jean-Marc voudra vraiment démarrer ce chantier, sans avoir à réinstaller quoi que ce soit.
**Statut : simple exploration conceptuelle, aucun développement engagé.** Jean-Marc a explicitement mis ce projet de côté pour revenir au pilotage vocal d'ASPIC ("c'est une autre aventure ! [...] Revenons à notre micro sous aspic."). À reprendre le jour où il voudra s'y consacrer, avec cette base d'infrastructure déjà cadrée.
**Statut : simple exploration conceptuelle, aucun développement engagé.** Jean-Marc a explicitement mis ce projet de côté pour revenir au pilotage vocal d'ASPIC. À reprendre le jour où il voudra s'y consacrer, avec cette base d'infrastructure déjà cadrée.
## 11. Le "bureau à l'ancienne" — délégation à plusieurs assistants IA nommés (réflexion long terme, 2 septembre 2026)
**Origine.** Née en marge des essais du pilotage vocal multi-agents (voir journal de développement, section 27) : une fois plusieurs assistants nommés distincts (Viktor, Matilda...) capables de recevoir des consignes vocales chacun sur son périmètre, Jean-Marc a partagé une vision plus large pour l'évolution de l'interface d'ASPIC à long terme.
**Le principe.** Remplacer les écrans CRUD traditionnels par une métaphore de bureau à l'ancienne : un tableau de liège avec des post-its de couleur, un par assistant IA, des dossiers de vérification, un agenda, un téléphone. L'utilisateur délègue oralement à plusieurs assistants nommés, chacun responsable d'un périmètre (voir `AGN_Fonction` dans `ASP_Agents` — Agent Commercial, Agent Administratif...). Différence assumée avec une assistante humaine : un agent IA n'a pas la faculté de procrastiner ou de remettre une tâche à plus tard sans raison — il agit, ou explique pourquoi il n'a pas pu.
**Interface volontairement basique.** Pas une interface "sexy" ou soignée visuellement — la valeur réelle est vue comme résidant dans la structure des données et la couche de délégation, pas dans l'habillage visuel. Cohérent avec la philosophie déjà en place dans ASPIC (pas de sur-ingénierie, PHP/JS vanilla plutôt que framework).
**Périmètre et statut.** Vision explicitement limitée à ASPIC lui-même à ce stade, pas un projet d'outillage plus large. Jean-Marc reconnaît que cette réflexion peut évoluer avec l'expérience acquise sur le terrain — voir justement le principe ci-dessous, tiré d'un premier retour d'expérience concret le jour même. Aucun développement engagé — pure réflexion à ce stade, capturée ici pour mémoire.
**Principe de conception qui en découle, tiré de l'expérience réelle du pilotage vocal (2 septembre 2026) :** mieux vaut choisir des noms d'agents qui passent bien nativement à la reconnaissance vocale que d'empiler des tolérances pour rattraper un nom mal choisi — chaque tolérance ajoutée étant à la fois un risque de faux déclenchement (si elle recoupe un mot français courant) et un pari sur un seul accent/une seule prononciation testée, fragile face à la diversité réelle des utilisateurs. Deux agents (Lilou, Karl) ont été retirés sur cette base après des essais répétés peu concluants, plutôt que d'être maintenus à coups de correctifs successifs. Principe à garder en tête si le "bureau à l'ancienne" se concrétise un jour avec davantage d'assistants nommés.