27 KiB
2. Modèle de données
Structure définitive reçue le 20 août 2026 (export SQL phpMyAdmin transmis par Jean-Marc, fichier "Tables V01.txt", puis version corrigée "Tables V02.txt" — voir corrections ci-dessous), qui remplace la version simplifiée utilisée pour le tout premier prototype (CRUD contacts minimal — CNT_Incr/CNT_Nom/CNT_Prenom/CNT_Mail — voir section 3-5 pour ce prototype initial, encore en place à ce stade). Cinq tables : ASP_Contacts, ASP_Annees, ASP_Statuts, ASP_Realisations, ASP_Actions.
Précision de vocabulaire importante : ASP_Realisations est la table qui journalise une ou plusieurs actions par contact (ce que ce journal appelait auparavant, de façon imprécise, "ASP_Actions" pour désigner la relation 1-N avec les contacts — voir sections 6-7 pour les mentions antérieures à corriger mentalement). ASP_Actions, elle, est la table de référence des types d'action possibles (gérée à la main), pas le journal des actions réalisées — confirmé par Jean-Marc le 20 août 2026.
Deux niveaux de commentaire distincts, à bien garder en tête pour l'écran de détail du contact (précisé par Jean-Marc le 21 août 2026, retour d'expérience terrain) : une action (ASP_Actions, le type) peut porter son propre commentaire générique décrivant l'action elle-même, ou pas — ex. "Création de la fiche" n'en a pas besoin, tandis que "Prospection automatisée sur LinkedIn 01" en a un décrivant les paramètres de recherche utilisés par ce type de prospection. Une réalisation (ASP_Realisations, l'instance concrète de cette action appliquée à un contact donné, à un moment donné) porte elle aussi son propre commentaire, spécifique à cette occurrence précise — ex. pour l'action "Modification de la fiche" (qui elle-même n'a pas de commentaire de type), une réalisation donnée pourra porter "Il a changé de portable" ou "L'entreprise a déménagé". Conséquence directe sur l'ergonomie de l'écran de détail du contact : la liste des réalisations sous les informations du contact ne pourra afficher que des éléments basiques par ligne (type d'action, date) — la saisie/consultation du commentaire d'une réalisation ne peut pas se faire "à la volée" dans la ligne, elle nécessite d'ouvrir un panneau dédié par-dessus le panneau contact (voir ci-dessous, empilement de panneaux). Objectif métier explicite derrière cette exigence : pouvoir retrouver rapidement de petits détails de la vie professionnelle d'un contact (ex. une panne machine mentionnée par le contact) constitue un vrai avantage relationnel en usage terrain (un autre commercial qui relance le contact quelques semaines plus tard peut y faire référence) — ce n'est pas une complexité gratuite, c'est une fonctionnalité voulue et mûrement réfléchie. ⚠️ Mise à jour du 23 août 2026 : cette sous-liste des réalisations, bien qu'ergonomiquement pensée dès le départ, est finalement retirée du périmètre de la première version de l'écran de détail — voir section 6, "Précisions du 23 août 2026 (suite de session)". L'analyse ci-dessus reste valable pour le jour où cette fonctionnalité sera reprise.
Empilement de panneaux pour l'écran de détail du contact — principe validé (21 août 2026) : panneau contact ouvert depuis la liste (par-dessus l'écran liste des contacts, lui-même plein écran), avec édition directe des champs basiques (nom, prénom, etc.) dans ce même panneau ; un second panneau, ouvert par-dessus le premier, pour ajouter/consulter une réalisation (avec son commentaire propre à l'occurrence). Deux niveaux d'empilement jugés raisonnables et cohérents avec le principe déjà en place "Échap ferme le panneau le plus prioritaire d'abord" (voir section 6), qui s'adapte naturellement à un empilement à plusieurs niveaux sans mécanisme nouveau à inventer. Point de vigilance pour la suite (pas encore tranché) : si une action lancée depuis une réalisation nécessitait elle-même un troisième niveau de panneau, mieux vaudra chercher une alternative (fermer un panneau parent, remonter l'information) plutôt que d'empiler à trois — au-delà de deux niveaux, le risque de perte de repère pour l'utilisateur devient significatif. ⚠️ Mise à jour du 23 août 2026 : le second niveau de panneau (réalisation) est reporté — voir section 6. L'écran de détail du contact reste à un seul niveau d'empilement pour l'instant (visualisation/modification comme deux états du même panneau, pas deux panneaux distincts).
Documentation utilisateur ASPIC — démarrée (21 août 2026). Jean-Marc a validé l'idée d'une documentation utilisateur tenue en parallèle du journal de développement, alimentée par les explications fonctionnelles qu'il donne au fil de l'eau (au-delà des simples instructions de gestion de données ou d'écrans) — utile pour ASPIC, mais surtout vu comme un vrai avantage concurrentiel pour ses futurs projets clients (documentation utilisateur rarement livrée par les prestataires, faute de temps). Nouveau document créé dans le projet : "ASPIC - Documentation utilisateur.md", langage utilisateur uniquement (aucun détail technique), organisé par écran. Premier jet couvrant l'écran d'identification et l'écran liste des contacts livré le 21 août 2026, à compléter au fur et à mesure des écrans suivants. Convention retenue : Claude reconnaît de lui-même le contenu à vocation "doc utilisateur" dans les explications fonctionnelles de Jean-Marc (comme celle sur les réalisations/actions ci-dessus) et propose l'extrait correspondant pour validation ; Jean-Marc garde la possibilité d'utiliser une balise explicite (ex. #Utilisateur#) pour lever toute ambiguïté si besoin, mais ce n'est pas la convention par défaut.
Réflexion sur la capitalisation des méthodes de travail ASPIC pour de futurs projets (21 août 2026). Jean-Marc souhaite, une fois ASPIC "ficelé", pouvoir réutiliser l'ensemble des conventions mises en place ici (choix technique PHP+MySQL+JS vanilla sans framework, structure des écrans en panneaux empilés sur fond plein écran, conventions de nommage/livraison de fichiers, discipline de test systématique avant livraison, pattern de mutualisation des assets, mode de secours "double mode", tenue d'un journal de développement) pour de futurs projets, via un mécanisme de "compétence" (skill) — pouvoir dire "on part sur le modèle ASPIC" et que cela porte l'ensemble de ces conventions, avec la possibilité d'avoir plusieurs modèles différents à l'avenir (ex. une interface plus soignée graphiquement). Explications données par Claude : une compétence est un ensemble d'instructions packagées que Claude charge quand c'est pertinent ; Claude ne peut pas créer/enregistrer une compétence directement dans une session (limite technique de l'environnement), mais peut rédiger un fichier de compétence (SKILL.md ou .skill) et le transmettre à Jean-Marc en téléchargement pour qu'il l'enregistre lui-même dans son compte. Décision : à faire plus tard, une fois les conventions ASPIC plus éprouvées (plusieurs écrans supplémentaires construits), plutôt que de figer un modèle encore incomplet — le journal actuel sert déjà de matière première brute pour cette future extraction. À reprendre quand Jean-Marc estimera ASPIC suffisamment abouti pour ça.
Méthode retenue pour la conception de l'écran de détail (21 août 2026) : Jean-Marc fournira une maquette approximative (structure, regroupement des champs, pas nécessairement au format exact d'un écran) accompagnée d'instructions textuelles de dimensionnement par référence à l'existant déjà codé et validé (ex. "la ligne 3 à la même hauteur que la ligne X de liste_contacts.html") plutôt qu'une maquette pixel-perfect. Approche jugée plus fiable qu'une maquette isolée : elle s'appuie sur le vocabulaire de mesures déjà en place dans le code (hauteur de ligne 16px, bandeau de titre 12px avec son padding, tailles de police 10-12px selon contexte) et préserve la cohérence visuelle entre écrans, plutôt que de risquer d'introduire involontairement une valeur légèrement différente de l'existant.
Table ASP_Contacts
CREATE TABLE `ASP_Contacts` (
`CNT_Incr` int NOT NULL AUTO_INCREMENT,
`CNT_Code` varchar(15) DEFAULT NULL,
`CNT_Nom` varchar(40) NOT NULL,
`CNT_Prenom` varchar(40) DEFAULT NULL,
`CNT_Statut` varchar(3) DEFAULT NULL,
`CNT_Société` varchar(40) DEFAULT NULL,
`CNT_Service` varchar(40) DEFAULT NULL,
`CNT_Fonction` varchar(40) DEFAULT NULL,
`CNT_AdrLig1` varchar(40) DEFAULT NULL,
`CNT_AdrLig2` varchar(40) DEFAULT NULL,
`CNT_AdrLig3` varchar(40) DEFAULT NULL,
`CNT_AdrCP` varchar(6) DEFAULT NULL,
`CNT_AdrVille` varchar(40) DEFAULT NULL,
`CNT_SIRET` varchar(20) DEFAULT NULL,
`CNT_Tel` varchar(15) DEFAULT NULL,
`CNT_Portable` varchar(15) DEFAULT NULL,
`CNT_Mail` varchar(40) DEFAULT NULL,
`CNT_Notes` text,
`CNT_CodeProfession` int DEFAULT NULL,
`CNT_Actif` tinyint(1) NOT NULL DEFAULT '1',
PRIMARY KEY (`CNT_Incr`),
KEY `CNT_Statut` (`CNT_Statut`),
KEY `CNT_CodeProfession` (`CNT_CodeProfession`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
⚠️ Champ CNT_CodeProfession ajouté le 23 août 2026 (voir "Table ASP_Professions, nouvelle le 23 août 2026" plus bas dans cette section pour le détail de la table référencée et la décision d'ergonomie associée) — la position exacte de la colonne dans la vraie table (avant ou après CNT_Notes) n'a pas été précisée par Jean-Marc, celle indiquée ci-dessus est une supposition raisonnable, sans incidence pratique puisque les requêtes nomment toujours leurs colonnes explicitement. Index KEY CNT_CodeProfession ajouté par Jean-Marc le même jour (ALTER TABLE transmis, aux côtés d'un rappel de la PRIMARY KEY et de la KEY CNT_Statut déjà en place) — cohérent avec l'index déjà présent sur CNT_Statut pour la même raison (colonne de type "référence vers table gérée à la main", potentiellement utile en filtre/tri à l'usage).
Règles métier précisées par Jean-Marc (20 août 2026) :
- CNT_Code : code composite auto-généré à la création du contact, format
xxx-yyyyzzz(ex. VSX-20654). xxx = code de l'année de création, lu dans ASP_Annees (table gérée à la main, donc une simple lecture, pas un calcul). Logique du code année (révélée par Jean-Marc, 20 août 2026) : V (pour "Vingt") + première lettre du chiffre des unités + dernière lettre de ce même chiffre, le tout prononcé "Vingt-[chiffre]". Ex. 2026 = Vingt-Six → V-S-X ; 2027 = Vingt-Sept → V-S-T ; 2028 = Vingt-Huit → V-H-T. Amusant, mais sans incidence sur le code à écrire puisque c'est une table gérée à la main (simple lecture en base, pas de formule à implémenter). yyyy = CNT_Incr du contact, sans zéro de tête. zzz = nombre aléatoire entre 1 et 999, toujours sur exactement 3 caractères, zéro-padé (ex. 001, 005, 654 — confirmé explicitement par Jean-Marc le 20 août 2026 : "005 et pas 5"). Comme CNT_Incr est déjà unique de par l'auto-increment, la partie xxx-yyyy suffit déjà à garantir l'unicité du code ; le suffixe zzz n'a donc pas de rôle d'unicité, seulement un rôle d'obfuscation/lecture. Point d'implémentation à garder en tête : CNT_Code dépend de CNT_Incr, qui n'est connu qu'après l'INSERT (auto-increment) — la génération du code se fera donc en deux temps (INSERT puis UPDATE juste après avec le code calculé à partir de lastInsertId()), pas en un seul INSERT. - CNT_Actif : tinyint(1), 1 = actif, 0 = supprimé (suppression logique — voir section 6). Valeur par défaut à 1 confirmée dans la structure V02 (
DEFAULT '1') — chaque nouveau contact est actif sans qu'il faille y penser à chaque INSERT. Toujours ajouterWHERE CNT_Actif = 1dans les requêtes d'affichage. - CNT_AdrCP : varchar(6), donc capable de stocker un zéro de tête ("06110") — mais Jean-Marc signale un problème récurrent constaté par expérience : ce champ se retrouve parfois amputé de son zéro de tête (typiquement lors d'un import Excel, qui traite spontanément un code postal comme un nombre). Conséquence concrète : un CP stocké "6110" au lieu de "06110" fausse le tri par code postal et fausse le département affiché en liste (voir ci-dessous). Point de vigilance pour l'import et la saisie : toujours traiter CNT_AdrCP comme du texte, jamais comme un nombre, et le remettre à 5 caractères avec un zéro de tête si besoin (LPAD en SQL, ou validation à la saisie). Le même risque existe en théorie sur CNT_Tel et CNT_Portable (numéros français commençant aussi par 0) — à garder en tête sur les mêmes imports.
- Dépt (colonne affichée dans l'écran liste des contacts, section 9) = les 2 premiers caractères à gauche de CNT_AdrCP (LEFT(CNT_AdrCP, 2)). Directement impacté par le point ci-dessus : un CP tronqué de son zéro de tête donnerait un département faux.
- Pas de gestion de contacts à l'étranger, ni de multi-contacts par entreprise : choix assumé de Jean-Marc, cohérent avec la structure de ses futurs clients visés (petites structures). Les informations de société (CNT_Société, CNT_Service, CNT_Fonction) sont donc stockées directement dans la fiche contact plutôt que dans une table société séparée. Modifiable plus tard si besoin, mais pas une priorité.
- Création d'un contact → création automatique d'un enregistrement dans ASP_Realisations (date+heure, code user, code action CRE_CNT) — même logique prévue pour les autres actions (modification, suppression, etc.). Détail du mécanisme à définir au moment venu.
Table ASP_Annees (gérée à la main)
CREATE TABLE `ASP_Annees` (
`ANN_Année` int DEFAULT NULL,
`ANN_Code` varchar(3) DEFAULT NULL,
UNIQUE KEY `ANN_Année` (`ANN_Année`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Table de correspondance année → code à 3 lettres utilisé dans CNT_Code (ex. 2026 → VSX, 2027 → VST — voir la logique de construction ci-dessus). Alimentée à la main par Jean-Marc, une ligne par nouvelle année.
Table ASP_Statuts (gérée à la main)
CREATE TABLE `ASP_Statuts` (
`STA_Incr` int NOT NULL AUTO_INCREMENT,
`STA_Code` varchar(3) NOT NULL,
`STA_Libellé` varchar(20) NOT NULL,
PRIMARY KEY (`STA_Incr`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Table de référence des statuts de contact possibles (référencée par CNT_Statut). Suggestion Claude, non urgente vu le volume et la gestion à la main : ajouter une contrainte UNIQUE sur STA_Code pour éviter la création accidentelle d'un code en double.
Table ASP_Professions (nouvelle, créée par Jean-Marc le 23 août 2026, gérée à la main comme ASP_Statuts/ASP_Actions)
CREATE TABLE `ASP_Professions` (
`PRF_Incr` int NOT NULL,
`PRF_Libelle` varchar(40) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
ALTER TABLE `ASP_Professions`
ADD PRIMARY KEY (`PRF_Incr`),
ADD KEY `PRF_Libelle` (`PRF_Libelle`);
ALTER TABLE `ASP_Professions`
MODIFY `PRF_Incr` int NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=23;
Table de référence des professions possibles pour un contact (déjà peuplée — AUTO_INCREMENT=23 indique 22 lignes existantes). Liée à ASP_Contacts via CNT_CodeProfession = PRF_Incr (lien applicatif, pas de contrainte FOREIGN KEY SQL — cohérent avec le principe déjà en place pour CNT_Statut/ASP_Statuts, aucune table de référence d'ASPIC n'a de FK SQL formelle à ce stade). Suggestion Claude, non urgente, même logique que pour STA_Code/ACT_Code : une contrainte UNIQUE sur PRF_Libelle éviterait la création accidentelle d'un libellé en double.
Décision d'ergonomie associée (23 août 2026) : dans l'écran de détail du contact, CNT_CodeProfession sera saisi via une liste déroulante alimentée par ASP_Professions (même principe que pour un futur champ Statut lié à ASP_Statuts) plutôt qu'un champ texte libre. La Profession n'est pas ajoutée à l'écran liste des contacts (ni colonne ni filtre) — Jean-Marc a explicitement tranché contre, pour ne pas alourdir cet écran déjà considéré abouti (voir section 9) ; réservée à l'écran de détail pour l'instant, réévaluable plus tard si le besoin se confirme.
Exception à la règle "table gérée à la main" — création d'une profession depuis le formulaire contact (demandée le 23 août 2026). Contrairement à ASP_Statuts et ASP_Actions (ensembles fermés, gérés uniquement via phpMyAdmin), ASP_Professions est une liste plus ouverte, amenée à grandir avec l'usage : Jean-Marc a demandé la possibilité de créer une nouvelle profession directement depuis le formulaire du contact (mode modification, et mode ajout d'un nouveau contact), sans repasser par phpMyAdmin. Choix d'ergonomie retenu : un dernier choix « + Nouvelle profession… » en bas de la liste déroulante des professions ; le sélectionner fait apparaître un petit champ texte juste en dessous, dans le même panneau (pas de panneau superposé supplémentaire — cohérent avec la discipline des deux niveaux d'empilement maximum, section 2, et avec l'abandon de la sous-liste des réalisations pour la même raison). Valider (Entrée ou petit bouton) crée la ligne dans ASP_Professions (INSERT PRF_Libelle, récupération de lastInsertId()) et sélectionne aussitôt la nouvelle profession créée pour le contact en cours d'édition. Reste à préciser au moment de l'implémentation : l'endpoint API à créer pour cette création (probablement un petit professions.php avec GET liste / POST création, sur le même modèle que contacts.php) et la gestion d'un doublon de libellé (ASP_Professions n'a pas de contrainte UNIQUE sur PRF_Libelle à ce stade — voir suggestion Claude ci-dessus).
Table ASP_Realisations (journal des actions réalisées sur un contact) — structure corrigée, version V02 (20 août 2026)
CREATE TABLE `ASP_Realisations` (
`REA_Incr` int NOT NULL AUTO_INCREMENT,
`REA_IncrContact` int NOT NULL,
`REA_CodeUser` varchar(3) NOT NULL,
`REA_Date` datetime NOT NULL,
`REA_Action` varchar(20) NOT NULL,
`REA_Comment` text,
PRIMARY KEY (`REA_Incr`),
KEY `REA_CodeUser` (`REA_CodeUser`) USING BTREE,
KEY `REA_Action` (`REA_Action`) USING BTREE,
KEY `REA_Date` (`REA_Date`) USING BTREE,
KEY `REA_IncrContact` (`REA_IncrContact`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Une ligne par action réalisée sur un contact (REA_IncrContact référence CNT_Incr ; REA_Action référence ACT_Code de ASP_Actions ; REA_Date inclut l'heure pour préserver la chronologie à l'affichage, comme demandé par Jean-Marc).
⚠️ Incohérence corrigée le 23 août 2026 (repérée par Jean-Marc) : REA_Action était en varchar(3) alors qu'il référence ACT_Code (ASP_Actions), lui-même en varchar(15) — une valeur de code action de plus de 3 caractères (ex. "CRE_CNT", "MAJ_CNT", "REL_TEL", déjà plus longs que 3 caractères dans les données peuplées de ASP_Actions, voir plus bas) aurait donc été tronquée silencieusement à l'insertion. Corrigé : REA_Action passe en varchar(15), aligné sur ACT_Code. ⚠️ Longueur à nouveau élargie le 26 août 2026 : REA_Action, ACT_Code et OPE_Action (voir section 18) passent tous à varchar(20), et ACT_Libelle à varchar(40), pour accueillir les codes plus longs introduits avec la prospection (ex. WEB-FORM-001-CRE). Point de vigilance pour la suite : toujours vérifier qu'un champ de liaison (FK applicative, sans contrainte SQL formelle — voir le principe déjà en place pour CNT_Statut/CNT_CodeProfession) a bien la même longueur que la colonne qu'il référence, ASPIC n'ayant pas de contrainte FOREIGN KEY SQL pour le détecter automatiquement.
✅ Points de vigilance identifiés en revue par Claude sur la V01 (20 août 2026), tous corrigés par Jean-Marc et confirmés dans la V02 transmise le même jour :
UNIQUE KEYsur REA_CodeUser était très probablement une erreur de configuration : tel quel, un même code utilisateur n'aurait pu apparaître qu'une seule fois dans toute la table. Corrigé en V02 : c'est désormais un index simple (KEY ... USING BTREE), comme REA_Action.UNIQUE KEYsur REA_Date aurait interdit à deux actions d'être journalisées à la même seconde. Corrigé en V02 : index simple également.- Absence d'index sur REA_IncrContact, alors que c'est la colonne la plus utile à indexer (retrouver l'historique d'un contact donné depuis l'écran de détail,
WHERE REA_IncrContact = ?). Corrigé en V02 :KEY REA_IncrContact (REA_IncrContact)ajouté. - Coquille détectée dans le fichier SQL transmis ("Tables V01.txt") : juste avant le bloc
ALTER TABLE ASP_Realisations ... AUTO_INCREMENT, la ligne de commentaire était--nau lieu de--(tiret-tiret-espace), ce qui aurait pu provoquer une erreur de syntaxe MySQL si ce fichier avait été rejoué tel quel. Corrigé en V02. - CNT_Actif sans valeur par défaut — voir ci-dessus dans ASP_Contacts. Corrigé en V02 (
DEFAULT '1').
Retour de Jean-Marc sur cette revue : "bien vu d'ailleurs !" — confirmation que cette étape de revue technique (au-delà de la structure fonctionnelle) apporte de la valeur et est à reproduire sur les prochaines évolutions de schéma.
Table ASP_Actions (référence des types d'action, gérée à la main, déjà peuplée)
CREATE TABLE `ASP_Actions` (
`ACT_Incr` int NOT NULL AUTO_INCREMENT,
`ACT_Code` varchar(20) NOT NULL,
`ACT_Libelle` varchar(40) NOT NULL,
`ACT_Comment` text NOT NULL,
PRIMARY KEY (`ACT_Incr`),
KEY `ACT_Code` (`ACT_Code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
⚠️ Contenu corrigé le 24 août 2026 — Jean-Marc a changé les codes d'action en base sans le journaliser sur le coup ("je te confirme que j'ai changé les codes des actions, j'aurais dû te le dire"). Contenu réel de ASP_Actions, communiqué par Jean-Marc le 24 août 2026, complété le 26 août 2026 avec les codes de prospection (voir section 18) :
| ACT_Incr | ACT_Code | ACT_Libelle |
|---|---|---|
| 1 | CNT_CRE |
Création du contact |
| 2 | CNT_MAJ |
Mise à jour du contact |
| 3 | CNT_SUP |
Suppression du contact |
| 4 | CNT_TELS |
Appel Téléphonique Sortant |
| 5 | CNT_TELE |
Appel Téléphonique Entrant |
| 9 | WEB-FORM-001-CRE |
Web Form 001. Le prospect s'enregistre |
| 10 | WEB-FORM-001-VER |
Web Form 001. Vérification du mail |
| 11 | WEB-FORM-001-VAL |
Web Form 001. L'adresse mail est validée |
| 12 | WEB-FORM-001-DOC |
Web Form 001. Viktor envoie la doc |
| 13 | WEB-FORM-001-LEC |
Web Form 001. Le prospect lit la doc |
Point de vigilance à valeur générale : une table de référence gérée à la main (ASP_Actions, ASP_Statuts, ASP_Professions, ASP_Campagnes, ASP_Docs) peut être modifiée directement en base sans que Claude en soit informé, puisqu'ASPIC n'a pas de mécanisme de synchronisation — à signaler explicitement à Claude dès qu'un changement de ce type est fait, plutôt que de compter sur le journal pour rester à jour tout seul.
Suggestion Claude, non urgente : ajouter une contrainte UNIQUE sur ACT_Code, même logique que pour STA_Code ci-dessus.
Table ASP_Users (état validé le 19 août 2026, à des fins d'authentification)
CREATE TABLE `ASP_Users` (
`USR_Code` varchar(3) NOT NULL,
`USR_Nom` varchar(40) NOT NULL,
`USR_MDP` varchar(15) NOT NULL,
`USR_RatioPanneauContact` tinyint UNSIGNED NOT NULL DEFAULT '100',
`USR_RatioPanneauProspect` tinyint UNSIGNED NOT NULL DEFAULT '100',
PRIMARY KEY (`USR_Code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
⚠️ Structure mise à jour le 25 août 2026 : Jean-Marc a ajouté les deux colonnes USR_RatioPanneauContact/USR_RatioPanneauProspect (voir section 17) directement en base, DEFAULT '100' conformément à la décision prise le même jour. Deux comptes existent à ce stade dans la table (dont JMP) — contenu des lignes volontairement non reporté ici (mots de passe en clair, voir ci-dessous). Troisième compte, Vik (Viktor, premier assistant IA de Jean-Marc), créé le 26 août 2026 — voir section 18 : sert d'identité pour la journalisation automatique des opérations sur les prospects et comme expéditeur des mails, sans usage réel de mot de passe à ce stade (aucune authentification effective des scripts publics de prospection).
⚠️ Nouvelle colonne USR_Societe ajoutée le 29 août 2026 (varchar(40) DEFAULT NULL, gérée à la main comme le reste de ASP_Users) — voir section 22 pour le détail complet (badge de repérage d'environnement dans le bandeau applicatif de liste_contacts.html).
Correspondance avec l'écran d'identification (section 8) : le champ "Identifiant" du formulaire de connexion correspond à USR_Code (code utilisateur court, 3 caractères), pas à USR_Nom. Correspondance également avec REA_CodeUser (ASP_Realisations) et OPE_CodeUser (ASP_Operations, section 18) qui référencent ce même code. ⚠️ Ce paragraphe est désormais un historique : depuis le 30 août 2026 (section 24, MIRADOR), le champ d'identification correspond à MIR_Email, plus à USR_Code — voir cette section.
Décisions prises (19 août 2026) sur les deux points remontés en relecture :
- PRIMARY KEY ajoutée sur USR_Code par Jean-Marc — la table a désormais une vraie clé primaire, cohérent avec ASP_Contacts.
- Mot de passe stocké en clair (USR_MDP), assumé consciemment. Choix délibéré de Jean-Marc pour rester agile sur une application strictement interne, avec une gestion des utilisateurs faite directement en phpMyAdmin (pas de module ajout/modification/suppression d'utilisateur dans ASPIC). Ce compromis serait à revoir si ASPIC est un jour proposée à un client externe (cf. section 1, portée). Voir section 21 : ce compromis est effectivement revu le 28 août 2026, avec l'arrivée de MIRADOR et de futurs bêta testeurs externes. Et section 24 : USR_MDP n'est plus du tout consulté par le code depuis le 30 août 2026, devenu un vestige à retirer quand Jean-Marc le souhaite.
À faire : table ASP_Contacts_SaisieWeb pour le formulaire web public — idée initiale du 19 août, finalement remplacée par le modèle ASP_Prospects/ASP_Campagnes/ASP_Operations (voir section 11, 17 et 18).
Convention de nommage des fichiers en production (précisée le 21 août 2026) : les écrans front, livrés par Claude sous des noms descriptifs/versionnés (ex. ASPIC_ecran_identification.html, aspic_liste_contacts.html), sont renommés par Jean-Marc au moment du transfert FTP vers le serveur, sans préfixe décoratif et en .php par uniformité avec le reste de l'application (même si ces fichiers ne contiennent aujourd'hui aucun code PHP — un .php sans balise <?php ?> est servi à l'identique par Apache+PHP, aucun changement de contenu requis) : ASPIC_ecran_identification.html → identification.php, aspic_liste_contacts.html → liste_contacts.php. login.php garde déjà son nom final. Jean-Marc conserve de son côté un numéro incrémental sur les fichiers reçus pour garder un historique de versions ; ce renommage/historique est géré entièrement par lui au moment du transfert, sans action particulière attendue de Claude sur les noms de fichiers livrés.