Chaque projet est présenté de la même façon : le contexte métier, le cadrage de la donnée, l'architecture, le résultat, et le problème qu'il a fallu résoudre seul. Le détail complet, schémas et vidéos compris, est dans chaque étude de cas.
OptiControl Travaux
Enedis, Direction Régionale Nord Midi-Pyrénées, 2025 à 2026
DenodoFME Form et FME ServerBase SDEArcGIS Experience BuilderGitLab
Contexte métierLe service Politique Industrielle oriente les contrôleurs vers les chantiers des prestataires, et le résultat pèse sur les contrats futurs. Les données sont réparties dans quatre SI (Racing, e-Plan, e-Presta, PGI). Les évaluateurs choisissaient à l'aveugle, sur des données de la semaine précédente. Contrainte : aucun budget de développement, uniquement les briques déjà présentes dans le SI.
Cadrage de la donnéeQuatre sources et leurs clés de jointure, trois niveaux d'agrégation (prestataire, contrat, chantier), exclusion explicite des enregistrements défectueux analysés à part plutôt qu'imputés, et comptage des chantiers jamais contrôlés, l'information la plus utile au pilotage.
ArchitectureUne vue Denodo virtualise les quatre SI et est lue directement par FME en reader ; écriture en base SDE ; restitution Experience Builder en quatre vues synchronisées. FME Server planifie l'exécution quotidienne, envoie les mails et alerte en cas d'échec. Workspaces versionnés sur GitLab. Avant : quatre exports manuels hebdomadaires. Après : actualisation quotidienne, zéro intervention humaine.
RésultatEn production, repéré au national pour sa dimension spatiale, intégré à la Ruche (plateforme d'innovation Enedis), dupliqué par deux DR, atelier de nationalisation engagé.
Défi surmontéL'alimentation manuelle bloquait tout déploiement national, et la solution n'était documentée nulle part en interne. Veille en cinq temps (data analyst, recherche FME-Denodo, documentation Safe Software, communauté FME, test réel avec un accès habilité) jusqu'à la preuve que la vue Denodo se lit depuis FME, puis recommandation en trois phases pour la direction.
Étude de cas complète, avec le schéma avant/après et la vidéo du workspace →
WebSIG Accessibilité PMR
Projet certifiant, mission de maîtrise d'œuvre simulée sur marché public, 2025 à 2026
PostgreSQL 17 / PostGISpgRoutingQGIS ServerLizmapDocker ComposeCaddyGitHub ActionsVPS OVHcloud
Contexte métierUne agglomération, Autorité Organisatrice de la Mobilité, doit publier les données d'accessibilité de sa voirie au standard CNIG. Cahier des charges, spécifications, jalons de recette, plateforme déployée et plan de formation, en équipe de quatre. Deux contraintes : 100 % open source, interface conforme au RGAA.
Cadrage de la donnéeUser stories, cas d'usage UML, priorisation MoSCoW. Contrôle qualité en deux étages avant ingestion : modeleur graphique QGIS qui calcule et classe la pente réglementaire depuis le MNT, puis script Python (GeoPandas, SQLAlchemy) qui vérifie les champs CNIG et répare les géométries avant écriture en base.
ArchitectureQuatre conteneurs Docker Compose sur VPS, un seul exposé : Caddy en reverse proxy HTTPS devant QGIS Server (WMS, WFS), Lizmap et PostGIS/pgRouting. Sécurité couche par couche (pg_hba, Row Level Security, ufw, SSH durci). GitFlow avec versionnement sémantique, revue par un pair, CI GitHub Actions. Sauvegarde 3-2-1, PRA testé (RTO 4 h, RPO 24 h).
RésultatPreuve de concept en ligne, conformité RGAA 4.1 mesurée à plus de 85 % avec Tanaguru, itinéraire recalculé en direct (1 700 m, 46 segments), consultation temporelle des travaux filtrée par profil, extinction automatique du VPS la nuit via l'API OVHcloud.
Défi surmontéLe plus court chemin ne suffit pas pour un usager en fauteuil. La fonction de calcul recompose le coût de chaque tronçon selon le profil de mobilité et retire du graphe les obstacles bloquants pour ce profil. Un trigger PL/pgSQL détecte le déplacement des marqueurs et relance pgRouting, sans bouton ni rechargement.
Étude de cas complète, avec l'architecture, le GitFlow et les captures de la plateforme →
Éclairage public
Agglomération d'Agen, 44 communes, 2023 à 2024
PostgreSQL / PostGISTriggers PL/pgSQLQGIS AtlasMapServerINSPIRE, ISO 19115
Contexte métierUne politique d'extinction nocturne (23 h-6 h ou 2 h-6 h) débattue sur du ressenti, sur 650 km². L'élu doit délibérer sans savoir quelles voies restent fréquentées la nuit ni ce que coûte chaque ajustement. Personne n'avait commandé de projet SIG : l'initiative vient d'une observation, une collègue recomptant des véhicules à la main alors que la donnée existait déjà.
Cadrage de la donnéeComptages routiers hétérogènes et vieillissants, BD TOPO IGN, 20 416 candélabres, emprises d'extinction. Classification des points de comptage en quatre zones pour rendre les situations comparables, construction de l'indicateur clé, le temps d'usage routier sous éclairage actif, voie par voie. MCD puis MLD, métadonnées ISO 19115, publication data.gouv.fr.
ArchitectureBase PostGIS où deux triggers PL/pgSQL recalculent les statistiques d'environ 400 points de comptage à chaque insertion, jointures spatiales entre trafic, voirie et éclairage, restitution par QGIS Atlas et application cartographique MapServer. Triggers plutôt qu'un batch nocturne, pour une donnée qui évolue au fil des recalibrages.
RésultatQuatre scénarios chiffrés : 183 418 €/an en référence contre 159 059 €/an pour l'option retenue, soit 24 k€ d'économies potentielles. Planche utilisée pour la délibération des élus.
Défi surmontéL'inventaire a invalidé une partie de la question posée : certaines voiries ne sont pas équipées en éclairage, parler d'extinction n'y a aucun sens. Recadrage de l'analyse en croisant chaque tronçon avec la présence effective de foyers, ce qui a modifié le périmètre des scénarios présentés.
Étude de cas complète, avec les modèles de données et les cartes livrées →
Deux autres réalisations, OptiControl-PGOC et le diagnostic HTA, restent consultables depuis le dossier de compétences.
