GeoServer ou QGIS Server, ou MapServer : quel serveur cartographique choisir

En bref

QGIS Server sert un projet QGIS tel que vous l'avez construit dans QGIS Desktop, avec ses styles, ses étiquettes et ses mises en page. GeoServer publie des couches indépendantes d'un projet, avec ses propres styles SLD, et vise les infrastructures de données. MapServer est le plus ancien, très rapide, configuré par un fichier texte. Martin et pg_tileserv ne font qu'une chose : servir des tuiles vectorielles, surtout depuis PostGIS.

Aucun n'est meilleur dans l'absolu. Le bon choix dépend de votre outil de travail, de vos clients et de l'équipe qui entretiendra le serveur.

Les serveurs côte à côte

Tous ces logiciels sont libres. Les langages et fonctions indiqués sont ceux de leurs projets respectifs ; vérifiez la documentation de la version que vous installez.

Les styles : là où les serveurs diffèrent le plus

Sur le papier, tous ces serveurs publient du WMS. Dans la pratique, la différence la plus sensible au quotidien tient à la façon de décrire l'apparence des cartes. C'est là que se jouent le temps de mise en ligne, la qualité du rendu et la facilité de maintenance.

• QGIS Server lit directement le projet QGIS : symbologie, étiquettes, règles d'échelle, mélanges de couleurs, mises en page d'impression. Ce que vous voyez dans QGIS Desktop est ce que le serveur dessine, parce que les deux partagent les mêmes bibliothèques de rendu.
• GeoServer utilise le standard SLD, un format XML verbeux mais normalisé. Des extensions officielles permettent aussi d'écrire les styles en CSS ou en YSLD, plus lisibles. Un style QGIS peut être exporté en SLD, mais les rendus avancés (effets, générateurs de géométrie, certaines étiquettes) se perdent souvent en route.
• MapServer décrit les styles dans le mapfile, avec des blocs CLASS et STYLE et des expressions pour choisir la classe d'une entité. Il sait aussi lire du SLD. Le format est compact et se relit bien, mais il s'écrit à la main.
• Martin et pg_tileserv ne stylent rien : ils envoient des géométries, et le style est un document JSON interprété par la bibliothèque cliente, par exemple MapLibre. Changer une couleur ne demande aucune intervention sur le serveur.

Conséquence pratique : si vos cartes sont riches et déjà soignées dans QGIS, chaque autre serveur vous demandera de traduire ces styles, puis de maintenir deux versions. Si vos couches sont simples (aplats, contours, quelques classes), le format importe peu et d'autres critères, comme la couverture des standards ou la performance, reprennent le dessus. Faites le test sur trois de vos couches les plus complexes avant de décider : c'est le moyen le plus rapide de mesurer l'effort réel.

GeoServer ou QGIS Server : la vraie question

Pour la plupart des équipes qui travaillent dans QGIS, le choix se joue entre ces deux-là. La question décisive : où vivent vos styles ?

• Vos cartes sont conçues dans QGIS et doivent s'afficher sur le web exactement comme à l'écran : QGIS Server, et Lizmap par-dessus pour obtenir un portail complet (recherche, édition, impression).
• Vous diffusez des couches à des partenaires qui les consommeront dans leurs propres outils (ArcGIS, OpenLayers, catalogue de données) : GeoServer, conçu pour publier des services OGC autonomes.
• Vous avez besoin des deux : c'est fréquent. Un portail Lizmap pour les usagers, un GeoServer pour les flux de référence. Une couche GeoServer s'ajoute d'ailleurs à un projet QGIS publié dans Lizmap comme n'importe quel flux WMS ou WFS.

Chez LizPack, les deux tournent côte à côte : LizPack Map inclut QGIS Server, et GeoServer Cloud offre un espace GeoServer isolé, reliable à votre base PostGIS. Pour le détail côté Lizmap, voyez héberger Lizmap ou l'installer soi-même. Un cas fréquent illustre la répartition : une collectivité publie son plan local d'urbanisme dans un portail Lizmap, avec recherche par parcelle, impression au format A3 et édition des demandes par les agents. Les mêmes zonages sont publiés dans GeoServer pour le portail régional de données, qui les moissonne chaque nuit. Une seule base PostGIS alimente les deux, et une correction faite le matin apparaît partout.

MapServer : la vitesse, au prix de la configuration

MapServer, né à l'université du Minnesota et aujourd'hui projet de la fondation OSGeo, reste une référence pour servir de gros volumes de cartes avec peu de ressources. Tout se décrit dans un mapfile, un fichier texte qui définit couches, sources et styles.

C'est un excellent choix pour une équipe technique à l'aise avec les fichiers de configuration et le versionnement. Pour une équipe de géomaticiens qui veut publier depuis une interface, GeoServer ou QGIS Server seront plus accessibles.

MapServer ne se limite pas au mode serveur : ses liaisons MapScript permettent de piloter le rendu depuis Python ou d'autres langages, pour générer des cartes en lot ou intégrer le moteur dans une application. Le projet, sous licence de type MIT, est maintenu par un comité de pilotage au sein de la fondation OSGeo.

Performances : ce qui compte vraiment

Les comparatifs de vitesse entre serveurs circulent beaucoup, mais ils disent rarement grand-chose de votre cas. Sur des données réelles, l'écart entre deux serveurs bien configurés est souvent plus faible que l'écart entre une couche bien préparée et une couche mal préparée sur le même serveur. Avant d'accuser le logiciel, vérifiez ces leviers, valables pour tous :

