03 · Approche

Comment la donnée devient lisible.

Chaque source suit le même pipeline documenté. Traçabilité, reproductibilité, indice de confiance par enregistrement.

01

Collecte

Récupération programmée depuis les API et miroirs publics. Versioning par millésime source.

02

Nettoyage

Typage strict, normalisation adresses via BAN, déduplication, rejet des enregistrements aberrants.

03

Croisement

Liaison inter-sources par ban_id, code_insee, id_parcelle. Scoring de la qualité du match.

04

Exposition

Indicateurs dérivés, vues statistiques, journal d'audit public, mise à jour incrémentale.

1 · Collecte

Les données sources sont récupérées en continu via des edge functions dédiées. Chaque source a son propre orchestrateur et sa propre queue de téléchargement. Les millésimes sont conservés afin de pouvoir rejouer l'historique si nécessaire.

  • DVF : téléchargement semestriel depuis files.data.gouv.fr, par département.
  • DPE : ingestion mensuelle de l'API ADEME, avec filtrage des diagnostics pertinents.
  • BDNB : ingestion des archives CSV 2025-07 depuis open-data.s3.fr-par.scw.cloud, département par département.
  • BAN : réconciliation hebdomadaire du référentiel national.
  • BPE, IRIS, Cadastre : synchronisation annuelle ou trimestrielle selon fréquence source.

2 · Nettoyage

Les enregistrements bruts passent par une série de filtres :

FiltreActionSources concernées
Types strictsCast numérique, date ISO, booléens uniformesToutes
Valeurs manquantesRejet si champs critiques absentsDVF, DPE
Ventes groupéesFlag is_vente_groupee exclu du prix/m²DVF
Surface aberranteRejet si < 9 m² ou > 500 m² en résidentielDVF, DPE
Prix aberrantRejet si hors 3σ de la distribution communeDVF
DéduplicationConservation du plus récent par clé uniqueToutes

3 · Croisement

Le cœur du projet : rattacher chaque enregistrement à un ban_id, identifiant d'adresse pérenne qui sert de pivot universel.

Fonction canonique score_ban_candidate()

Pour chaque paire (enregistrement source, adresse BAN candidate), un score est calculé à partir de quatre signaux : similarité trigram du nom de voie, égalité du numéro, égalité du code commune, distance géodésique.

NiveauScoreCritères
exact100numéro ✓, voie sim ≥ 0,95, commune ✓, dist ≤ 20 m
high85numéro ✓, voie sim ≥ 0,80, commune ✓, dist ≤ 50 m
good70voie sim ≥ 0,70, commune ✓, dist ≤ 100 m
medium55voie sim ≥ 0,55, commune ✓, dist ≤ 150 m
low40voie sim ≥ 0,40 ou dist ≤ 250 m
weak20tous autres cas — candidat à purge

Le score est stocké dans la colonne ban_match_score de chaque table, aux côtés de ban_match_method et ban_match_scored_at. Les enregistrements sous seuil (< 40) voient leur lien ban_id remis à NULL automatiquement, puis un nouveau matching est tenté avec une recherche élargie.

4 · Exposition

Les indicateurs dérivés sont calculés à partir des données croisées :

  • Prix médian / m² par commune et typologie, sur fenêtre glissante de 24 mois.
  • Distribution des classes DPE par IRIS et commune.
  • Score équipements basé sur la densité et la diversité BPE à 800 m autour de chaque adresse.
  • Index de liquidité marché : volume trimestriel et délai médian de commercialisation.

Gouvernance qualité

Un journal d'audit consigne chaque correction automatique : ré-attribution d'un ban_id suite à un score insuffisant, purge d'enregistrement aberrant, transition d'état d'un cron de reconcile.

Transparence par défaut.

L'ensemble de la méthodologie est documenté en SQL dans le dépôt technique. Les seuils, les règles de filtrage, les fonctions de scoring sont ouverts à la revue.