WebSIG Accessibilité PMR · Preuve de concept au standard CNIG

Projet de certification RNCP mené en équipe de quatre, pour une autorité organisatrice de la mobilité fictive : concevoir et déployer une chaîne WebSIG open source complète, de la base de données au serveur en production, dans le cadre imposé par la loi LOM.

Cadre

Projet académique · certification RNCP niveau 7 · IDGEO Toulouse

Période

2025-2026 · équipe de quatre

Mon rôle

Couche applicative, versionnage GitFlow, qualité des livrables

Stack

Lizmap · QGIS Server · PostGIS · pgRouting · Docker · Caddy · GitHub Actions

Résultat clé

Chaîne conteneurisée déployée · TLS noté A+ par SSL Labs

Le problème posé

La loi LOM impose aux autorités organisatrices de la mobilité de collecter et publier les données d'accessibilité de la voirie et des établissements recevant du public, au standard CNIG Accessibilité. Le sujet de certification simule cette commande : une collectivité fictive demande une base conforme au standard et un WebSIG qui permette de consulter l'accessibilité de la chaîne de déplacement et de calculer des itinéraires adaptés aux personnes à mobilité réduite.

Je présente ce projet pour ce qu'il est : une preuve de concept académique, sans client réel. Son intérêt est ailleurs. Il démontre la capacité à monter une infrastructure SIG open source complète et à la faire fonctionner en conditions proches de la production, avec les contraintes de standard, de sécurité et de qualité logicielle d'un vrai projet.

La démarche

L'équipe a réparti le travail en quatre lots : la base de données au schéma CNIG, l'analyse de réseau, l'infrastructure serveur et la couche applicative. J'ai pris en charge cette dernière : la configuration du WebSIG Lizmap servi par QGIS Server, l'organisation du versionnage en GitFlow et la qualité des livrables rendus au jury.

La base structure les entités du standard CNIG Accessibilité : tronçons de voirie, nœuds, obstacles, équipements et établissements recevant du public. L'import est scripté en Python avec GeoPandas et piloté par un fichier de configuration, ce qui rend le chargement reproductible. L'extension pgRouting construit le graphe de cheminement à partir des tronçons, avec un coût de déplacement qui combine longueur, pente, dévers et revêtement : un itinéraire PMR évite ainsi les segments impraticables plutôt que de simplement minimiser la distance.

L'architecture

L'ensemble tourne sous Docker Compose : la base, le serveur cartographique et l'application sont des conteneurs distincts, reconstruisibles à l'identique. Caddy sert de reverse proxy et gère le certificat TLS, avec une configuration notée A+ par SSL Labs. Le dépôt suit un GitFlow strict et une chaîne GitHub Actions vérifie les livrables à chaque fusion.

Les choix de conception

Le calcul d'itinéraire en base. Porter le routage dans pgRouting plutôt que dans un service externe garde le graphe synchrone avec la donnée : un obstacle saisi dans la base modifie immédiatement les itinéraires, sans recalcul préalable.

Un GitFlow imposé à l'équipe. À quatre sur le même dépôt, la discipline de branches n'est pas un luxe. Formaliser le flux, branches de fonctionnalité, revues avant fusion, a évité les conflits destructeurs et laissé un historique lisible pour le jury.

La sécurité traitée comme un livrable. Même sur un projet académique, exposer un serveur sans HTTPS correct n'est pas défendable. La note A+ de SSL Labs sert de preuve vérifiable que la configuration tient un niveau professionnel.

Les résultats

Ce que j'en retiens

Ce projet complète mon expérience Enedis sur l'écosystème Esri par sa contrepartie open source, et m'a confronté aux sujets qu'un environnement grand compte prend en charge pour vous : l'infrastructure, la sécurité, le déploiement. Savoir monter la chaîne complète change la façon d'en utiliser chaque brique.