Description

Code du département de la ou des parcelles cadastrales concernées par la mutation.

La variable est codée sur 2 caractères pour la France métropolitaine et la Corse et sur 3 caractères pour les départements d'outre-mer.

• Cette variable sert de contrainte de vérification pour les tables des schémas départementaux de la base DVF+/DV3F. Pour accélérer une requête SQL sur un département, il peut donc être intéressant d'utiliser cette variable dans la clause WHERE.

Exemple :

SELECT ...
FROM ...
WHERE coddep = '59' AND ...

• Une mutation se rapporte nécessairement à un seul département. Autrement dit, toutes les parcelles concernées par une mutation se situent sur le même département.

Fiabilité - Limite

Cette variable est systématiquement remplie.

Construction

Cette variable est directement issue de la donnée source.

Situer dans le temps

Date de mutation

La date de mutation est le jour de la date de signature de l'acte notarié.

C'est une donnée essentielle car les prix d'un même bien vendu en 2004 et 2014 ne sont pas comparables.

Choix de la période d'observation

Il est important de bien définir les limites temporelles pour le type d'analyse que l'on souhaite réaliser. Deux contraintes s'appliquent pour le choix de la période d'observation :

• Temps de latence liés à DVF : L'enregistrement des actes de vente par les services fiscaux peut prendre plusieurs mois ce qui implique une apparition tardive dans la donnée DVF. Ainsi, lorsque l'on effectue des analyses (tout au moins sur les volumes de mutation ou de montant de transaction, par exemple), il faut éviter de regarder l'évolution sur le semestre précédant l’actualisation de la version de DVF ayant servi à constituer la version DV3F utilisée.
• Appariement avec les Fichiers fonciers : la disponibilité des Fichiers fonciers peut impacter le niveau de remplissage de DV3F, notamment sur la dernière année et particulièrement pour les informations liées aux acheteurs et aux vendeurs ainsi que pour les périodes de construction. Ainsi, lorsque l'on souhaite travailler sur les logiques d'acteurs, par exemple, il est préférable de travailler sur la période couverte par les Fichiers fonciers.

Situer dans l'espace

Informations disponibles pour localiser

DV3F permet la localisation des biens selon plusieurs moyens :

• via les informations administratives : code du département, code insee de la commune, code de section cadastrale, numéro des parcelles concernées par la vente ;
• via la géolocalisation à la parcelle : un localisant ponctuel et un contour vectorisé ;
• via l’adresse du bien : numéro de la voie, libellé de la voie, code postal et libellé de commune ;

Géolocalisation dans DV3F

Des géométries sont présentes dans trois tables de DV3F :

• dans la table disposition_parcelle : le contour et le localisant de chaque parcelle est restitué respectivement par geompar et geomloc ;
• dans la table local : le localisant de la parcelle sur laquelle se situe le local au moment de la vente est restitué par geomloc ;
• dans la table mutation : la variable geomparmut correspond au contour de l'ensemble des parcelles ayant muté, la variable geomloc correspond aux localisants des parcelles sur lesquels se situent les locaux mutés et la variable geompar correspond au contour de l'ensemble des parcelles concernées.

Dans l'illustration ci-dessous, on retrouve, délimitées par des pointillés rouges, les géométries de toutes les parcelles vendues ou sur lesquelles un bien a été vendu (geompar). Lorsque la parcelle a été vendue, elle est ici colorée en vert (geomparmut). Lorsque qu'au moins un local a été vendu sur la parcelle, le localisant de la parcelle est représenté par un rond vert (geomlocmut).

Adresse dans DV3F

Les adresses sont présentes dans la donnée source DVF mais leur rattachement à la parcelle ou au local n'est pas précisé. Elles sont disponibles dans la table adresse et rattachées aux locaux et aux parcelles via les tables de passage adresse_local et adresse_dispoparc.

Pour faciliter l'identification de l'adresse des biens dans DV3F, celles-ci ont été directement rapatriées des Fichiers fonciers dans les tables local et disposition_parcelle. C'est cette solution qui est à privilégier.

Tables et modèle de données

Modèle de données simplifié

On peut décomposer les tables de la base selon l'arborescence suivante :

• 18 tables principales parmi lesquelles on trouve :
  • 3 tables dites "principales"
  • 15 tables dites "secondaires"
• 13 tables agrégées parmi lesquelles on trouve :
  • 4 tables dites "principales"
  • 9 tables "secondaires".

Tables principales

Les tables secondaires

Tables agrégées

Tout MAJIC est dans les fichiers fonciers

Le Cerema garde toutes les variables déjà présentes dans les fichiers MAJIC fournis par la DGFiP. La présence de ces champs permet aux utilisateurs originels de MAJIC de reconstituer leurs propres variables, ou de faire fonctionner avec les Fichiers fonciers les outils conçus pour les fichiers MAJIC. Cependant, en cas de doute entre plusieurs variables, il est plutôt conseillé d'utiliser les variables créées par le Cerema.

Les variables d’origines et les variables affiliées

Dans les fichiers bruts, les informations relatives à un local ou à une parcelle sont parfois situées dans des tables secondaires, nécessitant parfois des jointure nombreuses. À la demande des utilisateurs et pour faciliter l'utilisation des données, le Cerema a donc regroupé les informations les plus demandées dans 3 tables dites essentielles :

