SIG municipal — Visualiser, gérer et décider sur la base de données territoriales précises
Système d'information géographique municipal open source pour communes et EPCI : couches cartographiques multi-thématiques, import IGN/Géoportail, édition terrain mobile hors ligne, partage inter-services, portail open data citoyen. Une alternative open source aux licences ESRI/ArcGIS.
Nos clients types
Les communes et EPCI de moins de 100 000 habitants se trouvent dans une situation paradoxale : elles gèrent un patrimoine territorial complexe (réseaux d'eau, d'assainissement, voirie, éclairage public, mobilier urbain, bâtiments, espaces verts, zones à risques) mais sans outil de visualisation centralisé. Conséquence directe : les décisions d'aménagement, d'entretien et de planification se prennent sur la base de données incomplètes, contradictoires ou périmées. La première source de ce problème est l'héritage des données non structurées. Plans de réseaux au format DWG datant des années 1990, levés topographiques papier non numérisés, tableurs Excel tenus par chaque service sans synchronisation, photos terrain non géolocalisées : la donnée territoriale existe mais elle est inutilisable en l'état. Quand le service travaux cherche l'emplacement exact d'un regard d'assainissement avant d'ouvrir une tranchée, il appelle un agent à la retraite ou cherche dans des archives physiques. C'est chronophage, risqué et coûteux. La deuxième source est la balkanisation entre services. Le service urbanisme a ses fichiers PLU sur son propre serveur. Le service technique gère son inventaire voirie dans un tableur. Le service environnement suit les zones humides dans un autre outil. La DGS n'a accès à aucune de ces données de façon synthétique. Quand arrive une demande de permis de construire impliquant une zone de risque inondation et un réseau enterré, la réponse nécessite un circuit de plusieurs services sans outillage commun. Les délais s'allongent, les erreurs augmentent. La troisième source est le coût prohibitif des solutions propriétaires du marché. ESRI ArcGIS Server représente des licences récurrentes selon le nombre d'utilisateurs et les modules activés, soit une part importante du budget numérique d'une petite collectivité pour un seul outil. Faute de budget à la reconduction, des données saisies dans des formats propriétaires peuvent devenir difficiles à exploiter. La quatrième source est la pression réglementaire croissante sur les données territoriales. Le Plan Climat-Air-Énergie Territorial (PCAET), obligatoire pour les EPCI de plus de 20 000 habitants depuis le décret n°2016-849, exige un diagnostic territorial précis et un reporting annuel chiffré sur les émissions de GES par secteur géographique. Le Plan Local d'Urbanisme (PLU et PLUi) nécessite des couches cartographiques conformes aux standards CNIG. Le recensement de la voirie pour le règlement de voirie et les obligations de signalement des réseaux (arrêté du 15 février 2012 anti-endommagement réseaux) supposent une base de données géographique à jour. Sans SIG structuré, chacune de ces obligations génère des ressaisies manuelles chronophages et des risques de non-conformité. Cinquième problème : les signalements citoyens sans géolocalisation. Quand un habitant signale un nid-de-poule ou un lampadaire défaillant par téléphone ou email, l'agent qui reçoit le signalement ne peut pas le localiser précisément sur une carte, l'affecter au bon secteur, ni suivre son traitement en temps réel. Le service technique reçoit des signalements approximatifs ("rue du Moulin, après la boulangerie"), perd du temps à identifier le lieu exact sur le terrain, et ne peut pas consolider les données pour prioriser ses interventions selon les zones les plus dégradées.
Le SIG municipal Nehos est construit sur une stack open source éprouvée dans le secteur public : QGIS Server pour le serveur cartographique, GeoServer pour la publication des flux OGC (WMS, WFS, WMTS), PostgreSQL/PostGIS pour la base de données géospatiale, et OpenLayers pour l'interface web interactive. Ce choix technique n'est pas une économie par défaut : c'est une stack éprouvée, largement utilisée dans le secteur public pour les données géographiques ouvertes. Aucun enfermement propriétaire, aucune donnée dans un format illisible sans logiciel payant. Les couches cartographiques standard déployées couvrent l'intégralité du patrimoine territorial d'une collectivité. Réseaux techniques : eau potable (canalisations, vannes, compteurs, branchements), assainissement (réseau séparatif et unitaire, regards, postes de refoulement), éclairage public (armoires, mâts, luminaires, câbles), réseaux de chaleur le cas échéant. Voirie et espace public : réseau routier avec état de surface par tronçon (indice de dégradation 0-5), trottoirs, pistes cyclables, mobilier urbain géolocalisé (bancs, corbeilles, panneaux, bornes). Bâtiments et foncier : bâtiments communaux avec fiches techniques (surface, année de construction, DPE, dernière intervention), emprise foncière, servitudes. Urbanisme et planification : zones PLU (U, AU, A, N), emplacements réservés, périmètres de protection, zones de risques naturels (Plan de Prévention des Risques Naturels). Environnement : espaces verts avec inventaire des arbres, zones humides, corridors écologiques, zones de bruit (PPBE). Chaque couche est modifiable selon des droits par profil : les agents du service technique peuvent éditer les couches voirie et réseaux, les urbanistes les couches PLU, le service environnement les couches espaces verts — la DGS accède à toutes les couches en lecture. L'import des données IGN et Géoportail est natif. Les référentiels IGN suivants sont intégrés automatiquement : BD TOPO (bâtiments, voirie, hydrographie, végétation), BD ORTHO (orthophotographies haute résolution pour le fond de carte), BD PARCELLAIRE Express (données cadastrales DGFIP), MNT (modèle numérique de terrain pour les calculs d'altitude et de risques). Ces données sont mises à jour via les flux OGC ouverts de l'IGN (Géoportail de l'urbanisme, API Carto) — plus besoin de payer des licences IGN séparées depuis la mise en open data de ces référentiels. L'édition terrain mobile est un des points forts qui différencie cette solution des portails SIG classiques en lecture seule. Les agents de terrain (techniciens voirie, agents recenseurs, inspecteurs) utilisent QGIS Mobile (ou QField, son équivalent mobile) sur tablette Android ou iPad. Ils peuvent saisir des données géolocalisées précisément, prendre des photos associées à un point géographique, et travailler hors ligne dans les zones sans réseau — les données se synchronisent automatiquement à la reconnexion. Un agent qui constate un état de chaussée dégradé lors d'une tournée peut créer un point sur la carte, renseigner la catégorie et l'indice de dégradation, attacher une photo, et valider depuis le terrain. L'information est disponible au bureau en temps réel. Le partage inter-services est géré par une gestion des droits granulaire intégrée au portail web. Chaque service municipal dispose d'un accès dimensionné à son périmètre de responsabilité. L'interface web développée en OpenLayers est accessible depuis n'importe quel navigateur, sans installation de logiciel — les agents du service urbanisme qui ne sont pas des experts SIG peuvent consulter les couches PLU, exporter un extrait cartographique pour intégrer dans un dossier de permis de construire, ou lancer une requête spatiale simple ("quels bâtiments communaux sont dans la zone inondable ?") sans assistance informatique. Le portail cartographique citoyen open data est une couche supplémentaire en lecture seule, accessible au grand public, exposant les données non sensibles (zones PLU, espaces verts, pistes cyclables, équipements publics, travaux en cours). Ce portail respecte les obligations de la loi n°2016-1321 pour une République Numérique et les engagements open data des collectivités. Il réduit aussi les appels entrants au standard pour des questions cartographiques basiques. Les alertes géolocalisées par croisement de couches constituent la fonctionnalité la plus stratégique pour la gestion des risques. Le moteur de règles permet de croiser automatiquement n'importe quelles couches : bâtiments communaux situés dans une zone inondable PPR = alerte préventive avant épisodes pluvieux ; arbres d'alignement dont le dernier élagage date de plus de 5 ans ET situés dans une zone de fort passage piéton = priorité d'intervention ; tronçons de voirie dégradés (indice ≥ 3) ET sur un itinéraire de ramassage scolaire = remontée automatique au service technique. Ces croisements sont configurables par les référents SIG sans développement — via l'interface de règles du portail. Le reporting PCAET automatisé est généré à partir des couches énergétiques et environnementales. Les exports CNIG (Conseil National de l'Information Géographique) assurent la conformité des données PLU pour les échanges avec les DDT (Directions Départementales des Territoires) et le portail national de l'urbanisme (GPU). Les exports sont produits en formats standard (GeoJSON, Shapefile, GML) sans manipulation manuelle — le responsable SIG déclenche l'export depuis l'interface, et le fichier conforme CNIG est généré sans ressaisie.
Stack open source
QGIS Server, GeoServer, PostgreSQL/PostGIS, OpenLayers
Standards OGC
flux WMS, WFS et WMTS, sans enfermement propriétaire
QField
édition terrain sur mobile, y compris hors ligne, avec synchronisation à la reconnexion
PCAET et CNIG
exports et reporting produits sans ressaisie manuelle
#Le problème : pourquoi sIG municipal est un enjeu critique
Les communes et EPCI de moins de 100 000 habitants se trouvent dans une situation paradoxale : elles gèrent un patrimoine territorial complexe (réseaux d'eau, d'assainissement, voirie, éclairage public, mobilier urbain, bâtiments, espaces verts, zones à risques) mais sans outil de visualisation centralisé. Conséquence directe : les décisions d'aménagement, d'entretien et de planification se prennent sur la base de données incomplètes, contradictoires ou périmées.
La première source de ce problème est l'héritage des données non structurées. Plans de réseaux au format DWG datant des années 1990, levés topographiques papier non numérisés, tableurs Excel tenus par chaque service sans synchronisation, photos terrain non géolocalisées : la donnée territoriale existe mais elle est inutilisable en l'état.
Quand le service travaux cherche l'emplacement exact d'un regard d'assainissement avant d'ouvrir une tranchée, il appelle un agent à la retraite ou cherche dans des archives physiques. C'est chronophage, risqué et coûteux.
La deuxième source est la balkanisation entre services. Le service urbanisme a ses fichiers PLU sur son propre serveur. Le service technique gère son inventaire voirie dans un tableur. Le service environnement suit les zones humides dans un autre outil. La DGS n'a accès à aucune de ces données de façon synthétique.
Quand arrive une demande de permis de construire impliquant une zone de risque inondation et un réseau enterré, la réponse nécessite un circuit de plusieurs services sans outillage commun. Les délais s'allongent, les erreurs augmentent.
La troisième source est le coût prohibitif des solutions propriétaires du marché. ESRI ArcGIS Server représente des licences récurrentes selon le nombre d'utilisateurs et les modules activés, soit une part importante du budget numérique d'une petite collectivité pour un seul outil. Faute de budget à la reconduction, des données saisies dans des formats propriétaires peuvent devenir difficiles à exploiter.
La quatrième source est la pression réglementaire croissante sur les données territoriales. Le Plan Climat-Air-Énergie Territorial (PCAET), obligatoire pour les EPCI de plus de 20 000 habitants depuis le décret n°2016-849, exige un diagnostic territorial précis et un reporting annuel chiffré sur les émissions de GES par secteur géographique.
Le Plan Local d'Urbanisme (PLU et PLUi) nécessite des couches cartographiques conformes aux standards CNIG. Le recensement de la voirie pour le règlement de voirie et les obligations de signalement des réseaux (arrêté du 15 février 2012 anti-endommagement réseaux) supposent une base de données géographique à jour.
Sans SIG structuré, chacune de ces obligations génère des ressaisies manuelles chronophages et des risques de non-conformité.
#Notre approche en 4 phases
#Phase 1 : Audit territorial et inventaire des données 2-3 semaines
Cartographier les données existantes (plans DWG, fichiers shapefile, tableurs Excel, données papier), identifier les sources IGN/Géoportail exploitables, lister les services utilisateurs (urbanisme, travaux, technique, environnement), définir les couches prioritaires et les droits d'accès par profil.
Voir notre expertise : hébergement souverain OVHcloud France.
#Phase 2 : Mise en place de l'infrastructure et migration des données 4-6 semaines
Déploiement PostgreSQL/PostGIS chez un hébergeur français (par exemple OVHcloud), import et nettoyage des données existantes (DWG via FME, shapefile IGN, données cadastrales DGFIP), configuration QGIS Server et GeoServer, flux WMS/WFS standards OGC pour l'interopérabilité.
Voir notre expertise : développement d'applications métier pour collectivités.
#Phase 3 : Développement du portail cartographique et modules terrain 4-5 semaines
Interface web cartographique interactive OpenLayers avec couches multi-thématiques (réseaux, voirie, PLU, bâtiments), module d'édition terrain mobile sous QGIS Mobile ou QField pour saisie hors ligne, portail open data citoyen en lecture seule, alertes géolocalisées par croisement de couches.
Voir notre expertise : portail citoyen avec signalement géolocalisé.
#Phase 4 : Formation agents, recette et mise en production 1-2 semaines
Formation des référents SIG par service, recette des couches avec les services techniques et d'urbanisme, mise en production et surveillance, exports CNIG et reporting PCAET automatisé configuré.
Voir notre expertise : guide open data collectivités (loi République Numérique).
#Repères
| Repère | Ce que c'est |
|---|---|
| Stack open source | QGIS Server, GeoServer, PostgreSQL/PostGIS, OpenLayers |
| Standards OGC | flux WMS, WFS et WMTS, sans enfermement propriétaire |
| QField | édition terrain sur mobile, y compris hors ligne, avec synchronisation à la reconnexion |
| PCAET et CNIG | exports et reporting produits sans ressaisie manuelle |
#Exemple de situation
#Contexte
Un EPCI sans SIG en place, avec des plans de réseaux DWG anciens, des tableurs de suivi par commune non consolidés, plusieurs services municipaux qui travaillent en silo, une obligation PCAET produite à la main chaque année, et un budget insuffisant pour une licence ESRI.
#Défi
Mettre en place un SIG sans licence propriétaire, reprendre les données existantes, donner à chaque service la vue qui le concerne, et automatiser le reporting PCAET et les exports de conformité PLU.
#Approche
Audit territorial et inventaire des fichiers et sources IGN. Migration et nettoyage des données dans PostgreSQL/PostGIS, avec correction des incohérences géométriques. Portail OpenLayers avec droits par service, module QField pour les agents de terrain, portail open data citoyen. Règles d'alertes géolocalisées prioritaires (risques inondation et bâtiments, voirie dégradée et itinéraires scolaires). Formation par profil métier.
#Ce qu'on mesure
Le temps de traitement d'un signalement géolocalisé avant et après, la part des données territoriales structurées et géolocalisées, le temps de production du reporting PCAET. On mesure ces points après la mise en production, sans résultat promis à l'avance.
#Pourquoi Nehos pour sIG municipal
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes.
Nos expertises connexes : portail citoyen avec signalement géolocalisé, guide open data collectivités (loi République Numérique).
Côté hébergement, nous pouvons déployer chez un hébergeur français (par exemple OVHcloud, datacenters en France) et recourir à des modèles open source (Mistral) quand la performance le permet. Le choix se fait avec vous, selon vos contraintes de souveraineté.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur le SIG municipal open source Nehos
QGIS, GeoServer et PostGIS sont utilisés par de nombreuses administrations et collectivités qui gèrent elles-mêmes leurs données géographiques. QGIS est maintenu par la fondation OSGeo, dispose d'une large communauté de développeurs, et respecte les standards OGC (WMS, WFS, GML). PostGIS est une extension officielle de PostgreSQL, base de données utilisée par des millions de systèmes critiques. La vraie différence entre ESRI et la stack open source n'est pas la fiabilité technique — c'est l'écosystème commercial (support téléphonique dédié, certification propriétaire, intégration avec d'autres produits ESRI). Pour une collectivité qui veut des données souveraines, des formats ouverts et un coût maîtrisé, la stack open source est un choix courant dans le secteur public.
Migration en 3 étapes. (1) Inventaire et qualification : on analyse tous les fichiers DWG, shapefile, Excel et PDF de plans pour évaluer leur exploitabilité (système de coordonnées, cohérence géométrique, complétude des attributs). (2) Conversion et nettoyage : les fichiers DWG sont convertis via FME Data Integration Platform ou l'import QGIS natif — en général, les plans DWG de réseaux nécessitent un travail de nettoyage géométrique (fermeture des polygones, correction des lignes interrompues, attribution des identifiants). Les shapefiles IGN s'importent directement dans PostGIS via ogr2ogr sans transformation. Les tableurs Excel sont convertis en tables PostGIS avec géocodage des adresses via l'API Adresse (base-adresse-nationale.fr). (3) Validation métier : chaque couche migrée est validée avec le service responsable avant mise en production — c'est l'étape la plus longue mais la plus critique pour la qualité des données.
Oui, nativement. Depuis la mise en open data progressive des données IGN, les flux WMS et WFS de l'IGN (Géoportail) sont accessibles sans licence spécifique pour les organismes publics. Le SIG Nehos intègre en standard : BD TOPO (fond de carte détaillé), BD ORTHO (orthophotographies), BD PARCELLAIRE Express (cadastre DGFIP mis à jour quotidiennement), MNT 1m RGE Alti (relief précis pour les calculs de risques), PCI Vecteur (parcellaire cadastral). Le Géoportail de l'Urbanisme (GPU) est également connecté pour les données PLU/PLUi des communes voisines. Ces intégrations se font via des flux OGC standardisés — elles sont configurées une fois et se mettent à jour automatiquement quand l'IGN publie de nouvelles données.
Non — et c'est un point important de notre approche. Le portail cartographique web développé en OpenLayers ne nécessite aucune installation et aucune formation QGIS. Un agent d'accueil, un instructeur PLU ou un agent d'état civil peut consulter les couches cartographiques, faire une recherche par adresse, exporter un extrait cartographique pour un dossier, depuis son navigateur sans aucune compétence SIG préalable. La formation QGIS (logiciel complet installé sur poste) est réservée aux référents SIG qui administrent et enrichissent les données. Pour les agents terrain, la formation porte sur QField (mobile) — c'est une interface simplifiée, l'essentiel se prend en main rapidement. Notre formation type est découpée selon les profils (administrateur SIG, agent terrain, utilisateur consultation), avec support de formation QGIS disponible sous licence Creative Commons réutilisable en interne.
Hébergement possible chez un hébergeur français (par exemple OVHcloud, dans ses datacenters français), sans recours à AWS, GCP ou Azure. Les données géographiques de la collectivité ne quittent jamais le territoire français. Sur le RGPD et les données parcellaires : les données cadastrales (BD PARCELLAIRE) sont des données publiques ouvertes accessibles sur data.gouv.fr — elles ne sont pas soumises à des restrictions RGPD spécifiques en tant que données de localisation de parcelles. En revanche, dès que des données à caractère personnel sont associées à une adresse ou une parcelle (propriétaire, occupant, dossier urbanisme contenant des données personnelles), le traitement est soumis au RGPD avec base légale mission de service public (article 6.1.e). Un registre de traitement RGPD est fourni pour les couches concernées, et la configuration PostGIS inclut des niveaux d'accès granulaires par couche.
Pas de texte imposant explicitement un 'SIG' comme outil, mais plusieurs obligations réglementaires rendent un SIG structuré de facto indispensable. (1) PCAET (décret n°2016-849) : le diagnostic territorial requiert des données géographiques précises sur les émissions par secteur — sans SIG, le reporting devient une estimation invérifiable. (2) Anti-endommagement réseaux (arrêté du 15 février 2012) : la collectivité doit fournir une réponse DICT précise sur l'emplacement de ses réseaux dans les délais réglementaires — sans SIG à jour, c'est une mise en cause de responsabilité civile. (3) PLU/PLUi (code de l'urbanisme, L153-1 et suivants) : les données PLU doivent être transmises en format numérique conforme CNIG à la DDT — sans SIG, la conformité est impossible à garantir. (4) Loi République Numérique 2016 : obligation d'open data pour les collectivités de plus de 3 500 habitants et 50 agents — les données géographiques sont explicitement visées.