Documentation — DataLab0

01

Vision globale du produit

Le projet vise à devenir un SaaS BI professionnel grande échelle, audelà d’un simple outil de dashboards. Le produit devra couvrir : dashboards, datasets, prépa…

02

Structure cible du projet

Le produit doit pouvoir évoluer comme une vraie plateforme SaaS BI enterpriseready. Structure cible en monorepo : Décision : monorepo structuré dès le départ, a…

03

Front-end et workspace

Le front doit supporter un workspace lourd, le multifenêtres, les dashboards, la data prep, les graphes visuels, le drag & drop et les éditeurs complexes. Choix…

04

Backend et plateforme SaaS

Le backend devra gérer les organisations, utilisateurs, permissions, workspaces, objets BI, datasets, pipelines, refresh, publications, audit et collaboration. …

05

Multi-tenant et organisation des espaces

Le SaaS doit gérer plusieurs clients/organisations. Décision : multitenant logique dès le départ ; hybride possible plus tard pour grands comptes. Tous les obje…

06

Navigation, dossiers et fil d’Ariane

Un workspace s’ouvre par défaut sur l’arborescence de l’espace partagé. L’utilisateur navigue dans les dossiers, clique sur un objet BI, et l’objet s’ouvre dans…

07

Runtime multi-fenêtres et Workspace Views

Le workspace est un environnement multifenêtres. Les objets BI s’ouvrent dans des fenêtres : dashboard, dataset, pipeline, widget collection, exploration, édite…

08

Layouts, plein écran et overlays

Il ne doit exister qu’un seul comportement de plein écran. Les déclencheurs doivent produire exactement le même résultat : double clic, clic sur nom de fenêtre …

09

Runtime dev, viewer et publication

Le produit doit séparer développement et consultation publiée. Un dashboard publié s’ouvre normalement dans le viewer. Pour modifier, action explicite : “Entrer…

10

Permissions, sécurité et collaboration

Cycle simple : création dans espace personnel, déplacement vers un dossier partagé accessible, publication selon permissions. Créer / modifier ≠ publier. Permis…

11

Dépendances, suppression, audit et versioning

Le système doit connaître les dépendances entre objets. Mettre en place un dependency graph pour impact analysis, suppression protégée, refresh intelligent, lin…

12

Datasets, semantic model et bindings

Un dataset est un objet central. Phase 1 : chaque dataset contient ses attributs, mesures, champs calculés et semantic model local. Pas de semantic layer global…

13

Widgets et Widget Collections

Un widget doit séparer apparence, configuration et données. On doit pouvoir réutiliser un widget en conservant sa forme mais en changeant les données. Les widge…

14

Dashboards, viewer et visualisation

Les dashboards seront composables. Ils contiennent widgets, filtres, interactions, bindings datasets, layout et thème. Le viewer publié est optimisé consultatio…

15

Data preparation et pipelines

Le produit doit intégrer des modules type SAS Guide : transformation, joins, filtres, calculs, outputs, preview et pipelines. Représentation : DAG visuel, nœuds…

16

Sources de données, connecteurs et stockage

Phase 1 : CSV, Excel, TXT, autres formats classiques et bases de données classiques. Phase 2 : BigQuery, Snowflake, Databricks, Redshift. Phase 3 : APIs SaaS mé…

17

Jobs, scheduler et performance

Les tâches longues ne doivent pas bloquer l’application : imports, refresh, pipelines, exports, IA, transformations. Phase 1 : workers async + queue. Phase 2 : …

18

UI, design system, tables et charts

Les datasets nécessitent des grilles avancées : preview, tri, filtres, édition, groupement, pivot potentiel. Préco initiale : AG Grid pour modules data avancés,…

19

Filtres, interactions, alertes, notifications et exports

Dashboards avec filtres globaux, filtres widget, interactions, crossfiltering, drilldown, drillthrough. Créer des alertes sur données : seuil dépassé, variation…

20

Recherche, API, IA et plugins

Retrouver dashboards, datasets, pipelines, widget collections, utilisateurs, workspaces et dossiers. Phase 1 : recherche, filtres, favoris, récents. Plus tard :…

