Hébergement GeoServer : vos couches en ligne sans serveur

Pourquoi publier avec GeoServer

GeoServer est un serveur cartographique libre, écrit en Java, qui publie des données géographiques selon les standards de l'OGC : WMS pour les images de carte, WFS pour les entités vectorielles, WCS pour les rasters et WMTS pour les tuiles. Il lit des fichiers (Shapefile, GeoPackage, GeoTIFF) et des bases de données, dont PostGIS, et applique des styles SLD.

Son intérêt tient aux standards : une couche publiée par GeoServer s'affiche dans QGIS, Lizmap, ArcGIS, Leaflet ou OpenLayers, sans conversion. C'est ce qui en fait un choix courant pour partager des données avec des partenaires, alimenter une application web ou répondre à une obligation de diffusion. Si vous hésitez encore entre plusieurs serveurs, lisez notre comparatif GeoServer, MapServer ou QGIS Server.

Les cas d'usage les plus courants

Avant de parler d'hébergement GeoServer, il vaut la peine de préciser à quoi servira le serveur. Les besoins réels déterminent la taille, les services à ouvrir et le niveau de sécurité. Voici les situations que l'on rencontre le plus souvent dans les bureaux d'études, les collectivités et les projets de coopération.

• Diffuser des données de référence à des partenaires. Limites administratives, réseau routier, zonages : une couche WMS ou WFS stable évite d'envoyer des fichiers par courriel à chaque mise à jour, et chacun voit la même version.
• Alimenter une application web. Une application Leaflet ou OpenLayers développée en interne lit les couches en WMS pour l'affichage et en WFS pour les fiches d'information, sans stocker elle-même les données.
• Répondre à une obligation de diffusion. Beaucoup de programmes de données ouvertes et d'infrastructures nationales demandent des services conformes aux standards OGC ; GeoServer les fournit sans développement.
• Partager des rasters volumineux. Orthophotos, modèles numériques de terrain ou cartes scannées se consultent en WMS ou WMTS sans que l'utilisateur télécharge des gigaoctets.
• Compléter un portail Lizmap. Un flux GeoServer s'ajoute à un projet QGIS, puis s'affiche dans la carte publiée avec LizPack Map comme une couche ordinaire.

Si votre besoin se limite à publier une carte construite dans QGIS, avec ses styles et ses mises en page, un portail Lizmap servi par QGIS Server sera souvent plus direct. GeoServer prend tout son sens quand les couches doivent vivre indépendamment d'un projet et être consommées par des outils variés. Les deux se combinent d'ailleurs très bien : un portail pour le grand public, des flux GeoServer pour les partenaires techniques, alimentés par la même base PostGIS, sans copie de données ni double mise à jour.

Ce qu'exige un GeoServer auto-hébergé

Installer GeoServer est documenté et à la portée d'un technicien. Le tenir en production demande davantage, et sur la durée :

• Un environnement Java compatible avec la version de GeoServer choisie, et un conteneur de servlets si vous n'utilisez pas le paquet autonome.
• De la mémoire. GeoServer réserve plusieurs gigaoctets dès que les couches et les utilisateurs se multiplient ; le réglage de la mémoire Java et du cache de tuiles fait partie du métier.
• Un nom de domaine et un certificat HTTPS, renouvelé à temps, avec un proxy inverse devant l'application.
• La sécurité : changer le mot de passe administrateur livré par défaut, ne pas exposer la console d'administration à tout Internet, régler les droits par espace de travail.
• Les mises à jour. GeoServer publie régulièrement des versions correctives, dont certaines ferment des failles graves. Notre guide sécuriser et mettre à jour GeoServer détaille pourquoi c'est décisif.
• La surveillance et les sauvegardes du répertoire de données, des styles et de la base.

Installer GeoServer soi-même : les grandes étapes

Pour mesurer l'effort réel, voici le parcours type d'une installation en production sur un serveur Linux. Chaque étape est documentée sur geoserver.org ; c'est leur enchaînement, et leur entretien, qui prend du temps.

1. Louer ou préparer une machine, avec assez de mémoire pour GeoServer et pour le système, et un disque séparé ou sauvegardé pour les données.
2. Installer la version de Java indiquée par la documentation de la version de GeoServer choisie, puis vérifier qu'aucune autre version ne prend le dessus.
3. Déployer GeoServer, soit avec le paquet autonome qui embarque son propre serveur web, soit sous forme d'archive WAR dans un conteneur de servlets.
4. Placer le répertoire de données hors du dossier d'installation, en le désignant avec la variable GEOSERVER_DATA_DIR, pour qu'une mise à jour ne l'efface pas.
5. Régler la mémoire allouée à Java en fonction de la machine, puis redémarrer et vérifier la page d'état de la console.
6. Mettre un proxy inverse devant GeoServer, avec un nom de domaine et un certificat HTTPS renouvelé automatiquement, et indiquer à GeoServer son adresse publique pour que les GetCapabilities renvoient les bonnes URL.
7. Remplacer les identifiants par défaut (admin et geoserver), créer les comptes nominatifs, fermer l'accès public à la console.
8. Programmer les sauvegardes du répertoire de données et de la base, et une surveillance qui prévient quand le service ne répond plus.

Comptez une à plusieurs journées pour une première installation propre, puis quelques heures par mois pour les mises à jour, la surveillance et les incidents. Ce temps est le vrai coût de l'auto-hébergement, bien plus que le prix de la machine.

Hébergement GeoServer : auto-hébergé ou géré

L'auto-hébergement reste le bon choix si vous avez besoin d'extensions GeoServer particulières, d'un accès complet au serveur ou de très gros volumes. LizPack ne remplace pas GeoServer : il l'héberge et l'entretient. Pour garder la main sur la machine, l'édition LizPack Entreprise installe GeoServer chez vous.

