SIG on-premise : vos cartes sur vos serveurs

Pourquoi un SIG souverain

Un SIG web hébergé est la solution la plus simple pour la plupart des organisations. Mais certaines données ne doivent pas quitter l'infrastructure de leur propriétaire : cadastre et foncier, réseaux sensibles, données personnelles, défense, santé. Parfois c'est la loi, parfois une politique interne, parfois une exigence d'un bailleur ou d'un marché public.

• Maîtrise de l'emplacement : les données restent dans votre centre de données ou chez l'hébergeur que vous avez choisi.
• Maîtrise des accès : vos agents se connectent avec leur compte habituel, et les règles de sécurité sont les vôtres.
• Maîtrise du calendrier : vous décidez quand une mise à jour s'applique.
• Continuité : le service ne dépend pas de la survie d'un prestataire extérieur.

Souveraineté ne veut pas dire isolement. Un SIG installé chez vous peut publier des cartes ouvertes au public, servir des flux WMS à des partenaires ou échanger avec une infrastructure nationale. La différence tient à qui décide : c'est vous qui choisissez ce qui sort, et rien ne sort par défaut.

Hébergé ou sur site : une grille de décision

Le choix entre un SIG hébergé et un SIG on-premise se décide rarement sur un seul argument. Cette grille aide à poser la question de façon méthodique, avec les services juridiques, informatiques et métiers autour de la même table.

Si la majorité des réponses tombent dans la colonne de droite, un SIG on-premise est justifié. Si elles se répartissent, commencez par une offre hébergée pour les cartes publiques et gardez les données sensibles en interne : les deux approches reposent sur les mêmes logiciels libres et peuvent coexister.

Ce qu'un SIG on-premise demande vraiment

Installer Lizmap, QGIS Server, PostGIS ou GeoServer sur un serveur interne est tout à fait possible : ce sont des logiciels libres, bien documentés. La difficulté vient après l'installation, quand il faut faire tourner le tout en production pendant des années.

• Un serveur dimensionné : processeurs, mémoire et disque rapide, adaptés au nombre de cartes et au volume d'imagerie.
• Un annuaire : les agents ne veulent pas un mot de passe de plus ; le SIG doit reconnaître les comptes Active Directory, LDAP ou un fournisseur OpenID Connect.
• Des droits fins : qui voit quelle carte, qui modifie quelle couche.
• Des sauvegardes : planifiées, copiées hors du serveur, et testées.
• Un plan de reprise : savoir reconstruire le service sur un serveur neuf après une panne grave.
• Des mises à jour : versions compatibles entre QGIS, QGIS Server et Lizmap, correctifs de sécurité appliqués à temps.

Pour peser l'effort réel d'une installation faite maison, lisez héberger Lizmap ou l'installer soi-même ; pour le budget, combien coûte un SIG web open source.

LizPack Entreprise : le SIG on-premise sans tout construire

LizPack Entreprise est l'infrastructure géospatiale open source de LizPack, la même que l'offre hébergée, installée sur un serveur que vous contrôlez. Il ne remplace pas les logiciels libres : il installe Lizmap, QGIS Server, PostGIS, GeoServer et, si votre licence l'inclut, la collecte terrain avec QField, puis les pilote depuis un portail unique.

• Instances Lizmap : autant que votre licence le permet, chacune avec QGIS Server et sa base PostGIS.
• Connexion par votre annuaire : Active Directory, LDAP ou OpenID Connect (Entra ID, Keycloak), avec rôles, groupes et accès par carte.
• Sauvegardes et reprise : sauvegardes planifiées, copie vers votre stockage S3, et reconstruction complète sur un serveur neuf.
• GeoServer et données : GeoServer intégré et un recensement des données de vos instances, avec leurs fiches.
• [LizPack Field](/lizpack-field) : la collecte terrain avec QField, sur le même serveur, si votre licence l'inclut.
• Vos couleurs : le portail porte votre nom et votre logo ; vos données ne quittent pas votre infrastructure.

Annuaire, rôles et droits par carte

