ETL géospatial : pourquoi préparer ses données avant QGIS change tout

Vous téléchargez un fichier IGN, vous l'ouvrez dans QGIS, et avant même de commencer à travailler, vous passez une heure à renommer des colonnes, harmoniser des valeurs, faire une jointure avec un fichier INSEE et filtrer les entités qui vous intéressent.

La semaine suivante, vous recommencez.

Ce travail invisible a un nom : la transformation de données. C'est la couche "T" de l'ETL. Et il existe des outils faits pour ça — qui ne sont pas QGIS.

Introduction — Ce que vous faites avant d'ouvrir QGIS

Un géomaticien d'une communauté d'agglomération de l'ouest de la France m'a décrit sa routine du lundi matin. Chaque semaine, il reçoit un export de la base adresse nationale mis à jour. Avant de pouvoir l'utiliser dans son SIG, il effectue les mêmes opérations :

• renommer les colonnes selon la convention interne
• passer les noms de voie en minuscules
• supprimer les accents pour compatibilité avec le système de l'agglomération
• supprimer les 34 colonnes inutiles sur 38
• filtrer les adresses de son périmètre
• faire une jointure avec le fichier des IRIS pour enrichir les attributs

Temps moyen : entre 45 minutes et une heure. Chaque lundi.

Ce n'est pas un cas isolé. C'est la routine de la majorité des géomaticiens qui travaillent avec des données externes — IGN, data.gouv.fr, prestataires, autres services. La donnée brute n'arrive jamais dans le bon format, avec les bonnes colonnes, dans le bon périmètre. Elle se prépare. Et cette préparation se fait souvent dans QGIS, parce que c'est l'outil sous la main — pas parce que c'est le bon outil pour ça.

Cet article s'adresse aux géomaticiens et chargés SIG qui reconnaissent cette routine. L'objectif est simple : nommer ce travail, comprendre pourquoi QGIS n'est pas le bon endroit pour le faire, et découvrir ce qui existe à la place.

La donnée brute n'est jamais prête

Ce que vous faites vraiment avant d'ouvrir QGIS

Faisons l'inventaire honnête. Avant de commencer à analyser, à cartographier, à produire quoi que ce soit, la plupart des projets SIG impliquent une ou plusieurs de ces opérations :

Normalisation des colonnes : renommer NOM_COMMUNE en nom, CODE_INSEE en code_insee, supprimer les espaces dans les noms de champs, harmoniser les majuscules et les minuscules. Les fichiers IGN, les exports d'ERP, les données de prestataires — chacun a ses conventions. Votre projet en a une autre.

Nettoyage des valeurs : passer PARIS en Paris, supprimer les accents pour les systèmes qui ne les supportent pas (Île-de-France → Ile-de-France), corriger les encodages (ISO-8859-1 reçu, UTF-8 attendu), formater les codes INSEE sur 5 caractères avec zéro padding (75056 correct, 7556 invalide sans padding).

Filtrage des entités : garder uniquement les communes d'un département, les bâtiments d'une certaine catégorie, les parcelles d'une commune précise. Un fichier BD TOPO national quand vous travaillez sur une intercommunalité de 12 communes, c'est 99 % de données inutiles à charger.

Sélection des colonnes : un fichier IGN livré avec 47 colonnes dont 4 vous sont utiles. Les 43 autres alourdissent le fichier, ralentissent le chargement, et encombrent la table attributaire.

Jointures attributaires : enrichir une couche géométrique avec des attributs d'un fichier CSV ou d'une autre table. Communes + population INSEE. Parcelles + données foncières. Bâtiments + données énergie.

Vérification des géométries : les données téléchargées contiennent parfois des géométries invalides. Les charger telles quelles dans une analyse spatiale ou dans PostGIS produit des erreurs silencieuses dont le diagnostic est douloureux.

Prise individuellement, chaque opération semble anodine. C'est leur répétition — sur les mêmes sources, selon les mêmes règles, chaque semaine ou chaque mois — qui révèle le problème de fond.

Les actions répétées que personne ne nomme

Ce travail s'appelle de la transformation de données. C'est précisément la couche "T" de l'ETL — Extract, Transform, Load. La plupart des géomaticiens le font dans QGIS parce que c'est l'outil qu'ils ont sous la main. Mais QGIS a été conçu pour visualiser et analyser des données géographiques — pas pour les transformer.

