On choisit un format avec soin, on construit une carte, on expose une API — et la question du stockage arrive en dernier, comme une contrainte technique à régler rapidement. C'est une erreur. Le où stocker n'est pas un détail d'infrastructure. C'est une décision architecturale qui conditionne les performances de lecture, la capacité d'analyse, la scalabilité, les coûts d'exploitation et la facilité d'exposition. Ce deuxième volume de la collection « Chaîne de la donnée géospatiale » couvre 55 ans d'évolution — du fichier propriétaire ESRI aux lacs de données columnar cloud-native — avec une taxonomie en cinq familles, des benchmarks réels et quatre architectures de référence pour 2026.

Préface

La donnée géospatiale pose une question que l'on reporte trop souvent : où la stocker ? On choisit un format, on construit une carte, on expose une API — et la question du stockage arrive en dernier, comme une contrainte technique à régler rapidement. C'est une erreur.

Ce deuxième livre blanc de la série MP-i s'attaque à cette question centrale. Le où stocker n'est pas un détail d'infrastructure. C'est une décision architecturale qui conditionne les performances de lecture, la capacité d'analyse, la scalabilité, les coûts d'exploitation et la facilité d'exposition — tout ce qui vient ensuite.

Ce document est le maillon central d'une trilogie :

• Livre Blanc Formats Géospatiaux 2026 (le QUOI) : la structure des formats géospatiaux, leur histoire, leurs critères de choix. La question des contenants de la donnée.
• LB2 — Stockage (le OÙ) : ce document. Les moteurs, les index, les coûts, la gouvernance. La question de l'endroit où la donnée réside et comment on l'interroge.
• LB3 — Exposition (le COMMENT) : servir et consommer la donnée sur le web. La question des interfaces entre le stockage et les clients.

Mattieu Pottier — Consultant en transformation digitale, spécialiste SIG et applications géospatiales

Introduction — Pourquoi le stockage géospatial est un sujet stratégique

Stocker de la donnée géospatiale n'est pas stocker de la donnée ordinaire. Une table de 10 millions de polygones de parcelles cadastrales ne se comporte pas comme une table de 10 millions de lignes de facturation. Les géométries sont des objets complexes, variables en taille, qui nécessitent des index spécialisés, des opérateurs dédiés et des moteurs capables de répondre à des questions fondamentalement différentes des requêtes attributaires classiques : quelles entités intersectent cette zone ? quels points sont à moins de 500 mètres de cette route ? quelle est la superficie de l'union de ces polygones ?

Choisir le mauvais moteur de stockage, c'est potentiellement :

• Des performances dégradées — un scan complet d'un GeoJSON de 2 Go pour trouver les entités dans une bbox, là où un index spatial GiST sur PostGIS répondrait en quelques millisecondes
• Une scalabilité impossible — un fichier GeoPackage verrouillé par un utilisateur QGIS pendant qu'un script Python tente d'écrire dessus
• Un coût d'infrastructure disproportionné — un stack PostGIS + tile server (Martin, pg_tileserv) pour servir des données qui changent une fois par mois, là où PMTiles sur un CDN suffirait pour dix fois moins cher
• Une dette technique — un Shapefile au cœur d'un pipeline de données moderne, avec sa limite de 2 Go, ses noms de colonnes tronqués à 10 caractères et son absence de transactions

Le fil conducteur : quatre ruptures technologiques

Les trois questions fondamentales

Avant de choisir un moteur de stockage, trois questions doivent être posées :

Comment lire ce document

Lecture linéaire — recommandée pour comprendre l'évolution des paradigmes de stockage géospatial et les raisons historiques des choix actuels. Suivre les parties 1 à 11 dans l'ordre.

Lecture orientée décision — pour un projet en cours, aller directement à la Partie 9 (guide décisionnel) et aux architectures de référence (Partie 10), puis remonter vers les parties techniques selon les moteurs retenus.

Partie 1 — Taxonomie des modes de stockage géospatial

Avant d'entrer dans l'histoire et les détails techniques, il est utile de disposer d'une grille de lecture. Le paysage du stockage géospatial est vaste et hétérogène — des fichiers plats hérités des années 1990 aux lacs de données columnar cloud-native de 2026. Cinq grandes familles structurent cet espace.

1.1 Les cinq grandes familles

Figure 2 — Les cinq familles de stockage géospatial

1.2 Les 5 critères de choix d'un mode de stockage

1.3 Matrice synthétique famille × critères

Partie 2 — Ère 1 : Le fichier comme paradigme (1970–1999)

Shapefile (1993 — ESRI)

Le Shapefile est introduit par ESRI en 1993 avec ArcView GIS 2. Conçu comme format d'interopérabilité entre produits ESRI, il devient le format d'échange universel de la géomatique par défaut d'inertie, faute de concurrent ouvert viable pendant plus d'une décennie.

Problèmes de stockage spécifiques au Shapefile

Coverage ESRI et formats propriétaires historiques

