Rova Ralaimidona · irova@me.com

📌 Objectif¶

Cartofriche est un inventaire recenssant les données des friches en France, celle ci contient:

• une application cartographique interactive affichant la liste des friches par zones et leur statuts avec projets en cours ou non, avec 14 986 données complétées, et des donnees interactives textuelles complétant les informations.
• Les données agrégées sous forme de tableau contenant 28115 lignes.
• Et enfin les données issues des différents observatoires. 7239 lignes

Ce notebook vise à :

• Évaluer la qualité des données (complétude, unicité, actualité, etc.) ;
• Identifier les valeurs manquantes, doublons et éventuelles incohérences ;
• Comprendre les écarts entre la carte interactive et les jeux de données tabulaires ;
• Identifier les variables cibles et préparer les données à des analyses statistiques ou des modèles prédictifs, le cas échéant.

Problématiques¶

• Comment la qualité des données impacte-t-elle l’expérience utilisateur de Cartofriche et la fiabilité des usages associés ?
• Quels paramètres utiliser pour prédire le potentiel de mutabilité d'une friche?

Aperçu visuel des indicateurs de qualité¶

Avant d’entrer dans les détails techniques, voici un aperçu synthétique de plusieurs indicateurs-clés de qualité, évalués sur les jeux de données disponibles :

Aperçu du jeu de donnée:

28115 lignes chargées — 50 colonnes

Problématiques identifiées sur la qualité¶

• Présence importante de valeurs manquantes ou ambigües, nécessitant un travail de clarification et de normalisation.
• Vocabulaire redondant, notamment l’usage fréquent de catégories comme "Autres", à normaliser.
• Noms de colonnes parfois longs ou peu explicites, à harmoniser pour une meilleure lisibilité.
• Incohérences dans les types de données et la structure des valeurs, à corriger dès l’audit qualité.
• Plusieurs colonnes sont quasiment vides : un arbitrage est à faire entre suppression et enrichissement.
• Origine de certaines valeurs floue : une documentation précise est indispensable.
• Corrélations possibles entre certaines variables : des visualisations croisées sont à prévoir.

Méthodologie¶

Nous nous intéréssons aux Données gouvernementales, car elle est la plus exhaustive friches-standard.csv Pour auditer la qualité des données nous avons évaluer:

• les valeurs manquantes
• doublons à vérifier par subset
• unifomité des features et des types, uniformité de la casse
• analyse statistique descriptive et analyse sur l'équilibre des données
• focus sur les variables pertinents pour la mutabilité

🧩 Description des jeux de données¶

les données cartofriche sont issues de data.gouv, Le dataset comprend les données issues:
• des données gouvernementales
• les données issues des observatoires

Le jeu de donnée gouvernementale comprend 50 colonnes 'Afin de constituer une base nationale de pré-recensement des friches, le Cerema s'est appuyé sur deux sources de données :

BASOL est une base de données nationale sur les sites et sols potentiellement pollués appelant une action des pouvoirs publics, produites par le Ministère de la Transition Ecologique ; les données utilisées sont issues du travail de consolidation de la base réalisé par le collectif Lou Dupont, et diffusé sur data.gouv.fr ;
BASIAS est une base de données de l’inventaire historique des sites industriels et activités de service, produites par le Ministère de la Transition Ecologique et le BRGM ; les données utilisées sont également issues du travail de consolidation de la base réalisé par le collectif Lou Dupont, et diffusé sur data.gouv.fr.'

reférences: https://artificialisation.developpement-durable.gouv.fr/agir-et-etre-accompagne/cartofriches/donnees-utilisees

Visualisation des origines des données¶

Le graphique ci-dessous illustre les liens entre les principales sources de données (ex. ADEME, UrbanSIMUL, BASOL) et les variables du jeu de données.

Chaque lien correspond à une colonne, colorée selon son domaine thématique (pollution, urbanisme, bâti, etc.).
L’objectif est d’assurer la traçabilité des variables, d’anticiper les croisements possibles, et de repérer les éventuels doublons ou chevauchements.
🧩 Remarques complémentaires sur les sources non représentées dans le Sankey :

• Certaines bases nationales comme MAJIC (DGFiP – fichiers fonciers) et BDND sont évoquées dans les documents normatifs comme sources potentielles. Elles sont cependant non identifiées explicitement dans les colonnes actuelles du fichier friches-standards.csv.
• Il est probable que des variables telles que unite_fonciere_refcad, proprio_nom, ou comm_insee soient partiellement issues de croisements avec MAJIC, via des exports intermédiaires non documentés dans le dictionnaire de variables.
• De même, des jeux comme DV3F, ou les outils régionaux (ex : UrbanSIMUL) pourraient avoir enrichi certaines dimensions sans que la traçabilité complète ne soit conservée.

🛠️ Pour un usage avancé ou une mise à jour dynamique de la base, il serait pertinent de demander à l’éditeur Cartofriches un mapping source/variable complet, ou de tenter de le reconstruire en comparant les exports avec les bases originales.

Cette représentation est particulièrement utile pour :

• Identifier les variables fournies par plusieurs sources (potentiel conflit de versions) ;
• Prioriser les enrichissements ou contrôles selon la source ;
• Structurer le dictionnaire de données par groupe cohérent.

Interprétation

• La source ADEME alimente plusieurs variables critiques liées à la reconversion, à la typologie du site et à sa documentation.
• Le domaine "Pollution" est largement couvert par BASOL, avec des informations souvent hétérogènes.
• Certaines variables proviennent de sources peu documentées ("Inconnue ou manuelle") → nécessitent un traitement particulier ou une exclusion conditionnelle.
• On remarque un chevauchement partiel entre Cartofriches, BASIAS et les observatoires locaux sur les métadonnées du site : à clarifier pour éviter les incohérences.
• ici source_nom montre la répartition des fournisseurs des données mais ces fournisseurs eux mêmes utilisent d'autres bases de données comme les données gouvernementales, ou sources sur georisques

⚠️ Il serait intéressant de les revérifier redondances, il y a un mélange entre sources, type de saisie, et les opérations qui ont été réalisées par le cerema, comme les agrégations ou opérations manuelles? Refaire la distinction entre fournisseur des données et source des donnée

Rôles dans la chaîne de la donnée¶

enrichissement possible et source des données

🧾 Audit Qualité¶

Répartition des Valeurs manquantes dans le temps¶

Remplacement des valeurs inconnues¶

dtype('O')

2022-10-10
2021-12-31

Commentaire: Les données ci dessus montrent la répartition des Na dans le temps, on constate une zone entre 12/2021 10/2022 ou la complétude de certainnes données comme site_url, site_securite, activite_libelle sont plus importantes ⚠️problématique qui gére ces données, y a t 'il une maintenance automatique y a t'il des observatoires qui complètent moins bien

⚠️définir les critères d'exploitabilité et de qualité par rapport a ML ou audit qualité ou mix

📊 Analyse métier et qualité¶

La complétude, l'unicité, la pertinence, la validité, ainsi que la criticité de chaque variable est analysée dans un premier temps pour évaluerla qualité générale des données fournies par cartofriche et leur provenance, cette analyse exhaustive permet un mapping des données, une navigation plus simple pour les détails. Mais aussi la compréhension métier de chaque variable, ce qui est critique pour l'évaluation de la pertinence.

Le dataset a été séparé en plusieurs dataframe, une catégorisation mixte prioritairement

• métier, par catégorie ou provenance propable, le travail a été déjà grandement facilité par l'ajout des préfixes
• fonctionelle: les données ayant la même fonction comme les localisations, les données de surface, les données temporelles

Dictionnaire des variables¶

Fonction d'audit¶

Fonction de tri métier¶

Fonction de detection des outliers et modalités invalides¶

Fonction de Transformation des dates et gestions des outliers¶

🏷️ Informations générales¶

L'analyse de la qualité de ces données fait ressortir plusieurs points de vigilance sur les données information:
'site_id', 'site_nom', 'site_type', 'site_statut', 'site_occupation'
• Valeurs manquantes : De nombreuses entrées présentent des valeurs non renseignées dans certains champs (par exemple, absence d'information pour le statut d'un site ou sa taille). Certains attributs clés sont incomplets pour une proportion significative des sites.
• Doublons potentiels : On observe des cas où des sites semblent apparaître en double (même nom ou mêmes coordonnées GPS). Ceci peut provenir de la fusion de plusieurs sources de données – un même site ayant pu être inventorié plusieurs fois.
• Types de données et formats : Quelques incohérences de format existent, par exemple des codes chiffrés stockés comme du texte, ou des catégorisations divergentes pour un même champ selon les sources (nécessitant une harmonisation).
• Distribution déséquilibrée : Certaines variables catégorielles sont dominées par une modalité unique. Par exemple, si la majorité des friches sont d’un seul type d’usage industriel, cela crée un déséquilibre pouvant biaiser les analyses.
Interprétation et recommandations : Ces constats soulignent des défis pour la fiabilité des analyses. Les valeurs manquantes indiquent qu'une partie de l'information est indisponible, ce qui peut limiter les conclusions ou nécessiter des méthodes d'imputation. La présence de doublons suggère de dédupliquer les données afin d’éviter de compter plusieurs fois le même site et d’obtenir des statistiques correctes. Les problèmes de format (types inadéquats, libellés incohérents) doivent être corrigés pour assurer une interprétation correcte des variables (par exemple convertir les champs numériques au bon format, uniformiser les catégories de classification). Enfin, la domination d’une seule catégorie dans certains champs invite à la prudence : elle peut refléter un biais de collecte (p. ex. un inventaire centré sur un certain type de friche) et nécessite de nuancer l’analyse ou d’enrichir les données pour mieux représenter les autres cas.

site_id (identifiant unique)¶

Aucune valeur manquante (0%) et chaque identifiant semble unique. La qualité est bonne sur ce champ. On ne constate pas de doublon évident ni d’anomalie sur le format.
Causes potentielles : Ce champ est généré lors de l’intégration des données, il est bien géré en interne.
Recommandation : Maintenir l’unicité en contrôlant les doublons lors des imports. Documenter le format de l’identifiant (concaténation de codes) pour lever toute ambiguïté.

⚠️voir le rapport entre les typologies et la provenance ou signification de la typologie

site_nom* (nom de la friche, description)¶

Quasiment pas de valeurs nulles au sens technique (0,02% de NaN) après transformation, mais de nombreuses ⚠️quantifier, valeurs improvisées jouent le rôle de données manquantes. En outre, le nom le plus fréquent est littéralement « Décharge » (415 occurrences), ce qui suggère des noms peu descriptifs ou génériques.
Problèmes de qualité : une part significative de friches n’a pas de nom spécifique (nom très générique), ce qui complique leur identification unique. Certains noms peuvent être dupliqués entre sites (ex : plusieurs sites nommés simplement “Ancienne usine” ou “Décharge”), ce qui correspond plus à une colonne de description générale.
Causes : les bases sources n’attribuent souvent (⚠️quels acteurs) pas de nom propre aux sites, se contentant d’un type ou d’une description sommaire. Les contributeurs locaux peuvent ne pas nommer formellement chaque friche.
Recommandations : Lors de la collecte, encourager un nommage plus descriptif (par exemple en incluant un lieu-dit, une entreprise ou une adresse) afin de distinguer les sites similaires. En l’absence de nom, il vaut mieux laisser la valeur nulle plutôt que “inconnu”, ou générer un identifiant lisible (par ex. « Friche sans nom – Commune YYYY »). Un nettoyage pourrait regrouper les noms très génériques et les compléter avec des informations de localisation pour éviter les confusions. Prioriser la documentation des friches les plus importantes en leur donnant un nom distinct si possible.
⚠️voir combien de lignes sont redondantes avec site_adresse ou site_id

Commentaire: ⚠️vérifier pertinence existence site_nom et site_id et redondance, Pourquoi il y a des données de la forme 00000_00000 quels lignes ont tendance a avoir des données manquantes? pourquoi? besoin de standardisé l'entrée des données? Site_numero (identifiant unique) : Aucune valeur manquante (0%) et chaque identifiant semble unique. La qualité est bonne sur ce champ. On ne constate pas de doublon évident ni d’anomalie sur le format (de type code INSEE_commune + numéro tel que 01001_32316). Causes potentielles : Ce champ est généré lors de l’intégration des données, il est bien géré en interne. Recommandation : Maintenir l’unicité en contrôlant les doublons lors des imports. Documenter le format de l’identifiant (concaténation de codes) pour lever toute ambiguïté.

site_type (type de la friche standard cnig)¶

19 modalités avec des types comme autre,  inconnu , mixte (≈17229 occurrences), soit ~61% des sites sans type renseigné. mais aucune catégorie ne domine largement (la plus fréquente “Décharge” ne représente que 1,5% des cas).
Problèmes : plus de la moitié des sites n’ont pas de typologie définie. ⚠️ traçabilité des données: vérifier combien des sites ayant un type, ont une source vérifiée
Causes : Les sources historiques ne fournissent pas toujours une classification par type, ou utilisent des classifications différentes. Par exemple, BASIAS note des activités passées plutôt qu’une typologie normalisée de friche, et les inventaires locaux peuvent varier dans leurs terminologies.
Recommandations : Normaliser la méthode de reconnaissance des types de friches et appliquer une classification homogène. On peut s’appuyer sur un référentiel (industrielle, commerciale, urbaine, naturelle, etc.) et recoder les valeurs existantes en conséquence. ⚠️Pour les nombreux “inconnu”, essayer une imputation d’après d’autres champs (par ex. l’ancienne activité ou la présence de bâtiments : une ancienne station-service => friche industrielle) ou via un examen expert. Documenter les catégories de site_type et éventuellement.

Commentaire: Dans le cadre d'un modèle de machine learning il faudrait réechantilloner cette variable, et dabord résoudre les variables ambigues: comment sont réparties ces variables ambigues -> agrégation.
🧠il y a t-il un moyen de prédire site_type en fonction des autres features

site_statut (statut de la friche vis-à-vis d’un projet, variable cible pour machine learning)¶