• Le cache de tuiles. GeoServer intègre GeoWebCache ; MapServer s'accompagne souvent de MapCache ; devant QGIS Server, un cache de tuiles évite de redessiner les mêmes zones. Une carte consultée par beaucoup d'utilisateurs doit presque toujours passer par un cache.
• La source de données. Une table PostGIS indexée répond bien mieux qu'un gros Shapefile ou qu'un fichier lu sur un disque réseau lent.
• Les règles d'échelle. Afficher toutes les parcelles d'un pays à petite échelle est coûteux et illisible ; limitez chaque couche aux échelles où elle a du sens.
• Les étiquettes et les effets. Les étiquettes avec gestion des collisions, les ombres et les effets de couche coûtent cher. Ce sont souvent eux, et non les géométries, qui ralentissent un projet QGIS publié.
• Les rasters. Un GeoTIFF tuilé, compressé et doté d'aperçus se lit bien plus vite qu'une image brute de même contenu.

Pour comparer honnêtement, mesurez le temps de réponse d'une même requête GetMap, sur la même couche, avec et sans cache, à deux ou trois échelles. Gardez ces mesures : elles serviront aussi à vérifier qu'une mise à jour du serveur n'a rien dégradé.

Martin et pg_tileserv : les tuiles vectorielles

Les tuiles vectorielles (format MVT) envoient au navigateur des géométries découpées, que la bibliothèque cliente (MapLibre, OpenLayers) dessine elle-même. Le résultat est fluide et le style se change sans retoucher le serveur. Elles conviennent bien aux cartes grand public très consultées, aux fonds de plan personnalisés et aux applications mobiles. Elles conviennent moins quand l'utilisateur doit imprimer une carte normalisée, interroger des attributs complets ou recevoir exactement le même rendu dans tous les logiciels.

• Martin, projet de la communauté MapLibre, sert des tuiles depuis PostGIS, MBTiles ou PMTiles.
• pg_tileserv, publié par Crunchy Data, expose les tables et fonctions PostGIS en tuiles avec très peu de réglages.
• Ni l'un ni l'autre ne remplace un WMS ou un WFS : ils complètent un serveur OGC pour les cartes web grand public.

Ces deux serveurs s'appuient sur la capacité de PostGIS à produire lui-même des tuiles au format MVT. Conséquence pratique : la performance dépend surtout de la base, de ses index et de la complexité des géométries. Martin sait aussi servir des fichiers GeoJSON et des tuiles déjà générées, ce qui en fait un bon choix pour mêler données vivantes et fonds statiques.

Ce que demande l'exploitation de chaque serveur

Le choix d'un serveur engage pour des années. Au-delà des fonctions, regardez ce qu'il faudra faire chaque mois pour le garder en service : qui sait le configurer, comment il se met à jour, et ce qu'il exige de la machine. Notez aussi qui, dans votre équipe, sera prévenu d'une faille de sécurité et saura l'appliquer dans la semaine : c'est souvent le critère qui départage deux serveurs aux fonctions équivalentes.

Deux remarques pratiques. D'abord, les serveurs ne s'excluent pas : beaucoup d'organisations font tourner QGIS Server pour leurs portails et GeoServer pour leurs flux de référence, sur la même base PostGIS. Ensuite, le coût réel est celui du temps humain. Un serveur que personne dans l'équipe ne sait mettre à jour finit par devenir un risque, quelle que soit sa qualité. C'est le travail que prend en charge LizPack, une infrastructure géospatiale open source qui orchestre ces logiciels sans les remplacer : ce que fait LizPack détaille cette répartition.

Les erreurs fréquentes au moment de choisir

• Choisir sur une liste de fonctions. Les quatre serveurs couvrent les standards principaux. Ce qui fait la différence, c'est votre chaîne de travail : où naissent les cartes, qui les maintient, qui les consomme.
• Sous-estimer la traduction des styles. Passer d'un projet QGIS soigné à des SLD équivalents peut prendre des jours par carte. Ce coût doit entrer dans la comparaison.
• Oublier les clients. Un partenaire qui attend du WFS 2.0, un portail de données qui moissonne des GetCapabilities, une application mobile qui lit des tuiles vectorielles : partez de ce qu'ils savent lire.
• Croire qu'un seul serveur doit tout faire. Un portail QGIS Server avec Lizmap pour les usagers et un GeoServer pour les flux de référence, sur la même base PostGIS, est une architecture courante et saine.
• Négliger l'entretien. Le meilleur serveur devient un risque s'il n'est jamais mis à jour. Choisissez celui que votre équipe saura réellement maintenir, ou confiez cette part du travail.
• Tester sur des données jouets. Un test sur dix entités ne dit rien. Utilisez vos couches réelles, à leurs volumes réels, avec vos styles.

Une méthode simple fonctionne bien : retenir deux candidats, publier les trois mêmes couches représentatives sur chacun, les afficher dans les clients de vos utilisateurs, mesurer, puis estimer le temps d'entretien annuel. En une ou deux semaines, la réponse est généralement claire, et elle repose sur vos données plutôt que sur des réputations.

Choisir selon votre besoin

Quel que soit le serveur, il faudra l'entretenir : Java ou bibliothèques système, certificats, mises à jour de sécurité. Le guide sécuriser et mettre à jour GeoServer montre ce que cela implique concrètement. Si vous retenez QGIS Server et GeoServer côte à côte, gardez une règle de nommage commune pour les couches et documentez quelle couche est publiée où : vos utilisateurs sauront à quelle adresse s'adresser, et vous éviterez de maintenir deux versions divergentes d'une même donnée.

Questions fréquentes