La question du stockage géospatial arrive presque toujours en dernier. On choisit un format, on construit une carte, on expose une API — et le où stocker se règle dans l'urgence, souvent par défaut. C'est une erreur qui se paie cher, parfois plusieurs années plus tard, quand une refonte complète d'infrastructure devient inévitable.
Pourquoi le stockage géospatial n'est pas un détail d'infrastructure
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.
Choisir le mauvais moteur de stockage, c'est potentiellement : un scan complet de 2 Go pour trouver des entités dans une bounding box, un GeoPackage verrouillé en écriture dès que deux utilisateurs travaillent simultanément, ou une dette technique impossible à résorber sans migration complète.
Quelle volumétrie ? Quel usage dominant (édition, analytique, distribution) ? Quelle infrastructure disponible ? Ce sont ces trois axes qui structurent le guide décisionnel du livre blanc.
Quatre ruptures technologiques en 55 ans
L'histoire du stockage géospatial est celle de quatre ruptures successives, chacune déclenchée par une limite fondamentale du paradigme précédent.
1970–1999
Le fichier comme paradigme — Shapefile, GeoTIFF
ESRI publie le Shapefile en 1993. Format d'interopérabilité devenu standard mondial par inertie. Architecture multi-fichiers, limite 2 Go, pas de transactions. GeoTIFF apporte le référencement spatial au raster, mais sans accès partiel depuis un stockage distant.
2000–2009
La base de données spatiale — PostGIS, SpatiaLite
PostGIS paraît en mai 2001. Transactions ACID, index GiST spatial, 800+ fonctions géométriques. Pour la première fois, la donnée géospatiale bénéficie d'un moteur relationnel éprouvé. SpatiaLite (2008) apporte la même logique en mode embarqué sur SQLite.
2010–2019
Formats modernes et NoSQL — GeoPackage, FlatGeobuf, MongoDB
GeoPackage (OGC, 2014) remplace le Shapefile sans ses limitations. FlatGeobuf invente l'accès spatial partiel via HTTP Range. L'écosystème NoSQL ouvre des cas d'usage spécifiques : IoT géolocalisé, recherche textuelle + proximité, cache temps réel.
2020–2026
Cloud-native analytique — GeoParquet, DuckDB, COG
GeoParquet 1.0 stable en septembre 2023. DuckDB 1.0 en juin 2024. Le stockage columnar sur objet cloud (S3/R2) rend possible l'analyse géospatiale à grande échelle sans infrastructure dédiée, pour un coût proche de zéro.
Les cinq familles de stockage : taxonomie opérationnelle
Le livre blanc propose une taxonomie en cinq familles, transversale aux formats et moteurs. C'est la grille de lecture la plus utile pour orienter un choix architectural avant d'aller dans le détail technique.
Famille 1
Fichier vecteur plat
Shapefile · GeoJSON
GeoPackage · FlatGeobuf
Famille 2
Fichier raster
GeoTIFF · COG
MBTiles · NetCDF
Famille 3
BDD relationnelle spatiale
PostGIS · SpatiaLite
Oracle Spatial
Famille 4
NoSQL géospatial
MongoDB · Elasticsearch
Redis GEO · TimescaleDB
Famille 5
Analytique cloud-native
GeoParquet · DuckDB
Delta Lake · BigQuery Geo
La plupart des projets démarrent avec PostGIS parce que c'est ce qu'on connaît. C'est souvent le bon choix — mais pas toujours. Un pipeline analytique batch sur 50 millions d'entités n'a pas besoin d'un serveur PostgreSQL à 40 €/mois quand DuckDB + GeoParquet sur R2 répond au même besoin pour moins d'1 €.
PostGIS : toujours la colonne vertébrale
Vingt-cinq ans après sa première version, PostGIS reste le choix de référence pour la grande majorité des projets SIG. La raison est simple : aucun autre moteur open source n'offre la combinaison transactions ACID + index GiST spatial éprouvé + 800+ fonctions géométriques + écosystème SIG universel.
La version 3.5.x (2026) maintient cette position avec trois types d'index spatiaux complémentaires :
| Index | Structure | Usage recommandé |
|---|---|---|
GiST |
R-Tree sur bounding boxes | Choix par défaut — ST_Intersects, ST_DWithin, ST_Contains |
SP-GiST |
Partitionnement quadtree / kd-tree | Distributions très non-uniformes |
BRIN |
Index léger par plages de blocs | Tables très larges, import séquentiel géographique |
Les requêtes indexées sur PostGIS répondent en moins de 200 ms pour des intersections spatiales sur des dizaines de millions d'entités. Là où PostGIS perd l'avantage, c'est sur les scans analytiques massifs : une agrégation sur 10 millions d'entités peut prendre 15 à 60 secondes là où GeoParquet + DuckDB répond en 1 à 5 secondes.
GeoParquet et DuckDB : le tournant analytique de 2023–2024
La publication de GeoParquet 1.0 en septembre 2023 et de DuckDB 1.0 en juin 2024 marque une rupture réelle dans l'écosystème géospatial. Ces deux technologies combinées rendent possible l'analyse géospatiale à grande échelle sans aucune infrastructure dédiée.
Pourquoi le format columnar change la donne
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 des parcelles dans une région — seules deux colonnes
(geom et surface) sont lues, pas l'intégralité des 50 attributs.
Sur 10 millions d'entités, l'économie en I/O est considérable.
Recommandé
GeoParquet + DuckDB
- Scan complet 10M entités en 1–5 s
- Coût infra 50 Go : < 1 € / mois (R2)
- Zéro serveur à maintenir
- Lecture directe depuis S3/R2/HTTP
- Compatible GeoPandas, GDAL 3.5+
Limites à connaître
Ce que GeoParquet ne fait pas
- Pas d'écriture incrémentale native
- Requête indexée : 500 ms–2 s vs <200 ms PostGIS
- Pas de concurrence d'écriture
- Compatibilité QGIS encore partielle
- Mises à jour fréquentes → Delta Lake requis
GeoParquet n'est pas un remplacement de PostGIS — c'est un format complémentaire pour les cas analytiques. La bonne architecture 2026 combine les deux : PostGIS pour l'édition, l'intégrité et les requêtes indexées ; GeoParquet + DuckDB pour les pipelines analytiques et la distribution à moindre coût.
Benchmark Overture Maps France : des chiffres concrets
Le livre blanc inclut un benchmark sur les données Overture Maps France — environ 30 millions d'entités pour 8 Go de GeoParquet. Les résultats matérialisent concrètement la différence entre les deux approches :
| Requête | PostGIS (index GiST) | DuckDB + GeoParquet |
|---|---|---|
| Bâtiments département 75 (requête indexée) | ~800 ms | ~2,5 s |
| Superficie totale France (scan complet) | ~45 s | ~4 s |
La règle est claire : PostGIS gagne sur les requêtes spatiales indexées à faible cardinalité. DuckDB + GeoParquet gagne sur les scans analytiques à grande échelle. Les deux moteurs ont une place dans une architecture bien conçue.
Comparatif de coûts réels
Le livre blanc inclut un comparatif de coûts vérifiés en mars 2026, organisé par profil projet. Les chiffres ci-dessous donnent l'ordre de grandeur mensuel pour les solutions les plus courantes.
Le différentiel entre PostGIS self-hosted et les solutions cloud managées est réel et significatif dès 50 Go. Pour une collectivité ou une PME avec des contraintes budgétaires, un VPS PostGIS bien configuré reste la solution à l'équilibre optimal performances / coût / maîtrise.
Quatre architectures de référence pour 2026
Le livre blanc propose quatre architectures calibrées selon la taille de structure et le contexte d'usage. Voici leur synopsis :
Stack PME / Startup
20–50 € / mois
- PostgreSQL + PostGIS 3.5
- GeoParquet sur Cloudflare R2
- COG sur R2 (raster)
- DuckDB + GDAL/OGR (ETL)
- pg_dump + WAL archiving
Stack Institutionnelle
50–200 € / mois
- PostGIS self-hosted (EU)
- GeoPackage + legacy Shapefile
- GeoNetwork (ISO 19115)
- RLS PostgreSQL + rôles métier
- LUKS + WAL archiving
Stack Cloud-native
200–800 $ / mois
- GeoParquet sur Cloudflare R2
- DuckDB + Spark Sedona
- AlloyDB / RDS + PostGIS
- COG + STAC sur R2
- PMTiles sur R2 + CDN
Stack Big Data
500–2 000 $ / mois
- Spark + Sedona (distribué)
- GeoParquet + Delta Lake (S3)
- DuckDB / Athena selon volume
- PostGIS (source de vérité)
- Airflow / Prefect (orchestration)
Sécurité, RGPD et gouvernance
Les coordonnées GPS sont des données personnelles
Les coordonnées GPS sont des données personnelles au sens du RGPD dès qu'elles permettent d'identifier directement ou indirectement un individu. Trois techniques d'anonymisation spatiale sont documentées dans le livre blanc : le floutage (déplacement aléatoire dans un rayon donné, à opérer en Lambert 93 pour un résultat métrique correct), l'agrégation spatiale par maille IRIS ou carreaux 200 m, et le k-anonymat spatial.
Row-Level Security PostGIS
PostgreSQL intègre un mécanisme de Row-Level Security (RLS) qui permet de filtrer les lignes visibles d'une table selon l'utilisateur connecté — utile pour les portails multi-collectivités où chaque organisation ne doit voir que ses propres entités géographiques. Le livre blanc donne les patterns SQL complets pour la mise en place.
AWS S3 facture l'egress à environ 0,09 $/Go. Pour un portail cartographique à fort trafic, ce poste peut rapidement dépasser le coût du stockage lui-même. Cloudflare R2 offre l'egress gratuit — un avantage décisif pour les architectures de distribution géospatiale à grande échelle.
Ce que ça change selon votre contexte
Le guide décisionnel complet est dans le livre blanc. Voici les orientations rapides selon les situations les plus fréquentes :
| Contexte | Volume | Solution recommandée | Priorité |
|---|---|---|---|
| SIG desktop, échange de fichiers | < 500 Mo | GeoPackage |
Remplace Shapefile |
| Application web collaborative | Toute volumétrie | PostGIS |
Référence |
| ETL / analytique batch | Grand volume | DuckDB + GeoParquet |
Coût < 1 €/mois |
| IoT géolocalisé haute fréquence | Élevé, temps réel | TimescaleDB + PostGIS |
Spécialisé |
| Fond de carte vectoriel statique | Planet-scale | GeoParquet → PMTiles |
Pipeline nécessaire |
| Catalogue raster cloud | Variable | COG sur S3/R2 + STAC |
Standard 2026 |
| Lac de données, mises à jour fréquentes | Grand volume | Delta Lake + GeoParquet |
Complexité élevée |
Les tendances à horizon 2030
GeoParquet comme standard universel du vecteur cloud. L'adoption par Overture Maps, GDAL 3.5+, GeoPandas et DuckDB est en cours. La limitation actuelle — pas de transactions natives — sera adressée par Delta Lake et Apache Iceberg. Un standard OGC officiel est probable en 2027.
DuckDB comme ETL géospatial de référence. Moteur analytique in-process, sans serveur, lecture directe depuis S3 et HTTP. La contrainte reste le mono-nœud : au-delà de 500 Go, Spark Sedona prend le relais.
La convergence PostGIS / analytique. AlloyDB (columnar adaptatif + PostGIS) et pg_duckdb (DuckDB dans PostgreSQL) représentent la tendance la plus intéressante à horizon 2026–2027 : un seul moteur pour les usages transactionnels et analytiques géospatiaux.
Le stockage objet comme paradigme central. Coût 10 à 50 fois inférieur au disque attaché, scalabilité infinie, egress gratuit sur Cloudflare R2. Tous les formats modernes (COG, GeoParquet, PMTiles, FlatGeobuf) sont conçus pour fonctionner nativement sur stockage objet.
— Conclusion du Livre Blanc MP-i n°2
Ce que je retiens — et pourquoi j'ai écrit ce document
La question du stockage géospatial est structurellement sous-documentée pour les praticiens. La documentation officielle des outils est exhaustive sur le comment — elle ne dit presque rien sur le pourquoi choisir tel moteur plutôt qu'un autre dans tel contexte.
Ce livre blanc est né de missions concrètes : des collectivités qui démarrent un projet SIG sans avoir jamais posé la question de l'architecture de stockage, des PME qui utilisent PostGIS pour des usages qui ne nécessitent pas de serveur, des projets analytiques qui souffrent de performances médiocres parce que le moteur choisi n'était pas adapté au volume.
Il n'y a pas de solution universelle. Il y a des contextes, des contraintes, des usages — et des outils adaptés à chacun. C'est ce que ce document essaie de formaliser, avec des chiffres réels et des architectures testées en production.
PostGIS reste la colonne vertébrale pour tout projet d'édition collaborative. GeoParquet + DuckDB sur R2/S3 est la solution 2026 pour l'analytique à moindre coût. La bonne architecture combine les deux selon les usages — et rarement une seule famille de stockage suffit.