Avant le Shapefile, ESRI utilisait le format Coverage (ARC/INFO, années 1980) — une structure de répertoire complexe stockant géométries, topologie et tables attributaires dans une arborescence propriétaire. Il encodait la topologie explicitement (relations entre arcs, nœuds, polygones), puissant pour l'analyse topologique mais opaque pour l'interopérabilité.

Les formats DXF (AutoCAD, 1982) et DGN (MicroStation, Intergraph / Bentley) viennent du monde de la CAO et ont été massivement utilisés pour stocker des données géographiques dans les collectivités et bureaux d'études. Ils partagent les mêmes limitations : pas de projection standardisée, pas d'attributs structurés, sémantique géométrique CAO incompatible avec les SIG.

GeoTIFF (1994–1995) — le raster de référence

La spécification GeoTIFF est rédigée par Niles Ritter (NASA Jet Propulsion Laboratory) et Mike Ruth (SPOT Image Corp). La version 1.0 officielle est publiée en novembre 1995. Il étend le format TIFF en ajoutant des balises géoréférencées (système de coordonnées, transformation affine) dans les métadonnées du fichier.

Sans pyramides (overviews), tout accès à une vue dézoomée oblige à lire l'intégralité du fichier. Les overviews sont des versions sous-échantillonnées précalculées — internes au fichier ou dans un fichier `.ovr` séparé. Le tiling interne (TILED=YES dans GDAL) organise les données en blocs carrés (256×256 ou 512×512 px), réduisant les lectures pour les accès à une zone géographique spécifique.

Le problème fondamental du fichier plat

Partie 3 — Ère 2 : La base de données spatiale (2000–2009)

PostGIS (2001 — Refractions Research)

PostGIS est créé par Refractions Research (Victoria, Colombie-Britannique, Canada). Première version publiée en mai 2001 par Dave Blasby, avec Paul Ramsey comme co-fondateur. Version stable 1.0 : 19 avril 2005. Version actuelle 2026 : PostGIS 3.5.x, maintenu par la communauté OSGeo.

Types géométriques et géographiques

Index spatial : GiST, SP-GiST, BRIN

Fonctions clés PostGIS

EXPLAIN ANALYZE sur les requêtes PostGIS

-- Vérifier que l'index GiST est bien utilisé
EXPLAIN ANALYZE
SELECT id, nom
FROM parcelles
WHERE ST_Intersects(geom, ST_MakeEnvelope(2.3, 48.8, 2.4, 48.9, 4326));

-- Un plan optimal montre un Bitmap Index Scan ou Index Scan
-- sur l'index GiST, suivi d'un Recheck Cond.
-- Un Seq Scan sur une grande table = index absent ou désactivé.

SpatiaLite (2008)

SpatiaLite est une extension spatiale pour SQLite, développée par Alessandro Furieri à partir de 2008. Il apporte à SQLite des capacités comparables à PostGIS : types géométriques OGC, index spatial R-Tree natif, fonctions d'analyse géospatiale (basées sur GEOS et PROJ).

Positionnement : le fichier de base de données spatiale transportable. Un fichier .sqlite peut être copié, ouvert dans QGIS sur n'importe quelle machine — sans configurer un serveur PostgreSQL. Idéal pour les applications QGIS hors ligne, les échanges entre techniciens SIG sans infrastructure partagée, les bases embarquées.

Oracle Spatial & Graph

Oracle intègre des capacités spatiales depuis Oracle 7 Spatial Data Option (milieu des années 1990), avec le composant Oracle Spatial stabilisé à partir d'Oracle 9i (2001). Il a dominé le marché du SIG d'entreprise pendant les années 2000, porté par la présence Oracle déjà établie dans les grandes infrastructures publiques.