Publier votre première couche

Avec GeoServer Cloud, la mise en ligne suit quatre étapes, sans ligne de commande :

1. Depuis le tableau de bord LizPack, ouvrez GeoServer Cloud : votre espace isolé est créé immédiatement.
2. Déposez un Shapefile compressé en ZIP, un GeoPackage ou un GeoTIFF. Si vos données sont dans une base PostgreSQL et PostGIS LizPack, reliez-la à votre espace en un clic.
3. Publiez la couche en WMS, WFS ou WMTS et choisissez son style dans la console GeoServer.
4. Récupérez l'adresse du service pour l'utiliser dans vos outils.

Si vos données vivent dans PostGIS, le guide publier PostGIS en WMS et WFS avec GeoServer décrit pas à pas l'entrepôt, la couche, le style SLD et le test dans QGIS. Avant de publier, nommez vos couches simplement (minuscules, sans espaces ni accents) : ce nom apparaîtra dans les adresses des services et dans les logiciels de vos utilisateurs, et le changer plus tard oblige chacun à reconfigurer ses connexions. Vérifiez aussi que la projection de vos données est déclarée : un fichier sans projection connue se publie mal, ou s'affiche au mauvais endroit.

Consommer le flux dans QGIS, Lizmap ou le web

Une fois publiée, la couche a une adresse de service par standard. Dans QGIS, ouvrez le gestionnaire des sources de données, onglet WMS/WMTS ou WFS, créez une connexion avec cette adresse, puis ajoutez la couche.

• QGIS : WMS pour l'affichage, WFS pour interroger ou exporter les entités.
• Lizmap : ajoutez le flux dans votre projet QGIS, puis publiez le projet ; la couche s'affiche comme les autres.
• Leaflet, OpenLayers, ArcGIS : tout client qui lit les standards OGC affiche vos couches.
• Tuiles WMTS : le cache de tuiles intégré accélère l'affichage des couches consultées souvent.

Préférez WMTS ou WMS pour une carte grand public, WFS quand l'utilisateur doit récupérer les attributs ou la géométrie.

Pour partager une couche avec un partenaire, envoyez-lui l'adresse GetCapabilities du service plutôt qu'une capture ou un export : il verra toujours la dernière version des données, et son logiciel saura lister seul les couches disponibles, leurs projections et leurs styles.

Erreurs fréquentes et comment les corriger

Que GeoServer soit chez vous ou hébergé, les mêmes difficultés reviennent au moment de publier ou de consommer une couche. La plupart se règlent en quelques minutes une fois la cause identifiée.

Un réflexe utile : testez toujours la couche dans l'aperçu de la console GeoServer avant d'accuser le client. Si l'aperçu fonctionne, le problème vient de l'adresse, de la projection ou des droits côté client ; sinon, il est dans la publication elle-même.

Dimensionner et faire durer un GeoServer

Avant de choisir, estimez ce que vous allez réellement publier. Trois facteurs pèsent plus que le nombre d'utilisateurs : le type de données, le nombre de couches et la façon dont elles sont consultées. Une couche vectorielle de quelques milliers d'entités, servie en WMS, coûte peu. Une mosaïque d'orthophotos de plusieurs gigaoctets, interrogée à toutes les échelles, demande de la mémoire, du disque rapide et un cache de tuiles bien réglé. Un WFS ouvert sur une grosse table peut, à lui seul, saturer le serveur si un client demande toutes les entités d'un coup.

• Rasters lourds : préférez des GeoTIFF tuilés et dotés d'aperçus (pyramides), qui se lisent beaucoup plus vite qu'une image brute.
• Couches très consultées : servez-les en WMTS, depuis le cache de tuiles, plutôt qu'en WMS recalculé à chaque requête.
• Grosses tables : stockez-les dans PostGIS, avec un index spatial, plutôt que dans des fichiers Shapefile.
• Croissance : surveillez le volume de données et le nombre de couches publiées ; c'est ce qui fait passer d'une offre gratuite à un devis, ou d'un petit serveur à un plus gros.
• Temps de réponse : une carte qui met plusieurs secondes à s'afficher signale presque toujours un style trop coûteux, un index manquant ou un cache absent, rarement un manque de puissance brute.

Pensez aussi à la sortie, dès l'entrée. Un GeoServer repose sur des éléments standards : des fichiers de données ou une base PostgreSQL, des styles SLD, des services aux adresses OGC. Si vous changez d'hébergement, vous exportez vos données et vos styles, vous recréez les couches, puis vous communiquez les nouvelles adresses à vos utilisateurs. Gardez donc une copie de vos styles SLD et une liste de vos couches publiées, quel que soit l'hébergeur. Avec GeoServer Cloud, vos données déposées restent les vôtres, et une base PostgreSQL et PostGIS se reprend avec les outils PostgreSQL habituels.

Quelle option choisir

Si vous publiez quelques dizaines de couches, sans besoin d'extension particulière, un hébergement géré vous évite le serveur, Java, le certificat et la veille de sécurité. Vous gardez un GeoServer standard : vos styles SLD et vos adresses de services restent valables ailleurs. Posez-vous trois questions simples : combien de couches et de gigaoctets publierez-vous dans un an, qui dans l'équipe saura mettre à jour le serveur en urgence, et quelles extensions vous sont indispensables. Si les réponses sont « peu », « personne » et « aucune », l'hébergement géré est le choix raisonnable.

Si GeoServer est au cœur d'une infrastructure de données lourde, avec une équipe système, l'auto-hébergement se justifie. Pour situer le coût global de chaque option, voyez notre guide sur le coût d'un SIG web open source, et pour la vue d'ensemble, ce que fait LizPack.

Questions fréquentes