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. Ce troisième volume de la collection « Chaîne de la donnée géospatiale » s'attaque à cette couche trop souvent sous-estimée : comment servir la donnée géospatiale sur le web, architecturalement — pas seulement techniquement. En trente ans, la couche d'exposition a subi quatre ruptures aussi profondes que celles des formats et du stockage.

Préface

Il existe un paradoxe récurrent dans les projets SIG : 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 — 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.

Ce troisième volume de la collection « Chaîne de la donnée géospatiale » s'attaque à cette couche trop souvent sous-estimée : comment servir la donnée géospatiale sur le web. Non pas techniquement — les outils sont documentés — mais architecturalement : pourquoi tel serveur plutôt qu'un autre, quelles sont les contraintes réelles de performance et de coût, et surtout, comment la couche d'exposition articule les décisions prises dans LB1 (les formats) et LB2 (le stockage) avec ce que le client JavaScript va réellement recevoir et rendre.

En trente ans, la couche d'exposition a subi quatre ruptures aussi profondes que celles des formats et du stockage. En 1994, exposer une carte sur le web signifiait faire tourner un script CGI en C sur un serveur Unix et envoyer une image GIF ou JPEG par requête HTTP. En 2026, la même carte peut être servie depuis un fichier unique hébergé sur un CDN Cloudflare, sans aucun serveur applicatif, avec un rendu GPU directement dans le navigateur du visiteur. La trajectoire entre ces deux points est l'objet de ce document.

Ce livre blanc suppose la lecture de LB1 et LB2. Les formats (substrat) et le stockage (backend) ne sont pas redécrits ici — des renvois précis permettent de retrouver le détail dans les volumes précédents. LB3 se concentre exclusivement sur les couches service, style et exposition.

Mattieu Pottier

Consultant en transformation digitale — SIG, géomatique, Web, ERP Odoo

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.

Introduction — 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, c'est potentiellement :

• Des performances dégradées — 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
• Une scalabilité plafonnée — un tile server dynamique qui sature à 50 requêtes simultanées là où PMTiles sur CDN aurait absorbé un million de requêtes/jour sans sueur
• Un coût disproportionné — un serveur dédié à 80 €/mois là où un fichier PMTiles sur Cloudflare R2 aurait coûté moins d'un euro
• Une dette de souveraineté — des dépendances silencieuses vers des CDN Mapbox ou Maptiler qui envoient les IPs de vos utilisateurs à des providers tiers, invisibles dans le code JavaScript
• Une incompatibilité client — servir du MVT à un client Leaflet qui ne le supporte pas nativement, ou configurer un tile server qui génère du WMS à un client MapLibre qui ne sait pas le rendre

La chaîne complète : de LB2 à LB3

LB1 a établi les formats — le substrat. LB2 a établi les moteurs de stockage — le backend. LB3 couvre les trois couches intermédiaires.

Articulation avec LB2 — de chaque scénario de stockage à son exposition

Les quatre questions fondamentales

Partie 1 — Taxonomie des modes d'exposition

Avant d'entrer dans le détail historique, il est indispensable de disposer d'une grille de lecture commune. Les modes d'exposition géospatiale se répartissent en six grandes familles, chacune avec ses contraintes propres.

1.1 Les six grandes familles

1.2 Les 5 critères de choix

1.3 Matrice synthétique famille × critères

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

Au milieu des années 1990, exposer une carte sur le web est une entreprise technique non triviale. Le web grand public est naissant, HTTP 1.0 date de 1996, et les navigateurs ne savent rien faire d'autre qu'afficher du HTML statique et des images. La cartographie web repose entièrement sur un paradigme simple : le serveur fait tout le travail de rendu, le navigateur reçoit une image.

MapServer (1994 — UMN ForNet / NASA)

MapServer naît en 1994 à l'Université du Minnesota (UMN), dans le cadre d'un projet de recherche financé par la NASA et le Minnesota Department of Natural Resources : le projet ForNet. Le premier programme est un script C qui génère des appels ArcPlot, avec des temps de rendu de l'ordre de 30 secondes par requête. En 1995, le passage à la bibliothèque GD pour la génération d'images marque un bond de performance. MapServer fonctionne selon le modèle CGI : chaque requête HTTP déclenche l'exécution d'un processus C qui lit un Mapfile, charge les données spatiales, effectue le rendu en mémoire, et retourne une image PNG ou JPEG.

