Packs métiers (post‑MVP / V1) — Aurora Nexus

0) Contexte et hypothèses validées

• Mode d’exploitation cible (Nexus) : mono-tenant par déploiement (une instance par client).
• tenant_id est conservé dans les données/contrats, mais il représente l’organisation (le client) et, en mono-tenant, il est unique et constant à l’échelle de l’instance.
• Plusieurs applications (internes ou externes) consommeront Nexus via API : chatbot, prise de note, “notebook”, veille, etc.
• L’objectif “packs métiers” est post‑MVP : ajouter de la valeur métier (RH, compta…) via tables, enrichissements et règles de retrieval, sans casser le socle.

1) Définitions (ne pas mélanger)

source_app (déjà en place)

• Identifie l’application productrice/consommatrice (ex: chatbot, notes, veille, default).
• Sert à :
  • permissionner les accès (user_permissions / source_apps_config),
  • tracer et filtrer les contenus dans Qdrant (metadata.source_app),
  • tracer les requêtes et coûts côté API (queries_log.source_app).

Statut actuel : le pipeline ingestion et la requête RAG supportent déjà source_app (filtre Qdrant + droits).

pack_id (partiellement en place)

• Doit représenter un périmètre “dataset / base de connaissance / espace” au sein d’un même client (ex: “CV”, “Clients”, “Missions”, “Compta 2024”, “Veille RH”).
• Un même source_app peut lire/écrire dans plusieurs packs.

Statut actuel : présent dans une partie des tables (caches/optimizer/logs) et transmis à la Gateway, mais pas encore utilisé comme filtre Qdrant ni comme routage ingestion.

“Pack métier” (post‑MVP)

• Un “pack métier” est un module applicatif (RH, compta, juridique…) qui :
  1. ajoute des tables spécialisées (migrations SQL),
  2. ajoute des jobs/pipelines d’enrichissement (extract → normalise → indexe),
  3. ajoute des règles de requêtes (combiner RAG + SQL structuré + scoring),
  4. ajoute des prompts/évaluations (et plus tard l’Optimizer) pour améliorer la qualité.

Le pack métier ne remplace pas le socle “documents génériques” : il s’appuie dessus.

2) “Source of truth” des données

Socle Nexus

• Postgres = source de vérité des entités (documents, jobs, logs, settings, utilisateurs).
• Qdrant = index vectoriel dérivé (chunks embeddings) + cache sémantique (option).
• MinIO = stockage objet (uploads + artefacts docling + backups).

Recommandation structurante (pour les packs)

• documents reste la table racine ; tout pack métier référence un document via document_id.
• Chaque table métier doit être scopée au minimum par :
  • tenant_id (constant en mono-tenant, mais présent),
  • un scope dataset : pack_id (recommandé) ou un équivalent (workspace/projet) si tu préfères.

3) Modèle de segmentation recommandé (mono-tenant + multi-app)

Décisions proposées

• tenant_id = le client (unique dans l’instance). Ne pas l’utiliser pour “CV vs clients”.
• pack_id = dataset / espace au sein du client (CV, Clients, etc.).
• source_app = application (chatbot, notes…).

Pourquoi ce modèle

• Tu évites de recréer un “faux multi-tenant” interne (source de bugs).
• Tu peux faire des requêtes :
  • “dans 1 pack” (CV uniquement),
  • “dans N packs” (CV + Missions),
  • “dans tous les packs autorisés” (search transverse),
  • “dans une app” (source_app=chatbot) ou multi-app.

4) Impacts attendus : Qdrant, MinIO, Postgres

Qdrant

Recommandation : 1 collection par version de pipeline embeddings (ex: aurora_documents_v1_3072), et filtrage par metadata.

Payload minimal conseillé par chunk :

• tenant_id (string UUID) — constant en mono-tenant
• pack_id (string UUID) — optionnel tant que non implémenté, mais cible post‑MVP
• source_app (string)
• document_id (string UUID)
• chunk_id (int) et/ou source_ref (page/section)
• lang, tags, etc.

Pourquoi :