La connexion par l'annuaire est souvent ce qui fait accepter un SIG en interne. Les agents gardent leur identifiant habituel, et le service informatique garde la main sur les comptes. Deux familles de protocoles coexistent, et LizPack Entreprise accepte les deux.

• LDAP et Active Directory : le portail interroge l'annuaire pour vérifier le mot de passe et lire les groupes de l'utilisateur. C'est le cas le plus fréquent dans les administrations équipées de postes Windows.
• OpenID Connect : l'utilisateur est redirigé vers le fournisseur d'identité de l'organisation, comme Entra ID ou Keycloak, qui confirme son identité. Le mot de passe ne transite jamais par le SIG, et l'authentification forte configurée chez le fournisseur s'applique d'elle-même.

Une fois l'utilisateur reconnu, reste à décider ce qu'il voit. La bonne pratique consiste à raisonner par groupes plutôt que par personnes : un groupe Urbanisme, un groupe Réseaux, un groupe Élus. Chaque carte est ouverte à un ou plusieurs groupes, et l'arrivée ou le départ d'un agent se règle dans l'annuaire, sans toucher au SIG.

1. Lister les cartes prévues et, pour chacune, qui doit la consulter et qui doit la modifier.
2. Regrouper ces besoins en quelques groupes métiers, alignés si possible sur les groupes déjà présents dans l'annuaire.
3. Attribuer un rôle à chaque compte dans le portail, puis ouvrir chaque carte aux groupes concernés.
4. Vérifier avec un compte de test de chaque groupe, avant l'ouverture aux agents.

Le serveur, le réseau et les certificats

LizPack Entreprise demande un processeur x86_64 (les serveurs ARM ne sont pas pris en charge), Ubuntu 22.04 LTS ou 24.04 LTS avec un accès administrateur, un disque NVMe ou SSD, et les ports 80 et 443 ouverts.

GeoServer réserve à lui seul 4 à 8 Go de mémoire, et LizPack Field demande 6 Go de plus. En cas de doute, contactez-nous avant de commander votre serveur.

Un SIG sur site reste un service web : sa sécurité commence au réseau. LizPack Entreprise demande que les ports 80 et 443 soient ouverts vers le serveur ; le reste dépend de votre politique.

• Choisir l'exposition. Un SIG réservé aux agents peut n'être joignable que depuis le réseau interne ou le VPN. Des cartes publiques demandent une exposition à Internet, idéalement derrière le relais ou le pare-feu applicatif que votre organisation utilise déjà.
• Prévoir les noms. Réservez tôt les noms de domaine du portail et des sites de cartes auprès de votre service DNS : c'est souvent l'étape la plus lente dans une administration.
• Chiffrer partout. Toutes les connexions doivent passer en HTTPS, y compris en interne. Un certificat d'une autorité publique convient pour un nom exposé à Internet ; pour un nom purement interne, l'autorité de certification de l'organisation fait l'affaire, à condition que les postes lui fassent confiance.
• Limiter l'accès d'administration. L'accès administrateur au serveur doit être réservé à quelques postes et à quelques personnes, avec des clés plutôt que des mots de passe.

Notez ces choix dans un court document d'architecture : il servira à la sécurité informatique pour valider le projet, puis à l'équipe qui reprendra l'exploitation.

La mise en place, étape par étape

1. Décrire vos besoins : nombre de cartes, de comptes, collecte terrain.
2. Commander ou réserver un serveur selon la configuration requise.
3. Installer le portail avec votre licence, puis créer le premier compte administrateur. Le gestionnaire de portails, téléchargeable librement pour Windows, installe et met à jour le portail sur vos serveurs Linux depuis votre poste.
4. Créer vos instances, brancher votre annuaire et publier vos projets avec LizPack Publisher.

Un accès Internet est nécessaire pour installer et mettre à jour. Au quotidien, les postes des utilisateurs n'ont besoin que d'atteindre votre serveur. Les mises à jour, c'est vous qui les lancez depuis le portail, quand vous le décidez. L'édition entreprise est proposée sur devis, selon le nombre d'instances, de comptes et les produits compris dans la licence.

