Exposer la donnée géospatiale sur le web : serveurs, APIs, tuiles et architectures

On choisit les formats avec soin, on réfléchit longuement au moteur de stockage — et puis la donnée est là, propre, indexée, requêtable — et on règle la question de l'exposition en quelques heures. Un GeoServer posé rapidement, un endpoint WMS configuré par défaut, et on passe à autre chose. Le résultat est souvent fonctionnel. Il est rarement optimal. Cet article couvre les six familles d'exposition géospatiale, trente ans d'évolution en quatre ères, et donne un guide décisionnel actionnable pour choisir la bonne architecture en 2026 — que vous partiez de PostGIS, de GeoParquet ou d'un simple jeu de données statique.

Pourquoi l'exposition est une décision architecturale

Stocker la donnée géospatiale dans PostGIS ou GeoParquet résout le problème du backend. Mais la donnée n'a de valeur que lorsqu'elle est consommée — par un navigateur, une application mobile, un pipeline analytique ou un rapport PDF. La couche d'exposition est le pont entre le backend de stockage et le consommateur final. Et ce pont conditionne tout le reste.

Choisir le mauvais mode d'exposition provoque des effets concrets et coûteux. Un WMS générant des images PNG à la demande là où des tuiles vectorielles pré-calculées auraient rendu la même carte dix fois plus vite. Un tile server dynamique qui sature à 50 requêtes simultanées là où PMTiles sur CDN aurait absorbé un million de requêtes par jour. Un serveur dédié à 80 €/mois là où un fichier PMTiles sur Cloudflare R2 aurait coûté moins d'un euro. Une incompatibilité client — servir du MVT à Leaflet qui ne le supporte pas nativement, ou configurer un WMS pour MapLibre qui attend du MVT.

La chaîne complète : du stockage à l'écran

LB1 a établi les formats — le substrat. LB2 a établi les moteurs de stockage — le backend. Cet article couvre les trois couches intermédiaires : le service (ce qui répond aux requêtes HTTP), le style et ses assets (style GL JSON, sprites, glyphs), et le rendu client (le moteur JavaScript dans le navigateur).

Les 6 familles d'exposition géospatiale

Avant tout choix d'outil, il faut une grille de lecture. Les modes d'exposition géospatiale se répartissent en six grandes familles, chacune avec ses contraintes propres de latence, de volumétrie, d'interactivité et de coût.

Les 5 critères de choix

30 ans en 4 ères

Ère 1 (1993–2004) — Les serveurs cartographiques

Au milieu des années 1990, exposer une carte sur le web est une entreprise technique non triviale. Le serveur fait tout le travail de rendu, le navigateur reçoit une image. C'est dans ce contexte que naissent les deux piliers qui domineront l'exposition cartographique institutionnelle pendant vingt ans.

MapServer (1994, Université du Minnesota) est un script C qui génère des appels de rendu via une configuration déclarative — le Mapfile. Chaque requête HTTP déclenche l'exécution d'un processus C qui charge les données, effectue le rendu et retourne une image PNG. Toujours maintenu en 2026 (v8.4, janvier 2025), il occupe une niche stable dans les portails legacy et les contextes où la performance brute prime.

GeoServer (2001, The Open Planning Project, New York) adopte une philosophie radicalement différente : une application web Java avec interface d'administration graphique, conçue comme référence d'implémentation WFS. C'est lui qui structure encore en 2026 les portails INSPIRE européens.

La directive européenne INSPIRE (2007), en rendant obligatoire la publication de données géographiques via WMS et WFS conformes, a créé un marché institutionnel pour ces deux outils qui perdure en 2026 — indépendamment de l'émergence d'alternatives plus modernes.

Ère 2 (2005–2013) — Le tuilage XYZ et le web cartographique

