GeoJSON, Shapefile, GeoPackage : quel format SIG choisir en 2026 ?

« Vous pouvez m'envoyer la couche des communes ? » Réponse inévitable : « Oui, en .shp, .geojson ou .gpkg ? » Trois extensions, trois philosophies, et autant de façons de perdre des données en route si l'on choisit mal. Le format d'un fichier SIG n'est pas un détail technique : il conditionne la taille du fichier, la conservation des accents, la rapidité d'affichage, la compatibilité avec les logiciels et même la pérennité de vos archives.

Cet article fait le point, sans jargon inutile, sur les trois grands formats de données vectorielles que vous croiserez forcément : le vénérable Shapefile, le web-friendly GeoJSON et le moderne GeoPackage. Objectif : savoir lequel choisir selon votre usage, et comment convertir proprement de l'un à l'autre.

Ce que ces formats ont en commun

Les trois formats stockent des données vecteur : la même façon de décrire le monde, à savoir des entités géométriques — des points (un puits, une borne), des lignes (une route, un oued), des polygones (une commune, un parc national) — auxquelles est attachée une table attributaire : un tableau de colonnes décrivant chaque entité (nom, population, superficie…).

Peu importe le contenant, le contenu est donc conceptuellement identique. Un polygone de la province d'Azilal reste le même polygone, qu'il soit écrit dans un .shp, un .geojson ou un .gpkg. Ce qui change, c'est tout le reste : la robustesse, les performances, la portabilité et les limites techniques.

Le Shapefile : le standard historique… et ses casseroles

Créé par Esri au début des années 1990 pour ArcView, le Shapefile est devenu le format d'échange universel du SIG. Trente ans plus tard, c'est encore lui que vous recevrez de la plupart des administrations — au Maroc comme ailleurs.

Premier piège : un Shapefile n'est pas un fichier, mais un ensemble de fichiers indissociables :

• .shp : les géométries ;
• .shx : l'index des géométries ;
• .dbf : la table attributaire (format dBase des années 80) ;
• .prj : le système de coordonnées ;
• parfois .cpg, .sbn, .xml…

Oubliez le .prj en copiant vos fichiers, et votre couche se retrouve « sans projection définie ». Oubliez le .shx, et certains logiciels refusent carrément l'ouverture.

Ses limites, héritées d'une autre époque

• Noms de colonnes limités à 10 caractères : « population_2024 » devient « populatio » après conversion ;
• Texte limité à 254 caractères par champ ;
• Taille maximale de 2 Go par fichier ;
• Encodage capricieux : les accents passent souvent mal — qui n'a jamais vu un « Région » ou un « Douar Aït… » dans une table attributaire marocaine ? ;
• Gestion imparfaite des valeurs NULL (souvent remplacées par 0 ou vide) ;
• Un seul type de géométrie par couche (impossible de mélanger points et polygones).

Quand l'utiliser malgré tout

Lorsque vous échangez avec des administrations ou des partenaires dont vous ignorez l'outillage, ou lorsqu'un logiciel ancien ne lit rien d'autre. Le Shapefile reste le « plus petit dénominateur commun » : tout le monde le lit. Mais dès que vous en avez le choix, regardez plus loin.

Le GeoJSON : le format né pour le web

Le GeoJSON est un simple fichier texte au format JSON, normalisé par la RFC 7946. Lisible à l'œil nu dans n'importe quel éditeur, encodé en UTF-8 (adieu les accents massacrés), il est le format natif des bibliothèques cartographiques web comme Leaflet ou MapLibre. Autre avantage sous-estimé : étant du texte, il se versionne parfaitement dans Git, ligne par ligne.

Un exemple minimal — un point sur Casablanca :

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [-7.62, 33.59]
      },
      "properties": {
        "nom": "Casablanca",
        "population": 3359818
      }
    }
  ]
}

Attention : dans un GeoJSON, les coordonnées sont toujours en longitude, latitude (x, y) — l'inverse de l'habitude lat/lon — et le standard impose le WGS 84 (EPSG:4326) comme système de coordonnées.

Ses limites

• Verbeux : tout est du texte, y compris les coordonnées. Un même jeu de données pèse typiquement 3 à 5 fois plus lourd qu'en GeoPackage ;
• Pas d'index spatial : ouvrir un GeoJSON de 300 000 entités oblige le logiciel à tout lire séquentiellement. L'affichage rame dès que la couche devient sérieuse ;
• Contrainte au WGS 84 : pratique pour le web, mais il faut reprojeter vos données locales.

Quand l'utiliser

Pour le web mapping, les API, les petits jeux de données, le partage rapide et le versionnement. C'est le format de publication par défaut des portails de données ouvertes — y compris pour les couches légères sur Kharita.

Le GeoPackage : le choix moderne par défaut

Le GeoPackage (.gpkg) est un standard de l'OGC publié en 2014, devenu le format par défaut de QGIS 3. Son principe : tout le jeu de données tient dans un seul fichier, qui est en réalité une base de données SQLite.

Concrètement, cela signifie :

• Un seul fichier à copier, envoyer, archiver — fini les paquets .shp + .shx + .dbf + .prj ;
• Plusieurs couches dans un même fichier : communes, provinces et régions peuvent cohabiter dans un unique .gpkg ;
• Index spatial intégré : ouverture et affichage rapides même sur de grosses couches ;
• Aucune des limites absurdes du Shapefile : noms de colonnes longs, texte illimité, UTF-8 natif, NULL correctement gérés, taille de fichier confortable ;
• Format ouvert et documenté, sans dépendance à un éditeur.

