Plateforme de données — Architecture trois étages

Victor Lequay — Mars 2026 — Document de travail, v3 (post revue externe)

Le problème

Notre stack actuelle (datapipe + dataprovider + hemis) a été conçue pour une vision de la donnée qui ne correspond plus à nos besoins. L'audit du code existant révèle des problèmes structurels majeurs.

Problèmes identifiés dans le code

1. Aucune préservation des données brutes Quand Enedis envoie des index demi-horaires en Wh, DataConverter convertit immédiatement en kWh et mappe vers FIELD_NAME.DIFF. Le XML SOAP original est jeté. Si la logique de conversion a un bug ou si les hypothèses changent, impossible de retraiter depuis la source. L'API Enedis a une fenêtre glissante de 24 mois — au-delà, la donnée source est perdue.

2. La distinction FACT/SEN n'est pas respectée CT-Injector écrit les relevés Enedis bruts avec nature=FACT, alors que FACT signifie "valeur calculée/agrégée". Hemis écrit les mesures capteurs (SEN) ET les agrégats (FACT). Rien n'empêche d'écrire du brut comme du calculé. La distinction n'existe que par convention.

3. Deux versions de DataProvider en production Hemis utilise 1.2.0-SNAPSHOT (Java 8), datapipe utilise 2.0.0-SNAPSHOT (Java 21). Les ontologies, politiques de rétention et signatures d'API peuvent diverger. Aucun test de compatibilité.

4. Pertes de données silencieuses DataProvider.persistData() attrape TSDBException et InvalidParameterException en interne sans les relancer. Datapipe retourne HTTP 200. CT-Injector avance lastFetchTime. Aucune donnée écrite, aucune anomalie envoyée. Mécanisme de perte latent sans chemin de détection.

5. Double ingestion Enedis Hemis (EnedisComManager) et CT-Injector peuvent ingérer les données Enedis pour le même bâtiment. Les deux écrivent dans nature=FACT, group=CPOW_DIFF mais avec des dataSourceId différents. Sans filtre dsid, les requêtes retournent les deux.

6. Trois instances datapipe = trois systèmes différents datapipe.ubiant.io (DATASTORE), datapipe-rt.ubiant.io et datapipe-flexompremium (HEMIS/BRIDGES) ont des ontologies, des rétentions, et des comportements différents. Le routage dépend de custom_datapipe_url dans metainfodb, vérifié seulement par ct-injector.

7. Le dispatch crée des données dérivées indistinguables des mesures Quand CT-Injector dispatche l'énergie d'un parent vers ses enfants au prorata de surface, les données enfants sont stockées avec les mêmes tags (FACT/CPOW_DIFF) que les mesures réelles. Aucun tag n'indique qu'il s'agit d'estimations.

8. Qualité fragmentée Le champ RELIABILITY dans InfluxDB 1.8 et les anomalies dans GEDB (InfluxDB 2.4) sont deux signaux de qualité complètement déconnectés. Un consommateur ne peut pas corréler les deux.

9. La transformation manageCpid() est irréversible En profil DATASTORE, CPOW + cpid=DIFF est réécrit en CPOW_DIFF + cpid=null. L'information cpid originale est perdue en base.

Architecture proposée : trois dataspaces

Inspirée de l'architecture medallion (bronze/silver/gold) mais adaptée à notre domaine.

Principe directeur : logique forte > distribution. Les trois couches sont des séparations logiques (schémas dans une même base), pas nécessairement trois services distincts dès le départ. Les microservices viendront quand le scaling l'imposera.

Vue d'ensemble

Fournisseurs          BRUT              CORRIGÉ            ENRICHI
                    (Bronze)           (Silver)            (Gold)
                       │                  │                  │
