Un ERP figé alimente un vrai tableau Grafana

Objectif Donner à la direction un tableau de ventes à jour à partir des exports d'un ERP qu'on ne touche plus.

L'ERP exporte ses ventes et son catalogue en CSV. lumnik les joint, et Grafana lit l'entité par un compte PostgreSQL en lecture seule, borné à son tenant.

lundi: 10 450 €
mardi, l'export change: 14 200 €
la vente modifiée n'apparaît qu'une fois

lumnik Open
Ventes
BI
Connector
Entity

products.csv

product_id,product_name,category
P-100,Laptop Pro 14,Computing
P-200,27-inch Monitor,Computing
P-300,Standing Desk,Furniture
P-400,Ergonomic Chair,Furniture

sales-monday.csv

sale_id,sale_date,order_no,product_id,quantity,amount,status
SALE-001,2026-10-19,SO-1001,P-100,2,4000.00,NEW
SALE-002,2026-10-19,SO-1002,P-200,5,1500.00,SHIPPED
SALE-003,2026-10-19,SO-1003,P-300,3,1800.00,PREPARING
SALE-004,2026-10-19,SO-1004,P-400,8,1200.00,PREPARING
SALE-005,2026-10-19,SO-1005,P-100,1,1500.00,NEW
SALE-006,2026-10-19,SO-1005,P-200,1,450.00,SHIPPED

manifests/10-products.yaml

apiVersion: connectors.lumnik.io/v1kind: Connectormetadata:  name: legacy-bi-products-b  connector_type: csv-file  scopes: [sales-bi]spec:  transport:    kind: local    path: /tmp/lumnik-scenario/legacy-sales-grafana/b/products.csv  parser:    has_header: true  after_process: none  mapping:    dataset:      - require-headers:          columns: [product_id, product_name, category]    cell:      - clean:          columns: [product_name, category]          strip: true          remove-control-chars: true          normalize-unicode: NFC

manifests/20-sales.yaml

apiVersion: connectors.lumnik.io/v1kind: Connectormetadata:  name: legacy-bi-sales-b  connector_type: csv-file  scopes: [sales-bi]spec:  transport:    kind: local    path: /tmp/lumnik-scenario/legacy-sales-grafana/b/sales.csv  parser:    has_header: true  after_process: none  mapping:    dataset:      - require-headers:          columns: [sale_id, sale_date, order_no, product_id, quantity, amount, status]    cell:      - clean:          columns: [order_no, status]          strip: true          remove-control-chars: true          normalize-unicode: NFC      - upper: { columns: [status] }      - parse-number: { column: quantity }      - parse-number: { column: amount }

$ lm apply -f manifests/10-products.yaml
Applied connector "legacy-bi-products-b" — 1 endpoint

$ lm apply -f manifests/20-sales.yaml -o json
{
  "name": "legacy-bi-sales-b",
  "connectorId": "aa90f088-2068-4265-8725-ff15e372d140",
  "endpointsApplied": 1
}

$ lm connector run legacy-bi-products-b
run scheduled: d800163e-98be-4daa-8f6a-8f7e7fbed3b9

$ lm run get d800163e-98be-4daa-8f6a-8f7e7fbed3b9
ID        CONNECTOR             ENDPOINT  STATUS     IN  OUT  SKIPPED  DEAD-LETTERS  STARTED           ENDED             EVALUATED
d800163e  legacy-bi-products-b  default   Completed  4   4    0        0             2026-11-03 19:20  2026-11-03 19:20  no

$ lm connector run legacy-bi-sales-b
run scheduled: dfbca9cd-8ecb-402f-93e0-58b3e546585a

$ lm run get dfbca9cd-8ecb-402f-93e0-58b3e546585a
ID        CONNECTOR          ENDPOINT  STATUS     IN  OUT  SKIPPED  DEAD-LETTERS  STARTED           ENDED             EVALUATED
dfbca9cd  legacy-bi-sales-b  default   Completed  6   6    0        0             2026-11-03 19:20  2026-11-03 19:20  no

manifests/30-sale-with-category.yaml

