7.0 KiB
25. MIRADOR validé à deux utilisateurs, nettoyage des bases obsolètes, retrait de USR_MDP, déploiement sur aspic.bzh — V1.003 (30 août 2026, soir)
Contexte. Suite directe de la section 24 : Jean-Marc reprend la main après le branchement de MIRADOR sur l'authentification pour effectuer les opérations qui restaient à sa charge (voir la liste "reste à faire" de la section 24), puis va nettement plus loin dans la même soirée — au point de considérer l'objectif initial de tout ce chantier (accès simultané multi-bases pour plusieurs utilisateurs sur aspic.bzh, section 21) comme atteint.
Deuxième utilisateur MIRADOR ajouté et testé. Jean-Marc a ajouté une ligne MIR_Users pour un second utilisateur (celui destiné à MS-TST) et généré son mot de passe hashé selon la commande déjà en place (docker exec -it aspic-crm-app-1 php -r "echo password_hash('...', PASSWORD_DEFAULT) . PHP_EOL;", section 21). Test effectué en conservant l'environnement en l'état (deux instances MySQL, deux bases MS-DEV/MS-TST, comme laissé par la section 24) : connexion réussie avec les deux comptes, chacun routé vers sa propre base — première confirmation concrète, avec deux vrais utilisateurs distincts (au-delà des simulations par script PHP faites en section 24), que le routage dynamique de getDbConnection() fonctionne comme prévu.
Nettoyage de l'infrastructure — suppression des bases devenues obsolètes. Une fois ce test validé, Jean-Marc a supprimé les bases ASPIC et MIRADOR de l'instance mysql — les copies d'origine, conservées par précaution depuis la section 24 (ASPIC en filet de sécurité avant le clonage vers MS-DEV/MS-TST ; la copie de MIRADOR restée sur mysql, non consultée par le code depuis que l'application interroge celle de mysql2). Ce nettoyage n'a plus de risque à ce stade : la section 24 avait explicitement noté que db.php ne s'appuie plus que sur mysql2 pour MIRADOR (ROUTER_DB_HOST) et que MS-DEV/MS-TST sont les seules bases de travail utilisées.
Retrait de USR_MDP. Colonne supprimée de la table ASP_Users dans MS-DEV et MS-TST (ALTER TABLE ASP_Users DROP COLUMN USR_MDP ou équivalent, fait directement par Jean-Marc en base). Cohérent avec ce qui était annoncé dès la section 24 : cette colonne n'était plus consultée par aucun code depuis le branchement de MIRADOR (le mot de passe est vérifié une seule fois, contre MIR_MDPHash) — elle était devenue un pur vestige, et son retrait ne change rien au comportement de l'application.
Déploiement sur aspic.bzh. Jean-Marc a téléchargé les fichiers de l'application sur aspic.bzh — premier déploiement réel de ce nom de domaine, dont l'acquisition avait été annoncée dès la section 21 (28 août 2026) comme le déclencheur prévu de toute cette architecture MIRADOR. aspic.mvl-tls.fr (environnement de développement habituel) et aspic.bzh (nouvel environnement de test) tournent désormais sur un code strictement identique. Précisé par Jean-Marc le 31 août 2026 : les deux domaines ont chacun leur propre environnement sous Docker (deux services/docker-compose.yml distincts, pas un conteneur partagé entre les deux noms de domaine) — un correctif futur devra donc être déployé séparément sur chacun des deux, via le même circuit FileZilla + SSH mais deux dépôts de fichiers distincts.
Accès via Homarr. Jean-Marc s'est installé deux tuiles sur son tableau de bord Homarr (outil de page d'accueil auto-hébergée, hors périmètre technique de ce journal) pour accéder directement aux deux environnements : une tuile vers aspic.mvl-tls.fr (développement), une tuile vers aspic.bzh (tests) — un raccourci de confort plutôt qu'un changement d'architecture, mais qui matérialise concrètement la coexistence des deux environnements évoquée depuis la section 22.
Résultat. Confirmé par Jean-Marc : "ça fonctionne !" — les deux environnements sont opérationnels, avec authentification centralisée par MIRADOR, chacun routé vers sa propre base MySQL. C'est la première fois que l'objectif initial du chantier MIRADOR (section 21 : permettre à plusieurs utilisateurs de travailler simultanément, chacun sur sa propre base, une fois aspic.bzh actif) est démontré de bout en bout sur les deux domaines réels, et pas seulement en test isolé sur aspic.mvl-tls.fr.
Version applicative — V1.003. Incrémentée par Claude dans version.php à la demande explicite de Jean-Marc, pour marquer cette étape ("je souhaite que cette version soit fièrement intitulée 1.003"). Fichier vérifié (php -l), livré à Jean-Marc, puis déployé par lui via le circuit habituel (FileZilla → /docker/aspic/src → SSH sur le VPS). Push GitHub effectué le 31 août 2026 avec le commit 00c58fb "V 1.003 Accès par MIRADOR sur deux environnements", vérifié réussi par Claude en récupérant l'état réel du dépôt (git fetch) : contenu strictement identique à ce qui avait été livré (diff vide), version.php affichant bien V1.003, compte de démonstration absent, code MIRADOR présent dans aspic.php/db.php, les huit fichiers PHP du dépôt passant php -l sans erreur.
Le blocage d'écriture du proxy git côté Claude (section 20) reste entier et n'a jamais été levé — mais Jean-Marc a explicitement confirmé le 31 août 2026 que ce n'est plus un sujet d'inquiétude pour lui : le circuit de contournement (FileZilla → SSH VPS, section 23) est maintenant adopté comme "une habitude de travail à prendre", pas une gêne. Point de méthode retenu pour ce circuit : les trois commandes du terminal (git add, git commit, git push) peuvent être collées d'un bloc dans le terminal SSH plutôt que tapées une à une — un terminal exécute les lignes collées dans l'ordre, comme si elles étaient tapées séquentiellement. Conseil donné par Claude : les enchaîner avec && (git add -A && git commit -m "..." && git push) plutôt que de les laisser sur des lignes séparées, pour qu'un échec sur une étape (ex. rien à committer parce que le dépôt FileZilla n'a pas eu lieu avant) interrompe la suite au lieu de s'exécuter dans le vide.
Point de vigilance résolu : la question ouverte en fin de chantier (l'application aspic.bzh partage-t-elle son conteneur avec aspic.mvl-tls.fr ou dispose-t-elle de son propre déploiement Docker ?) a été tranchée par Jean-Marc le 31 août 2026 — voir le paragraphe "Déploiement sur aspic.bzh" ci-dessus : chaque environnement a son propre déploiement Docker.
Reste à faire, plus tard :
- Poursuivre l'onboarding de futurs bêta testeurs externes (objectif business sous-jacent à toute l'architecture MIRADOR — voir réflexions stratégiques) : rappel de la règle actée en section 21, migrer MIRADOR vers une instance MySQL dédiée avant l'arrivée du tout premier bêta testeur réel, pas avant.
src_old(section 23) toujours à retirer une fois le nouveau circuit Git éprouvé sur quelques cycles supplémentaires de livraison — non traité dans cette session.