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.

Mise à jour du 11 septembre 2026 (soir) — obsolète depuis le passage à Claude Code sur le serveur. Le mécanisme ci-dessus (lecture via token GitHub, copie téléchargeable à redéposer) supposait l'ancien environnement cloud éphémère sans accès direct aux fichiers (voir consigne plus bas sur la fin de cet environnement). Désormais, Claude lit et modifie directement les fichiers de /docker/aspic/src/journal sur le serveur — la règle de fond (mise à jour de contenu en fin de session seulement, jamais au fil de l'eau) reste entière, mais l'étape de copie téléchargeable/dépôt manuel du contenu ne l'est plus : les fichiers sont déjà à jour sur le disque, prêts pour le git add/commit/push que Jean-Marc effectue lui-même.

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

Consigne du 6 septembre 2026 — numérotation de version à trois niveaux (version.php) et son partage de responsabilité. Après une session de réflexion stratégique ayant fait évoluer la conception même d'ASPIC sans toucher une ligne de code (voir Réflexions stratégiques, section 14), Jean-Marc a fait évoluer le format du numéro de version pour que ce type d'avancée soit tracé au même titre qu'une évolution de code, sans jamais mélanger les deux :

• Format : V<majeur>.<code>.<conception> (ex. V1.12.14), sans zéro de tête sur aucun des trois nombres — pas de largeur fixe supposée à l'avance.
• <code> : inchangé par rapport à la règle déjà en place depuis le début (incrémenté à la main une seule fois par session avec du code réellement livré et poussé, jamais à chaque fichier reçu).
• <conception> : compteur libre, incrémenté de 1 chaque fois que Jean-Marc juge qu'une évolution de la conception est majeure, y compris sur un sujet déjà effleuré auparavant (auquel cas la nouvelle section des Réflexions stratégiques peut reprendre l'ancien titre suivi de "[Évolutions majeures]") — une évolution mineure ou un abandon reste un addendum dans la section existante, sans faire avancer ce compteur. Correction du 11 septembre 2026 : ce paragraphe affirmait jusqu'ici, à tort, que <conception> "reprend le numéro de la dernière section créée" dans les Réflexions stratégiques — Jean-Marc a confirmé que ça n'a jamais été une règle réelle, seulement une coïncidence fréquente ces derniers temps (les sections récentes s'étant enchaînées sans saut). Les deux numérotations (le compteur de version, et le numéro qu'une section prend dans les Réflexions stratégiques, qui peut lui sauter — ex. de 10 à 28) restent indépendantes.
• <majeur> : change uniquement quand Jean-Marc juge qu'ASPIC franchit un cap de maturité important — décision, pas calcul. À cette occasion, <code> repart à 1 (V1.58 → V2.1, jamais V2.59) tandis que <conception> continue sa suite normale sans saut ni retour à 1 (V1.58.67 → V2.1.68), puisque franchir ce cap est lui-même consigné comme une nouvelle section des Réflexions stratégiques.

Consigne du 11 septembre 2026 — hygiène des sessions Claude Code, indépendante d'ASPIC. En discutant d'une consommation inattendue sur la clé API (voir journal, section 32), Jean-Marc a réalisé que cette conversation même (Claude Code) tourne sur le même forfait que l'application, et coûte pour la même raison structurelle qu'un appel Anthropic classique : l'API est sans état, donc chaque nouvelle réponse renvoie (et refacture) tout l'historique du fil depuis le début — plus un fil est long, plus chaque tour coûte cher, quel que soit le sujet traité. Décision de Jean-Marc : fermer une session Claude Code dès qu'un sujet aboutit (un chantier de code livré, une décision stratégique actée) plutôt que de laisser un même fil grossir indéfiniment sur plusieurs sujets — un aller-retour de recherche web a par exemple consommé plus de 400 000 tokens à lui seul le 11 septembre 2026.

Partage de responsabilité pour signaler un changement de version, en début ou en fin de session : si Jean-Marc sait dès le début d'une session que le code va évoluer, il peut demander à Claude de faire évoluer <code> immédiatement plutôt que d'attendre la fin de session. Pour <conception>, par défaut c'est à Claude de juger et de signaler en fin de session si l'évolution a été assez majeure pour justifier une nouvelle section — sauf si Jean-Marc sait déjà en début de session que ce sera le cas, auquel cas il le dit d'emblée (c'est par exemple déjà acté pour la session suivant celle du 6 septembre 2026).

Consigne du 11 septembre 2026 (soir) — fin de l'environnement cloud éphémère, mise à jour de la consigne du 2 septembre 2026 ci-dessus. Confirmé en direct au fil d'une session : Claude Code tourne désormais sur le serveur de Jean-Marc lui-même (accès fichier direct à /docker/aspic, aux conteneurs Docker via docker ps/docker exec), et non plus dans un environnement cloud entièrement neuf à chaque fenêtre. La continuité entre deux fenêtres de conversation n'est donc plus assurée par les seuls documents de ce projet (journal, Réflexions stratégiques, Documentation utilisateur) : les fichiers de travail eux-mêmes persistent d'une session à l'autre sur le serveur. Cette consigne ne change rien à la discipline de mise à jour de fin de session décrite ci-dessus (elle reste le seul filet pour la mémoire de Claude, l'historique d'une conversation n'étant lui-même jamais garanti de survivre) ; en revanche, transmettre un fichier à Claude ne nécessite plus de le coller dans le chat — le déposer n'importe où sur le serveur (Jean-Marc envisage un répertoire dédié) suffit.

Sur la pérennité des trois documents, précisé le 6 septembre 2026 : Jean-Marc prévoit qu'un jour ce journal de développement (résumé/index, et les sections détaillées de /journal) sera repris et expurgé de ce qui sera devenu inutile — en conservant les anciennes versions via l'historique Git, projet non commencé et pas à l'ordre du jour. Les Réflexions stratégiques, en revanche, ne seront jamais expurgées : la méthode d'écriture qu'on vient d'adopter (addendum sur une évolution mineure, nouvelle section sur une évolution majeure, jamais de réécriture de l'existant) fait de ce document une trace chronologique complète et volontairement définitive de l'évolution de la pensée stratégique — utile en particulier pour retrouver, en relecture, des pistes un moment abordées puis laissées de côté qui mériteraient d'être reprises.

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
• 29. Interprétation vocale des contacts par LLM
• 30. Chantier des consignes — moteur générique
• 31. Compétences, Missions et premier chantier agentique — Sophia et les sites web
• 32. BackOffice — Collaborateurs, Compétences, Espaces disque et coût IA
• 33. Vision des compétences, champ Relationnel et sortie des prompts IA du code

(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, puis (8 septembre 2026, matin) à un bureau à trois fonds interchangeables (liège actuel, futur écran assistants, futur tableau de bord) navigables par deux flèches, avant-plan désormais séparé du code des fonds, puis (9-10 septembre 2026) à un écran 2 ("assistants") réellement présenté (portraits, couleurs, rôles) et à une nouvelle répartition des 9 classeurs suivant le cycle de vie d'une affaire, puis (10 septembre 2026, soir) au renommage "collaborateurs" et à deux outils plein écran intégrés à cet écran 2 pour construire et tester l'identité de chaque collaborateur, avec un premier dialogue réel dans ASPIC via l'API Anthropic — fichier de section mis à jour ce jour-là, à déposer par Jean-Marc, voir Statut actuel. 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. Section 30 (Chantier des consignes — moteur générique) ouverte le 6 septembre 2026, fichier définitif rédigé le soir même après validation de bout en bout du mécanisme sur des cas réels ; substantiellement complétée le 7 septembre 2026 (hiérarchisation cohérence/Tests/IA, traçabilité de l'agent, REA_NomAffiche, premier appel IA réel dans une consigne avec avertissement bloquant) ; complétée à nouveau le 8 septembre 2026 (unicité mail/portable, retrait des points sur les numéros, échecs de consigne_completer_code_postal() rendus non-silencieux) — fichier de section mis à jour à déposer par Jean-Marc, voir Statut actuel.)

