# Déploiement — Immbot AI

## Cible de référence : nœud unique (macOS/Linux)

L'architecture v1 (SQLite + embeddings locaux) est conçue pour un déploiement mono-nœud simple et
robuste — typiquement le nœud M3U96b du cluster MacLustr, ou tout VPS Linux.

### Étapes (production mono-nœud)

```bash
# 1. Copier le projet ET les deux dossiers de cours sur le serveur
rsync -a immbot-ai IMM1003-20 IMM1033-20 serveur:~/apps/

# 2. Sur le serveur
cd ~/apps/immbot-ai
cp .env.example .env         # renseigner OPENROUTER_API_KEY, AUTH_SECRET, APP_URL
pnpm install && pnpm seed && pnpm ingest && pnpm build

# 3. Processus géré (PM2 recommandé — auto-restart)
pm2 start "pnpm start" --name immbot-ai
pm2 save
```

### HTTPS / domaine

- **ngrok** (utilisé pour www.immbot.ai) : `ngrok http 3070 --url=www.immbot.ai` (domaine réservé
  dans le compte ngrok), géré par PM2 ou launchd pour la persistance.
- **Alternative reverse-proxy** : Caddy (`caddy reverse-proxy --from immbot.example.com --to :3070`)
  ou nginx + certbot.
- Mettre `APP_URL=https://www.immbot.ai` dans `.env` (active `Secure` sur les cookies et la
  vérification d'origine CSRF).

### Docker

```bash
docker compose up --build          # app seule (SQLite)
docker compose --profile scale up  # + PostgreSQL/pgvector, Redis, MinIO (trajectoire de montée en charge)
```

## Sauvegardes et restauration

- `./scripts/backup.sh` → `backups/<horodatage>/` (BD + uploads). Planifier via cron/launchd.
- Restauration : arrêter l'app, remplacer `data/immbot.db` par la sauvegarde, redémarrer.
- Les fragments RAG se reconstruisent à tout moment : `pnpm reindex`.

## Rotation des clés

- **OpenRouter** : générer une nouvelle clé, remplacer `OPENROUTER_API_KEY`, redémarrer. L'ancienne
  clé se révoque dans le tableau de bord OpenRouter.
- **AUTH_SECRET** : le changer n'invalide pas les sessions (elles vivent en BD) ; pour tout
  déconnecter : `DELETE FROM sessions;` via `sqlite3 data/immbot.db`.

## Mises à jour du matériel de cours

Déposer/modifier les fichiers dans `IMM1003-20/` / `IMM1033-20/` puis « Relancer l'ingestion »
depuis l'admin (ou `pnpm ingest`). L'ingestion est incrémentale (sommes de contrôle SHA-256).

## Surveillance

- Admin → Vue générale : coûts, erreurs API, citations invalides, santé de l'ingestion.
- Journaux structurés sur stdout (PM2 : `pm2 logs immbot-ai`).
- `SENTRY_DSN` prévu dans `.env.example` (intégration optionnelle non activée par défaut).

## Trajectoire de montée en charge (documentée, non requise en v1)

| Besoin | Évolution |
|---|---|
| > ~200 utilisateurs simultanés | PostgreSQL (+ pgvector) via le profil docker `scale` ; le schéma SQL est portable (types simples, requêtes préparées) |
| Multi-instances | Sessions et rate-limit déplacés vers Redis ; uploads vers MinIO/S3 (interface déjà isolée dans `.env`) |
| > 100 k fragments RAG | pgvector (index HNSW) au lieu du cosinus en mémoire |