mirror of
https://github.com/JMP-MS/ASPIC.git
synced 2026-10-27 16:07:10 +00:00
V1.22.23 Passage à Claude Code et création du BackOffice
This commit is contained in:
@@ -21,6 +21,8 @@ Pour les trois documents de ce projet (ce journal — résumé/index —, les R
|
||||
- `<conception>` : reprend le numéro de la dernière section **créée** dans les Réflexions stratégiques — jamais un simple complément apporté à une section déjà existante. Critère de Jean-Marc pour ouvrir une nouvelle section plutôt qu'un addendum : le jugement qu'une évolution de la conception est **majeure**, y compris sur un sujet déjà effleuré auparavant (auquel cas la nouvelle section 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. Les "trous" de numérotation que ça peut produire (ex. de 10 à 28) sont acceptés sciemment par Jean-Marc, ce n'est pas une anomalie à corriger.
|
||||
- `<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).
|
||||
|
||||
**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.
|
||||
@@ -58,6 +60,8 @@ Pour les trois documents de ce projet (ce journal — résumé/index —, les R
|
||||
- 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
|
||||
|
||||
*(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.)*
|
||||
|
||||
@@ -123,6 +127,10 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
|
||||
|
||||
**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.
|
||||
|
||||
**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 :**
|
||||
@@ -159,5 +167,9 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
|
||||
- **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_Identite` au fil du temps (réflexions stratégiques, section 20) — intention actée, rien conçu ni codé à ce stade.
|
||||
- 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` (champ dénormalisé, écrasé/recalculé à chaque modification des compétences d'un collaborateur, lu par `mission_agent.php` ET par le dialogue de test de `bo_collaborateurs.html` en plus d'`AGN_Identite`/`AGN_Experience`) — décrit et validé avec Jean-Marc, pas encore codé. 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, toujours en attente :** les chantiers des 10 et 11 septembre (collaborateurs, compétences/missions, BackOffice) n'ont jamais été committés/poussés — `git status` montre tout en attente. Décision de Jean-Marc à prendre sur le commit/push groupé.
|
||||
- **Services externes pour les futurs chantiers (prospection, réseaux sociaux) — réflexions stratégiques section 23 (11 septembre 2026) :** décision de méthode actée (préférer un service externe existant au cas par cas, internaliser ensuite si besoin réel constaté), mais aucun service concret encore choisi ni intégré — recherche à reprendre spécifiquement pour ces deux chantiers quand ils s'ouvriront.
|
||||
|
||||
@@ -378,3 +378,45 @@ Dans cette architecture, peu importe finalement que Jean-Marc « connaisse » ou
|
||||
**Statut.** Aucun développement engagé — réflexion volontairement anticipée, avant tout besoin réel, pour que le premier fichier réellement stocké le soit déjà dans la bonne architecture plutôt que dans une version à corriger après coup. Reste à concevoir le jour venu : la table de métadonnées (nom d'origine, type, taille, contact/mission lié, propriétaire, date), l'endpoint de dépôt et l'endpoint de téléchargement, sur les mêmes conventions défensives déjà en place ailleurs dans ASPIC (vérification de session, requêtes préparées, erreurs explicites plutôt que silencieuses).
|
||||
|
||||
`<code>` avait déjà avancé en tout début de cette même session (V1.18.19 → V1.19.20) pour le code livré ce jour sur l'écran des collaborateurs ; ces deux nouvelles sections (20 et 21) font avancer `<conception>` une seconde fois au cours de la même session, de 20 à 21 — nouvelle version **V1.19.21**.
|
||||
|
||||
## 22. Le concept de "compétence" — donner à un collaborateur une capacité réelle d'agir, et jusqu'où (10-11 septembre 2026)
|
||||
|
||||
**Origine — un collaborateur qui réclame ce qu'il n'a pas.** En testant l'identité de Sophia (section 20), Jean-Marc l'a vue lui demander spontanément des informations et des fichiers pour "créer des sites web" — alors qu'elle n'a jamais eu la moindre capacité réelle d'agir, seulement une conversation. Claude a noté que ce n'est pas dangereux en soi (rien ne peut se passer sans outil réel), mais révélateur : rien dans son identité ni son prompt système ne la borne sur ce qu'elle peut légitimement proposer — un collaborateur non briefé "invente" son périmètre. Jean-Marc a validé cette lecture explicitement : *"c'est à moi de la canaliser"*, en la limitant demain aux seules compétences dont elle aura été dotée.
|
||||
|
||||
**Reformulation du besoin par Jean-Marc, plus large que le cas Sophia.** Plutôt que de traiter "donner à Sophia la capacité de faire des sites" comme un besoin isolé, Jean-Marc a explicitement relié le sujet à un chantier de fond resté en suspens depuis le 8 septembre : le concept de **Mission** (section 18), posé dans ses grandes lignes mais jamais conçu en détail. Doter un collaborateur de **compétences** est la pièce manquante qui permet à une Mission d'exister concrètement : quelles compétences un collaborateur possède, quelles compétences une Mission requiert pour être réalisable. Point de méthode assumé par Jean-Marc, qui découvre l'usage réel de Claude/des LLM en marge de ce chantier : *"j'ai besoin d'être assisté"* — le sujet a été traité comme un apprentissage autant que comme une conception.
|
||||
|
||||
**Ce qu'une "compétence" signifie réellement, techniquement.** Point pédagogique important établi en cours d'échange : côté Anthropic, il n'existe aucune notion de "compétence" — seulement un mécanisme d'outils (tools) déclarés à chaque appel, que le modèle peut choisir d'invoquer, jamais exécuter lui-même. "Doter" un collaborateur d'une compétence se traduit donc concrètement par deux choses combinées : quels outils apparaissent réellement dans la liste envoyée pour lui (une compétence non accordée = un outil absent, pas juste déconseillé), et ce que son prompt système lui dit avoir le droit de faire — pour éviter exactement l'épisode qui a lancé cette réflexion.
|
||||
|
||||
**Le périmètre business tranché avant toute conception technique.** Jean-Marc a été explicite et sans détour sur ce que la compétence "sites web" ne doit jamais devenir : Sophia ne produit des sites que pour l'entreprise qui exploite ASPIC elle-même, jamais pour un client tiers de cette entreprise — *"il faut rester dans le périmètre d'un CRM !"*. Elle ne travaille qu'à partir des documents de l'entreprise, doit pouvoir mettre à jour un site déjà créé (retours clients, nouveaux produits du catalogue), et une fois ses créations validées, doit pouvoir les faire publier. Une nuance importante s'est imposée en creusant ce dernier point : la validation et la publication restent des actes humains — cohérent avec le principe déjà posé pour la clôture d'une Mission (section 18, *"la clôture d'une mission est une décision du manager, jamais un calcul automatique"*) : la même discipline s'applique à la mise en ligne d'un livrable produit par un collaborateur.
|
||||
|
||||
**Le stockage — un cas différent du coffre-fort documentaire de la section 21, pas une extension de celui-ci.** Jean-Marc a d'abord été réticent à l'idée d'un stockage "sur le disque dur local de l'utilisateur", inquiet de devoir retrouver ses données en changeant d'ordinateur d'un jour à l'autre — un malentendu levé en clarifiant qu'aucun stockage local n'était en jeu, tout vivant côté serveur, déjà accessible identiquement depuis n'importe quelle machine. La vraie question restait la bonne clé d'isolement par entreprise. Contrairement au coffre PDF (section 21, où l'inaccessibilité totale au navigateur est le principe même), un site web doit au contraire être servable — la section 21 ne pouvait donc pas être simplement recopiée, seulement inspirée dans son esprit (hors racine tant que brouillon, accès contrôlé). Confirmation apportée par Jean-Marc que plusieurs sites pourront coexister pour une même entreprise (deux domaines réels déjà en tête : `mevelia-solutions.bzh` pour la future agence, `aspic.bzh` pour le CRM lui-même une fois commercialisé) — le modèle retenu autorise nativement cette pluralité.
|
||||
|
||||
**Une précision de fond sur `AGN_Identite`/`AGN_Experience`, qui affine la section 20.** En repensant au mécanisme de clôture d'une Mission, Jean-Marc a corrigé une ambiguïté laissée par la section 20 : ce n'est pas l'identité d'un collaborateur qui s'enrichit avec l'usage, c'est son **expérience** — `AGN_Identite` reste le profil fixe à l'embauche, volontairement écrasable si Jean-Marc veut corriger un trait de caractère ; `AGN_Experience` est ce qui se met à jour à la clôture d'une mission, jamais réécrit, seulement accumulé. Séparer les deux champs dès le 10 septembre (section 20) s'avère avoir anticipé, sans le nommer alors, exactement cette distinction.
|
||||
|
||||
**Une question laissée volontairement ouverte par Jean-Marc, reconnue comme le sujet le plus intéressant du chantier : comment un collaborateur évolue-t-il vraiment avec l'expérience ?** Claude a rappelé un fait déstabilisant mais déjà entrevu en section 18 : le modèle lui-même n'apprend jamais rien, une session à l'autre — ce qui ressemble à une évolution du collaborateur n'est que le texte accumulé dans `AGN_Experience`, réinjecté intégralement à chaque appel. Jean-Marc a validé cette mécanique comme **souhaitable**, pas comme une limite à contourner : *"un fonctionnement différent voudrait dire que le LLM apprend de mon utilisation, ce que je n'ai ni la prétention ni l'intention de faire"* — la mémoire reste ainsi entièrement éditoriale, sous le contrôle de Jean-Marc (correction, purge, gel possible à tout moment), jamais une boîte noire qui dériverait toute seule. Question laissée en réserve pour une prochaine session : à partir de quel volume ce texte accumulé devra-t-il être résumé plutôt qu'injecté intégralement (même tension déjà identifiée pour les consignes et les missions, sections 12/18) — et si une remise à zéro complète de l'expérience d'un collaborateur sera un jour nécessaire (l'échappatoire existe déjà, via "Modifier l'expérience", simplement jamais pensée jusqu'ici comme une réinitialisation).
|
||||
|
||||
**Statut.** Conception validée et codée dans la foulée de cette même session (voir journal de développement, section 31, pour le détail technique : tables, endpoints, boucle agentique, premier essai réel). Points laissés ouverts, actés ici comme sujets de fond plutôt que comme détails techniques : le mécanisme réel de clôture d'une Mission (comment un bilan de mission vient concrètement enrichir `AGN_Experience`) ; le seuil à partir duquel l'expérience accumulée d'un collaborateur devra être résumée plutôt qu'injectée en entier ; la question, gardée en réserve, d'une remise à zéro de mémoire.
|
||||
|
||||
`<code>` avance également au cours de cette même session (chantier décrit en détail au journal de développement, section 31) — nouvelle version **V1.21.22**.
|
||||
|
||||
## 23. Services externes ou développement interne pour les compétences des collaborateurs — premier cas réel, le site web (11 septembre 2026)
|
||||
|
||||
**Origine.** Après avoir vu la compétence "site web" fonctionner (section 22), Jean-Marc s'est demandé s'il n'était pas en train de "réinventer l'eau chaude" — et s'il ne vaudrait pas mieux faire appel à un agent/service déjà existant plutôt que tout construire lui-même.
|
||||
|
||||
**Distinction posée par Claude entre le mécanisme et l'intégration.** Le "tool use" lui-même (déclarer des outils, boucler, exécuter côté serveur) est effectivement un patron générique, documenté par Anthropic, sans originalité — l'équivalent d'utiliser une prise électrique standard. Ce qui n'est pas de l'eau chaude, c'est l'intégration : aucun service externe grand public ne connaît Sophia, sa mémoire, ni les règles métier posées par Jean-Marc (jamais pour un client tiers, publication toujours validée par lui) — un outil externe rendrait le même service technique, mais casserait la valeur ajoutée réelle (une collaboratrice qui reste elle-même).
|
||||
|
||||
**Recherche réelle effectuée le même soir** sur les services existants de génération de site vitrine, avec un critère de filtrage strict : seuls comptent les services offrant une vraie **API programmable** (pas une interface de chat humaine) permettant de déclencher une génération et d'en récupérer le résultat par un appel HTTP. Résultat : sur une dizaine d'acteurs examinés (v0/Vercel, Bolt.new, Lovable, Framer AI, Durable.co, 10Web, Wix, GoDaddy Airo, Webflow...), **seuls deux** correspondent vraiment au besoin — et aucun des deux n'apporte de gain net pour un site vitrine strictement statique :
|
||||
- **10Web** : une vraie API prompt→site en un appel, mais impose une sortie **WordPress** (PHP + base de données), pas du HTML/CSS statique comme ce qu'ASPIC produit déjà. Tarif de production non public (sur devis).
|
||||
- **v0 (Vercel)** : API tarifée publiquement (20-30$/mois + facturation token), mais renvoie du **code** (React/Next.js) nécessitant un déploiement séparé, pas un résultat clé en main.
|
||||
|
||||
**Réserve explicite sur la fiabilité des tarifs trouvés** : la quasi-totalité des chiffres 2026 proviennent de blogs tiers/affiliés, pas des pages officielles des éditeurs — non vérifiables à 100% sur une source primaire.
|
||||
|
||||
**Conclusion retenue par Jean-Marc, qui devient une règle de décision générale plutôt qu'un simple constat ponctuel :** pour la compétence "site web" précisément, garder ce qui a été construit en interne — aucun service externe ne fait mieux sans changement d'architecture. Mais Jean-Marc a profité de l'occasion pour repréciser les **trois objectifs fondateurs** qui motivent tout le projet ASPIC depuis le début : (1) se doter enfin d'un outil efficace, longtemps rêvé sans jamais l'avoir eu dans ses expériences professionnelles passées ; (2) casser la sensation de solitude du patron de petite structure, y compris vis-à-vis de l'extérieur, via des collaborateurs humanisés à mémoire persistante ; (3) optionnellement, vendre ASPIC en SaaS si l'outil fonctionne bien et que la demande existe.
|
||||
|
||||
**Décision de méthode pour les prochains chantiers (prospection, réseaux sociaux...) :** au cas par cas, préférer un service externe existant pour les grosses fonctionnalités à venir — le temps disponible avant 2027 ne permet pas de tout construire à la main comme pour le site web (une soirée entière pour une seule compétence). Une fois l'expérience acquise avec ces services externes (ce qui marche, ce qui déçoit), Jean-Marc envisage une "Phase II" d'internalisation ciblée, avec l'aide de Claude, en capitalisant sur cette expérience plutôt qu'en devinant à l'avance ce qui vaudra la peine d'être ramené en interne.
|
||||
|
||||
**Point pédagogique retenu, pour distinguer un cas qui nécessite un outil d'un cas qui n'en nécessite pas** (exemple discuté : faire rédiger un article web à Sophia à partir d'un texte source) : la question à se poser est "est-ce que le résultat attendu EST le texte de sa réponse, ou est-ce que quelque chose doit changer en dehors de la conversation (fichier écrit, donnée enregistrée, action déclenchée) ?" Dans le premier cas (rédaction pure), un bon prompt suffit — le "savoir-faire" rédactionnel n'est pas un outil à fabriquer, il est déjà dans le modèle, le prompt se contentant de l'orienter (ton, structure, longueur des phrases). Dans le second cas (écrire un fichier, publier, aller chercher une donnée non fournie), un outil réel est indispensable, quelle que soit la qualité du prompt — c'est le prompt qui donne le contexte, jamais la capacité d'agir.
|
||||
|
||||
**Statut.** Décision actée : pour le site web, développement interne conservé ; pour les prochains grands chantiers, priorité aux services externes, réévaluation possible après usage réel. Rien d'autre engagé à ce stade — cette section fixe le cadre de décision, pas un choix définitif compétence par compétence.
|
||||
|
||||
`<code>` n'avance pas dans cette section (aucune ligne de code applicative touchée par cette réflexion elle-même — le code livré ce soir, décrit au journal de développement section 32, avait déjà fait avancer ce compteur avant cette discussion) ; `<conception>` avance de 22 à 23 — nouvelle version **V1.22.23**.
|
||||
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
# 31. Compétences, Missions et premier chantier agentique — Sophia et les sites web
|
||||
|
||||
**Origine (10-11 septembre 2026).** En utilisant l'outil "Tester l'identité" (voir section 28, Réflexions stratégiques section 20), Jean-Marc a constaté que Sophia se mettait à lui réclamer des informations et des fichiers pour "créer des sites web" pour lui — alors qu'aucune capacité réelle ne lui avait jamais été donnée, seulement une conversation. Claude a fait remarquer que ce n'était pas un problème en soi (elle n'avait aucun moyen d'agir) mais un symptôme : rien dans son prompt système ne la bornait sur ce qu'elle pouvait réellement proposer. Point retenu comme leçon de fond pour toute la suite du chantier.
|
||||
|
||||
**Reformulation par Jean-Marc : ce n'est pas un besoin ponctuel, c'est un chantier de fond.** Plutôt que de traiter la demande de Sophia isolément, Jean-Marc a explicitement élargi le sujet : donner à chaque collaborateur des **compétences**, pour qu'il puisse accomplir seul (pour commencer, mono-collaborateur) des **Missions** — reprenant directement le concept déjà posé sans être conçu le 8 septembre (Réflexions stratégiques, section 18). Les deux petits outils actuels ("Construire une identité"/"Tester l'identité") ont été explicitement qualifiés par Jean-Marc de **provisoires** — utiles aujourd'hui, pas destinés à survivre tels quels dans l'application finale.
|
||||
|
||||
**Périmètre de la compétence, fixé explicitement par Jean-Marc avant tout schéma :**
|
||||
- Sophia ne devient en aucun cas productrice de sites pour des clients tiers de l'entreprise — elle reste strictement dans le périmètre du CRM : le site produit est celui de l'entreprise qui utilise ASPIC elle-même.
|
||||
- Elle ne travaille qu'avec les documents de l'entreprise — mais en creusant ce point, aucune table réelle n'existe encore derrière les classeurs "Catalogue"/"Documents" (voir section 19 : classification actée, contenu non construit). Pour cette première version, elle travaille donc uniquement à partir de ce qui lui est fourni directement dans la conversation ; un outil de lecture du catalogue/documents réels est remis à plus tard, quand ces données existeront pour de bon.
|
||||
- Elle doit pouvoir mettre à jour un site déjà créé (retours clients, nouveaux produits).
|
||||
- Une fois ses créations validées, elle doit pouvoir les faire **publier** — mais la publication reste un acte humain déclenché par Jean-Marc, jamais un outil laissé entre les mains du modèle (même discipline que la clôture d'une Mission, jamais calculée automatiquement, section 18).
|
||||
|
||||
**Modèle de données.** Cinq tables créées dans `MS-DEV` (pas encore dans `MS-TST`, synchronisation manuelle à refaire le jour venu, les deux bases ne se répliquant pas automatiquement) :
|
||||
- `ASP_Competences` — catalogue curaté par Jean-Marc, même logique que le catalogue de consignes (section 15/18) : c'est le code (`mission_agent.php`), pas une donnée éditable en base, qui définit réellement ce qu'un outil fait.
|
||||
- `ASP_AgentsCompetences` — jonction agent/compétence.
|
||||
- `ASP_Missions` — objectif, statut (`ouverte`/`close`), collaborateur assigné, compétence mobilisée, site éventuellement lié, et un champ `MIS_Journal` (brouillon vivant, accumulé par `CONCAT`, même mécanique que `AGN_Experience`).
|
||||
- `ASP_SitesWeb` — un site par ligne, `SIT_NomDomaine` plutôt qu'un slug générique : Jean-Marc a d'emblée deux domaines réels en tête (`mevelia-solutions.bzh` pour la future agence, `aspic.bzh` pour le CRM lui-même).
|
||||
- `ASP_SitesWebFichiers` — métadonnées des fichiers d'un site, noms **prévisibles** (`index.html`, etc.) — volontairement différent du coffre-fort documentaire de la section 21 (noms randomisés) : là où un PDF doit rester inatteignable, un site web doit au contraire être servable.
|
||||
|
||||
**Convention de nommage imposée par Jean-Marc en cours de route :** chaque champ d'une table doit commencer par le préfixe de **sa propre** table, jamais celui de la table référencée par une clé étrangère — ex. dans `ASP_AgentsCompetences`, le champ pointant vers `ASP_Agents.AGN_Incr` doit s'appeler `AGC_AgentIncr`, pas `AGN_Incr`. Toutes les tables ont été (re)nommées en conséquence avant création.
|
||||
|
||||
**Clarification de fond sur `AGN_Identite`/`AGN_Experience`, apportée par Jean-Marc et qui affine la section 20 :** `AGN_Identite` est le profil fixe du collaborateur à l'embauche, avant toute mission — écrasable à volonté. `AGN_Experience` est ce qui se met à jour à la **clôture** d'une mission (pas l'identité, contrairement à ce que la section 20 laissait entendre). La mécanique de clôture elle-même (comment `MIS_BilanCloture` vient effectivement enrichir `AGN_Experience`) reste non codée à ce stade.
|
||||
|
||||
**Stockage — brouillon hors racine web, publication dans la racine.** Nouveau volume Docker `./sites_brouillons:/var/www/sites_brouillons` ajouté à `docker-compose.yml` (hors de tout chemin servi par Apache — aucune URL ne peut jamais l'atteindre, même principe que le coffre PDF de la section 21) ; `crm-app` recréé pour appliquer le volume (brève coupure de service). Un second dossier, `sites_publies`, vit lui À L'INTÉRIEUR du volume existant `./src:/var/www/html` — sans volume supplémentaire — puisqu'un site publié est, par nature, censé être atteignable par une URL.
|
||||
|
||||
**Incident de permissions, première fois que du code PHP écrit sur disque dans ce projet.** `/var/www/html` appartient à `1001:1001` (chown fait par la commande de démarrage du conteneur) mais Apache tourne en réalité en tant que `www-data` (uid 33, vérifié via `ps aux`) — sans droit d'écriture nulle part par défaut. Un `chmod 0777` a été posé spécifiquement sur les deux dossiers de stockage (`sites_brouillons` et `sites_publies`), jamais sur le reste de l'arborescence. Choix du `chmod` plutôt que d'un `chown` vers `www-data` : la commande de démarrage du conteneur refait un `chown -R 1001:1001 /var/www/html` à **chaque redémarrage**, ce qui aurait annulé un `chown` ciblé sur `sites_publies` (qui est sous `/var/www/html`) — un `chmod`, lui, n'est jamais touché par cette commande et survit donc aux redémarrages.
|
||||
|
||||
**`mission_agent.php` — la boucle agentique, fichier séparé de `collaborateur_dialogue.php`.** Décision explicite de ne jamais faire glisser le bac à sable sans effet de bord ("Tester l'identité") vers un endpoint qui écrit réellement sur disque. Différences clés avec `collaborateur_dialogue.php` :
|
||||
- L'historique complet des échanges (texte ET appels d'outils, format Anthropic) est conservé côté serveur (nouvelle colonne `ASP_Missions.MIS_HistoriqueJson`, ajoutée en cours de session — besoin technique découvert, pas anticipé dans le schéma initial), pas côté navigateur : une Mission doit être reprenable depuis n'importe quel ordinateur, exigence explicite de Jean-Marc (il travaille sur plusieurs machines).
|
||||
- Paquet d'outils fixé par compétence (`outilsDeLaCompetence()`), une seule câblée pour l'instant (`SITE_WEB`) : `lister_fichiers_site`, `lire_fichier_site`, `ecrire_fichier_site` — extensions autorisées limitées à `html/css/js/json/svg` (pas de PHP, pas d'exécutable ; pas d'images/binaire pour cette première version, complexité d'encodage remise à plus tard).
|
||||
- Sandbox fichiers : chemin relatif uniquement, résolution par `realpath()` vérifiée sous la racine du site (protection traversée de chemin), taille max 2 Mo par fichier.
|
||||
- Boucle plafonnée à 6 aller-retours d'outils par message, même discipline que `consigne_completer_code_postal()` (section 30) : ne jamais laisser un enchaînement s'emballer.
|
||||
- Chaque appel d'outil (réussi ou refusé) journalisé dans `MIS_Journal` — jamais un échec silencieux.
|
||||
- Création différée du site (`ASP_SitesWeb` + dossier physique) au tout premier `ecrire_fichier_site()` réussi, jamais à l'ouverture de la mission — pour ne pas laisser de site fantôme si une mission n'aboutit à rien.
|
||||
|
||||
**`sites_web.php` — publication, action humaine.** Liste les sites et leurs fichiers ; l'action `publier` vide le dossier publié puis le repeuple **uniquement** à partir des fichiers connus d'`ASP_SitesWebFichiers` (jamais une copie brute de dossier, qui traînerait un fichier orphelin). Le rattachement à un vrai nom de domaine (vhost Apache ou entrée dans `npm-app-1`) reste une étape manuelle de Jean-Marc, hors périmètre de cet endpoint.
|
||||
|
||||
**`missions.php`** — ouverture/liste des missions ; refuse explicitement la création si le collaborateur assigné n'a pas la compétence demandée.
|
||||
|
||||
**`mission_test.html`** — outil de mise au point interne (même esprit "terminal" que `contact_ia_test.html`), pas un écran utilisateur : le classeur "Missions" du bureau n'a toujours aucun écran réel (section 19), inutile de construire l'écran final avant que le mécanisme lui-même soit validé.
|
||||
|
||||
**Donnée d'amorçage.** Compétence `SITE_WEB` créée et attribuée à Sophia (`AGN_Incr = 13`).
|
||||
|
||||
**Premier essai réel.** Jean-Marc a d'abord tenté d'ouvrir `mission_test.html` en tapant l'URL directement, sans passer par l'écran d'identification — échec attendu ("Non identifié — veuillez vous connecter."), aucune session PHP ouverte : même règle que tous les autres écrans de l'application, rien de spécifique à cette fonctionnalité. Une fois connecté dans le même onglet, l'ouverture d'une mission a fonctionné : Sophia s'est montrée réactive, et a spontanément fait référence aux échanges précédents des sessions "Tester l'identité" — confirmation en conditions réelles que le mécanisme de mémoire (`AGN_Experience` réinjecté dans le prompt système de la mission) fonctionne comme prévu. Vérification détaillée de ce qu'elle a réellement écrit comme fichiers laissée à une prochaine session (Jean-Marc fatigué).
|
||||
|
||||
**Découverte en cours de route : du travail de la session précédente jamais poussé.** `git status` a révélé des modifications non committées antérieures à cette session (`collaborateur_dialogue.php`, `collaborateurs_identite.php`, `ecran_fond.html`, `version.php`, plus `collaborateur_experience_append.php` non suivi) — le chantier "collaborateurs" du 10 septembre (section 28/20) n'avait jamais été poussé sur GitHub. Signalé à Jean-Marc, décision de commit/push en attente.
|
||||
|
||||
**Statut.** Mécanisme construit et atteignable de bout en bout (tables, deux endpoints de gestion, la boucle agentique, un outil de test, une compétence réelle attribuée) ; premier échange réel validé comme cohérent et réactif. Points explicitement laissés ouverts :
|
||||
- Clôture de mission (`MIS_Statut`, `MIS_BilanCloture`, et le mécanisme concret d'enrichissement d'`AGN_Experience`) — non conçue en détail, non codée.
|
||||
- Lecture réelle du catalogue/documents de l'entreprise — dépend de classeurs encore vides (section 19).
|
||||
- Rattachement à un vrai nom de domaine une fois un site publié — étape d'infrastructure manuelle.
|
||||
- Support des images/fichiers binaires dans un site — non traité (texte uniquement pour l'instant).
|
||||
- Synchronisation du schéma vers `MS-TST` — pas encore faite.
|
||||
|
||||
`<code>` avance (tables + quatre nouveaux fichiers PHP/HTML + volume Docker) ; `<conception>` avance également, une nouvelle section (22) ouverte dans les Réflexions stratégiques pour la partie conceptuelle de cette même session — nouvelle version **V1.21.22**.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# 32. BackOffice — Collaborateurs, Compétences, Espaces disque et coût IA (11 septembre 2026)
|
||||
|
||||
**Origine.** En regardant le BO fonctionner (voir section 31), Jean-Marc a réalisé qu'il existe désormais deux univers distincts dans ASPIC : l'écran vu par l'utilisateur final, et toute la mécanique interne (identités des collaborateurs, compétences, missions-types) qui ne doit jamais lui être accessible. Décision : sortir ces outils de mise au point de l'écran des collaborateurs (`ecran_fond.html`) et leur donner une vraie maison — un **BackOffice** (terme repris de l'expérience Prestashop de Jean-Marc), esthétique volontairement minimale ("écran noir dans l'esprit du Terminal"), avec une règle de navigation précise : chaque application du BO, en se refermant, reste dans le BO (jamais un retour direct vers la CRM) ; Échap ne sort du BO que depuis son écran de menu, quand aucune application n'est ouverte.
|
||||
|
||||
## Point 1 — La coquille du BackOffice
|
||||
|
||||
**Accès.** Nouvelle colonne `MIRADOR.MIR_Users.MIR_BO` (O/N) — lue une seule fois par `aspic.php` à l'identification, posée en session (`$_SESSION['USR_BackOffice']`), relue par `preferences.php` (déjà appelé au chargement du bureau). Un bouton discret "BO" apparaît sur le bureau (près du logo ASPIC) uniquement pour les comptes autorisés, et renvoie vers `backoffice.html`.
|
||||
|
||||
**La coquille elle-même** (`backoffice.html`/`.css`/`.js`) : colonne de menu à gauche, logo + version en bas (même esprit que le bureau principal), et la règle Échap décrite plus haut, centralisée dans `initBackoffice()`.
|
||||
|
||||
**Collaborateurs** (`bo_collaborateurs.html`) : migration à l'identique de "Construire une identité"/"Modifier l'expérience"/"Tester l'identité", débranché d'`ecran_fond.html` (718 lignes retirées — CSS, HTML de l'écran plein cadre, et toute la logique JS associée). Vérification faite après coup : accolades CSS et JS toujours équilibrées, aucune référence orpheline aux identifiants supprimés.
|
||||
|
||||
**Compétences** (`competences.php`, `agents_competences.php`, `bo_competences.html`) : nouveau, catalogue (créer/lister) + attribution/retrait à un collaborateur. `AGN_Competences` (le champ dénormalisé prévu ensuite, voir "reste à faire") n'est volontairement pas encore câblé à ce stade.
|
||||
|
||||
**Bug trouvé et corrigé en cours de route (point 2, mais découvert ici) :** `MIR_Code` n'est pas une clé unique dans `MIR_Users` — "JMP Dev" et "JMP Tests" partagent le même `MIR_Code` ("JMP"). Une première version de `espace_utilisateur.php`/`espaces.php` cherchait par `MIR_Code`, ce qui aurait mélangé les deux comptes. Corrigé en utilisant `MIR_Email` comme clé partout (même colonne que la vérification de mot de passe dans `aspic.php`).
|
||||
|
||||
## Point 2 — Espaces disque
|
||||
|
||||
**Origine.** Jean-Marc voulait automatiser la création d'un espace disque privé par utilisateur, organisé par instance MySQL puis par utilisateur, avec des noms de dossiers illisibles pour un fouineur. Sa première proposition (SHA256 tronqué sur le nom de l'instance + numéro d'incrément) a été discutée et écartée : SHA256 est un hash **rapide**, donc cassable par dictionnaire dès que l'univers des noms possibles est petit et connu — ce qui est le cas ici (une poignée de noms d'instances/bases).
|
||||
|
||||
**Solution retenue** (`espace_utilisateur.php`) :
|
||||
- Dossier "tenant" (une base de travail) : **HMAC-SHA256 avec clé secrète** (`ESPACE_CLE_SECRETE`, nouvelle variable d'environnement) sur `host|baseNom` — déterministe (recalculable sans stockage), mais infaisable à deviner sans la clé. Reprend exactement le mécanisme déjà en place dans `prospects_core.php` pour les liens de suivi (`LIEN_DOC_CLE_SECRETE`, `hash_hmac`), avec sa propre clé dédiée.
|
||||
- Dossier "utilisateur" : jeton **aléatoire** (`random_bytes`), jamais dérivé d'un nom, généré une seule fois au premier besoin réel puis persisté (`MIR_Users.MIR_Espace`) — même principe de création différée que `creerSiteSiBesoin()` (voir section 31).
|
||||
- Stockage physique hors racine servie par Apache (nouveau volume Docker `./espaces_utilisateurs`), même principe que les brouillons de sites.
|
||||
|
||||
**Rassurance de Jean-Marc, anticipée avant même la construction :** inquiétude légitime de perdre l'accès à "son propre" dossier une fois les noms rendus illisibles. Réponse retenue : l'opacité protège d'un visiteur extérieur, jamais de l'administrateur qui interroge la base — d'où la page BO **"Espaces disque"** (`espaces.php`/`bo_espaces.html`), qui liste chaque utilisateur avec son chemin résolu, son statut (créé ou pas) et sa taille, plus un bouton "Provisionner" pour forcer la création immédiate.
|
||||
|
||||
**Testé réellement** : le dossier de "JMP Dev" existe désormais pour de vrai sur le disque (`/var/www/espaces_utilisateurs/{tenant}/{user}/`), jeton persistant confirmé en base.
|
||||
|
||||
**Explication donnée à Jean-Marc, pour lever un doute exprimé sur la navigation utilisateur :** ce mécanisme reste invisible du navigateur dans tous les cas — un futur accès à un fichier de cet espace passera par un endpoint dédié (URL du type `telecharger_fichier.php?id=42`), qui lit le fichier réel côté serveur et renvoie les octets, jamais un lien direct vers le chemin haché. Endpoint non construit à ce stade — seule l'architecture qui le rendra possible est posée.
|
||||
|
||||
## Point 3 — Cache de prompt et journalisation du coût IA (non planifié, ajouté en cours de session)
|
||||
|
||||
**Origine.** Jean-Marc a constaté plus de 20€ de consommation sur sa clé Anthropic sans pouvoir se l'expliquer. Deux réglages non optimisés identifiés en relisant le code :
|
||||
- Aucun cache de prompt : le prompt système (identité + expérience, ou identité + expérience + brief + outils pour une mission) était renvoyé et refacturé en entier à **chaque** appel — y compris chaque tour d'une même boucle d'outils (jusqu'à 6 par message dans `mission_agent.php`).
|
||||
- Aucune trace du coût réel dans l'application : ni `collaborateur_dialogue.php` ni `mission_agent.php` ne lisaient le champ `usage` pourtant renvoyé par l'API à chaque appel — la même préoccupation que celle qui avait mené à `_realisation`/`_avertissement` dans le moteur de consignes (7 septembre 2026), jamais appliquée ici jusqu'à ce soir.
|
||||
|
||||
**Corrections :**
|
||||
- `system` transmis en tableau de blocs avec `cache_control: ephemeral`, dans les deux fichiers.
|
||||
- Nouvelle table `ASP_AppelsIA` + `journal_ia.php` (tarifs vérifiés le 8 septembre 2026, ratios de cache documentés par Anthropic) : chaque appel réel (chaque tour de boucle inclus) est désormais journalisé avec ses vrais tokens et son coût estimé. Nouvelle page BO **"Coût IA"** (`appels_ia.php`/`bo_cout_ia.html`) : total général, répartition par origine, 50 derniers appels.
|
||||
|
||||
**Non vérifié en conditions réelles** : comme pour le reste de ces mécanismes, aucun appel réseau réel n'a pu être déclenché depuis l'environnement de développement — le calcul de coût est vérifié unitairement (test local avec des chiffres fictifs), mais le comportement réel du cache reste à observer sur le prochain essai de Jean-Marc.
|
||||
|
||||
## Découverte annexe, propre à l'usage de Claude Code (pas à ASPIC)
|
||||
|
||||
En discutant de ces 20€, Jean-Marc a réalisé que **cette conversation même** tourne sur la même clé/le même forfait que l'application — et qu'elle coûte, pour la même raison structurelle (API sans état, tout l'historique renvoyé à chaque tour) : plus un fil de conversation est long, plus chaque réponse coûte cher, indépendamment du sujet traité. Un seul appel de recherche web lancé ce soir a consommé 436 549 tokens à lui seul. Conclusion retenue par Jean-Marc : fermer une session Claude Code dès qu'un sujet aboutit plutôt que de laisser un fil grossir indéfiniment — voir la nouvelle consigne ajoutée à l'Index.
|
||||
|
||||
## Statut
|
||||
|
||||
Points 1 et 2 de la feuille de route "BackOffice" livrés et testés ; point 3 (`AGN_Competences`) reste à faire (voir "reste à faire"). Le point sur le cache/coût IA, non prévu au départ, a été traité en cours de session à la demande de Jean-Marc.
|
||||
|
||||
`<code>` avance (coquille BO complète, deux nouvelles paires endpoint/écran, mécanisme d'espace disque, cache + journalisation IA) ; `<conception>` avance également (nouvelle section 23 des Réflexions stratégiques, voir ce document) — nouvelle version **V1.22.23**.
|
||||
Reference in New Issue
Block a user