V1.005 Débuts de l'intégration de la voix

journal/ASPIC - Documentation utilisateur.md

@@ -0,0 +1,76 @@
+# ASPIC — Documentation utilisateur
+
+*Application de Suivi des Prospects et Ingénierie Commerciale*
+
+Ce document explique comment utiliser ASPIC au quotidien, écran par écran. Il est écrit pour l'utilisateur de l'application, pas pour un développeur — pour les détails techniques (choix d'architecture, code, structure de la base de données), voir le "Journal de développement ASPIC", document séparé dans ce même projet.
+
+Ce premier jet couvre les deux écrans construits à ce jour (identification et liste des contacts). Il sera complété au fur et à mesure que de nouveaux écrans seront ajoutés à l'application.
+
+## 1. Se connecter à ASPIC
+
+Au lancement de l'application, l'écran d'identification s'affiche. Il comporte deux champs :
+
+- **Identifiant** : votre code utilisateur.
+- **Mot de passe** : un clic sur l'icône en forme d'œil, à droite du champ, permet d'afficher ou de masquer temporairement le mot de passe saisi, pour vérifier qu'il est correct avant de valider.
+
+Un clic sur **Valider** (ou la touche Entrée) tente la connexion.
+
+**En cas d'erreur :** un message s'affiche en rouge par-dessus le formulaire. ASPIC vous laisse trois tentatives :
+
+- 1ʳᵉ tentative incorrecte : *"Utilisateur ou mot de passe incorrect. Il vous reste 2 essais"*.
+- 2ᵉ tentative incorrecte : *"Utilisateur ou mot de passe incorrect. Dernier essai"*.
+- 3ᵉ tentative incorrecte : l'application se ferme, sans message supplémentaire.
+
+Pour fermer ce message d'erreur sans quitter l'application et corriger votre saisie, appuyez sur **Échap**.
+
+**Quitter l'application** : la touche **Échap**, utilisée à tout autre moment sur cet écran (aucun message d'erreur affiché), ferme directement l'application.
+
+Une fois l'identification réussie, vous êtes automatiquement redirigé vers l'écran "Liste des contacts".
+
+## 2. La liste des contacts
+
+C'est l'écran d'accueil de l'application une fois connecté : un tableau présentant tous vos contacts actifs, avec sept colonnes — Nom, Prénom, Département, Ville, Téléphone, Portable, Mail.
+
+### Se repérer dans la liste
+
+La barre en bas de l'écran indique en permanence : le nombre de contacts actuellement affichés sur le nombre total de contacts actifs, le tri en cours, et le filtre actif s'il y en a un.
+
+### Trier la liste
+
+Un clic sur l'en-tête **Nom** ou **Ville** trie la liste sur cette colonne ; un nouveau clic inverse le sens (croissant/décroissant). Les deux petites flèches à côté du titre de colonne indiquent le sens de tri actuellement sélectionné, et peuvent aussi être cliquées directement.
+
+### Se déplacer et sélectionner un contact
+
+- Un clic sur une ligne la sélectionne (encadré vert).
+- Les flèches **haut/bas** du clavier déplacent la sélection ligne par ligne.
+- **Page précédente / Page suivante** font défiler la liste par blocs.
+- La touche **Entrée**, une fois un contact sélectionné, ouvre son détail *(écran à venir — pour l'instant un message temporaire s'affiche à la place)*.
+
+### Actions sur un contact : le menu contextuel
+
+Un **clic droit** sur une ligne sélectionne d'abord cette ligne, puis ouvre un petit menu avec deux actions : *Ajouter un nouveau contact* et *Afficher le détail de ce contact*.
+
+Un **double clic droit** rapide sur la même ligne ouvre directement le détail du contact, sans passer par le menu.
+
+### Filtrer la liste
+
+L'icône en forme d'entonnoir, dans le bandeau du haut, ouvre le panneau de filtre. Vous pouvez filtrer sur n'importe laquelle des sept colonnes affichées (Nom, Prénom, Département, Ville, Tél, Portable, Mail), en combinant plusieurs filtres à la fois si besoin.
+
+**Recherche par préfixe :** en terminant une valeur de filtre par une étoile (`*`), ASPIC recherche tous les contacts dont le champ *commence par* le texte saisi. Par exemple, `FOUR*` sur le champ Nom retrouve "Fournier", "Fourneau", etc. Sans étoile, la recherche cherche une correspondance exacte (la casse — majuscules/minuscules — n'a pas d'importance).
+
+La case à cocher **Supprimer les filtres**, en haut du panneau, vide et désactive tous les champs de filtre en une seule action.
+
+Une fois les filtres saisis, le bouton **Appliquer** met à jour la liste ; **Réinitialiser** efface la saisie du formulaire sans quitter le panneau. L'icône entonnoir se met en surbrillance dès qu'un filtre est actif, pour le rappeler visuellement même une fois le panneau refermé.
+
+### Le menu principal
+
+L'icône en forme de menu ("hamburger"), en haut à gauche, ouvre un menu avec les grandes sections de l'application. À ce stade, seule *Gestion des contacts* (cet écran) est active ; *Gestion des actions* et *Documentation* apparaissent grisées, en attente de leur développement.
+
+### Fermer un panneau ouvert
+
+Quel que soit le panneau actuellement ouvert (menu contextuel, menu principal, ou panneau de filtre), la touche **Échap** le referme. Si aucun panneau n'est ouvert, Échap n'a pas d'effet sur cet écran.
+
+## À venir
+
+- **Écran de détail du contact** : consultation et modification des informations d'un contact, et de l'historique de ses réalisations (actions menées auprès de lui — appels, échanges, prospections… — chacune pouvant porter son propre commentaire).
+- Les données affichées correspondent à vos contacts actifs uniquement ; un contact supprimé n'est pas détruit mais simplement retiré de cette liste (récupérable en cas de besoin, fonctionnalité à venir).