MAP
  NAME "exemple"
  STATUS ON
  SIZE 800 400
  EXTENT -5.5 41.0 10.0 51.5
  PROJECTION
    "init=epsg:4326"
  END
  LAYER
    NAME "departements"
    TYPE POLYGON
    DATA "/data/departements.shp"
    STATUS ON
    CLASS
      STYLE
        COLOR 200 200 200
        OUTLINECOLOR 100 100 100
      END
    END
  END
END

Statut 2026 : MapServer est toujours maintenu activement (version 8.4, janvier 2025). Il occupe une niche stable dans les portails cartographiques institutionnels et les projets legacy. Écrit en C, il reste l'un des moteurs de rendu cartographique les plus rapides disponibles.

GeoServer (2001 — The Open Planning Project)

GeoServer naît en 2001 à New York, au sein de The Open Planning Project (TOPP). Contrairement à MapServer, il est conçu comme un serveur de données géospatiales interopérable, dont la vocation est de publier des données en open access via des standards OGC. Application web Java (J2EE) déployable dans Tomcat, GeoServer dispose d'une interface d'administration web complète et est l'implémentation de référence du standard WFS de l'OGC.

Les standards OGC — WMS, WFS, WMTS

L'OGC publie dans cette période les trois standards fondateurs de l'exposition cartographique web normalisée.

Partie 3 — Ère 2 : Le web cartographique et les tile servers (2005–2013)

Le 8 février 2005, Google Maps est lancé aux États-Unis. Ce n'est pas simplement un nouveau service de cartographie en ligne : c'est une rupture architecturale qui va transformer l'ensemble de l'écosystème géospatial web pour les vingt années suivantes.

Google Maps et la révolution du tuilage (2005)

Google Maps introduit deux innovations conjointes qui créent l'expérience de la "slippy map" : le tuilage précalculé (la carte mondiale découpée en millions de petites images 256×256 px organisées en niveaux de zoom XYZ) et le chargement AJAX asynchrone (les tuiles se chargent en arrière-plan sans rechargement de page). Le schéma d'adressage /{z}/{x}/{y}.png devient un standard de facto mondial — jamais formalisé par l'OGC, mais adopté par OpenStreetMap depuis 2007 et tous les frameworks cartographiques.

TileCache, TileStache, MapProxy — les premiers tile caches

TileServer GL — les tuiles vectorielles en production

TileServer GL, développé par Jiří Koníček (MapTiler), est publié en 2016. Il prend en entrée des fichiers MBTiles ou PMTiles et génère des tuiles MVT ou des images raster, avec une interface d'administration web intégrée. C'est le premier tile server open source à servir directement des tuiles vectorielles depuis des fichiers sans dépendance à une base de données. Il expose aussi un endpoint de rendu image statique — traité en Partie 9.

Leaflet (2011) et OpenLayers

Créé par Volodymyr Agafonkin en 2011, Leaflet est une bibliothèque cartographique JavaScript légère et accessible. Son architecture Canvas/SVG, sans WebGL, est à la fois sa force et sa limite : excellente pour les tuiles raster XYZ, WMS natif, et GeoJSON léger ; aucun support natif MVT, MLT, ou PMTiles. Conséquence architecturale directe : choisir Leaflet comme client rend un tile server MVT architecturalement inutile. OpenLayers, plus complet et plus verbeux, supporte WMS, WFS, WMTS, OGC API, et MVT via ol/format/MVT.

Partie 4 — Ère 3 : APIs REST et tile servers modernes (2014–2019)

2014 marque une rupture double : Mapbox publie les premières spécifications MVT et le client WebGL Mapbox GL JS. La combinaison tuile vectorielle + rendu GPU côté client change le paradigme : le serveur n'a plus besoin de styliser la carte — il se contente de fournir les données géométriques brutes, le style est appliqué côté client.

pg_tileserv et Martin — la génération ST_AsMVT