Utiliser QGIS pour préparer ses données, c'est un peu comme utiliser un logiciel de cartographie pour rédiger un compte rendu de réunion. Ça marche techniquement — QGIS peut tout à fait renommer des colonnes et faire des jointures. Mais ce n'est pas ce pour quoi l'outil est optimisé, et ça se voit dans l'expérience quotidienne.

QGIS n'est pas un outil de transformation — c'est un outil d'analyse

Le problème des couches temporaires

Chaque opération de transformation dans QGIS produit par défaut une couche temporaire en mémoire. Sélection par attribut : couche temporaire. Jointure attributaire : couche temporaire. Calculateur de champ : couche temporaire. Filtre géométrique : couche temporaire.

Ces couches n'existent que pendant la session QGIS en cours. Elles disparaissent à la fermeture sans "Enregistrer sous". Un pipeline de transformation de 5 étapes dans QGIS, c'est donc 5 "Enregistrer sous" successifs, 5 fichiers intermédiaires à nommer selon une convention ad hoc, à stocker quelque part, et à retrouver la prochaine fois.

La conséquence pratique : les géomaticiens développent des habitudes défensives. On sauvegarde très souvent, au moindre doute. On accumule des fichiers intermédiaires communes_v1.gpkg, communes_v2_filtre.gpkg, communes_v2_filtre_jointure.gpkg. Le dossier de travail devient illisible en quelques semaines.

Le projet QGIS comme brouillon permanent

La couche temporaire est le symptôme visible. Le problème plus profond est la confusion entre deux espaces de travail distincts : l'espace de préparation des données et l'espace d'analyse et de cartographie.

Dans QGIS, les deux coexistent dans le même panneau de couches. Les couches qui sont des états intermédiaires de transformation se mélangent aux couches qui sont des données de travail définitives. On ne sait plus quelle couche est "la bonne version". On hésite à en supprimer une de peur qu'elle soit encore utile. Le projet QGIS ressemble à un brouillon plutôt qu'à un espace de travail organisé.

Ce n'est pas un problème d'organisation personnelle — c'est la conséquence structurelle d'utiliser le mauvais outil pour la transformation.

La séparation des responsabilités

Quand on sépare ces deux responsabilités, QGIS retrouve son rôle naturel : un outil de cartographie et d'analyse puissant, alimenté par des données déjà propres. Le projet QGIS ne contient que des données de travail. Plus de couches temporaires d'états intermédiaires, plus de fichiers _v2_final_definitif.gpkg.

Ce qu'un pipeline ETL fait à votre place

Un pipeline ETL géospatial, c'est une séquence d'opérations définie une fois, rejouable à volonté. Il prend la donnée brute en entrée et livre la donnée propre en sortie — sans interaction humaine, sans couches temporaires, sans "Enregistrer sous" intermédiaire. Voici les cinq opérations les plus courantes.

Standardisation : colonnes, casse, accents, types

Un fichier de la BD TOPO IGN arrive avec des noms de colonnes en majuscules, des valeurs texte avec accents, un champ surface stocké comme chaîne de caractères alors qu'il devrait être un nombre flottant. Toutes ces transformations sont triviales à coder une fois et à rejouer automatiquement.

import geopandas as gpd
import unicodedata

# Charger le fichier source
gdf = gpd.read_file("batiments_bdtopo.gpkg")

# Normaliser les noms de colonnes
gdf.columns = (
    gdf.columns
    .str.lower()
    .str.replace(" ", "_")
)

# Supprimer les accents dans les valeurs texte
def supprimer_accents(texte):
    if not isinstance(texte, str):
        return texte
    return unicodedata.normalize("NFD", texte).encode("ascii", "ignore").decode("utf-8")

gdf["nom"] = gdf["nom"].apply(supprimer_accents)

# Convertir le champ surface en float
gdf["surface"] = gdf["surface"].astype(float)

# Garder uniquement les colonnes utiles
gdf = gdf[["nom", "surface", "usage", "geometry"]]

# Exporter le résultat propre
gdf.to_file("batiments_propres.gpkg", driver="GPKG")

