
Ingénierie
recherche-maison.com : retrouver le DPE derrière une annonce
Un SaaS que j'ai construit et que je vends moi-même. Vous recopiez ce qu'affiche une annonce immobilière, il retrouve le diagnostic de performance énergétique (DPE) du logement, avec son adresse. 15,5 millions de certificats cherchés directement dans votre navigateur, pour quelques centimes d'hébergement par mois.
- saas
Introduction
Vous êtes-vous déjà demandé où se trouvait vraiment la maison d’une annonce immobilière ? L’annonce doit afficher la classe énergie (la fameuse lettre de A à G), la surface et la commune, mais pas l’adresse. Sauf que le diagnostic derrière cette lettre, le DPE, est public ! Chaque certificat est déposé auprès de l’ADEME et publié en open data.
Donc si on recopie ce que donne l’annonce, on retrouve en général le certificat, et l’adresse avec. C’est ce que fait recherche-maison, et c’est un produit que je vends moi-même, sous ma propre entreprise individuelle (EI Chauquest).
Avant de rentrer dans le détail, voici ce que je voulais que le site fasse :
Fonctionnalités
- Chercher avec seulement ce qu’affiche une annonce : code postal ou commune, classe énergie, surface
- Resserrer la recherche avec la date du DPE ou la consommation (kWh/m²/an) quand l’annonce les donne
- Afficher tous les certificats qui correspondent, en liste et sur une carte (souvent quelques-uns, parfois un seul)
- Ouvrir un certificat pour voir toutes ses données, son bâtiment et sa parcelle
- Enregistrer un logement ou une recherche pour y revenir plus tard
- Ne presque rien coûter en hébergement
Premier plan : une grosse base de données (mauvaise idée)
Ma première idée, c’était le classique : tout télécharger dans une base de données et mettre une API devant. Avant d’écrire le code, j’ai mesuré quelques chiffres :
- 15,5 millions de certificats, 226 colonnes chacun
- environ 31 Go en CSV
- l’API de l’ADEME est limitée à 500 ko/s, donc un téléchargement complet prend environ 17 heures (et GitHub Actions coupe un job au bout de 6 heures)
Avec ces chiffres, un serveur de base de données n’avait plus de sens. Les données sont publiques et n’appartiennent à personne, alors pourquoi faire tourner un serveur juste pour les distribuer ? Je suis parti sur des fichiers Parquet (un format compressé qui range les données colonne par colonne) que le navigateur lit directement.
Avantages :
- Environ 4,5 Go une fois compressé, soit quelques centimes par mois sur Cloudflare R2
- Aucun serveur de base de données à maintenir
- Les 226 colonnes ne coûtent rien de plus, une recherche ne lit que les colonnes dont elle a besoin
Inconvénients :
- Les fichiers doivent être reconstruits chaque semaine, quand l’ADEME publie de nouveaux certificats
- Une mise en place plus délicate (requêtes partielles, CORS sur le bucket) qu’une simple API
Comment ça marche
En gros, sans rentrer dans chaque composant :
- Les certificats sont des fichiers Parquet sur R2, un dossier par département.
- La recherche tourne dans votre navigateur avec DuckDB-WASM. Elle ne télécharge que les morceaux de fichier dont elle a besoin (requêtes HTTP partielles), pas tout le département (Paris à lui seul compte 838 532 certificats !).
- Les comptes, logements et recherches enregistrés sont les seules données privées. Ils vivent dans un petit Worker Cloudflare avec une base D1 et la connexion Google.
La partie délicate : D1 n’a pas de sécurité au niveau des lignes, c’est-à-dire que la base ne vérifie pas toute seule qui a le droit de lire quelle ligne. J’ai donc fait en sorte qu’un seul fichier ait le droit de parler à la base, et un test fait échouer le build si un autre fichier essaie. C’est moins élégant que de vraies règles dans la base, mais ça fait le travail.
Des données pleines de pièges
L’open data, c’est génial, mais ce n’est pas propre du tout. Voici ce que j’ai découvert à mes dépens (chaque piège est maintenant couvert par un test) :
- Les noms de colonnes du CSV ne sont pas ceux de l’API, et deux d’entre eux sont inversés. En lisant par nom, l’adresse atterrit dans la mauvaise colonne sans aucune erreur.
- Les coordonnées appartiennent à chaque certificat, pas à chaque adresse. Les fusionner par adresse fait perdre des données.
- Stocker les nombres en flottants n’est pas sans perte. 96 colonnes ont exactement une décimale, donc je les stocke en entiers multipliés par 10.
La base a été construite une fois sur mon ordinateur, et depuis, un job hebdomadaire ne récupère que ce qui a changé.
Résultat
Le site est en ligne. En plus des logements existants, il couvre le neuf, le tertiaire et les audits énergétiques, chacun rattaché à son bâtiment (RNB) et à sa parcelle cadastrale. La recherche dans tout l’historique est gratuite avec un compte Google, et les certificats des deux derniers mois sont à 5 € par mois, payés via Stripe.
Je l’ai aussi publié comme réutilisation sur data.gouv.fr, le portail open data de l’État, pour qu’on le trouve juste à côté des jeux de données de l’ADEME.
Limites
- Un logement n’apparaît que si son DPE a été déposé auprès de l’ADEME. Pas de DPE, pas de résultat.
- L’adresse est celle géocodée par l’ADEME, elle peut être approximative.
- Plusieurs certificats peuvent correspondre à la même annonce. Le site les montre tous et ne choisit pas à votre place.
Conclusion
Voilà pour ce petit tour ! Si vous cherchez un logement, essayez-le, et s’il vous manque une fonctionnalité, n’hésitez pas à me le dire. Et si vous voulez voir un autre projet qui tourne sur Cloudflare, ce portfolio en est un, j’en parle ici.