Leaflet, OpenLayers ou MapLibre : choisir son moteur de rendu carto

La semaine dernière, nous avons choisi la donnée à afficher — Overture, OpenStreetMap ou IGN — en gardant MapLibre comme constante. Mais MapLibre n’est qu’un moteur de rendu parmi d’autres, et ce choix-là se fait trop souvent par habitude, ou au gré du premier tutoriel venu. C’est une erreur de cadrage : derrière Leaflet, OpenLayers et MapLibre se cachent trois architectures de rendu différentes, et c’est l’architecture — pas le logo — qui décide de ce que votre carte saura faire dans trois ans. Voici comment trancher.

On ne choisit pas un moteur, on choisit une architecture de rendu

« On part sur Leaflet, c’est le plus simple. » La phrase paraît raisonnable. Elle l’est, pour une carte avec trois marqueurs. Elle devient un piège dès que l’application grandit.
Parce que choisir Leaflet, OpenLayers ou MapLibre, ce n’est pas choisir entre trois marques équivalentes — c’est choisir entre trois façons de dessiner une carte, qui n’ont pas les mêmes limites.

Rendre une carte : du DOM au GPU

Il existe deux grandes manières de transformer de la donnée géographique en image à l’écran.

Cette différence d’architecture n’est pas un détail technique : c’est elle qui sépare une carte qui plafonne d’une carte qui tient la charge. Le reste de l’article en découle.

Leaflet, OpenLayers, MapLibre : trois architectures

Avant de les départager, voici leur carte d’identité — année, architecture, et le terrain sur lequel chacun excelle.

Leaflet — le vétéran raster, léger et plafonné

Sorti en 2011 et pesant à peine plus de 40 Ko, Leaflet a démocratisé la carte web. Son architecture est simple : des tuiles raster empilées, des marqueurs en éléments DOM, et un écosystème de plugins qui couvre presque tout. Pour une carte avec quelques points et popups, rien n’est plus rapide à mettre en ligne.

import L from 'leaflet';
import 'leaflet/dist/leaflet.css';

// Leaflet attend [latitude, longitude] — l'inverse de MapLibre
const carte = L.map('map').setView([4.92, -52.33], 12); // Cayenne

L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
  attribution: '© OpenStreetMap'
}).addTo(carte);

L.marker([4.92, -52.33]).addTo(carte).bindPopup('Un actif');

Quelques lignes, une carte fonctionnelle : c’est sa force et c’est honnête. La limite apparaît avec l’échelle : empiler des milliers d’objets vectoriels fait ramer le DOM, il n’y a pas de tuiles vectorielles natives, pas de 3D, pas de rotation fluide. Leaflet fait parfaitement le simple — et s’arrête là.

OpenLayers — le couteau suisse du SIG exigeant

Plus ancien encore (2006, projet de l’OSGeo depuis 2007), OpenLayers est l’outil des cas SIG sérieux. Son architecture hybride combine raster et vectoriel, et sa vraie force est ailleurs : la gestion des projections cartographiques. Reprojection à la volée, services WMS/WFS, systèmes de coordonnées officiels — là où les autres calent, OpenLayers répond.

import Map from 'ol/Map.js';
import View from 'ol/View.js';
import TileLayer from 'ol/layer/Tile.js';
import OSM from 'ol/source/OSM.js';
import proj4 from 'proj4';
import { register } from 'ol/proj/proj4.js';
import { get as getProjection, transformExtent } from 'ol/proj.js';

// Déclarer une projection officielle non native — ici Lambert-93 (EPSG:2154)
proj4.defs('EPSG:2154',
  '+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 ' +
  '+x_0=700000 +y_0=6600000 +ellps=GRS80 +units=m +no_defs');
register(proj4);

// Étendue de validité (dérivée des bornes WGS84 officielles de la France)
getProjection('EPSG:2154').setExtent(
  transformExtent([-9.86, 41.15, 10.38, 51.56], 'EPSG:4326', 'EPSG:2154')
);

const carte = new Map({
  target: 'map',
  // OpenLayers reprojette les tuiles OSM (EPSG:3857) vers le Lambert-93 à la volée
  layers: [new TileLayer({ source: new OSM() })],
  view: new View({ projection: 'EPSG:2154', center: [700000, 6600000], zoom: 8 })
});

Cette capacité à parler couramment les projections est inégalée — c’est l’outil du géomaticien. Le coût est visible dans le code même : OpenLayers est verbeux, sa courbe d’apprentissage est raide, et il est surdimensionné pour une simple carte web grand public.

MapLibre — le vectoriel GPU, libre et sans jeton

Né fin 2020 du fork de la dernière version libre de Mapbox GL JS (passé propriétaire), MapLibre rend la donnée vectorielle en WebGL, consomme la Style Specification JSON et ne réclame aucun jeton d’accès. Sa signature : un style appliqué côté navigateur, qui peut réagir à la donnée elle-même.

import maplibregl from 'maplibre-gl';
import 'maplibre-gl/dist/maplibre-gl.css';

