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

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**.