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.