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.

8.3 KiB Raw Blame History