V1.19.21 Réflexions stratégiques et gestion de la personnalité des collaborateurs

journal/ASPIC - Journal. Index.md

@@ -59,7 +59,7 @@ Pour les trois documents de ce projet (ce journal — résumé/index —, les R
 - 29. Interprétation vocale des contacts par LLM
 - 30. Chantier des consignes — moteur générique
 
-*(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 — 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.)*
+*(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-10 septembre 2026)
 
@@ -121,7 +121,9 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
 
 **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**.
 
-**Prochain chantier annoncé par Jean-Marc : gérer les attributions de tâches des assistants.** L'écran 2 ("assistants") est désormais présenté (portraits, couleurs, rôles) mais ne porte encore aucune action réelle — à 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.
+**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**.
+
+**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).
@@ -138,7 +140,7 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
 - 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 assistants restent à documenter (mise à jour du 3 septembre limitée à l'écran d'accueil et à la liste des contacts ; l'écran assistants volontairement laissé de côté pour l'instant, tant qu'il ne porte aucune action réelle, voir 9-10 septembre) — l'outil de banque de dictées et le chantier des consignes n'ont volontairement pas vocation à y figurer pour l'instant, ce sont des chantiers internes, pas des modules utilisateur finalisés.
+- 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.**
@@ -153,6 +155,9 @@ Version incrémentée une seule fois pour l'ensemble de cette session (uniquemen
 - 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, clé API Anthropic) — faisabilité confirmée le 8 septembre 2026 (réflexions stratégiques, section 18), rien conçu ni codé à ce stade.