kind: Entityname: SaleWithCategoryBdescription: Legacy ERP sales enriched with product and category labels for BI.match: [sale_id]scopes: [sales-bi]sources:  - table: t_legacy_bi_sales_b    map:      sale_id: sale_id      sale_date: sale_date      order_no: order_no      product_id: product_id      quantity: quantity      amount: amount      status: statusjoins:  - table: t_legacy_bi_products_b    from: product_id    to: product_id    map:      product_name: product_name      category: category

$ lm entity apply -f manifests/30-sale-with-category.yaml
Applied entity "SaleWithCategoryB" → connector."v_salewithcategoryb"

boundary: Monday KPIs visible, unrelated relations denied, cross-tenant override denied
reader KPIs: 6 lines · 5 orders · EUR 10450.00
grafana: datasource, six panels and expected KPIs are live

preuves: replay.log, kpis-monday.csv, kpis-tuesday.csv, reader-boundary.txt, sale-003-tuesday.txt · transform v1

sales-tuesday.csv

sale_id,sale_date,order_no,product_id,quantity,amount,status
SALE-001,2026-10-19,SO-1001,P-100,2,4000.00,NEW
SALE-002,2026-10-19,SO-1002,P-200,5,1500.00,SHIPPED
SALE-003,2026-10-19,SO-1003,P-300,3,1800.00,SHIPPED
SALE-004,2026-10-19,SO-1004,P-400,8,1200.00,PREPARING
SALE-005,2026-10-19,SO-1005,P-100,1,1500.00,NEW
SALE-006,2026-10-19,SO-1005,P-200,1,450.00,SHIPPED
SALE-007,2026-10-20,SO-1006,P-100,1,2500.00,SHIPPED
SALE-008,2026-10-20,SO-1007,P-400,8,1250.00,SHIPPED

$ lm connector run legacy-bi-sales-b
run scheduled: 8981e785-803c-4954-94f2-71362992c084

$ lm run get 8981e785-803c-4954-94f2-71362992c084
ID        CONNECTOR          ENDPOINT  STATUS     IN  OUT  SKIPPED  DEAD-LETTERS  STARTED           ENDED             EVALUATED
8981e785  legacy-bi-sales-b  default   Completed  8   8    0        0             2026-11-03 19:20  2026-11-03 19:20  no

Limites

Grafana interroge PostgreSQL à intervalle régulier; ce n'est pas du streaming.
Le compte de lecture est créé pour la démonstration; en production, ses identifiants vont dans un gestionnaire de secrets, avec la même borne.
Le compte lit les tables du schéma connector: une évolution de la vue demande de revoir ses droits.
Données synthétiques.

Ventes · tableau de bord

La direction veut un tableau de ventes.

L'ERP ne bouge plus.

Il sait seulement exporter ses ventes et son catalogue en CSV.

ERP fictif · données synthétiques

Le problème

Les ventes et les produits sont dans deux fichiers.

Une vente porte un id de produit, pas sa catégorie.
Chaque matin, l'export remplace celui de la veille.
Grafana ne lit pas un CSV qui change.

Rien n'est modifié

L'ERP exporte comme avant.

Deux fichiers CSV, tels quels.
Grafana garde sa source PostgreSQL.
Aucun connecteur Grafana à écrire.

Ce qu'il a fallu écrire

joins:
  - table: t_legacy_bi_products_b

Une jointure donne la catégorie à chaque vente.

Le scénario complet tient en 3 fichiers de déclaration, 71 lignes.

Lundi puis mardi

10 450 €, puis 14 200 €.

Lundi: 6 lignes, 5 commandes.
Mardi: 8 lignes, 7 commandes.
SALE-003 passe à SHIPPED, une seule fois.

Rejeu du 3 novembre 2026.

Qui lit quoi

Grafana lit, et seulement son tenant.

Un rôle PostgreSQL en lecture seule.
SELECT sur la vue et ses deux tables.
Une politique le garde dans son tenant.

La limite

Ce n'est pas du streaming.

Grafana interroge PostgreSQL à intervalle régulier.
Les identifiants vont dans un gestionnaire de secrets.
Une évolution de la vue demande de revoir les droits.

Essayer

Le scénario se rejoue de bout en bout.

CSV, entité, compte de lecture, Grafana: chaque étape est publiée avec sa sortie.

Ce scénario tourne sur lumnik Open, gratuit et open source.

Essayer lumnik Open →