6.2 KiB
6. Pistes pour la suite
Évolution du modèle de données
- Structure réelle de ASP_Contacts, ASP_Annees, ASP_Statuts, ASP_Realisations, ASP_Actions, ASP_Professions, ASP_Users : voir section 2, à jour.
- ASP_Prospects, ASP_Campagnes, ASP_Operations, ASP_Mails, ASP_Docs : nouvelles tables du 26 août 2026, voir section 18.
- MIRADOR (MIR_Users) : base d'authentification/dispatch multi-instances, voir section 21 (conception) et section 24 (branchement effectif, 30 août 2026).
Évolution graphique du frontend
Deux directions possibles, à trancher : rester en JavaScript vanilla enrichi (cohérent avec le choix d'architecture initial), ou viser une charte visuelle plus travaillée si l'application est amenée à être livrée telle quelle à des clients. Le prototype d'écran d'identification (section 8) tranche pour l'instant en faveur d'un JS vanilla enrichi, avec une vraie charte graphique ASPIC (couleurs, typographie Metro DF).
Cible d'affichage et outil de maquettage (précisé le 19 août 2026)
- Écrans conçus pour un usage desktop uniquement ; pas de gestion spécifique du mobile pour l'instant.
- Résolution de référence : 1920×1080 (écrans de travail de Jean-Marc).
- Principe de conception : pas de scroll sur les écrans — le contenu doit tenir dans la hauteur visible, quitte à adapter les tailles/densités des éléments plutôt que de laisser déborder.
- Outil de maquettage retenu : Penpot, auto-hébergé sur le VPS, utilisé en solo. Prise en main en pause (19-20 août 2026) ; premiers jets d'écrans transmis directement en image ou en tableur, ça fonctionne tout aussi bien pour la revue.
Écran "Liste des contacts" et écran "Détail du contact"
Statut détaillé en sections 6 (historique complet des décisions d'ergonomie), 9 (implémentation) et 12-17 (branchement aux données réelles, ergonomie de visualisation/modification, création/suppression, panneau redimensionnable). Les deux écrans, plus l'écran d'identification, sont considérés comme aboutis par Jean-Marc au 25 août 2026. Décision du 26 août 2026 : cette partie "gestion des contacts" est laissée en l'état pour l'instant, le développement bascule sur la prospection (section 18).
Décisions de modélisation discutées le 19 août 2026
- JOIN ASP_Realisations / ASP_Contacts (relation 1-N sur CNT_Incr) : pas de vue SQL pour l'instant, deux requêtes distinctes plutôt qu'un JOIN. Une vue ne sera envisagée que si le même JOIN se retrouve dupliqué à l'identique dans plusieurs endpoints (règle empirique : à partir de 3 réutilisations) — cette règle a été explicitement réinvoquée et appliquée le 26 août 2026 pour trancher la question d'une "table des scénarios" de prospection (voir section 18) : pas assez de répétitions concrètes pour généraliser un moteur, on reste sur du code dédié par parcours. Réinvoquée une troisième fois le 28 août 2026 pour l'architecture MIRADOR (voir section 21) : pas de table "instances" séparée pour factoriser serveur/port, dupliqué par ligne utilisateur tant que le nombre d'instances reste faible.
- Formulaire web public de saisie de contact : idée initiale d'une table ASP_Contacts_SaisieWeb à contraintes assouplies, promue manuellement vers ASP_Contacts — remplacée le 26 août 2026 par le modèle ASP_Prospects (section 18), plus riche (campagnes, vérification mail, suivi de lecture) et mieux aligné avec le pivot du 23-25 août sur la prospection multi-campagnes (sections 11 et 17).
Décisions sur la suppression et l'historisation des données (20 août 2026)
- Suppression logique, jamais physique, pour les données métier réelles. Choix de principe de Jean-Marc, appliqué systématiquement sur ASPIC (CNT_Actif à 0, jamais de DELETE SQL réel sur les données importantes) — repris à l'identique pour les prospects via PSP_Actif (section 18), et pour MIRADOR via MIR_Actif (section 21). Exception assumée pour des données de test technique (pas des prospects réels) : suppression physique explicitement demandée et effectuée par Jean-Marc le 26 août 2026 pour nettoyer un enregistrement de test avant de relancer un essai — voir section 18.
- Pas d'historisation des modifications de champs. Un UPDATE écrase simplement l'ancienne valeur, sans table d'historique.
Automatisations futures (évoqué le 19 août 2026)
Objectif à terme : greffer des automatisations sur ASPIC, en particulier un déclenchement lorsque des enregistrements apparaissent depuis un formulaire public. Premier pas concret réalisé et testé avec succès en production le 26 août 2026 (section 18) : formulaire de prospection avec vérification mail et envoi automatique de documentation, sans intervention manuelle de Jean-Marc.
Portabilité
- Transport d'une version du CRM vers mvl-dcs.fr évoqué par Jean-Marc, non planifié dans l'immédiat.
- Objectif à terme : que cette même base PHP + MySQL soit directement réutilisable chez un client sur un hébergement mutualisé classique, sans Docker ni VPS.
- Note (19 août 2026) : ASPIC est pour l'instant à usage strictement interne — la portabilité reste un objectif d'architecture, pas un besoin client immédiat. La fonctionnalité de prospection (section 18) est un cas à part : conçue pour l'usage propre de Jean-Marc (Viktor, Brevo, n8n potentiellement), pas nécessairement destinée à être reproduite telle quelle chez un client — contrairement au cœur CRM (contacts).
Protection du code et modèle de déploiement pour de futurs projets clients (22 août 2026)
Réflexion engagée par Jean-Marc sur un sujet hypothétique, anticipant un futur déploiement d'applications de ce type chez des clients externes. Constat technique établi : aucune protection réelle n'existe côté JavaScript navigateur ; côté PHP, des encodeurs bytecode existent mais supposent un loader installé, incompatible avec l'hébergement mutualisé bas de gamme visé. Stratégie retenue selon la nature du projet (sur mesure pour un client vs. produit verticalisé mutualisé, avec point RGPD à vérifier avec un professionnel du droit dans le second cas) — ASPIC reste hors sujet dans l'immédiat.