21

Documentation intégrée, catalogue et qualité data

Documenter directement datasets, dashboards, pipelines, widgets et métriques. Phase 1 : descriptions, owners, notes. Phase 2 : documentation riche, lineage inté…

22

Enterprise, Ops, quotas et résilience

Limiter l’usage par organisation, puis éventuellement workspace. Concerné : stockage, refresh, exports, jobs, datasets, pipelines, IA. Supporter exploitation pr…

23

Mobile, offline, déploiement et i18n

Le workspace est desktopfirst. Le viewer doit être responsive. Pas d’édition mobile complète. Produit 100% online. Pas d’édition offline. Pas de sync locale com…

24

Décisions structurantes finales

1. React + Vite pour le workspace. 2. Backend modular monolith puis services. 3. PostgreSQL pour metadata. 4. Object storage pour fichiers. 5. Multitenant logiq…

25

Redondances et points de vigilance

1. Verrouillage collaboratif : lock hybride + lecture seule + indication utilisateur. 2. Runtime dev/viewer : séparation forte. 3. Multifenêtres : les objets s’…

26

Conclusion générale

Le projet est désormais défini comme une plateforme SaaS BI enterpriseready, avec un cœur workspace multifenêtres et une forte ambition data prep / BI. La direc…

27

Docker et déploiement

Le SaaS BI devra pouvoir être mis en production proprement sur serveur, avec isolation des composants critiques. Docker sert à : isoler les responsabilités ; év…

28

Gestion de la documentation

La documentation doit permettre à un développeur humain ou IA de comprendre : ce qui existe ; ce qui est cible ; ce qui est réellement implémenté ; ce qui est s…

29

Structure de l’archive livrable

L’archive livrable doit être compréhensible immédiatement par un développeur humain ou IA. Elle doit contenir : le projet réorganisé ; la documentation à la rac…

30

État d’implémentation de cette archive

Page d’accueil DataLab0 ajoutée à la racine /. Ancien prototype workspace conservé sur /workspace/. Documentation doc.html et /doc/ servie par le reverse proxy.…

31

Déploiement Docker — Version exécutable avec page d’accueil

Cette archive contient un dockercompose.yml à la racine. La version actuelle ajoute une page d’accueil dédiée à la racine du site. Avant cette évolution, le pro…

32

Déploiement serveur Proxmox / NAT — Notes d’exploitation

Cette archive a été déployée sur une VM Ubuntu dédiée dans Proxmox. Architecture utilisée : Pour cette archive, une seule VM suffit. Les services applicatifs so…

33

Domaine, HTTPS et sécurité de base — appv2dev.datalab0.com

Le déploiement public validé utilise : Le domaine DEV permet d’éviter l’accès brut par IP et prépare une séparation propre entre environnements : L’enregistreme…

34

Navigation UI et documentation compacte

Cette évolution améliore la navigation générale et la lisibilité du portail documentaire. Le logo BI du menu latéral est maintenant un lien vers la page d’accue…

35

Architecture EDGE / DEV / PROD — Reverse proxy centralisé

Cette évolution stabilise l’infrastructure DataLab0 en séparant clairement les rôles : EDGE : reverse proxy, HTTPS, routage public ; DEV : environnement de déve…

36

36 - Git, branches et CI/CD

Cette documentation décrit la mise en place Git + CI/CD de DataLab0. Elle couvre : le rôle du dossier local Windows ; le dépôt GitHub ; les branches dev et main…

Release

Historique des releases

Suivi produit des versions et builds DataLab0.

37

37 - UI Runtime Safety Rules

Règles de sécurité front/UI pour éviter les régressions.

38

38 - Desktop Runtime System

Fondation du window manager, layers, z-index, modales et overlays.

39

39 - Layout & Modal Corrections

Compaction de la modale de fermeture et correction des dispositions préconfigurées bord à bord.

40

40 - Debug Sessions

Topbar runtime, sessions debug, snapshots et export JSON local.

41

41 - Application Shell Topbar

Barre globale rétractable pour navigation/debug.

42

42 - Served Entrypoints

Cartographie des entrées HTML patchées.

Documentation projet