Statut actuel (2-11 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.

3 septembre 2026 : homogénéisation liste des contacts / écran de fond, adaptation à la nouvelle photo de bureau (V1.009). Détail complet en section 28 du journal (/journal sur GitHub). Résumé : nettoyage des bandeaux de liste_contacts.html (hamburger, avatar, badge société et micro retirés du haut, regroupés avec le logo et la version dans la barre du bas désormais commune aux deux écrans) ; icône Mévélia Solutions ajoutée devant le logo ASPIC (et en favicon) avec infobulle ; bug corrigé où Échap sur l'écran de fond ouvrait par erreur la ToDoList ; correctif .htaccess livré pour un problème récurrent de cache navigateur (déploiement non encore confirmé) ; nouvelle photo ecran_fond.jpg fournie par Jean-Marc (chevalet physiquement retiré de la scène, 13px de bureau en moins / de liège en plus), tous les positionnements calés sur l'image repris avec un décalage de +13px mesuré par analyse de pixels ; bloc identité (société/prénom/logo/version) reconstruit en position fixe de viewport, identique sur les deux écrans, après une première tentative erronée de le caler sur les coordonnées de la photo ; bug d'alignement horizontal entre les deux écrans corrigé (résidu de calcul --sb-width sans rapport avec cette barre). Version incrémentée une seule fois pour l'ensemble de cette session : V1.009. Documentation utilisateur mise à jour en fin de session pour refléter le nouvel écran d'accueil et la disparition du hamburger.

3 septembre 2026 (soirée) : micro du bureau branché sur la reconnaissance vocale réelle, puis détourné pour constituer une banque de dictées de test (V1.010). Détail complet en sections 27 et 28 du journal. Résumé : micro.js cherche désormais le bouton micro par #bouton-micro (bandeau) ou, à défaut, #micro-desk (écran de fond) — un seul comportement partagé, sans dupliquer la logique — et le micro du bureau déclenche bien la reconnaissance vocale réelle depuis ce soir. Discussion stratégique dans la foulée (Réflexions stratégiques, section 12) : Jean-Marc, après avoir montré l'application à sa compagne (confrontée à SAP dans son travail), s'inquiète de la fiabilité du pilotage vocal une fois étendu aux contacts, au catalogue, aux devis, à la facturation — distinction actée avec Claude entre le problème de reconnaissance du mot déclencheur (déjà traité, sa surface d'erreur ne grandit pas avec les modules) et celui de l'interprétation d'une dictée bien captée (à traiter via un LLM à sortie structurée contre un catalogue d'actions, le RAG/pgvector restant réservé à la recherche floue dans un corpus, pas au déclenchement d'action). Décision : constituer d'abord un vrai corpus de dictées avant d'écrire la moindre règle. Micro du bureau temporairement détourné vers un nouvel outil de mise au point (micro_test.js/dictees_test.php, table ASP_DicteesTest, thème "Gestion des Contacts") — écoute continue sans mot déclencheur, restitution au fur et à mesure dans une fenêtre dédiée, aucune suppression possible même pour un essai raté (décision explicite de Jean-Marc : la banque doit refléter la réalité). Premier essai réel concluant le soir même. Version incrémentée une seule fois pour l'ensemble de cette session (branchement réel + outil de test) : V1.010.

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.

6 septembre 2026 : chantier des consignes — un moteur générique pour sortir du code en dur (V1.14.15). Détail complet en section 30 du journal, fil conceptuel complet en Réflexions stratégiques, section 15. Résumé : reprise le soir même, sous forme concrète, de la distinction règles/consignes esquissée le matin — première mise en œuvre volontairement circonscrite à la fiche Contacts (création/modification). Deux tables créées par Jean-Marc (ASP_Fonctions : catalogue de fonctions génériques ; ASP_Consignes : instructions actives par contexte/champ), un moteur générique unique (moteur_consignes.php, fonction appliquerConsignes()) qui lit ces tables à l'exécution et applique traitements (mise en forme silencieuse) puis tests (validation, avec message d'erreur personnalisé), et une bibliothèque de fonctions du catalogue (consignes_fonctions.php : MAJUSCULE, NON_VIDE, PREMIERE_LETTRE_MAJUSCULE). contacts.php réduit à un seul appel au moteur, plus aucun contrôle de champ écrit en dur. Détour initial corrigé par Jean-Marc (Claude avait d'abord codé en dur un contrôle par champ au lieu du moteur générique demandé), puis abandon délibéré de la validation en temps réel côté écran au profit de la robustesse — révélant au passage un bug préexistant (message d'erreur générique affiché au lieu du message réel du serveur), corrigé. Ajustements d'interface demandés en cours de test : toast d'erreur centré et rouge sur le panneau de saisie, rendu correct des retours à la ligne saisis dans un message d'erreur. Preuve de concept validée par Jean-Marc en fin de session : ajout de nouvelles consignes (NON_VIDE sur Prénom et Ville) sans la moindre modification de fichier PHP/JS, comportement immédiatement actif avec les fichiers déjà livrés. Version incrémentée une seule fois pour l'ensemble de cette session, sur les deux compteurs anticipés dès le début (code et conception) : V1.14.15.

