Dans un projet cartographique, le choix du format de données est souvent perçu comme un simple détail technique. En réalité, il conditionne les performances d'affichage, la capacité de montée en charge, la maintenabilité de l'architecture et parfois la viabilité du projet à moyen terme.
Un format inadapté peut imposer une refonte complète de l'infrastructure.
Pourquoi le choix d'un format géospatial n'est jamais neutre
Le SIG n'est plus cantonné au bureau et au logiciel desktop. Il alimente aujourd'hui des applications web, des tableaux de bord décisionnels, des GMAO cartographiques, des portails citoyens et des applications mobiles terrain. Les volumes augmentent, les attentes de temps réel progressent, les utilisateurs se multiplient.
Utiliser le mauvais format dans ce contexte provoque des effets concrets et coûteux : des temps de chargement excessifs qui dégradent l'expérience utilisateur, une surcharge mémoire côté client ou serveur, une éditabilité limitée qui bloque les workflows métier, et une architecture dont la scalabilité est impossible sans refonte majeure.
Aucun format n'est « meilleur » dans l'absolu. Chaque format répond à un contexte précis — volume, audience, interactivité, infrastructure disponible.
L'évolution des formats géospatiaux — quatre générations
Comprendre les formats actuels exige de comprendre leur évolution. Chaque génération de formats a émergé pour répondre aux limites de la précédente, dans un contexte technique et métier en mutation permanente.
1990–2000
SIG Bureau
Shapefile · KML
2001–2014
BDD Spatiales
PostGIS · GeoPackage
2010–2020
Services OGC
WMS · WFS · OGC API
2014–2024
Tuiles Vectorielles
MVT
2024+
Optimisation
MLT
L'ère des formats fichiers (1990–2010)
La première génération de formats est née avec les SIG desktop. Ces formats sont conçus pour le stockage local et l'échange de fichiers entre logiciels. Ils restent omniprésents dans les échanges de données géographiques, même si leurs limites sont bien documentées.
Shapefile
Standard ESRI universellement supporté. Format multi-fichiers (.shp .shx .dbf) imposant jusqu'à 3 fichiers obligatoires. Limite de 2 Go par fichier, pas de support natif des types complexes, peu adapté au web.
KML
Format XML conçu pour Google Earth. Supporte les styles visuels et l'animation temporelle. Verbeux par nature — peu performant sur des gros volumes. Principalement utilisé pour la visualisation et le partage grand public.
GeoJSON
JSON natif JavaScript, idéal pour les APIs REST et les bibliothèques cartographiques web (Leaflet, MapLibre). Simple à générer et consommer. Limité en production au-delà d'un million d'entités — problèmes mémoire et parsing côté client.
L'ère des bases de données spatiales (2001–2014)
La deuxième génération répond à un besoin fondamental : centraliser la donnée, gérer les accès concurrents et effectuer des calculs spatiaux directement en base. C'est l'émergence de l'infrastructure SIG professionnelle.
PostGIS
Extension PostgreSQL qui ajoute les types géométriques, les index GiST et les fonctions spatiales (ST_Intersects, ST_Buffer…). Transactions ACID, gestion des accès concurrents. La fondation de référence pour toute infrastructure SIG professionnelle.
GeoPackage
Standard OGC basé sur SQLite. Contient géométries, tuiles raster, attributs et métadonnées dans un seul fichier portable. Successeur naturel du Shapefile pour les échanges SIG desktop. Peu exploitable directement côté navigateur.
L'ère des services OGC — la donnée devient distribuée (2010–2020)
La troisième génération introduit le paradigme service : la donnée ne se télécharge plus, elle est interrogée via des protocoles standardisés. C'est la naissance de l'interopérabilité SIG à grande échelle.
WMS
Le serveur génère et renvoie une image raster (PNG, JPEG) pour chaque requête. Simple à mettre en place, universellement supporté. Pas d'interactivité attributaire réelle — impossible de cliquer sur un objet pour lire ses propriétés sans requête supplémentaire.
WFS
Expose les entités vectorielles avec leurs attributs. Supporte l'édition via WFS-T (transactions). Peu scalable pour une forte audience : chaque requête retourne des données brutes. Adapté aux contextes métier internes.
OGC API – Features
Successeur REST moderne de WFS. API JSON standard, pagination native, filtrage CQL2, compatible microservices. S'intègre naturellement dans les architectures cloud-native. Le standard recommandé pour les nouvelles infrastructures de service vectoriel.
L'ère des tuiles vectorielles — changement de paradigme (2014–présent)
La quatrième génération résout le problème fondamental du web cartographique : comment afficher des millions d'entités de manière fluide dans un navigateur ? La réponse : ne pas envoyer toutes les données d'un coup — les découper en tuiles et les servir à la demande.
MVT
Mapbox Vector Tile — format binaire Protobuf organisé en pyramide XYZ. Le navigateur reçoit uniquement les tuiles de la zone et du niveau de zoom affichés. Le rendu est entièrement côté client (WebGL). Standard de facto du web cartographique moderne.
MLT
MapLibre Tile — format émergent porté par la communauté MapLibre. Promet de meilleures performances et une meilleure compression que MVT. Écosystème d'outils encore en développement. Maturité inférieure à MVT en 2026 — à surveiller activement.
En 2026, trois grandes familles coexistent : chargement direct (GeoJSON), service vectoriel (WFS/OGC API), tuiles vectorielles (MVT/MLT). Le choix dépend du volume, de l'audience et des besoins d'édition.
Comparatif technique des principaux formats
Le tableau suivant synthétise les caractéristiques techniques des six principaux formats selon huit critères déterminants pour un choix d'architecture.
| Critère | Shapefile | GeoJSON | GeoPackage | WFS | MVT | MLT |
|---|---|---|---|---|---|---|
| Type | Fichier | Fichier / API | SQLite | Service | Tuiles binaires | Tuiles binaires |
| Web natif | ❌ | ✅ | ❌ | ⚠️ | ✅ | ✅ |
| Perf. gros volumes | ❌ | ❌ | ⚠️ | ⚠️ | ✅ | ✅ |
| Streaming | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
| Édition | ⚠️ | ⚠️ | ✅ | ✅ | ❌ | ❌ |
| Scalabilité | ❌ | ⚠️ | ⚠️ | ⚠️ | ✅ | ✅ |
| Complexité infra | Faible | Faible | Faible | Moyenne | Élevée | Élevée |
| Maturité 2026 | ★★★ | ★★★ | ★★★ | ★★★ | ★★★ | ★★ |
| Usage type | Échange | Web léger | SIG bureau | SIG métier | Web public | Web moderne |
Performance selon la volumétrie
La volumétrie est souvent le facteur décisif. Ce tableau présente le comportement observé des trois principaux formats web selon le nombre d'entités chargées.
| Volume | GeoJSON | WFS | MVT |
|---|---|---|---|
| < 1 000 entités | ✅ Rapide | ✅ Rapide | ✅ Instantané |
| 10 000 entités | ⚠️ Lent | ⚠️ Moyen | ✅ Très rapide |
| 100 000 entités | ❌ Très lent | ⚠️ Lent | ✅ Rapide |
| 1M+ entités | ❌ Inexploitable | ❌ Très lent | ✅ Exploitable |
Les 5 erreurs d'architecture les plus fréquentes
Ces erreurs sont récurrentes dans les projets SIG, indépendamment de la taille de l'organisation. Elles partagent toutes la même origine : un choix de format fait sans projection volumétrique ni analyse de l'audience cible.
- 1 Charger 50 Mo de GeoJSON en production pour un portail grand public — le navigateur sature, l'expérience est catastrophique.
- 2 Utiliser WFS pour une plateforme à forte audience sans cache — chaque utilisateur déclenche une requête serveur complète.
- 3 Mélanger logique d'édition et logique de diffusion dans la même couche — deux besoins fondamentalement incompatibles.
- 4 Ne pas anticiper la croissance volumétrique à 3–5 ans — un format adapté aujourd'hui peut devenir un goulot d'étranglement demain.
- 5 Confondre performance cartographique (rendu, fluidité) et performance API métier (requêtes, transactions) — ce sont deux axes orthogonaux.
MVT vs MLT — analyse stratégique 2026
La question revient fréquemment dans les projets SIG web : faut-il rester sur MVT ou migrer vers MLT ? Voici une comparaison factuelle des deux formats en 2026.
| Critère | MVT | MLT |
|---|---|---|
| Maturité | Très élevée | Moyenne |
| Outils disponibles | Nombreux (tippecanoe, pg_tileserv, Martin…) | En développement |
| Adoption industrie | Large (Mapbox, Esri, Google…) | Émergente |
| Performance | Excellente | Potentiellement meilleure |
| Standardisation | Standard de facto | En construction |
| Recommandation 2026 | Production stable ✅ | À surveiller 👀 |
Trois architectures types selon votre besoin
Au-delà du choix du format, c'est l'architecture globale qui détermine la robustesse d'un projet SIG. Voici trois patterns éprouvés, adaptés à trois niveaux de complexité et de volumétrie.
Architecture Simple
≤ 5 000 entités · faible audience · infrastructure minimale
Carte touristique, projet événementiel, POC, prototype
Architecture Intermédiaire
10K–100K entités · édition requise · utilisateurs internes
GMAO cartographique, SIG communal, gestion d'actifs terrain
Architecture Scalable
100K–millions d'entités · forte audience · haute performance
Portail national, plateforme territoriale, open data public
| Critère | Simple | Intermédiaire | Scalable |
|---|---|---|---|
| Complexité | Faible | Moyenne | Élevée |
| Coût infra | Faible | Moyen | Variable |
| Scalabilité | Faible | Moyenne | Élevée |
| Édition | Limitée | Oui (WFS-T) | API séparée |
| Performance | Bonne | Bonne | Excellente |
| Maintenance | Simple | Structurée | DevOps requis |
Une architecture robuste sépare toujours la logique d'édition métier de la logique de diffusion grand public. Ce sont deux besoins fondamentalement différents qui appellent des formats, des protocoles et des infrastructures distincts.
Comment choisir ? La grille décisionnelle
Face à la diversité des formats et des contextes, une grille de décision structurée permet d'orienter rapidement le choix vers l'architecture la plus adaptée. Ce diagramme couvre les cas d'usage les plus fréquents en 2026.
Arbre de décision — Choix du format géospatial
Les 6 questions avant tout choix technique
Avant de choisir un format, répondez à ces six questions. Elles couvrent l'ensemble des dimensions qui conditionnent la pertinence d'une architecture géospatiale à long terme.
01
Quel est le volume actuel ?
< 5K / 5K–100K / 100K–1M / 1M+ entités — le seuil conditionne directement le format possible.
02
Quelle projection volumétrique à 3–5 ans ?
Un format adapté aujourd'hui peut devenir un goulot d'étranglement si le volume ×10 dans 3 ans.
03
Édition ou simple consultation ?
Édition → PostGIS + WFS-T ou API métier dédiée. Consultation seule → GeoJSON ou MVT selon le volume.
04
Public interne ou grand public ?
Interne → WFS envisageable. Grand public → MVT + CDN recommandé pour absorber les pics de charge.
05
Quel niveau d'interactivité ?
Popup simple → GeoJSON. Requêtes spatiales complexes → couche API dédiée. Filtrages dynamiques → OGC API.
06
Quelle maturité technique disponible ?
Pas de DevOps → GeoJSON. Dev backend → PostGIS + API. Équipe complète → MVT avec pipeline de génération.
| Situation | Format recommandé | Architecture |
|---|---|---|
| Carte événementielle simple | GeoJSON | Simple |
| SIG communal interne | OGC API – Features | Intermédiaire |
| GMAO cartographique | PostGIS + API métier | Intermédiaire |
| Portail touristique national | MVT | Scalable |
| Open data territorial | MVT + CDN | Scalable |
| Projet exploratoire moderne | MVT ou MLT (test) | Scalable |
Conclusion stratégique
Le choix d'un format géospatial n'est pas un détail technique. C'est une décision d'architecture qui engage la performance, la scalabilité, la sécurité, la maintenabilité et le coût à long terme. Un mauvais choix initial peut coûter plusieurs mois de refactoring et paralyser la roadmap produit.
Les projets SIG qui réussissent partagent une caractéristique commune : ils ont anticipé la croissance volumétrique, séparé clairement les logiques d'édition et de diffusion, et choisi une architecture dont la complexité correspond à la maturité technique réelle de l'équipe.
Le format géospatial n'est que la surface visible.
Ce qui compte réellement : l'architecture globale, le flux de données, la projection volumétrique et l'objectif métier.
Choisir le bon format sans concevoir l'architecture qui l'entoure, c'est optimiser le mauvais problème.
— Mattieu Pottier, consultant SIG & cartographie — MP-i