Aller au contenu

ADR-012 — N approches d'estimation en parallèle (PriceHubble comme approche sœur de estimate_value)
Statut Proposed
Date 12/05/2026 (S20)
Décideurs Nicolas Léonard, Romain BAZIL
Origine Brainstorm Nicolas × Claude Code 12/05/2026, déclenché par l'investigation Notion sur 6 projets en KO estimate_value

Contexte

L'estimation de la valeur vénale d'un projet repose aujourd'hui sur un unique agent estimate_value (LLM-based, framework RICS) qui mobilise en interne 3 méthodes (Comparables, Revenu, Coût). PriceHubble — un AVM ML packagée externe — est consommé par cet agent comme une source Cat B parmi d'autres (DVF, MeilleursAgents, SeLoger, LBC, Observatoire des loyers), au sein de la méthode Comparables.

Conséquences observées :

  • L'analyste ne dispose jamais d'une seconde opinion indépendante en face de l'estimation RICS. Le LLM pondère PH au milieu des autres sources, dans une boîte qu'on ne peut pas challenger.
  • Quand estimate_value court-circuite (sortie data_insufficient=true parce que les minima address, property_type, surface ne sont pas tous remplis), toute la valeur vénale tombe — y compris pour des dossiers où PH aurait pu produire un signal exploitable de manière autonome.
  • L'investigation du 12/05/2026 (6 projets en KO) montre que estimate_value est aujourd'hui plus souvent skippé qu'avant, sans visibilité côté analyste. La frustration produit est réelle.

Le pari fiabilité bricks-OS (ADR-001) postule pourtant N approches indépendantes en parallèle → convergence auto → LLM-as-a-judge → HITL ciblé. Imbriquer PH dans estimate_value casse cette indépendance dès le premier étage : on n'a pas de "N approches", on a une approche unique qui ingère plusieurs signaux.

Décision

Toute approche d'estimation packagée — PriceHubble en V1, AVM concurrents ou estimations agentiques alternatives demain — est une approche sœur de estimate_value, exécutée en parallèle au niveau de l'orchestrator project-analysis.

Chaque approche sœur dispose de :

  1. Ses propres préconditions, évaluées indépendamment de celles des autres approches
  2. Sa propre sortie structurée (valeur centrale, plage min/max, confidence, métadonnées de traçabilité)
  3. Son propre rendu UI, côte à côte avec les autres approches dans la section "Estimation valeur vénale"

L'analyste arbitre entre les approches. L'orchestrator ne pondère pas — il rend transparent. La synthèse automatique (LLM-as-a-judge de réconciliation) n'est introduite que si le besoin est confirmé sur la durée, conformément à la cascade ADR-001.

Rationale

  • Cohérence avec le pari fiabilité (ADR-001). Imbriquer PH dans estimate_value casse l'indépendance des signaux dès le premier étage. Mettre PH en parallèle restaure la triangulation que la doctrine appelle de ses vœux.
  • Capacité de challenge pour l'analyste. Avec deux approches indépendantes, l'analyste peut lire "RICS dit X, PH dit Y, écart 8 %" et décider. Aujourd'hui il ne lit qu'un nombre opaque issu d'une pondération LLM non auditable.
  • Robustesse au skip d'estimate_value. Si RICS court-circuite parce que la fiche consolidée manque de surface ou de type, PH peut quand même tourner (pour les dossiers résidentiels ≤ 1000 m²) et fournir un point de référence — au lieu d'un écran vide.
  • Anti-pattern LIDAR évité. Le mémo Parallèle LIDAR identifie le "consensus corrélé" comme anti-pattern : N LLMs sur la même pipeline ≠ triangulation. PH consommé par le LLM d'estimate_value coche exactement cette case (deux signaux corrélés via le LLM). En parallèle, on retrouve une vraie triangulation.
  • Extensibilité. Ajouter un AVM concurrent ou une approche statistique demain = ajouter une approche sœur, sans toucher au code d'estimate_value. Le contrat top-level "N approches" est stable, les approches sont pluggable.

Conséquences