Le 8 février 2005, Google Maps est lancé aux États-Unis. Ce n'est pas simplement un nouveau service de cartographie — c'est une rupture architecturale. Deux innovations conjointes créent l'expérience de la "slippy map" : le tuilage précalculé (la carte mondiale découpée en millions d'images 256×256 px organisées par niveau de zoom) et le chargement AJAX asynchrone. Le schéma d'adressage /{z}/{x}/{y}.png devient un standard de facto sans jamais avoir fait l'objet d'une spécification OGC formelle.

Cette rupture engendre immédiatement les tile caches : TileCache (2006), MapProxy (2009-2010) — un proxy interposé devant un WMS existant qui le transforme en source de tuiles XYZ cachables sur CDN. En 2026, MapProxy reste pertinent pour les architectures hybrides qui maintiennent la compatibilité avec des WMS institutionnels legacy tout en exposant des tuiles XYZ modernes.

Côté client, deux bibliothèques structurent cette période. OpenLayers (2006, MetaCarta) vise l'exhaustivité des standards OGC — WMS, WFS, WMTS, OGC API. Leaflet (2011, Volodymyr Agafonkin) adopte l'approche inverse : faire bien le travail essentiel en 42 Ko, sans ambition OGC. Les deux restent pertinents en 2026, dans des niches différentes.

Ère 3 (2014–2019) — Tile servers modernes et APIs REST

L'arrivée de WebGL stable dans les navigateurs (fin 2013) provoque une rupture fondamentale. Si le rendu est délégué au GPU du client, le serveur n'a plus besoin de générer des images — il lui suffit d'envoyer des données vectorielles brutes encodées de façon compacte. Naît l'architecture en trois couches découplées : stockage (PostGIS), service (tile server léger), rendu (client WebGL).

Le point de jonction est ST_AsMVT, introduite dans PostGIS 2.4 (2017). Cette fonction génère directement des tuiles MVT depuis une requête SQL — PostGIS devient à la fois moteur de stockage et moteur de sérialisation. C'est la fondation technique de tous les tile servers modernes.

Martin v1.0.0 a été publié le 19 novembre 2025, après huit ans de développement et plus de 80 contributeurs. C'est le signal de maturité le plus clair de l'écosystème tile server open source. Côté APIs REST, pygeoapi (2018, certifié OGC en 2020) s'impose comme implémentation Python de référence pour OGC API Features — le successeur REST moderne de WFS, publié par l'OGC en 2019.

Ère 4 (2020–2026) — Serverless et cloud-native

La quatrième rupture ne vient pas d'un nouveau format ou d'un nouveau moteur — elle vient de l'élimination du serveur lui-même. PMTiles v3 (octobre 2022, Brandon Liu / Protomaps) est une archive binaire organisée selon la courbe de Hilbert, accessible directement par le navigateur via HTTP Range Requests depuis un stockage objet. Deux requêtes HTTP suffisent pour récupérer n'importe quelle tuile d'un fichier PMTiles couvrant un pays ou une région.

PMTiles est format-agnostique : le même conteneur peut accueillir des tuiles MVT, MLT (MapLibre Tile, spécification stable octobre 2025, annonce publique 23 janvier 2026) ou raster. MLT est un format à encodage column-oriented qui offre une compression jusqu'à 6× supérieure à MVT et des transferts CPU→GPU plus efficaces pour WebGPU. Son support est disponible dans MapLibre GL JS depuis la version 5.12 (novembre 2025). Côté génération, Planetiler intégrera MLT dans une prochaine release — l'écosystème n'est pas encore complet mais la direction est claire.

Moteurs de rendu client et implications serveur

Le choix du moteur de rendu client n'est pas un détail frontend. Il détermine les formats que le serveur doit produire — et rend inutile une infrastructure inadaptée. La règle d'or : choisir le client avant le serveur.

L'antipattern le plus fréquent : déployer Martin pour servir du MVT à un client Leaflet qui ne le supporte pas nativement. Leaflet consomme WMS, XYZ raster et GeoJSON — un tile server MVT est superflu. Inversement, configurer un WMS pour MapLibre GL JS qui attend du MVT produit une carte fonctionnelle mais dégradée en termes de performance et d'interactivité.

