Comment une obligation légale de publication est devenue un produit à part entière — 48 logements, un flux public pour le portail de l’État et l’historique complet des prix de chaque logement, sans aucun « prix sur demande »
Une réalisation de référence de Digital Vantage : le site d’un promoteur immobilier qui traite l’obligation légale polonaise de publication des prix (art. 19b) comme une fonctionnalité produit et un argument de vente, plutôt que comme une obligation que quelqu’un tient à jour à la main. La marque Osnowa Development est une démonstration — le cas montre ce que nous savons construire, pas le résultat commercial d’une autre entreprise.

La loi sur la transparence des prix oblige le promoteur à publier le prix de chaque logement, l’historique complet de chaque modification et un flux lisible par machine pour le portail national des données ouvertes — et un amendement de février 2026 y ajoute l’interdiction d’augmenter le prix d’un logement déjà vendu. Un promoteur typique tient ses prix dans des tableurs et des PDF, affiche « prix sur demande » et remplit l’obligation à la main : en retard, et avec un risque d’erreur qui peut lui coûter cher.
Le point de départ était commercial. Une obligation légale que tout le monde traite comme une taxe peut au contraire devenir un avantage — mais seulement si la transparence vit au cœur du modèle de données au lieu d’y être greffée après coup.
La transparence est devenue une partie du modèle de données, pas un ajout. Chaque prix de logement porte sa date d’entrée en vigueur et son historique complet ; le système ouvre l’historique au lancement et ajoute une nouvelle entrée à chaque modification, avec le sens, le motif et la date. Un rédacteur ne peut pas « oublier » l’historique, car aucun chemin ne permet de contourner cette règle.
La conformité est garantie par le code : toute tentative d’augmenter le prix d’un logement vendu est rejetée avant même que l’enregistrement soit écrit, si bien que l’amendement existe comme un garde-fou et non comme une note dans une procédure. Cette même source unique de vérité alimente le portail de l’État selon son schéma officiel à 30 colonnes, sans aucun export manuel. Le parcours de vente repose sur la même transparence : un tableau des disponibilités avec filtres, une page par logement et une page distincte d’historique des prix — le tout accessible sans se connecter et sans laisser ses coordonnées.
Le module de publication des prix fonctionne de bout en bout en production, et c’est là la vraie preuve : le flux public renvoie les 48 logements dans le schéma officiel, et la page d’historique des prix montre une véritable chronologie (lancement → indexation → nouvelle correction) avec un motif pour chaque entrée. Un prix peut monter ou baisser, mais il ne disparaît jamais derrière un « prix sur demande ».
Pour un promoteur, cela se traduit par une valeur chiffrable : la conformité à l’art. 19b sans travail manuel et sans exposition à une sanction, et un parcours d’achat où le client trouve un logement dans son propre budget au lieu de remplir un formulaire et d’attendre. Une faiblesse est signalée ouvertement : la performance sur mobile (LCP ~4,9 s, CLS sur la page logement) est la première chose à corriger avant d’utiliser ce cas dans un entretien commercial.
L’art. 19b en module opérationnel : 48 logements, un flux officiel à 30 colonnes, un historique des prix automatique et une conformité garantie par le code.
Le tableau des disponibilités sur ordinateur et la page logement sur téléphone lisent un seul et même modèle de données — prix, historique des modifications et statut sont identiques partout, car ils proviennent d’une source unique et non de fichiers séparés.









Je construis un site qui accompagne l’acheteur du premier clic jusqu’à une demande sur un logement précis.