9 points par seogi1004 4 시간 전 | 5 commentaires | Partager sur WhatsApp

Bonjour. Je suis l’ingénieur qui développe Apartment Insights APT Insights, un service d’analyse du marché des appartements en Corée et de simulation de prix.

Ayant longtemps travaillé principalement sur le développement frontend et la visualisation de données, l’infrastructure backend, les files asynchrones, les statistiques et les modèles de prévision de séries temporelles m’étaient très peu familiers. Je ne pensais pas en venir à construire moi-même un modèle de prévision des prix, mais en collaborant activement avec des agents IA, j’ai pu surmonter mes limites techniques et mener à bien, en environ 100 jours, un développement solo piloté à 100 % par des agents IA.

J’ai commencé à étudier le marché des appartements afin de préparer un foyer où m’installer pendant que mon enfant grandit. Au départ, il s’agissait d’un petit projet personnel pour simuler les futurs prix des résidences candidates à l’habitation. Il s’est ensuite étendu à un service couvrant des résidences dans tout le pays, avec l’intégration de variables macroéconomiques, de la modélisation statistique et une montée en maturité de la stack d’infrastructure serverless. Récemment, au-delà du web/PWA, j’ai également lancé des applications natives officielles sur l’iOS App Store et le Google Play Store, que je partage gratuitement et sans publicité.


1. Limites de surapprentissage de la réponse ponctuelle (Point Forecast) et définition du problème

Les méthodes existantes d’estimation des prix du marché et de prévision ponctuelle (Point Forecast) ont tendance à surapprendre (Overfitting) la question : « combien vaudra exactement cet appartement dans 24 mois ? ». Le marché immobilier est en effet fortement influencé par des variables macroéconomiques comme les taux d’intérêt, le taux de change, l’endettement des ménages ou les politiques publiques.

J’ai donc estimé qu’il était plus pratique de calculer un intervalle central à 50 % (P25 ~ P75) via une simulation probabiliste fondée sur des scénarios, plutôt que de présenter une valeur unique comme réponse.


2. Modélisation statistique & structure de simulation

Pour résoudre ce problème, j’ai conçu le moteur de prévision autour de trois grands axes.

  1. 16 facteurs macro, structurels et régionaux actifs : combinaison des statistiques officielles ECOS de la Banque de Corée (taux d’intérêt, taux de change, dette des ménages, coûts de construction) et d’indicateurs qualitatifs et régionaux (politiques publiques, sentiment, emplacement, etc.), avec restauration de snapshots de données historiques afin d’assurer la cohérence entre les périodes.
  2. Correction des résidus VECM (modèle vectoriel à correction d’erreur) : correction adaptée au moment du déménagement et à l’environnement de marché, avec application d’une couche de correction du momentum des résidus du modèle vectoriel à correction d’erreur (VECM), qui maintient les relations d’équilibre de long terme.
  3. Simulation de Monte-Carlo & interpolation de trajectoires de prévision ponctuelle : les scénarios de prix à 24 mois sont produits sous forme d’intervalle de probabilité P25 ~ P75 via l’interpolation de trajectoires de prévision ponctuelle et une simulation de Monte-Carlo.

3. Performance quantitative du modèle et backtests OOS transparents

Pour évaluer la capacité de généralisation et la fiabilité du modèle, nous effectuons régulièrement des backtests Forward OOS de validation hors échantillon à 12 mois sur des résidences représentatives de la cohorte d’évaluation et sur des résidences d’échantillon de validation de généralisation.

  • MAPE du prix sur échantillon retenu en Forward OOS à 12 mois : 6,32 % (sur la cohorte officielle d’évaluation)
  • R^2 ajusté sur échantillon retenu : 0,610 (sur la validation de backtest de cohorte)
  • Gate de qualité de validation : tous les contrôles sont passés
  • Validation OOS quotidienne sur 5 résidences aléatoires & mise en avant principale : sur la page du livre blanc technique, les résultats de backtests Forward OOS à 12 mois de 5 résidences tirées au hasard chaque jour sont publiés de manière transparente ; parmi elles, la résidence dont le taux d’erreur est médian (Median) est automatiquement mise en avant sur l’écran principal comme appartement vérifié du jour.
  • Prévention des biais d’échantillonnage : un suivi séparé est aussi effectué sur des résidences d’échantillon de généralisation qui ne font pas partie de la cohorte d’évaluation, afin de vérifier en continu la capacité de généralisation aux résidences de tout le pays sans biais lié aux données d’entraînement.

4. Lancement officiel sur App Store/Google Play et construction multi-plateforme