Enedis ──────┐    ┌────┴─────┐     ┌─────┴──────┐    ┌─────┴──────┐
GRDF ────────┤    │ Ingestion│     │Harmonisation│    │ Synthèse   │
CPCU ────────┤───▶│ Archivage│────▶│ Correction  │───▶│ Agrégation │
Fraîcheur ───┤    │ Contrôle │     │ Fiabilité   │    │ Prédiction │
Capteurs ────┘    │ Alerte   │     │ Gap filling │    │ KPIs       │
                  └──────────┘     └────────────┘    └────────────┘
                       │                  │                  │
                  Donnée brute      Donnée fiable      Donnée métier
                  (preuve légale)   (exploitable)      (aide décision)

1. BRUT (Raw Dataspace)

Rôle : Ingérer, archiver, ne pas transformer. Source de vérité légale.

Double stockage : un TSDB seul ne suffit pas pour la preuve légale. Le Raw est composé de :

1. Object storage (S3/MinIO, mode WORM) — payloads originaux (XML SOAP Enedis, JSON GRDF, réponses CPCU) archivés tels quels. Immuable. Preuve légale.
2. Base temps (TimescaleDB ou autre) — valeurs extraites des payloads, indexées pour requêtage rapide. Liées au payload source.

Modèle de données enrichi (vs le modèle initial trop pauvre) :

CREATE TABLE raw.events (
    id                  BIGSERIAL,
    received_at         TIMESTAMPTZ NOT NULL DEFAULT now(),  -- quand on l'a reçu
    source_timestamp    TIMESTAMPTZ NOT NULL,                -- timestamp du fournisseur
    source_interval_start TIMESTAMPTZ,                       -- début de la période mesurée
    source_interval_end   TIMESTAMPTZ,                       -- fin de la période mesurée
    meter_id            TEXT NOT NULL,                        -- PRM, PCE, n° client
    provider            TEXT NOT NULL,                        -- enedis, grdf, cpcu, ...
    entity_id           TEXT,                                 -- ID bâtiment/entité
    value               DOUBLE PRECISION NOT NULL,           -- valeur brute
    unit                TEXT NOT NULL,                        -- Wh, m3, MWh, °C
    quality_code        TEXT,                                 -- code qualité fournisseur (Enedis: N, Tc, Iv, Ec)
    source_timezone     TEXT DEFAULT 'UTC',                   -- fuseau du fournisseur
    payload_ref         TEXT,                                 -- lien vers payload S3/MinIO
    payload_hash        TEXT,                                 -- SHA-256 du payload original
    parser_version      TEXT,                                 -- version du parseur utilisé
    source_event_id     TEXT,                                 -- ID unique côté fournisseur si disponible

    PRIMARY KEY (source_timestamp, meter_id, provider)
);

SELECT create_hypertable('raw.events', 'source_timestamp');

2. CORRIGÉ (Corrected Dataspace)

Rôle : Nettoyer, harmoniser, qualifier. Produire un flux exploitable avec garanties de qualité.

Principe clé : append-only versionné, pas mutable. On ne modifie jamais une valeur corrigée — on la remplace par une nouvelle version. Chaque valeur pointe vers sa source brute et la règle qui l'a produite.

Modèle versionné :

CREATE TABLE corrected.values (
    id                  BIGSERIAL,
    ts                  TIMESTAMPTZ NOT NULL,                -- timestamp harmonisé (UTC)
    meter_id            TEXT NOT NULL,
    provider            TEXT NOT NULL,
    entity_id           TEXT,
    value               DOUBLE PRECISION NOT NULL,           -- valeur corrigée (kWh, kWh, °C)
    unit                TEXT NOT NULL,
    reliability         DOUBLE PRECISION NOT NULL DEFAULT 1.0,
    origin              TEXT NOT NULL DEFAULT 'measured',     -- measured, dispatched, interpolated, estimated
    raw_event_id        BIGINT,                              -- FK vers raw.events
    rule_version        TEXT,                                 -- version de la règle de correction
    supersedes_id       BIGINT,                              -- version précédente (NULL si première)
    is_current          BOOLEAN NOT NULL DEFAULT true,
    produced_at         TIMESTAMPTZ NOT NULL DEFAULT now(),

    PRIMARY KEY (ts, meter_id, provider, produced_at)
);