7 septembre 2026 : chantier des consignes — hiérarchisation, traçabilité et premier appel IA réel dans une consigne [Évolutions majeures] (V1.15.17). Détail complet en section 30 du journal, fil stratégique en Réflexions stratégiques, section 17. Résumé : reprise le lendemain matin par une session dédiée au lien entre Claude et l'ordinateur de Jean-Marc (voir Réflexions stratégiques, section 16 — chantier finalement clos, sans suite), puis, le soir, extension substantielle du chantier des consignes ouvert le 6 septembre. Un badge de chargement générique (consignes_apercu.php, convention de fonction jumelle _seraitDeclenchee) prévient désormais l'utilisateur qu'un appel IA va réellement se produire avant qu'il ne soit lancé. Bug de coût découvert par Jean-Marc et corrigé structurellement : une soumission vouée à échouer sur un Test déclenchait quand même, en pure perte, un Traitement IA coûteux — le moteur exécute désormais trois phases strictement séquentielles (Traitements de cohérence, puis Tests, puis seulement si tout est passé les Traitements IA), sur la base d'un seul attribut déjà présent au catalogue (FON_VisuelAttenteIA). Traçabilité renforcée : un nom d'agent resté codé en dur ("Mat") a été remplacé par une source unique de vérité (CNS_Agent, la consigne elle-même) ; nouvelle colonne REA_NomAffiche sur ASP_Realisations, un instantané écrit une seule fois à la création (session utilisateur côté humain, nom d'agent côté IA) plutôt qu'une jointure recalculée à la lecture — écartée pour sa complexité et son incompatibilité avec une future architecture multi-bases (MIRADOR). Renommage ASP_Agents.AGN_Nom → AGN_Prenom à l'origine d'une régression du pilotage vocal (cinq fichiers pré-existants non mis à jour, "aucun impact" affirmé à tort par Claude sans avoir vérifié) — corrigée le soir même, leçon actée pour la suite (grep systématique avant d'affirmer l'absence d'impact d'un changement de schéma). Nouveau Test générique consigne_sans_chiffre(), appliqué par Jean-Marc sur Nom/Prénom/Ville sans retoucher un seul fichier. Premier vrai appel IA dans une consigne : consigne_completer_code_postal() journalise désormais un échec (ville ambiguë, ex. Paris) au lieu de rester silencieuse, via une nouvelle clé réservée générique _avertissement affichée immédiatement à l'écran — trois itérations d'affinage de ce retour visuel dans la soirée, jusqu'à un message réellement bloquant (bouton "Valider" explicite, pas de disparition automatique) qui ne fait que finaliser l'affichage sans jamais redéclencher un enregistrement. Version incrémentée deux fois au fil de cette même journée de travail (code en tout début, conception en fin de session, section 17 des Réflexions stratégiques étant jugée majeure) : V1.15.17.

8 septembre 2026 : session de réflexion stratégique — concept de "Mission" et faisabilité d'un dialogue simulé avec Claude (V1.15.18). Aucune ligne de code applicative touchée ce jour — premier cas réel d'une session faisant avancer uniquement la partie <conception> du numéro de version depuis l'instauration du format à trois niveaux (voir consigne du 6 septembre 2026 ci-dessus). Détail complet en section 18 des Réflexions stratégiques : clarification du fonctionnement général d'un "agent" IA (prompt, contexte, outils, boucle) ; conception d'un nouveau concept — la Mission — pour structurer les objectifs confiés à un agent dans la durée (trois niveaux de mémoire, clôture décidée par Jean-Marc, tags en nuage envisagés pour retrouver des missions similaires, RAG gardé en réserve) ; et confirmation de la faisabilité technique d'un dialogue simulé avec Claude intégré à ASPIC via l'API Anthropic (même schéma d'intégration que l'appel IA déjà en place pour l'interprétation vocale, prompt système gardé secret côté serveur, bulles de dialogue façon SMS). Chantier à ouvrir prochainement, rien conçu ni codé à ce stade.

8 septembre 2026 (matin) : écran de fond — trois fonds interchangeables derrière un avant-plan désormais séparé du décor (V1.16.18). Détail complet en section 28 du journal. Résumé : Jean-Marc a constaté que l'écran de fond, limité à un seul décor (le tableau de liège), ne suffira pas à tout gérer, et a posé le principe de trois fonds navigables par deux flèches, derrière un même avant-plan (bureau, classeurs, micro, carnet, téléphone) qui ne change jamais — l'écran 1 restant l'actuel tableau de liège, l'écran 2 un futur écran "assistants" (fond en tasseaux de bois gris, présentation encore à concevoir), l'écran 3 un futur tableau de bord (fond tableau blanc). Décisions actées avant codage : code de l'avant-plan et code des fonds séparés ; les trois fonds codés en dur plutôt qu'en liste extensible ("il faut s'autoriser à coder ça en dur") ; animation de glissement au changement de fond, dont le sens dépend de la flèche pressée (l'écran n+1 entre par la droite en chassant l'écran actuel vers la gauche, et inversement) ; l'avant-plan reste visible sur les trois écrans, y compris le futur tableau de bord ; aucune mémorisation du fond choisi d'une session à l'autre (toujours l'écran 1 à l'ouverture) ; flèches posées sur le bureau à droite. Point corrigé en cours de route : les post-its, d'abord traités par erreur comme un élément fixe de l'avant-plan, doivent en réalité rester solidaires du panneau de liège et disparaître/réapparaître avec lui — résolu par une technique de réattachement du même nœud DOM de post-its à la bonne "diapositive" de fond, sans dupliquer sa logique de position. Le nouvel avant-plan fourni par Jean-Marc étant un dessin recomposé (pas la même photo que l'ancienne), l'ensemble des repères (classeurs, micro, pastille, zone de post-its) a dû être entièrement remesuré par analyse de pixels plutôt qu'ajusté par simple décalage — remesure reconduite une seconde fois après qu'une version corrigée de l'avant-plan (traces blanches et halo du micro retouchés) s'est révélée légèrement décalée par rapport à la première. Nombreux réglages fins en fin de session à partir des retours directs de Jean-Marc sur son propre écran (taille et position des flèches, position de l'icône du micro, position de la pastille de comptage des contacts). Version incrémentée une seule fois pour cette session : V1.16.18 (<code> avancé dès le début à la demande de Jean-Marc, <conception> inchangé — évolution jugée comme une continuation du chantier de l'écran de fond, pas une nouvelle section des Réflexions stratégiques).

8 septembre 2026 (après-midi) : petits chantiers de finition — position du micro, unicité mail/portable, retrait des points, robustesse du code postal auto, toast bloquant sans bouton (V1.17.18). Aucune réflexion stratégique nouvelle (<conception> inchangé, pas de nouvelle section des Réflexions stratégiques) ; <code> avancé dès le début de session à la demande de Jean-Marc. Résumé, dans l'ordre traité :