Ce qui change

  1. PriceHubble sort du pré-fetch d'estimate_value — les 8 sources actuellement pré-fetchées (cf. prompts_v4.py:142-150) passent à 7 : DVF, MeilleursAgents, SeLoger, LeBonCoin, Observatoire des loyers, estimate_land_value, estimate_construction_cost.
  2. Nouveau module pricehubble_estimation invoqué par l'orchestrator project-analysis (côté IA-analyse-API ou côté project-analysis, à arbitrer en Phase 2).
  3. La sortie de la section "Estimation valeur vénale" devient une structure top-level à N approches (au lieu de la sortie unique actuelle de EstimateValueOutputV4).
  4. L'UI rend les approches côte à côte dans la section "Estimation valeur vénale" de l'App TS.
  5. Le prompt v4 d'estimate_value est ajusté pour clarifier que PH n'est plus une source de la méthode Comparables et n'apparaît plus dans methods[].

Ce qu'il faut faire

  • Phase 1 (spec en cours) — préparer le schéma enveloppe à N approches, ajuster le prompt v4 pour figer le mental model côté LLM (PH n'est plus une méthode). Pas encore de refacto code de pré-fetch.
  • Phase 2 (ticket Linear à créer après merge Phase 1) — refacto orchestrator + suppression PH du pré-fetch estimate_value + module pricehubble_estimation + UI multi-cartes.
  • Documenter le lien doctrine ↔ ADR dans wiki/doctrine/pari-fiabilite.md (renvoi explicite vers cet ADR en exemple d'application).

Ce qu'il faut éviter

  • Pondérer les approches au niveau orchestrator. Recréer une logique de pondération automatique au-dessus des approches casse l'indépendance qu'on vient d'établir — c'est ré-imbriquer le problème sous un autre nom. La pondération éventuelle reste celle de l'analyste tant qu'un LLM-as-a-judge n'est pas validé sur métriques (cascade ADR-001).
  • Cascader RICS → PH (ex. n'appeler PH que si RICS échoue). Casse le parallélisme et la capacité de challenge à dossier réussi.
  • Mélanger les seuils de confidence entre approches. Chaque approche conserve son propre référentiel (high/medium/low n'a pas la même définition dans RICS et dans PH).

Alternatives écartées

  • PH élevé au rang de 4ᵉ méthode interne à estimate_value (statu quo amélioré). Garde le couplage : le LLM continue à pondérer PH au milieu des autres méthodes, dans la même boîte noire. Aucune seconde opinion indépendante. Reproduit le défaut actuel sous un nouveau nom — cosmétique.
  • PH reste source Cat B de la méthode Comparables (statu quo). Le rapport entre RICS et PH n'est pas explicitable à l'analyste, qui ne peut pas le challenger. Ne traite pas le besoin de triangulation, et n'aide pas dans les cas où RICS court-circuite alors que PH aurait pu tourner.
  • Synthèse automatique RICS × PH par un agent de réconciliation dès la V1. Recrée un LLM-as-a-judge avant d'avoir validé qu'il en faut un. La cascade ADR-001 impose convergence → judge → HITL dans cet ordre, pas judge en premier. Risque d'enchaîner deux LLMs corrélés sans vraie réconciliation indépendante.

Verbatims

« Concernant PriceHubble : dans la doctrine (philosophie produit de ce que nous construisions) on a le principe de "N approches en parallèle", ce qui me fait penser que pour estimation valeur vénale → PriceHubble doit être considéré comme une approche (estimation ML packagée) et pas comme un tool de l'agent estimate_value. » — Nicolas, brainstorm 12/05/2026

« On est passé d'une situation où on avait un agent estimate_value qui tournait la majorité du temps sur les projets et qui, parfois, certes, générait des valeurs incohérentes. La situation actuelle, c'est […] de nouveaux mécanismes pour éviter de faire tourner cet agent quand il manque des data points obligatoires en entrée. La conséquence, c'est que l'agent semble être skippé. » — Nicolas, ouverture du brainstorm 12/05/2026

« Il n'y a rien qui est publié dans la section "Estimation de Valeur Vénale" sur l'app TS. […] Ça me semble important d'afficher dans cette section un message qui explique les raisons pour lesquelles l'agent a volontairement décidé de ne pas travailler. » — Nicolas, 12/05/2026 (motivation produit de la Phase 1)

Voir aussi

Sources