Si le projet passe par un marché public, le cahier des charges gagne à fixer des exigences vérifiables plutôt qu'une liste de logiciels : localisation des données sur l'infrastructure de l'acheteur, connexion par l'annuaire existant (LDAP, Active Directory ou OpenID Connect), droits par carte et par groupe, sauvegardes planifiées avec copie hors du serveur, procédure documentée de reconstruction sur un serveur neuf, mises à jour déclenchées par l'acheteur, formats ouverts pour les projets, les bases et les services. Demandez aussi aux candidats une démonstration de restauration et la configuration serveur exacte qu'ils recommandent. Ces critères permettent de comparer des offres de nature différente, et ils protègent l'organisation le jour où elle change de prestataire, puisque projets QGIS, bases PostgreSQL et services OGC restent lisibles par d'autres outils. Enfin, demandez comment les compétences seront transmises à vos équipes : un SIG installé chez vous que seul le prestataire comprend ne vous appartient pas vraiment.

Exploiter un SIG souverain au quotidien

Une fois le portail installé, la souveraineté se joue dans les habitudes d'exploitation. Quelques règles simples font la différence entre un SIG on-premise fiable et un serveur qu'on n'ose plus toucher.

• Tester la restauration, pas seulement la sauvegarde. Une sauvegarde jamais restaurée n'est qu'une promesse. Prévoyez une restauration d'essai à intervalle régulier, idéalement sur un serveur de test.
• Garder une copie hors du serveur. Une copie sur le même disque disparaît avec lui. La copie vers votre stockage S3 protège contre la perte complète de la machine.
• Passer par l'annuaire pour les départs. Quand un agent quitte l'organisation, la désactivation de son compte dans l'annuaire coupe aussi son accès au SIG, sans liste séparée à tenir.
• Planifier les mises à jour. Choisissez une fenêtre calme, prévenez les utilisateurs, et faites une sauvegarde juste avant.
• Écrire la procédure de reprise. Qui fait quoi si le serveur tombe, où sont les sauvegardes, comment reconstruire sur un serveur neuf : une page suffit, à condition qu'elle existe avant l'incident.

Ces règles valent pour tout SIG installé chez soi. LizPack Entreprise fournit les outils (sauvegardes planifiées, copie vers S3, reconstruction sur un serveur neuf, connexion à l'annuaire), mais l'organisation qui les met en œuvre reste la vôtre.

Les erreurs fréquentes d'un projet de SIG on-premise

Les mêmes écueils reviennent d'un projet à l'autre. Les connaître à l'avance évite des semaines de retard.

• Sous-dimensionner le serveur. GeoServer réserve à lui seul plusieurs gigaoctets de mémoire, et l'imagerie remplit vite un disque. Partir du profil recommandé plutôt que du minimum laisse de la marge pour les nouvelles cartes.
• Choisir un disque mécanique ou un serveur ARM. Les deux sont exclus par la configuration requise : le disque doit être NVMe ou SSD, le processeur x86_64.
• Oublier l'accès Internet de l'installation. Le serveur doit pouvoir joindre Internet pour installer et mettre à jour, même si les utilisateurs n'en ont pas besoin ensuite. Faites ouvrir ce flux avant le jour de l'installation.
• Brancher l'annuaire en dernier. Si les cartes sont créées avec des comptes locaux puis migrées, les droits sont à refaire. Branchez l'annuaire dès les premières cartes.
• Ne jamais restaurer. La première restauration ne doit pas avoir lieu le jour de la panne.
• Tout confier à une seule personne. Un SIG interne doit avoir au moins deux administrateurs qui savent le mettre à jour et le reconstruire.

Quand rester sur une offre hébergée

Un SIG on-premise n'est pas toujours la bonne réponse. Si vous n'avez pas d'équipe pour surveiller un serveur, si vos données ne sont pas sensibles ou si vous démarrez avec quelques cartes, une offre hébergée comme LizPack Map, l'hébergement Lizmap de LizPack, est plus simple et moins coûteuse. Les deux partagent les mêmes logiciels libres : vous pourrez passer de l'une à l'autre. Pour situer ces choix face aux solutions propriétaires, voir les alternatives à ArcGIS Online.

Questions fréquentes