ASPIC/journal/ASPIC-Journal. 23. Push GitHub en SSH depuis le VPS.md

## 23. Push GitHub en SSH depuis le VPS, fusion de `./src` avec le dépôt Git, réconciliation, correctif V1.002 (30 août 2026)

**Contexte.** Session ouverte sur un petit correctif isolé (voir plus bas), puis élargie à un chantier plus structurant : Jean-Marc a désormais un accès terminal fonctionnel sur son VPS avec clé SSH déjà paramétrée pour sa propre connexion — ce qui résout au passage le souci de console Hostinger capricieuse rencontré le 28 août (section 21). Ceci a permis de reprendre la question, restée en suspens depuis le 27-28 août (section 20), du confort du circuit de mise à jour de GitHub : Jean-Marc trouvait le glisser-déposer manuel sur l'interface web "pas très pratique" et n'était pas très à l'aise avec cette manipulation.

**Point important, clarifié en début de chantier :** le blocage d'écriture rencontré par Claude en section 20 (le proxy git de l'environnement cloud de Claude, qui refuse tout `git push` vers un dépôt non explicitement autorisé) est **indépendant du protocole** — il intercepte toute connexion sortante de Claude vers GitHub avant même l'authentification, que ce soit en HTTPS ou en SSH. Ce chantier ne lève donc pas ce blocage-là, et ne cherche pas à le lever : il met en place un circuit où **c'est Jean-Marc, depuis son propre VPS, qui pousse en SSH** — un chemin entièrement différent, qui ne passe jamais par l'environnement de Claude.

**Correctif isolé livré en tout début de session — `NGÉNIERIE` → `NTELLIGENCE` (V1.002).** Demande récurrente de Jean-Marc ("cela fait 20 fois que j'y pense") : dans le bandeau acrostiche de l'écran d'identification, le mot associé à la lettre "I" affichait `NGÉNIERIE` (pour "Ingénierie Commerciale") ; changé en `NTELLIGENCE` (pour "Intelligence Commerciale"), plus cohérent avec la vocation IA du projet. Localisé dans `identification.html`, ligne `<div class="word">NGÉNIERIE</div>` — seule occurrence dans tout le dépôt. Changement d'un seul mot, vérifié par diff (une seule ligne modifiée), équilibre des balises `<div>` inchangé (23/23), JavaScript extrait toujours valide (`node --check`). `version.php` incrémenté à `V1.002` en parallèle, à la demande explicite de Jean-Marc (numéro donné directement, pas calculé). Fichiers livrés en téléchargement dans la conversation — leur déploiement effectif sur le VPS n'a eu lieu que plus tard dans la session, une fois le nouveau circuit Git en place (voir plus bas).

**Mise en place de l'accès SSH dédié pour GitHub.**

- Clé SSH générée directement sur le VPS, dédiée à ce seul usage (distincte de celle que Jean-Marc utilise pour se connecter au VPS depuis son poste) : `ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_aspic_github -N ""` (sans phrase de passe, pour un `git push` non interactif — risque jugé limité puisque la clé n'a accès qu'à un seul dépôt, voir plus bas).
- Ajoutée côté GitHub comme **Deploy key** sur le seul dépôt `JMP-MS/ASPIC` (`Settings → Deploy keys`), avec l'option **Allow write access** cochée — plutôt qu'une clé personnelle liée à l'ensemble du compte GitHub de Jean-Marc. Choix délibéré de Jean-Marc (répondant à une question posée explicitement) : cohérent avec le principe de moindre privilège déjà appliqué ailleurs sur ce projet (comptes techniques limités à leur périmètre plutôt que larges — `crm_user` limité à sa base, futur compte MySQL dédié pour MIRADOR en section 21).
- Alias d'hôte dédié dans `~/.ssh/config` sur le VPS, pour éviter tout conflit avec d'éventuelles autres clés GitHub sur ce même serveur :
  ```
  Host github.com-aspic
      HostName github.com
      User git
      IdentityFile ~/.ssh/id_ed25519_aspic_github
      IdentitiesOnly yes
  ```
  Le remote Git du dépôt utilise donc `git@github.com-aspic:JMP-MS/ASPIC.git`, pas l'adresse standard `git@github.com:...`.
