# formation-consultant — site de formation autodidacte perso

**Date de creation** : 25/07/2026
**Sphere** : perso (aucune donnee TT ou Nyora business)

## Objectif
Site web personnel accompagnant le parcours de certification autodidacte "Solution Consultant"
(3 phases : Google GenAI / IREB exigences / IIBA ECBA business analysis), a consulter avant
l'arrivee du MacBook. Phase 1 (Google GenAI) entierement peuplee, Phase 2/3 a construire au fil
des sessions Claude suivantes.

## Stack
- Conteneur unique `formation-consultant` : nginx:alpine, statique (index.html + style.css + app.js)
- Port **8801->80**, reseau docker `n8n`, restart unless-stopped
- Basic Auth au niveau nginx (`.htpasswd`, utilisateur `nabil`) — le mot de passe genere vit
  uniquement dans `/volume1/docker/formation-consultant/auth/.pw-generated-once.txt` sur le NAS,
  **jamais pousse sur Gitea**
- Repo Gitea : `bolbol/formation-consultant` (prive) — contient `site/`, `docker-compose.yml`,
  `nginx.conf`. Le dossier `auth/` (htpasswd + mot de passe) reste local au NAS uniquement.

## Deploiement (deja fait le 25/07/2026)
```
cd /volume1/docker/formation-consultant
docker compose up -d
```

## Etape manuelle restante — reverse-proxy DSM
Le conteneur n'est pas encore joignable sur `formation.bolbol.tn` : la creation du vhost DSM
necessite un acces root que le compte Best0f (utilise via mcp-nas) n'a pas (sudo demande un mdp,
claude-ops NOPASSWD n'a pas de cle presente dans ce container). Meme pattern deja rencontre pour
cin-search-tt (ports-registry.md note deja "reverse-proxy DSM a creer manuellement").

**A faire une fois dans DSM > Panneau de configuration > Portail de connexion > Avance > Proxy inverse :**
- Nom : formation-consultant
- Source : HTTPS, formation.bolbol.tn, port 443
- Destination : HTTP, localhost (ou 127.0.0.1), port 8801

Le certificat wildcard *.bolbol.tn existant couvre deja ce sous-domaine (pas de nouveau certificat
a generer). Le DNS bolbol.tn est deja wildcard (aucune entree pihole/OVH specifique necessaire,
confirme par l'absence d'entree custom.list pour les autres sous-domaines).

## Mise a jour du contenu (sessions suivantes)
Le contenu HTML est genere depuis un pipeline pandoc (markdown -> HTML) construit hors-NAS, puis
pousse directement sur Gitea via l'API contents (POST, pas PUT tant que le fichier n'existe pas ;
PUT + sha pour mise a jour), puis recupere sur le NAS via curl sur l'endpoint raw interne
(`http://172.17.0.1:3232/api/v1/repos/bolbol/formation-consultant/raw/site/<fichier>`).
Cette methode evite le transfert manuel par heredoc (teste, beaucoup plus fiable pour des fichiers
de plusieurs dizaines de Ko contenant des caracteres accentues).

## Lecons
- Le fichier `/usr/syno/etc/www/ReverseProxy.json` est lisible par Best0f mais pas modifiable
  (proprietaire root, 644) : toute creation de vhost DSM reste une etape manuelle tant qu'un acces
  root (ou la cle SSH claude-ops) n'est pas disponible dans le container mcp-nas.
- Transferer du contenu volumineux vers le NAS via heredoc mcp-nas est lent et fragile (risque de
  troncature/erreur de recopie). Passer par Gitea (accessible publiquement en HTTPS sur
  gitea.bolbol.tn) comme relais est nettement plus fiable : push depuis l'environnement source via
  l'API contents publique, pull sur le NAS via l'API interne.
- `GITEA_TOKEN_TT` a un scope suffisant pour creer un repo (`write:repository` implicite), mais
  `GITEA_TOKEN_PERSO`/`GITEA_TOKEN_NYORA` non — a verifier/harmoniser si la creation de repos perso
  redevient necessaire.