SELECT create_hypertable('corrected.values', 'ts');
CREATE INDEX idx_corrected_current ON corrected.values (meter_id, provider, ts) WHERE is_current = true;

Conversion gaz — PCS versionné :

CREATE TABLE corrected.pcs_coefficients (
    id              SERIAL PRIMARY KEY,
    zone            TEXT NOT NULL,            -- zone géographique
    meter_id        TEXT,                     -- NULL = zone entière, sinon compteur spécifique
    valid_from      DATE NOT NULL,
    valid_to        DATE,
    pcs_kwh_per_m3  DOUBLE PRECISION NOT NULL, -- coefficient de conversion
    source          TEXT,                     -- GRDF bulletin, contrat, etc.
    UNIQUE(zone, meter_id, valid_from)
);

3. ENRICHI (Enriched Dataspace)

Rôle : Calculer, agréger, prédire. Indicateurs métier.

Principe clé : utiliser au maximum les continuous aggregates de TimescaleDB pour les agrégations standard (SUM, AVG, MIN, MAX par jour/mois/an). Le service d'enrichissement ne gère que la logique métier complexe.

Choix technologiques — Discussion

Rappel : ACID

ACID (Atomicity, Consistency, Isolation, Durability) garantit qu'une écriture en base est soit complètement réussie, soit complètement annulée. PostgreSQL/TimescaleDB offre ces garanties. InfluxDB et ClickHouse non — une écriture peut partiellement réussir sans transaction. Pour des données append-only (Raw), c'est acceptable (on peut ré-écrire). Pour le Corrigé versionné, ACID garantit qu'un remplacement de version est atomique.

Candidats

Sept moteurs évalués. Prometheus inclus pour référence.

Comparaison détaillée

Architecture et modèle de données

Langage de requête

Performance (benchmarks TSBS IoT + benchmarks éditeurs, 2024-2025)

Attention : les benchmarks éditeurs sont biaisés. Les benchmarks TSBS sont plus neutres mais ne couvrent pas tous les candidats.

Stockage et compression

VictoriaMetrics affiche ~0.4 octet/point. Ces chiffres viennent de VM — à vérifier sur nos données.

Garanties et fonctionnalités

Opérationnel

Notes sur les candidats

InfluxDB 3.x — réécriture Rust avec Apache Arrow/DataFusion/Parquet. Performances annoncées impressionnantes mais produit jeune (~2 ans), breaking changes vs v2. SQL ajouté mais Flux conservé (maintenance mode). Le format Parquet le rapproche de ClickHouse. Pas recommandé pour un déploiement critique aujourd'hui. À surveiller.

Prometheus — système de collecte et d'alerting avec stockage local limité (15j par défaut). Pour le stockage longue durée → backend externe (Thanos, Cortex, VictoriaMetrics). Pertinent comme couche de collecte (Prometheus → remote_write → VM) ou pour le monitoring de notre infra.

QuestDB — sous-estimé dans les versions précédentes. Supporte les JOIN (incluant ASOF JOIN, très utile pour le time-series), le PostgreSQL wire protocol, et l'InfluxDB Line Protocol. Candidat sérieux.

ClickHouse — la formulation "non ACID" est à nuancer. Les INSERT sont atomiques dans certains cas, transactions expérimentales existantes. Pas un moteur transactionnel complet.

VictoriaMetrics / Prometheus — analyse approfondie

VM et Prometheus sont souvent proposés pour le stockage time-series. Ils ont des arguments forts : communauté massive, performances éprouvées, compression record (VM), écosystème riche (Grafana, AlertManager), et nos données sont quasi exclusivement des floats. La question mérite une réponse précise.