Statut 2026 : Oracle Spatial reste présent dans les grandes structures publiques (ministères, opérateurs d'infrastructures critiques) standardisées Oracle depuis les années 2000. Les nouveaux projets choisissent systématiquement PostGIS. La migration Oracle Spatial → PostGIS est un chantier courant dans les DSI en transformation.

SQL Server Spatial (2008)

Microsoft introduit les types spatiaux dans SQL Server 2008 avec deux types distincts : geometry (coordonnées planes) et geography (coordonnées sphériques). SQL Server Spatial est le choix naturel dans les organisations standardisées sur l'écosystème Microsoft (Azure, Power BI, SSRS). Hors cet écosystème, PostGIS reste plus performant, plus complet et sans coût de licence.

PostGIS vs les alternatives relationnelles — comparatif

L'index spatial : le cœur de la performance

Le R-Tree (Rectangle Tree) est la structure d'index spatial dominante. Il organise les géométries dans une hiérarchie de bounding boxes imbriquées. Une requête spatiale parcourt l'arbre depuis la racine, éliminant les branches dont la bounding box n'intersecte pas la zone de recherche.

PostGIS implémente le R-Tree via le GiST (Generalized Search Tree), un framework d'index extensible de PostgreSQL. L'index GiST est bidimensionnel par défaut (2D) mais supporte les index nD pour les géométries 3D.

Partie 4 — Formats de fichier modernes (2010–2019)

GeoPackage (2014 — OGC)

Le GeoPackage est adopté comme standard OGC en février 2014 (OGC 12-128r12). Basé sur SQLite — fichier unique contenant une base de données relationnelle complète — avec un schéma standardisé OGC pour stocker vecteur, raster et métadonnées.

Pourquoi GeoPackage remplace Shapefile

GeoPackage hérite des caractéristiques de stockage de SQLite : index spatial R-Tree (rtree), moins performant que GiST PostGIS sur grands volumes mais suffisant pour des millions d'entités en lecture. Concurrence limitée : SQLite utilise un verrou global en écriture (mode WAL améliore légèrement la lecture concurrente).

FlatGeobuf (2018–2019)

FlatGeobuf est développé par Björn Harrtell à partir de 2018–2019. Il utilise FlatBuffers (format de sérialisation binaire Google) pour encoder les géométries et intègre un index Hilbert R-Tree pour l'accès spatial sans serveur.

Stockage sur CDN et S3 : l'accès HTTP Range

La caractéristique distinctive de FlatGeobuf est son support natif des HTTP Range Requests. Un fichier .fgb hébergé sur S3, R2 ou un CDN peut être requêté spatialement sans serveur intermédiaire. Le flux d'accès partiel :

MBTiles — le tile store en SQLite

MBTiles est une spécification développée par Mapbox à partir de 2010 pour stocker des tuiles cartographiques (PNG, WebP, ou MVT) dans une base de données SQLite. Structure simple : une table tiles avec colonnes zoom_level, tile_column, tile_row et un blob tile_data.

Avantages pour le stockage local : compatible TileServer GL, supporté par QGIS pour les fonds de carte offline, utilisé dans les applications mobiles hors ligne (OsmAnd, Organic Maps). Limite pour le cloud : SQLite ne supporte pas les HTTP Range Requests nativement — un serveur (TileServer GL) reste nécessaire pour servir les tuiles HTTP. C'est précisément ce que PMTiles élimine.

PMTiles (2021 — Protomaps, V3 stable 2022)

PMTiles est développé par Brandon Liu (Protomaps LLC). Première version annoncée en mars 2021. Version 3 stable publiée en octobre 2022. Il résout le problème central de MBTiles pour le cloud : servir des tuiles depuis un stockage objet sans serveur. Chaque tuile est accessible via une unique requête HTTP Range, permettant à MapLibre GL JS de la consommer directement depuis Cloudflare R2 ou AWS S3 — sans aucun serveur intermédiaire.

Workflow de génération

Comparatif coûts de stockage : S3 vs R2

Partie 5 — Le NoSQL géospatial (2010–2019)

MongoDB + GeoJSON

MongoDB (lancé en 2009 par 10gen) intègre des capacités géospatiales significatives à partir de la version 2.4 (mars 2013) avec l'introduction de l'index 2dsphere et le support natif de GeoJSON. Les types supportés couvrent les géométries OGC Simple Features : Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection.

{
  "_id": ObjectId("..."),
  "nom": "Tour Eiffel",
  "localisation": {
    "type": "Point",
    "coordinates": [2.2945, 48.8584]
  },
  "categorie": "monument"
}

Index géospatiaux et opérateurs

Cas d'usage : données IoT/GPS (ingestion massive, attributs variables par capteur), documents géolocalisés riches (fiches de commerces, POI avec photos et horaires), logs géolocalisés. MongoDB brille sur les cas que PostGIS gère mal ou surdimensionne.

Elasticsearch Geo

Elasticsearch (lancé le 8 février 2010 par Shay Banon) intègre des capacités géospatiales dès ses premières versions. En 2026, la vraie valeur d'Elasticsearch pour le stockage géospatial n'est pas la performance spatiale — PostGIS est meilleur sur ce point — c'est la combinaison requête textuelle + filtre spatial dans un seul moteur distribué.

// "Toutes les boulangeries artisanales dans un rayon de 500m"
{
  "query": {
    "bool": {
      "must": {
        "match": { "nom": "boulangerie artisanale" }
      },
      "filter": {
        "geo_distance": {
          "distance": "500m",
          "localisation": { "lat": 48.8584, "lon": 2.2945 }
        }
      }
    }
  }
}

Redis Geo

Redis intègre les commandes GEO* à partir de la version 3.2 (avril 2016). Les données GEO sont stockées comme scores dans un sorted set Redis, encodées en Geohash 52 bits — précision sub-centimétrique, largement suffisante pour toutes les applications de géolocalisation.

TimescaleDB — le stockage spatio-temporel

TimescaleDB est une extension PostgreSQL lancée par Timescale Inc. en 2017, conçue pour les séries temporelles. Elle ne remplace pas PostGIS — elle le complète pour les données à forte dimension temporelle. Elle organise les données en hypertables, partitionnées automatiquement par intervalle de temps en chunks internes (compressibles, archivables, supprimables automatiquement).

-- Table de positions GPS de véhicules
CREATE TABLE positions (
  temps        TIMESTAMPTZ NOT NULL,
  vehicule_id  INTEGER NOT NULL,
  geom         GEOMETRY(Point, 4326) NOT NULL,
  vitesse      FLOAT,
  cap          FLOAT
);

-- Conversion en hypertable (partitionnement par jour)
SELECT create_hypertable('positions', 'temps');

-- Index spatial sur la géométrie
CREATE INDEX ON positions USING GIST(geom);

Cas d'usage : suivi GPS de flottes (positions toutes les secondes), données de capteurs IoT géolocalisés (qualité de l'air, météo, trafic), trajectoires et analyses de mobilité, télémétrie géolocalisée.

