Luciia
Développement produit et couche d'intégration data / Un rapport d'analyse immobilière construit sur treize sources publiques
Développement du site et du tunnel de conversion d'un produit d'analyse immobilière pré-achat, et architecture de toute la couche d'intégration serveur vers l'API de données. Next.js 16, dix-neuf routes serveur, treize sources de données publiques françaises croisées en un rapport.
Le contexte
Luciia vend au particulier un rapport d’analyse immobilière pré-achat. Vous visitez un appartement, vous hésitez, vous achetez le rapport : il vous dit ce que les registres publics français savent de ce bien.
Toute la donnée est publique et gratuite. Le produit ne vend pas la donnée : il vend le fait de l’avoir trouvée, réconciliée et rendue lisible.
Ma mission a porté sur le site et le tunnel de conversion, et sur toute la couche d’intégration serveur vers l’API de données. Le module de cartographie a été développé par un binôme ; l’architecture du projet sépare explicitement les deux périmètres, avec une vérification de types dédiée pour prouver que le câblage ajouté est propre.
Le problème réel : l’identification, pas l’affichage
On imagine que la difficulté d’un produit comme celui-ci est de faire une belle carte. Ce n’est pas le cas. La difficulté est en amont : passer d’une adresse tapée à la main au bon objet immobilier.
Une adresse saisie par un humain est approximative. Les référentiels publics, eux, s’articulent autour d’objets différents qui ne partagent pas d’identifiant commun : la parcelle cadastrale, le bâtiment, le local, le lot de copropriété. Un diagnostic énergétique est rattaché à un local ; une transaction passée à une parcelle ; un risque naturel à une zone géographique ; un règlement d’urbanisme à un zonage.
Réconcilier tout cela sans se tromper de bien, c’est le cœur du produit, et l’essentiel du travail d’intégration.
L’architecture
Le site est un Next.js 16 en App Router, déployé sur Vercel. Toute l’interrogation de données passe par des routes serveur : aucune clé d’API et aucune source ne sont exposées au navigateur. Le front consomme une surface stable, indifférente aux changements des portails publics en amont.
Les sources croisées couvrent le géocodage et le fond de plan de l’institut géographique national, la base d’adresses nationale, le cadastre, la base de données nationale des bâtiments, les diagnostics énergétiques, le registre des copropriétés, l’historique des transactions foncières, les risques naturels et technologiques, les données statistiques et les documents d’urbanisme.
Trois décisions structurantes :
- Des budgets de temps différenciés par route. Construire un rapport complet peut légitimement prendre deux minutes ; un aperçu gratuit doit répondre en quelques secondes. Appliquer le même délai partout, c’est soit casser le rapport, soit ralentir l’entrée dans le tunnel.
- Un cache qui change la nature du produit. Le rapport composite met une dizaine de secondes à se construire à froid, moins de cent millisecondes ensuite. C’est la différence entre un outil qu’on subit et un outil qu’on consulte.
- Ne jamais inventer. Quand une source ne répond pas ou ne contient rien pour ce bien, l’interface le dit. Sur un produit d’aide à la décision d’achat, une valeur plausible mais fausse est pire qu’une valeur absente.
Le tunnel
Recherche d’adresse, identification du bien jusqu’au lot, aperçu gratuit, paiement, rapport complet. L’état de qualification est modélisé comme une machine à états persistée côté navigateur : on peut fermer l’onglet et revenir sans repartir de zéro.
L’ensemble est instrumenté, avec analytics et enregistrement de session en région européenne, et piloté par des feature flags évalués côté serveur, ce qui permet d’activer une variante sans redéployer et de mesurer son effet sur la conversion.
Ce que ce cas illustre
Les projets bâtis sur de la donnée publique ont un profil de risque particulier : la donnée est gratuite, mais elle est instable, hétérogène et sans garantie de service. Les portails changent de format, répondent lentement, tombent.
La réponse tient en trois principes : isoler chaque source derrière sa propre route serveur pour qu’une panne reste locale, mettre en cache agressivement parce que ces données bougent lentement, et rendre l’absence explicite plutôt que de la masquer.
C’est le même raisonnement que sur un connecteur ERP × CMS : un système d’intégration se juge sur son comportement quand une dépendance ne répond pas.