Ce qui fonctionne parfaitement : relevés de compteurs (kWh, m³, °C) → float64. Métadonnées (meter_id, provider, entity_id) → labels string. Ingestion via ILP ou remote_write. Compression VM imbattable. Ops simple (binaire unique).

Ce qui coince pour notre cas d'usage :

1. Pas de jointures relationnelles — Le Corrigé a besoin de traçabilité : "cette valeur corrigée vient de l'événement brut X, via la règle Y, remplaçant la version Z." En MetricsQL, impossible d'exprimer un JOIN corrected↔raw. Il faudrait faire deux requêtes et joindre côté application — faisable mais fragile et lent. Si les audits de traçabilité sont rares (pas temps réel), c'est tolérable. Si c'est un besoin quotidien, non.

2. Pas de corrections versionnées — VM écrase un point au même timestamp pour la même métrique. Pas de supersedes_id, pas de is_current, pas d'historique de version. On perd la capacité de dire "la valeur était X, puis on l'a corrigée en Y le 15 mars avec la règle v2." Encoder la version dans les labels (rule_version="v2") est possible mais devient ingérable.

3. Sampling implicite dans les requêtes — VM et Prometheus peuvent silencieusement sous-échantillonner les résultats quand il y a trop de points dans la plage demandée. Pour un dashboard de monitoring, c'est transparent. Pour des données de facturation où chaque kWh compte, une approximation silencieuse est inacceptable. Contrôlable via le paramètre step, mais il faut savoir que ça existe.

4. Pas de continuous aggregates — TimescaleDB maintient automatiquement des vues matérialisées incrémentales (agrégations jour/mois/an mises à jour à chaque insertion). VM a du downsampling (Enterprise) et des recording rules, mais moins intégrés et moins flexibles que des agrégats SQL.

5. Pas de transaction outbox — Le pipeline nécessite "écrire les données brutes ET marquer pour traitement correctif dans une seule opération atomique." PostgreSQL le fait trivialement (même transaction). VM n'a aucun concept de transaction.

Conclusion : VM/Prometheus est le meilleur choix si on ne fait que du monitoring (stocker des métriques, afficher des dashboards, alerter sur des seuils). Notre cas a trois besoins que le monitoring ne couvre pas : - Traçabilité relationnelle (raw → corrected) - Corrections versionnées (historique, rejeu) - Résultats de requête exacts (pas de sampling implicite sur données facturables)

Si on accepte de renoncer à ces trois besoins, VM est le meilleur choix. Si on les garde, il faut SQL pour au moins le Corrigé/Enrichi. VM reste un excellent candidat pour le Raw seul (option E).

GreptimeDB — candidat récent (v1.0 2026, Rust, Apache 2.0) qui combine les avantages de VM et TimescaleDB : SQL complet avec JOINs, PromQL (~90% compatible), ILP natif, PostgreSQL wire protocol, continuous aggregates (Flow engine), stockage S3 natif (compute-storage separation), multi-types (pas limité à float64), edge-compatible (700K pts/s sur ARM, <150MB RAM).

C'est le seul candidat qui offre SQL + PromQL + ILP + JOINs + continuous aggregates + S3 natif dans un seul moteur. En théorie, il pourrait couvrir les trois étages sans compromis majeur — le SQL avec JOINs résout le problème de traçabilité du Corrigé, les continuous aggregates couvrent l'Enrichi, et l'ILP + S3 couvrent le Raw.

Ce qui manque : pas d'ACID (même limitation que VM/ClickHouse/QuestDB — les corrections versionnées ne sont pas atomiques), benchmarks indépendants quasi inexistants (produit trop jeune), et risque éditeur significatif (startup de ~3 ans, communauté petite). Beaucoup de "?" dans les tableaux — les performances serveur ne sont pas encore bien documentées hors du cas edge/IoT.

