ASPIC/journal/ASPIC-Journal. 25. MIRADOR Validé à Deux Utilisateurs.md

## 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.