Le pipeline publie désormais une maille quartier (IRIS INSEE) en plus des mailles région/département/commune : prix au m² et écart qualité-prix recalculés par quartier, qualité héritée de la commune. Référence côté pipeline : ADR-0015 et PR pipelines#11.
Détection (feature-gate)
meta.json expose deux clés additives (schema_version reste 1) :
nb_iris : nombre de quartiers publiés (~16 400)
nb_iris_scores : quartiers avec données (~14 500)
Activer la couche si nb_iris > 0 ; clés absentes = ancien run, couche masquée. Si le schéma zod de meta est en .strict(), ajouter les deux clés en .optional() (en mode par défaut zod ignore les clés inconnues : rien à faire).
Artefacts
{base}/choropleth/iris-high/{dept}.geojson — même mécanique que communes-high/{dept}.geojson : un fichier par département, chargement lazy au zoom fort pour les départements visibles. ~104 fichiers, ~80 Ko gzip en moyenne, max ~400 Ko (13, 59, 75, 97x). URLs immuables sous runs/, cache long déjà en place.
Couverture — point d'UX important
La couche ne contient que les communes multi-IRIS (1 944 villes). Pour toutes les autres, le quartier serait identique au contour communal : il n'est pas publié. Superposer iris-high au-dessus de communes-high au zoom quartier — là où il n'y a pas de feature IRIS, la maille commune reste la lecture correcte.
Properties par feature
- Identité :
code_iris, nom (nom du quartier, ex. « Croix-Rousse »), code_commune, nom_commune, type_iris, code_departement
- Données :
prix_m2_median (entier), nb_transactions, fiable (bool), annee_min/annee_max
- Score :
score_commune, n_prix_iris, gap_iris, gap_pondere_iris (arrondis à 3 décimales)
fiable = false → valeurs à null → rendu « Pas de donnée », même convention que les communes
Mapping des métriques
Les noms diffèrent de la maille commune : score_valeur → score_commune, gap → gap_iris, gap_pondere → gap_pondere_iris ; prix_m2_median inchangé. Les échelles de couleurs sont réutilisables telles quelles (gap_iris vit sur la même échelle que le gap communal).
Tooltip
Pas de fichier fiche séparé : les properties suffisent. Deux précautions :
- le prix quartier est une médiane poolée sur plusieurs millésimes — afficher « prix médian {annee_min}–{annee_max} » et ne pas le comparer chiffre à chiffre au prix communal (millésime courant) ;
score_commune est hérité de la ville — seul le prix (donc le gap) varie entre quartiers d'une même ville.
Paris/Lyon/Marseille
Les quartiers sont rattachés aux codes arrondissements (75101…75120, 6938x, 132xx) : la couche quartier affiche des données sur Paris là où la choroplèthe communale montre « Pas de donnée » (75056). Le lien quartier → fiche commune fonctionne avec code_commune tel quel (les fiches arrondissements existent).
Sémantique
gap_iris > 0 = quartier sous-coté par rapport à la qualité de vie de sa ville ; < 0 = quartier cher pour sa ville. Classement des « bonnes affaires » : trier par gap_pondere_iris.
Exemple réel (run de validation, Lyon) : Debrousse (5e, 6 529 €/m²) gap −0,233 vs Le Château (9e, 2 334 €/m²) gap +0,197.
Le pipeline publie désormais une maille quartier (IRIS INSEE) en plus des mailles région/département/commune : prix au m² et écart qualité-prix recalculés par quartier, qualité héritée de la commune. Référence côté pipeline : ADR-0015 et PR pipelines#11.
Détection (feature-gate)
meta.jsonexpose deux clés additives (schema_versionreste1) :nb_iris: nombre de quartiers publiés (~16 400)nb_iris_scores: quartiers avec données (~14 500)Activer la couche si
nb_iris > 0; clés absentes = ancien run, couche masquée. Si le schéma zod demetaest en.strict(), ajouter les deux clés en.optional()(en mode par défaut zod ignore les clés inconnues : rien à faire).Artefacts
{base}/choropleth/iris-high/{dept}.geojson— même mécanique quecommunes-high/{dept}.geojson: un fichier par département, chargement lazy au zoom fort pour les départements visibles. ~104 fichiers, ~80 Ko gzip en moyenne, max ~400 Ko (13, 59, 75, 97x). URLs immuables sousruns/, cache long déjà en place.Couverture — point d'UX important
La couche ne contient que les communes multi-IRIS (1 944 villes). Pour toutes les autres, le quartier serait identique au contour communal : il n'est pas publié. Superposer
iris-highau-dessus decommunes-highau zoom quartier — là où il n'y a pas de feature IRIS, la maille commune reste la lecture correcte.Properties par feature
code_iris,nom(nom du quartier, ex. « Croix-Rousse »),code_commune,nom_commune,type_iris,code_departementprix_m2_median(entier),nb_transactions,fiable(bool),annee_min/annee_maxscore_commune,n_prix_iris,gap_iris,gap_pondere_iris(arrondis à 3 décimales)fiable = false→ valeurs ànull→ rendu « Pas de donnée », même convention que les communesMapping des métriques
Les noms diffèrent de la maille commune :
score_valeur→score_commune,gap→gap_iris,gap_pondere→gap_pondere_iris;prix_m2_medianinchangé. Les échelles de couleurs sont réutilisables telles quelles (gap_irisvit sur la même échelle que legapcommunal).Tooltip
Pas de fichier fiche séparé : les properties suffisent. Deux précautions :
score_communeest hérité de la ville — seul le prix (donc le gap) varie entre quartiers d'une même ville.Paris/Lyon/Marseille
Les quartiers sont rattachés aux codes arrondissements (
75101…75120,6938x,132xx) : la couche quartier affiche des données sur Paris là où la choroplèthe communale montre « Pas de donnée » (75056). Le lien quartier → fiche commune fonctionne aveccode_communetel quel (les fiches arrondissements existent).Sémantique
gap_iris > 0= quartier sous-coté par rapport à la qualité de vie de sa ville ;< 0= quartier cher pour sa ville. Classement des « bonnes affaires » : trier pargap_pondere_iris.Exemple réel (run de validation, Lyon) : Debrousse (5e, 6 529 €/m²) gap −0,233 vs Le Château (9e, 2 334 €/m²) gap +0,197.