Verdict : le candidat le plus prometteur sur le papier. Si GreptimeDB mûrit et prouve ses performances à notre échelle, il pourrait devenir le "un seul moteur pour tout" qui rend l'option A (TimescaleDB pour tout) obsolète avec de meilleures performances. Aujourd'hui, trop jeune pour un pari en production. À évaluer via un POC si le timing le permet.

Besoins par étage

Options

Option A : TimescaleDB pour tout (recommandée pour démarrer)

1 cluster PostgreSQL + TimescaleDB
├── schema raw      (hypertable, compression policies)
├── schema corrected (hypertable, versionné)
├── schema enriched  (continuous aggregates + tables)
└── + S3/MinIO pour les payloads bruts

Option B : InfluxDB 2.x (Raw) + TimescaleDB (Corrigé/Enrichi)

Option C : ClickHouse (Raw) + TimescaleDB (Corrigé/Enrichi)

Option D : QuestDB (Raw) + TimescaleDB (Corrigé/Enrichi)

Option E : VictoriaMetrics (Raw) + TimescaleDB (Corrigé/Enrichi)

Option F : GreptimeDB pour tout (à évaluer)

1 cluster GreptimeDB
├── database raw      (ILP ingestion, S3 backend)
├── database corrected (SQL + JOINs, Flow engine)
├── database enriched  (continuous aggregates)
└── + S3/MinIO pour les payloads bruts (en plus du stockage natif S3)

Verdict : le candidat le plus complet sur le papier — il résout les limitations de VM (pas de SQL/JOINs) sans la lourdeur de TimescaleDB (compression, S3 natif). Mais trop jeune pour un pari en production aujourd'hui. Recommandation : POC pour valider les performances réelles et la stabilité avant tout engagement.

Licensing

Tous les candidats sont open-source (Apache 2.0) et gratuits en self-hosted pour le core. Les features entreprise (RBAC, TLS, downsampling avancé, support) sont payantes chez QuestDB, VictoriaMetrics et ClickHouse. TimescaleDB a une licence "Timescale License" (TSL) pour la Community Edition : gratuite en self-hosted, mais interdiction de la revendre comme service managé.

Le coût réel n'est pas la licence — c'est l'infrastructure (CPU, RAM, disque).

Coût réel à notre échelle

Nous gérons des dizaines de milliers de bâtiments. Estimation pour 10 000 bâtiments, ~5 compteurs/bâtiment, relevés horaires, 5 ans de rétention sur le Raw :

• 50 000 compteurs × 8 760 pts/an × 5 ans = ~2.2 milliards de points

Ces chiffres concernent le Raw seul. Le Corrigé et l'Enrichi sont moins volumineux (données agrégées). Les octets/point sont des moyennes de benchmarks éditeurs — à valider sur nos données réelles.

À cette échelle, la compression est le facteur de coût dominant. VictoriaMetrics stocke en ~2 TB ce que TimescaleDB sans compression stocke en 63 TB. Même avec les compression policies activées (7-11 TB), la différence reste 5-10x.

Et c'est pour 10 000 bâtiments. Si on passe à 30 000 ou 50 000, les chiffres se multiplient linéairement.

Résumé des options

Recommandation

Avec des dizaines de milliers de bâtiments, l'option A (TimescaleDB pour tout) reste viable grâce aux compression policies, mais n'est plus l'évidence. Le Raw sera le plus gros poste de stockage sur 5+ ans, et TimescaleDB est le moteur le plus gourmand en disque.

Deux approches :

1. Commencer simple (option A) — 1 cluster TimescaleDB, compression policies activées, ~70-110€/mois de stockage Raw. On accepte le surcoût disque en échange de la simplicité opérationnelle (un seul moteur, SQL partout, ACID). Si le coût devient un problème, on migre le Raw vers un moteur plus compact.