-- PostGIS génère une tuile MVT depuis une table
SELECT ST_AsMVT(q, 'communes', 4096, 'geom')
FROM (
  SELECT id, nom, population,
         ST_AsMVTGeom(
           geom,
           ST_TileEnvelope(z, x, y),
           4096, 64, true
         ) AS geom
  FROM communes
  WHERE ST_Intersects(geom, ST_TileEnvelope(z, x, y))
    AND population > 0
) q;

pygeoapi — le serveur Python OGC API

pygeoapi implémente la famille complète des standards OGC API (Features, Tiles, Records, Coverages, EDR) en Python avec Flask/Starlette. Configuration YAML, certifié OGC Compliant pour OGC API Features depuis 2020. Son positionnement est complémentaire de Martin : pygeoapi gère les APIs features interactives (filtres, pagination, CQL2) là où Martin gère les tiles haute performance.

OGC API Features (2019) et OGC API Tiles (2022)

Partie 5 — Les moteurs de rendu client et leurs implications serveur

Partie 6 — Le style cartographique : sprites, glyphs et autonomie complète

Le style GL JSON décrit l'intégralité du rendu cartographique (sources de données, couches, couleurs, fonts, icônes) dans un document JSON déclaratif. Il est consommé par MapLibre GL JS et Mapbox GL JS. Mais ce style référence deux ressources servies qui sont souvent oubliées dans l'architecture : les sprites (icônes vectorielles PNG + JSON descriptor) et les glyphs (fonts PBF pour le rendu des labels).

Checklist d'autonomie complète — zéro dépendance externe

Maputnik est l'éditeur visuel de référence pour les styles GL JSON — application React statique auto-hébergeable, avec prévisualisation temps réel, connexion à Martin ou PMTiles local, et export JSON en un clic. Élevé au rang de projet "supported" MapLibre en 2025.

Partie 7 — Ère 4 : Serverless, Cloud-Native et CDN (2020–2026)

La quatrième rupture de l'exposition géospatiale ne vient pas d'un nouveau format ou d'un nouveau moteur de rendu — elle vient de l'élimination du serveur lui-même. L'idée que des tuiles cartographiques puissent être servies depuis un fichier statique sur un stockage objet, accessibles directement par le navigateur via HTTP Range Requests, sans aucune infrastructure applicative, représente un changement de paradigme aussi profond que le passage du WMS au tuilage XYZ en 2005.

PMTiles v3 — la tuile sans serveur

PMTiles est créé par Brandon Liu (projet Protomaps). La version 3, publiée en octobre 2022, stabilise l'approche HTTP Range Requests avec un système d'adressage en courbe de Hilbert et une déduplication interne des tuiles. Le principe : un fichier PMTiles est une archive binaire organisée en header fixe (127 octets), un répertoire d'index structuré selon la courbe de Hilbert, et les données de tuiles avec déduplication. Pour récupérer une tuile, MapLibre envoie 2 requêtes HTTP Range (3 max pour les fichiers planet-scale). PMTiles est format-agnostique : le conteneur peut héberger des tuiles MVT, MLT, ou raster PNG/JPEG/WebP.

Tippecanoe et Planetiler — les générateurs de tiles

TiTiler — les tuiles raster serverless

TiTiler (Development Seed, Python/FastAPI + Rasterio) génère des tuiles raster dynamiques depuis des COG (Cloud Optimized GeoTIFF) hébergés sur S3 ou R2, sans pré-génération. Chaque tuile est calculée à la demande par une HTTP Range Request sur le COG. Déployable en Lambda ou Cloud Run — réellement serverless. Cas d'usage : orthophotos, images satellites, cartes de chaleur, MNT.

FlatGeobuf — le vecteur cloud-native

FlatGeobuf est un format de fichier vectoriel binaire basé sur FlatBuffers, avec un index spatial R-tree intégré qui permet des HTTP Range Requests ciblées — similaire au principe COG/PMTiles mais pour les features vectorielles individuelles. Cas d'usage : distribution de données vectorielles statiques volumineuses sans tile server, avec accès bbox ciblé depuis un CDN.

Partie 8 — Big Data géospatial : DuckDB, Spark Sedona, BigQuery Geo

Le Big Data géospatial change la couche d'exposition : le moteur de requête devient directement la couche d'accès. Pas de tile server intermédiaire, pas de sérialisation MVT préalable — le client envoie une requête SQL ou un filtre, le moteur retourne un agrégat GeoJSON ou un GeoParquet filtré en réponse.