0% de valeurs manquantes. Seuls 20% des sites ont un statut avec projet.
Problèmes : Le statut – information cruciale (friche avérée, en cours de projet, réaménagée…) – est inconnu pour l’essentiel des sites. De plus, une confusion existe entre statut et provenance.
Causes : À l’origine, Cartofriches distingue les friches confirmées de simples “friches potentielles” identifiées dans BASIAS (qui contient des terrains possiblement pollués mais pas forcément des friches avérées) cnig.gouv.fr . Il semble que cette distinction soit restée en dehors du champ site_statut (peut-être affichée seulement sur la carte interactive). Le remplissage de ce champ a donc été négligé ou remis à plus tard, sauf pour quelques entrées manuelles où un statut de projet a été saisi (ex: “friche avec projet”, “friche réhabilitée”, etc.).
Recommandations : Revoir la définition et l’usage de site_statut. Il faudrait y intégrer systématiquement un statut, par exemple : Potentielle (à vérifier), En projet, Réhabilitée, Abandonnée sans projet, etc. Actuellement, on devrait au moins distinguer les ~13k sites BASIAS en “Potentielles” et les valider ou infirmer au cas par cas. Techniquement, il est recommandé de remplir ce champ par lot : tous les sites provenant uniquement de BASIAS pourraient recevoir statut = “Potentielle (non encore vérifiée)” par exemple. De même, un site provenant d’un appel à projet lauréat pourrait être marqué “Projet en cours”. Documenter les catégories officielles de statut et s’y tenir. Dans l’immédiat, il faudrait rapatrier les deux libellés mentionnés (friche potentielle, non vérifié) dans le champ site_statut pour qu’ils figurent dans les exports, au lieu de les laisser implicites. Cela augmentera la complétude à ~100% et permettra une analyse plus fine de l’avancement des projets. (Complétion possible) : Croiser avec les données de suivi des projets (par exemple fonds friches ADEME) pour mettre à jour le statut des sites engagés dans une reconversion.

site_occupation (occupation actuelle du site)¶

Absence d’information sur 25 850 occurrences, 92% des sites. Seule une minorité (~8%) des fiches ont une occupation indiquée (ex: “partiellement occupé”, “à l’abandon”…). On constate une redondance avec bati_vacance Problèmes : Dans l’écrasante majorité des cas, on ignore si la friche est actuellement utilisée (parking, entrepôt temporaire, etc.) ou complètement délaissée. Les quelques valeurs renseignées peuvent être hétérogènes (texte libre, difficile à regrouper).
Causes : Ce champ n’est pas documenté Seuls certains acteurs locaux ont pu préciser l’occupation (par ex. « partiellement occupée par une entreprise »). Le fait d’avoir mis “inconnu” plutôt que de laisser vide a évité les NaN, mais reflète l’absence d’enquête de terrain sur l’usage courant.
Recommandations : Actuellement, la prédominance d’« inconnu » rend ce champ peu exploitable. Il conviendrait de prioriser une collecte sur le terrain pour les sites stratégiques afin de qualifier leur occupation (ou non). Par exemple, croiser avec des images satellites ou OpenStreetMap pourrait aider à déceler des usages (stationnement, stockage…). Documenter clairement que “inconnu” signifie absence totale d’info (et non “site inaccessible” ou autre interprétation).

Nombre total de lignes où 'site_occupation' contient 'friche': 2080
Nombre de valeurs manquantes dans 'site_type' pour ces lignes: 0
Pourcentage de 'site_type' manquants que vous pourriez compléter parmi ces lignes: 0.00%

site_reconv_type¶

🕒 Données temporelles¶

Les données temporelles (telles que l’année de cessation d’activité ou la date de recensement du site) présentent également des particularités en termes de qualité : Informations temporelles manquantes : Une proportion notable de sites n’a pas d’année renseignée pour certains événements (par exemple, date de fermeture inconnue), ce qui limite les analyses chronologiques. Valeurs incohérentes (outliers) : On détecte quelques dates aberrantes ou peu plausibles. Par exemple, un site pourrait afficher une date très ancienne ou au contraire futuriste, suggérant une erreur de saisie ou une valeur par défaut erronée. Distribution non uniforme : La répartition des friches par année n’est pas homogène. On observe des pics à certaines périodes et des creux à d’autres, reflétant possiblement des vagues de créations/fermetures de sites (ou simplement des biais dans la collecte des dates).

site_identif_date (date d’identification du site)¶

100% de valeurs manquantes. Aucune friche n’a de date indiquant quand elle a été identifiée/inscrite dans Cartofriches.
Problème : On ne sait pas de quand datent les entrées, ce qui empêche de suivre l’historique d’intégration ou de filtrer les sites par ancienneté dans l’inventaire.
Présence de formats non standard '6-09-23', '14-09-23', '31-05-23', '1-08-23' JJ/MM/AAAA. Et autres formats ambigus '1-12-31' → pourrait être 1er décembre 1931, ou 31 décembre 2001. ces valeurs sont très révélateurs de saisies manuelles pour site_actu_date: donc soit les données ont été agrégées a partie de bases de données externes soient urbansimul permet des saisies non stdanrdisées. Causes : Ce champ n’était sans doute pas alimenté par les sources externes (BASIAS, etc., ne fournissent pas une date de “découverte” de la friche). Cartofriches n’a pas non plus historisé la date d’ajout initiale dans la base nationale, d’où un champ vide.
Recommandations : Si possible, renseigner a posteriori la date d’entrée dans l’inventaire national. Par exemple, de nombreux sites semblent provenir du chargement initial de BASIAS en octobre 2022 – on pourrait leur attribuer la date 2022-10-10 (observée comme date d’actualisation massivement répétée). D’autres provenances pourraient être datées d’après les appels à projets ou mises à jour Cerema. Pour les nouvelles saisies, implémenter automatiquement le timestamp d’identification. À défaut, documenter que ce champ est inopérant dans l’état actuel et le retirer de l’export CSV pour éviter toute confusion.

Nettoyage des colonnes de dates et gestions des outliers¶

site_identif_date
str    28115
Name: count, dtype: int64

site_actu_date (date de dernière actualisation)¶

Présent dans ~79% des fiches (seulement 20,7% de NaN). Cependant, la valeur modale est “2022-10-10” pour plus de 15 500 sites, ce qui indique que la plupart des enregistrements n’ont pas été mis à jour depuis le chargement initial à l’automne 2022. Les autres valeurs d’actualisation doivent correspondre à des mises à jour ponctuelles (par ex. quelques sites mis à jour en 2023 ou 2024).
Problèmes : la concentration des dates identiques montre un manque de fréquence de mise à jour – de nombreux sites ont potentiellement des informations périmées (plus de 2 ans sans actualisation). Par ailleurs, quelques dates futures ou incohérentes pourraient exister (pas observées ici, mais à vérifier, ex. si la date était mal formatée).

Causes : Le gros du jeu de données provient d’imports de bases externes à une date donnée (ex. intégration de BASIAS/BASOL en bloc) plutôt que de mises à jour continues. Ensuite, l’effort de mise à jour manuelle ou via les observatoires locaux a été limité, d’où peu de changement de date.
Recommandations : Mettre en place un suivi des mises à jour plus systématique. Cela peut passer par des synchronisations annuelles avec les sources (si BASIAS/BASOL sont mis à jour) ou par sollicitation des acteurs locaux pour revoir les fiches. Il serait pertinent de stocker aussi la date de création initiale (manquante actuellement) pour distinguer l’ancienneté vs. la fraicheur de l’info. En attendant, on peut identifier les sites potentiellement obsolètes en calculant le délai depuis site_actu_date et en priorisant ceux dont la date est la plus ancienne (plus de 2–3 ans) pour vérification. (Complétion suggérée) : Une idée serait de lier Cartofriches à une API d’observatoire ou de data.gouv permettant de notifier des changements (par ex., si un site Basol change d’état, mettre à jour automatiquement), afin d’améliorer la réactivité des actualisations.

site_actu_date
str    28115
Name: count, dtype: int64

📊 Moyenne de l'ancienneté (≤ 9000 jours) : 1068.74 jours
🔹 Médiane : 967 jours
± Écart type : 889.27 jours
📈 Nombre de points : 27862 / 27862

Ces variables sont les seules variables temporelles que l'on a elles indiquent la date de saisie des données et leurs mises a jour site_actu date est un bon indicateur de la qualité de la maintenance du site.
On peut estimer le délai de mise a jour moyen des données, et aussi la récurence de ces mises à jour, il nous manquerai juste une information si jamais il y a des mises a jour multiples. On peut aussi déterminer la fréquence des mises à jour.

local_ancienne_annee / local_recent_annee (années de construction du plus ancien et plus récent bâtiment)¶