- **Vérification de l'empreinte de l'hôte à la première connexion.** Au premier `ssh -T git@github.com-aspic`, SSH a demandé de confirmer l'empreinte du serveur GitHub (`SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU`) — étape normale et attendue (mémorisation de l'hôte pour les connexions suivantes), pas une anomalie. Empreinte vérifiée par Claude contre la documentation officielle GitHub avant validation par Jean-Marc (correspondance confirmée) plutôt que d'accepter à l'aveugle — cohérent avec la discipline "tester plutôt que croire sur parole" déjà appliquée sur ce projet. Connexion validée : *"Hi JMP-MS/ASPIC! You've successfully authenticated, but GitHub does not provide shell access."*
- **`git config --global --add safe.directory`** nécessaire au premier `git status`/`git clone` en tant que `root` sur ce nouveau dossier ("detected dubious ownership") — protection standard de Git depuis une version récente, sans lien avec un problème réel de permissions ici ; résolu en une commande, comme suggéré par Git lui-même.

**Localisation du vrai dossier de déploiement.** Le chemin exact du `docker-compose.yml` d'ASPIC sur le VPS n'était pas documenté dans ce journal. Retrouvé de façon fiable via `docker inspect aspic-crm-app-1 --format '...'` (ou `docker inspect aspic-crm-app-1 | grep -A2 '"Source"'` en repli, plus robuste aux soucis de guillemets lors d'un copier-coller de template Go) plutôt qu'en devinant l'emplacement du fichier YAML — donne directement le vrai chemin hôte du bind mount. **Chemin confirmé : `/docker/aspic`, avec le dossier `src` à l'intérieur** (le service applicatif se nomme `crm-app` dans `docker-compose.yml`, le conteneur réel `aspic-crm-app-1` ; le service SFTP existant se nomme `sftp`).

**Fusion du dossier de déploiement avec le dépôt Git — décision et méthode.** Plutôt que de garder deux emplacements distincts (le dossier `./src` servant au déploiement, et un clone Git séparé ailleurs sur le VPS qu'il aurait fallu recopier vers `./src` à chaque livraison — solution qui aurait reproduit exactement la corvée que Jean-Marc voulait éviter), décision de faire de `./src` lui-même la copie de travail du dépôt Git. Un seul dossier sert désormais à la fois de dossier de production et de dépôt Git.

**Point de vigilance essentiel, identifié avant toute manipulation : ne pas cloner GitHub par-dessus `./src` sans précaution.** Le dépôt GitHub était connu comme étant en retard sur la vraie production (`version.php` y affichait encore `V1.000` alors que la prod réelle était à `V1.001` depuis le 29 août, section 22 — les livraisons du 29 août n'avaient jamais été poussées). Un clone brutal aurait donc fait régresser la prod. Méthode de réconciliation suivie :

1. `mv src src_old` — le vrai dossier de production est mis de côté intact, comme filet de sécurité, avant toute manipulation.
2. `git clone git@github.com-aspic:JMP-MS/ASPIC.git src` — un nouveau `src` est recréé à partir du dépôt GitHub (donc, à ce stade, en retard).
3. `diff -rq src_old src --exclude=.git` — comparaison explicite avant d'agir. Résultat : trois fichiers divergents (`liste_contacts.html`, `preferences.php`, `version.php`) — exactement les trois fichiers du chantier badge société/avatar du 29 août jamais poussés (section 22). `identification.html`, en revanche, s'est révélé **identique** entre les deux — résultat intéressant qui clôt une question restée ouverte depuis plusieurs sessions (section 8) : le soupçon de décalage GitHub/prod sur ce fichier précis était infondé (le compte de démonstration `UTILISATEURS_DEMO`, lui, est bien présent des deux côtés, retiré depuis — section 24). Aucun fichier présent d'un seul côté (pas de ligne "Only in ..." dans le diff).
4. `rsync -a --exclude='.git' src_old/ src/` — le contenu réel de la production est ramené dans le nouveau dossier Git, pour ne perdre aucun travail non poussé.
5. `git add -A && git commit -m "Réconciliation avec la production réelle - V1.001 (badge société/avatar, USR_Code/USR_Societe dans preferences.php)" && git push` — premier vrai commit "de fond" du dépôt (commit `ff0e3a6`), qui succède au commit unique initial ("Add files via upload", section 20). **Identité Git (`user.name`/`user.email`) configurée en global sur le VPS à cette occasion, absente auparavant.**

**Piège rencontré — le conteneur SFTP restait attaché à l'ancien dossier.** Une fois la réconciliation poussée, Jean-Marc a déposé les deux fichiers V1.002 du tout début de session (`identification.html`, `version.php`) via son client SFTP habituel (FileZilla, port 2224) — mais `grep -c NTELLIGENCE identification.html` sur le nouveau `src` répondait `0` alors que FileZilla confirmait un dépôt réussi. **Cause identifiée :** un conteneur avec un volume bind-mount reste attaché à l'objet-dossier hôte tel qu'il existait à son démarrage. Le service `sftp` tournait déjà depuis un moment quand `mv src src_old` a eu lieu ; il est donc resté attaché à ce qui s'appelle maintenant `src_old`, invisible pour Git, alors même que FileZilla montrait un dépôt "réussi" au bon nom de dossier apparent. Le conteneur `crm-app`, lui, avait déjà été redémarré entre-temps (voir plus bas) et voyait donc correctement le nouveau `src`. **Diagnostic confirmé** par `grep -c NTELLIGENCE src_old/identification.html` → `1`. **Corrigé** par `cp src_old/identification.html src_old/version.php src/` (récupération directe, sans repasser par FileZilla) puis `docker compose restart sftp`, pour que les prochains dépôts FileZilla arrivent directement au bon endroit. **Point de méthode à valeur générale, ajouté en section 3 : un renommage/recréation de dossier sur l'hôte pendant qu'un conteneur tourne n'est pas vu par ce conteneur tant qu'il n'est pas redémarré — à vérifier systématiquement (et redémarrer tous les conteneurs concernés, pas seulement l'application principale) après toute manipulation de ce type sur un dossier monté en bind mount.**

**Deuxième commit — clôture du correctif V1.002.** Une fois les fichiers bien positionnés dans le dossier Git : `git add -A && git commit -m "V1.002 - Bandeau identification : Ingenierie devient Intelligence" && git push` (commit `64cc133`). `docker compose restart crm-app` refait ensuite pour réappliquer le `chown -R 1001:1001` sur les fichiers déposés par `cp` en tant que `root` (ce dernier ne préserve pas le propriétaire d'origine sans l'option `-p`/`-a`). **Confirmé en production par Jean-Marc le jour même :** bandeau affichant "INTELLIGENCE", version `V1.002` visible.

**Nouveau circuit de livraison, en vigueur à partir de maintenant :**

1. Claude livre les fichiers en téléchargement dans la conversation, comme avant.
2. Jean-Marc les dépose dans `/docker/aspic/src` via son client SFTP habituel (FileZilla, port 2224) — inchangé de son point de vue, c'est toujours le même dossier apparent.
3. Depuis un terminal SSH connecté au VPS, dans `/docker/aspic/src` : `git add -A`, `git commit -m "..."` (idéalement avec le numéro de version, convention de la section 21 enfin appliquée), `git push`.
4. Le glisser-déposer manuel sur l'interface web GitHub (section 20-21) est abandonné.

**`src_old` conservé pour l'instant en filet de sécurité** (pas supprimé à la fin de cette session) — à retirer une fois plusieurs cycles de livraison confirmés stables via le nouveau circuit.

**Reste à faire, plus tard :**

- Supprimer `src_old` une fois le nouveau circuit éprouvé sur quelques livraisons.
- ~~Vérifier/corriger le compte de démonstration (`UTILISATEURS_DEMO`) dans `identification.html`~~ **Retiré le 30 août 2026 — voir section 24.**
- Confirmer que la convention "numéro de version dans le message de commit" (section 21) devient systématique sur les prochains push, pas seulement ce soir.
- Documenter ce nouveau circuit Git (clé SSH dédiée, deploy key, alias d'hôte) également côté projet de gestion du serveur si Jean-Marc le juge pertinent pour la cohérence avec les autres applications du VPS — non fait ici, hors périmètre de ce journal.