MapLibre GL JS s'est imposé comme moteur de référence pour les nouvelles applications self-hosted depuis le changement de licence de Mapbox GL JS en décembre 2020. Son support natif de PMTiles et MLT, combiné à sa gouvernance open source (organisation MapLibre, financement AWS et autres), en fait le choix par défaut pour toute nouvelle application cartographique web sans contrainte OGC stricte.

La souveraineté : l'angle oublié

Sur un projet récent en prestation, l'audit de conformité RGPD d'une application cartographique "100% self-hosted" révèle deux dépendances silencieuses : les fonts PBF (glyphs) chargées depuis api.mapbox.com, et les sprites depuis api.maptiler.com. Résultat : l'IP de chaque visiteur était transmise à ces deux providers à chaque chargement de carte — sans apparaître nulle part dans la politique de confidentialité. Zéro donnée métier exposée, mais traitement de données personnelles non déclaré.

Audit — Dépendances silencieuses cartographiques

• Ouvrir DevTools → Network → filtrer par domaine au chargement de la carte
• Vérifier que zéro requête part vers mapbox.com, maptiler.com, googleapis.com non déclarés
• Glyphs auto-hébergés depuis openmaptiles/fonts ou Martin
• Sprites auto-hébergées depuis openmaptiles/maptiler-basic-gl-style
• Fond de carte : OpenMapTiles PMTiles sur R2 ou MapTiler Server local

La correction est simple et sans coût : héberger les glyphs sur son propre serveur ou sur R2 (dossier statique de ~50 Mo pour les fonts open source courantes — Noto Sans, Open Sans, Roboto), et pointer le style JSON vers cette URL. Martin peut également servir les glyphs directement depuis sa configuration YAML pour une stack entièrement consolidée.

Guide décisionnel : choisir son architecture

Trois questions suffisent à orienter 90% des choix d'architecture d'exposition géospatiale. Elles se posent dans l'ordre — et la réponse à chacune peut clore le processus.

4 architectures de référence 2026

Comparatif coûts réels — exposition mensuelle

Ce qui arrive : tendances 2026–2030

MLT va progressivement compléter MVT dans les nouveaux projets haute performance. La spécification est stable (octobre 2025), MapLibre GL JS le supporte depuis v5.12, Martin sert les fichiers MLT existants. Il manque encore Planetiler stable pour la génération — attendu en 2026. La migration des productions existantes n'est pas recommandée avant stabilisation complète de l'écosystème de génération.

DuckDB-WASM ouvre une voie radicalement nouvelle : l'analytique géospatiale directement dans le navigateur, sans serveur, en interrogeant des fichiers GeoParquet depuis S3 ou R2 via HTTP Range Requests. Encore expérimental mais fonctionnel, c'est une piste sérieuse pour les tableaux de bord analytiques sans infrastructure backend.

WebGPU est disponible depuis Chrome 113 (mai 2023) et Safari 26 (automne 2025). MapLibre GL JS explore activement un backend WebGPU qui offrirait de meilleures performances pour les rendus complexes et les compute shaders géospatiaux. L'impact sur les architectures d'exposition sera surtout côté format — MLT et son encodage column-oriented est optimisé pour les transferts CPU→GPU de WebGPU.

OGC API Tiles (standard approuvé novembre 2022) gagne en adoption dans les nouvelles implémentations GeoServer et pygeoapi. Sa séparation protocole/format permet de migrer de MVT à MLT côté serveur sans modifier les clients — un argument architectural décisif pour les projets à long terme.

📘

Livre Blanc LB3 complet — Exposer la donnée géospatiale sur le web

Sécurité, CORS, RLS multi-tenant, DuckDB-WASM, rendu SSR, SaaS comparatif · Distribution libre

↓