Contribuer
Le code de Députédex est disponible sous licence libre (AGPL-3.0), réparti sur deux dépôts. Curieux de savoir comment les données sont calculées, ou envie de mettre les mains dans le code ? C’est par ici.
Si vous êtes développeur, voici comment le site est construit : le projet est volontairement séparé en deux dépôts distincts, avec chacun sa responsabilité propre :
Envie de comprendre comment un chiffre est obtenu ? Direction deputydex-data. Envie d’améliorer une page ou une visualisation ? Direction deputydex-front
Le code des deux dépôts est disponible sous licence AGPL-3.0 : lisible, forkable et réutilisable, avec republication obligatoire du code de toute version modifiée déployée publiquement. Le nom, le logo et l’identité visuelle « Députédex » n’en font pas partie et restent réservés — voir les mentions légales.
Le pipeline deputydex-data traverse plusieurs étapes, chacune isolée dans son propre dossier. Voici de quoi elles parlent, et à quel point elles sont corsées pour un premier contact — pas de quoi être découragé, chaque thème se comprend indépendamment des autres.
Récupère les archives XML/JSON de l’Assemblée nationale, par source et par législature.
Transforme les XML/JSON bruts en JSON normalisé, domaine par domaine (acteurs, scrutins…).
Charge le JSON parsé en base, par étapes, jusqu’aux tables finales.
(Re)construit les tables de référence : groupes, types de scrutin, types d’organe…
Complète des données déjà importées par jointure (ex. reconstitue l’historique des groupes d’un acteur depuis ses mandats).
Calcule les statistiques consommées par le front : résultats par groupe, activité, calendrier…
Les workflows download et parser séparent la logique cœur de ses effets de bord et de son point d’entrée CLI — une forme allégée de la même séparation contrat / implémentation que côté front.
Import, référentiels, enrichissement et agrégation tournent sur le même moteur générique, qui exécute une série d’étapes en séquence jusqu’aux tables finales.
Ce repo est l’unique propriétaire du schéma de base de données et de ses migrations. Le front consomme le client généré, en lecture seule.
Le socle de l’app : le domaine définit les contrats métier, l’infrastructure les implémente, les routes API orchestrent l’entrée HTTP entre les deux.
Design system interne : des composants techniques génériques, assemblés en pages via des templates.
Construit des pages entières depuis de la config : un registry associe chaque type de bloc (chart, table, card…) à son composant de rendu.
Chaque composant récupère ses données via un gateway fetch dédié, qui implémente le contrat défini côté domaine.
Les repositories combinent le client Prisma généré et des requêtes SQL écrites à la main sur des tables agrégées.
Le cache des endpoints API est géré côté Route Handler.
Un fichier unique qui remplace les exceptions par un type Result explicite dans les use-cases.