01 / Contexte et contrainte métier
Un exercice d'école, mené avec les livrables d'une vraie mission
Le client est une agglomération fictive, Losse-en-Gelaisse. Tout le reste suit le déroulé d'une mission de maîtrise d'œuvre sur marché public : un cahier des charges, des spécifications fonctionnelles et techniques, des jalons de recette avec vérification d'aptitude puis vérification de service régulier, une plateforme déployée qui tourne, et un plan de formation pour la réversibilité.
Le besoin du client : en tant qu'Autorité Organisatrice de la Mobilité, l'agglomération doit collecter et publier les données d'accessibilité de sa voirie et de ses ERP. La loi d'orientation des mobilités l'y oblige, le standard CNIG Accessibilité fixe le modèle de données. Les relevés existent, mais restent stockés en fichiers, sans outil pour les consulter, les croiser ou les mettre à jour. Deux contraintes au cahier des charges : une solution entièrement open source, sans brique propriétaire, et une interface conforme au RGAA.
02 / Cadrage et spécifications
Traduire le besoin avant d'écrire une ligne de code
Chaque besoin est formalisé en user story. Exemple tiré des spécifications : en tant qu'agent de la collectivité, je veux filtrer les zones de travaux par période, afin de préparer une communication trimestrielle. Des diagrammes de cas d'usage UML structurent les interactions entre les trois profils, service voirie, associations PMR et administrateur SIG, et chaque fonctionnalité est priorisée selon MoSCoW : must, should, could, won't. Cette priorisation est révisée à chaque jalon pour arbitrer en cas de pression sur les délais.
La conduite du projet combine un cycle en V global, imposé par le cadre contractuel du marché public, et des sprints de deux semaines sur la phase de réalisation. Les responsabilités sont réparties selon une matrice RACI. La feuille de route du déploiement tient en cinq jalons : infrastructure à J+2, cœur de la solution à J+5, exposition et sécurité à J+10, recette à J+20, mise en production à J+30.
03 / Le socle : architecture et continuité
Quatre conteneurs, un seul exposé sur Internet
L'ensemble tourne dans des conteneurs Docker Compose sur un VPS OVHcloud sous Ubuntu Server 24.04 : PostgreSQL 17 avec PostGIS et pgRouting, QGIS Server 3.40 LTR pour les flux WMS et WFS, Lizmap Web Client 3.9 pour l'interface, Caddy pour le reverse proxy et les certificats TLS. La sécurité est traitée couche par couche : filtrage réseau dans pg_hba.conf et Row Level Security côté base, validation des flux côté QGIS Server, pare-feu ufw et SSH durci côté machine.
La continuité de service est un livrable à part entière : plan de reprise d'activité avec un RTO de 4 h et un RPO de 24 h, sauvegarde en stratégie 3-2-1. La procédure de restauration a été exécutée pour validation avant la recette.
04 / Le bouclier : fiabiliser la donnée et le code
Rien n'entre en base ni en production sans contrôle
Le modeleur graphique QGIS plutôt qu'un script opaque
La couche de conformité voirie, pente calculée depuis le MNT, classée selon les seuils réglementaires, croisée avec le réseau, est produite par un modeleur graphique QGIS. Chaque étape reste visible et rejouable par un agent SIG non développeur.
Écarté : un script Python isolé pour cette étape, plus rapide à écrire mais opaque pour un agent qui doit pouvoir le rejouer sans moi.GitFlow, revue par un pair et intégration continue
Branches feature, bugfix et release liées au versionnement sémantique. Une fusion exige une revue de code puis le passage des contrôles GitHub Actions. Le même outillage éteint le VPS à 19 h 59 et le rallume à 7 h 45 via l'API OVHcloud, pour réduire les coûts d'hébergement.
Écarté : le déploiement direct par SFTP, sans historique ni retour arrière.Ingestion et contrôle qualité. Le script Python (GeoPandas, SQLAlchemy) qui suit vérifie que les champs du standard CNIG, identifiant de tronçon, pente, dévers, largeur, revêtement, sont bien présents, répare les géométries invalides par un buffer nul, puis journalise chaque intégration couche par couche : un rejet tracé si un champ manque, une confirmation avec le nombre d'entités sinon, avant d'écrire dans le schéma accessibilite de la base PostGIS. Rien n'entre en base sans être passé par ce double contrôle, géométrique et sémantique.
05 / La vitrine : une interface par profil, un itinéraire par mobilité
Un même tronçon peut être praticable en fauteuil manuel et bloquant en électrique
L'interface Lizmap sert deux modes. Le mode agent donne accès aux panneaux d'édition et à la saisie des données métier. Le mode consultation, épuré et projetable en plein écran, est pensé pour les réunions publiques avec les associations PMR. Les droits sont gérés par groupe dans le back-office Lizmap, sans multiplier les projets QGIS.
Le calcul d'itinéraire est la partie la plus technique. Le graphe de cheminement issu du modèle CNIG porte des attributs de pente, de largeur utile, de revêtement et d'obstacles. Le plus court chemin ne suffit donc pas : la fonction de calcul recompose le coût de chaque tronçon selon le profil de mobilité sélectionné, et retire du graphe les tronçons portant un obstacle bloquant pour ce profil. Côté ergonomie, un trigger PL/pgSQL sur la table des points de départ et d'arrivée détecte le déplacement des marqueurs sur la carte, vérifie la validité des entrées, puis relance le calcul pgRouting. Le résultat s'affiche avec la distance totale et le détail par tronçon.
La conformité RGAA est vérifiée avec l'extension Tanaguru, critère par critère, sur les vues livrées. L'audit mesure plus de 85 % de conformité RGAA 4.1.
06 / Résultat mesuré
Ce que la plateforme démontre
Le tableau de bord croise par requêtes spatiales l'état d'accessibilité au modèle CNIG, l'offre de transport au format GTFS et la densité de population INSEE, pour attribuer un score de priorité à chaque zone. Les données restent ouvertes en sortie : flux WMS et WFS pour les outils tiers, exports GeoJSON et GPX pour charger un itinéraire sur GPS ou smartphone.
07 / Maintenance, formation et réversibilité
La mission ne s'arrête pas à la mise en production
Le plan de maintenance distingue quatre régimes : corrective pour réparer, préventive pour anticiper les risques, évolutive pour les nouvelles fonctionnalités, adaptative pour les montées de version. La formation est différenciée par profil, administrateur SIG, agent voirie, association PMR, avec des supports eux-mêmes accessibles : vidéos sous-titrées et guides PDF pas à pas. Une sandbox, instance isolée sur données fictives, permet aux agents de s'exercer sans risque pour la production. En fin de mission, la collectivité reçoit un bundle Git complet, généré avec git bundle, qui contient le dépôt et tout son historique : elle peut reprendre le projet sans dépendre de la forge du prestataire.
08 / Ce que je ferais différemment aujourd'hui
Je brancherais l'affichage de l'itinéraire sur le module Lizmap pgRouting officiel plutôt que sur notre vue de résultat, pour ne pas maintenir un composant équivalent. Et je lancerais l'audit Tanaguru dès les premiers sprints plutôt qu'en fin de réalisation : les critères de structure sémantique se traitent plus simplement à la conception des gabarits qu'après leur validation.
09 / Démo et code
La preuve de concept est déployée sur un VPS de démonstration, avec des données fictives conformes au standard CNIG. La publication se limite à ce qui m'appartient : la configuration d'infrastructure, les fonctions SQL et les schémas ci-dessus.