Dans un environnement de monorepo unique (pnpm workspace + Turborepo), nous avons assuré l’accessibilité sur différents appareils et lancé officiellement le service sur le web, en PWA, sur l’iOS App Store et sur l’Android Google Play Store.

  • Pipeline unique Web / PWA / Native WebView : l’infrastructure Next.js (Vercel) sert de serveur principal, puis l’environnement est étendu aux apps natives iOS/Android via le packaging Capacitor et l’intégration de plugins natifs.
  • Connexion sociale et résolution des problèmes de navigateur in-app : pour les connexions Kakao, Apple et Google, nous avons mis en place la validation OIDC Nonce et un flux de transmission (handoff) des identifiants Native SDK ↔ serveur, ce qui résout les blocages liés aux navigateurs in-app. (fallback vers une adresse e-mail virtuelle si l’utilisateur n’autorise pas l’e-mail Kakao)
  • Toolchain de synchronisation automatique des assets : génération automatique, à partir d’une seule source SVG, des splash screens PWA (40 résolutions), du launcher/splash Android et des assets d’icônes d’app iOS.
  • Pipeline de push redondé : lors d’un changement de prévision pour une résidence suivie, Web Push et push natif OS (FCM/APNs) sont routés selon deux niveaux d’importance (Strong/Normal), puis envoyés en lot via un pipeline asynchrone Cloudflare Queue / QStash.

5. Infrastructure et troubleshooting / leçons d’un développement piloté par l’IA

J’ai développé de manière autonome avec une architecture hybride serverless (Next.js + Neon Postgres + Cloudflare Workers + Hono + Cloudflare Queue / Upstash Redis), en minimisant les coûts fixes mensuels.

  • Alignement entraînement-serving : nous avons identifié un décalage entraînement-serving (Train/Serve Skew) où le gate de fraîcheur (Recency) différait à cause de l’écart en jours entre la date de référence de la fenêtre d’échantillonnage lors du backtest/de l’entraînement et la date de transaction la plus récente au moment du serving. En séparant la date de référence de la fenêtre d’échantillonnage et en alignant les paramètres de reproduction historique (as-of), nous avons obtenu une cohérence complète entre serving et backtest.
  • Catalogue à construction différée à la demande : au lieu de collecter à l’avance tous les appartements du pays et de gaspiller des coûts, nous avons intégré un pipeline qui construit de manière asynchrone et différée uniquement les catalogues des zones (villes/districts/arrondissements) d’où viennent les utilisateurs, ainsi que les transactions réelles des résidences suivies.
  • Accumulation automatique des échantillons en violation de qualité : dans les batchs de validation aléatoire, les échantillons anormaux bloqués par le gate d’erreur sont cumulés dans un stockage append-only, afin de servir d’échantillons prioritaires d’amélioration avant le tuning du modèle.
  • Dépassement de la limite mémoire d’Upstash Redis : lors du backfill de grands volumes de données, quand les données JSON brutes faisaient atteindre la limite mémoire, l’agent a séparé lui-même l’architecture en requêtes dynamiques en temps réel (live fetch), évitant ainsi les fuites de coûts d’infrastructure.
  • Correction du plafond de pondération des politiques publiques : pour certains segments de prix, le poids des politiques de prêt augmentait anormalement ; nous l’avons corrigé en injectant une formule de calibration de plafond.

Si vous avez des retours ou des questions sur la modélisation de séries temporelles immobilières, les simulations VECM/Monte-Carlo ou l’infrastructure hybride serverless/Capacitor, n’hésitez pas à en discuter en commentaire.

5 commentaires

 
beoks 2 시간 전

Le lien vers le livre blanc technique renvoie une erreur 404 !
https://edge.apt-insights.com/v1/public/whitepaper

 
seogi1004 2 시간 전

Merci pour le signalement. C’est corrigé !!

 
baeba 31 분 전

J’ai essayé en entrant l’ancien appartement où vivent mes parents...
seul le 33 pyeong s’affiche... pourtant, dans cet immeuble, il y a à la fois des 33 et des 26 pyeong.
Est-ce que seul le 33 pyeong est pris en charge à l’origine ?

 
seogi1004 22 분 전

Oui ! Le modèle est basé sur la surface standard la plus courante.
En revanche, pour les appartements qui ne disposent pas de cette surface de référence, la prédiction est réalisée à partir de plusieurs surfaces d’échantillon.

 
seogi1004 1 시간 전

J’ai oublié de mentionner dans l’article la fonction de partage d’appartements, haha. Je laisse ici, à titre de test, un lien de partage pour Helio City, un grand ensemble très connu.
(Les résultats de prédiction sont à prendre uniquement à titre indicatif ; pour les détails de la modélisation, veuillez consulter le livre blanc !)
Le lien s’ouvre directement sans connexion, donc n’hésitez pas à cliquer pour jeter un œil à l’UI des graphiques.
https://app.apt-insights.com/s/apt/9NPumhVmCv