L’AI ne calcule pas le prix de l’appartement. Cela ne suffit pas à rendre l’estimation juste

Demander à un modèle de langage d’« estimer un appartement » produit vite un chiffre bien élevé. Il peut venir avec une explication assurée, une liste de facteurs et presque aucune base vérifiable.

Pour LiveDXB Analytics, j’ai choisi un moteur de calcul distinct. Il lit les transactions, choisit les comparables, calcule la distribution du prix au pied carré puis y compare le prix demandé. Le commentaire AI arrive après. Le résultat numérique provient du code TypeScript.

Mais on peut se rassurer trop vite. Un programme sait calculer sans erreur la médiane d’appartements mal sélectionnés.

Comment fonctionne le calcul

L’interface utilise React, l’API Hono dans un Cloudflare Worker. D1 stocke données normalisées et résultats des contrôles ; R2 accueille les fichiers sources. Le résultat possède paramètres d’entrée, date et version de méthode.

Le moteur extrait médiane et quartiles, filtre les valeurs aberrantes par l’écart interquartile puis compare le prix au corridor obtenu. S’il y a moins de trois comparables initiaux, la réponse prévue est INSUFFICIENT DATA.

Le formulaire archivé contient déjà un bien fictif. On peut examiner les paramètres et le parcours disponible vers le résultat. C’est une démo autonome, pas une interrogation du marché actuel.

Données d’entrée de l’estimation

Interface archivée · données de démonstration

C’est une forme utile de refus. L’interface fonctionne encore sans prétendre que chaque clic doit produire un prix.

Voici un résultat de démonstration préparé. L’écran illustre la présentation du calcul, mais ses chiffres ne prouvent pas le prix de marché d’un appartement réel.

Résultat de l’estimation

Interface archivée · données de démonstration

Quelles transactions sont comparées ?

La sélection actuelle applique des tolérances de surface de 18 et 30 %. Les transactions sont triées par date, sans limite temporelle explicite dans la requête. La méthode antérieure prévoyait 180/365 jours et 15/25 % ; le code ne lui correspond pas encore.

La sélection élargie relâche aussi les conditions de correspondance. Cela aide à trouver des données mais change le sens du résultat. Des transactions anciennes et moins proches ne deviennent pas précises parce qu’elles suffisent en nombre.

Je ne présente donc pas le système comme une estimation garantie exacte, ni ne reprends la promesse initiale de « zéro hallucination ». Un algorithme distinct rend l’arithmétique reproductible. Qualité de l’échantillon, fraîcheur et pertinence de la conclusion nécessitent leurs vérifications.

Le produit que je souhaite en tirer

Un outil montrant pourquoi ces transactions sont retenues, quelles contraintes sont relâchées et où finit la confiance. La suite doit commencer par rapprocher code et méthode, contrôler la fraîcheur et les comparables. Un beau paragraphe du modèle attendra.

Ce projet ne doit pas être confondu avec Comps Engine, suspendu dans le CRM immobilier. Il possède sa propre réalisation ; code et ancien déploiement ne prouvent pas l’exhaustivité actuelle de la base de marché.

LiveDXB Analytics possède son moteur de calcul. C’est une réalisation distincte après Comps Engine, avec ses limites de données et de méthode. Le calcul reproductible permet de vérifier l’arithmétique, pas de remplacer les contrôles d’exhaustivité et d’actualité.

Histoires liées : Exploration de Comps Engine · Calculateur hypothécaire.