+- 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_Identite` au fil du temps (réflexions stratégiques, section 20) — intention actée, rien conçu ni codé à ce stade.
+- 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.

journal/ASPIC - Reflexions strategiques.md

@@ -341,3 +341,40 @@ Session sans aucune ligne de code applicative touchée — seule la partie `<con
 **Statut.** Décision actée et codée le soir même (voir journal, section 28, pour le détail des 9 classeurs et de leur position). Rien de plus engagé sur le contenu réel de chacun de ces classeurs (Missions, Propositions, Livraisons et Gestion n'ont, à ce stade, aucun écran ni donnée derrière eux — seul Contacts reste fonctionnel) : cette section fixe la classification cible, pas son implémentation fonctionnelle classeur par classeur, qui reste à construire un par un.
 
 Cette clarification du classement documentaire est jugée par Jean-Marc suffisamment structurante pour faire avancer la partie `<conception>` du numéro de version — `<code>` avait déjà avancé en tout début de cette même session (V1.17.18 → V1.18.18) pour le code produit ce soir sur l'écran des assistants ; cette section fait avancer `<conception>` de 18 à 19 : nouvelle version **V1.18.19**.
+
+## 20. Donner une identité aux collaborateurs — un chemin médian entre l'agent robotique et l'avatar-compagnon malsain (10 septembre 2026)
+
+**Origine — un mot qui ne convenait plus.** Jean-Marc a constaté que son propre discours avait glissé, sans décision explicite, d'« agents » à « assistants », et a voulu franchir une dernière étape terminologique : « collaborateurs ». **Choix assumé dès le départ : ce changement reste strictement un habillage côté utilisateur** — la table `ASP_Agents`, les colonnes `AGN_*` et `agents.php` ne sont pas touchés (« c'est notre cuisine interne », dans les mots de Jean-Marc) : seul le panneau de l'écran des collaborateurs change de libellé (« Bureau des assistants » → « L'équipe des collaborateurs »).
+
+**Le vrai sujet derrière le mot : quelle identité donner à ces cinq collaborateurs.** Jean-Marc a partagé une observation tirée de sa veille sur le secteur : deux écueils opposés dans la façon dont l'IA est présentée aujourd'hui — d'un côté l'« agent IA » présenté comme un outil technique impersonnel (peu engageant, difficile à déléguer sincèrement comme à un collègue), de l'autre des cas rapportés dans les médias d'avatars-compagnons IA créant une dépendance affective malsaine chez leurs utilisateurs. **Décision de principe : viser un chemin médian, délibérément à distance des deux extrêmes** — donner aux collaborateurs une identité humaine crédible (un visage réel via `AGN_Photo`, déjà en place ; un rôle professionnel concret plutôt qu'une étiquette générique, ex. Matilda passe d'« Administration » à « Assistante de direction ») sans jamais glisser vers un registre relationnel de type compagnon.
+
+**Le garde-fou de confidentialité, posé avant tout développement.** Jean-Marc a été explicite : le parcours de vie et la personnalité de chaque collaborateur (mémoire, expérience professionnelle, façon de voir les choses) ne doivent **jamais** être consultables tels quels par un utilisateur — seule une présentation synthétisée, dans les mots du collaborateur lui-même et selon son caractère propre, pourra un jour en être tirée, en dialogue. Ce principe structure directement l'architecture retenue (voir plus bas) : un champ dédié (`AGN_Identite`), lu par un endpoint séparé de l'endpoint public `agents.php`, jamais renvoyé à un écran utilisateur ordinaire.
+
+**Un trait de caractère assumé : des avis qui peuvent diverger.** Interrogé sur la possibilité que deux collaborateurs (ou un collaborateur et Jean-Marc lui-même) ne soient pas d'accord, Jean-Marc a répondu sans détour : « magnifique, la vraie vie ! » — un désaccord renforce, plutôt qu'il ne fragilise, la nécessité de trancher, rôle qui revient explicitement au « boss ». Point à retenir pour tout prompt système futur bâti sur ce mécanisme : la personnalité doit pouvoir influencer un ton, un jugement, une préférence — jamais neutraliser l'IA en une voix unique et consensuelle.
+
+**Opérationnalisé le soir même, directement sur l'écran des collaborateurs plutôt qu'en outil à part.** Jean-Marc a explicitement écarté une première piste (un outil interne séparé), de peur qu'un outil isolé « fasse passer à côté de plein de choses » : la mécanique retenue est intégrée à `ecran_fond.html` lui-même, deux boutons sous le panneau des collaborateurs :
+- **« Construire une identité »** — écran plein cadre, terminal de saisie repris tel quel d'un collaborateur à l'autre.
+- **« Tester l'identité »** — même écran, mais avec une vraie fenêtre de dialogue (façon session de chat), branchée sur l'API Anthropic (`ANTHROPIC_API_KEY`, acquise par Jean-Marc ce jour — apprentissage en cours de route : une clé « organisation » plutôt que liée à un espace de travail précis échoue sur l'API avec une erreur explicite, résolu en recréant la clé correctement scopée).
+
+**Un enseignement relevé en cours de route, qui dépasse ce seul écran : l'identité est un document vivant, pas une biographie figée.** Jean-Marc a corrigé une hypothèse implicite de Claude (« ce champ n'atteindra jamais sa limite de toute façon ») en rappelant l'intention de fond : l'expérience vécue par un collaborateur au fil de l'usage réel de l'application (missions menées, réunions, compétences acquises — voir la Mission, section 18) a vocation à venir **enrichir** son identité avec le temps, pas seulement la déclarer une fois pour toutes à l'embauche. Conséquence technique immédiate : la colonne `AGN_Identite`, initialement `TEXT` (65 535 octets), élargie le soir même en `MEDIUMTEXT` (16 777 215 octets) pour ne jamais devenir un plafond réel sur la durée de vie d'un collaborateur — avec un indicateur d'occupation ajouté à l'écran de saisie pour que ce plafond, même repoussé très loin, reste visible plutôt que découvert par surprise le jour où il serait atteint.
+
+**Statut.** Mécanisme construit, testé et validé par Jean-Marc en conditions réelles le soir même (« les deux outils fonctionnent parfaitement et passer de l'un à l'autre est vraiment idéal »). Premiers textes d'identité en cours de rédaction par Jean-Marc lui-même (Matilda déjà saisie), à la première personne plutôt qu'à la troisième — choix motivé par le fait qu'un texte écrit comme les propres notes intimes du collaborateur aide davantage le modèle à en adopter la voix qu'une biographie racontée de l'extérieur. Points laissés ouverts pour une prochaine session : le lien concret entre une Mission close (section 18) et l'enrichissement réel de `AGN_Identite` — non conçu, seule l'intention est actée ici — et le contenu même des cinq identités, encore à écrire.
+
+## 21. Stockage de documents utilisateur (PDF) — anticiper l'architecture et les risques avant le premier octet écrit (10 septembre 2026)
+
+**Origine.** Question posée par Jean-Marc en marge des échanges du jour, sans besoin immédiat identifié (« ce n'est pas que je pense saturer le champ aujourd'hui ») mais avec la conviction qu'il faudra, à un moment donné, permettre à un utilisateur d'ASPIC de stocker des PDF (documents commerciaux, contrats...) — et une inquiétude explicite sur les risques que ça peut ouvrir.
+
+**Les risques identifiés, par ordre d'importance réelle plutôt que d'intuition première.** Le danger le plus concret n'est pas « un PDF piégé qui infecte le serveur » (peu probable en pratique), mais l'exécution de ce qui est déposé : un fichier renommé en `.pdf` mais en réalité exécutable, s'il atterrit dans un dossier que le serveur web sait interpréter, ouvre une vraie brèche — d'où la nécessité de ne jamais faire confiance à l'extension ni au `Content-Type` envoyé par le navigateur (trivialement falsifiable), de vérifier la signature réelle du fichier (`%PDF-` en tête), et surtout d'empêcher toute exécution de script dans le dossier de stockage lui-même. Viennent ensuite : le risque de traversée de chemin si un nom de fichier fourni par l'utilisateur sert tel quel à construire un chemin serveur ; le fait qu'un PDF n'est pas un format inerte (JavaScript embarqué possible, à ne jamais ouvrir « en confiance » côté serveur) ; le contrôle d'accès (un document lié à un contact ne doit jamais être joignable par une URL directe devinable) ; et une limite de taille raisonnable pour éviter la saturation du disque du VPS.
+
+**La question posée explicitement par Jean-Marc : où stocker ces fichiers, dans un répertoire propre à chaque utilisateur, sans qu'il en connaisse le chemin exact ni même le nom réel sur le disque.**
+
+**Réponse retenue — la protection réelle n'est pas l'obscurité du chemin, c'est son inaccessibilité totale au navigateur.** Cacher un chemin (le rendre difficile à deviner) reste une protection secondaire et insuffisante prise seule — si un fichier reste malgré tout servi directement par le serveur web, un chemin fini toujours, tôt ou tard, par pouvoir être deviné, journalisé quelque part, ou exposé par une erreur de configuration. La vraie architecture retenue va plus loin que ce que Jean-Marc demandait littéralement, dans l'esprit de sa demande :
+- **Stockage hors de la racine servie par le serveur web** — le dossier de documents ne se trouve tout simplement pas dans l'arborescence qu'Nginx/Apache sait servir. Aucune URL directe ne peut donc jamais atteindre un fichier, quel que soit son nom ou son chemin.
+- **Tout accès passe par un endpoint PHP dédié**, sur le même principe que le reste d'ASPIC (`$_SESSION['USR_Code']` vérifiée avant toute lecture) — c'est lui, et lui seul, qui résout en interne quel fichier physique correspond à quel document, jamais le navigateur.
+- **En complément (défense en profondeur, pas le mécanisme principal) :** un sous-dossier par compte client, nommé par un identifiant interne opaque plutôt que par un code déjà visible ailleurs dans l'application ; et un nom de fichier généré aléatoirement sur le disque (le nom réel du document — celui que Jean-Marc ou son client voit à l'écran — ne vivant qu'en base, dans une table de métadonnées séparée du fichier lui-même). Cette organisation par compte a aussi un bénéfice direct pour le modèle SaaS envisagé (section 5) : un client = un dossier, facilement exportable ou supprimable en bloc.
+
+Dans cette architecture, peu importe finalement que Jean-Marc « connaisse » ou non le chemin ou le nom réel d'un fichier — la question ne se pose plus, puisqu'aucune voie d'accès ne passe jamais par là.
+
+**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**.

