Comment VibeBI fonctionne.

1 · Vue d'ensemble

VibeBI est une plateforme d'analytique d'entreprise on-premise qui transforme un entrepôt brut en un service BI gouverné, en libre-service. Elle repose sur trois surfaces produit qui partagent des contrats mais séparent les responsabilités :

• VibeBI Desktop — l'interface power-user et d'administration : BI Agent (rapports), DG Agent (gouvernance des données), Explorer, Store, écrans de certification et d'accès.
• VibeBI Web — une surface consommateur légère, en lecture seule, pour découvrir et ouvrir les liens de partage de rapports gouvernés.
• VibeBI Server — le plan de contrôle on-premise sans interface : identité, contrôle d'accès, magasin de rapports, planification, audit, broker d'entrepôt et passerelle LLM.

VibeBI est livré avec son propre moteur agent embarqué. L'agent assume l'essentiel de la rédaction ; les stewards humains et les custodians IT approuvent et exécutent via des portes de certification — ils ne sont jamais le goulet d'étranglement.

2 · Architecture

La plateforme sépare le runtime agent (sur le laptop de l'utilisateur) du plan de contrôle (serveur on-prem). Les identifiants d'entrepôt et LLM n'atteignent jamais les appareils des utilisateurs finaux.

flowchart LR
  subgraph client["User laptop"]
    DT["VibeBI Desktop"]
    SC["Agent sidecar :4580
VibeBI agent engine"]
    DT --> SC
  end
  subgraph server["On-prem server :8080"]
    AUTH["Auth / SSO"]
    BRK["Warehouse broker
read-only SQL"]
    GW["LLM gateway"]
    STORE["Report store
Postgres + object store"]
    ACL["Access control"]
  end
  CH[("Warehouse (EDW)
bronze · silver · gold")]
  WEB["VibeBI Web viewer"]
  SC --> AUTH
  SC --> BRK
  SC --> GW
  BRK --> CH
  DT --> STORE
  WEB --> AUTH
  WEB --> STORE
  STORE --> ACL
            

3 · The Alchemist (médaillon)

Le périmètre de VibeBI commence au bronze — après ingestion. Il fait progresser les données dans un médaillon gouverné : bronze → silver → gold + sémantique. La règle d'airain : le gold n'est jamais construit directement à partir du bronze ; des vues silver certifiées doivent exister au préalable.

flowchart LR
  B["Bronze
source-shaped landing
source__entity"] --> S["Silver
silver_<domain>
conformed views"]
  S --> G["Gold
gold_<domain>
facts & dims"]
  G --> SEM["Semantics
entities · grain · tags"]
  SEM --> CR["Create / Web
published gold only"]
            

L'étape 1 (Bronze → Silver) couvre le profilage, l'analyse de qualité des données, la conformation et les propositions de domaine/classification. L'étape 2 (Silver → Gold) couvre la résolution d'entités, la rédaction de manifeste et de vues gold, la validation et les boucles de réparation. Les noms physiques de bases de données sont une configuration de déploiement, non codés en dur dans les binaires.

4 · Couche sémantique

La couche sémantique est ce qui rend les rapports durables. Au lieu de lier les tableaux de bord à des tables physiques, VibeBI expose entités, grains, mappings, métriques certifiées et métadonnées de modèles gold via un contrat unique.

• Métriques certifiées — mesures approuvées par les stewards, avec expression, grain et liaison gold. Une définition, réutilisée partout.
• Glossaire métier — termes au périmètre Société / Équipe / Personnel, avec définitions et alias, injectés dans les sessions agent.
• Tags de champs — chaque champ exposé porte ≥ 1 domaine de données et un niveau de classification.

Parce que les rapports lisent la couche sémantique, un changement de schéma en amont est absorbé dans le mapping silver→gold — les rapports en aval continuent de fonctionner sans réécriture.

# Agent discovery contract
GetSemantics      # entities, tables, grains, mappings, certified metrics
QueryVibeBIGold  # read-only SQL against published gold for real answers

5 · Gold BI learning (boucle d'auto-enrichissement)

Le gold n'est pas une publication unique. VibeBI capture les signaux de demande de chaque agent BI se transforment — questions des utilisateurs, métriques clairsemées ou nulles issues des sondes en direct, erreurs de requête, lacunes de jointure, et entités auxquelles l'assistant n'a pas pu répondre — et les transforme en améliorations revues par les stewards portant sur les business drivers, les manifestes et les jointures.

flowchart LR
  BI["BI Agent turns
chat + gold/silver probes"] --> SIG["Learning signals
catalog backlog"]
  SIG --> PROC["Process backlog
drivers · joins · hints"]
  PROC --> STW["Steward review
Gold → BI Learning tab"]
  STW --> GOLD["Approve drivers
publish manifests · build gold"]
  GOLD --> SEM["Updated semantics
fewer gaps next turn"]
  SEM --> BI
            

Les stewards restent maîtres du jeu. Les propositions créent bi_learning business drivers dans proposé statut jusqu'à approbation. Les reconstructions de manifeste pour métriques clairsemées reviennent à brouillon jusqu'à republication. Les stewards peuvent traiter étape par étape ou exécuter un pipeline complet (traiter → approuver → publier → construire le gold) depuis le desktop.

L'agent BI reçoit un lacunes d'apprentissage section lors des tours suivants (mesures clairsemées, entités non couvertes, drivers en attente) afin qu'il réponde honnêtement au lieu de re-sonder des colonnes connues comme nulles. L'agent DG utilise le même backlog lorsqu'il régénère les business drivers.

6 · Moteur agent

VibeBI exécute un runtime agent embarqué, conçu à cet effet — pas un chatbot généraliste. Deux rôles d'agent pilotent le produit :

7 · Modèle de gouvernance

Le contrôle d'accès utilise deux plans orthogonaux, définis par le client et appliqués à chaque champ, requête, rapport et partage.

Plan A — Domaines de données (thématique métier)

Domaines thématiques portés par le métier (Revenu, Supply Chain, Rémunération RH), avec sous-domaines optionnels. Chaque domaine a un propriétaire qui approuve les demandes d'accès — la partie métier responsable, pas le constructeur technique de la table.

Plan B — Paliers de sensibilité

Rôles (RACI)

• Data Domain owner — qui peut accéder à un domaine ; approuve les demandes d'accès ; cosigne les publications sensibles.
• Data steward — ce que les données signifient : définitions, grain, métriques, approbation de manifeste, certification DQ, et gold BI learning (traiter les signaux de chat → approuver les drivers → publier le gold).
• Custodian des données (IT) — comment les pipelines s'exécutent : exécution DDL, performance, sauvegardes, break-glass.

8 · Accès dérivé aux rapports

C'est la règle d'accès fondamentale, et elle n'a aucun contournement :

Les habilitations au niveau rapport (rôles, liens de partage) ne peuvent que restreindre l'accès — jamais l'élargir au-delà des habilitations sous-jacentes sur les données. Un modèle gold construit à partir de plusieurs tables silver hérite du union de leurs tags de domaine, de sorte que les owners de tous les domaines hérités deviennent les approbateurs.

9 · Déploiement

Le 100 % on-premise est notre avantage — VibeBI s'exécute entièrement dans votre réseau, avec des identifiants d'entrepôt et des clés de modèle qui n'en sortent jamais. Le pilote est une installation Docker Compose sur une seule VM ; la production se durcit en cluster HA sans refonte produit.

On-premise est le défaut, pas la seule option. La même architecture se déploie dans le cloud de votre choix — public, privé, hybride ou multi-cloud — afin que vous puissiez placer le plan de contrôle et l'entrepôt là où votre stratégie de résidence des données et d'exploitation l'exige.

Le serveur est volontairement léger — un binaire léger qui s'exécute sans peine sur du matériel standard. Tout le calcul agentique — profilage, extraction sémantique, génération de modèles, rédaction de rapports — s'exécute distribué sur le client desktop de chaque utilisateur, et non sur le serveur. Le serveur ne gère que la gouvernance, le courtage et la diffusion, de sorte que les besoins en ressources côté serveur restent minimaux, même lorsque votre base d'utilisateurs grandit.

Pour les clients sensibles aux données, VibeBI prend en charge un déploiement entièrement air-gapped : 100 % on-premise, zéro dépendance à Internet, en s'appuyant sur un LLM interne. Aucune donnée, aucune requête et aucune métadonnée ne quitte jamais votre réseau. L'ensemble du système — serveur, client desktop et LLM — fonctionne en boucle fermée à l'intérieur de votre périmètre.

• Les agents de création s'exécutent sur les laptops des utilisateurs (~100 créateurs concurrents).
• La visionneuse Web sert les consommateurs occasionnels sur PC et mobile (~500 concurrents).
• La production livre artefacts compilés — aucun code source dans les images runtime, aucune source map en production.
• Les rapports sont stockés sous forme de .report.ts + HTML généré, rendu via des API contrôlées par ACL.

10 · Invariants de sécurité

Cinq non-négociables valent pour chaque déploiement :

1. Les identifiants d'entrepôt jamais sur les appareils clients — tout le flux gold et sémantique passe par le broker serveur.
2. Les clés LLM jamais sur les appareils clients — passerelle serveur ou jetons émis de courte durée uniquement.
3. Les liens de partage sont des URL de capacité — identifiant opaque + SSO/ACL + jeton de rendu de courte durée, et non des chemins HTML statiques.
4. L'accès aux rapports est dérivé des habilitations sur les données — aucune autorisation de rapport autonome ne peut contourner les habilitations de domaine et de classification.
5. La production déploie des artefacts compilés — aucun src/ dans les images runtime.

11 · Stack technologique