DuckDB — le moteur analytique in-process

DuckDB v1.0.0 est publié le 3 juin 2024. Son extension spatial supporte les types géométriques WKT/WKB, les fonctions ST_* usuelles (ST_Intersects, ST_Buffer, ST_Distance…), et la lecture directe de GeoParquet depuis S3 ou R2 via le connecteur HTTP. Benchmark indicatif sur 1M d'entités GeoParquet : agrégation spatiale en 4 secondes versus 45 secondes sur PostGIS sans index (requête de scan complet). PostGIS reprend l'avantage sur les requêtes indexées (<200 ms).

-- Requête DuckDB sur GeoParquet hébergé sur Cloudflare R2
LOAD spatial;

SELECT
  departement,
  COUNT(*) AS nb_parcelles,
  SUM(superficie_ha) AS superficie_totale
FROM read_parquet('https://r2.example.com/parcelles_2026.parquet')
WHERE ST_Intersects(
  geometry,
  ST_GeomFromText('POLYGON((2.0 48.5, 3.0 48.5, 3.0 49.0, 2.0 49.0, 2.0 48.5))')
)
GROUP BY departement
ORDER BY superficie_totale DESC;

Partie 9 — Rendu serveur-side (SSR) : cartes PDF et exports automatisés

Le rendu serveur-side répond à quatre cas d'usage : export PDF avec carte intégrée (rapports clients, CDC), génération de thumbnails géographiques, pipelines automatisés (cartes de situation récurrentes), et environnements sans navigateur (scripts CLI, workers Lambda).

Partie 10 — Les solutions SaaS cartographiques

Partie 11 — Sécurité, gouvernance et RGPD

CORS — prérequis fondamental

location /tiles/ {
    add_header Access-Control-Allow-Origin "https://mon-app.example.com";
    add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS";
    add_header Access-Control-Allow-Headers "Range, Content-Type";
    add_header Access-Control-Expose-Headers "Content-Range, Content-Length, ETag";
    proxy_pass http://martin:3000/;
}

Rate limiting et protection des APIs

limit_req_zone $binary_remote_addr zone=tiles:10m rate=10r/s;

server {
    location /tiles/ {
        limit_req zone=tiles burst=50 nodelay;
        proxy_pass http://martin:3000/;
    }
}

Row-Level Security (RLS) et tiles multi-tenant

Martin supporte les function layers PostGIS — des fonctions SQL qui reçoivent les paramètres Z/X/Y et tout paramètre URL supplémentaire. Ce mécanisme permet des tiles filtrées par utilisateur via RLS : le proxy d'authentification valide le JWT, extrait le user_id comme paramètre URL, et PostGIS applique le RLS via set_config('app.current_user_id', user_id, true) avant d'exécuter ST_AsMVT.

Partie 12 — Guide décisionnel complet

12.1 Matrice d'usage — cas d'usage → solution

12.2 Arbre de décision

12.3 Comparatif coûts réels — exposition et stockage combinés

12.4 Les 7 scénarios architecturaux

Partie 13 — Architectures de référence 2026

Partie 14 — Tendances 2030

Cette partie projette les trajectoires identifiables à partir de l'état de l'écosystème en mars 2026. Les horizons indiqués sont des estimations fondées sur les signaux observables — roadmaps publiées, communiqués officiels, rythme d'adoption — pas des prédictions.

Conclusion

Trente ans d'exposition géospatiale sur le web se résument en quatre ruptures architecturales successives. Chacune a rendu obsolètes les outils de la précédente, sans pour autant les éliminer complètement — les WMS institutionnels existent encore en 2026 aux côtés des PMTiles edge-native.

Ce document clôt la collection « Chaîne de la donnée géospatiale ». LB1 a établi le substrat : les formats géospatiaux et leurs compromis. LB2 a construit le backend : comment stocker la donnée géospatiale à chaque échelle. LB3 a couvert la couche finale : comment exposer cette donnée au web, avec quels outils, à quel coût, et avec quelles garanties de souveraineté.

L'écosystème continue d'évoluer rapidement — les sections sur MLT, DuckDB-WASM et WebGPU seront les premières à vieillir. Les principes architecturaux (découplage, séparation des fréquences de mise à jour, choix du client avant le serveur) sont, eux, durables.

