Tout est déjà public.
Tout ce que vous lisez ici, la Ville l'a déjà publié quelque part — un dataset OpenData, une annexe comptable, un PDF du compte de gestion. Notre boulot : relier, renommer en français courant, rendre l'ensemble lisible. Le pipeline est ouvert, chaque chiffre se recalcule depuis la source.
D'où vient chaque chiffre
Six portails officiels. Aucun autre.
De la Ville, et seulement de la Ville. Aucune donnée n'est reconstruite, aucune n'est estimée. Les ratios financiers qualitatifs non publiés en open data (taux moyen pondéré, maturité de dette) sont explicitement marqués « indicatifs » sur leur fiche.
opendata.paris.frBudget M57, marchés publics, subventions, logements sociaux, AP, bilan comptable, dette-garantie — 8 datasetsQuotidien à annuel selon datasetdata.gouv.fr / decpDonnées Essentielles de la Commande Publique consolidées (filtre SIRET 217500* Paris)Fichiers annuels 2019-2026data.gouv.fr / sireneRegistre entreprises (SIRET, APE, effectifs, établissements) · enrichissement tier2 gratuitMensuelapi-adresse.data.gouv.frGéocodage des adresses de projets d'investissementTemps réelcdn.paris.frAnnexes CA (investissements localisés), Rapport d'Orientation Budgétaire, compte de gestionAnnuel (juin N+1)drihl.ile-de-france…gouv.frInventaire SRU, parc social au 1er janvier, Socle demandes/attributions logement socialAnnuelDe la source au site, en quatre étapes
Un seul pipeline, rejoué à chaque nouvelle donnée publiée.
On récupère
On télécharge les datasets publiés par la Ville, par l'État (DECP, INSEE) et par les services déconcentrés (DRIHL). On lit aussi les PDFs joints aux comptes annuels. Rien n'est transformé à cette étape : on archive la source telle quelle.
On relie & traduit
On traduit les nomenclatures comptables en français courant et on joint les sources entre elles — par SIRET pour savoir qui reçoit, par adresse pour savoir où, par numéro de marché pour relier un contrat à son projet.
On enrichit
L'enrichissement tourne en deux niveaux. Gratuit : l'API publique SIRENE pour vérifier ~5 800 bénéficiaires (forme juridique, activité, siège). Optionnel : un modèle de langage classe les subventions par thème, géolocalise les projets d'investissement ambigus, vulgarise les intitulés techniques de marchés.
On publie
Le résultat est figé en fichiers JSON, versionnés avec le code. Le site lit ces fichiers directement — pas de base de données live, pas de calcul côté navigateur. Ce que vous voyez est exactement ce qui a été calculé.
Règle absolue sur l'enrichissement : un modèle de langage n'est utilisé que pour du texte — catégoriser, décrire, résumer, retrouver une adresse. Aucun montant, aucun agrégat financier ne passe jamais par un LLM. Les chiffres sortent d'un calcul SQL déterministe sur les données brutes.
La provenance, outil par outil
Cliquer ouvre la chaîne complète source → BigQuery → mart, avec un lien direct vers chaque table publique.
Pourquoi Budget, Subventions et Marchés ne s'additionnent pas
Ces trois pages sont des lectures complémentaires, pas trois calculs du même chiffre. Le budget contient une ligne agrégée de subventions ; notre page Subventions détaille cette même ligne côté bénéficiaires. Les marchés affichent des plafonds contractuels pluriannuels qui peuvent recouvrir plusieurs lignes budgétaires. Un même euro peut donc apparaître dans plusieurs pages sous des angles différents — on ne les additionne jamais. Côté pipeline, core_budget, core_subventions, core_marches_publics et core_ap_projets ne sont jamais UNIONés.
Ce qui est à jour, ce qui ne l'est pas
Les données publiées par la Ville ne sont pas toutes maintenues au même rythme.
Règle : l'année en cours est toujours provisoire tant que le compte administratif définitif n'est pas publié (~juin N+1). Les chiffres d'une année non-close reposent sur le voté.
Comment on vérifie nos chiffres
Un audit re-jouable qui tourne à chaque update. Toute personne peut le relancer.
Trois familles de contrôles tournent sur chaque mise à jour : réconciliation (les totaux core doivent rejouer les totaux staging, au centime près), complétude (les enrichissements LLM et géoloc doivent dépasser des seuils documentés), limites connues (les trous de la source — années manquantes, datasets gelés — sont marqués comme tels). Le script run_data_quality_audit.py écrit le résultat en JSON, lu ci-dessous. Aucun chiffre n'est tapé à la main dans cette page.
Chargement de l'audit…
Confiance LLM : auto-déclarée, pas encore mesurée
Les caches d'enrichissement (thématique des subventions, géoloc des projets AP) portent une colonne ode_confiance. C'est un score auto-déclaré par le LLM. Pour en faire une garantie externe, on tire un échantillon stratifié (60 lignes thématique + 40 géoloc) qu'on annote à la main, et on compare la précision mesurée à la confidence déclarée par bucket. Le script et les échantillons : calibration_samples ↗. La précision mesurée sera publiée ici dès qu'elle est disponible.
Quand nos chiffres diffèrent de ceux annoncés par la Ville
Sur un même dataset, nos agrégats sont identiques à ceux de la Ville : on ne change pas les montants, on regroupe et on renomme. Les écarts viennent de trois causes : (1) périmètre — on publie le budget principal, la Ville peut communiquer un « groupe Ville » qui inclut les satellites ; (2) timing — notre chiffre vient du dernier dataset ouvert, qui peut être un cran derrière la communication officielle ; (3) renommage — on traduit chapitres et fonctions en libellés grand public, mais les agrégats restent ceux du M57. Si l'écart persiste, c'est un bug — dites-le-nous.
Pipeline AGPL, corrections traçables
Le pipeline (Python + dbt) est publié sous AGPL-3.0. Chaque chiffre se recalcule depuis sa source, chaque page expose son JSON. Erreur signalée = corrigée dans le code et consignée dans le changelog avec la date et l'origine du signalement. On corrige en place et on garde la trace — pour que tout ancien screenshot reste vérifiable.