HyprBox docs GitHub ↗

Runbook de démo — la boucle find → fix → verify, version parlée (FR)

Script de présentateur pour une démo live de ~5 min de HyprBox sur un agent réel. Sans risque : la boucle que tu pilotes à l'écran utilise un Finding de démo bénin (demo.marker-missing) et un preset SAFE (hyprbox-demo) qui ne touche que /tmp. Le beat HyprWatch à la fin est en preview-only sauf sur une machine jetable.

Version anglaise complète (canonique) : DEMO.md. Ici, le script parlé en français — les commandes sont identiques.

Le cadrage (à dire en ouverture, ~20s)

« Ton monitoring te dit qu'un disque est plein, que SSH accepte les mots de passe, qu'un certificat expire. Ensuite tu te connectes en SSH et tu corriges à la main, sur chaque serveur. HyprBox, c'est la partie qui corrige — elle trouve le problème, te montre le changement exact avant de l'exécuter, l'applique, et prouve que ça a marché. Preview-puis-apply, sur une flotte. Je te montre la boucle complète sur un serveur live. »

Garde l'anti-pitch sous le coude si on te demande « c'est du Terraform / k8s ? » : « Non — ça pilote des API cloud et des clusters. Nous, on exécute des correctifs vetés en bash sur les hôtes qu'une PME a vraiment. Apps installées sur l'hôte : oui. Plans de contrôle : non. » (cf AUTOPILOT.md).

Pré-vol (à faire AVANT que le prospect arrive)

Rien ne tue une démo comme un démarrage à froid. À lancer 5 min avant :

# 1. Stack up. Postgres (docker = la voie sans sudo sur cette machine) :
docker compose -f docker-compose.dev.yml up -d postgres
pnpm --filter @hyprbox/api dev   # :4000
pnpm --filter @hyprbox/web dev   # :3000
# 2. Vérifie qu'un admin + au moins un node avec findings existent déjà :
#    connecte-toi sur http://localhost:3000 (admin@hyprbox.local / hyprbox-admin)
#    et ouvre /dashboard/health — tu dois voir de vrais findings (disk, audit…).
# 3. Mint un node token lié à ton node (page Tokens ou POST /api/tokens),
#    et ARME la démo :
rm -f /tmp/hyprbox-demo.ok
# 4. Démarre l'agent en mode démo (intervalles courts pour que les beats tombent vite) :
HYPRBOX_API_URL=http://localhost:4000 \
HYPRBOX_NODE_ID=wsl-smoke \
HYPRBOX_NODE_TOKEN=<node token> \
HYPRBOX_DEMO=1 \
HYPRBOX_INTERVAL=8s HYPRBOX_SCAN_INTERVAL=8s \
./agent/hyprnode/hyprnode