journal/ASPIC-Journal. 28. Ecran de fond.md

@@ -302,3 +302,52 @@ En parallèle du chantier ci-dessus, Jean-Marc a revu de son côté la répartit
 - Exploiter enfin `AGN_Couleur`, portée sur cet écran mais encore inutilisée par aucun affichage réel (post-its du tableau de liège, bulles de dialogue d'une future Mission).
 - Contenu réel des classeurs Missions, Propositions, Livraisons et Gestion — aucun écran ni donnée derrière à ce stade, seule la classification est fixée (voir réflexions stratégiques, section 19).
 - Reconstituer, si l'occasion se présente, le détail de la session intermédiaire (~7 septembre) qui avait fait passer d'un classeur unique à 9 classeurs — non fait, faute de matière, comme déjà noté le 8 septembre.
+
+
+## 10 septembre 2026 (soir) : "collaborateurs" — construire et tester l'identité de chaque assistant, premier dialogue réel avec l'API Anthropic (V1.19.21)
+
+*Réflexion stratégique associée : Réflexions stratégiques, section 20 (identité des collaborateurs — le chemin médian entre agent robotique et avatar-compagnon) ; section 21 (stockage de documents PDF, discussion architecturale indépendante de cette session technique, pas de code produit sur ce second sujet).*
+
+### "Assistants" → "collaborateurs" : habillage seul, confirmé
+
+Dans la continuité du glissement de vocabulaire déjà amorcé ("agents" → "assistants"), Jean-Marc a voulu franchir une dernière étape : "collaborateurs". Confirmé dès le départ comme un changement strictement côté présentation — `ASP_Agents`, les colonnes `AGN_*` et `agents.php` restent inchangés ("c'est notre cuisine interne") ; seul le libellé du panneau change ("Bureau des assistants" → "L'équipe des collaborateurs").
+
+### Deux outils plein écran, intégrés à l'écran des collaborateurs plutôt qu'en outil à part
+
+Jean-Marc a explicitement écarté l'idée d'un outil interne séparé (comme `dictees_test.php`/`contact_ia_test.html`), de peur qu'un outil isolé "fasse passer à côté de plein de choses" : les deux mécanismes suivants prennent la forme de deux boutons ajoutés sous le panneau des collaborateurs, chacun ouvrant un même overlay `#overlay-collab` en plein cadre (efface l'intégralité du bureau, y compris l'avant-plan), avec les 5 photos de collaborateurs en tête et un corps de fenêtre différent selon l'outil :
+
+- **"Construire une identité"** — sélection d'un collaborateur en tête, puis un grand terminal de saisie (`<textarea>`) pour écrire ou modifier son texte d'identité, boutons Abandonner/Valider. Écriture via l'endpoint `collaborateurs_identite.php` (nouveau, PUT sur `AGN_Identite`).
+- **"Tester l'identité"** — même sélection, puis une vraie fenêtre de dialogue façon session de chat (bulles utilisateur/collaborateur), branchée sur l'API Anthropic pour un dialogue réel avec le collaborateur choisi, prenant en compte l'identité déjà enregistrée. Bouton Fermer, retour à l'écran des collaborateurs dans les deux cas.
+
+`collaborateurs_identite.php` reste un endpoint interne (session ouverte suffisante, pas de contrôle par rôle — décision explicite de Jean-Marc tant qu'il reste seul utilisateur réel de l'application, à revoir le jour d'un second compte MIRADOR, voir en-tête du fichier) volontairement séparé d'`agents.php` : `AGN_Identite` n'est jamais renvoyée à l'écran des collaborateurs standard ni à aucun autre écran utilisateur — décision de confidentialité actée dès la conception (réflexions stratégiques, section 20) : le parcours de vie/la personnalité d'un collaborateur ne doit jamais être consultable tel quel, seule une présentation synthétisée par le collaborateur lui-même, en dialogue, pourra un jour en être tirée.
+
+### Bug critique trouvé par test automatisé avant livraison : la cascade CSS `[hidden]` perdait toujours face à `display:flex`
+
+Avant toute livraison, une vérification par navigateur headless (Playwright) a révélé un bug qui serait resté invisible à la seule relecture du code : `#overlay-collab{display:flex}` et `.overlay-collab-corps{display:flex}` — des règles d'auteur, nécessaires pour que l'overlay s'affiche correctement une fois ouvert — **l'emportaient systématiquement sur la règle native du navigateur `[hidden]{display:none}`, quelle que soit la spécificité du sélecteur**, parce que l'origine d'une règle (auteur vs agent utilisateur) prime sur la spécificité dans la cascade CSS. Conséquence en pratique : l'overlay plein écran restait **toujours affiché et interceptait tous les clics sur l'ensemble du bureau**, y compris avant toute ouverture volontaire, dès le chargement de la page — bug détecté quand un clic Playwright sur la flèche suivante a échoué avec un message explicite ("element intercepts pointer events", pointant vers `<div hidden="" id="overlay-collab">`). Corrigé par l'ajout de deux règles explicites `#overlay-collab[hidden]{display:none;}` et `.overlay-collab-corps[hidden]{display:none;}`, chacune commentée pour expliquer le mécanisme de cascade en cause — revérifié ensuite par un scénario Playwright complet (ouverture/fermeture des deux outils, lecture de `getComputedStyle().display` à chaque étape, aucune erreur JS).
+
+### `collaborateur_dialogue.php` — premier dialogue réel avec l'API Anthropic dans ASPIC
+
+Nouvel endpoint, sur le même schéma défensif que le reste du projet : session ouverte requise, méthode POST uniquement, `AGN_Incr` et l'historique de la conversation (`messages`) validés avant tout envoi. Prompt système construit dynamiquement à partir de `AGN_Prenom`/`AGN_Fonction`/`AGN_Identite`, avec des garde-fous explicites : le collaborateur reste un collègue professionnel, jamais un assistant IA générique ni une figure de compagnon ; il ne doit jamais réciter ni paraphraser son texte d'identité mot pour mot même si on le lui demande directement, toujours reformuler brièvement dans ses propres mots ; il peut avoir et exprimer des avis divergents de ceux de Jean-Marc ou d'un autre collaborateur (trait de caractère assumé, réflexions stratégiques section 20 : "magnifique, la vraie vie !"). Constantes : modèle `claude-sonnet-5`, `https://api.anthropic.com/v1/messages`, `anthropic-version: 2023-06-01`.
+
+**Incident de production réel, diagnostiqué et résolu le soir même.** Premier essai de Jean-Marc (dictée d'une identité pour Matilda, puis test du dialogue) : erreur HTTP 400 de l'API Anthropic, *"This API key is not scoped to a workspace, so this request must include the anthropic-workspace-id header..."* — diagnostiqué comme une clé API scopée "organisation" plutôt que liée à un espace de travail précis. Deux remèdes possibles proposés à Jean-Marc : recréer la clé en sélectionnant un espace de travail à la création (aucun changement de code), ou ajouter une variable d'environnement `ANTHROPIC_WORKSPACE_ID` (implémentée en secours dans le code, header `anthropic-workspace-id` ajouté seulement si cette variable est définie). Jean-Marc a choisi la première option ("Je propose de faire simple, recréer la clé !") — confirmée fonctionnelle immédiatement après ("Cela fonctionne parfaitement !").
+
+### Affinage de mise en page demandé après un vrai test en conditions réelles
+
+Une fois les deux outils validés en usage réel, Jean-Marc a demandé un resserrement précis de l'espace vertical disponible pour la saisie/le dialogue, point par point : titre "identité de..." remonté en haut de l'overlay, espace réduit entre ce titre et la ligne des 5 photos (photos et texte sous les photos non retouchés), haut de la fenêtre de saisie/dialogue remonté, boutons descendus au plus bas dans les deux outils, zone de saisie du message de "Tester l'identité" agrandie à deux lignes, boutons Envoyer et Fermer mis côte à côte plutôt que l'un sous l'autre. Traduit en CSS par un resserrement des paddings/marges du haut de l'overlay (`#overlay-collab` : 28px→10px de padding vertical ; titre et ligne de photos : marges basses réduites) et une restructuration du bloc de saisie du chat (`#chat-input` en bloc pleine largeur autonome plutôt que dans une ligne flexible partagée avec les boutons, `rows="2"`, boutons Fermer/Envoyer réunis dans la même ligne sous la zone de texte).
+
+### Capacité du champ `AGN_Identite` et indicateur d'occupation
+
+En testant, Jean-Marc s'est interrogé sur la capacité réelle du champ (`TEXT` MySQL à l'origine, 65 535 octets) — sans besoin de saturation identifié dans l'immédiat, mais avec l'idée d'ajouter un indicateur visuel par prudence. Claude a d'abord qualifié cette limite de "largement inatteignable", ce que Jean-Marc a corrigé : l'intention de fond est que l'identité d'un collaborateur **s'enrichisse avec l'usage réel de l'application** (missions menées, réunions, compétences acquises — voir la Mission, réflexions stratégiques section 18) plutôt que de rester une biographie figée écrite une fois pour toutes — ce qui change la nature de la question (un plafond qui semble haut aujourd'hui peut devenir réel sur la durée de vie d'un collaborateur). Conséquence actée le soir même : colonne élargie par Jean-Marc directement en base (`ALTER TABLE ASP_Agents MODIFY COLUMN AGN_Identite MEDIUMTEXT NULL DEFAULT NULL;`, 16 777 215 octets), et ajout d'un compteur d'occupation sous la zone de saisie de "Construire une identité" (`#compteur-identite`), recalculé à chaque frappe, comptant les octets réels au sens de l'encodage UTF-8 stocké en base (`utf8mb4`, via `TextEncoder`, pas un simple compte de caractères — un caractère accentué ou spécial pouvant occuper plusieurs octets) : affichage neutre en usage normal, orangé au-delà de 90% de la capacité, rouge et bouton "Valider" désactivé au-delà de la limite — garde-fou également revérifié côté JavaScript avant tout envoi, pas seulement affiché.
+
+### Fichiers touchés
+
+`ecran_fond.html` (refonte complète de la logique d'interaction de l'overlay collaborateurs — structure DOM, positionnement, ouverture/fermeture, correctif de cascade CSS, resserrement de mise en page, compteur d'occupation), `collaborateurs_identite.php` (nouveau — lecture/écriture de `AGN_Identite`), `collaborateur_dialogue.php` (nouveau — dialogue réel via l'API Anthropic). Côté base : colonne `AGN_Identite` ajoutée par Jean-Marc à `ASP_Agents` en `TEXT` puis élargie en `MEDIUMTEXT` le soir même (voir ci-dessus).
+
+### Statut en fin de session
+
+Les deux outils validés par Jean-Marc en conditions réelles ("les deux outils fonctionnent parfaitement et passer de l'un à l'autre est vraiment idéal"), après correction du bug de cascade CSS et de l'incident de clé API. `<code>` avancé en tout début de cette même session (V1.18.19 → V1.19.20) pour le code livré ce soir ; `<conception>` avancé deux fois au cours de la même session, de 19 à 21, pour l'ouverture des sections 20 et 21 des Réflexions stratégiques — nouvelle version **V1.19.21**.
+
+**Reste à faire, noté au passage :**
+- Rédaction des cinq textes d'identité eux-mêmes — Jean-Marc les écrit lui-même, à la première personne plutôt qu'à la troisième (choix motivé : un texte écrit comme les propres notes intimes du collaborateur aide davantage le modèle à en adopter la voix), Matilda déjà saisie via l'outil réel.
+- Lien concret entre une Mission close (réflexions stratégiques, section 18) et l'enrichissement réel de `AGN_Identite` au fil du temps — intention actée (section 20), rien conçu ni codé à ce stade.
+- Stockage de documents utilisateur (PDF) — réflexion architecturale actée (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é.