Ce script tourne en quelques secondes. La semaine prochaine, quand le fichier est mis à jour, il tourne à nouveau — sans intervention humaine.

Jointures automatiques entre sources

Cas concret : une couche géométrique des communes (fichier GeoPackage) doit être enrichie avec les données de population du fichier INSEE (CSV). Dans QGIS : jointure manuelle, couche temporaire, Enregistrer sous. Dans un pipeline Python ou avec ogr2ogr : une opération, un fichier propre en sortie.

La jointure est codée une fois selon les règles métier — clé de jointure, gestion des valeurs nulles, colonnes à conserver. Elle est rejouée automatiquement à chaque nouvelle livraison des données sources, que ce soit la mise à jour annuelle des données INSEE ou une livraison hebdomadaire d'un prestataire.

Filtrage et sélection des champs utiles

Un fichier BD TOPO national fait plusieurs gigaoctets. Pour un projet sur une intercommunalité de 15 communes, 99 % de ces données sont inutiles. Un pipeline ETL filtre les entités et sélectionne les colonnes utiles avant même que QGIS ne soit impliqué. La géométrie est conservée automatiquement — seuls les champs attributaires sont à lister.

# Filtrer les bâtiments d'un département et garder 3 colonnes sur 47
ogr2ogr \
  -f GPKG batiments_973.gpkg \
  batiments_france.gpkg \
  -where "CODE_DEP = '973'" \
  -select "NOM,SURFACE,USAGE"

Le fichier livré à QGIS est 50 fois plus léger. Il se charge en secondes. La table attributaire est lisible.

Vérification et correction des géométries invalides

Les données téléchargées contiennent parfois des géométries invalides : auto-intersections, anneaux non fermés, géométries nulles. Les charger directement dans PostGIS ou les utiliser dans une analyse d'intersection produit des erreurs silencieuses — des résultats faux sans message d'erreur explicite.

Un pipeline ETL géospatial inclut une étape de validation et de correction avant chargement. En Python avec GeoPandas, buffer(0) corrige la plupart des géométries invalides en une ligne. En QGIS Processing via qgis_process, l'algorithme native:fixgeometries fait le même travail en mode batch.

Un seul fichier en sortie — propre, nommé, dans le bon format

Le résultat du pipeline est un fichier unique : nommé selon la convention interne, dans le bon CRS, avec uniquement les colonnes utiles, les géométries validées, les attributs normalisés. QGIS l'ouvre directement. Pas de nettoyage, pas de couche temporaire, pas de "Enregistrer sous". Le projet QGIS ne contient que des données de travail.

Les outils adaptés au géomaticien

Trois niveaux d'entrée selon les compétences disponibles. Pas besoin de tout maîtriser — choisir l'outil le plus simple qui couvre le besoin.

Pour aller plus loin sur ces outils et les architectures de pipelines associées, le livre blanc ETL 2026 couvre l'ensemble de l'écosystème, du script Python aux plateformes comme FME, avec un guide décisionnel par profil et volumétrie.

Quand automatiser — et quand ne pas le faire

Automatiser un pipeline ETL géospatial a un coût initial : écrire le script ou construire le modèle, le tester, le maintenir quand les sources changent. Ce coût n'est justifié que si la transformation est répétée régulièrement.

La règle est simple : si vous effectuez la même transformation plus d'une fois sur la même source, automatisez. Sinon, QGIS reste un outil parfaitement valide pour les manipulations ponctuelles.

Ce qu'il faut retenir

Le travail de préparation des données géospatiales — renommer les colonnes, harmoniser les valeurs, faire les jointures, filtrer par périmètre — est un travail de transformation. C'est de l'ETL. Il a sa place dans un pipeline dédié, pas dans QGIS.

Séparer la transformation de l'analyse a un effet concret et immédiat : le projet QGIS devient plus propre, plus rapide, plus lisible. Les couches temporaires et les "Enregistrer sous" intermédiaires disparaissent. QGIS redevient ce qu'il est : un outil d'analyse et de cartographie alimenté par des données déjà prêtes.

Les outils existent — ogr2ogr, QGIS Processing + qgis_process, Python + GeoPandas — et ils sont accessibles sans être data engineer. Le premier pipeline ETL géospatial peut être opérationnel en une demi-journée pour un géomaticien à l'aise avec un terminal.