NoSQL géospatial vs PostGIS — quand choisir quoi

Partie 6 — Stockage cloud-native et analytique (2020–2026)

COG — Cloud Optimized GeoTIFF

Le COG est un GeoTIFF réorganisé pour que toutes les métadonnées soient en tête de fichier et que les overviews + tuiles soient géographiquement ordonnées. Cela permet à un client HTTP de requêter uniquement les octets nécessaires — souvent 1 à 5 % du fichier total pour une vue typique.

Workflow de génération

# Conversion GeoTIFF classique → COG avec GDAL
gdal_translate \
  -of COG \
  -co COMPRESS=ZSTD \
  -co OVERVIEW_RESAMPLING=LANCZOS \
  -co OVERVIEW_COMPRESS=ZSTD \
  input.tif \
  output_cog.tif

# Validation avec rio-cogeo (pip install rio-cogeo)
rio cogeo validate output_cog.tif

Stratégies d'overviews selon la volumétrie

GeoParquet (spécification v1.0 stable — septembre 2023)

GeoParquet 1.0.0-beta.1 est publié en décembre 2022. La version stable GeoParquet 1.0.0 est publiée en septembre 2023. Contributeurs fondateurs : GeoPandas, GeoTrellis, Voltron Data, Microsoft, CARTO, Planet.

Apache Parquet stocke les données d'une même colonne de manière contiguë sur disque. Pour une requête analytique typique — "superficie totale de toutes les parcelles dans une région" — un moteur columnar ne lit que deux colonnes (geom et surface), pas l'intégralité de chaque ligne. Sur 10 millions d'entités avec 50 attributs, l'économie est considérable.

Partitionnement spatial

Lire GeoParquet depuis DuckDB, GeoPandas, Spark Sedona

# GeoPandas
import geopandas as gpd
gdf = gpd.read_parquet("s3://mon-bucket/parcelles.parquet",
                        storage_options={"anon": True})

# DuckDB
import duckdb
conn = duckdb.connect()
conn.execute("INSTALL spatial; LOAD spatial;")
result = conn.execute("""
  SELECT ST_Area(geometry) as superficie, commune
  FROM read_parquet('s3://mon-bucket/parcelles.parquet')
  WHERE bbox.xmin > 2.0 AND bbox.xmax < 3.0
    AND bbox.ymin > 48.0 AND bbox.ymax < 49.0
""").fetchdf()

Comparatif GeoParquet vs PostGIS pour l'analytique

DuckDB + extension spatial

DuckDB est créé par Mark Raasveldt et Hannes Mühleisen au CWI Amsterdam. Version stable 1.0.0 ("Snow Duck") publiée le 3 juin 2024. Extension spatial disponible depuis la version 0.7 (2023). Moteur analytique in-process — il s'exécute dans le processus appelant, sans serveur séparé. Lit directement depuis S3, R2, fichiers locaux, HTTP.

INSTALL spatial; LOAD spatial;

-- Lire GeoParquet S3, filtrer spatialement, écrire en GeoParquet
COPY (
  SELECT geom, commune, surface_ha
  FROM read_parquet('s3://mon-bucket/france/parcelles.parquet')
  WHERE ST_Within(
    geom,
    ST_GeomFromText('POLYGON((2.2 48.8, 2.4 48.8, 2.4 48.9, 2.2 48.9, 2.2 48.8))')
  )
  AND surface_ha > 1.0
) TO 'paris_grandes_parcelles.parquet' (FORMAT PARQUET);

import duckdb

conn = duckdb.connect()
conn.execute("INSTALL spatial; LOAD spatial;")

# ETL : Shapefile → reprojection Lambert 93 → WGS84 → GeoParquet
conn.execute("""
  COPY (
    SELECT
      ST_Transform(geom_src, 'EPSG:2154', 'EPSG:4326') as geom,
      nom_commune, code_insee,
      ST_Area(geom_src) / 10000 as surface_ha   -- en Lambert 93 = m²
    FROM (
      SELECT geom as geom_src, nom_commune, code_insee
      FROM ST_Read('communes.shp')
      WHERE code_insee LIKE '75%'
    )
  ) TO 'paris_communes.parquet' (FORMAT PARQUET)
""")

Benchmark Overture Maps France (~30M entités, 8 Go GeoParquet)

