Proposition : Migrer le dashboard vers un projet GitLab clean avec approche live

Date : 15/02/2026 Status : IMPLEMENTEE Contexte : Audit dashboard — generate.sh trop lourd, données statiques périmées Origine : Demande utilisateur lors de la revue d'audit

Probleme actuel

• generate.sh = ~20 scripts bash qui collectent (SSH, curl, jq) + génèrent du HTML statique
• Chaque exécution prend plusieurs minutes (SSH vers chaque VM, parsing, génération)
• Les données sont périmées dès la génération — statique = snapshot
• Le déploiement = git push vers O2switch (pas de CI/CD)
• Les credentials sont dans les scripts bash (findings C-01, C-15, C-16)
• Le code est un monolithe bash fragile (pas de tests, pas de set -e, heredocs partout)

Proposition : Dashboard live léger

Architecture

┌─────────────────┐       ┌──────────────────┐       ┌─────────────────┐
│   O2switch       │       │  prod-portainer   │       │  Services        │
│                  │       │                   │       │  (VMs, Docker)   │
│  Frontend SPA    │──────►│  Dashboard API    │──────►│                  │
│  (HTML/JS statiq)│ fetch │  (léger, Bun/Elysia│ SSH/ │  Prometheus      │
│                  │◄──────│   ou Python)      │◄──API │  Loki            │
└─────────────────┘  JSON  └──────────────────┘       │  Portainer       │
                                                       │  GitLab          │
                                                       └─────────────────┘

Option A : API backend + SPA frontend

Backend (sur prod-portainer) :

• Micro-service léger (Bun/Elysia ou FastAPI) qui expose les données en JSON
• Collecte en temps réel : appelle les APIs existantes (Portainer, GitLab, Prometheus, Loki) à la demande
• Cache court (30s-60s) pour ne pas surcharger les services
• Auth : API key simple (comme les autres services internes)
• CI/CD GitLab → smart-deploy comme les autres projets

Frontend (sur O2switch) :

• SPA statique légère (HTML + vanilla JS ou Qwik SSG)
• Fetch les données depuis l'API backend
• Auto-refresh toutes les 30s (ou WebSocket pour du vrai temps réel)
• Pas de credentials dans le frontend — tout passe par l'API backend
• Déployé via CI/CD GitLab → smart-deploy O2switch

Avantages :

• Données toujours fraîches (pas de génération)
• Plus de credentials dans le frontend/git
• Réutilise le pattern des autres projets (Elysia, smart-deploy)
• Testable, maintenable, typé

Inconvénients :

• Un service de plus sur prod-portainer
• Dépend de la disponibilité du backend pour afficher les données

Option B : SSG amélioré (generate.sh v2)

• Réécrire generate.sh en TypeScript/Bun
• Garder l'approche statique mais propre :
  • Données collectées via API (pas SSH brut)
  • Templates propres (pas de heredoc bash)
  • Credentials en .env
  • CI/CD GitLab
• Exécution cron toutes les 5 min

Avantages :

• Pas de service supplémentaire
• Le dashboard marche même si prod-portainer est down (snapshot)

Inconvénients :

• Toujours des données périmées (5 min de délai)
• Moins flexible qu'une API

Option C : Hybride

• API backend pour les données temps réel (status services, GPU, jobs)
• SSG pour les pages lourdes/stables (CI/CD history, config, docs)
• Le meilleur des deux mondes

Sources de données existantes à réutiliser

Note : La majorité des données sont DÉJÀ accessibles via des APIs. Les scripts bash réinventent la roue avec du SSH brut.

Projet GitLab clean

• Nouveau repo : dashboard-33800 (ou renommer l'existant)
• Structure :

  dashboard-33800/
  ├── backend/          # API (si option A ou C)
  │   ├── src/
  │   ├── package.json
  │   └── Dockerfile
  ├── frontend/         # SPA
  │   ├── src/
  │   ├── index.html
  │   └── package.json
  ├── .gitlab-ci.yml    # CI/CD
  └── conf.prod.gouroubleu.yml

• CI/CD : build → push registry → smart-deploy (backend sur prod-portainer, frontend sur O2switch)

Decision

En attente de validation utilisateur + choix entre Option A, B, ou C.