Références

Glossaire

COG (Cloud Optimized GeoTIFF)

Format GeoTIFF réorganisé pour des lectures partielles via HTTP Range Requests. Permet de ne télécharger que la portion nécessaire d'une image depuis un stockage objet distant.

CORS

Cross-Origin Resource Sharing — mécanisme HTTP contrôlant les requêtes entre domaines. À configurer sur tout serveur de tiles accessible depuis un navigateur.

Glyphs

Fonts vectorielles encodées en Protocol Buffers (PBF) par plages de 256 caractères Unicode. Utilisées par MapLibre GL JS pour le rendu des labels via la technique SDF.

HTTP Range Requests

Mécanisme HTTP (RFC 9110) permettant de demander une plage d'octets précise d'un fichier distant. Fondement technique de PMTiles et COG.

Martin

Tile server Rust open source de l'organisation MapLibre. Génère des tuiles MVT depuis PostGIS et sert des fichiers PMTiles/MBTiles. v1.0.0 — 19 novembre 2025.

MLT (MapLibre Tile)

Format de tuile vectorielle successeur de MVT, à encodage column-oriented, optimisé pour WebGPU. Spécification stable octobre 2025, annonce publique janvier 2026.

MVT (Mapbox Vector Tile)

Format de tuile vectorielle basé sur Protocol Buffers. Standard de facto pour les tuiles vectorielles depuis 2015.

OGC API Features

Standard OGC REST (2019) pour l'accès aux features géospatiales via JSON. Successeur de WFS.

OGC API Tiles

Standard OGC REST (2022) pour l'accès aux tuiles vectorielles ou raster. Successeur de WMTS.

PMTiles

Format d'archive binaire pour pyramides de tuiles, créé par Brandon Liu (Protomaps). Repose sur HTTP Range Requests pour servir des tuiles depuis un stockage objet sans serveur applicatif. Version 3 — octobre 2022.

R2 (Cloudflare)

Service de stockage objet S3-compatible de Cloudflare. Particulièrement adapté à la distribution de PMTiles grâce à l'absence de frais d'egress vers le réseau Cloudflare.

SDF (Signed Distance Field)

Technique de rendu de texte sur GPU. Permet de rendre du texte à toute taille et rotation sans pixellisation. Utilisée par MapLibre GL JS pour les labels cartographiques.

STAC

SpatioTemporal Asset Catalog — spécification de catalogage d'assets géospatiaux (images, COG, GeoParquet).

ST_AsMVT

Fonction aggregate PostGIS (v2.4, 2017) qui sérialise des lignes de table en tuile MVT binaire. Point de jonction entre le stockage PostGIS et la couche service.

TiTiler

Serveur de tuiles raster dynamiques en Python (FastAPI + Rasterio), Development Seed. Sert des tuiles depuis des COG hébergés sur S3 ou R2.

Tippecanoe

Outil de génération de tuiles vectorielles (MVT), maintenu par Felt. Prend des fichiers GeoJSON en entrée et produit des PMTiles ou MBTiles.

WebGPU

API graphique bas niveau pour navigateurs, successeur de WebGL. Chrome 113 (mai 2023), Safari 26 (automne 2025), Firefox 141 (juillet 2025).

WFS (Web Feature Service)

Standard OGC (2002) pour l'accès aux features géospatiales en GML. Remplacé progressivement par OGC API Features.

WMS (Web Map Service)

Standard OGC (2000) pour la génération d'images cartographiques côté serveur. Encore dominant dans les contextes institutionnels INSPIRE.

Historique des révisions

À propos de l'auteur

Mattieu Pottier

Consultant indépendant en transformation digitale — MP-i · Mattieu Pottier Indépendant

Expert SIG, architecture système et Odoo. Spécialisé dans les ERP (Odoo V18/V19), les systèmes d'information géographique (QGIS, développement Python), et les applications web (WordPress, FastAPI, JavaScript). La collection « Chaîne de la donnée géospatiale » 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. mp-i.pro

← Article précédent (LB2)

Stocker la donnée géospatiale en 2026 : du Shapefile au GeoParquet cloud-native

←