• une app peut requêter plusieurs packs sans jongler avec plusieurs collections,
• tu gardes des opérations simples (reindex / snapshot),
• tu évites l’explosion du nombre de collections.

MinIO

Recommandation : garder les buckets fonctionnels (uploads/artifacts/backups) et isoler par préfixes :

• uploads/{tenant_id}/{pack_id}/... (ou {tenant_slug} tant que pack_id n’existe pas)
• artifacts/{tenant_id}/{pack_id}/...

Pourquoi :

• facile à opérer et à migrer,
• compatible “multi-apps” (un même document est un objet ; les artefacts sont dérivés).

Postgres

Recommandation : tout ajout “pack métier” doit :

• référencer documents(id),
• être scoped tenant_id + pack_id,
• être indexé sur (tenant_id, pack_id) et sur les clés de recherche métier (ex: email, SIRET, skills).

5) Contrats API à prévoir (post‑MVP pack_id / packs métiers)

Endpoints “socle” (déjà existants ou à faire évoluer)

• Ingestion :
  • accepter source_app (déjà) et ajouter pack_id dans upload/init + upload/commit.
  • persist DB : stocker pack_id côté documents et ingestion_jobs (si retenu).
  • indexation Qdrant : écrire metadata.pack_id.
• Query RAG :
  • accepter pack_id (déjà dans la requête) et l’appliquer au filtre Qdrant,
  • supporter pack_ids[] (requête multi-packs) si besoin.
• Admin :
  • CRUD des packs (liste, create, disable) + permissions (par user/source_app).

Endpoints “pack métier”

Un pack métier peut exposer :

• des endpoints CRUD métier (ex: candidats, missions),
• des endpoints d’enrichissement (reparse CV, extraction skills),
• des endpoints de recherche hybride (RAG + SQL structuré) : “top candidats pour une mission”.

6) Risques à anticiper (et comment les éviter)

• Confusion tenant_id vs pack_id : crée des “silos” incohérents et des bugs d’accès.
  • Mitigation : conventions écrites + validations (en mono-tenant, tenant_id doit toujours être le tenant de l’instance).
• Dérive “tables métier sans référence documents” : tu perds la traçabilité et la qualité RAG.
  • Mitigation : document_id obligatoire pour tout item issu d’un doc.
• Explosion collections Qdrant par app : bloque les requêtes multi-packs et augmente l’ops.
  • Mitigation : une collection par pipeline embeddings ; filtrage par metadata.
• Artefacts MinIO non reliés : nettoyage/retention impossibles.
  • Mitigation : convention de chemins + DB artifacts liée aux documents + jobs.

7) Tests & recette recommandés (post‑MVP)

Scénarios (Given/When/Then) :

1. Multi-app / même dataset

• Given un document ingéré avec source_app=notes dans pack=A
• When le chatbot (source_app=chatbot) requête le même pack
• Then la réponse cite ce document et aucune source hors pack.

2. Multi-packs

• Given des docs dans pack=A et pack=B
• When query avec pack_ids=[A,B]
• Then les citations proviennent des deux packs.

3. Pack métier RH (exemple)

• Given un CV ingéré dans pack=CV
• When l’enrichissement RH tourne
• Then les tables métier (skills, expériences) sont remplies et référencent document_id.

8) Roadmap proposée (alignée avec MVP)

MVP (maintenant)

• Stabiliser socle : ingestion documents, RAG, permissions source_app, observabilité, sécurité.
• Garder tenant_id constant (mono-tenant) ; ne pas ouvrir de multi-tenant.

Post‑MVP (packs métiers + pack_id)

• Implémenter pack_id end‑to‑end (ingestion → DB → Qdrant → query).
• Ajouter un registre des packs (DB + UI admin).
• Introduire le premier pack métier (ex: RH) avec migrations + enrichissement + tests.

Post‑MVP (Optimizer)

• Brancher l’Optimizer sur des métriques stables (queries_log/llm_evaluation) et des datasets/pack_id bien définis.
• Garantir que l’Optimizer recommande uniquement (jamais d’auto-apply) et que l’audit (config_audit_log) est complet.