Serveur Linux 16 Go RAM, disque NVMe SSD. PostGIS gagne sur les requêtes indexées précises. DuckDB gagne sur les scans analytiques complets. Les deux sont complémentaires.

Delta Lake / Apache Iceberg + géospatial

Delta Lake est lancé par Databricks en 2019 pour apporter les propriétés ACID aux lacs de données Parquet. Apache Iceberg est créé par Ryan Blue et Daniel Weeks chez Netflix (Apache Incubator 2018, projet top-level 2020). GeoParquet est immutable — toute modification implique de réécrire le fichier complet. Delta Lake résout ce problème via un journal de transactions (_delta_log) qui enregistre chaque opération.

from delta import DeltaTable
from pyspark.sql import SparkSession
from sedona.spark import SedonaContext

spark = SedonaContext.create(SparkSession.builder
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension")
    .getOrCreate())

# Écriture géospatiale en Delta
parcelles_df.write.format("delta").save("s3://mon-bucket/delta/parcelles")

# Mise à jour ACID : corriger la géométrie d'une parcelle
deltaTable = DeltaTable.forPath(spark, "s3://mon-bucket/delta/parcelles")
deltaTable.update(
    condition = "id_parcelle = '75001-001'",
    set = {"geom": "ST_GeomFromText('POLYGON(...)')"}
)

# Time travel : état du dataset il y a 7 jours
spark.read.format("delta") \
    .option("timestampAsOf", "2026-03-10") \
    .load("s3://mon-bucket/delta/parcelles")

Overture Maps + GeoParquet

Overture Maps Foundation est lancée en décembre 2022 par Amazon, Microsoft, Meta et TomTom. Première release publique : juillet 2023. Overture publie ses données exclusivement en GeoParquet partitionné sur AWS S3 — la plus grande validation publique du format à ce jour.

# Télécharger les bâtiments de France depuis Overture Maps avec DuckDB
duckdb -c "
INSTALL spatial; LOAD spatial; INSTALL httpfs; LOAD httpfs;

COPY (
  SELECT id, geometry, height, num_floors
  FROM read_parquet('s3://overturemaps-us-west-2/release/{RELEASE_DATE}/theme=buildings/type=building/*',
                    filename=true, hive_partitioning=1)
  -- Remplacer {RELEASE_DATE} par la date courante : overturemaps.org/download/
  WHERE bbox.xmin > -5.1 AND bbox.xmax < 9.6
    AND bbox.ymin > 41.3 AND bbox.ymax < 51.1
) TO 'france_buildings.parquet' (FORMAT PARQUET);
"

Partie 7 — Stockage raster : du fichier à l'objet cloud

Le stockage raster géospatial a suivi une trajectoire parallèle au vecteur : du fichier local isolé vers le stockage objet cloud requêtable à distance. GeoTIFF pyramidé reste le standard local ; COG est devenu le standard cloud ; STAC en est le catalogue.

PostGIS Raster (postgis_raster)

L'extension postgis_raster permet de stocker des données raster dans PostgreSQL sous forme de tuiles. L'outil CLI raster2pgsql génère les instructions SQL de chargement depuis un GeoTIFF.

# Chargement d'un GeoTIFF en base PostGIS — tuiles 100×100 px
raster2pgsql -s 4326 -I -C -M -t 100x100 mnt_france.tif public.mnt_france | psql -d geodata

GeoTIFF pyramidé — le raster local classique

Compression : quel choix pour quel usage

COG sur stockage objet — le raster cloud

Un COG hébergé sur Cloudflare R2 ou AWS S3 peut être consommé directement par QGIS (via GDAL/VSI), par des scripts Python (rasterio, rio-cogeo), par des APIs (TiTiler — exposition traitée dans LB3) ou par des navigateurs.

STAC — cataloguer le raster cloud

Le SpatioTemporal Asset Catalog (STAC) est une spécification communautaire dont le premier sprint a lieu en octobre 2017 (Radiant Earth Foundation). Version 1.0.0 publiée le 25 mai 2021. STAC répond à un problème simple : comment découvrir et requêter des COG stockés sur S3 sans les connaître individuellement ?

{
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "idf-ortho-2024-75",
  "bbox": [2.224, 48.815, 2.470, 48.902],
  "geometry": { "type": "Polygon", "coordinates": [[...]] },
  "properties": {
    "datetime": "2024-06-15T00:00:00Z",
    "resolution": 0.2,
    "crs": "EPSG:2154"
  },
  "assets": {
    "image": {
      "href": "s3://mon-bucket/ortho/idf-2024-75.tif",
      "type": "image/tiff; application=geotiff; profile=cloud-optimized"
    }
  }
}

Stratégies de pyramidage et de compression — tableau récapitulatif

Partie 8 — Sécurité, accès et gouvernance du stockage

Contrôle d'accès à PostGIS

La bonne pratique est de créer des rôles métier correspondant aux profils d'utilisation, plutôt que de gérer les droits par utilisateur.

