La plateforme

Le principe

Un dataset est un projet GitLab dans flender/dataplateforme/dataset/. Il contient un contrat (dataset.yaml) et ce qu'il faut pour produire ses données : fichiers déposés, script générateur, requête SQL, ou la liste des accès autorisés à pousser ou écrire. À partir de là, la forge génère la base, le stockage, l'API, les droits et la page du dataset. Aucun SQL, aucune API, aucun droit écrit à la main : changer le contrat et merger, c'est changer la plateforme.

flender/
└── dataplateforme/
    ├── plateforme/        ce qui fait vivre la plateforme : socle, pipeline commun, gabarit, portail, accès
    └── dataset/
        ├── ref_articles/  un dataset = un projet : contrat, sources, scripts
        └── anc/

Même chemin partout : flender/dataplateforme/dataset/anc dans GitLab, /datasets/anc sur ce portail, data-prod.flturbo.dev/anc/<table> dans l'API, schéma anc en SQL.

Le cycle de vie d'une donnée

1. Déclaration : le responsable crée le dataset avec le gabarit (contrat, projet GitLab).
2. Premier chargement : fichier en dev, merge request, schéma déduit relu et épinglé (un code qui ressemble à un nombre reste du texte).
3. Qualification : extrait réel anonymisé en staging, règles de qualité, application pilote.
4. Mise en service : prod publiée par un mainteneur, droits posés, page en ligne.
5. Vie courante : rafraîchissements planifiés, alertes au responsable (échec, fraîcheur), évolutions de schéma par merge request. Une colonne ajoutée passe ; un type qui change fait échouer le chargement au lieu de casser en silence.
6. Retrait : contrat supprimé, vues et droits révoqués, tables et fichiers bruts conservés en archive.

Chaque chargement est un commit, un pipeline et une ligne d'historique (qui, quand, quel fichier, combien de lignes). Les fichiers bruts sont archivés avec l'empreinte du commit.

Livrer des données : trois portes, une seule table à l'arrivée

• Déposer : fichiers (CSV, TSV, TXT, Excel, JSON même imbriqué, JSONL, Parquet), un zip, un dossier entier, dans incoming/<env>/ du projet du dataset. Un fichier = une table, un dossier = une table, x_2026-01.csv + x_2026-02.csv = la table x.
• Pousser : une autre base ou un outil envoie ses fichiers par HTTP avec sa clé API (POST https://ingest.data.flturbo.dev/<dataset>/<env>). Le fichier est stocké intact avec son empreinte, puis le pipeline du dataset se déclenche. Seuls les accès listés dans source.pushers du contrat y sont autorisés.
• Aller chercher : la plateforme lit une requête ou des tables d'une base source, à l'heure dite dans le contrat (source.type: sql, avec incrémental possible).
• Écriture directe : pour un dataset qui est une base entière, les accès source.writers écrivent dans le schéma raw_<dataset> ; l'API et le catalogue suivent.

Par défaut les types sont déduits prudemment ; typing: text garde toutes les colonnes telles quelles. Le nom d'origine d'une colonne renommée est conservé en commentaire.

Le cloisonnement

• Entre environnements : trois bases Postgres, trois API, trois sous-domaines. Une application en revue ne peut pas lire prod par erreur. Prod est un environnement GitLab protégé.
• Entre datasets : chaque dataset a son schéma, son bucket, son projet et ses rôles. Qui peut alimenter = membres du projet.
• Entre lecteurs : un rôle Postgres par accès ; le jeton porte le rôle, la base applique les droits, en SQL comme par l'API.
• Entre la donnée et sa documentation : le portail n'affiche jamais de donnée réelle ; les échantillons de prod viennent de staging (anonymisé) ou de dev (synthétique). Accès réseau limité aux adresses du site, TLS partout.

Sous le capot

GitLab (groupe, projets, CI, merge requests, identité), Postgres 17 (une instance, trois bases), PostgREST (API de lecture et OpenAPI), MinIO (fichiers bruts, archives), Caddy (routage, TLS, filtrage), l'outil dp en Python (inférence de schéma par dlt, chargement, qualité, droits, ce portail). Tout est versionné ; le serveur se reconstruit depuis le dépôt.