Les données du site, à un seul endroit

Un responsable par dataset, une API et un accès SQL par environnement, des données mises à disposition telles qu'elles ont été livrées. Vous ne cherchez plus qui détient quoi : vous venez ici.

La plateformeCe que c'est, les principes, le cycle de vie, comment obtenir un accès Les datasetsInventaire, responsables, environnements, fraîcheur, modèle et exemples Les accèsMes accès, mes clés (SQL et API), demander un accès, lecteurs de mes datasets L'APIEndpoints par environnement, OpenAPI, console pour essayer avec votre identité La doc d'usagePython, JavaScript/TypeScript, C#, Power Query : exemples prêts à copier Le modèle de donnéesToutes les tables, les relations entre datasets, recherche d'une colonne

0datasets

0tables exposées

0accès déclarés

Derniers chargements

Pourquoi une plateforme

Aujourd'hui chaque application reconstruit ses référentiels (articles, machines, ANC) à partir d'exports : même donnée copiée plusieurs fois, jamais à jour en même temps, sans responsable identifié. La plateforme renverse la logique : un responsable décrit sa donnée une fois dans un contrat, la forge la charge, la documente, l'expose et applique les droits. Les applications et les analystes la lisent, ils ne la copient plus.

Quatre engagements

Une porte d'entrée unique. Les producteurs (ERP, GMAO, qualité, exports de services) livrent ici, une fois ; les consommateurs viennent ici, pas chez dix fournisseurs.
Rien n'est dénaturé. Le fichier livré est conservé intact avec son empreinte ; la version typée et l'API en sont dérivées et reconstructibles. Les seules transformations sont celles que le contrat déclare (anonymisation pour staging).
Un accès = une identité. Personne ou application, une clé utilisateur (SQL) et une clé API, les mêmes droits des deux côtés, une date d'expiration.
La distribution est gouvernée. La cellule décide qui a un accès et sur quels environnements ; le responsable d'un dataset décide qui le lit ; tout est écrit dans Git, donc revu, approuvé et historisé.

Trois environnements, même API

	dev	staging	prod
Nature	synthétique ou extrait	réel anonymisé	réel
Pour	développer, tests automatiques	qualifier une application	la donnée de référence
Accès	ouvert aux accès dataplateforme	ouvert ou authentifié	selon le contrat, souvent restreint
URL	`data-dev.flturbo.dev`	`data-staging.flturbo.dev`	`data-prod.flturbo.dev`

Une application choisit son environnement par DATA_API_URL. Même structure partout : ce qui marche en dev marche en prod.

Obtenir un accès

Connectez-vous avec votre compte GitLab de la forge et demandez un accès dans l'espace Accès. La cellule approuve (merge request), vous générez vos clés, elles ne sont affichées qu'une fois. Un dataset restreint demande en plus d'être ajouté comme lecteur par son responsable.

Qui fait quoi

Qui	Fait	Ne fait pas
Cellule digitalisation / Cellule IA	porte la plateforme (socle, pipelines, gabarit, portail, accès, supervision), accompagne la création des datasets	ne décide ni du contenu des données, ni de qui peut lire un dataset
Responsable d'un dataset	rédige et maintient le contrat, fournit la source, valide le schéma et l'anonymisation, déclare les lecteurs, traite les alertes	n'écrit ni SQL, ni API, ni droits : le pipeline s'en charge
Équipes applicatives	consomment l'API ou le SQL par environnement, demandent l'accès par le portail, signalent les besoins de nouveaux datasets	ne copient pas les référentiels dans leurs bases

Point de contact : Vincent Montaud (cellule digitalisation / cellule IA).