-- Rôle lecture seule SIG
CREATE ROLE sig_lecteur;
GRANT CONNECT ON DATABASE geodata TO sig_lecteur;
GRANT USAGE ON SCHEMA public TO sig_lecteur;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO sig_lecteur;

-- Rôle éditeur (lecture + écriture sur tables métier)
CREATE ROLE sig_editeur;
GRANT sig_lecteur TO sig_editeur;
GRANT INSERT, UPDATE ON TABLE parcelles, voirie, zonage TO sig_editeur;

-- Rôle admin
CREATE ROLE sig_admin;
GRANT ALL ON ALL TABLES IN SCHEMA public TO sig_admin;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO sig_admin;

Row-Level Security (RLS) sur des tables géographiques

-- Activer RLS sur la table parcelles
ALTER TABLE parcelles ENABLE ROW LEVEL SECURITY;

-- Politique : un utilisateur ne voit que les parcelles de sa commune
CREATE POLICY acces_commune ON parcelles
  USING (
    code_commune IN (
      SELECT code_commune
      FROM utilisateurs_communes
      WHERE utilisateur = current_user
    )
  );

Chiffrement au repos et en transit

Sauvegarde et restauration d'une base PostGIS

# Sauvegarde standard (format custom compressé)
pg_dump -Fc -d geodata -f geodata_backup_$(date +%Y%m%d).dump

# Sauvegarde parallèle pour bases > 50 Go (format directory, 4 workers)
pg_dump -Fd -j 4 -d geodata -f geodata_backup_$(date +%Y%m%d)/

# Restauration complète
pg_restore -d geodata_restore geodata_backup_20260317.dump

# Restauration d'une table spécifique
pg_restore -d geodata -t parcelles geodata_backup_20260317.dump

Vérification de l'intégrité après restauration

-- Vérifier les géométries invalides
SELECT id, ST_IsValidReason(geom) as raison
FROM parcelles
WHERE NOT ST_IsValid(geom);

-- Compter les entités par type pour détecter une corruption
SELECT ST_GeometryType(geom), COUNT(*)
FROM parcelles
GROUP BY ST_GeometryType(geom);

RGPD et données de géolocalisation

Techniques d'anonymisation spatiale

-- Purge automatique des positions GPS > 90 jours
CREATE OR REPLACE FUNCTION purge_positions_anciennes() RETURNS void AS $$
BEGIN
  DELETE FROM positions_gps
  WHERE horodatage < NOW() - INTERVAL '90 days';
END;
$$ LANGUAGE plpgsql;

-- Planification via pg_cron
SELECT cron.schedule('purge-positions', '0 3 * * *', 'SELECT purge_positions_anciennes()');

Versioning et historique des données géospatiales

-- Schéma de versionning géospatial manuel
CREATE TABLE parcelles_historique (
  id              SERIAL PRIMARY KEY,
  parcelle_id     INTEGER NOT NULL,
  geom            GEOMETRY(Polygon, 4326) NOT NULL,
  attributs       JSONB,
  valid_from      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  valid_to        TIMESTAMPTZ,
  modifie_par     TEXT NOT NULL DEFAULT current_user,
  operation       CHAR(1) CHECK (operation IN ('I', 'U', 'D'))
);

-- État des parcelles à une date donnée
SELECT * FROM parcelles_historique
WHERE valid_from <= '2025-01-01'
  AND (valid_to IS NULL OR valid_to > '2025-01-01');

# Versionner un fichier GeoParquet avec DVC
dvc init
dvc remote add -d s3remote s3://mon-bucket/dvc-storage

dvc add france_parcelles_2026.parquet
git add france_parcelles_2026.parquet.dvc .gitignore
git commit -m "feat: mise à jour parcelles 2026"
dvc push

Partie 9 — Guide décisionnel complet

Ce guide synthétise les enseignements des parties précédentes en outils directement utilisables : matrice d'usage, arbre de décision, comparatif de coûts réels et cinq scénarios architecturaux bout en bout.

9.1 Matrice d'usage

9.2 Arbre de décision

9.3 Comparatif coûts réels 2026

Tarifs de référence stockage objet 2026

9.4 Cinq scénarios architecturaux

Partie 10 — Architectures de référence 2026

Quatre stacks types, calibrées par profil de projet. Chaque stack est opérationnelle telle quelle et peut être adaptée selon les contraintes d'infrastructure.

Figure 5 — Les quatre architectures de référence 2026

Partie 11 — Tendances 2030

Les technologies décrites dans ce livre blanc ne sont pas figées. Cinq dynamiques structurantes dessinent le paysage du stockage géospatial à l'horizon 2030.

GeoParquet comme standard universel du vecteur cloud

GeoParquet 1.0 est stable depuis septembre 2023. Overture Maps publie l'intégralité de ses données en GeoParquet, GDAL 3.5+ supporte le format nativement en lecture/écriture, GeoPandas, DuckDB et Spark Sedona en font un format de première classe. Deux limitations actuelles freinent l'adoption totale : pas de transactions natives (Delta Lake et Apache Iceberg adressent ce point, mais ajoutent de la complexité) ; pas d'index spatial dédié (GeoParquet 1.1 introduit la covering column bbox, un index spatial complet reste à standardiser). Horizon 2027 : GeoParquet probable standard OGC officiel, adoption généralisée dans QGIS 4.x et GRASS GIS.

