Checklist Go‑Live (client)

Objectif : vérifier qu’une installation auto‑hébergée d’Aurora Nexus est prête pour la production (sécurité, stabilité, sauvegardes, exploitabilité).

1) Infra & réseau

• Domaine : un FQDN dédié (ex. rag.client.tld) pointe vers le serveur (A/AAAA).
• TLS : proxy reverse (Caddy/équivalent) configuré, certificats OK, redirection HTTP→HTTPS.
• Exposition des ports : seuls les ports nécessaires sont exposés publiquement (l’API et l’UI via le proxy). Les services internes (Postgres/Qdrant/MinIO/Redis) ne sont pas exposés.
• Horloge : NTP actif (évite des problèmes de JWT/certificats).

2) Secrets & configuration

• Secrets générés/saisis (mots de passe, clés, secrets inter‑services) et jamais committés.
• Le fichier .env de prod est stocké hors repo et protégé (ex. chmod 600).
• Les variables .env sont alignées sur .env.example (mêmes clés).

3) Déploiement

• Installation : docker compose up -d démarre l’ensemble des services sans crash.
• Santé : UI + API répondent via le domaine public (et non via des ports internes).
• Logs : pas d’erreurs répétées (boucles 401/500/502) après quelques minutes d’inactivité.

4) Auth & accès

• Création d’un compte admin et login UI OK.
• Logout OK, refresh page OK (cookie/JWT cohérents).
• Permissions testées (un utilisateur sans droits ne peut pas lire/ingérer hors de ses source_app).

5) Ingestion (test minimal)

• Upload d’un document test (PDF/Doc/HTML selon usage) via UI.
• Job ingestion terminé (success) et le document apparaît dans la liste.
• Le document est consultable et ses artefacts (MinIO/S3) existent.

6) RAG (test minimal)

• Question simple sur le document : réponse avec citations.
• Filtrage : test d’un source_app + workspace (si utilisé) cohérent.
• Follow‑ups : test multi‑tours (avec thread_id si une app externe est utilisée) :
  • résumé → bloc SUIVI présent,
  • “détaille S2” (ou “point B”) → réponse sourcée.

7) Cache & coûts (si activé)

• Cache exact : une même question renvoie un hit attendu (et réduit la latence).
• Cache sémantique : activé seulement si validé sur les cas d’usage (sinon OFF).
• Statuts cache visibles dans l’admin (observabilité).

8) Sauvegardes & restauration

• Plan de backup défini : Postgres + MinIO/S3 + volumes nécessaires.
• Test de restauration : au moins une restauration “à blanc” validée (environnement de test).

9) Upgrade & rollback

• Procédure d’upgrade documentée et comprise (migrations SQL, redémarrage).
• Rollback défini (tag/commit, sauvegarde DB, stratégie de retour arrière).

10) Exploitabilité & support

• Accès aux métriques/logs (au minimum : queries_log, erreurs API, état jobs ingestion).
• Contact support / process incident clarifiés (qui fait quoi : client vs intégrateur).