Estimap

Le problème

Les données immobilières françaises sont publiques et gratuites. Elles sont aussi éparpillées : les transactions dans DVF, la géométrie des parcelles dans le cadastre, les caractéristiques du bâti dans la BDNB, la performance énergétique dans les DPE, la démographie à l'INSEE, l'exposition aux risques ailleurs encore — et bien d'autres : équipements de proximité, transports, fibre, écoles, permis de construire, copropriétés.

Chacune a son format, sa granularité et son identifiant pivot. Croiser « le prix au m² des maisons construites avant 1975 avec un DPE F ou G dans un secteur inondable » demande donc un travail de fusion préalable considérable.

L'objectif produit

Un moteur d'estimation de prix immobilier — la carte est le support d'exploration, mais l'objectif est de nourrir un modèle avec des caractéristiques réellement croisées.

La phase 1 (comparables kNN pondérés, rayons progressifs, garde-fous de plausibilité) est en production et répond aujourd'hui à 100 % des requêtes d'estimation. La phase 2 (LightGBM, 27 features) est en cours d'entraînement final avant promotion, avec un gate de promotion automatique qui compare tout nouveau modèle au modèle actuellement servi.

Architecture

• Frontend : Nuxt 3 + MapLibre GL, tuiles PMTiles — carte, fiche de bien, backoffice
• Backend : FastAPI + SQLAlchemy, avec Celery pour les traitements longs
• Données : PostgreSQL / PostGIS pour le spatial, Redis comme broker et cache
• Infra : docker-compose, workers séparés par file d'attente

Les workers sont scindés en deux files : imports pour l'ingestion des sources, et mutations pour les rebuilds, l'enrichissement, la génération de tuiles et l'entraînement du modèle. Cette séparation évite qu'un import de plusieurs heures bloque un recalcul de tuiles de quelques minutes.

Un backoffice /admin pilote 15 connecteurs de sources et suit l'état des imports.

Ce que couvre la carte

Environ 7 millions de ventes immobilières (18 M de lignes DVF brutes) affichées en points colorés par prix/m² ou en heatmap, filtrables par type, prix, DPE, piscine. Un clic ouvre la fiche de bien : historique des ventes, DPE étendu, contexte du bien (annexes, fibre, école avec IPS, copropriété, permis récents, parc/eau/bruit), risques réglementaires live, et les services à proximité affichables sur la carte.

Méthode

Le projet s'appuie sur une documentation en dix fichiers — architecture, sources, modèle de données, pipelines, API, frontend, backoffice, runbook, roadmap — tenue à jour à chaque évolution significative. Le runbook consigne notamment les pièges d'infrastructure appris à la dure, ce qui évite de les réapprendre.

Ce que j'en retire

Sur ce type de projet, la difficulté n'est jamais l'algorithme : c'est la réconciliation d'identifiants entre référentiels qui ne se sont jamais parlé. Une parcelle cadastrale et un bâtiment BDNB ne partagent pas de clé — il faut la reconstruire spatialement, et accepter un taux d'appariement imparfait. Et une mesure de qualité (un medAPE de backtest, par exemple) ne vaut que si son protocole est audité : une fuite temporelle entre comparables et vente testée a longtemps faussé le chiffre affiché.