DuckDB comme ETL géospatial de référence

DuckDB 1.x (stable depuis juin 2024) s'impose comme le moteur ETL géospatial sans infrastructure. Son extension spatial couvre l'essentiel des fonctions GDAL/OGR en SQL pur. Deux limites à surveiller : mono-nœud (au-delà de 500 Go, Spark Sedona reste nécessaire) ; DuckDB-WASM + spatial non encore pleinement supporté. Horizon 2027–2028 : DuckDB-WASM spatial mature, analytique géospatiale navigateur viable sur des datasets < 1 Go stockés sur S3/R2.

La convergence PostGIS / analytique

PostGIS reste irremplaçable sur le transactionnel, mais la pression des cas d'usage analytiques pousse à des hybridations : AlloyDB (Google Cloud, moteur columnar adaptatif + PostGIS, hybride OLTP/OLAP, en production générale depuis 2023) ; pg_duckdb (intégration DuckDB dans PostgreSQL, en forte croissance en 2026) ; PostGIS + Parquet FDW (requêtes SQL PostGIS lisant directement des GeoParquet S3 via Foreign Data Wrapper, expérimental en 2026). L'objectif : un seul moteur PostgreSQL capable de gérer transactions géospatiales ET analytique columnar.

Delta Lake et l'ACID sur les lacs de données géospatiaux

L'immutabilité de GeoParquet est un blocage pour les pipelines avec mises à jour fréquentes. En 2026, Delta Lake et Apache Iceberg coexistent avec des bases d'adoption différentes : Delta Lake dominant dans les environnements Databricks et Azure Synapse ; Apache Iceberg en progression rapide sur AWS (Athena, Glue, S3 Tables) et les stacks multi-cloud. La question ouverte pour 2030 : l'un des deux s'imposera-t-il comme standard universel, ou les deux coexisteront-ils via des couches d'interopérabilité (Apache XTable) ?

Le stockage objet comme nouveau paradigme central

S3, R2 et Azure Blob Storage deviennent les backends de référence de tout le stockage géospatial analytique. Coût au Go 10 à 50× inférieur à un disque attaché à une VM, scalabilité infinie, egress gratuit sur Cloudflare R2, intégration native avec les moteurs analytiques. Conséquence pour les architectures SIG : la séparation stockage / calcul devient le modèle dominant — le stockage objet stocke, le moteur analytique calcule à la demande, sans serveur dédié permanent.

Synthèse — Solutions à surveiller d'ici 2030

Conclusion

Le stockage géospatial a traversé en 25 ans une transformation radicale. Du Shapefile multi-fichiers de 1993, limité par une architecture 32 bits et conçu pour un usage desktop mono-utilisateur, au GeoParquet columnar hébergé sur Cloudflare R2 sans aucune infrastructure dédiée — le chemin est considérable.

Références et ressources

Bases de données spatiales

• PostGIS : postgis.net · Documentation : postgis.net/docs
• SpatiaLite : gaia-gis.it
• TimescaleDB : timescale.com
• AlloyDB (Google Cloud) : cloud.google.com/alloydb
• pg_duckdb : github.com/duckdb/pg_duckdb

Formats cloud-native

• GeoParquet spec : geoparquet.org
• COG spec : cogeo.org
• PMTiles spec : github.com/protomaps/PMTiles
• FlatGeobuf : flatgeobuf.org
• GeoPackage OGC : geopackage.org

Moteurs analytiques

• DuckDB : duckdb.org · Extension spatial : duckdb.org/docs/extensions/spatial
• Apache Sedona : sedona.apache.org
• GDAL/OGR : gdal.org

Stockage objet et cloud

• Cloudflare R2 : developers.cloudflare.com/r2
• Delta Lake : delta.io
• Apache Iceberg : iceberg.apache.org

Catalogues et standards

• STAC Spec : stacspec.org
• Overture Maps : overturemaps.org
• OGC Standards : ogc.org/standards

Standards historiques et formats classiques

• GeoTIFF spec : geotiff.maptools.org/spec/geotiffhome.html
• ESRI Shapefile tech description : esri.com — shapefile.pdf

Outils ETL et génération

• cogeo-mosaic : github.com/developmentseed/cogeo-mosaic
• Tippecanoe (Felt) : github.com/felt/tippecanoe
• Planetiler : github.com/onthegomap/planetiler
• DVC : dvc.org

Glossaire

ACID

Atomicity, Consistency, Isolation, Durability. Les quatre propriétés garantissant la fiabilité des transactions en base de données.

BKD-tree

Block KD-tree. Index k-dimensionnel utilisé par Elasticsearch pour les geo_shape depuis la v7.x. Meilleure précision (~1e-7°) et meilleures performances mémoire que le prefix tree.

