V1.23.24 Externalisation des prompts et évolutions des collaborateurs

journal/ASPIC - Reflexions strategiques.md

@@ -420,3 +420,24 @@ Dans cette architecture, peu importe finalement que Jean-Marc « connaisse » ou
 **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**.
+
+## 24. Quatre facettes de la mémoire d'un collaborateur, et sortir le patron du code (11 septembre 2026)
+
+**Origine.** En testant le panneau "Compétences" tout juste ajouté au BackOffice (voir journal de développement, section 33), Jean-Marc a attribué par jeu à Sophia la compétence "savoir faire un bon café" — et l'a vue, dans "Tester", la citer et la commenter comme n'importe quelle compétence réelle. Révélateur d'un flou plus large que ce seul bug : qu'est-ce qui distingue vraiment, dans la mémoire d'un collaborateur, ce qui relève du caractère, de la capacité, de l'histoire vécue et de la relation ?
+
+**Le modèle à quatre facettes, posé par Jean-Marc en cours d'échange.** Trois champs existaient déjà, chacun avec un rôle propre mais pas toujours net dans son esprit :
+1. **Identité** (`AGN_Identite`) — ce que la personne *est* : caractère, goûts, ce qui ne dépend pas de son emploi chez Jean-Marc.
+2. **Compétences** (`ASP_Competences`) — ce qu'**ASPIC lui apporte** comme capacité réelle, mécanique par nature (aucun effet sans câblage dans `mission_agent.php`, voir section 22) : *"même si personne n'arrive dans une boîte sans rien savoir faire, on n'est pas là pour faire le CV des collaborateurs !"*
+3. **Expérience** (`AGN_Experience`) — ce qui s'accumule par append au fil des dialogues réels, mémoire éditoriale sous contrôle de Jean-Marc (section 22).
+
+Restait un point sans case évidente : la dimension relationnelle envers l'équipe, jusque-là diluée dans l'identité de chacun — *"je ne sais pas où caser l'aspect relationnel avec l'équipe qui donne selon moi du sens à l'ensemble. Je l'ai mis jusqu'à présent dans l'identité, ce n'est pas complètement cohérent..."* Clarification retenue avec Claude : une posture relationnelle *initiale* (directe, réservée, chaleureuse...) est un trait de caractère comme un autre, mais la relation *vécue* se construit avec le temps — elle ressemble par nature à ce que l'Expérience capte déjà, plutôt qu'à un trait figé. Jean-Marc a néanmoins choisi d'ouvrir une quatrième facette dédiée (**`AGN_Relationnel`**, statique pour l'instant) plutôt que de forcer cette idée dans l'un des trois champs existants — la distinction reste plus nette pour lui à l'écriture, quitte à ce que la frontière avec l'expérience s'affine à l'usage.
+
+**Le café n'était pas un bug, mais un défaut de garde.** Diagnostic technique du symptôme de départ : `AGN_Identite`/`AGN_Experience` sont protégées dans le prompt par une consigne explicite ("aide-mémoire, jamais à réciter"), mais le bloc compétences ne l'était pas — un oubli de conception, pas une fatalité du modèle. Corrigé (détail au journal, section 33). Point de méthode qui en découle, généralisable : tout champ injecté dans un prompt système comme mémoire d'un collaborateur doit porter la même garde, faute de quoi il devient une donnée à réciter au lieu d'un aide-mémoire — l'oubli sur les compétences n'est probablement pas le dernier de ce genre.
+
+**Sortir les prompts eux-mêmes du code — même geste que les consignes, appliqué un cran plus haut.** Demande explicite de Jean-Marc, dans la foulée : *"j'aimerai bien que ces prompts ne soient plus dans le code mais me soient accessibles"* — étendue par lui à l'ensemble des quatre prompts IA du projet plutôt qu'au seul dialogue collaborateur. Même philosophie que le chantier des consignes (sections 15/17) et le catalogue de compétences (section 22) : ce qui relève du jugement de Jean-Marc plutôt que de la logique du programme ne doit pas vivre en dur dans un fichier PHP. Concrètement, une table `ASP_Prompts` et un mécanisme d'auto-amorçage (le texte d'origine, gardé en code comme filet, crée sa propre ligne en base au premier besoin réel) — détail complet au journal, section 33.
+
+**Le "aha" du prénom en dur — un premier pas concret vers un ASPIC réutilisable.** En écrivant le relationnel de Sophia (qui mentionne "le patron"), Jean-Marc a réalisé, de lui-même, un point resté invisible jusqu'ici : *"il n'est pas bon que mon prénom apparaisse dans le code si demain l'application est fournie à Joseph ou à Sylvie !"* Lien direct et explicite avec le troisième objectif fondateur d'ASPIC, la vente en SaaS (section 23) — jusqu'ici une intention lointaine, jamais confrontée à un détail concret d'implémentation. Toutes les occurrences de "Jean-Marc" réellement transmises à un modèle (dans les deux prompts système concernés, et dans le journal texte d'une mission) ont été remplacées par le prénom de la session en cours (`USR_Prenom`, déjà connu du système à l'identification) — aucune nouvelle donnée à saisir, juste arrêter de figer par erreur une donnée qui n'a jamais eu vocation à être fixe. Premier cas concret, mineur en soi, mais qui rend tangible une question qui restera à se poser systématiquement à mesure qu'ASPIC grandit : qu'est-ce qui, dans le code, suppose implicitement "Jean-Marc" comme seul patron possible ?
+
+**Statut.** Modèle à quatre facettes adopté et codé le soir même (voir journal de développement, section 33) ; prompts sortis du code pour les quatre cas réels du projet ; dé-figement du prénom du patron traité comme un premier cas d'école, pas comme un chantier de "multi-tenant" en soi — aucune autre donnée de ce type recherchée systématiquement à ce stade.
+
+`<code>` avance également au cours de cette même session (détail au journal de développement, section 33) — nouvelle version **V1.23.24**. Point de méthode noté au passage (voir Index) : `<conception>` est un compteur libre, incrémenté à chaque évolution jugée majeure — **il ne correspond pas** au numéro que prend la section ci-dessus dans ce document (24), malgré une coïncidence numérique fréquente ces derniers jours.