ASPIC/journal/ASPIC - Journal. Index.md

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 (28 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.

Cas particulier des fichiers de code livrés en session (2 septembre 2026) : un fichier .js n'est pas téléchargeable tel quel depuis le client utilisé par Jean-Marc. Pour tout fichier JavaScript livré (micro.js et les suivants), fournir systématiquement, en plus du fichier .js normal, une copie strictement identique au format .txt (même nom, extension changée — ex. micro.js.txt), pour qu'elle soit récupérable.

Précision du 2 septembre 2026 (fin de session) sur les exports SQL transmis par Jean-Marc : un CREATE TABLE/INSERT envoyé par Jean-Marc est le compte-rendu d'une modification déjà faite à la main côté base (il travaille en éditant directement, puis exporte pour informer Claude) — jamais une commande à exécuter côté Claude. Claude peut donc lire ces exports comme l'état réel de la base au moment de l'envoi, sans jamais chercher à les "lancer".

Précision du 2 septembre 2026 (soir) sur la continuité entre fenêtres de conversation : chaque nouvelle fenêtre de conversation démarre un environnement cloud entièrement neuf, sans mémoire du fil précédent ni accès aux fichiers de travail locaux de la session précédente (ex. le clonage temporaire du dépôt GitHub fait dans /tmp pour éditer du code) — seuls les documents de ce projet (ce journal, les Réflexions stratégiques, la Documentation utilisateur) traversent d'une fenêtre à l'autre. C'est pour cette raison que la consigne ci-dessus (mise à jour en fin de session, pas au fil de l'eau) compte particulièrement : c'est le seul filet de continuité entre deux sessions. Point déjà noté dans les Réflexions stratégiques, section 2. Un résumé automatique de conversation trop longue (fait par Claude Code en cours de fil, différent d'un changement de fenêtre) est en revanche censé préserver les faits essentiels de la session en cours — dans les faits, une erreur de mesure de pixels a bien eu lieu le 2 septembre après un tel résumé, mais elle provenait d'une méthode de mesure imprécise, pas d'une perte d'information liée au résumé lui-même (voir section 28, le centrage de l'étiquette "Contacts").

Sommaire des sections (/journal sur GitHub)

• 0. Présentation
• 1. Contexte et décision d'architecture
• 2. Modèle de données
• 3. Architecture technique
• 4. Fichiers de l'application
• 5. Points de friction
• 6. Pistes pour la suite
• 7. Statut actuel
• 8. Écran d'identification
• 9. É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
• 28. Écran de fond

(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.)