Checklist avant de partager l'écran :

  • /dashboard/health charge et liste des findings (la page n'est pas vide).
  • Le finding INFO « Demo: marker file is missing » est apparu.
  • Tu es déjà connecté (pas de galère avec le mot de passe à l'écran).
  • Zoom navigateur ~125% pour que la salle lise le bash rendu.

Acte 1 — Discover (~45s)

Ouvre /dashboard/health.

« Voici tous les serveurs que l'agent surveille. Chaque ligne est un Finding — un risque précis, en langage clair, pas une métrique à interpréter. »

Pointe un vrai (disk usage / UFW inactive / fail2ban down). Puis le finding démo :

« En voici un qu'on va corriger en live : un fichier que l'agent attend est absent. INFO, parce que c'est inoffensif — mais ça pilote exactement la même machinerie que les findings critiques. »

Le point clé : les findings sont des causes lisibles, et chacun porte un correctif recommandé. C'est ça le produit, vs un dashboard qui montre juste du rouge.

Acte 2 — Fix, avec preuve (~2min — le cœur)

Clique sur le finding « Demo: marker file is missing ».

« Avant que quoi que ce soit s'exécute, je vois la recommandation et le bash exact qui va tourner. Rien n'est caché. »

Pointe :

  • le titre de la recommandation + le tier de risque SAFE (le bouton Apply est gated par tier — un fix MANUAL n'a aucun bouton, un DANGEROUS exige une confirmation tapée). « Le produit décide combien de friction chaque fix mérite. »
  • le script rendu (l'écriture du marker + le bloc verify).

Clique Apply fix →. Tu atterris sur le live-tail du job.

« L'agent l'exécute pour de vrai, là, maintenant — streamé en live. Et surtout : il ne fait pas que l'exécuter, il vérifie. Tu vois la ligne verified: … ? C'est le step de verify qui affirme que le fix a vraiment pris. Pas de verify, pas de succès. »

Le job passe SUCCEEDED. Retourne sur /dashboard/health.

« Et le finding s'est résolu tout seul — la boucle s'est fermée. On lui a demandé de corriger X, il a lancé le fix veté, X a disparu. C'est find → fix → verify → resolve, de bout en bout, en quinze secondes. »

C'est tout le pitch en un seul mouvement. Si tu ne montres qu'une chose, montre ça.

Acte 3 — Ça installe, pas juste répare (~1min, optionnel mais fort)

C'est le wedge qui transforme « auto-remédiation » en « ton ops-stack en autopilote ». Active HyprWatch sur le node (page config ou PATCH /api/nodes/<id>/config {"hyprwatch":true}) ; en un tick un finding « No monitoring stack detected » apparaît, recommandant le preset monitoring-only.

« Même boucle — mais ici le fix installe Prometheus, Grafana, node-exporter et Alertmanager, ouvre le firewall, et vérifie que les trois servent avant de dire que c'est fait. Tu pointes HyprBox sur un serveur PME neuf et il dresse ton monitoring, ton logging, tes backups — et les garde en bonne santé. »

Deux façons de le montrer :

  • Machine jetable : clique vraiment Apply — le stack monte, le verify passe au vert, le finding se résout. Le plus impressionnant ; seulement là où déployer Prometheus est acceptable.
  • N'importe quelle machine (sûr) : ouvre la recommandation et montre le compose rendu + les steps verify, puis narre l'apply. Ne clique pas Apply sur une machine à laquelle tu tiens — ça déploie de vrais services.

Reset après : PATCH …/config {"hyprwatch":null} + résous le finding.

Le close (~15s)

« Trois modules, une boucle : HyprGuard durcit, HyprVault sauvegarde, HyprWatch surveille — tous en find → preview → fix → verify. Construit sur des moteurs OSS éprouvés, avec l'intelligence d'autopilote par-dessus. Self-hosted, tes serveurs, tes données. »

Run rapide (référence)

Arme + démarre l'agent (mode démo), puis sur http://localhost:3000 :

  1. /dashboard/health → en ~un tick de scan le node montre « Demo: marker file is missing » (INFO).
  2. Clique → la modal montre la recommandation hyprbox-demo (SAFE) + le bash rendu → Apply fix →.
  3. Live-tail du job : marker écrit, verify affiche verified: … → SUCCEEDED.
  4. Health : le finding est RESOLVED (auto-resolve sur succès du job).
rm -f /tmp/hyprbox-demo.ok                 # arme la démo
HYPRBOX_API_URL=http://localhost:4000 HYPRBOX_NODE_ID=wsl-smoke \
HYPRBOX_NODE_TOKEN=<node token> HYPRBOX_DEMO=1 \
HYPRBOX_INTERVAL=8s HYPRBOX_SCAN_INTERVAL=8s ./agent/hyprnode/hyprnode

Ré-armer / reset

rm -f /tmp/hyprbox-demo.ok                  # le prochain scan ré-émet le finding démo

Pour HyprWatch : PATCH /api/nodes/<id>/config {"hyprwatch":null} et résous le finding monitoring.absent (POST /api/findings/<id>/resolve).

Si ça casse en live

  • Pas de finding démo après ~15s → le marker existe encore (rm -f /tmp/hyprbox-demo.ok) ou HYPRBOX_DEMO n'était pas mis sur l'agent. Garde un second terminal prêt à relancer l'agent.
  • Page Health vide → l'agent ne reporte pas ; vérifie que le node token est lié à ce nodeId et que l'API est sur :4000.
  • Bouton Apply absent → la recommandation de ce finding est MANUAL (pas d'auto-apply, par design) — utilise le finding démo, qui est SAFE.
  • Fallback terminal : toute la boucle marche en curl (GET /api/findings, GET /api/findings/:id, queue via POST /api/jobs, stream GET /api/jobs/:id/stream) si l'UI déconne — cf API.md.

Notes

  • HYPRBOX_DEMO_MARKER surcharge le chemin du marker (défaut /tmp/hyprbox-demo.ok).
  • Sans HYPRBOX_DEMO, le scanner démo est un no-op — safe en prod.
  • hyprbox-demo est le seul preset que tu peux Apply sans risque sur ta propre machine ; les vrais fixes (server-light, docker-prune, …) exécutent du bash destructif sur l'hôte.