2. Optimiser dès le départ (option E ou C) — Raw sur VictoriaMetrics ou ClickHouse (~10-70€/mois), Corrigé/Enrichi sur TimescaleDB. Plus complexe à opérer (deux moteurs), mais coût de stockage 5-10x inférieur sur le long terme.

Le choix dépend de la priorité : simplicité ops vs coût stockage. À 10 000 bâtiments, la différence est de ~50-100€/mois. À 50 000 bâtiments, elle passe à ~250-500€/mois. Ce n'est pas négligeable mais ce n'est pas non plus un deal-breaker.

GreptimeDB (option F) mériterait un POC : s'il tient ses promesses, il offre la simplicité d'un seul moteur (comme A) avec le stockage S3 natif (comme E/C). Mais trop jeune pour s'engager sans validation.

Langage

Go. Cohérent avec metainfodb, gedb, ct-injector-go, consent-manager. Binaire statique, déploiement Nomad.

Pipeline — pas de microservices day 1

1 service Go (ou jobs internes SQL/cron)
    │
    ├── Ingestion → raw.events + S3 payload
    ├── Correction (cron/trigger) → corrected.values
    └── Enrichissement → enriched.* (continuous aggregates + jobs)
    │
    └── 1 cluster PostgreSQL+TimescaleDB

Pas de message broker au démarrage. LISTEN/NOTIFY n'est pas un bus fiable (limite 8KB, notifications non garanties, drops sous charge). Pattern recommandé : - Table outbox transactionnelle : l'ingestion écrit dans raw.events ET dans raw.outbox dans la même transaction - Consumer idempotent : le correcteur poll l'outbox, traite, marque comme fait - NOTIFY = simple wake-up (optionnel) pour réduire la latence du polling

Référence : Transactional Outbox Pattern

Les services séparés viendront quand le scaling l'imposera — pas avant.

Ontologie

Aujourd'hui, l'ontologie est codée en dur dans DataSourceTypeOntology.java (~5000 lignes). C'est le cœur du couplage.

Proposition : externaliser l'ontologie dans une configuration déclarative (YAML ou table PostgreSQL) chargée par chaque étage.

data_types:
  electricity_consumption:
    raw_unit: Wh
    corrected_unit: kWh
    conversion: divide_1000
    groups: [CPOW_DIFF]
    retention_raw: 5y
    retention_corrected: infinite
    aberration_rules:
      min: 0
      max_delta_per_hour: 100000  # dépend du type de bâtiment
    gap_fill_max_hours: 24

  gas_consumption:
    raw_unit: m3
    corrected_unit: kWh
    conversion: pcs_table    # PCS versionné par zone/période, pas un simple multiply
    groups: [CGAS_DIFF]
    pcs_source: corrected.pcs_coefficients
    ...

Note gaz : la conversion m³ → kWh n'est PAS un simple multiply_pcs. Le PCS (Pouvoir Calorifique Supérieur) dépend de l'altitude, de la composition du gaz, et de la pression. Il est recalculé régulièrement par GRDF. La table pcs_coefficients doit être versionnée par zone, par période, et potentiellement par compteur.

Ce qui change concrètement

Migration

Pas de big bang. Migration progressive en parallèle de l'existant.

Questions ouvertes

1. Volumétrie cible : combien de bâtiments / compteurs à 1 an, 3 ans ? Centaines = option A. Milliers = envisager C ou E.
2. Hemis : ses données capteurs (SEN) vont dans le Raw ? C'est le flux le plus volumineux (sub-minute par capteur × milliers d'instances).
3. TimescaleDB mono-instance ou séparées ? Un cluster avec trois schémas, ou trois instances ?
4. Ontologie : YAML en config ou table en base (modifiable à chaud) ?
5. Temps réel : des cas d'usage sub-seconde ? Si oui, pipeline stream (broker nécessaire).
6. Payloads bruts : S3/MinIO déjà disponible ou à déployer ?
7. PCS gaz : source de données pour les coefficients versionnés ? Bulletin GRDF ?

Historique du document