• Position de l'icône micro sur l'écran de fond. Le dernier réglage du 8 septembre au matin (ICONE_CENTRE_X = 522) allait trop loin vers la droite — repéré par Jean-Marc en testant. Ramené à 515 dans ecran_fond.html après essai réel. L'icône en état "écoute" reste masquée par un panneau superposé sur l'écran de test actuel de Jean-Marc — signalé, volontairement non traité (pas prioritaire).
• Unicité mail/portable (chantier des consignes, section 30). Deux nouveaux Tests dans ASP_Fonctions/consignes_fonctions.php : MAIL_UNIQUE et PORTABLE_UNIQUE, deux fonctions dédiées (consigne_mail_unique(), consigne_portable_unique()) plutôt qu'une seule fonction générique paramétrable par champ — décision explicite de Jean-Marc pour qu'un futur opérateur du catalogue ne puisse pas appliquer par erreur une contrainte d'unicité à un champ où elle n'a pas de sens (ex. Prénom, où deux homonymes sont normaux). Les deux s'appuient en interne sur un même utilitaire privé (valeurDejaUtilisee(), hors catalogue) pour ne pas dupliquer la requête SQL. A nécessité une première extension du contrat des Tests à un champ dans moteur_consignes.php : ces fonctions peuvent désormais recevoir deux paramètres de plus, $pdo et $idExclusion (identifiant de la fiche en cours de modification, pour qu'une consigne d'unicité ne se bloque jamais elle-même en retrouvant sa propre valeur déjà enregistrée — null en Création) — sans effet sur les Tests existants, qui ignorent simplement ces arguments en trop. contacts.php (PUT) transmet désormais cet identifiant au moteur.
• Retrait des points dans les numéros de téléphone. Nouveau Traitement générique RETIRER_POINTS (consigne_retirer_points()), sur le même principe que SANS_CHIFFRE (7 septembre) : une seule fonction réutilisable, appliquée par Jean-Marc à CNT_Portable et CNT_Tel via deux lignes dans ASP_Consignes, sans aucune fonction par champ.
• Bug corrigé : échecs silencieux de consigne_completer_code_postal(). Jean-Marc a repéré qu'une ville inconnue de l'IA n'aboutissait à aucune trace dans les réalisations, contrairement au cas "ville ambiguë" (type Paris) déjà traité le 7 septembre. Diagnostic : deux sorties anticipées de la fonction (clé API absente ; échec réseau/HTTP) renvoyaient les valeurs inchangées sans jamais poser ni _realisation ni _avertissement. Corrigé : l'échec réseau/HTTP pose désormais les deux (un appel a réellement été tenté, donc journalisé comme le cas "ville ambiguë") ; la clé API absente pose seulement l'avertissement écran (aucun appel réellement tenté, rien à journaliser comme coût engagé).
• Toast bloquant du code postal : bouton "Valider" retiré, Échap seul. Le bouton du toast bloquant (avertissement IA, 7 septembre) fonctionnait, mais Échap sur ce même toast fermait EN PLUS le panneau détail en dessous — le gestionnaire clavier global ne savait pas qu'un toast bloquant était ouvert. Corrigé dans liste_contacts.html : bouton retiré, le toast mémorise son rappel de fermeture (toastValidationEnCours) et le gestionnaire Échap global le vérifie désormais EN TOUT PREMIER, avant le menu contextuel du panneau détail — Échap referme alors le toast seul.
• Ménage à prévoir sur ASP_Consignes. Jean-Marc a repéré des champs qui lui semblent redondants dans la structure de cette table (CNS_TexteDefinition/CNS_TexteAffiche en particulier) — à examiner ensemble, rien fait ce jour.
• Confusion résolue en cours de session : un doute initial de Jean-Marc sur la persistance du correctif "Échap" (le bouton "Valider" restait visible après un premier essai) provenait du cache navigateur, pas d'un problème de déploiement — confirmé après rechargement forcé.

Version incrémentée une seule fois pour l'ensemble de cette session (uniquement <code>) : V1.17.18.

9-10 septembre 2026 : écran 2 ("assistants") — portraits des assistants, nouvelle texture de fond, et réorganisation des 9 classeurs (V1.18.19). Détail technique complet en section 28 du journal ; fil stratégique de la réorganisation des classeurs en Réflexions stratégiques, section 19. Résumé : nouvelle texture de fond pour l'écran 2 (tasseaux de bois, filigrane retiré) ; conception puis intégration réelle de la présentation des assistants sur cet écran — portraits recadrés en photo d'identité, couleurs pastel par assistant (AGN_Couleur), rôle affiché en gras sous le nom (AGN_Fonction), colonnes calculées dynamiquement depuis le nombre réel d'agents de ASP_Agents (jamais un nombre codé en dur), panneau "Bureau des assistants" dimensionné à son texte dans l'espace restant. Nouvelles colonnes AGN_Photo (nom de fichier de la photo, éditée à la main comme AGN_Variantes) et AGN_OrdreAffichage (tri de l'écran, indépendant de AGN_Incr) ajoutées par Jean-Marc à ASP_Agents. En parallèle, Jean-Marc a revu la classification des 9 classeurs du bureau pour suivre le cycle de vie réel d'une affaire (Catalogue, Documents, Contacts, Missions, Propositions, Livraisons, Factures, Journalier, Gestion) — mêmes 9 positions physiques, seuls les libellés changent ; un point de vigilance (la pastille de comptage des contacts, positionnée indépendamment du tableau des classeurs) a été identifié et corrigé avant livraison pour continuer à suivre "Contacts" à sa nouvelle position. <code> avancé dès le début de session à la demande de Jean-Marc (V1.17.18 → V1.18.18) ; <conception> avancé en fin de session (18 → 19), la réorganisation des classeurs étant jugée par Jean-Marc suffisamment structurante pour justifier une nouvelle section des Réflexions stratégiques. Version : V1.18.19.

10 septembre 2026 (soir) : "collaborateurs" — construire et tester l'identité de chaque assistant, premier dialogue réel avec l'API Anthropic (V1.19.21). Détail technique complet en section 28 du journal ; fil stratégique en Réflexions stratégiques, sections 20 (identité des collaborateurs) et 21 (stockage de documents PDF, discussion architecturale indépendante, non codée). Résumé : dernière étape terminologique "assistants" → "collaborateurs" (habillage seul, ASP_Agents/AGN_*/agents.php inchangés) ; deux outils plein écran ajoutés sous le panneau des collaborateurs — "Construire une identité" (terminal de saisie sur un nouveau champ AGN_Identite, endpoint collaborateurs_identite.php) et "Tester l'identité" (vraie fenêtre de dialogue, premier appel réel à l'API Anthropic dans ASPIC via le nouvel endpoint collaborateur_dialogue.php, modèle claude-sonnet-5, prompt système construit à partir de l'identité du collaborateur avec garde-fous explicites — jamais de récitation verbatim de l'identité, avis pouvant diverger de ceux de Jean-Marc). Un bug critique de cascade CSS ([hidden] toujours perdant face à une règle d'auteur display:flex, quelle que soit la spécificité) a été détecté par test automatisé avant toute livraison — l'overlay serait resté en permanence visible et aurait intercepté tous les clics du bureau dès le chargement de la page — et corrigé par deux règles [hidden]{display:none} explicites. Incident de production réel diagnostiqué et résolu le soir même : clé API Anthropic non scopée à un espace de travail (HTTP 400), résolu en recréant la clé correctement scopée. Après validation en conditions réelles par Jean-Marc, resserrement de mise en page demandé point par point (titre remonté, boutons descendus, zone de dialogue agrandie à deux lignes, boutons Envoyer/Fermer côte à côte). Discussion sur la capacité du champ AGN_Identite : colonne élargie de TEXT à MEDIUMTEXT en base par Jean-Marc, l'intention étant que l'identité d'un collaborateur s'enrichisse avec l'usage réel de l'application (missions, réunions) plutôt que de rester figée — indicateur d'occupation en octets réels (UTF-8) ajouté à l'écran de saisie, avec seuil d'avertissement et blocage à l'approche de la limite. <code> avancé en tout début de session (V1.18.19 → V1.19.20) ; <conception> avancé deux fois au cours de la même session (19 → 21) pour l'ouverture des sections 20 et 21 des Réflexions stratégiques — nouvelle version V1.19.21.

10-11 septembre 2026 : compétences, Missions et premier chantier agentique — Sophia dote de la capacité réelle de créer des sites web (V1.21.22). Détail technique complet en section 31 du journal ; fil stratégique en Réflexions stratégiques, section 22. Origine : Sophia, en session "Tester l'identité", s'est mise à réclamer des fichiers/infos pour "créer des sites web" sans avoir aucune capacité réelle — Jean-Marc a saisi l'occasion pour reprendre le concept de Mission resté en suspens depuis le 8 septembre (réflexions stratégiques, section 18) et le rendre concret via un mécanisme de compétences attribuées à chaque collaborateur. Périmètre tranché explicitement par Jean-Marc : Sophia ne produit un site que pour l'entreprise exploitant ASPIC elle-même (jamais pour un client tiers), à partir des seuls contenus fournis en conversation (Catalogue/Documents restent des classeurs vides à ce stade, section 19), avec mise à jour possible et publication toujours déclenchée par un humain. Cinq tables créées dans MS-DEV (ASP_Competences, ASP_AgentsCompetences, ASP_Missions, ASP_SitesWeb, ASP_SitesWebFichiers, convention de nommage stricte imposée par Jean-Marc : chaque champ préfixé par sa propre table, jamais celle référencée). Nouvel endpoint mission_agent.php (boucle agentique avec vrais outils Anthropic — écrire/lire/lister des fichiers de site, sandbox stricte, historique persisté côté serveur pour rester indépendant de l'ordinateur utilisé), séparé de collaborateur_dialogue.php qui reste sans effet de bord. sites_web.php (liste + publication, jamais un outil du modèle) et missions.php (ouverture/liste des missions). Nouveau volume Docker (sites_brouillons, hors racine servie) et premier incident de permissions du projet (première fois qu'un fichier PHP écrit réellement sur disque). Compétence SITE_WEB attribuée à Sophia, premier essai réel concluant (réactive, mémoire d'expérience bien réinjectée) — détail des fichiers réellement écrits pas encore vérifié par Jean-Marc. Clarification actée au passage : c'est AGN_Experience (pas AGN_Identite) qui s'enrichit à la clôture d'une Mission. <code> et <conception> avancent tous les deux au cours de cette session — nouvelle version V1.21.22.