Statut actuel (2-3 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. Nouveaux endpoints todolist.php et utilisateurs.php, nouvel écran liste_todolist.html. Livré, testé (Playwright) et déployé — version V1.004.

1er septembre 2026 : migration du sous-domaine de bêta test. L'environnement de test bascule de aspic.bzh vers crm.aspic.bzh, pour libérer la racine du domaine en vue d'un futur site de promotion de la solution (voir réflexions stratégiques, section 7). Aucun changement fonctionnel côté application.

1er-2 septembre 2026 : pilotage vocal — de "Lilou" à un système multi-agents (V1.005 puis V1.006). Détail complet en section 27 du journal (/journal sur GitHub), fichier définitif déposé le 2 septembre après validation de bout en bout. Résumé : nouveau bouton micro dans le bandeau, comportement centralisé dans micro.js, reconnaissance vocale réelle (API Web Speech, écoute continue). Un "mode notation" capture une dictée libre entre une phrase d'ouverture et une phrase de clôture/annulation, sans interprétation à ce stade (corpus brut, interprétation prévue plus tard via n8n). Stockage pivoté d'un fichier texte défaillant vers une table ASP_ConsignesVoix, avec un type par ligne (CVX_Type : ouverture/contenu/cloture/annulation) pour qu'un futur automatisme sache exploiter un lot sans ré-analyser le texte brut.

Le système, initialement à agent unique ("Lilou"), a été généralisé le 2 septembre à plusieurs assistants IA nommés (table ASP_Agents, endpoint agents.php, lilou_notes.php renommé agent_notes.php) — chaque agent portant ses propres graphies alternatives tolérées (AGN_Variantes, pilotable en base sans code) et un agent par défaut (AGN_Defaut) pour ne plus jamais figer un nom précis dans le code. Un incident de confidentialité (bribes d'un appel téléphonique captées par un traçage de débogage resté actif) a conduit au retrait immédiat de ce traçage et à l'ajout d'une coupure automatique du micro après quelques minutes d'inactivité. Après plusieurs essais réels montrant des confusions de reconnaissance récurrentes, Jean-Marc a retiré deux agents (Lilou, Karl) plutôt que d'empiler des tolérances risquant de créer de faux déclenchements ou de mal vieillir face à la diversité des accents/prononciations — liste active : Viktor, Matilda (par défaut), Léon, Nikita. Version incrémentée une fois pour cette session, V1.006.

2 septembre 2026 (suite) : écran de fond — d'une maquette graphique à un premier essai fonctionnel (V1.007). Dans le prolongement de la réflexion "bureau à l'ancienne" (Réflexions stratégiques, section 11), Jean-Marc a d'abord engagé une maquette graphique (tableau en liège, post-it par agent IA, outil Claude Design) — non tranchée, jamais codée. En reprise de session le même jour, changement de cap : plutôt qu'une maquette stylisée, un premier essai fonctionnel réel ("c'est juste un test"), bâti sur une photo de scène de bureau fournie et recadrée par Jean-Marc lui-même (ecran_fond.jpg, 1024×457), affichée en plein écran juste après l'identification (background-size:contain). Un système de coordonnées calé sur l'image de référence (converties en position réelle par une fonction positionner()) permet de superposer des éléments interactifs précisément sur les objets photographiés. Livré dans ce premier essai : classeur "Contacts" cliquable, étiquette tournée, chevalet avec le prénom réel de l'utilisateur (USR_Prenom), micro cliquable en test d'affichage seul, numéro de version affiché. Version V1.007.

2-3 septembre 2026 (nuit) : pastille du classeur, conception et premier affichage réel du tableau de post-its (V1.008). Session enchaînée sur la même soirée, au départ pour une petite correction avant d'ouvrir le vrai chantier du tableau de liège.

Pastille de comptage sur le classeur Contacts. À la demande de Jean-Marc, une pastille ronde affiche désormais, sous le trou cerclé de métal du classeur "Contacts", le nombre réel de contacts actifs de la table (nouveau paramètre contacts.php?compte=1, comptage seul sans charger la liste complète). Couleur de fond calculée par assombrissement (×0,55) de la teinte réelle du classeur mesurée sur la photo, chiffre blanc gras, liseré blanc. Réduite en taille et le liseré adouci après premier retour de Jean-Marc sur son écran ("trop présente") — diamètre 22→17px (référentiel image), liseré 2px/85%→1,5px/40% d'opacité.

Conception du tableau de liège (vision actée, partiellement codée). Reprise du principe "bureau à l'ancienne" : le mur de la photo est confirmé être du vrai liège (texture visible au zoom, pas une couleur unie) — ça a orienté le choix graphique des post-its vers une punaise ronde en haut, cohérente avec la matière réelle. Principe de répartition de l'écran retenu : 70% de la largeur pour les assistants IA (Viktor, Matilda, Léon, Nikita), 30% fixe pour Jean-Marc lui-même — logique assumée : les assistants traitent vite (peu de post-its en attente à tout instant), l'humain accumule davantage avant de traiter, donc plus de place. Règles actées pour la part "assistants" (non codées ce soir, la ToDoList des assistants n'existant pas encore réellement) : part de chacun = (ses tâches en attente ÷ total tâches en attente tous assistants) × 70% ; l'assistant par défaut (Matilda) toujours le plus à gauche s'il a des tâches, puis les autres classés par charge décroissante ; un assistant sans tâche en attente disparaît entièrement du tableau (pas de colonne vide) ; couleur de post-it personnalisée par assistant (AGN_Couleur, à faire). Jean-Marc a fait remarquer, et Claude a vérifié dans le code, que la gestion de tâches par assistant n'est pas une nouvelle architecture à inventer : TDL_ToDoUser/TDL_RealUser dans ASP_ToDoList sont déjà des champs génériques non restreints à un humain (le commentaire d'en-tête de todolist.php anticipait déjà qu'un agent IA puisse assigner une tâche à un autre utilisateur) — il suffira d'ajouter un discriminant humain/agent le jour venu. Les écrans de gestion actuels (liste_todolist.html, todolist.php) sont conservés tels quels et pas encore reliés à la navigation depuis l'écran de fond (clic sur un post-it actuellement sans effet).

Nouveau besoin identifié en cours de réflexion, non traité ce soir : un écran "journalier" traçant ce qui a été réalisé par chacun (humain + assistants) — repéré comme déjà largement couvert par les champs existants TDL_RealDate/TDL_RealUser/TDL_RealText de ASP_ToDoList (une tâche marquée faite porte déjà qui, quand, avec quel commentaire), donc pas besoin a priori d'une nouvelle table pour un premier jet, seulement d'un écran de consultation à construire un jour.

Capacité du tableau — refus explicite d'un ascenseur. Jean-Marc a explicitement écarté toute idée de défilement/ascenseur sur le tableau ("ça casserait la logique du vrai bureau, et surtout m'inciterait à cumuler les post-its") au profit d'une capacité finie avec message de blocage. Ajout dans todolist.php : constante CAPACITE_TABLEAU_PAR_UTILISATEUR = 20 (valeur provisoire, posée avant d'avoir les vrais pixels, à faire évoluer) et vérification à la création (POST) — au-delà de la capacité, refus (HTTP 409) avec le message exact demandé par Jean-Marc : "Ton tableau est plein, tu ne peux plus ajouter de post-it !". Une tâche créée déjà réalisée n'est jamais bloquée (elle n'occupe pas de post-it). Posée dans todolist.php plutôt que côté écran, donc valable aussi le jour où la voix créera des tâches directement.

Premier affichage réel des post-its personnels. Dans ecran_fond.html : zone occupant 30% de la largeur depuis le bord droit de l'écran, du haut de l'image jusqu'à juste au-dessus du chevalet, avec une grille de 4 colonnes × 5 lignes = 20 cases — volontairement alignée sur CAPACITE_TABLEAU_PAR_UTILISATEUR. Données réelles de todolist.php, filtrées côté client sur l'utilisateur connecté (TDL_ToDoUser) et sur les tâches non réalisées (une tâche marquée faite libère sa place immédiatement). Chaque post-it reste dans sa propre case (léger jitter de rotation/décalage calculé de façon déterministe à partir de TDL_Incr, donc stable d'un rechargement à l'autre) — Jean-Marc a autorisé un chevauchement partiel entre post-its mais a explicitement refusé tout empilement en tas (illisible, imprécis au clic) ; rester dans sa case garantit qu'on ne recrée jamais ce cas. Punaise ronde, pastille d'urgence rouge/orange bien visible en coin haut-droit (jamais verte : le vert quitte le tableau dès qu'une tâche est réalisée), infobulle au survol avec le texte de la tâche, pas de texte visible sur le post-it lui-même, clic sans effet pour l'instant. Testé avec des données simulées (9 puis 23 tâches, plusieurs groupes d'urgence, tâches d'un autre utilisateur et déjà réalisées pour vérifier le filtrage) — rendu confirmé conforme par Jean-Marc sur image de synthèse avant dépôt.

Point relevé par Jean-Marc en toute fin de session, à traiter plus tard : les règles actuelles de calcul des pastilles rouge/orange/vert (calculerGroupe() dans todolist.php) risquent de donner un tableau surchargé de rouge/orange puisque le vert disparaît désormais immédiatement du tableau — à revoir, non traité ce soir.

Version incrémentée une seule fois pour l'ensemble de cette session (pastille classeur + capacité tableau + affichage post-its), conformément à la règle d'une incrémentation par session : V1.008.

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 — point en suspens depuis le 31 août).
• Pilotage vocal, étape 2 : définir les règles d'interprétation du contenu dicté (aujourd'hui stocké tel quel), envisagée via n8n avec des règles modifiables par l'utilisateur.
• Continuer à observer les agents actifs (Viktor, Matilda, Léon, Nikita) en usage réel ; ajuster AGN_Variantes en base si de nouvelles confusions apparaissent.
• Documentation utilisateur du pilotage vocal : pas encore rédigée, fonctionnalité encore en phase d'essais techniques.
• Écran de fond : revoir un jour le sujet de la "tranche du bureau" non visible chez Jean-Marc ; décider si les autres objets photographiés (carnet, téléphone) doivent devenir cliquables ; brancher le micro du bureau sur la reconnaissance vocale réelle ; trancher un jour le sort de la piste "maquette liège + post-its par agent" (Claude Design, mise de côté pour cet essai, pas explicitement abandonnée).
• Tableau de liège : coder la répartition dynamique des 70% entre assistants par charge de tâches (formule actée, voir Statut actuel) — bloqué tant que la ToDoList des assistants n'existe pas réellement.
• Étendre ASP_ToDoList/todolist.php pour qu'un assistant puisse être attributaire d'une tâche (discriminant humain/agent à définir) — préalable à la répartition dynamique et aux couleurs de post-it par assistant (AGN_Couleur, à ajouter).
• Écran "journalier" (trace des réalisations, humain + assistants) — donnée déjà quasi disponible (TDL_RealDate/TDL_RealUser/TDL_RealText), écran de consultation à construire.
• Revoir les règles de calcul des pastilles rouge/orange/vert (calculerGroupe()) pour éviter un tableau trop chargé en rouge/orange maintenant que le vert quitte le tableau immédiatement.
• Décider du comportement du clic sur un post-it (aujourd'hui inerte) : ouvrir liste_todolist.html sur la tâche précise, ou afficher un détail directement sur l'écran de fond.
• Capacité du tableau (20) et taille de la grille (4×5) dans ecran_fond.html/todolist.php sont des valeurs provisoires posées avant d'avoir les vrais pixels de la version finale — à ajuster ensemble après usage réel prolongé.