Ses limites

• C'est un format binaire : impossible à lire dans un éditeur de texte, pas de diff Git exploitable ;
• Pas natif pour le web : Leaflet ou MapLibre ne le lisent pas directement (il faut le convertir ou passer par un serveur).

Quand l'utiliser

Quasiment tout le temps en analyse et en production : c'est le format idéal pour travailler dans QGIS, organiser un projet, archiver des données. Réservez le GeoJSON à la publication web.

Tableau récapitulatif

Critère	Shapefile	GeoJSON	GeoPackage
Année / standard	~1992, Esri	2016, RFC 7946	2014, OGC
Structure	Plusieurs fichiers (.shp, .shx, .dbf, .prj…)	Un fichier texte JSON	Un fichier unique (SQLite)
Lisibilité humaine	Non (binaire)	Oui	Non (binaire)
Poids relatif	Moyen	Lourd (3–5× plus)	Léger
Index spatial	Possible (.sbn, rare)	Non	Oui, natif
Limite de taille	2 Go	Aucune (mais lent)	Très élevée
Noms de colonnes	10 caractères max	Illimité	Illimité
Accents / UTF-8	Capricieux	Parfait	Parfait
Plusieurs couches par fichier	Non	Non	Oui
Web (Leaflet, MapLibre)	Non	Oui, natif	Non
QGIS / ArcGIS	Oui	Oui	Oui (défaut QGIS 3)
Usage idéal	Échange avec administrations	Web, API, petits jeux de données	Analyse, projet, archivage

Convertir d'un format à l'autre

Dans QGIS

La conversion est triviale : ouvrez la couche, clic droit → Exporter → Sauvegarder les entités sous…, choisissez le format cible (ESRI Shapefile, GeoJSON ou GeoPackage) et le dossier de sortie.

Deux réflexes après chaque conversion :

1. Vérifier le SCR (système de coordonnées) de la couche produite : une reprojection involontaire est l'erreur la plus fréquente ;
2. Compter les entités avant et après (clic droit → Afficher le nombre d'entités) pour s'assurer que rien n'a été perdu — notamment les géométries nulles ou invalides.

En ligne de commande avec ogr2ogr

Pour automatiser, l'utilitaire ogr2ogr (fourni avec GDAL) est irremplaçable :

# Shapefile vers GeoJSON
ogr2ogr -f "GeoJSON" sortie.geojson entree.shp

# GeoJSON vers GeoPackage
ogr2ogr -f "GPKG" sortie.gpkg entree.geojson

Rappel utile au Maroc : si votre Shapefile est en Merchich (le système national historique) et que vous visez le web ou le GeoJSON, il faut le reprojeter en WGS 84 — le standard RFC 7946 l'exige. Nous détaillons ce point, les codes EPSG et les pièges de transformation dans notre article Merchich, WGS 84 et les projections au Maroc.

Et les autres formats ? En bref

• KML / KMZ : le format de Google Earth. Pratique pour partager un repère ou un itinéraire avec un public non spécialiste, mais limité pour l'analyse ;
• FlatGeobuf : un format binaire indexé spatialement, optimisé pour le web — il permet de ne télécharger que les entités visibles à l'écran. Excellent pour publier de grosses couches en ligne sans serveur de tuiles ;
• GeoParquet : le format du data engineering (écosystème Apache Arrow/Parquet), idéal pour traiter des millions d'entités dans un pipeline de données ou un entrepôt cloud ;
• COG (Cloud Optimized GeoTIFF) : l'équivalent raster de cette philosophie — un GeoTIFF structuré pour être lu à distance par petits morceaux. C'est le format que Kharita utilise pour ses couches continues : relief, pluie, sols. Le trio GeoPackage / GeoJSON / COG couvre l'essentiel des besoins modernes, vecteur comme raster.

Ce qu'il faut retenir

• Le Shapefile n'est pas un fichier mais quatre : gardez-les ensemble, et ne l'utilisez que pour la compatibilité avec des partenaires ou des logiciels anciens ;
• GeoJSON = web et petits jeux de données : lisible, UTF-8, natif Leaflet/MapLibre, mais lourd et sans index spatial ;
• GeoPackage = choix par défaut : un fichier unique, plusieurs couches, index spatial, aucune limite absurde — c'est le standard moderne pour travailler et archiver ;
• Toujours vérifier le SCR et compter les entités après une conversion, surtout lors d'une reprojection Merchich → WGS 84 ;
• Le format dépend de l'usage, pas de la mode : la même couche peut vivre en GeoPackage dans votre projet, être publiée en GeoJSON ou FlatGeobuf, et partagée en Shapefile à une administration.

Sources

• GeoPackage — standard OGC : https://www.geopackage.org/
• RFC 7946 — The GeoJSON Format : https://datatracker.ietf.org/doc/html/rfc7946
• ESRI Shapefile Technical Description : https://www.esri.com/content/dam/esrisites/sitecore-archive/Files/Pdfs/library/whitepapers/pdfs/shapefile.pdf
• Documentation QGIS : https://docs.qgis.org/latest/fr/docs/
• Figure d'illustration : documentation officielle QGIS.