11 septembre 2026 (après-midi) : le BackOffice — Collaborateurs, Compétences, Espaces disque, coût IA (V1.22.23). Détail technique complet en section 32 du journal ; fil stratégique en Réflexions stratégiques, section 23. Jean-Marc a réalisé qu'ASPIC a désormais deux univers distincts — l'écran utilisateur final, et la mécanique interne (identités, compétences, missions-types) — et a demandé un vrai BackOffice ("BO", terme repris de Prestashop) pour héberger cette mécanique : esthétique terminal minimale, menu à gauche, Échap pour en sortir uniquement depuis le menu. Accès piloté par MIR_Users.MIR_BO, bouton "BO" discret sur le bureau. Les outils "Construire une identité"/"Tester l'identité" ont été débranchés d'ecran_fond.html (718 lignes retirées) et migrés dans le BO ; nouvelle page Compétences (catalogue + attribution, AGN_Competences pas encore câblé). Espaces disque privés automatisés : la proposition initiale de Jean-Marc (SHA256 tronqué) a été remplacée par un HMAC à clé secrète pour le dossier de chaque base de travail et un jeton aléatoire pour chaque utilisateur (bug trouvé au passage : MIR_Code n'est pas unique dans MIR_Users, corrigé en utilisant MIR_Email). Enfin, après la découverte de plus de 20€ de consommation Anthropic inexpliquée, mise en place d'un cache de prompt (cache_control) et d'une journalisation réelle du coût de chaque appel (nouvelle page BO "Coût IA") — non prévu au départ, ajouté à la demande de Jean-Marc en cours de session.

