01 — Projet professionnel · Juin 2026 — présentConstruite · recette à venir
CEPS
CEPS Data Platform & Explorer
Au CEPS, je conçois et développe seul une plateforme de données et son application métier, en dialogue avec les équipes et la DNUM.
CEPS Explorer · montants, dates et informations sensibles masquésAgrandir ↗
0
sources intégrées
~0 M
lignes en base · 6,4 Go
0
vues SQL métier & qualité
0
tests automatisés
Volumétries au 30 septembre 2026
Architecture
CEPS Data Platform & Explorer
Les composants, les flux de données et les frontières de confiance du système.
Faites défiler le schéma →
Technologies
Python
DuckDB
SQL
FastAPI
Next.js
TypeScript
GitLab CI
PostgreSQL (next)
Docker (next)
Choix d’architecture
01
Les fichiers sources sont conservés tels quels et tracés par empreinte SHA-256 ; chaque import est transactionnel et journalisé.
02
Aucune correspondance d’identifiants n’est inventée : chaque rattachement garde sa méthode et son statut, une valeur manquante reste manquante.
03
L’API est en lecture seule : l’application métier ne peut jamais modifier l’entrepôt.
04
Tests sur données synthétiques, aucune donnée dans Git ni dans les images Docker, aucun envoi vers un service externe.
Le problème
Pour négocier le prix des médicaments, les équipes doivent croiser ventes, remboursements, hôpital, remises et parcours réglementaires. Le point de départ : des fichiers dispersés et des identifiants concurrents.
Ce que j’ai construit
J’ai construit une chaîne qui fiabilise ces sources, conserve leur historique et restitue les analyses dans une application unique.
Une application pour le métier
Recherche produit, ventes et remboursements par circuit, décomposition de la croissance par prix, volumes et structure, parcours HAS et accès dérogatoires, exports CSV/Excel et fiche produit PDF.
Une traçabilité de bout en bout
442 fichiers tracés par SHA-256, 675 exécutions d’import journalisées et 3 922 anomalies qualité détectées. Sources préservées, imports transactionnels, corrections validées par un humain.
Ce que je prends en charge
Recueil des besoins, règles métier, adaptateurs par source, normalisation des identifiants, historisation, modèles SQL, API, interface et documentation de reprise. 113 migrations SQL versionnées et journalisées.
Des règles explicites
Aucune correspondance d’identifiants inventée. Une valeur manquante reste manquante. Les révisions remplacent les périodes concernées sans effacer les anciennes versions. Chaque rattachement conserve sa méthode et son statut.
Un cadre de travail maîtrisé
Tests sur données synthétiques, aucune donnée dans Git ou dans les images Docker, aucun envoi de données confidentielles à un service externe. Dictionnaire de données, procédures d’ingestion et dossier technique préparés pour la transmission.
La suite : recette et infrastructure ministérielle
La plateforme et l’application sont construites. Prochaines étapes : recette utilisateurs, migration vers PostgreSQL et Docker sur l’infrastructure DNUM, et derniers arbitrages métier.