Collecter les données PTZ dans le contexte du serveur RStudio des DREAL
Varibles attendues :
- Nombre de PTZ
- Nombre de PTZ par type d’opération ( Ancien / Neuf )
- Nombre de PTZ par type de construction ( maison / appartement )
- Prix au mètre carré de l’opération
- Durée totale moyenne du PTZ
- Durée médiane moyenne du PTZ
- Montant moyen du PTZ
- Montant médian du PTZ
- Montant moyen de l’ensemble des prêts de l’opération
- Montant médian de l’ensemble des prêts de l’opération
- Durée moyenne du prêt principal
- Durée médiane du prêt principal
- Montant moyen du prêt principal
- Montant médian du prêt principal Pour moi, pas de secret sur ces variables qui ne permettent pas d'identifier les emprunteurs.
Activity
assigned to @Daniel.Kalioudjoglou
mentioned in issue #90 (closed)
created branch
95-collecter-les-donnees-ptz-dans-le-contexte-du-serveur-rstudio-des-drealto address this issueadded En cours label
@christelle.belkacem Pour le prix au m2/opération, on ne va pouvoir le calculer que dans le neuf, car on n'a qu'un indicateur de surface, qui se nomme surh, qui correspond à la surface habitable, et il est précisé que pour l'ancien, il s'agit de la surface avant travaux.
-
indicateurs utilisés
- cpfl = code postal
- cins = code insee
- cdco = code commune déclaré
- lcom = libéllé commune
- timm = type d'immeuble (1 = individuel, 2 = collectif)
- tope = type d'opération (neuf/ancien)
- surh = surface habitable (dans l'ancien, surface avant travaux)
- vtto = montant total de l'opération
- vtpr = montant de l'ensemble des prets
- vtpz = montant du pret à taux zero
- durt = durée total du pret à taux zero
- vtpp = montant du pret principal
- dtpp = durée totale du pret principal (mois)
Edited by Daniel.Kalioudjoglou -
@christelle.belkacem @JulietteEngelaere je pense qu'il y a pas mal d'erreurs dans la base, car il y a des chiffres exorbitants. Sur une petite commune de l'ain , on a un ptz individuel à plus de 21 millions d'euros.Dans cet exemple, on est sur une surface habitable de 165m2. Et l'Ain, ce n'est pas la côte d'azur. ça serait plus logique si on dit qu'il manque la virgule des centimes, ce qui nous ferait 213.406,93 euros. Ce qui collerait avec le total des prets de 203.920, un pret principal de 151.480 et un ptz de 28.440.
Sur la base entière, on a 297 ptz individuels avec un montant de l'opération à plus de 50 millions d'euros. Sur ces 297, 139 ptz (presque la moitié) ont un montant total des prets inférieur à 500.000 euros, ce qui pourrait correspondre donc à une erreur de virgule. Seulement 7 de ces 139 logements font plus de 200m2.
Plus grave,pour l'ensemble de la base (individuel + collectif), le nombre de cas où vtto (montant de l'opération) < vtpr (montant de l'ensemble des prets) est de 270.235 pour un total de 775.353 observations. Ce qui signifierait que dans 35% des cas, l'emprunt serait plus élevé que le prix d'achat.
Sinon on a 87.436 observations pour lesquelles le PTZ (vtpz) est supérieur au pret principal (vtpp) ; 11,3% des observations. ça me semble louche.
Par contre, complètement impossible: le ptz(vptz) est supérieur au montant de l'ensemble des prets (vtpr): 21.009 observations soit dans 2,7% des cas.
On fait quoi ?
-
@christelle.belkacem @JulietteEngelaere Après m'être re-penché sur l'intégration des données PTZ, nous avons 2 solutions;
-
solution initiale à savoir on ne faisait que les calculs sur le nombre de ptz avec quelques croisements. Ce sont les 3 premières variables de la liste. Dans ce cas le script est quasi opérationnel. Cette solution permet d'intégrer de suite des données 2023, mais cela ne répond pas à la demande de Christelle.
-
solution 2: on intègre le maximum possible des indicateurs souhaités. Dans ce cas il va falloir pour de nombreux indicateurs, passer les filtres recommandés pour supprimer les valeurs aberrantes. En face de chaque indicateur calculé, il va falloir afficher le nombre de lignes auquel il se rapporte, car pour une même commune, le nombre total de ptz sera différent du nombre de ptz pris en compte pour cet indicateur. Et ce nombre de ptz de l'indicateur servira aussi pour le calcul du secret stat.
Pour le secret statistique, on sera donc sur une logique similaire à ce qui a été fait pour EPTB ou ECLN.
Concernant les scripts, les données non secrétisées ne devant pas sortir du serveur rstudio, les scripts de cogification et de secrétisation, seront effectués aussi sur le serveur rstudio. Par soucis de simplification, je pense qu'il serait bienvenue d'y mettre aussi par la même occasion le script de calcul d'indicateurs.
Le temps de développement est je pense un peu moins important que celui qui a été passé pour EPTB (on a gagné en expérience), mais reste quand même bien conséquent. Par contre il y aura peut-être du temps à passer pour comparer nos chiffres avec les chiffres nationaux (s'attendre à des écarts), vu que l'on n'a qu'une vision très floue de la méthode de filtrage utilisée par le national. Pour moi, il ne s'agit plus d'une simple mise à jour, comme considéré au départ, mais d'un véritable projet.
En fonction des priorités du service, je suis prêt à attaquer. A vous de me dire si je passe ça avant ou après propre.artificialisation.
Edited by Juliette Engelaere-Lefebvre -