const map = new maplibregl.Map({
  container: 'map',
  style: 'https://demotiles.maplibre.org/style.json', // fond de démo libre, sans jeton
  center: [-52.33, 4.92], // Cayenne — MapLibre attend [lng, lat]
  zoom: 12
});

map.on('load', () => {
  // Source des équipements (ici en GeoJSON pour l'exemple)
  map.addSource('reseau', {
    type: 'geojson',
    data: {
      type: 'FeatureCollection',
      features: [
        { type: 'Feature', properties: { etat: 'ok' },     geometry: { type: 'Point', coordinates: [-52.33, 4.92] } },
        { type: 'Feature', properties: { etat: 'alerte' }, geometry: { type: 'Point', coordinates: [-52.30, 4.94] } },
        { type: 'Feature', properties: { etat: 'panne' },  geometry: { type: 'Point', coordinates: [-52.35, 4.90] } }
      ]
    }
  });

  // Colorer chaque actif selon un attribut métier — hors de portée du raster
  map.addLayer({
    id: 'actifs',
    type: 'circle',
    source: 'reseau',
    paint: {
      'circle-radius': 6,
      // la couleur dépend du champ "etat" de chaque objet, calculée par le GPU
      'circle-color': [
        'match', ['get', 'etat'],
        'ok', '#2D5F3F',
        'alerte', '#E97423',
        'panne', '#C0392B',
        /* défaut */ '#999999'
      ]
    }
  });
});

Ce data-driven styling — la carte se colore selon l’état réel de chaque équipement, recalculé en continu par le GPU — est typiquement ce que le raster ne sait pas faire. Pour la documentation de référence, voir le guide MapLibre GL JS. Ici les points sont en GeoJSON pour l’exemple ; en production, ces données arrivent plutôt sous forme de tuiles vectorielles — c’est tout le sujet de Exposer la donnée géospatiale sur le web, dont le livre blanc détaille serveurs, PMTiles et architectures de diffusion.

L’architecture fixe le plafond de votre carte

Une fois posées les trois architectures, le choix se clarifie : chacune autorise certaines choses et en interdit d’autres. Le tableau ci-dessous n’oppose pas trois marques — il oppose trois manières de dessiner.

Densité, fluidité, interactivité : ce que le GPU débloque

Le GPU change la nature même de la carte. Là où le raster fige une image par niveau de zoom, le vectoriel recompose la scène en continu : des dizaines de milliers de géométries dessinées à 60 images par seconde, un zoom sans paliers, la rotation, l’inclinaison 3D, les étiquettes qui se replacent toutes seules.

Et puisque le style est calculé dans le navigateur, vous le modifiez à chaud — couleur selon un seuil d’alerte, épaisseur selon un débit, filtrage selon une date — sans jamais régénérer la donnée côté serveur. C’est exactement ce que montrait l’exemple de code précédent.

Le cap suivant : de WebGL 2 à WebGPU

Soyons honnêtes sur un raccourci courant : WebGL 2 n’est pas le futur, c’est le présent. Disponible dans les navigateurs depuis 2017, c’est la technologie sur laquelle MapLibre s’appuie aujourd’hui. Le véritable horizon porte un autre nom — WebGPU.

Côté navigateur, WebGPU avance vite. Côté MapLibre GL JS, le rendu reste en WebGL aujourd’hui et une API WebGPU est en cours de développement, annoncée par le projet comme la prochaine étape pour des cartes encore plus performantes. Pour les détails techniques, la documentation MDN sur WebGPU fait référence.

La conséquence pour votre décision est simple : miser aujourd’hui sur le vectoriel / GPU, ce n’est pas suivre une mode, c’est s’aligner sur la trajectoire du rendu web. Le raster, lui, a déjà donné son maximum.

Quel moteur pour quel projet

Aucun de ces trois moteurs n’est « le meilleur » dans l’absolu — chacun a son terrain. Le bon réflexe n’est pas de chercher le plus populaire, mais de partir du besoin dominant de votre projet et de remonter jusqu’à l’architecture qui le sert.

Dit autrement : Leaflet quand la simplicité prime et que la carte restera modeste ; OpenLayers quand le SIG et les projections sont au cœur du besoin ; MapLibre quand l’application est vouée à grossir, à devenir interactive, ou à passer à la 3D.

Ce qu’il faut retenir

Choisir un moteur de rendu cartographique, ce n’est pas comparer trois logos : c’est choisir une architecture qui fixe le plafond de votre application. Leaflet pour la carte simple et légère, OpenLayers pour les besoins SIG et de projection exigeants, MapLibre pour le vectoriel de production amené à grossir. Et la trajectoire du web — du WebGL au WebGPU — confirme que le pari du GPU n’en est pas vraiment un. Le bon moteur n’est pas le plus connu : c’est celui dont l’architecture colle à ce que votre carte devra faire demain, pas seulement aujourd’hui.

Un moteur de rendu ne se choisit pas sur sa popularité, mais sur le plafond qu’il vous laisse — celui que vous toucherez dans trois ans, pas aujourd’hui.

— Mattieu Pottier, MP-i