Ces deux champs sont totalement vides (100% NaN) en export, mais l’audit laissait entrevoir des “1900” comme valeurs fréquentes (ce qui suggère que 1900 a été utilisé comme substitut d’absence de données pour ces champs). Donc possiblement présents dans la base sous forme “1900” mais convertis en NaN dans l’audit à cause du type? Ou inversement, “1900” a été vu en top valeur, ce qui veut dire qu’il a été enregistré comme chaîne, pas en datetime.
Problèmes : Quoiqu’il en soit, on n’a pas d’informations fiables sur l’âge des bâtiments sur site. Et le cas échéant, la valeur “1900” est un fourre-tout qui fausse la donnée (très peu de friches ont vraiment un bâtiment construit exactement en 1900, c’est plutôt avant 1914 etc. ⚠️ ce champ permet de connaître quels batiments sont concernés par la présence potentiel d'amiante.
Causes : Par manque de données, ces champs n’ont pas été alimentés. Le standard autorise la valeur vide, mais on soupçonne qu’un système a mis 1900 par défaut quand année non connue.
Recommandations : Purger les “1900” qui n’ont pas de sens (ou toute autre valeur par défaut improbable). Si quelques sites ont de vraies années (par ex. on aurait pu en renseigner sur des friches patrimoniales connues), les conserver. Sans données cadastre détaillées, ces champs resteront vides. On peut alors envisager de ne pas les afficher ou de les renseigner via un travail ultérieur (ex: requête sur l’année de construction moyenne des bâtiments de la parcelle via MAJIC, mais c’est complexe et soumis à confidentialité). Bref, à court terme : considérer ces champs comme non disponibles, et les retirer pour ne pas induire l’utilisateur en erreur.

site_reconv_annee ( année de réhabilitation de la friche)¶

Problème: Ce champ est complètement vide. Le standard autorise la valeur vide mais il permettrait la traçabilité des données surtout que au moins 20% ⚠️reverifier des friches recensées sont déja reconverties.
Recommendations: Ce champ n'est pas critique dans le cadre de cartofriche mais il gagnerai a être documenté pour les acteurs de l'urbanisme ou du batiment pour les futurs projet immobiliers et la traçabilité des transformations.

activite_fin_annee (année de fin d’activité)¶

86,75 de rempli, ce qui est surprenant mais signifie que quasiment tous les sites ont une date de cessation d’activité indiquée. La valeur la plus fréquente est 2010 (315 occurrences). Cela indique beaucoup d’arrêts autour de 2010, mais globalement les années doivent s’échelonner du milieu XX° siècle à 2020.
Problèmes : Ce champ est bien rempli mais la fiabilité de l’information peut varier – certaines dates peuvent être par défaut ou arrondies à la décennie. Le fait que 2010 ressorte peut correspondre à une vague de fermetures industrielles, ou simplement à la date arbitraire assignée lorsqu’aucune info précise n’était disponible.
Causes : BASIAS inclut souvent l’année de cessation d’activité (quitte à indiquer 1990 par défaut si l’activité a cessé “avant 1990”, etc.). Il est possible que pour les sites toujours en activité ou incertains, une valeur “1900” ait été utilisée comme code inconnu – à vérifier dans la distribution. (On ne le voit pas en mode ici, signe que ça n’a pas été le cas fréquent, ou ces “1900” ont été filtrés).
Recommandations : Nettoyer les années aberrantes : si “1900” apparaît pour signifier “inconnue”, il faut le traiter comme manquant. De même, vérifier s’il y a des années dans le futur ou très lointaines par erreur de saisie. Sinon, ce champ est exploitable en l’état. On peut envisager de le croiser avec site_actu_date pour repérer les friches très anciennes non remises en usage (écart > 50 ans par ex). Documentation : préciser s’il s’agit de l’année de fin de l’activité principale sur le site (et si oui, laquelle en cas de multiples activités). Données surfaciques.

⚠️ séparer les graphiques, revoir le graphique diagramme de dispersion, illisible

Interprétation et recommandations : Les lacunes temporelles (années manquantes) signifient qu’il faudra être prudent dans l’analyse des tendances historiques – beaucoup de sites ne peuvent pas être situés dans le temps, ce qui empêche de savoir s’ils datent par exemple de périodes industrielles spécifiques. Il serait utile d’enquêter sur les outliers identifiés : une date incohérente doit être vérifiée (peut-être s’agit-il d’une erreur de formatage, comme une confusion de siècle ou l’utilisation d’une date par défaut “1900” en cas de valeur manquante). La distribution inégale des dates suggère que certaines périodes ont été plus propices à la formation de friches (ex : déclin industriel durant une décennie donnée) ou bien que les efforts de recensement se sont intensifiés à certaines époques. Il est recommandé de contextualiser ces tendances avec l’histoire locale et de combler, si possible, les lacunes en recherchant des données supplémentaires pour les sites dont les dates sont inconnues. Visualisations suggérées : Un histogramme du nombre de friches par année (ou une courbe temporelle) pour visualiser les tendances globales et repérer les années anormalement hautes ou basses en nombre de sites. Un graphique cumulatif montrant l’accumulation des friches au fil du temps (si la date de découverte ou de mise en friche est disponible) afin de voir l’évolution du phénomène et d’identifier des points de changement. Une mise en évidence des outliers temporels, par exemple via un diagramme de dispersion où l’axe des X serait l’année et l’axe des Y une autre variable (taille du site, type, etc.), pour voir si les sites aux dates extrêmes ont des caractéristiques particulières. Un croisement entre l’ancienneté et d’autres variables (par ex. comparer la distribution des types de friches ou le statut de pollution selon les périodes) pour déceler d’éventuels liens entre l’époque de fermeture et la nature des sites.

📍 Données de localisation¶

La qualité des informations géographiques (coordonnées, adresses, communes) influence fortement les analyses spatiales : Coordonnées manquantes ou imprécises : Certains enregistrements n’ont pas de coordonnées GPS renseignées, ou seulement une localisation partielle (par ex. commune sans adresse précise). Cela empêche de cartographier ces sites avec précision. Anomalies géographiques : On note la présence possible de coordonnées incohérentes (p. ex. une inversion latitude/longitude ou un point situé en dehors de la zone du Loiret). Ces cas isolés suggèrent des erreurs de saisie ou de format. Doublons spatiaux : Plusieurs sites partagent exactement les mêmes coordonnées, ce qui indique potentiellement des doublons (le même lieu inventorié deux fois) ou des friches distinctes très rapprochées géographiquement. Concentration spatiale : La distribution des sites n’est pas uniforme sur le territoire. Quelques communes ou zones concentrent une grande partie des friches, tandis que d’autres en comptent très peu, ce qui peut introduire un biais géographique.

Interprétation et recommandations : Les coordonnées manquantes ou imprécises limitent l’utilité du jeu de données pour des analyses cartographiques et la planification territoriale. Il serait pertinent de géocoder les adresses manquantes ou de compléter ces informations via d’autres sources afin de pouvoir intégrer tous les sites dans les études spatiales. Les anomalies repérées (coordonnées hors zone attendue) devraient être vérifiées et corrigées, car elles peuvent fausser les analyses (par exemple un site affiché à l’étranger par erreur). La détection de doublons géographiques implique d’établir une procédure de regroupement des entrées dupliquées : si deux enregistrements représentent le même site, ils devraient être fusionnés pour éviter une double comptabilisation. Enfin, la forte concentration de friches dans certains secteurs peut indiquer des zones industrielles historiques ou un effort de recensement inégal selon les communes. Il faudra en tenir compte dans l’analyse, par exemple en comparant les contextes locaux ou en normalisant par la taille de la commune ou de la population afin de relativiser ces concentrations.

comm_insee* (code INSEE de la commune)¶

Comme pour le nom de commune, pas de NaN direct (0.94% manquants) mais beaucoup de codes non valides (probablement “inconnu” ou vide masqué). On observe par exemple le code 16015 (Angoulême) comme valeur la plus fréquente, ce qui correspond au fait qu’Angoulême concentre de nombreux sites (697 sites, record national).
Problèmes : un code INSEE “inconnu” n’est pas exploitable pour les jointures avec d’autres référentiels. De plus, l’absence de code valide pour autant de cas signale possiblement un défaut de correspondance entre comm_nom et comm_insee pour certains enregistrements.
Causes : Même causes que pour comm_nom – données sources incomplètes. Il est possible que pour les sites “inconnus”, aucun code n’ait pu être attribué (commune non déterminée). Il se peut aussi que certains codes présents soient obsolètes (fusion de communes non mises à jour, codes postaux pris à tort pour code INSEE, etc.).
Recommandations : Nettoyer et compléter les codes INSEE en se basant sur le nom de commune (quand connu) ou par reverse geocoding des coordonnées. Mettre en place un contrôle de validité (5 caractères numériques correspondant à une commune réelle du bon département). Lorsque le nom est “inconnu” mais que le département est connu (voir ci-dessous), on peut au moins inférer le code du département (les deux premiers chiffres du code INSEE). Sinon, mieux vaut laisser la valeur vide que “inconnu”.

⚠️ interpoller avec d'autres colonnes essayer de comprendre pourquoi ces valeurs manquent pour proposer des correctifs durables pourtant elles sont obligatoires

comm_nom* (commune d’implantation)¶

Aucune valeur nulle techniquement (0,47% NaN), avant transformation 132/28115 , certainnes valeurs étaient "inconnu". Problèmes : la commune est une information fondamentale, son absence empêche l’agrégation territoriale (par commune, département…). Causes : Ces “commune inconnue” proviennent probablement de données mal géoréférencées initialement – par exemple des sites pour lesquels seule une région ou des coordonnées approximatives existaient. Il est aussi possible qu’une erreur de lecture du CSV ait traité des valeurs manquantes comme du texte.
Recommandations : Vérifier la cohérence commune/coordonnées – pour chaque “commune inconnue”, on peut tenter de déterminer la commune via les coordonnées géographiques (si dispos) ou via le code parcelle. Idéalement, aucun site ne devrait rester sans commune : il faudrait effectuer un rattrapage manuel pour ces 132 de cas, en utilisant des outils SIG pour retrouver la commune d’appartenance. Par ailleurs, remplacer “inconnu” par une valeur nulle serait préférable pour bien marquer le manque d’info. On peut aussi mettre en place une contrainte : ne pas accepter de nouvelle fiche sans commune (quitte à utiliser la commune la plus proche connue).

Series([], Name: count, dtype: int64)

site_adresse (adresse détaillée)¶

Seulement ~14% des sites ont une adresse renseignée. Même parmi les adresses présentes, beaucoup sont partielles (par ex. « Le Village » est la plus courante avec 46 occurrences – un libellé très générique de lieu-dit). ce champ peut être primordiale dans le cas du référencement d'un local ou batiment en particulier. Problèmes : L’absence d’adresse précise pour la majorité des sites rend difficile le géoréférencement exact hors usage des coordonnées. De plus, certaines adresses sont peu informatives ou non normalisées (lieux-dits sans numéro, tout en majuscules, etc.).
Causes : BASIAS fournit souvent la commune et le lieu-dit plutôt qu’une adresse postale exhaustive, expliquant ces nombreux vides. Les sites repérés par photo aérienne ou déclaration sommaire n’ont pas toujours d’adresse.
Recommandations : Améliorer la collecte d’adresses lors des contributions locales (encourager la saisie de la voie, du numéro et du lieu-dit). Enrichir a posteriori via un géocodage inverse des coordonnées disponibles – par exemple utiliser la BAN (Base Adresse Nationale) pour retrouver une adresse proche. Il est utile de stocker séparément les composants (n°, voie, lieu-dit, code postal) pour homogénéiser le format. Enfin, considérer qu’en l’absence d’adresse, la commune et un lieu-dit ou des coordonnées approximatives doivent suffire à identifier la friche – documenter explicitement ces cas. Les coordonnées géographiques permettront d'enrichir éventuellement les adresses, mais une vérification visuelle ou une prédiction multisource sera necéssaire.

Commentaire: la variable site adresse est inhomgène avec 86% de Na des typologies variables, problème de casses, des abréviations dans des cas et d'autres sans abréviation des lieux dits.
Quels types de friches ont tendance à ne pas avoir d'adresses? Pourquoi ? réponse partielle, des friches sur des lieux-dits

geompoint* (coordonnées du centroïde en WKT)¶

Champ ajouté lors de l’analyse (non présent tel quel dans le CSV original, il a été construit à partir de la latitude/longitude). 95,9% des sites ont une coordonnée (26966 points renseignés), ⚠️ quantifier sont en doublons. Le format est POINT (lon lat). La valeur la plus fréquente – “POINT (3.175503 50.7054)” – apparaît 18 fois, ce qui signifie qu’il y a 18 sites pile au même endroit (même coordonnées). Cela peut indiquer des doublons géographiques (plusieurs enregistrements pour un même lieu) ou un arrondi ayant fusionné des points très proches.
Problèmes : Quelques sites De plus, le fait que 18 sites partagent exactement le même point suggère soit des doublons de saisie, soit une imprécision (ex: toutes les friches d’une commune pointées sur la mairie).
Causes : Les clusters de points identiques peuvent provenir de friches sur la même adresse (ex: plusieurs parcelles d’un même site enregistrées séparément) ou d’une localisation par défaut (ex: coordonnées du centre de la commune utilisées pour toutes les friches de cette commune lors de l’import initial BASIAS – d’où 18 sites sur le même point).
Recommandations : Traiter en priorité les friches en doublon. Sinon, si c’est juste un point communal générique, il faudrait affiner en recherchant des informations plus précises (ou au moins disperser légèrement les points pour ne pas confondre, mais c’est du bricolage). Vérifier la précision globale : les coordonnées sont issues des données sources – certaines peuvent être approximatives (ex: données BASIAS souvent pointées au centroïde commune). On pourrait marquer un champ “precision” (non présent) pour indiquer la fiabilité. Pour l’instant, garder en tête que beaucoup de points sont précis à la commune seulement.
Amélioration : lorsque les parcelles seront identifiées, recalculer les centroïdes exacts. Documenter que geompoint est un centroïde approximatif pour visualisation, non l’emprise réelle.

geomsurf (géométrie surfacique en WKT)¶

100% manquante dans l’export – aucun polygone de périmètre n’est fourni. Ce champ était prévu pour contenir la géométrie de la friche (polygone). Son absence totale signifie qu’on ne dispose pas des contours des sites, juste des points.
Problèmes : Sans ces polygones, difficile d’évaluer précisément la surface (d’où le champ site_surface mal rempli), d’analyser les recouvrements (avec zones naturelles, etc.) ou d’afficher l’emprise exacte sur une carte.
Causes : Les données sources n’ont pas été livrées avec les géométries, à l’exception de potentiellement quelques observations locales. De plus, inclure des polygones de milliers de sites dans un CSV aurait été lourd – c’est peut-être volontairement exclu de cette exportation (les polygones sont peut-être seulement dans la base SIG du Cerema).
Recommandations : Récupérer et intégrer les polygones lorsque possible. Cela peut se faire via : (a) les parcelles cadastrales si identifiées, en agrégation, (b) les contours fournis par certaines régions ou EPF, (c) du dessin manuel sur orthophoto. C’est un chantier de fond qui dépasse l’urgence, mais c’est crucial pour la suite (notamment mesurer l’avancement du zéro artificialisation nette). À court terme, on pourrait au moins fournir la surface approximative (ce qui avait été tenté via site_surface, mais avec limites vues). Si la décision est de ne pas publier de polygones pour l’instant, il faut clairement le mentionner. Peut-être que dans l’interface Cartofriches, l’emprise est visible mais pas exportée – il faudrait alors expliquer aux utilisateurs de données que seule une localisation ponctuelle est disponible dans le CSV standard.

🏙️ Champs Urbanisme¶

Problèmes de qualité : Cette section présente des valeurs manquantes notables, notamment pour les champs de zonage urbain (par exemple, les zones d’urbanisme peuvent être non renseignées pour de nombreux sites). On observe aussi des formats de données complexes (le champ des distances de desserte compile plusieurs valeurs séparées par des caractères spéciaux, ce qui le rend difficile à exploiter tel quel). De plus, certaines distributions sont très déséquilibrées : une modalité unique domine la plupart des enregistrements (par exemple, un type de document d’urbanisme couvre l’essentiel des sites), réduisant la diversité d’information utile. Interprétation : Ces lacunes et déséquilibres suggèrent que l’intégration des données d’urbanisme n’est pas homogène selon les sites. De nombreux champs non renseignés (ou partiellement formatés) limitent la capacité à analyser l’impact du zonage et de l’accessibilité sur la réutilisation des friches. La dominance d’une valeur unique (par exemple, la majorité des sites sous un même régime d’urbanisme) indique un biais potentiel : l’attribut apporte peu de pouvoir discriminant, ce qui complique l’identification de tendances significatives sur ces critères. Il faudra en tenir compte pour ne pas tirer de conclusions hâtives biaisées par la sur-représentation d’un cas général.

urba_doc_type¶

(Les champs urba_ décrivent le zonage et le document d’urbanisme applicable sur la friche.) Urba_doc_type (type de document d’urbanisme) : Aucune valeur nulle techniquement (0% NaN), mais pratiquement toutes les friches sont marquées “inconnu” sur ce champ. Quelques valeurs existantes correspondent au type de plan local : on voit par exemple « PLU » apparaître 12 694 fois (ce qui indique que 45% des sites sont sous PLU) et possiblement « CC » (carte communale) ou « RNU » ailleurs. Cependant, il est probable que ces mentions aient été remplies par défaut plutôt que via un vrai croisement.
Problèmes : Pour la moitié des sites, on ignore sous quel règlement d’urbanisme ils se trouvent (PLU intercommunal, plan communal, etc.). Et pour l’autre moitié, l’information est peut-être incomplète ou par défaut (PLU mis dès qu’une commune a un PLU sans préciser plus).
Causes : Le Cerema avait prévu de croiser les coordonnées des friches avec le Géoportail de l’Urbanisme pour renseigner ces champs cnig.gouv.fr . Il semble que ce processus n’ait été fait que partiellement ou automatiquement. Le remplissage de “PLU” pour de nombreux sites indique que l’on a pu attribuer le type de doc d’urbanisme pour certaines communes, mais l’absence de détail (inconnu ailleurs) montre une couverture incomplète.
Recommandations : Finaliser le croisement avec les données d’urbanisme nationales cnig.gouv.fr . On sait pour chaque commune si un PLU, une carte communale ou le RNU s’applique. Donc, à minima, aucun site ne devrait être “inconnu” sur ce champ : il suffit d’utiliser le statut de la commune. Par exemple, si une commune est sous RNU, toutes ses friches devraient être marquées RNU. Si PLU, marquer PLU. Ce remplissage global est faisable via la liste des documents d’urbanisme approuvés. Ensuite, distinguer éventuellement PLUi (plan local intercommunal) vs PLU communal, etc., selon le besoin. Priorité : élevée, car c’est une donnée contextuelle importante pour la reconversion (règles d’urbanisme applicables).

urba_zone_type (type de zone de planification)¶

Là encore, pas de NaN direct mais “inconnu” très fréquent (ex: 89% des sites, 25 297 occurrences). Parmi les zones renseignées, la plus courante est « U » (zone urbaine) avec 15 992 occurrences, loin devant d’autres (on peut supposer que “N”, “AU” etc. apparaissent beaucoup moins).
Problèmes : Le zonage précis de la friche (U = urbain, N = naturel, AU = à urbaniser, etc.) manque pour la vaste majorité. Même les zones indiquées “U” pour plus de la moitié des sites peuvent provenir d’une attribution automatique (toutes friches en PLU mises par défaut en zone U ?). Il y a donc un risque d’information erronée ou incomplète – par exemple, certaines friches rurales en zone N pourraient avoir été notées “inconnu” ou étiquetées U par défaut.
Causes : Le croisement précis avec le zonage n’a probablement pas été fait sauf exceptions. Obtenir le zonage d’une parcelle nécessite la couche SIG du PLU, ce qui est complexe à l’échelle nationale (mais faisable via le géoportail de l’urbanisme qui propose ces données). Le Cerema prévoyait de le faire cnig.gouv.fr , mais peut-être après notre extraction de données.
Recommandations : Croiser les coordonnées des sites avec les zonages d’urbanisme disponibles. Beaucoup de PLU numérisés sont sur le géoportail, on peut donc automatiser la récupération du zonage réglementaire de chaque friche (ou de son centre). Cela renseignerait ce champ de façon fiable (typeZone = U, AU, N, etc.). À défaut d’automatisation complète, on peut au moins remplir “RNU” pour les communes sans document d’urbanisme (le standard prévoit de mettre zone_type = RNU dans ce cas cnig.gouv.fr ). Nettoyage : vérifier si la zone “U” n’a pas été attribuée abusivement. Par exemple, la présence de 15 992 « U » alors que seulement 12 694 PLU sont notés suggère que même des sites en carte communale ou autre ont pu être marqués U (erreur). Il faudra recoder correctement selon le contexte de chaque commune.

urba_zone_lib (libellé de la zone d’urbanisme)¶

Environ 14% des sites ont une valeur, 86% manquent (corrélé à zone_type). Le libellé donne le nom précis de la zone (ex: « ZnC – Secteur non ouvert à la construction… » apparaît, c’est typiquement un libellé de zone inconstructible dans une carte communale, vu 488 fois).
Problèmes : Très peu de friches ont ce niveau de détail. Celles qui l’ont pourraient toutes provenir d’une même source (par ex. des friches d’une région dont on a croisé le zonage CC ou PLU). La majorité est “inconnu”, donc inutilisable.
Causes : Identiques à zone_type – il faut la donnée SIG du PLU pour récupérer le libellé de zone. Visiblement fait pour un nombre limité de cas (peut-être un lot d’essai).
Recommandations : Procéder au remplissage via les données du géoportail en même temps que zone_type. Une fois la zone type identifiée, on peut extraire son libellé. Noter que le standard précise que pour les communes en carte communale, urba_zone_lib = urba_zone_type (par ex. ZnC) cnig.gouv.fr , et pour les communes en RNU on met “RNU”. Donc on devrait au moins mettre “RNU” partout où applicable.
Documentation : ce champ n’est pertinent que si le zonage détaillé est connu – sinon le laisser vide. On pourrait envisager de le remplir pour les grandes friches urbaines manuellement en priorité, car le libellé donne des indications (ex: “zone industrielle”, “zone agricole protégée”, etc. qui influencent la reconversion). Urba_zone_formdomi /

urba_zone_formdomi (forme dominante de la zone)¶

Ces champs indiquent la forme urbaine dominante (ex: “Urbain dense”, “Rural”), codée et en texte. Actuellement, une partie des valeurs semblent par défaut “1900.0” (ce qui est clairement une anomalie, 1900 n’étant pas une forme d’urbanisme). En effet, on trouve 1900.0 comme mode pour formdomi (1 153 occurrences) et formdomi_txt (1 015 occurrences) – possiblement le résultat d’un champ numérique mal importé.
Problèmes : Ces “1900” indiquent très probablement un défaut de saisie (peut-être ont-ils été confondus avec une année ou un code inexistant). À part ces valeurs aberrantes, le reste doit être vide ou anecdotique. Autrement dit, on n’a pas l’info de forme urbaine pour la quasi-totalité des sites.
Causes : On peut suspecter que “1900” a été utilisé à tort comme valeur vide lors d’un import (par exemple, un champ prévu entier non renseigné s’initialisant à 1900 par défaut, comme on a vu pour les années de construction bâtiments). Ou bien c’est une erreur de mapping – 1900 pourrait correspondre à un code interne par erreur. Quoi qu’il en soit, le croisement avec le géoportail d’urbanisme n’a pas dû renseigner ces champs.
Recommandations : Nettoyer immédiatement les “1900” en les remplaçant par null, car ils n’ont aucun sens ici. Ensuite, décider de l’utilité de ces champs. Le standard CNIG les prévoit, mais ils sont moins critiques. On pourrait estimer la forme dominante via l’occupation du sol ou le zonage (ex: zone UA => urbain dense, zone N => espace naturel). Cela demande des règles heuristiques, pas forcément prioritaire. Documentation : si on conserve ces champs, expliquer qu’ils sont largement non renseignés et que leur calcul automatique est envisagé (par exemple, via la densité bâtie autour du site). En l’état actuel, ils peuvent être ignorés dans les analyses.

urba_zone_formdomi
Habitat                                               1548
Espace naturel                                         862
Activité économique                                    702
Activité agricole                                      682
Mixte habitat/activité                                 390
Autres                                                 137
Equipements public                                      94
Sans objet ou non encore définie dans le règlement      42
Loisirs et tourisme                                     38
Espace remarquable                                      25
Secteur de carrière                                     16
Name: count, dtype: int64

deserte_distance, deserte_commentaire¶

ces champs on été laissé complètement vide, cela peut être du a l'accessibilité de croissement de données, pourtant ce champs est utilisé dans les indices de mutabilité Recommendation encore une fois, il serait intéressant d'utiliser différentes sources de bases de données pour compléter ces champs, c'est un travail exhaustif qui necessiterai à terme une reconnaissance automatisé puis un avis expert ou une visite terrain pour la confirmation des features.

☣️ Pollution¶

Les informations relatives à la pollution des sites (présence de contaminants, types de pollution) sont cruciales mais présentent des problèmes de complétude et de cohérence : Informations manquantes sur la pollution : La majorité des sites ne comportent pas de détails sur une éventuelle pollution. Souvent, le statut "pollué ou non" n’est pas renseigné et aucun liste de polluants n’est fournie, reflétant un manque de données dans ce domaine. Faible proportion de sites déclarés pollués : Parmi les sites qui ont une information, relativement peu sont explicitement marqués comme pollués. Cela peut signifier soit que peu de friches ont été évaluées et confirmées polluées, soit que la donnée est incomplète (de nombreux sites potentiellement pollués restent non confirmés). Types de polluants dominants : Dans les cas où des types de pollution sont indiqués, on observe que quelques catégories reviennent fréquemment (par ex. métaux lourds, hydrocarbures) tandis que d’autres contaminants sont rares. Cette concentration peut indiquer des industries prédominantes dans la région ou une focalisation sur certains polluants lors des diagnostics. Incohérences éventuelles : Il existe des situations où les données de pollution sont contradictoires, par exemple un site marqué "non pollué" alors qu’un type de polluant est listé ailleurs, ou des valeurs de concentration de polluants sans indication claire d’unité ou de seuil de danger.

Interprétation et recommandations : La forte proportion de données manquantes sur la pollution signifie qu’on ne peut pas conclure qu’un site sans information est sain – simplement qu’il n’a pas été évalué ou documenté. Pour une analyse environnementale fiable, il faudrait compléter ces informations en menant des études de terrain ou en croisant avec des bases spécialisées (telles que BASOL, qui recense les sites pollués avérés). Le faible nombre de sites déclarés pollués dans la base actuelle peut minimiser le problème aux yeux des décideurs ; il est donc conseillé de souligner que l’absence de preuve de pollution ne prouve pas l’absence de pollution. La prédominance de certains polluants (ex. métaux lourds) suggère de cibler ces contaminants dans les plans de réhabilitation, mais aussi de vérifier si d’autres polluants n’ont pas été sous-déclarés faute d’analyses approfondies. Enfin, les incohérences doivent être résolues en nettoyant la base : par exemple, uniformiser le statut pollué en fonction de la présence effective de polluants, et clarifier les unités ou seuils utilisés pour les concentrations afin d’éviter toute mauvaise interprétation.

sol_pollution_annee (année de constat de pollution du sol)¶

Quasiment vide – 100% de NaN dans l’audit (aucune valeur exploitable). Il est probable que ce champ n’a été rempli que pour les sites BASOL où une pollution a été constatée une année donnée, mais ces cas sont très rares dans Cartofriches (une centaine tout au plus). L’absence de données indique soit que ces sites n’ont pas été intégrés, soit que l’information n’a pas été extraite.
Problèmes : On ne dispose pas de l’historique de pollution pour les friches polluées, ce qui limite l’évaluation des risques.
Causes : BASOL contient l’année de première constatation de pollution, mais comme très peu de sites Cartofriches ont un identifiant BASOL, l’information n’a pas été reprise. Peut-être aussi un souci d’harmonisation (plusieurs sources de pollution possible).
Recommandations : Importer les données BASOL pour les sites concernés. Concrètement, pour chaque site ayant un site_numero_basol, récupérer l’année de constatation de pollution et la mettre ici. Ce serait un petit volume de données à intégrer (quelques dizaines de valeurs, qui feraient passer ce champ de 0 à peut-être 0,5% de complétude). Sinon, envisager de supprimer ce champ de la vue publique pour ne garder que un indicateur binaire de pollution.

sol_pollution_existe (existence d’une pollution du sol)¶

Champ problématique – moins de 0,01% de rempli (l’audit indique 99,99% de NaN), et en plus un warning de type mixte lors du chargement signale des valeurs hétérogènes. Cela suggère que quelques entrées contiennent “Oui” ou “pollution avérée” tandis que d’autres ont des nombres ou rien. En somme, presque personne n’a “Oui” ou “Non” de renseigné ici, et les rares qui l’ont ne sont pas uniformes (ex: certains sites pollués pourraient avoir la mention textuelle “pollution avérée” cnig.gouv.fr tandis que d’autres “1”).
Problèmes : Ce champ devrait indiquer clairement si la friche est polluée, or ce n’est pas exploitable. Avec si peu de valeurs, on ne peut même pas filtrer efficacement. La donnée est mélangeante (typage objet au lieu de booléen).
Causes : Il y a incohérence dans le remplissage : possiblement, certains observatoires locaux ont noté des choses (ex: un champ booléen 0/1 pour pollution) alors que le standard attend “Oui/Non” ou “pollution avérée/pas de pollution”. L’intégration a dû laisser tel quel, créant ce mélange. De plus, beaucoup de sites n’ont pas l’info – BASIAS répertorie des sites potentiellement pollués mais sans confirmation, et BASOL seulement une poignée de sites.
Recommandations : Uniformiser et remplir a minima ce champ. On pourrait considérer que tous les sites avec un identifiant BASOL ont “Oui” (pollution connue) cnig.gouv.fr, et ceux issus de BASIAS mais pas de BASOL ont “Non renseigné” ou “Suspectée”. Pour l’instant, convertir toutes les valeurs numériques en “Oui/Non” cohérents (ex: 1 => Oui) et supprimer les doublons de signification (peut-être n’utiliser que “pollution avérée” vs vide). Il faudrait idéalement marquer explicitement “Non” pour absence de pollution connue sur les sites dont on a la certitude (mais c’est délicat, on préfère “Non renseigné” par prudence).
Nettoyage prioritaire : élevé, car c’est un champ crucial environnemental. Une approche pragmatique : créer un champ dérivé binaire “pollue” = True si site_basol ou mention pollution ailleurs, False sinon, en attendant mieux.

sol_pollution_origine (origine de la pollution)¶

Très majoritairement vide (devrait suivre le même taux que sol_pollution_existe). À part les sites BASOL, peu ont une origine définie (exemples d’origines : “produits toxiques”, “activité métallurgique”, etc.). L’audit a montré 0,13% de non-null, ce qui correspond peut-être aux quelques sites pollués.
Problèmes : Champ vide pour 99,87% des cas, donc inutilisable à grande échelle.
Causes : Non applicable à la plupart (car pollutions pas avérées). Pour les sites pollués, l’origine existe dans BASOL, mais n’a sans doute pas été importée.
Recommandations : Compléter pour les sites BASOL – par exemple en indiquant “Hydrocarbures”, “Métaux lourds” ou ce qui correspond, selon ce que BASOL décrit. Vu le faible nombre, c’est faisable manuellement ou via un script ciblé. Sinon, ce champ peut être laissé vide par défaut. Documentation : préciser que c’est rempli uniquement en cas de pollution avérée, ce qui explique les nombreuses valeurs manquantes. Ce n’est pas prioritaire pour l’analyse globale, mais crucial pour les sites spécifiques concernés (on peut donc traiter au cas par cas).

bati_pollution (pollution dans les bâtiments)¶

Très majoritairement vide. Ce champ indique par ex. présence d’amiante ou plomb. On a aperçu “inconnu” comme valeur pour les rares remplis (dans l’exemple standard, bati_pollution = “inconnu”). Donc aucune friche n’a explicitement “amiante” ou autre de noté.
Problèmes : On ne sait pas si des polluants spécifiques au bâti (amiante, etc.) sont présents, ce qui est pourtant un enjeu pour la requalification.
Causes : Ces données ne sont pas dans les sources initiales, elles nécessitent des diagnostics techniques. Le champ est resté vide ou marqué inconnu par défaut.
Recommandations : Pas de solution miracle sans audits techniques. On peut éventuellement utiliser des données de permis de démolir (qui impliquent recherche d’amiante) pour inférer quels sites en contiennent, mais c’est du détour. Donc, documenter que ce champ est vide car non renseigné dans l’inventaire actuel, et le remplir éventuellement quand des informations locales remontent (ex: signalement d’amiante dans tel bâtiment). Pour l’instant, il est prudent de considérer que toutes les friches bâties d’avant 1997 sont potentiellement concernées par l’amiante – ce champ ne reflète juste pas cette potentialité, faute de vérification.

sol_pollution_commentaire (commentaire sur la pollution)¶

Là encore, seulement pertinent pour les sites pollués. Presque personne n’a de valeur (on attend <0,5%). Peut contenir un texte décrivant la pollution.
Causes & problèmes : Idem au champ précédent – très peu rempli car très peu de sites avec pollution détaillée. Les rares infos pourraient être longues ou hétérogènes. Recommandation : Pas de nettoyage massif nécessaire vu la rareté. Simplement, s’assurer que pour chaque site pollué on retrouve bien un commentaire (s’il existait dans BASOL). Sinon, pas de mesure spécifique, on accepte que ce champ soit vide presque partout. Sol_depollution_fiche (URL vers une fiche de dépollution) : Quasiment vide – une seule occurrence repérée (fiches-risques.brgm.fr/… pour 1 site). Cela signifie qu’à part un site qui a un lien (probablement vers une fiche de suivi de dépollution sur Géorisques), aucun autre n’a été renseigné.
Problèmes : C’est une occasion manquée de lier des ressources existantes (par ex. de nombreux sites BASOL ont des rapports ou arrêtés disponibles en ligne).
Causes : L’effort d’agrégation de liens externes n’a pas été poussé – on a mis le minimum (liens génériques ou rien). Le cas présent doit être un test ou un site d’étude.
Recommandations : Envisager de peupler ce champ via des sources ouvertes. Par ex, Géorisques propose pour chaque site pollué une page – intégrer ces URL pour tous les sites BASOL serait utile. De même, s’il existe des fiches de suivi de l’ADEME ou d’autres organismes sur certaines friches, les ajouter. C’est un travail manuel/veille, donc peut-être en mode collaboratif avec les référents locaux. Pour l’instant, comme seule une fiche est fournie, mentionner que ce champ est expérimental. Si aucune montée en qualité n’est prévue à court terme, on pourrait fusionner l’info dans site_url pour éviter de multiplier les champs URL.

site_securite (mesures de sécurisation du site)¶

100% manquant. Aucune indication sur la sécurisation (clôture, gardiennage, dépollution temporaire…) n’est présente, alors que ce champ pouvait accueillir plusieurs mesures.
Problèmes : On ignore complètement l’état de mise en sécurité des sites, ce qui est pourtant important (certains peuvent présenter des dangers).
Causes : Ces informations existaient partiellement dans BASOL ou InfoSols, mais leur intégration a été omise ou reportée. Le standard CNIG mentionne que les valeurs issues de BASOL/InfoSols devaient être converties dans ce champ avec des règles de correspondance cnig.gouv.fr , ce qui ne semble pas avoir été fait – possiblement par manque de temps ou de données au bon format.
Recommandations : Intégrer les données de sécurisation disponibles pour les sites BASOL au minimum (ex: “site clôturé et gardienné” etc., convertis selon les règles CNIG cnig.gouv.fr ). Pour les autres friches, envisager de capter cette info via les porteurs de projet ou inspections (même si c’est juste “pas de mesure” ou “inconnu”). Si l’intégration automatique est complexe, ce champ pourrait être mis à jour progressivement lors des visites de terrain ou retours des collectivités. Documenter pour l’utilisateur final que l’absence totale de données ne signifie pas forcément absence de sécurisation, mais un défaut d’information. Liens avec bases de données environnementales

sol_pollution_statut¶

bati_pollution¶

🏭 Données sur le bâti¶

(Les champs bati_ décrivent les bâtiments présents sur le site, issus pour la plupart de croisements avec les fichiers fonciers ou d’enquêtes terrain.)

Problèmes de qualité : Les données sur le bâti présentent de nombreuses valeurs manquantes ou indéterminées. Une proportion importante de sites n’a pas d’information sur les bâtiments présents : par exemple, le nombre de bâtiments (bati_nombre) ou la surface bâtie (bati_surface) est souvent nul ou non renseigné, et les champs décrivant la nature ou l’état du bâti contiennent fréquemment la valeur « inconnu » ou restent vides. On observe aussi des incohérences et outliers potentiels : certains enregistrements indiquent la présence de bâtiments sans en préciser les caractéristiques (types, surface, etc.), tandis que d’autres peuvent montrer des valeurs extrêmes (une friche affichant un nombre de bâtiments ou une superficie bâtie très élevée par rapport à la moyenne). Par ailleurs, la plupart des catégories qualitatives (pollution du bâti, vacance, valeur patrimoniale, état de dégradation) sont dominées par l’option « aucun/inconnu » – signe que soit les informations détaillées n’ont pas été collectées, soit que les friches n’ont pas de particularités notables sur ces aspects, ce qui limite la portée informative de ces variables.

Interprétation : Ces lacunes reflètent le fait que l’inventaire n’a pas encore intégré toutes les données sur les constructions existantes ou que celles-ci ne sont pas uniformément renseignées selon les sources. Pour l’analyste, cela signifie qu’il faudra interpréter prudemment les indicateurs liés au bâti. Par exemple, un grand nombre de « 0 » en surface bâtie ne signifie pas nécessairement l’absence totale de constructions – cela peut indiquer un manque de mesure ou une absence de mise à jour (certaines friches pourraient comporter de petits bâtiments non recensés). De même, la prépondérance de réponses « inconnu » ou « aucun » pour la pollution, la vacance ou le patrimoine bâti suggère que peu de sites ont fait l’objet d’une évaluation fine sur ces critères, rendant difficile toute conclusion générale (on ne peut pas facilement distinguer si la plupart des friches sont sans pollution/aspect patrimonial, ou si simplement on manque d’information). Enfin, les outliers identifiés (ex : friche avec surface bâtie exceptionnellement grande) indiquent une hétérogénéité marquée de la base : quelques sites aux caractéristiques extrêmes peuvent influencer les statistiques globales, d’où la nécessité de les traiter à part lors de l’analyse (voire de vérifier s’il ne s’agit pas d’erreurs de saisie).

Coefficient de corrélation (Pearson) entre Surface foncière et Proportion bâtie: -0.38

Analyse État de dégradation vs Ancienneté des constructions:
Les colonnes 'Local_ancienne_annee', 'Local_recent_annee' et 'bati_etat_degradation' sont largement vides ou non fiables d'après l'audit.
Cette analyse ne peut pas être réalisée avec les données actuelles.

bati_type (type de bâtiments présents)¶

83,9% de valeurs manquantes. Environ 16% des sites ont un type de bâti indiqué. La valeur la plus courante renseignée est « Habitat » (1548 occurrences), suggérant que sur ces sites on trouve principalement des bâtiments d’habitation. D’autres types possibles sont industriel, agricole, tertiaire, etc., mais ils sont très peu nombreux dans les données (le mode “Habitat” domine largement parmi les rares remplissages).
Problèmes : Pour la grande majorité des friches, on ne sait pas quel genre de bâtiment s’y trouve (s’il y en a). Les quelques données présentes sont biaisées – “Habitat” apparaît souvent, possiblement parce qu’un lot de friches urbaines a été traité, tandis que d’autres types n’ont pas été notés.
Causes : Ces informations proviennent sans doute d’un croisement avec la matrice cadastrale ou d’une saisie manuelle, ce qui n’a été fait que ponctuellement. Le standard CNIG autorise des valeurs multiples (plusieurs types séparés par |) cnig.gouv.fr , mais on ne voit pas de tels cas, signe d’un usage minimal.
Recommandations : Améliorer la remontée des données bâties. Puisque le standard suggérait d’utiliser la Base des Données des Bâtiments (à venir) ou les fichiers fonciers, il faut soit attendre ces sources consolidées, soit connecter dès maintenant aux fichiers fonciers (DV3F) pour connaître la nature des constructions. En attendant, les données existantes peuvent être homogénéisées (ex: vérifier s’il y a des libellés différents pour signifier la même chose).
Priorité : moyenne – ce n’est pas critique pour l’analyse macro, mais important localement. On pourrait cibler les friches prioritaires et renseigner si elles ont des bâtiments industriels, patrimoniaux, etc. Encourageons une saisie structurée plutôt que du texte libre.

bati_nombre (nombre de bâtiments)¶

Valeurs manquantes non explicitement listées, mais on peut déduire qu’une forte proportion est vide également (sans doute >80%). Les sites qui ont une info peuvent en avoir 1, 2, etc. On n’a pas la distribution précise ici, mais probablement très peu ont un nombre indiqué.
Problèmes : Champ sous-exploité – on ne connaît pas l’ampleur du bâti sur la plupart des friches. Certains ont peut-être “0” s’il n’y a pas de bâtiment (mais pas clair si c’est noté ou laissé vide).
Causes : Difficulté de recensement sans données cadastrales automatisées. Ce champ aurait pu être alimenté via le croisement bâti-cadastre (en comptant les polygones bâtis intersectant la friche). Cela n’a pas été généralisé.
Recommandations : Utiliser des sources externes comme la couche bâti d’OpenStreetMap ou la BD Topo pour estimer le nombre de bâtiments sur site, au moins approximativement pour les grandes friches. Sinon, collecter manuellement lors de visites ou retours terrain. Dans l’immédiat, uniformiser la saisie : si “0” n’a pas été noté pour absence de bâtiment, décider de le faire ou non. Ne pas laisser de “0” ambigus (0 bâtiment ou info manquante?). Mieux vaut un null pour inconnu et un 0 explicite si vérifié aucun bâtiment.

bati_surface (surface de plancher totale)¶

Similaire, très peu renseigné (on voit que dans l’exemple du standard, une friche avait 2400 m² de plancher, mais dans notre export on ne repère pas de mode significative). La plupart des sites n’ont pas cette donnée.
Problèmes : On ne peut pas estimer la volumétrie du bâti existant, utile pourtant pour évaluer le potentiel de réhabilitation.
Causes : Là encore, seule une extraction des données foncières (valeur locative et surface bâtie) ou des bases bâtiments pourrait fournir cette info. Non fait à ce stade hormis tests.
Recommandations : Prévoir de calculer ou importer ces surfaces quand la BD des bâtiments (BDNB) sera disponible. On peut aussi obtenir des approximations en multipliant l’emprise au sol par nombre d’étages, mais c’est un travail lourd manuellement. Court terme : laisser vide plutôt que mettre des mauvaises valeurs.

bati_vacance (état de vacance des bâtiments)¶

Devrait indiquer si les bâtiments sont inoccupés. Peu de données présentes. Peut-être quelques “vacant” ou “occupé partiellement” isolés. Probablement >90% manquant.
Problèmes : On ne sait pas si sur une friche certains bâtiments servent encore (stockage, etc.).
Causes : Là encore, il faut du travail de terrain ou des croisements (par ex. croiser avec la taxe foncière bâtie – si non imposé = vacant). Non fait sauf exceptions.
Recommandations : Laisser ce champ vide tant qu’on n’a pas de données fiables, plutôt que mettre “inconnu” partout. Sur les sites où on sait des choses (via les collectivités), on peut indiquer “occupé temporairement”, etc. Mais globalement, c’est un champ à remplir manuellement au cas par cas. Au niveau national, on peut estimer qu’il y a quasi 100% de vacance sur friche, mais ce serait imprécis. Donc champ peu utilisable actuellement. On peut suggérer comme amélioration d’analyser des images satellites nocturnes pour repérer l’absence d’éclairage comme indice de vacance, mais c’est prospectif.

bati_patrimoine (présence de bâti patrimonial)¶

Là aussi, très peu renseigné. Quelques friches peuvent avoir “monument inscrit” ou “présence d’un élément patrimonial” noté, mais c’est marginal.
Problèmes : On ne bénéficie pas de l’indication qu’un bâtiment sur site a une valeur historique ou architecturale, ce qui pourrait orienter les projets (conservation ou pas).
Causes : Cette info demande de croiser avec la liste des monuments historiques ou le PLU (certains bâtiments sont protégés). Non fait sauf si mentionné par un observatoire local.
Recommandations : Croiser avec la base Mérimée (Monuments protégés) ou le patrimoine industriel inventorié, afin de taguer les friches concernées. C’est un ajout précieux pour prioriser certains sites, mais il y a du bruit possible (bâtiment protégé adjacent, etc.). Au minimum, inciter les acteurs locaux à renseigner ce champ quand ils connaissent un édifice remarquable sur le site. Pour l’instant, supposer par défaut “non renseigné = pas d’info, nécessite enquête”.

bati_etat (état de dégradation des bâtiments)¶

Non présent dans l’audit (peut-être pas exporté ou confondu). On peut supposer qu’il n’est pas rempli non plus, sauf exceptions ponctuelles (“état de dégradation moyenne”, “très dégradé”, etc., comme dans l’exemple standard).
Problèmes : On n’a pas d’évaluation générale de l’état du bâti (neuf, réhabilitable, ruine…).
Causes : Donnée qualitative nécessitant une visite sur site. Les quelques valeurs peuvent provenir d’inventaires régionaux où l’état avait été noté.
Recommandations : Encourager la notation de l’état lors des relevés terrain (par ex. via une échelle standard : bon/moyen/mauvais/ruine). À l’échelle nationale, ce champ restera très lacunaire tant qu’une campagne d’évaluation visuelle n’est pas menée. Donc le considérer comme non prioritaire pour le moment. En sortie publique, on pourrait même le masquer pour éviter l’impression de données à moitié vides. (À noter : Le CNIG avait prévu de mettre à jour ces champs via des bases nationales dès que possible, ce qui explique qu’ils soient pour l’instant majoritairement vides. En d’autres termes, l’absence de données bati_ actuellement est un manque connu et temporaire.) Propriété foncière

unite_fonciere_surface¶

count    2.805200e+04
mean     1.120489e+05
std      1.188390e+06
min      1.000000e+00
25%      1.554750e+03
50%      7.521000e+03
75%      3.661200e+04
max      1.340958e+08
Name: unite_fonciere_surface, dtype: float64

Unite fonciere surface fait partie des données les plus fournies du dataset

📌 Année médiane pondérée par la surface foncière : 2022.0

unite_fonciere_refcad¶

👤 Activité et Propriétaires¶

Problèmes de qualité : La section propriétaires souffre de données incomplètes et d’un format peu structuré. De nombreux sites n’ont pas d’information propriétaire exploitable : soit les champs sont vides, soit les noms sont masqués (par exemple pour les propriétaires privés, en raison de la confidentialité). Les types de propriétaires sont codés (ex. catégories alphanumériques) et parfois multiples pour un même site – listés via un séparateur | – ce qui complique l’analyse directe (il faut les décoder et éventuellement compter le nombre de propriétaires). On constate également une sur-représentation potentielle d’une catégorie : par exemple, une majorité d’entrées indiquent des personnes morales comme propriétaires (entreprises, collectivités) par rapport aux personnes physiques, ou bien une forte proportion de sites sans propriétaire identifié clairement. Ces caractéristiques rendent la comparaison difficile et peuvent biaiser les indicateurs globaux. Interprétation : L’absence ou l’opacité de certaines informations propriétaires limite la compréhension de la situation foncière des friches. Des champs non renseignés signifient que l’origine de propriété n’a pas été collectée ou ne peut être diffusée, ce qui pose un enjeu d’analyse pour estimer la part de foncier public/privé mobilisable. La nécessité de décoder des listes de propriétaires indique un besoin de préparation des données avant toute exploitation (par exemple, compter le nombre de propriétaires uniques par site, distinguer privé vs public). La dominance d’un type de propriétaire (si confirmée, par ex. majorité de propriétaires privés) pourrait orienter les stratégies de requalification différemment que si les sites étaient majoritairement publics : en analyse, cela signifie qu’il faudra évaluer si ce biais reflète la réalité (beaucoup de friches privées) ou un biais de collecte (friches publiques mieux recensées). Enfin, la présence de sites à propriétaires multiples signale des cas complexes qui pourraient nécessiter un traitement à part ou une attention spécifique (ces cas pouvant ralentir les projets de réhabilitation).

⚠️vérifier code naf

proprio_type (type de propriétaire selon fichier foncier)¶

Ce champ contient un code ou intitulé de catégorie du propriétaire (ex: niveau 3 de la classification Personne Morale). Il est peuplé pour une partie des sites, mais pas tous – on n’a pas le % exact, possiblement autour de 45-50% (car lié aux données foncières disponibles). L’audit montre une valeur fréquente « X » (10 389 occurrences) qui ne correspond à aucune catégorie valide – cela semble être un artéfact (peut-être un code signifiant “donnée indisponible” ou un reliquat de format).
Problèmes : Les informations de type de propriétaire sont incomplètes et partiellement illisibles. On pourrait s’attendre à des valeurs comme “État”, “Collectivité”, “Entreprise privée”, etc., mais à la place on voit un code « X1a » ou « X » apparaître dans les données les plus fréquentes, ce qui n’est pas compréhensible tel quel.
Causes : L’info propriétaire provient du cadastre (MAJIC). Il semble que pour les personnes physiques, par respect RGPD, le type n’ait pas été renseigné (ou codé “X” pour inconnu/manuel). Le code X1a pourrait correspondre à une catégorie agrégée (par ex. “propriétaire privé inconnu”).
Recommandations : Clarifier le contenu de ce champ. Vérifier dans la documentation du Cerema ce que signifient les codes X1a, X, etc. Il faudra sans doute recoder ces valeurs en termes intelligibles ou les éliminer si ce sont des erreurs. Ensuite, compléter autant que possible les catégories manquantes : par exemple, si proprio_personne dit “personne morale” et qu’on a le nom d’une commune, on peut déduire type = “Collectivité locale”. On pourrait aussi utiliser le SIREN du propriétaire moral (s’il était disponible en coulisse) pour enrichir la catégorie via la base SIRENE (secteur public, privé, etc.). Priorité : moyenne – ce champ aide à savoir qui possède les friches (public/privé), ce qui est crucial pour orienter les politiques de requalification. Donc, il mérite un nettoyage pour isoler au moins “Privé” vs “Public”, “État”, etc., même grossièrement.

proprio_nom (nom du propriétaire actuel)¶

Ce champ devrait contenir le nom de l’entité propriétaire si c’est une personne morale (entreprise, collectivité…), et rester vide s’il s’agit d’une personne physique (pour respecter la réglementation). Dans la base, on constate une valeur récurrente aberrante : « lou dupont » avec 12 906 occurrences, ce qui semble être un artefact (peut-être une donnée test ou un anonymisation mal gérée). À part cela, beaucoup de valeurs sont sans doute vides (car personnes physiques anonymisées) ou contiennent des noms d’entreprises/organismes pour environ 45% des sites.
Problèmes : La présence de “lou dupont” est un bug manifeste – aucun individu ou société ne peut posséder 12 906 friches ! C’est vraisemblablement un placeholder erroné inséré lors d’un traitement. De plus, toutes les friches possédées par des particuliers n’ont logiquement pas de nom affiché (d’où absence ou valeur neutre).
Causes : Le standard CNIG stipule bien que ce champ n’est rempli que pour les personnes morales, conformément au RGPD. On peut imaginer que “lou dupont” était soit un exemple dans des données de test, soit une chaîne utilisée temporairement pour anonymiser et qui est restée. Les autres entrées devraient être des sociétés (par ex. “SNCF” si c’est un propriétaire) ou des collectivités (“Commune de X”).
Recommandations : Supprimer la valeur “lou dupont” de toutes les fiches – c’est une erreur sans signification, elle peut être remplacée par null. Ensuite, contrôler qu’aucun nom de personne physique n’apparaît (normalement non, à part cette anomalie). Pour les noms de personnes morales, vérifier la cohérence : par exemple, uniformiser “Commune de Truc” et “Mairie de Truc” en une seule forme. On peut aussi associer un identifiant SIREN en coulisses pour fiabiliser l’entité (non demandé ici mais en réflexion). Documentation : préciser que les propriétaires privés ne sont pas nommés dans la donnée pour des raisons légales (d’où de nombreux vides). Mettre en avant qu’environ 45% des friches sont détenues par un propriétaire identifié de type entreprise ou collectivité (d’après le champ proprio_personne ci-après), et donner éventuellement quelques exemples notables (ex: l’État via EPF possède X sites).

proprio_personne (indique si propriétaire physique ou moral)¶

Champ plutôt bien rempli (valeur “Personne morale” dans ≈16 614 cas, et on peut déduire 11 500 “Personne physique” par différence, puisque toutes friches ont un propriétaire). Il reste possiblement quelques “inconnu” si les données étaient ambiguës, mais a priori ça devrait être binaire. Qualité : Bonne, ce champ permet de distinguer plus de la moitié des sites comme appartenant à des personnes morales (entreprises, collectivités…).
Problèmes : Pas de problème majeur de remplissage, sinon s’assurer qu’il n’y a pas de confusion (ex: indivision, multiples propriétaires – dans ces cas, peut-être que c’est noté comme “plusieurs (morale/physique)” ou juste “morale” si au moins un moral?).
Causes : Donnée issue du fichier foncier également, elle semble avoir bien été intégrée car c’est une info binaire facile.
Recommandations : Conserver ce champ tel quel en le fiabilisant un peu plus : vérifier qu’aucun n’est “inconnu” (normalement non). Si une friche a plusieurs propriétaires mixtes, éventuellement adapter (le standard prévoyait la possibilité de valeurs multiples en séparant par |, mais ce cas est rare). Usage : C’est un champ analytique important (permet de dire X% des friches sont possédées par des privés). Donc veiller à sa mise à jour si la propriété change (ex: si un propriétaire privé vend à une commune, changer en “Personne morale”). (RGPD : On rappelle que conformément aux directives, aucune donnée nominative sur les propriétaires physiques n’est publiée – ce qui est respecté ici, hormis l’anomalie “lou dupont” à corriger.)

activite_libelle (libellé de l’ancienne activité)¶

47% de valeurs manquantes. Seules ⚠️revérifier 14% des friches ont un libellé textuel de l’ancienne activité exercée. La valeur la plus courante est « Dépôt de liquides inflammables (D.L.I.) » avec 1821 occurrences, ce qui montre que de nombreux sites avaient ce type d’activité (souvent associé à l’armée ou aux hydrocarbures).
Problèmes : La majorité des sites n’ont pas de description d’usage passé en clair, rendant la compréhension moins aisée (il faut se rabattre sur le code NAF éventuellement). De plus, le fait qu’un seul libellé compte pour près de la moitié des valeurs renseignées suggère une sur-représentation d’une catégorie (peut-être parce que certains contributeurs n’ont rempli que ce champ dans certains cas particuliers).
Causes : BASIAS fournit un code d’activité NAF ou une catégorie, mais pas toujours un libellé exploitable – ou alors le libellé est parfois absent dans l’export. Ici, il semble que la correspondance code->libellé n’a été faite que pour certaines catégories fréquentes (ex: DLI). Il est aussi possible que activite_libelle n’ait été rempli que par certaines sources locales.
Recommandations : Enrichir les libellés à partir des codes. Puisque activite_code est presque toujours renseigné, on peut utiliser la nomenclature officielle (NAF rév.2) pour traduire chaque code en libellé clair cnig.gouv.fr . Cela comblerait la plupart des 85% manquants (au moins en fournissant un texte standard). Vérifier toutefois si les codes utilisés sont bien des codes NAF ou une autre classification propre à BASIAS. Dans le cas de DLI (Dépôt de liquides inflammables), ce sigle est spécifique – garder la cohérence tout en l’expliquant. Priorité de nettoyage : assez élevée pour l’analyse des filières industrielles des friches – un libellé parlant est plus accessible qu’un code.

activite_code (code de l’ancienne activité)¶

99,5% des sites manquants. Cela indique que quasiment chaque friche a un code d’activité non renseigné, typiquement un code NAF/APE sur 4 ou 5 caractères (par ex. 4520A qui apparaît 7 fois en mode – ce code correspond à “Entretien et réparation de véhicules automobiles” dans la NAF). Causes : BASIAS attachait un code d’activité économique à chaque site inventorié. Ces codes ont été repris tels quels. Les très rares présents peuvent correspondre à des sites ajoutés manuellement sans code, ou à des friches non industrielles où un code standard manquait.
Recommandations : Vérifier l’uniformité des codes – s’il y a un mélange de nomenclatures (NAF 2008 vs NAF 2003), envisager de tout convertir vers la version actuelle pour simplifier l’analyse. Par exemple, le code 4520A cité est NAF 2008. Si des codes à lettre en fin manquent (NAF 2003), les mettre à jour. On devrait aussi supprimer d’éventuels codes aberrants (ex: “?” ou “N/D” s’ils existent). Comme mentionné, utilisez ces codes pour générer ou compléter activite_libelle plutôt que laisser l’utilisateur chercher la correspondance.

🔗 Sources de données et production¶

Problèmes de qualité : Les métadonnées de source indiquent que chaque site provient d’une base identifiée, mais on relève une hétérogénéité et des champs souvent incomplets. Le champ principal source_nom est toujours renseigné (nom court de la source de l’information), toutefois les informations complémentaires comme l’URL de la source, le nom du producteur ou le contact email sont souvent manquantes ou inégales selon les enregistrements. Par ailleurs, le nombre de sources différentes est élevé, avec potentiellement une dominance de quelques sources majeures : par exemple, un inventaire national peut regrouper la majorité des friches, tandis que d’autres sources locales n’en fournissent que quelques-unes. Cela crée un déséquilibre où certaines origines de données sont sur-représentées par rapport à d’autres. Enfin, on peut noter un manque de normalisation dans les noms de sources (certaines abréviations régionales, sigles peu explicites), rendant le suivi moins aisé. Interprétation : La variété des sources illustre la richesse de la collecte collaborative, mais complique l’agrégation des données. L’absence fréquente de détails comme source_url ou source_contact signifie qu’il est difficile de remonter à la source initiale pour obtenir des précisions ou des mises à jour, ce qui peut être problématique en cas de données obsolètes ou douteuses sur un site particulier. La forte contribution de quelques organismes (si confirmée) implique que l’état de la base reflète surtout la qualité de ces gros pourvoyeurs : par exemple, si la majorité des fiches proviennent d’une base nationale qui ne renseigne pas tel champ (comme le propriétaire ou le bâti), alors globalement ces informations apparaîtront manquantes pour la majorité des friches. Cela crée un biais de complétude lié à la source. De plus, sans normalisation, il est possible que des sources identiques soient nommées légèrement différemment, rendant l’analyse quantitative par source moins fiable sans un pré-traitement (regroupement des libellés équivalents).

source_nom* (nom de la source d’identification)¶

C’est l’origine de la fiche (par ex. BASIAS, Inventaire Région X, appel à projet Y, etc.). Ce champ est assez bien rempli (peu de NaN). On s’attend à des valeurs comme “BASIAS” majoritaire, “BASOL”, “Grand Est observatoire friches”, “Appel à projets ADEME 2021”, etc.
Problèmes : Potentielle hétérogénéité de libellés – par exemple, “Basias” vs “BASIAS 2019” vs “Base BASIAS MTES”. De plus, de nombreuses friches (12k) ont pour source_producteur la valeur “Fonds Friches” ou autre (vu plus bas), ce qui peut recouper ce champ.
Causes : Les sources ont été renseignées via un champ texte potentiellement peu contraint, ou consolidé manuellement.
Recommandations : Standardiser les noms de sources. Par exemple, utiliser strictement “BASIAS” pour toutes celles issues de cette base, plutôt que des variantes. Idem “Inventaire local – Région Occitanie” plutôt que multiples libellés. Une liste de sources officielles devrait être définie et appliquée. Cela permettra de grouper les sites par source facilement.
Nettoyage : repérer les libellés proches et les fusionner (via mapping). Documentation : lister les différentes sources ayant alimenté Cartofriches, leur périmètre et date. Cela aide à comprendre les éventuels biais (par ex. certaines régions très actives ont plus de friches car elles ont une source dédiée).

⚠️ essayer de chercher les données ici pour la pollution des sols: https://www.georisques.gouv.fr/consulter-les-dossiers-thematiques/dossier-expert-sur-les-sites-et-sols-potentiellement-pollues

source_producteur (producteur de la donnée)¶

Devrait indiquer qui a fourni la donnée de la friche (ex: CEREMA, Région, EPF…). Dans la réalité, un grand nombre ont une valeur comme “Appel à projet Fonds Friches”, “CEREMA” ou autre. Cependant, on observe encore ici la valeur aberrante “lou dupont” (12 906 fois), ce qui suggère le même bug que pour proprio_nom. Il est possible que ce champ ait été confondu avec un contact ou mal peuplé pour BASIAS/BASOL.
Problèmes : La moitié des sites environ ont un producteur mal identifié (“lou dupont” n’est clairement pas un producteur valide). Pour les autres, il peut y avoir confusion entre source et producteur (ex: “Basias” comme source_nom et aussi producteur?).
Causes : Lou Dupont semble s’être glissé ici aussi – possiblement comme nom de personne référente d’un producteur (par ex. une collectivité) et qui aurait dû être dans source_contact uniquement. Le champ a donc hérité d’une donnée inappropriée. En dehors de ça, le producteur devrait être un organisme, mais il a pu être laissé vide pour les sources nationales (où le producteur logique est l’État/Cerema).
Recommandations : Nettoyer en priorité “lou dupont” ici aussi – le remplacer par null ou par l’entité correspondante (Grand Angoulême, puisque l’email associe ce nom à GrandAngoulême – mais mieux vaut supprimer le nom personnel). Ensuite, uniformiser les noms d’organisations : par ex., ne pas avoir “EPF d’Occitanie” et “Établissement Public Foncier Occitanie” séparément. Clarifier qui est producteur : probablement le porteur de l’inventaire (région, DDT, etc. – voir exemples standard). Lien avec source_nom : souvent, source_nom = base de données, source_producteur = qui gère la base. Ex: source_nom = BASIAS, source_producteur = Ministère Transition écologique / BRGM. Il faut vérifier si c’est le cas et le rendre cohérent. Documentation : fournir la liste des producteurs avec peut-être leur acronyme pour éviter de stocker un nom de personne comme cela est arrivé.

Producteur: ADUGA
['ADUGA (Grand Amiénois)']

Producteur: AUDRR
["Agence d'Urbanisme de Développement et prospective de la Région Rémoise"]

Producteur: Ademe
['Friche étude Ademe 2021, intéressante pour du PV au sol']

Producteur: Appel à projet Fonds Friches
['Appel à projet Fonds Friches']

Producteur: CC Val de Gray
['Communauté de Communes du Val de Gray']

Producteur: Caux Seine agglo
['Caux Seine agglo']

Producteur: Cerema
['Site Basias ou Basol vérifié par le Cerema en 2020']

Producteur: Cerema AO Ademe
['Cerema AO Ademe']

Producteur: Commune de Fougères
['Commune de Fougères']

Producteur: Contributeur Cerema
['Contributeur Cerema']

Producteur: Contribution utilisateur
['Contribution utilisateur']

Producteur: DDT  Ain
["DDT de l'Ain"]

Producteur: DDT 15
['DDT du Cantal']

Producteur: DDT 42
['DDT de la Loire']

Producteur: DDT 45
['DDT du Loiret']

Producteur: DDT 52
['DDT de la Haute-Marne']

Producteur: DDT 80
['DDT de la Somme']

Producteur: DDT des Ardennes
['DDT des Ardennes']

Producteur: EPF Grand Est
['EPF Grand Est']

Producteur: EPF Normandie
['EPF Normandie']

Producteur: Friche étude Ademe 2021
['Friche étude Ademe 2021']

Producteur: Grand  Angoulême
['Grand Angoulême']

Producteur: IPR
['Institut Paris Région']

Producteur: Région Occitanie
['Région Occitanie']

Producteur: Sud Foncier Eco
['Sud Foncier Eco']

Producteur: Ville d'Ajaccio
["Ville d'Ajaccio"]

Producteur: lou dupont
['Site Basias ou Basol non vérifié par le Cerema']

Producteur: urbanvitaliz
['urban vitaliz']

source_url (URL de la source d’information)¶

Ce champ est rempli à 76% (23,6% NaN). La valeur modale est le lien data.gouv.fr de BASIAS (13751 occurrences). D’autres sources auront d’autres liens (ex: un lien vers la page régionale d’un inventaire).
Problèmes : Comme déjà discuté dans site_url, beaucoup partagent le même lien, ce qui n’est pas très informatif par fiche. De plus, 24% n’en ont pas – sans doute les fiches manuelles ou locales sans URL dédiée.
Causes : Lié à source_nom, on a mis ici le lien vers la ressource source (open data ou site web du producteur). Les manquants correspondent aux cas où soit l’URL n’existe pas, soit a été oubliée.
Recommandations : Conserver ce champ car il est utile pour la traçabilité (il renvoie vers le jeu de données original ou le site de l’observatoire). Tenter de remplir les 24% manquants en recherchant s’il existe une page web pour ces sources. Ex: si source_nom = “Inventaire friches Nouvelle-Aquitaine”, mettre le lien vers la page dédiée s’il y en a une. S’assurer aussi de la pérennité des URL (utiliser de préférence des URL stables ou archivées). Pour les sources multiples (ex un site combinant Basias + compléments locaux), on pourrait mettre plusieurs liens séparés par | mais c’est rarement fait.
Nettoyage : il s’agit plus de complétion que de nettoyage – peu de faux dans les liens hormis peut-être des http->https à uniformiser.

source_url
https://www.data.gouv.fr/fr/datasets/inventaire-des-sites-pollues/                                                                        13751
https://www.economie.gouv.fr/plan-de-relance/profils/collectivites/fonds-pour-le-recyclage-des-friches                                     2998
https://grandangouleme-lacharente.opendata.arcgis.com                                                                                      2185
https://www.data.gouv.fr/fr/datasets/observatoire-des-friches-en-lorraine/                                                                 1460
https://www.ecologie.gouv.fr/solaire#scroll-nav__7                                                                                          698
https://www.laregion.fr/friches-occitanie                                                                                                   109
https://carto.aduga.org/index.php/view/map/?repository=observatoire&project=friche_grd_amienois_383                                         102
www.ardennes.gouv.fr/observatoire-des-friches-a2126.html                                                                                     76
https://sudfonciereco.maregionsud.fr/                                                                                                        55
https://www.haute-marne.gouv.fr/index.php/Actions-de-l-Etat/Amenagement-du-territoire-urbanisme/Observatoire-departemental-des-friches       29
https://ajaccio.corsica/                                                                                                                     11
https://www.cauxseine.fr/                                                                                                                     1
Name: count, dtype: int64

source_url : 76.4% de valeurs renseignées
site_url : 60.4% de valeurs renseignées

source_contact (contact email de la source)¶

91,7% de valeurs manquantes. Seulement 2 185 sites ont un contact renseigné, dont le plus fréquent est “infoterritoriale@grandangouleme.fr” (apparu 2 185 fois justement). Cela signifie qu’à part le Grand Angoulême qui a mis un contact identique pour ses fiches, quasiment aucune autre source n’a fourni de contact.
Problèmes : Ce champ est vide dans l’écrasante majorité des cas, ce qui réduit la possibilité pour un utilisateur de savoir qui joindre pour en savoir plus sur une friche donnée.
Causes : Les données nationales (BASIAS/BASOL) n’ont pas de contact spécifique par site, et pour les données régionales, beaucoup n’ont pas saisi d’email de référent. Seul GrandAngoulême visiblement a mis une adresse générique. Il est aussi possible que certaines adresses aient été supprimées par prudence (RGPD, éviter de publier des emails personnels).
Recommandations : Recueillir des contacts institutionnels pour les principales sources de données – par exemple, un email générique par région ou par organisme (DDT, EPF) responsable de la friche. Plutôt que remplir par site, on pourrait remplir par source : toutes les friches d’une même source_producteur pourraient avoir le même contact générique. Actuellement c’est ce qu’a fait GrandAngoulême, ce qui est bien. Encourager les autres à le faire (ex: “inventaire-friches@occitanie.fr” pour la région Occitanie, etc.). Cela porterait la complétude du champ à un niveau utile, sans exposer de personnes nominatives. Nettoyage : retirer tout nom de personne ou email personnel si par hasard présent (on n’en voit pas dans l’aperçu, c’est plutôt générique). Harmoniser le format (tous en minuscule, etc.). Priorité moyenne, ce champ est “nice to have” pour le suivi local mais moins crucial analytiquement. Données géographiques

site_url (URL vers plus d’information)¶

valeur manquante (40%% NaN). Toutefois, ce lien varie selon la source et n’est pas toujours spécifique au site. Observations : Pour les sites BASIAS, site_url est souvent le même lien générique vers data.gouv.fr (identifié 13 751 fois), pointant probablement vers le jeu de données BASIAS complet. Pour d’autres, le lien renvoie vers une page web locale ou un document PDF précis. Par exemple, un lien récurrent https://www.suippes.fr/9143-2/ apparaît 14 fois, suggérant une source communal répliquée.
Problèmes : La pertinence de l’URL varie – un lien générique sur 13k sites n’apporte pas d’info individuelle. Certains liens peuvent être obsolètes ou peu informatifs.
Causes : Le champ a été alimenté automatiquement en fonction des données sources disponibles. BASIAS ne fournissant pas de fiche web par site, le choix a été de pointer vers la ressource open data correspondante. Pour des friches issues de projets locaux, on a parfois mis un lien vers un article de presse ou le site de la collectivité.
Recommandations : Idéalement, fournir une URL propre à chaque site. Si inexistante, mieux vaut peut-être ne rien mettre plutôt qu’un lien identique partout. Pour BASOL, il existe des fiches GeoRisques détaillant le site pollué – celles-ci devraient être utilisées (ex: un site Basol pourrait avoir le lien fiches-risques.brgm.fr spécifique, comme on voit pour une occurrence). Pour BASIAS, s’il n’y a pas de fiche site, on pourrait mettre le lien vers la fiche communale BASIAS ou vers une page Cartofriches interne décrivant la friche (si l’application web en génère). Vérifier l’accessibilité de chaque URL périodiquement et mettre à jour celles qui sont brisées. Documenter la signification de l’URL (source nationale, locale, etc.) pour l’utilisateur.

site_url_ademe¶

site_url_ademe (URL de fiche ADEME) 100% manquant. Aucune friche n’a de lien vers une fiche ADEME. Analyse : Ce champ était prévu pour les sites passés par un appel à projet ADEME (fonds friches) avec une fiche dédiée, mais visiblement aucune URL n’a été renseignée.
Causes : Il est possible qu’au moment de l’export, aucune friche n’avait encore ce type de ressource disponible, ou que l’information existe (ex. dans site_statut ou source_nom) mais n’a pas été dupliquée ici.
Recommandation : Si ce champ demeure vide, envisager de le supprimer pour simplifier le modèle. Sinon, dès que des sites disposent de pages ADEME, il faudrait les remplir. Par exemple, les lauréats des appels à projets possèdent parfois une fiche sur le site de l’ADEME ou de la préfecture – insérer ces liens le cas échéant. Pour l’instant, communiquer clairement que ce champ est inutilisé.

Conclusion En résumé, chaque colonne présente des défis de qualité distincts – globalement dus à la fusion incomplète de sources hétérogènes et au caractère inachevé de certaines enrichissements automatiques. Il est conseillé de documenter explicitement ces limites champ par champ dans le dictionnaire de données, afin que les analystes sachent interpréter les nombreuses valeurs “inconnu” , les valeurs par défaut (1900, 1 m², etc.) et l’absence de certaines informations clés, en attendant les améliorations futures. Ainsi priorisés, les efforts de nettoyage (noms de colonnes homogènes, suppression des placeholders erronés) et de normalisation (listes de valeurs cohérentes, alignement sur le standard CNIG) rendront les données Cartofriches plus fiables et exploitables pour le suivi de la requalification des friches. Les coordonnées manquantes ou imprécises limitent l’utilité du jeu de données pour des analyses cartographiques et la planification territoriale. Il serait pertinent de géocoder les adresses manquantes ou de compléter ces informations via d’autres sources afin de pouvoir intégrer tous les sites dans les études spatiales. Les anomalies repérées (coordonnées hors zone attendue) devraient être vérifiées et corrigées, car elles peuvent fausser les analyses (par exemple un site affiché à l’étranger par erreur). La détection de doublons géographiques implique d’établir une procédure de regroupement des entrées dupliquées : si deux enregistrements représentent le même site, ils devraient être fusionnés pour éviter une double comptabilisation. Enfin, la forte concentration de friches dans certains secteurs peut indiquer des zones industrielles historiques ou un effort de recensement inégal selon les communes. Il faudra en tenir compte dans l’analyse, par exemple en comparant les contextes locaux ou en normalisant par la taille de la commune ou de la population afin de relativiser ces concentrations.

site_projet_url¶

Ce champ a été laissé complètement vide, mais pourtant pour la traçabilité des projets il aurait été intéréssant de le compléter, le problème est que l'exhaustivité des champs à compléter peut rendre le formulaire rédhibitoire pour la saisies manuelle, c'est un commentaire générale que l'on peut appliquer aux différents référencements

📈 Modélisation pour l’évaluation des critères¶

critère pour le choix des features

Taux de remplissage :

• On conserve en priorité les variables avec peu de valeurs manquantes (<~20% manquants pour les variables majeures, mais on peut tolérer plus si la variable est stratégique).
• On élimine ou encode spécifiquement les variables où >80% des valeurs sont manquantes, sauf exception stratégique.

Pertinence métier / lien avec la cible :

• Garder les variables qui pourraient avoir un lien logique avec le "statut" (friche avérée/potentielle, reconversion, occupation, pollution, etc.).
• Eliminer les identifiants purs, ou les colonnes purement textuelles trop bruitées (ex : commentaires), ou URL inutiles pour la prédiction.
• Doublons, cardinalités et variabilité :
• Pour les catégorielles à très forte cardinalité (>1000 modalités uniques), ne garder que si vraiment essentiel, sinon regrouper ou éliminer.
• Pour les numériques avec très peu de valeurs différentes ou beaucoup de doublons, vérifier l’utilité.

Sélection assistée des variables

• Variables à éliminer directement (manquants ~100% ou non informatives) site_ademe_url,site_projet_url,geomsurf,desserte_distance,desserte_commentaire,sol_pollution_annee, sol_pollution_commentaire → 100% manquants. sol_depollution_fiche (99.99% manquants), bati_surface (99.93%), bati_pollution, site_reconv_annee (100% manquants), etc.
• Variables à garder ou à traiter: Cible : site_statut
• Informations clefs : site_type,site_occupation,site_reconv_type, site_securite
• Localisation : comm_nom,comm_insee, geompoint
• Temporalité : site_identif_date,site_actu_date,activite_fin_annee,local_ancien_annee, local_recent_annee
• Bâti : bati_type,bati_nombre,bati_vacance,bati_patrimoine, bati_etat
• Propriétaire : proprio_type, proprio_personne
• Urbanisme : urba_zone_type,urba_zone_lib,urba_zone_formdomi, urba_doc_type
• Pollution : sol_pollution_existe, sol_pollution_origine
• Source : source_nom, source_producteur
• Autres : unite_fonciere_surface,unite_fonciere_refcad(attention à la cardinalité sur refcad !)

À transformer ou encoder :

Les dates (site_identif_date, site_actu_date) → à parser en datetime et à transformer en features numériques (année, ancienneté, etc.).

• Les variables avec "inconnu", "nan", etc. à encoder proprement (valeur manquante explicite).
• À surveiller (peu de valeurs mais intérêt métier) :
• activite_libelle : à raccourcir, ou regrouper sur une modalité principale (déjà fait plus haut).
• bati_surface : très incomplet, mais à conserver pour test si impact sur modèle.

Prémodèle¶

Modélisation exploratoire pour évaluer l'importance des features

Répartition des classes cible :
site_statut
friche potentielle    13129
friche sans projet     8774
friche avec projet     5538
friche reconvertie      674
Name: count, dtype: int64

           site_statut       site_reconv_type_filled  count
28  friche sans projet                 Non renseigné   8663
32  friche sans projet                       habitat     41
31  friche sans projet  autres activités économiques     26
34  friche sans projet                         mixte     13
36  friche sans projet                  renaturation     12
33  friche sans projet                       inconnu      6
37  friche sans projet             équipement public      5
30  friche sans projet                         autre      4
29  friche sans projet   aménagement d'espace public      3
35  friche sans projet      panneaux photovoltaiques      1

il est surprenant de voir que des friches sans projets ont une valeur non nulle de site_reconv_type, ce qui peut nous améné à nous demander si on garde ou pas cette feature

⚠️En fonction des modèles il est important de regarder les échelles de données

RandomForestClassifier(class_weight='balanced', n_estimators=200, n_jobs=-1,
                       random_state=42)

RandomForestClassifier(class_weight='balanced', n_estimators=200, n_jobs=-1,
                       random_state=42)

Confusion matrix :
[[ 769   18    8  312]
 [   7 2527   12   80]
 [  29    1   73   32]
 [ 259   56   25 1415]]

Classification report :
              precision    recall  f1-score   support

           0       0.72      0.69      0.71      1107
           1       0.97      0.96      0.97      2626
           2       0.62      0.54      0.58       135
           3       0.77      0.81      0.79      1755

    accuracy                           0.85      5623
   macro avg       0.77      0.75      0.76      5623
weighted avg       0.85      0.85      0.85      5623

0 => friche avec projet
1 => friche potentielle
2 => friche reconvertie
3 => friche sans projet

Accuracy globale : 0.85, ce qui reste très satisfaisant au vu de l’hétérogénéité du jeu de données et du nombre de classes. Précision / recall / f1-score : Classes majoritaires (1 et 3) : Très bien reconnues (f1-score respectivement de 0.97 et 0.78), ce qui signifie que le modèle capte efficacement les cas les plus courants. La performance sur ces classes tire la moyenne globale vers le haut. 1 friche potentiel, 3 friche sans projet, sachant que nous voulons améliorer le score de 0 et 2 friche avec projet et friche reconverti pour connaître les paramètres influençant la prise de décision pour la mutabilité Classe 0 (“support”=1107) : Recall de 0.69, f1-score de 0.71. C’est honorable et cohérent avec une classe intermédiaire en termes de fréquence : le modèle n’a pas de mal particulier à la distinguer. Classe 2 (“support”=135) : Recall à 0.62, f1-score à 0.54. Cette classe, très minoritaire, est la moins bien détectée : le modèle en “oublie” presque et la confond probablement avec des classes voisines. Cela peut venir soit d’un manque d’exemples, soit d’une forte proximité avec d’autres profils de friches.

Macro avg (f1-score : 0.75) : Cette moyenne non pondérée est correcte, ce qui indique que, même sur les classes les moins représentées, la performance reste acceptable sans s’effondrer.

Weighted avg (f1-score : 0.84) : Cette moyenne pondérée par la taille des classes est très haute, mais elle masque les difficultés sur les minoritaires (effet “classe majoritaire”).

Déséquilibre de classes : La distribution du support montre un fort déséquilibre, ce qui explique la baisse de performance sur les classes rares (en particulier la classe 2). Enjeux : Si la détection des classes minoritaires est importante (ex : friches à potentiel spécifique), il faudra envisager un rééquilibrage (SMOTE, rééchantillonnage, class_weight...).

                    feature  importance
2   activite_libelle_courte    0.184373
0                 site_type    0.177751
3                  comm_nom    0.152870
10              proprio_nom    0.116813
8              proprio_type    0.096618
5              bati_vacance    0.073485
7                 bati_etat    0.045940
11     sol_pollution_existe    0.044022
1           site_occupation    0.033480
6           bati_patrimoine    0.027482
9          proprio_personne    0.026901
4                 bati_type    0.020266

activite_libelle_courte                                         
                                                                    13485
Dépôt de liquides inflammables (D.L.I.)                              1821
Commerce de gros                                                     1474
Collecte et stockage des déchets non dangereux dont les ordu         1237
Dépôt d'immondices                                                    527
                                                                    ...  
 Complexe industriel fabriquant des matériels militaires et             1
 Bâtiments anciens à l'origine non connue à usage de logemen            1
 Activité\tTertiaire (bureaux) Année début activité 1978\t Ann          1
\r\n\r\nBâtiments anciens à l'origine non connue à usage de loge        1
• La société « AUBINE » : ancienne Installation Classée soum            1
Name: count, Length: 1583, dtype: int64

il serait interessant de faire les tests statistiques par rapport a ces variables. remarque on a pris aucune variable numérique ici

⚠️pourquoi activite_libelle_courte aussi imporante? il est surprenant de voir bati_type en bas de liste

Commentaire: en enlevant site_reconv_type on constate une perte de performance pour f1 score sur la classe 2 friche reconvertie, site_reconv_type est à priori une feature non disponible avant la prise décision, sa présence dans la liste des feature pour la modélisation reste a débattre car dans certains cas (111) des friches sans projets ont une valeur non nulles de site_reconv_type, ce qui signifie que une decision a été prise en amont pour décider du devenir d'une friche.

resultats avec site_reconv_type precision recall f1-score support

       0       0.70      0.69      0.69      1107
       1       0.97      0.96      0.97      2626
       2       0.64      0.53      0.58       135
       3       0.76      0.79      0.78      1755

accuracy                           0.84      5623

macro avg 0.77 0.74 0.75 5623 weighted avg 0.84 0.84 0.84 5623

Equilibrage¶

0 => friche avec projet
1 => friche potentielle
2 => friche reconvertie
3 => friche sans projet

Counter({1: 10503, 3: 7019, 0: 4431, 2: 539})

Classification report :
               precision    recall  f1-score   support

           0       0.70      0.71      0.70      1107
           1       0.97      0.96      0.97      2626
           2       0.47      0.61      0.53       135
           3       0.78      0.77      0.77      1755

    accuracy                           0.84      5623
   macro avg       0.73      0.76      0.74      5623
weighted avg       0.85      0.84      0.84      5623

Feature engineering élargissement du choix des features¶

ex feature utilisé par l'EPF pour la mutabilité Etat de la friche Surface de la parcelle: Emprise au sol du bâti État du bâti et infrastructure Présence de pollution Situation: En centre-ville ou centre-bourg Terrain viabilisé Distance d'une entrée d'autoroute Distance d'une gare/ TC Voie d'eau à proximité
Commerces / services à proximité-Distance raccordement BT/HT
Réglementation: Zonage PLU-Risque naturel Risque technologique Monument historique - Patrimoine Valeur architecturale
Ecosystème Couvert: végétal Espèce protégée- Zonage environnemental- TVBZones humides

Test sur les 50 variables toutes les modalités nan sont transformé en 0¶

Statistique du test du Chi² : 368.0570615521297
Degrés de liberté : 36
P-value : 1.1782490964730334e-56
✅ Conclusion : il existe une association significative entre le statut de la friche et son type de réhabilitation.

bac a sable pour tester les features¶

                              precision    recall  f1-score   support

                           0       1.00      1.00      1.00      5155
 aménagement d'espace public       1.00      0.44      0.62         9
                       autre       1.00      0.43      0.60         7
autres activités économiques       0.90      0.83      0.86        69
                      bureau       0.50      0.29      0.36         7
                    commerce       0.67      0.35      0.46        17
                     habitat       0.83      1.00      0.91       215
                   industrie       0.00      0.00      0.00         7
                       mixte       0.85      0.90      0.87        68
    panneaux photovoltaiques       0.67      0.40      0.50         5
                renaturation       1.00      0.47      0.64        17
           équipement public       0.92      0.74      0.82        47

                    accuracy                           0.99      5623
                   macro avg       0.78      0.57      0.64      5623
                weighted avg       0.99      0.99      0.98      5623

⚠️Revoir signification feature importance ou utilisé SHAP pour l'importance des features

Cramer¶

dtype('<M8[ns]')

🔎 Lecture structurée 🔝 Variables fortement corrélées avec la cible site_statut (0.366) → cohérent, c’est souvent la variable cible ou une proche.

site_url (0.282) → étrange à première vue ; possible effet structurel (présence d’un site Web liée à des friches plus avancées ?).

bati_vacance (0.238), sol_pollution_existe (0.208), bati_pollution (0.185), site_securite (0.141) → toutes très pertinentes sur le degré de délabrement ou d’abandon.

Ces variables peuvent avoir une valeur explicative directe pour un modèle de classification du statut.

📉 Variables faiblement corrélées urba_zone_formdomi, urba_doc_type, proprio_nom, etc. → faible Cramér’s V : à ne garder que si elles ont un intérêt métier, ou si elles se croisent bien avec d’autres.

⚠️ Variables à 0 site_nom, sol_depollution_fiche, sol_pollution_origine → attention, soit :

elles n’ont aucune variation significative liée à la cible ;

soit leur encodage ou nettoyage a masqué les signaux.

❓ Variables à NaN (non traitées) site_id, geompoint → normal, ce sont des identifiants ou coordonnées.

➤ À exclure d’office de toute analyse statistique directe.

site_reconv_type              0
site_statut                   0
site_url                      0
bati_vacance                  0
sol_pollution_existe          0
bati_pollution                0
bati_etat                     0
site_securite                 0
site_type                     0
source_producteur             0
source_nom                    0
bati_type                     0
site_occupation               0
unite_fonciere_surface       63
bati_nombre                  66
local_recent_annee        10694
local_ancien_annee        12772
dtype: int64

site_url
inconnu                                                                                                                                                         11120
https://www.suippes.fr/9143-2/                                                                                                                                     14
https://fiches-risques.brgm.fr/georisques/basias-detaillee/LRO6602417                                                                                              13
https://fiches-risques.brgm.fr/georisques/basias-detaillee/NA                                                                                                      10
https://www.google.com/maps/@45.5922396,0.1766609,3a,72.8y,317.09h,84.27t/data=!3m6!1e1!3m4!1smpDybbJGI3Por8GFLoUS9Q!2e0!7i13312!8i6656?authuser=0&entry=ttu        3
                                                                                                                                                                ...  
https://fiches-risques.brgm.fr/georisques/basias-detaillee/LOR8800529                                                                                               1
http://fiches-risques.brgm.fr/georisques/basias-detaillee/PAC0501872                                                                                                1
https://basol.developpement-durable.gouv.fr/fiche.php?page=1&index_sp=87.0031                                                                                       1
http://fiches-risques.brgm.fr/georisques/basias-detaillee/LRO6602561                                                                                                1
http://fiches-risques.brgm.fr/georisques/basias-detaillee/BRE3503237                                                                                                1
Name: count, Length: 16940, dtype: int64

📖 Synthèse sur la qualité des données¶

Complétude¶

--- Début de l’analyse de complétude détaillée ---

🔍 Domaine : information
  • site_id : 100.0%
  • site_nom : 100.0%
  • site_type : 38.7%
  • site_statut : 100.0%
  • site_occupation : 8.1%
  • site_reconv_type : 8.5%

🔍 Domaine : temporel
  • site_identif_date : 100.0%
  • site_actu_date : 100.0%
  • site_reconv_annee : 0.0%
  • activite_fin_annee : 14.2%
  • local_ancien_annee : 54.6%
  • local_recent_annee : 62.0%

🔍 Domaine : localisation
  • comm_nom : 99.5%
  • comm_insee : 99.5%
  • geompoint : 100.0%
  • geomsurf : 0.0%
  • site_adresse : 14.2%

🔍 Domaine : bati
  • bati_type : 7.6%
  • bati_nombre : 99.8%
  • bati_surface : 0.1%
  • bati_vacance : 7.5%
  • bati_patrimoine : 10.0%
  • bati_etat : 20.6%
  • unite_fonciere_surface : 99.8%
  • unite_fonciere_refcad : 99.9%

🔍 Domaine : proprietaire
  • proprio_type : 98.9%
  • proprio_personne : 99.8%
  • proprio_nom : 98.9%
  • activite_libelle : 52.0%
  • activite_code : 0.5%

🔍 Domaine : pollution
  • sol_pollution_annee : 0.0%
  • sol_pollution_existe : 11.7%
  • sol_pollution_origine : 0.1%
  • sol_pollution_commentaire : 0.0%
  • sol_depollution_fiche : 0.0%
  • site_securite : 79.3%
  • bati_pollution : 4.4%

🔍 Domaine : urbanisme
  • urba_zone_type : 85.9%
  • urba_zone_lib : 85.9%
  • urba_zone_formdomi : 16.1%
  • urba_doc_type : 86.3%
  • desserte_distance : 0.0%
  • desserte_commentaire : 0.0%

🔍 Domaine : source
  • source_nom : 17.9%
  • source_url : 76.4%
  • source_producteur : 23.4%
  • source_contact : 8.3%
  • site_url : 60.4%
  • site_ademe_url : 0.0%
  • site_projet_url : 0.0%

✅ 50 colonnes analysées.

Criticité¶

Unicité¶

Pertinence¶

🧮 Méthodologie de pondération du score de pertinence des variables Afin d’évaluer la pertinence globale des variables dans le cadre de l’analyse des friches, nous avons combiné trois dimensions complémentaires, chacune normalisée et pondérée selon son poids stratégique :

Criticité métier (α) → Issue d’un codage expert cnig (codes couleur) fondé sur le dictionnaire de variables officiel. → Pondérée à 0.4, car elle reflète la vision métier stratégique, bien que subjective.

Importance dans le modèle de Machine Learning (β) → Calculée via un algorithme de type Random Forest pour prédire la classe de friche. → Pondérée à 0.3, ce score reflète l’utilité prédictive mais dépend du modèle et de la cible.

Utilisation dans les indicateurs métiers existants (γ) → Basée sur la présence des variables dans les 22 indicateurs utilisés par Cartofriches. → Pondérée à 0.3, ce critère ancre l’analyse dans les usages réels du terrain.

La formule du score global de pertinence pondérée est donc :

🧮 Formules de calcul

1. Score pondéré par variable :

2. Poids ML de chaque variable :

3. Score global de pertinence (pondéré) :

4. Score global exprimé en pourcentage de la note maximale (4.0) :

⚠️ réevaluer les cofficients de pondérations avec un modèle plus robuste

Score de pertinence global en % : 32.97 %

Afin d'évaluer la criticité d'un paramètre nous devons lui associer un besoin métier. site_statut est un indicateur final de la présence ou non de friche, Pourtant dans les critères de l'epf celui ci n'est pas utilisé, dans leur critère de mutabilité ils ont inclus 22 paramètres que nous avons repris pour déterminer la pertinence d'une feature. le résultat de ce modèle donne un score qui determine quel type de reconversion sera appliqué, ceci ressemble le plus a site_reconv_type qui semble être une variable critique.

on va tenter de savoir si il y a une corrélation entre ces deux variables

source : "Connaitre les friches pour un développement territorial sobre" webinaire proposé par l’EPF Normandie"

Validité¶

Actualité¶

np.float64(90.99)

count    28083.000000
mean       323.640886
std       1812.280978
min          0.000000
25%          0.000000
50%          0.000000
75%          0.000000
max      44969.000000
Name: age_donnees_jours, dtype: float64

💡 Recommandations¶

• enrichissement des données : croisement  datasets gouvernementales avec datasets des observatoires
• enrcichissement scrapping gpkg (données textuelles sur l'api?)
• enrichissement avec données textuelles
• enrichissement avec données externes ex( données toxicologiques)

Recommandation de sources exemple, RPG

Annexe¶

Sigles fréquents et leur signification¶