• la table des locaux : pb0010_local,
• la table des parcelles : pnb10_parcelle,
• la table des propriétaires : proprietaire_droit.

Ainsi le Cerema a croisé certaines variables provenant de tables différentes (variables affiliées). Par exemple, sur la table des parcelles, du groupe « propriétés non bâties », on ne trouve originellement que des données sur le foncier. Le Cerema a ajouté de nombreuses données provenant de la table des locaux. On peut ainsi connaître le nombre de logements, d’activités, de dépendances, etc présents sur une parcelle.

Par abus de langage, ou parce que certains sont habitués à travailler avec les données d’origine (MAJIC), des utilisateurs parleront de table « propriétés bâties » pour parler de la table des locaux et d’autres de « non bâties » pour les parcelles. En réalité, cette appellation ne s’applique qu’aux variables d’origine et non aux Fichiers fonciers retraités. Le plus simple consiste donc à reprendre les intitulés exacts des tables ou, à défaut, les noms usuels : table des locaux, table des parcelles, table des propriétaires.

Les identifiants uniques

Les variables de jointure

Les variables créées par le Cerema ne représentent qu’une partie du potentiel de variables pouvant être créées. En gardant disponibles les variables d’origine dans les livraisons des Fichiers fonciers, un utilisateur averti peut les combiner pour créer ses propres variables.

Trois variables sont couramment utilisées dans les Fichiers fonciers dès que l’on veut associer deux tables. Ces jointures sont liées par les relations suivantes :

• une parcelle contient entre 0 et N locaux.
• Un local contient entre 1 et 6 droits de propriété.
• Une parcelle contient entre 1 et 6 droits de propriété.

Dans de rares cas, un local ou une parcelle peuvent ne pas avoir de propriétaire. Il s’agit en réalité d’une erreur dans la base.

idlocal

Pour chaque local (notion explicitée par la suite), un numéro unique est attribué sur la France entière. Ce numéro se retrouve dans les tables des locaux et des pev. Il est composé des variables ccodep (code département) et invloc (numéro local invariant). Cet identifiant est unique dans la table des locaux.

idpar

Pour chaque parcelle (notion explicitée par la suite) un numéro unique est attribuée sur la France entière. Ce numéro se retrouve dans les tables des locaux et des parcelles. Il est composé des variables ccodep (code département), ccocom (code communal), ccopre (préfixe de section ou quartier servi pour les communes associées), ccosec (code section cadastrale), dnupla (numéro de la parcelle). Cet identifiant est unique dans la table des parcelles.

idprocpte

Pour chaque compte-propriétaire (notion explicitée par la suite) un numéro unique est attribué sur la France entière. Ce numéro se retrouve dans les tables des locaux, des parcelles et des propriétaires. Il est composé de ccodep (code département), ccocom (code communal), dnupro (numéro du propriétaire).

Les identifiants permettant une liaison avec d’autres bases

En outre, les Fichiers fonciers contiennent des données permettant des liaisons avec d’autres bases de données.

Variable département

La variable ccodep contient le code du département.

Cependant, le nom du champ n’est pas toujours le même selon la table utilisée. Le plus courant est ccodep, mais d’autres intitulés existent : ccodepb, ccodepl.

Variable communale

La variable idcom contient le numéro INSEE de la commune. Le code idcomtxt correspond au nom de la commune en toutes lettres, comme présent dans les données INSEE au 1er janvier.

Les Fichiers fonciers 20XX contiennent les données au 1er janvier 20XX.

⚠️ Il est nécessaire de prendre des précautions concernant les fusions de communes. En effet, certaines communes existent toujours dans les Fichiers fonciers au 1er janvier 20XX, alors qu’elles ont été absorbées lors d’une fusion à la même date. De même, certaines fusions non prises en compte par l'INSEE sont anticipées par les Fichiers fonciers. Ces problèmes sont rares à l'échelle nationale (quelques communes par millésimes), mais doivent tout de même faire l'objet d'une vérification.

Jointures à l’adresse

Il est possible de réaliser des jointures avec d’autres bases de données en se servant de l’adresse.

⚠️ Les adresses des Fichiers fonciers n’étant pas normalisées, il peut être délicat d’effectuer cet appariement. Dans tous les cas, il est toujours préférable d’utiliser des jointures géographiques.

Objets géométriques

Les Fichiers fonciers (tables des parcelles et des locaux) sont géolocalisés. Il est donc possible de les croiser avec des autres objets géomatiques.

Il est ainsi possible de repérer les locaux / parcelles dans les zones U des PLU, dans les quartiers prioritaires de la ville, autour d’arrêts de transports collectifs, etc.

Identifiant parcellaire

Le champ idpar (identifiant parcellaire) permet de faire la jointure avec d’autres bases. On peut ainsi citer la BD Parcellaire de l’IGN, ainsi que les données cadastrales, mais aussi toutes les données locales (liste des acquisitions d’une collectivité, emprise d’une opération d’aménagement, registre parcellaire graphique etc.)

Identifiant Siren du propriétaire

Dans la table des propriétaires, il existe la colonne dsiren, qui reprend le code siren du propriétaire.