journal/ASPIC - Journal. Index.md

@@ -0,0 +1,56 @@
+# ASPIC — Journal de développement (index)
+
+*CRM sur mesure — PHP + MySQL + JavaScript vanilla*
+
+**Le détail complet du journal est désormais tenu dans le dépôt GitHub `JMP-MS/ASPIC`, dossier `/journal`** (26 fichiers `.md`, un par grande section, protégés en accès web direct par un `.htaccess`). Ce document ne garde plus qu'un sommaire et l'état actuel, pour une vue d'ensemble rapide sans avoir à cloner le dépôt. Pour toute question qui touche à l'historique détaillé d'une section, demander sa lecture — Claude ira la chercher sur GitHub avec le token transmis en session (jamais stocké).
+
+## Consigne de travail (Claude) — à partir du 2 septembre 2026
+
+Pour les trois documents de ce projet (ce journal — résumé/index —, les Réflexions stratégiques, la Documentation utilisateur), **ainsi que pour les fichiers de section individuels du journal détaillé** (`/journal` sur GitHub, 28 sections numérotées 00 à 27 au 2 septembre 2026) : les mises à jour de contenu ne sont faites qu'**en toute fin de session**, jamais au fil de l'eau pendant les essais — pour éviter d'enregistrer un état intermédiaire ou instable. À ce moment-là, en plus d'écrire la mise à jour dans le document du projet le cas échéant, Claude fournit systématiquement une **copie téléchargeable** (fichier `.md`) de chaque document ou section modifié(e), pour que Jean-Marc puisse la sauvegarder de son côté et la déposer dans le dépôt GitHub. Pour une section du journal détaillé, le fichier téléchargeable reprend le nom exact utilisé dans `/journal` sur GitHub, pour un dépôt direct sans renommage.
+
+## Sommaire des sections (`/journal` sur GitHub)
+
+- 00. Présentation
+- 01. Contexte et décision d'architecture
+- 02. Modèle de données
+- 03. Architecture technique
+- 04. Fichiers de l'application
+- 05. Points de friction
+- 06. Pistes pour la suite
+- 07. Statut actuel
+- 08. Écran d'identification
+- 09. Écran liste des contacts
+- 10. Écran détail du contact
+- 11. Traitements de données de l'écran détail
+- 12. Notion de session utilisateur
+- 13. Prochaines étapes côté frontend
+- 14. Pivot sur le modèle de prospection
+- 15. Implémentation session utilisateur
+- 16. Panneau de détail du contact — création/suppression
+- 17. Panneau détail redimensionnable
+- 18. Formulaire de prospect externe
+- 19. Navigation entre contacts en panneau détail
+- 20. Dépôt GitHub et mirroir Gitea
+- 21. MIRADOR — base d'authentification centralisée
+- 22. Badge société et avatar utilisateur
+- 23. Push GitHub en SSH depuis le VPS
+- 24. MIRADOR branché
+- 25. MIRADOR validé à deux utilisateurs
+- 26. ToDoList
+- 27. Pilotage vocal (Lilou)
+
+*(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 26 confirmée présente dans le dépôt le 1er septembre 2026. Section 27 (Pilotage vocal) n'a en revanche pas encore son fichier dans `/journal` au moment de cette mise à jour — comportement pas encore stabilisé, voir Reste à faire ci-dessous ; fichier à créer une fois le test de bout en bout confirmé.)*
+
+## Statut actuel (2 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).
+
+**31 août 2026 : ToDoList.** Nouvel écran, devenu l'écran d'accueil post-connexion (la liste des contacts passe dans le menu hamburger). Table `ASP_ToDoList`, trois indicateurs d'urgence par pastille (rouge = à faire sans date ou en retard, orange = à faire dans les temps, vert = réalisé), tri par urgence calculé côté PHP. `TDL_ToDoDate` (date de création) reste éditable pour permettre l'antidatage d'une tâche oubliée. Nouveaux endpoints `todolist.php` et `utilisateurs.php`, nouvel écran `liste_todolist.html` (même gabarit que `liste_contacts.html`, hauteur de panneau égalisée entre les trois modes). Livré, testé (Playwright) et déployé — version **V1.004**, qui inclut aussi ce découpage du journal.
+
+**1er septembre 2026 : migration du sous-domaine de bêta test.** L'environnement de test bascule de `aspic.bzh` vers `crm.aspic.bzh`. Objectif : libérer la racine du domaine pour y installer, dans quelques mois, un site de promotion de la solution — si le contexte business évolue favorablement dans ce sens (voir réflexions stratégiques, section 7). Aucun changement fonctionnel côté application ; toute mention antérieure d'`aspic.bzh` comme environnement de test (dans ce document comme dans le journal détaillé sur GitHub) désigne donc désormais `crm.aspic.bzh`.
+
+**1er-2 septembre 2026 (nuit) : pilotage vocal — Lilou, phase 1.** Nouveau bouton micro dans le bandeau (positionné après l'avatar, pour une place fixe à l'écran), comportement centralisé dans un fichier partagé `micro.js` chargé sur chaque écran hôte — reconnaissance vocale réelle via l'API Web Speech du navigateur, écoute continue avec redémarrage automatique tant que l'utilisateur n'a pas explicitement refermé le micro, mot déclencheur "Lilou" (assistante vocale d'ASPIC, dans la même veine que "Viktor" côté contacts) pour ignorer la conversation de fond — tolérant aussi "Milou", confusion fréquente du moteur de reconnaissance sur ce prénom. Fonctionnalité livrée ce soir : le "mode notation", qui capture une dictée libre entre une phrase d'ouverture ("Lilou, ajoute une tâche" / "un truc à faire" / "note ça dans ma todolist") et une phrase de clôture ("c'est tout Lilou") ou d'annulation ("Lilou annule") — les deux traitées à l'identique, sans interprétation à ce stade, sur demande explicite de Jean-Marc — puis envoie le texte capté tel quel à un nouvel endpoint `lilou_notes.php`, qui l'ajoute, horodaté et attribué à l'utilisateur, à un fichier texte global (`notes_lilou/dictees.txt`, pensé pour être protégé par un `.htaccess` du même principe que `/journal`). Objectif : accumuler un vrai corpus d'essais réels avant de définir, dans un prochain chantier, des règles d'interprétation (étape 2, envisagée via n8n, avec des règles modifiables par l'utilisateur). Version incrémentée une fois pour cette session, **V1.005**.
+
+Longue session de débogage en conditions réelles cette nuit-là : plusieurs corrections apportées à `micro.js` (la clôture peut désormais porter à la fois la dernière ligne de contenu et la fin du lot dans une seule phrase, sans "ensuite" artificiel juste avant ; tolérance à la confusion "Lilou"/"Milou" ; fenêtre de quelques secondes pour recoller une phrase que le moteur de reconnaissance a coupée juste après la virgule suivant "Lilou"), et côté serveur (le fichier `lilou_notes.php` n'avait pas été déployé au premier essai ; droits d'écriture insuffisants sur `notes_lilou/` une fois déployé — dossier propriété de `1001:users`, `www-data` hors de ce groupe). Contournement provisoire en fin de session : `dictees.txt` écrit directement à la racine de l'application plutôt que dans `notes_lilou/`, donc **temporairement hors de toute protection `.htaccess`** — à corriger dès que possible. **Test de bout en bout non confirmé réussi au moment d'arrêter la session** ; à valider dès demain avec la dernière version livrée de `micro.js`.
+
+**Reste à faire, noté au passage :** 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` — risque connu que `AllowOverride None` côté Apache ignore silencieusement le fichier, voir échange du 31 août). Pour le pilotage vocal (section 27) : confirmer demain qu'une dictée complète produit bien `dictees.txt` ; une fois validé, remettre ce fichier sous la protection d'un `.htaccess` dans `notes_lilou/` (en corrigant durablement les droits d'écriture de `www-data` sur ce dossier — `chown`/`chmod`, ou ajout de `www-data` au groupe `users` — plutôt que de rouvrir le dossier en écriture pour tout le monde) ; créer alors le fichier de section 27 dans `/journal` sur GitHub. `notes_lilou/` (avec son contenu, y compris `dictees.txt` au fil de son remplissage) est destiné à être versionné et poussé sur GitHub comme le reste de l'application — décision explicite de Jean-Marc, pour qu'une future session Claude puisse lire ce corpus directement en clonant le dépôt.

journal/ASPIC - Reflexions strategiques.md

@@ -0,0 +1,116 @@
+# ASPIC — Réflexions stratégiques
+
+*Document séparé du journal de développement technique et de la documentation utilisateur. Rassemble les échanges à vocation stratégique/business autour du projet ASPIC et du projet d'agence de Jean-Marc — pas de décisions d'architecture ou de code ici (voir le journal de développement pour ça).*
+
+Démarré le 28 août 2026, lors d'une session explicitement dédiée aux aspects stratégiques (pas de réalisation de fonctionnalités).
+
+## 1. Contexte du projet d'agence
+
+Jean-Marc prépare la création d'une agence début 2027, pour proposer à des entrepreneurs (dans un premier temps en Bretagne) des solutions utilisant l'IA. En formation actuelle sur les outils du secteur. Position assumée dès le départ : refus d'appuyer son offre sur des outils no-code/low-code (Airtable, Lovable, Softr, etc.), pour des raisons à la fois techniques (limites structurelles, dépendance) et économiques (coûts récurrents mal adaptés à sa clientèle cible de petites structures). C'est ce qui a motivé l'acquisition du VPS et le choix d'architecture PHP+MySQL+JS vanilla d'ASPIC (voir journal de développement, section 1).
+
+ASPIC, initialement pensé comme un CRM interne "ersatz d'Airtable", est en train d'évoluer dans la tête de Jean-Marc vers quelque chose de potentiellement plus ambitieux (CRM enrichi en IA). Ce document capture la réflexion sur ce que ça implique, sans que rien ne soit tranché à ce stade.
+
+## 2. Capacité à suivre le projet dans la durée — Claude, abonnement, Git
+
+- **Croissance du projet et capacité de Claude à le suivre :** pas de rupture technique attendue tant que la discipline déjà en place est maintenue (journal de développement à jour, architecture en petits fichiers dédiés par écran/endpoint, sessions qui redémarrent "à froid" en relisant le projet plutôt qu'un fil de discussion qui s'éternise). Le vrai facteur de risque identifié n'est pas la taille du projet mais l'absence de contrôle de version (pas de Git à ce stade — livraison par transfert FTP avec versionnage manuel côté Jean-Marc). **Décision : installer Git, non urgent.** **Mise à jour du 28 août 2026 (matin) : Jean-Marc traitera l'installation de Git dans la session dédiée au projet de gestion du serveur, pas dans ce projet-ci — hors périmètre d'ASPIC à proprement parler.**
+- **Git et confidentialité :** clarifié que Git est un outil neutre (gestion de versions), pas intrinsèquement public — la confidentialité dépend uniquement de l'endroit où le dépôt est hébergé. Option recommandée compte tenu de la philosophie du projet : dépôt Git privé auto-hébergé sur le VPS (type Gitea/Forgejo), cohérent avec le refus des dépendances SaaS tierces déjà appliqué à ASPIC. Alternative : dépôt privé chez un hébergeur (GitHub/GitLab), également possible.
+- **Abonnement Anthropic et sessions parallèles :** vérifié via la documentation officielle — les limites d'usage (Pro/Max) sont un budget partagé par fenêtre de 5h + plafond hebdomadaire, commun à tous les produits Claude du compte, **pas** un compteur de sessions simultanées autorisées. Rien n'empêche déjà aujourd'hui de faire tourner plusieurs sessions en parallèle sur différents ordinateurs ; monter en gamme (Max 5x/20x) élargit le budget d'usage disponible pour soutenir cet usage sans buter sur les plafonds, mais ne "débloque" pas la fonctionnalité elle-même. Point non vérifiable avec certitude via la doc publique : existence ou non d'une limite technique dure sur le nombre de connexions simultanées, indépendante du budget d'usage. Point de vigilance à garder si le parallélisme devient réel : plusieurs sessions ne partagent pas un "cerveau" commun en temps réel, chacune ne sait que ce qu'elle relit (journal + doc utilisateur) — d'où l'intérêt de Git si plusieurs sessions doivent un jour toucher les mêmes fichiers.
+
+## 3. Confidentialité des données — compte Anthropic
+
+Question posée par Jean-Marc : garantie que le développement d'ASPIC (code, réflexion business) ne soit pas utilisé par Anthropic pour l'entraînement de ses modèles.
+
+- Deux régimes distincts chez Anthropic : les comptes professionnels (Claude for Work, Team, Enterprise, API) n'utilisent pas les conversations pour l'entraînement par défaut (confirmé par la documentation officielle), sauf participation explicite au "Development Partner Program". Les comptes grand public (Free/Pro/Max) ont un réglage dédié dans Paramètres → Confidentialité ("Contribuer à améliorer nos modèles d'IA").
+- **Vérifié et désactivé par Jean-Marc le 28 août 2026** sur son compte actuel (rattaché à "jmp.ia.bzh@gmail.com's Organization").
+- **Point à ressurveiller** si l'abonnement change de nature plus tard (ex. bascule vers un plan de type Claude for Work) — Jean-Marc en a pris note lui-même.
+
+## 4. La tentation GoHighLevel — usage-pont temporaire, pas fondation de l'offre
+
+Contexte : des formateurs contactés par Jean-Marc pour monter en compétence lui ont proposé GoHighLevel (outil marketing/CRM tout-en-un, ~97$/mois minimum en entrée de gamme, jusqu'à 497$/mois pour le mode "agence revendeuse en marque blanche") plutôt que de lui apprendre à construire l'équivalent lui-même, avec une promesse d'"accès gratuit".
+
+**Position de Jean-Marc, clarifiée après une première incompréhension de Claude sur ce point :** aucune intention de bâtir l'offre de sa future agence sur GoHighLevel. La réflexion porte uniquement sur un usage-pont temporaire, pour sa propre prospection, en attendant qu'ASPIC soit opérationnel — avec deux bénéfices visés (efficacité immédiate + étude des fonctionnalités pour inspiration future d'ASPIC) et une condition non négociable : pouvoir exporter ses données et les supprimer le jour de la bascule vers ASPIC.
+
+**Mise à jour du 28 août 2026 (soir) — offre confirmée par les formateurs :** gratuité annoncée pendant au moins un an (pas un simple essai de 14 jours), justifiée par des "relations privilégiées avec un responsable chez GHL" ; export des données annoncé comme total et sans restriction. Jean-Marc reste prudent et n'a rien signé. Point d'intérêt fonctionnel repéré au passage : publication automatisée sur Instagram, qui élargit le champ (pas seulement la prospection) — utile comme source d'inspiration pour ASPIC.
+
+Points de vigilance actés pour la suite :
+- Demander cet engagement de gratuité par écrit (email de confirmation, conditions précises, ou le compte lui-même une fois ouvert affichant clairement la durée) plutôt que de se fier à la parole rapportée d'intermédiaires ayant un intérêt commercial à la signature — une "relation privilégiée" informelle avec une personne chez GHL peut s'éteindre sans que ça dépende de Jean-Marc.
+- Vérifier l'export réellement, une fois le compte ouvert, sur des données de test — pas se fier à la garantie verbale, même donnée de bonne foi (même discipline que pour tous les autres sujets de cette session : tester plutôt que croire sur parole).
+- Si sous-compte chez un tiers plutôt que compte à son nom propre : qui est propriétaire du compte parent, et devenir des données en cas de rupture de la relation.
+- Richesse réelle de l'export (CSV basique vs historique complet des interactions) et volet RGPD (données de prospects réels) — non traités en profondeur, juste signalés comme points à ne pas négliger.
+- Nouveau, lié à la fonctionnalité Instagram repérée : connecter GHL à un compte Instagram/Meta professionnel expose une catégorie de donnée différente (des accès/jetons, pas de simples enregistrements) — prévoir, le jour du retrait, de révoquer proprement cet accès en plus d'exporter les données.
+
+**Alternative explorée en parallèle (voir section 9) : Hostinger Agents + Google Sheets, jugée par Jean-Marc moins risquée pour ses vraies données que GHL, le chemin d'export/sortie y étant mieux compris et mieux documenté.** GHL reste une option à tester en parallèle (données factices), les deux pistes n'étant pas exclusives l'une de l'autre.
+
+## 5. Modèle de commercialisation futur d'ASPIC — hypothèse de travail, non tranchée
+
+Projection à ~1 an : si un marché se confirme pour déployer ASPIC chez des clients, deux modèles distincts identifiés, avec des implications différentes :
+
+- **(a) Éditeur logiciel sous licence, déployé chez chaque client** — proche de la vision de portabilité initiale du projet (section 6 du journal de développement). Écarté par Jean-Marc pour ASPIC lui-même : risque de dissémination du produit hors de son contrôle ("faire des petits"), cohérent avec un constat déjà posé dans le journal le 22 août — aucune protection réelle n'existe pour du PHP/JS vanilla livré tel quel sur un hébergement mutualisé bas de gamme. **Reste autorisé et prévu :** déployer des solutions spécifiques "one-shot" chez des clients, réutilisant la même pile technique (MySQL/PHP/JS) et les mêmes conventions/méthodes de travail, sans que ce soit le produit ASPIC lui-même.
+- **(b) SaaS centralisé, hébergé et opéré par Jean-Marc, licence annuelle** — hypothèse ouverte, non tranchée. Réglerait le problème de protection IP du point (a) (le code ne quitte jamais le serveur de Jean-Marc), mais implique une responsabilité opérationnelle bien plus lourde (uptime, sauvegardes, sécurité, support) pour l'ensemble des clients simultanément — à intégrer dans le calcul du prix de la future licence, par comparaison avec le tarif GoHighLevel (~1200$/an) qui finance en partie ce type d'infrastructure.
+
+**Dimensionnement technique envisagé si (b) est un jour retenu** (réflexion préliminaire, pas un plan d'exécution) : repère de départ = VPS Hostinger haut de gamme (offre KVM 8 : 8 vCPU / 32 Go RAM / 400 Go NVMe, ~26 à 74$/mois selon promo), plausible pour plusieurs dizaines de clients TPE en usage CRUD léger comme ASPIC. Modèle d'isolation recommandé : une base MySQL séparée par client sur une même instance (isolation de sécurité + export/suppression facile par client, pas de colonne "client_id" partagée), plutôt qu'un partitionnement sur plusieurs instances MySQL ("un MySQL tous les x clients") — cette dernière option à réserver pour plus tard, seulement si une vraie tension de charge est constatée (même principe "pas de sur-ingénierie" déjà appliqué dans ASPIC). **Précision de Jean-Marc (28 août) : il imagine plutôt ce partitionnement futur par lots (ex. 10 bases par instance, puis une nouvelle instance pour les 10 suivantes) que par isolement nommé d'un client précis — les deux motifs sont couverts par le même mécanisme d'annuaire, voir section 8.**
+
+## 6. Séquencement retenu
+
+Priorité assumée aux prestations "one-shot" immédiatement rémunératrices dès le lancement de l'agence — ASPIC continue de mûrir en parallèle, sans précipitation ni pression de délai pour en faire un produit vendable. Les missions one-shot ne sont pas vues comme une perte de temps face au produit : elles sont l'occasion de repérer, sur des cas réels et payés, quels besoins reviennent assez souvent pour mériter d'être un jour généralisés — même logique que la règle déjà en place dans le code d'ASPIC ("généraliser à partir de 3 répétitions concrètes constatées"), appliquée ici au niveau du choix business plutôt que du code. Bascule progressive vers le produit envisageable si le marché confirme un potentiel réel ; sinon, Jean-Marc reste focalisé sur les prestations one-shot (pas de "lâcher la proie pour l'ombre").
+
+## 7. Nom de domaine aspic.bzh — environnement de test
+
+**Acheté par Jean-Marc le 28 août 2026 au soir**, chez OVH (seul registrar habilité pour le `.bzh`). Éligibilité déjà acquise dans les faits (Jean-Marc en contact avec l'association gestionnaire du `.bzh`, basée à Quimper, qui lui a déjà accordé la possibilité de créer des noms à deux lettres).
+
+Hébergement technique déjà cadré : DNS pointé chez OVH vers l'IP du VPS (même principe déjà en place pour `ms.bzh`), routage via Nginx Proxy Manager déjà en place sur le VPS.
+
+**Décision de Jean-Marc : ne pas se précipiter sur la mise en œuvre technique, à reprendre "dans quelques jours, sans stress".** Voir section 8 pour l'architecture d'accès multi-environnements envisagée (routage par annuaire), qui reste une réflexion conceptuelle non implémentée à ce stade.
+
+**Mise à jour du 1er septembre 2026 — migration vers un sous-domaine :** l'environnement de bêta test de l'application, jusque-là sur la racine `aspic.bzh`, est déplacé vers `crm.aspic.bzh`. Objectif explicite : garder la racine `aspic.bzh` libre pour y installer, dans quelques mois, un petit site de promotion de la solution — si la situation évolue favorablement dans ce sens (rien n'est encore engagé sur ce site vitrine à ce stade, c'est une réservation d'usage plutôt qu'un chantier commencé). Conséquence terminologique pour la suite de ce document : dans la section 8 ci-dessous, rédigée avant cette migration, les mentions d'« `aspic.bzh` » comme environnement applicatif de test désignent techniquement `crm.aspic.bzh` depuis le 1er septembre — laissées telles quelles pour ne pas réécrire une réflexion déjà actée, mais à lire avec cette correspondance en tête.
+
+## 8. Architecture d'accès pour aspic.bzh — routage par identifiant, annuaire, cohabitation avec aspic.mvl-tls.fr (28 août 2026)
+
+*Voir la mise à jour du 1er septembre 2026 en fin de section 7 : les mentions d'« aspic.bzh » ci-dessous, comme environnement applicatif de test, désignent depuis cette date `crm.aspic.bzh` — la racine `aspic.bzh` étant réservée au futur site de promotion.*
+
+Réflexion engagée par Jean-Marc, explicitement conceptuelle à ce stade ("sans passer à l'action maintenant") — aucune implémentation en cours.
+
+**Choix de principe validé par les deux :** un seul point d'entrée (`aspic.bzh`), pas de sous-domaine par client. Jean-Marc ne souhaite donner aucune indication de l'existence d'un client via l'URL (pas de `toto.aspic.bzh` visible par un curieux). Le routage vers la bonne base de données se ferait donc par l'identifiant saisi à la connexion, pas par l'adresse.
+
+**Mécanisme envisagé :** un petit annuaire central (une table séparée des bases clients, ne contenant aucune donnée métier — uniquement une correspondance identifiant → informations de connexion à la bonne base). L'identifiant de connexion évoluerait vers un format structuré (ex. `code_client-code_user`, dans l'esprit du USR_Code actuel à 3 caractères mais globalement unique) plutôt qu'un email, pour rester cohérent avec la lisibilité déjà recherchée dans les journaux (REA_CodeUser/OPE_CodeUser). Flux de connexion : l'app consulte d'abord l'annuaire avec l'identifiant saisi pour déterminer la base cible, puis vérifie le mot de passe dans cette base précise.
+
+**Anticipation d'une évolution vers plusieurs instances MySQL (pas seulement plusieurs bases sur une même instance) :** l'annuaire, dès sa conception, porterait pour chaque client une adresse de connexion complète (serveur + port + base), pas seulement un nom de base — même si, par défaut, tous les clients pointent vers le même serveur au départ. Ça permet de déplacer un client (ou un lot de clients) vers une instance MySQL séparée plus tard sans réécrire l'application, seulement en modifiant une ligne de l'annuaire. Jean-Marc envisage ce besoin futur plutôt sous forme de paliers de charge (ex. 10 bases par instance, puis une nouvelle instance pour les 10 suivantes) que sous forme d'isolement nommé d'un client précis — les deux cas de figure sont couverts par le même mécanisme, sans qu'il faille choisir maintenant lequel se produira.
+
+**Relation entre les environnements, clarifiée :**
+- `aspic.mvl-tls.fr` reste le bac à sable de développement (données de test, fonctionnalités en cours de maturation), complètement séparé (déploiement, base) de `aspic.bzh`.
+- `aspic.bzh` porte **une seule version** de l'application (celle jugée aboutie), jamais deux versions en parallèle. Sur cette version unique cohabiteraient plusieurs bases : celle de Jean-Marc pour son usage réel, une base de démonstration pour les prospects (à peupler de données fictives, avec réinitialisation périodique envisagée pour ne jamais laisser de trace d'une démo à l'autre), et plus tard celles de vrais clients si le modèle (b) de la section 5 se concrétise. Le passage d'une fonctionnalité du bac à sable vers la version unique de production se fait par promotion, une fois la fonctionnalité validée — pas de duplication de code à maintenir.
+- Confirmé explicitement par Jean-Marc : ce n'est donc pas "deux versions différentes" de l'application selon l'usage (personnel vs démo), mais une seule version servant plusieurs bases isolées.
+
+## 9. Hostinger Agents + Google Sheets — piste explorée comme alternative à GoHighLevel (28 août 2026)
+
+En marge de sa recherche d'un serveur Hostinger plus puissant, Jean-Marc a découvert "Hostinger Agents" — une offre d'agents IA spécialisés par fonction (SEO, Marketing, Réseaux sociaux, Contenu, **Sales Agent** — prospection et relance), ~7 à 10$/mois selon l'engagement (1000 crédits/mois, 150+ compétences), connectables à un catalogue d'applications tierces préconfigurées (Gmail, Outlook, HubSpot, Notion, Jira, GitHub, Google Drive, etc.).
+
+**Idée de Jean-Marc, jugée pertinente par Claude :** séparer la couche IA/automatisation (louée, bon marché, jetable) de la couche données (ASPIC, chez lui, jamais confiée à un tiers) — contrairement à GHL, où l'outil devient lui-même le coffre-fort des données.
+
+**Points vérifiés par Claude à date :**
+- Connexion à une API personnalisée/webhook générique : **non confirmée** dans la documentation publique de Hostinger Agents (liste de connecteurs fermée, ~20 applications nommées). Hostinger propose par ailleurs du n8n en self-hosted comme produit d'hébergement séparé, et un connecteur n8n pour piloter *leur propre API d'hébergement* — mais rien ne confirme que l'agent commercial puisse être relié à n8n comme intermédiaire. **À vérifier directement dans les paramètres de l'agent une fois un compte ouvert — pas encore fait par Jean-Marc au 28 août au soir.**
+- **Jean-Marc gère déjà n8n en auto-hébergé sur son VPS** (dans le cadre du projet de gestion du serveur, aux côtés de PostgreSQL/MySQL/LangFlow), indépendamment de l'offre Hostinger — la question de la compétence à acquérir sur n8n est donc caduque, il l'opère déjà.
+- Politique de confidentialité de Hostinger Agents (page officielle vérifiée) : conversations stockées et liées au compte Hostinger, **explicitement non utilisées pour entraîner/affiner leurs modèles d'IA**, jamais partagées à des tiers à des fins publicitaires. Fournisseur du modèle IA sous-jacent (OpenAI, Anthropic, autre) **non précisé** dans la documentation publique — point resté ouvert.
+- Nuance importante actée : cette politique ne couvre que la conversation avec l'agent Hostinger lui-même. Une donnée écrite ensuite dans un Google Sheet connecté tombe sous la politique de confidentialité de Google, distincte — deux périmètres de confiance empilés, pas un seul.
+
+**Piste retenue par Jean-Marc pour une première mise en pratique, explicitement double temporaire :**
+1. Utiliser Google Sheets (confirmé dans le catalogue de connecteurs standards) comme tampon de contrôle visuel — l'agent y écrirait ses résultats, et y lirait potentiellement les données à traiter en entrée (les agents ne semblant pas porter de base de données propre — un agent "sans mémoire" doit être alimenté à chaque tâche). Cette étape validerait au passage que le format de données échangé est compatible avec une future intégration dans ASPIC ; les fichiers Google Sheets ainsi produits seraient temporaires par nature.
+2. Une fois les fonctionnalités utiles réellement intégrées nativement dans ASPIC, abandon prévu des agents Hostinger loués — solution de transition assumée comme telle, pas une brique d'architecture définitive.
+
+**Nuance apportée par Claude sur la réduction du risque via ce montage :** la nécessité de nourrir l'agent en données d'entrée n'est pas propre à cette approche (tout outil, y compris GHL, a besoin d'être alimenté). Le vrai avantage structurel par rapport à GHL n'est donc pas "moins besoin de données", mais l'absence de copie persistante et complète des données sensibles chez le prestataire — bénéfice réel uniquement si l'alimentation de l'agent est conçue pour ne fournir, à chaque tâche, que la tranche de donnée strictement nécessaire (pas un accès large et permanent à l'ensemble d'une feuille ou d'une base) : un choix de conception à faire consciemment, pas une garantie automatique.
+
+**Point technique accessoire vérifié, à valeur générale pour tout usage de tableur (Excel ou Google Sheets) en amont d'ASPIC :** le format d'affichage spécial "Code postal" d'Excel est purement cosmétique — la valeur réellement stockée reste numérique, sans le zéro de tête, et c'est cette valeur qui part dans un export CSV ou une lecture programmatique. Seul un formatage explicite en texte protège réellement la donnée. Google Sheets ne propose même pas ce format spécial d'affichage. Même vigilance que celle déjà actée dans le journal de développement pour CNT_AdrCP.
+
+**Statut au 28 août 2026 (soir) : Jean-Marc n'a pas encore avancé sur la vérification des fonctionnalités/connecteurs Hostinger Agents.** Reste à faire : existence d'un connecteur générique/API personnalisée, identité du fournisseur de modèle IA sous-jacent.
+
+## 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.*
+
+**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.
+
+**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.
+
+**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.
+
+**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.

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

@@ -0,0 +1,50 @@
+## 27. Pilotage vocal (Lilou) — phase 1 [BROUILLON, fonctionnalité non encore validée de bout en bout] (1er-2 septembre 2026)
+
+**⚠️ Statut de ce fichier.** Section créée par anticipation le 2 septembre 2026 à la demande explicite de Jean-Marc, alors que le principe initial (voir sommaire du journal) était de ne créer ce fichier qu'une fois le pilotage vocal validé de bout en bout — ce qui n'est pas encore le cas. Contenu à considérer comme un brouillon de travail, à mettre à jour à la fin de chaque session tant que la fonctionnalité n'est pas stabilisée, plutôt que comme un compte-rendu définitif.
+
+**Contexte.** Suite de la ToDoList (section 26) : nouveau bouton micro dans le bandeau, positionné après l'avatar pour une place fixe à l'écran. Comportement centralisé dans un fichier partagé `micro.js`, chargé sur chaque écran hôte — reconnaissance vocale réelle via l'API Web Speech du navigateur, écoute continue avec redémarrage automatique tant que l'utilisateur n'a pas explicitement refermé le micro. Mot déclencheur **« Lilou »** (assistante vocale d'ASPIC, dans la même veine que « Viktor » côté contacts) pour ignorer la conversation de fond — tolérant aussi **« Milou »**, confusion fréquente du moteur de reconnaissance sur ce prénom.
+
+**Mode notation (livré le 1er septembre au soir).** Capture une dictée libre entre une phrase d'ouverture (« Lilou, ajoute une tâche » / « un truc à faire » / « note ça dans ma todolist ») et une phrase de clôture (« c'est tout Lilou ») ou d'annulation (« Lilou annule ») — les deux traitées à l'identique, sans interprétation à ce stade, sur demande explicite de Jean-Marc. Objectif : accumuler un vrai corpus d'essais réels avant de définir, dans un prochain chantier, des règles d'interprétation (étape 2, envisagée via n8n, avec des règles modifiables par l'utilisateur). Version applicative incrémentée une fois pour cette fonctionnalité, **V1.005**.
+
+**Première implémentation (abandonnée le 2 septembre, voir plus bas) : fichier texte.** Le texte capté tel quel était envoyé à un endpoint `lilou_notes.php`, qui l'ajoutait, horodaté et attribué à l'utilisateur, à un fichier texte global (`notes_lilou/dictees.txt`, pensé pour être protégé par un `.htaccess` du même principe que `/journal`).
+
+**Session de débogage en conditions réelles, nuit du 1er au 2 septembre.** Plusieurs corrections apportées à `micro.js` :
+- la clôture peut désormais porter à la fois la dernière ligne de contenu et la fin du lot dans une seule phrase, sans « ensuite » artificiel juste avant ;
+- tolérance à la confusion « Lilou »/« Milou » ;
+- fenêtre de quelques secondes pour recoller une phrase que le moteur de reconnaissance a coupée juste après la virgule suivant « Lilou ».
+
+Côté serveur, deux problèmes rencontrés : le fichier `lilou_notes.php` n'avait pas été déployé au premier essai ; puis, une fois déployé, droits d'écriture insuffisants sur `notes_lilou/` (dossier propriété de `1001:users`, `www-data` hors de ce groupe). **Contournement provisoire en fin de session :** `dictees.txt` écrit directement à la racine de l'application plutôt que dans `notes_lilou/`, donc temporairement hors de toute protection `.htaccess`. Test de bout en bout non confirmé réussi au moment d'arrêter la session.
+
+**Test du matin, 2 septembre — échec confirmé.** Jean-Marc a créé manuellement `dictees.txt` à la racine de l'application et refait un essai : aucune mise à jour du fichier. L'approche fichier ne fonctionne donc toujours pas en pratique, au-delà du problème de droits déjà identifié sur `notes_lilou/`.
+
+**Décision de pivot, 2 septembre — abandon de l'approche fichier texte.** Sur proposition de Jean-Marc, pour ne pas perdre plus de temps sur une idée qui n'était que provisoire : chaque ligne de dictée sera désormais stockée directement dans une table MySQL simple, `ASP_ConsignesVoix` (nom volontairement générique, pas centré sur « Lilou », l'assistante n'étant qu'une des interfaces possibles vers ce mécanisme).
+
+```sql
+CREATE TABLE `ASP_ConsignesVoix` (
+  `CVX_Incr` int NOT NULL,
+  `CVX_DateHeure` datetime NOT NULL,
+  `CVX_CodeUser` varchar(3) NOT NULL,
+  `CVX_Consigne` varchar(200) NOT NULL
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
+
+ALTER TABLE `ASP_ConsignesVoix`
+  ADD PRIMARY KEY (`CVX_Incr`);
+
+ALTER TABLE `ASP_ConsignesVoix`
+  MODIFY `CVX_Incr` int NOT NULL AUTO_INCREMENT;
+COMMIT;
+```
+
+`CVX_DateHeure` et `CVX_CodeUser` ajoutés par rapport à la proposition initiale de Jean-Marc (qui ne portait que `CVX_Incr`/`CVX_Consigne`), sur suggestion de Claude, pour préserver l'horodatage et l'attribution utilisateur que l'ancien fichier texte portait déjà — évite un `ALTER TABLE` ultérieur sur des données déjà présentes. `CVX_CodeUser` en `varchar(3)`, même convention que `USR_Code`/`TDL_ToDoUser`.
+
+**Accès au code — point bloquant identifié le 2 septembre.** `micro.js` et `lilou_notes.php` n'ont jamais été poussés sur GitHub (dépôt non fait la veille au soir, Jean-Marc étant trop fatigué) — ils n'existent que sur le VPS. Jean-Marc s'en occupe (dépôt en cours au moment de la rédaction de ce brouillon). Une fois le dépôt fait, Claude pourra lire le contenu actuel de ces deux fichiers, notamment le format JSON exact envoyé par `micro.js` vers `lilou_notes.php`, avant de réécrire cet endpoint pour insérer dans `ASP_ConsignesVoix` au lieu d'écrire dans `dictees.txt`.
+
+**Pattern d'implémentation identifié pour la suite** (lecture de `db.php` et `todolist.php`, tous deux déjà dans le dépôt) : connexion via `getDbConnection()` (PDO, routage MIRADOR géré automatiquement par session), vérification de session (`$_SESSION['USR_Code']`, 401 sinon), JSON en entrée (`php://input`) et en sortie, requêtes préparées. `lilou_notes.php` réécrit suivra ce même pattern.
+
+**Reste à faire.**
+- Push GitHub de `micro.js` et `lilou_notes.php` (Jean-Marc, en cours).
+- Réécriture de `lilou_notes.php` pour insérer dans `ASP_ConsignesVoix` (Claude, une fois le point précédent fait) — un `INSERT` par ligne de dictée, `au fur et à mesure` comme demandé par Jean-Marc.
+- Vérifier que le format envoyé par `micro.js` reste compatible avec le nouvel endpoint, ou adapter `micro.js` si besoin.
+- Test de bout en bout à refaire et confirmer.
+- 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 resté en suspens depuis le 31 août, sans lien direct avec Lilou mais noté ici pour mémoire tant que ce brouillon n'est pas remplacé par la version finale.
+- Une fois la fonctionnalité validée de bout en bout : remplacer ce brouillon par une version définitive de la section 27, avec une numérotation de version applicative si de nouveaux changements de code l'accompagnent.