Réforme de l’État — Plan de Rupture
Le dossier fondateur : finances publiques, structures, calendrier et mesures.
Voir le livre et la lecture gratuite →BUDGET · STRESS TEST · RESPONSABILITÉ
Open Data budgétaire : une API pour savoir qui savait quoi, quand et avec quelles données
Document d’appui : cette page conserve une fonction de transparence et de vérification, mais elle n’est pas conçue comme une réponse autonome aux moteurs de recherche.
Spécification publique du registre d’alertes, des méthodes, des certificats et de leur historique, avec minimisation des données personnelles.
FR
Un registre lisible par les citoyens… et par les machines
Le registre de responsabilité budgétaire ne doit pas devenir un PDF annuel impossible à exploiter. définit un prototype Open Data avec identifiants stables, historique des versions, source de chaque alerte et format structuré.
GET /v1/alerts
GET /v1/alerts/BR-2028-0001
GET /v1/fiscal-series
GET /v1/methodologies
GET /v1/certificatesCe que chaque alerte doit permettre de reconstruire
SourceQuel document a déclenché l’alerte ?
NotificationQui a reçu l’information et quand ?
DécisionQuelle décision a été prise ?
RésultatQuel écart a finalement été constaté ?
Protection indispensable : ce registre ne doit pas publier inutilement des données personnelles. Les noms ne sont associés à une responsabilité individuelle que lorsque la fonction, le droit applicable et la procédure le justifient.
Sources officielles principales
Revenir à la règle mère
Open data
Une API utile doit exposer les pièces, les versions et les liens entre décision et exécution
Publier une API ne suffit pas à créer de la transparence. Les objets doivent être stables, documentés et reliés : décision, programme budgétaire, responsable, document source, date, montant, statut d'exécution et éventuelle révision. Sans identifiants persistants, le citoyen ne peut pas suivre une décision dans le temps.
L'API doit distinguer les données publiques des informations protégées. La transparence budgétaire n'autorise pas la publication de données personnelles inutiles. Les champs sensibles doivent être minimisés et les suppressions ou rectifications historisées sans rendre l'ancienne donnée active.
La qualité se mesure par la reproductibilité : un tiers doit pouvoir reconstruire le tableau de bord public à partir de l'API, retrouver la pièce source et vérifier la date de dernière mise à jour. Une page graphique dont les chiffres ne peuvent pas être reproduits n'est pas encore de l'open data contrôlable.
Traçabilité = identifiant stable + source + date + version + statut d'exécution + historique
- Les identifiants sont-ils persistants ?
- Chaque valeur renvoie-t-elle à une source ?
- Les versions et corrections restent-elles historisées ?
- Un tiers peut-il reproduire le tableau de bord depuis l'API ?