COG (Cloud Optimized GeoTIFF)

GeoTIFF dont la structure interne permet un accès partiel via HTTP Range Requests depuis un stockage objet distant.

Columnar

Mode de stockage où les données d'une même colonne sont contiguës sur disque (opposé au row-oriented). Avantageux pour l'analytique — lecture de colonnes sélectives sur grands volumes.

EPSG / IOGP

Registre de systèmes de référence de coordonnées géographiques maintenu par l'IOGP. EPSG:4326 = WGS84, EPSG:2154 = Lambert 93 France métropolitaine.

Egress

Données sortant d'un datacenter vers Internet. Coût caché sur AWS S3 (0,09 $/Go), gratuit sur Cloudflare R2.

FlatGeobuf

Format binaire vecteur basé sur FlatBuffers, avec index Hilbert R-Tree intégré. Support natif des HTTP Range Requests pour l'accès spatial partiel sans serveur.

GeoArrow

Encodage natif des géométries dans Apache Arrow et Parquet. Alternative à WKB, plus efficace pour l'analytique vectorisée. Intégré dans GeoParquet v1.1.

GeoPackage

Format SQLite standardisé OGC (v1.0 : février 2014) pour stocker vecteur, raster et métadonnées dans un fichier unique. Successeur naturel du Shapefile.

GeoParquet

Spécification de stockage de données vecteur géospatiales dans Apache Parquet. Version stable 1.0 : septembre 2023.

Geohash

Encodage d'une position géographique en chaîne alphanumérique. Utilisé par Redis GEO (52 bits) et comme stratégie de partitionnement GeoParquet.

GiST (Generalized Search Tree)

Framework d'index extensible de PostgreSQL. Utilisé par PostGIS pour construire les index R-Tree spatiaux sur les colonnes géométriques.

HTTP Range Requests

Mécanisme HTTP permettant de requêter un sous-ensemble d'octets d'une ressource distante. Fondement des formats COG, FlatGeobuf et PMTiles.

PITR (Point-In-Time Recovery)

Capacité à restaurer une base de données dans l'état exact à un instant précis dans le passé, grâce au WAL archiving.

PMTiles

Format d'archive de tuiles cartographiques dans un fichier unique, conçu pour le stockage objet (S3/R2). V3 stable : octobre 2022.

PostGIS

Extension spatiale pour PostgreSQL. Première version : mai 2001 (Refractions Research, Dave Blasby et Paul Ramsey). Version stable 2026 : 3.5.x.

R-Tree

Structure d'index spatial organisant les géométries dans une hiérarchie de bounding boxes imbriquées. Base de l'index GiST PostGIS et de l'extension rtree SQLite.

RLS (Row-Level Security)

Mécanisme PostgreSQL filtrant les lignes visibles d'une table selon des politiques basées sur l'utilisateur courant. Clé pour la sécurité géospatiale multi-zones.

Shapefile

Format vecteur multi-fichiers ESRI (ArcView 2, 1993). Omniprésent par inertie malgré ses limitations : limite 2 Go, noms de colonnes tronqués à 10 caractères, pas de transactions.

STAC (SpatioTemporal Asset Catalog)

Spécification ouverte pour cataloguer les assets géospatiaux (COG, GeoParquet, LiDAR). Sprint fondateur : octobre 2017. Version 1.0 : 25 mai 2021.

WAL (Write-Ahead Log)

Journal des transactions PostgreSQL. Son archivage continu permet le PITR et la réplication logique.

WKB (Well-Known Binary)

Format binaire standardisé OGC pour encoder les géométries. Utilisé par PostGIS, GeoParquet (encodage par défaut) et les APIs géospatiales.

Z-order (Courbe de Morton)

Fonction mappant des coordonnées 2D à une courbe 1D en préservant la localité spatiale. Utilisé pour ordonner et partitionner les GeoParquet afin d'optimiser les requêtes spatiales.

Historique des révisions

À propos de l'auteur

Mattieu Pottier est consultant indépendant en transformation digitale, spécialisé dans les ERP (Odoo V18/V19), les systèmes d'information géographique (QGIS, développement QGIS), et les applications web (WordPress, FastAPI, Python, JavaScript). Il intervient sous la marque MP-i — Mattieu Pottier Indépendant auprès d'organisations souhaitant intégrer des outils open source dans leurs processus métier.

La trilogie de livres blancs techniques MP-i répond à un besoin terrain récurrent : disposer d'une référence synthétique, factuellement vérifiable et architecturalement actionnable sur la chaîne complète des données géospatiales — du format de stockage à l'exposition web.

Mattieu Pottier

Consultant SI indépendant — MP-i

Expert SIG, architecture système et Odoo. J'aide les collectivités, PME et bureaux d'études à construire des systèmes d'information calibrés sur leurs besoins réels — sans surcoût ni dépendance éditeur.

Volume suivant — LB3

Exposer la donnée géospatiale sur le Web (1993–2026)

→