11 septembre 2026 (soir) : vision des compétences, champ Relationnel, sortie des prompts IA du code (V1.23.24). Détail technique complet en section 33 du journal ; fil stratégique en Réflexions stratégiques, section 24. Nouvel onglet "Compétences" en lecture seule dans bo_collaborateurs.html. Bug de récitation découvert au premier essai (une compétence posée en test, "savoir faire un bon café", citée telle quelle par Sophia) : $blocCompetences ne portait pas la garde anti-récitation d'AGN_Identite/AGN_Experience, corrigé. Clarification conceptuelle en quatre facettes (Identité/Compétences/Expérience/Relationnel, voir Réflexions stratégiques) aboutissant à un nouveau champ AGN_Relationnel (posture envers l'équipe, statique), saisi dans un nouvel onglet et injecté dans le prompt de collaborateur_dialogue.php. Chantier plus large ensuite, à la demande de Jean-Marc : sortir les quatre prompts système du projet du code PHP vers une nouvelle table ASP_Prompts, avec auto-amorçage depuis un texte par défaut (moteur_prompts.php) et une nouvelle page BO bo_prompts.html/prompts.php. Au passage, retrait de toute occurrence du prénom "Jean-Marc" réellement transmise à un modèle ou journalisée, remplacée par le prénom de la session en cours (USR_Prenom) — Jean-Marc ayant réalisé que ce prénom en dur poserait problème le jour où ASPIC serait fourni à un autre patron (lien avec l'objectif fondateur de vente SaaS, réflexions stratégiques section 23). AGN_Couleur (pastel par collaborateur) branchée pour la première fois quelque part : les bulles du panneau "Tester" du BO, aux côtés du jaune classique (#fbe14a) pour l'utilisateur — l'usage sur le tableau de liège (post-its) reste, lui, à faire (voir chantier des attributions ci-dessous). <code> et <conception> avancés tous les deux à la demande explicite de Jean-Marc — nouvelle version V1.23.24.

Prochain chantier annoncé par Jean-Marc : gérer les attributions de tâches des assistants. L'écran 2 ("assistants"/"collaborateurs") est désormais présenté (portraits, couleurs, rôles, identité) mais ne porte encore aucune action réelle de répartition de tâches — à rapprocher des points déjà notés plus bas dans "Reste à faire" (discriminant humain/agent sur ASP_ToDoList, répartition dynamique des 70% par charge de tâches, exploitation réelle d'AGN_Couleur) — rien de plus précisé à ce stade sur le périmètre exact.

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) — distinct du cache navigateur simple rencontré le 8 septembre (résolu par un rechargement forcé), toujours en suspens.
• 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).
• Récupérer les résultats de la campagne de tests d'adresses mail que Jean-Marc prévoit de mener le 4 septembre (mode adresse de micro_test.js) pour mesurer un vrai taux de réussite, sur un échantillon plus significatif que les 4 essais du 3 septembre.
• Retirer le bloc de diagnostic temporaire (DIAGNOSTIC_ACTIF/logDiag) de micro_test.js une fois son comportement confirmé stable sur cette campagne.
• Décider si le cas "deux adresses dictées sans clic Valider entre les deux" (mode adresse) mérite un traitement automatique, ou reste une simple consigne d'usage.
• Si le taux d'échec mesuré début septembre reste trop élevé : évaluer en conditions réelles (pas seulement sur la documentation) Google Cloud Speech-to-Text (phrase hints/boost) et Deepgram (keyterm prompting) avec le vocabulaire métier d'ASPIC — voir réflexions stratégiques, section 12.
• Le problème des lettres avalées sur les mots inventés/sigles (ex. "mvl-tls.fr") reste entier, sans solution de contournement identifiée à ce stade — à garder en tête, pas à considérer comme résolu par le mode adresse.
• Reconnecter micro.js (vrai pilotage) sur le micro de l'écran de fond une fois la phase de mise au point terminée — une ligne à changer dans ecran_fond.html.
• Étendre MARQUEUR_FIN_LIGNE dans micro.js pour accepter "puis" en plus de "ensuite" (retour d'usage de Jean-Marc, 3 septembre) — sans urgence.
• Continuer à observer les agents actifs (Viktor, Matilda, Léon, Nikita, Sophia) en usage réel ; ajuster AGN_Variantes en base si de nouvelles confusions apparaissent.
• Documentation utilisateur : le panneau de détail du contact, la ToDoList, le pilotage vocal et l'écran des collaborateurs restent à documenter (mise à jour du 3 septembre limitée à l'écran d'accueil et à la liste des contacts ; l'écran des collaborateurs volontairement laissé de côté pour l'instant, tant qu'il ne porte aucune action réelle de gestion, voir 9-10 septembre) — l'outil de banque de dictées, le chantier des consignes et les outils de construction/test d'identité n'ont volontairement pas vocation à y figurer pour l'instant, ce sont des chantiers internes, pas des modules utilisateur finalisés.
• Gérer réellement les attributions de tâches des assistants (Matilda et les autres) — chantier annoncé par Jean-Marc le 8 septembre, toujours pas commencé (voir plus haut). Contenu réel de l'écran 3 (tableau de bord) toujours entièrement à concevoir ; décider si les autres objets de l'avant-plan (carnet, téléphone) doivent devenir cliquables ; 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).
• Concevoir les deux signes graphiques distincts pour les post-its "à corriger"/"à valider" (réflexions stratégiques, section 12) — le premier acté (point d'interrogation), le second encore à choisir.
• 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. À rapprocher du chantier des attributions des assistants.
• É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 à l'exploitation réelle des couleurs de post-it par assistant (AGN_Couleur, déjà ajoutée à ASP_Agents mais encore inutilisée par aucun écran). À rapprocher du chantier des attributions des assistants.
• É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é.
• Concevoir le contrat de retour complet à trois issues (silencieux / besoin de précision / question à poser) pour les consignes à appel IA — le 7 septembre n'en a construit qu'un premier incrément à deux issues (succès silencieux / échec avec avertissement bloquant), voir section 30. À généraliser le jour où un second cas concret en montrera le besoin réel, pas par anticipation.
• Écran de gestion des consignes par le boss (au lieu d'INSERT/UPDATE SQL à la main) — à construire après stabilisation du contrat ci-dessus, pour ne pas le refaire (chantier des consignes, section 30).
• Réflexion sur un catalogue restreint de consignes/fonctions avancées à proposer aux futurs utilisateurs de l'agence, sans leur ouvrir la création libre de A à Z — argument commercial identifié par Jean-Marc le 6 septembre (voir réflexions stratégiques, section 15).
• Accumulation de plusieurs messages d'erreur à la fois dans le moteur de consignes (aujourd'hui, seul le premier test en échec est remonté).
• Gestion des consignes transverses à toute la fiche (CNS_Champ NULL, ex. contrôle de doublon) — non traitée par le moteur de consignes actuel.
• Distinction Saisie/Validation réellement exploitée un jour dans le moteur de consignes (temps réel), si le besoin redevient assez fort pour justifier la complexité écartée le 6 septembre.
• Ouvrir le chantier du dialogue simulé avec Claude intégré à ASPIC (bulles de dialogue façon SMS, mission dédiée) — faisabilité confirmée le 8 septembre 2026 (réflexions stratégiques, section 18), premier dialogue réel désormais opérationnel côté outil interne de test (10 septembre, voir ci-dessus) mais rien conçu ni codé côté écran utilisateur final.
• Ménage dans la structure de ASP_Consignes (8 septembre 2026) : Jean-Marc a repéré des champs qui lui semblent redondants (CNS_TexteDefinition/CNS_TexteAffiche en particulier) — à examiner ensemble avant de toucher au schéma, pour ne pas supprimer un champ qui sert ailleurs sans qu'on l'ait vérifié.
• Contenu réel des classeurs Missions, Propositions, Livraisons et Gestion (nouvelle classification du 9-10 septembre, voir réflexions stratégiques section 19) — aucun écran ni donnée derrière à ce stade, seule la classification cible est fixée.
• Rédaction des cinq textes d'identité des collaborateurs — Jean-Marc les écrit lui-même, à la première personne (Matilda déjà saisie via l'outil réel du 10 septembre) — à intégrer aux EBAUCHES_IDENTITE de secours dans ecran_fond.html une fois reçus, si besoin.
• Lien concret entre une Mission close et l'enrichissement réel de AGN_Experience (pas AGN_Identite, voir réflexions stratégiques section 22 qui corrige la section 20) au fil du temps — intention actée, rien conçu ni codé à ce stade (MIS_Statut/MIS_BilanCloture existent en base, mais aucun endpoint de clôture n'a encore été écrit).
• Stockage de documents utilisateur (PDF) — architecture actée par anticipation (réflexions stratégiques, section 21 : stockage hors racine servie par le serveur web, endpoint PHP dédié, sous-dossier opaque par client en défense en profondeur), aucun développement engagé, pas de besoin immédiat.
• Compétence "sites web" de Sophia (section 31, 10-11 septembre 2026), points laissés ouverts : lecture réelle du catalogue/documents de l'entreprise (dépend de classeurs encore vides, section 19) ; support des images/fichiers binaires dans un site (texte seul pour l'instant) ; rattachement d'un site publié à un vrai nom de domaine (vhost Apache ou npm-app-1, étape manuelle) ; synchronisation du schéma des 5 nouvelles tables vers MS-TST (pas encore faite) ; vérification détaillée par Jean-Marc de ce que Sophia a réellement écrit lors du premier essai réel.
• BackOffice (section 32, 11 septembre 2026), points laissés ouverts : ASP_Agents.AGN_Competences — câblé en addendum le 11 septembre 2026 (agents_competences.php l'écrase/recalcule à chaque attribution/retrait de compétence ; lu par mission_agent.php et par collaborateur_dialogue.php, en plus d'AGN_Identite/AGN_Experience), non encore vérifié en conditions réelles. Endpoint de téléchargement de fichier depuis un espace disque utilisateur (telecharger_fichier.php ou équivalent) — architecture posée (section 32), rien construit. Comportement réel du cache de prompt et de la journalisation du coût IA à confirmer sur un premier vrai appel après ce soir (aucun appel réseau réel déclenché depuis l'environnement de développement).
• Travail non poussé sur GitHub, découvert le 11 septembre 2026 — résolu. Les chantiers des 10 et 11 septembre étaient restés en attente de commit/push ; git status est de nouveau propre au 12 septembre 2026, Jean-Marc ayant fait le commit/push lui-même dans l'intervalle, comme décidé. Rappel de la décision, qui reste valable pour la suite : Jean-Marc gère lui-même tout commit/push sur ce dépôt, y compris la rédaction du message — jamais une tâche à déléguer à Claude, "ça m'oblige aussi à continuer à manipuler". Les fichiers modifiés ce soir (version.php, ce document, les réflexions stratégiques section 25) sont prêts sur le disque pour ce même circuit, non commités par Claude.
• Vérifier que la colonne AGN_Relationnel (ajoutée par Jean-Marc le 11 septembre 2026, sans type précisé par Claude) est assez large pour un texte libre, cohérente avec AGN_Identite/AGN_Experience (MEDIUMTEXT).
• Affiner individuellement l'identité/le relationnel de chaque collaborateur (Matilda, Viktor, Léon, Nikita, Sophia) — explicitement reporté par Jean-Marc le 11 septembre 2026 à plus tard ("quand je n'aurai que ça à faire").
• Créer un répertoire dédié sur le serveur pour transmettre directement des fichiers à Claude (photos notamment) — envisagé par Jean-Marc le 11 septembre 2026, pas encore fait.
• Services externes pour les futurs chantiers (prospection, réseaux sociaux) — réflexions stratégiques section 23 (11 septembre 2026). Volet prospection largement avancé dans la nuit du 11 au 12 septembre : canal Sirene/RNE choisi et mis en œuvre pour de bon (voir réflexions stratégiques section 25) — décision de méthode de la section 23 confirmée dans les faits (gratuit d'abord, achat de contact seulement une fois la cible resserrée). Volet réseaux sociaux toujours entièrement ouvert, recherche à reprendre quand ce chantier s'ouvrira.
• Prospection B2B (réflexions stratégiques section 25, 11-12 septembre 2026) — mise à jour du 12 septembre 2026 (après-midi) : les 4 départements bretons sont désormais tous extraits. Entreprises56/29/22/35Phase1 alimentées via src/scripts/sirene_extract.py (déplacé de /docker/aspic/scripts/ dans le dépôt applicatif ce même après-midi, pour bénéficier du même suivi Git que le reste — voir .gitignore mis à jour pour exclure scripts/__pycache__/) : 167 468 + 174 691 + 128 904 + 227 713 = 698 776 entreprises (chiffre après correction Rennes, voir juste après), Phase3 (historique financier) alimentée en parallèle pour chacun. Cas limite rencontré puis corrigé le même après-midi : sur la commune de Rennes (35238, pas Saint-Malo comme noté par erreur dans un premier temps), la section NAF "L" (activités immobilières) restait plafonnée à 10 000 même après repli par section — ajout d'un 3e niveau de repli par code NAF précis (liste complète des 732 codes récupérée depuis le message d'erreur de validation de l'API elle-même). Rennes réextraite avec ce correctif : 69 115 entreprises retrouvées pour la seule commune (dont 50 857 bien rattachées à Rennes elle-même comme siège), portant le total du 35 de 221 646 à 227 713. Mise à jour de la nuit du 12 au 13 septembre 2026 (réflexions stratégiques, section 26). Comptes INSEE et INPI créés (identifiants dans src/scripts/.env, jamais commité). Backfill historique des comptes annuels (le BFH, src/scripts/inpi_bilans_backfill.py) conçu et lancé sur le 56 — a provoqué un incident sérieux (OOM ayant tué le script et systemd), corrigé (garde-fou de pagination + ulimit -v désormais systématique sur ces scripts). Tables ENT_Departements/ENT_Config ajoutées. Compression InnoDB appliquée à Phase1 (-60% de taille disque, projection nationale ramenée de ~70 à ~28-30 Go). Plan pour la suite de la nuit, sans supervision : une fois le BFH du 56 terminé, extraction + BFH enchaînés pour 44, 49, 85, 17, 40, 64, 65. Toujours à faire : synchronisation quotidienne par API différentielle (companies/diff/bilans-saisis) déclenchée par n8n plutôt qu'une crontab — comptes créés mais rien construit côté n8n. Écran de sélection par isochrone (IGN Géoplateforme, démontré fonctionnel) — idée actée, rien construit côté interface. Mise à jour du 13 septembre 2026 (réflexions stratégiques, section 27). Chaîne 44/49/85/17/40/64/65 terminée sans incident dans la nuit. Champ ENT_CodeCommune ajouté à Phase1 (backfill sans nouvel appel API) et cinq compteurs par taille d'entreprise (COM_EI/TPE/PME/ETI/GE) ajoutés à ENT_Communes, calculés quotidiennement par ent_communes_stats.py (deux bugs corrigés : agrégat SUM() sur ensemble vide, et pollution inter-département des stats d'une commune). Quatre prototypes de carte de prospection géographique publiés en Artifacts (Lorient, Lanester, Concarneau, Beuzec-Cap-Sizun) : commune de départ + communes accessibles en 30 min de route réelles (isochrone IGN), avec effectifs réels par taille — navigation par cliquer-glisser (clic gauche et droit) après un premier essai à l'ascenseur natif jugé peu lisible. Deuxième chaîne lancée pour 31/32/33/46/47/09/13/66 : bug de fond découvert et corrigé sur le repli NAF à 3 niveaux (retestait les 732 codes NAF entiers à chaque section plafonnée au lieu des seuls codes de la section — bloquait Toulouse depuis des heures), département 31 relancé et terminé après correctif. Cap des 2 millions d'entreprises cumulées franchi (2,23M sur 15 départements). Premières réflexions actées sur la refonte du module Contacts (lien entreprise↔contact non exclusif, qualification portée par l'entreprise) — rien construit, sujet remis à l'ouverture formelle du chantier. Mise à jour du 14-15 septembre 2026 (réflexions stratégiques, section 28). Deux bugs supplémentaires trouvés et corrigés sur le BFH (curseur de pagination basé sur le SIREN au lieu de l'identifiant unique du bilan, perdant ~14% des lots ; jeton INPI expirant en cours d'exécution sans reconnexion automatique), puis un vrai quota INPI dépassé rencontré (quota_exceeded) — BFH suspendu entièrement sur décision de Jean-Marc (risque de bannissement jugé disproportionné), à reprendre progressivement dans les mois à venir. Découverte indépendante et majeure sur l'extraction Sirene : Paris, Lyon et Marseille étaient massivement sous-captées (les entreprises y sont rattachées à un code arrondissement, jamais au code commune englobant qu'utilisait la liste de communes) — corrigé dans sirene_extract.py, ENT_Communes réparée pour le 13, réextraction replanifiée. Nouvelle chaîne d'extraction Sirene seule (aucun appel INPI) lancée pour la France entière restante, DOM-TOM inclus à la demande de Jean-Marc (La Réunion en tête). Statut au 15 septembre : 55 départements, 7 036 958 entreprises (~83% du national), BFH à l'arrêt. Piste d'export en masse du RNE par FTP/SFTP (opendata/www.inpi.net) identifiée via un contact de Jean-Marc, vérifiée réelle et testée en lecture seule (stock formalités 15,1 Go incluant le capital social, dernier stock à 6 mois d'écart, pas de flux quotidien visible) — accès obtenu, rien exploité encore. Jean-Marc est revenu sur sa décision initiale : le capital social doit être mutualisé dans ENTREPRISES (donnée factuelle), pas privé par compte, avec une exception assumée au principe de non-écriture applicative pour ce champ précis. Feuille de route formelle déposée (src/fdr/1. ENTREPRISES V1.0) et relue en détail (retour donné, pas d'implémentation) — découverte au passage que le champ JSON matching_etablissements[] donne probablement l'adresse des établissements secondaires. Trombinoscope des cinq collaborateurs ASPIC clarifié : Matilda, Viktor (commercial/qualification), Sophia, Léon (gestion/ENTREPRISES), Nikita. Mise à jour du 16 septembre 2026 (réflexions stratégiques, section 29). Méthode des feuilles de route institutionnalisée : dépôt PDF/.docx numéroté (1 à 11) dans src/fdr, retour de Claude Code toujours intégré dans une nouvelle version du fichier (plus seulement en conversation). Outillage installé (python-docx, openpyxl) pour générer des .docx éditables et lire des maquettes Excel. Vérification empirique demandée par Jean-Marc pour trancher un doute : 7 802 SIREN confirmés présents en double entre les tables du 35 et du 44 (établissement secondaire compté aussi bien dans le département du siège que dans celui où il se trouve) — le stockage des filiales devra être repensé, noté pour la suite. Nouvelle feuille de route "3. Sélection des Entreprises" déposée et itérée. Cible nationale recalibrée de 8,5M à 13,4M (un site tiers cite le chiffre SIRENE brut "établissements sièges", à distinguer de l'agrégat statistique INSEE qui regroupe les filiales d'un groupe) — projection disque recalculée à ~43,5 Go (toujours confortable). Lyon (69) extrait avec succès : 506 425 entreprises, le plus gros département à ce jour, correctif arrondissements validé en conditions réelles. Statut extraction : 74/101 départements, 9 855 993 entreprises. Clarifications hors chantier : abonnement Claude Max ≠ API Anthropic (deux facturations séparées) ; piste Claude Cowork pour les fonctionnalités réseaux sociaux côté utilisateur final (hors budget API d'ASPIC). Mise à jour du 17 septembre 2026 (réflexions stratégiques, section 30). Incident de parallélisme causé par Claude Code lui-même : une reprise du 74 lancée en même temps que la chaîne principale a saturé l'API Sirene (429), cascadant sur 75 (Paris)/76/77 — corrigé (script durci, plus jamais de traitement en parallèle) et reprise séquentielle programmée ; un second incident sans lien (verrou MySQL) a ensuite ajouté le 88 à la liste. Naissance du projet dérivé entreprises.bzh (domaine acquis) : accès aux données d'entreprises par isochrone plutôt que rayon, mis en ligne visé à la création de la société début 2027 (un an avant ASPIC), avec un objectif d'entraînement (paiement en ligne, facturation électronique, réseaux sociaux) autant que commercial. Dossier de marché commandé à une autre session Claude, relu : confirme un vrai créneau libre (fraîcheur quotidienne + géographie fine, aucun concurrent ne combine les deux) et révèle que le statut "P" (diffusion partielle, ex-non-diffusible) n'est pas capturé dans ENTREPRISES — à corriger lors du remodelage prévu, pas maintenant. Discussion approfondie sur les limites de l'enrichissement LinkedIn (Waalaxy et assimilés, risque d'éditeur distinct du risque utilisateur). Double-comptage inter-départements mesuré précisément : 1 189 137 doublons sur 12,3M lignes (9,6%), ~4,18 Go de poids disque. Feuilles de route ENTREPRISES (V7) et Sélection des Entreprises (V7) mises à jour. Fin d'extraction estimée pour le week-end du 19-20 septembre. Mise à jour du 18 septembre 2026 (réflexions stratégiques, section 31). Alerte disque serveur (84% d'occupation) : diagnostic révèle 79 Go de binlogs MySQL jamais purgés sur l'instance mysql2 (rétention à 30 jours, disproportionnée face au volume d'écriture de l'extraction), pas un problème de données — ENTREPRISES elle-même ne pèse que 52 Go, croissance normale. Purgé avec l'autorisation explicite de Jean-Marc (bloqué une première fois par le classificateur de sécurité du mode auto, qui l'a pris pour une altération de journaux d'audit) : disque ramené de 84% à 43%. Rétention réduite temporairement à 3 jours le temps du chantier. Mise à jour du 18-19 septembre 2026 (réflexions stratégiques, section 32). Bug de fond découvert et corrigé sur la Corse : le paramètre code_commune de l'API Sirene échoue silencieusement sur les codes alphanumériques (2A/2B), remplacé par une requête directe au niveau département pour ces deux cas — sirene_extract.py modifié en conséquence. Deux départements orphelins retrouvés en vérifiant l'état de ENT_Departements (88, planté le 17 septembre mais jamais réintégré à la reprise ; 48, données déjà extraites mais jamais finalisées) et ajoutés à la file de reprise, désormais 74/75/76/77/88/2A/2B/48 derrière la fin de la chaîne principale (13, Marseille). Total national fait le point : 94 départements fiables à 13 088 450 entreprises, Paris déjà à 831 979 avant même la fin de sa reprise. Exploration du logo (détecteur/pépite) refermée sans aboutir : Pippit AI a fini par signaler son incapacité à retoucher précisément (pas de calques), une alternative vectorielle proposée par Claude Code jugée trop abstraite — piste de retouche manuelle (Photopea) identifiée mais reportée. Recherche du nom de domaine d'entreprises.bzh close après plusieurs vérifications systématiques (marque INPI + collision de nom, conformément au principe explicite de Jean-Marc "éviter les problèmes plutôt que devoir les gérer") : prospecter.bzh écarté (marque française active "PROSPECTER" détenue par TESSI, classe 35) ; piste fichiers-prospects.fr explorée puis délaissée en cours de route ; API Pappers étudiée pour ses numéros de téléphone d'entreprise mais écartée (CGU interdisant explicitement toute réutilisation pour alimenter un service tiers). Nom définitivement retenu : entreprizh.bzh, disponible, accordé par l'association .bzh, vérifié propre par Claude Code puis confirmé sans résultat par Jean-Marc lui-même sur data.inpi.fr — achat décidé le soir même. Mise à jour du 19-20 septembre 2026 (réflexions stratégiques, section 33) : extraction Sirene entièrement terminée. La file de reprise a enchaîné sans incident sur 74/75(Paris)/76/77/88/2A/2B/48 ; le correctif Corse a fonctionné du premier coup (2A : 55 190, 2B : 54 823 entreprises). Total national final : 101 départements, 15 972 915 entreprises. Plus aucun processus d'extraction actif. Le chantier de restructuration ENTREPRISES (siège/filiale, partitionnement, statut "P") peut désormais démarrer sur des données complètes — Jean-Marc prévoit une session neuve pour ce chantier. Rétention des binlogs MySQL toujours à 3 jours (section 31), à remettre à 30 jours maintenant que l'extraction est finie.