mirror of
https://github.com/JMP-MS/ASPIC.git
synced 2026-10-27 18:17:09 +00:00
V1.18.19 Mise en place des collaborateurs
This commit is contained in:
@@ -323,3 +323,21 @@ Version : `<code>` avait déjà avancé plus tôt dans cette même session de tr
|
||||
- Conception de l'écran de dialogue (mission dédiée, bulles, choix du modèle Anthropic) — faisabilité confirmée, rien conçu ni codé à ce stade.
|
||||
|
||||
Session sans aucune ligne de code applicative touchée — seule la partie `<conception>` du numéro de version avance, de 17 à 18, premier cas réel d'une session purement dédiée à la réflexion depuis l'instauration du format à trois niveaux (6 septembre 2026, section 15) : **V1.15.18**.
|
||||
|
||||
## 19. Refonte de la classification en 9 classeurs — aligner les catégories du bureau sur le cycle de vie réel d'une affaire (9-10 septembre 2026)
|
||||
|
||||
**Origine.** En marge du chantier de l'écran 2 ("assistants", voir journal de développement section 28), Jean-Marc a repris de son côté la liste des 9 classeurs physiquement posés sur le bureau — mise en place lors d'une session intermédiaire aux alentours du 7 septembre 2026, jamais formellement consignée ni comme décision stratégique ni dans le détail technique du journal (trou de documentation déjà relevé le 8 septembre, voir section 28 du journal). Cette première liste (Consignes, Contacts, Catalogue, Documents, Prospection, Réseaux, En-cours, Factures, Journalier) juxtaposait des catégories de nature hétérogène — des objets métier (Contacts, Factures), une étape de processus (Prospection, En-cours), un mécanisme interne (Consignes) et un attribut d'assistant qui n'a rien à faire dans une classification de documents (Réseaux, qui est en réalité `AGN_Fonction` de l'assistant Nikita) — sans qu'un principe de classement unique les relie.
|
||||
|
||||
**La nouvelle répartition, pensée comme le cycle de vie d'une affaire plutôt que comme un inventaire d'objets.** Jean-Marc a proposé une liste resserrée à neuf classeurs toujours, mais cette fois organisée dans l'ordre où une affaire se déroule réellement chez lui : **Catalogue** (la liste des prestations réalisables), **Documents**, **Contacts** (cumulant prospects et clients — un contact n'a plus besoin de changer de classeur en devenant client), **Missions** (en cours et réalisées), **Propositions**, **Livraisons**, **Factures**, **Journalier**, **Gestion**. Chaque classeur y a maintenant sa place dans une même logique de progression (de ce qu'on propose à ce qu'on facture), plutôt que de mélanger des objets et des étapes sans hiérarchie commune.
|
||||
|
||||
**Deux choix de fond, au-delà du simple renommage :**
|
||||
- **Contacts cumule prospects et clients.** Un même classeur pour tout le cycle de la relation — cohérent avec la donnée déjà en place côté base (aucune distinction structurelle entre prospect et client dans `ASP_Contacts`, seul le contenu réel des échanges le dit) : la classification suit ici la réalité déjà actée du modèle de données, plutôt que de recréer une frontière artificielle.
|
||||
- **Consignes disparaît de la vue "classeurs".** Cohérent avec la nature même de ce mécanisme (sections 14, 15, 17) : une consigne est un réglage du fonctionnement des assistants, pas un document ou une affaire à classer — elle n'avait sa place dans les classeurs du bureau que par un raccourci de mise en œuvre initiale, pas par nature. Elle continuera d'exister comme mécanisme (table `ASP_Consignes`, futur écran de gestion évoqué en section 15), simplement plus comme un classeur visible du bureau à l'ancienne.
|
||||
|
||||
**Une contrainte assumée, pas subie : rester dans la limite de 9 classeurs.** Jean-Marc s'est explicitement imposé de retrouver une classification cohérente sans dépasser le nombre de classeurs déjà physiquement dessinés sur l'avant-plan du bureau (section 28 du journal, image fixe fournie le 8 septembre) — la contrainte visuelle existante a été un guide pour la réflexion business, pas un obstacle à contourner en redessinant l'image.
|
||||
|
||||
**Répercussion technique, anticipée par construction plutôt que découverte après coup :** la conservation des 9 positions physiques exactes (mêmes coordonnées x1/x2/étiquette sur l'image de référence, seuls les libellés et identifiants changent) a permis un renommage sans aucune retouche de l'avant-plan. Un seul point de vigilance identifié et corrigé avant livraison, propre à ce changement précis : la pastille de comptage des contacts (`PASTILLE_CONTACTS_CENTRE_X`) était positionnée par une coordonnée **indépendante** du tableau des classeurs, calée sur l'ancienne 2ᵉ position — un renommage naïf des seuls libellés l'aurait laissée sous "Documents" au lieu de suivre "Contacts" à sa nouvelle 3ᵉ position. Voir journal de développement, section 28, pour le détail technique de cette correction.
|
||||
|
||||
**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**.
|
||||
|
||||
Reference in New Issue
Block a user