Le document décrit le développement de l'infrastructure de géomatique ouverte (IGO) au Québec, faisant état de son historique, de ses objectifs et de ses enjeux en matière de sécurité civile et de collaboration inter-organisationnelle. Il souligne l'importance de l'utilisation d'outils et de logiciels libres, ainsi que l'architecture modulaire du système, permettant une intégration et une évolution continues. Enfin, il met en avant les partenariats établis et la nécessité d'une gouvernance partagée pour la pérennité du projet.

1. 1
Infrastructure de
géomatique ouverte
(IGO)
un modèle inspirant de
développement inter-organisation
Vision géomatique 2014

2. Contenu
Historique et situation actuelle
Besoins en sécurité civile
G.O. LOC
Projet IGO
Architecture
Outils et logiciels libres
Maturité
Utilisation de la forge
Processus et gouvernance
Partenariats
Priorisation des développements
Un modèle inspirant de mise en commun
2

3. Historique et situation actuelle
3

4. Sécurité Publique du Qc
Mission gouvernementale pour diminuer la vulnérabilité du Qc face
aux sinistres et à la criminalité
±200 employés dans toutes les régions
Mission gouvernementale venant du PM
Mandats de coordination
collaboration avec tous les M/O et municipalités
4
Sécurité civile (±90%) et incendies ;
Affaires policières.
sur le territoire du Qc

5. Démarche du MSP (2006-2007)
Répondre aux besoins en géomatique du MSP (SC) :
Assurer un leadership dans l’accessibilité à l’Information
géographique gouvernementale
Mise en place d’un entrepôt de données géographiques multi-source
5
et distribué
Innover (« ne pas reproduire ce qui existe »)
Au début: Oracle, ESRI, quelques outils OpenSource pour la
diffusion

6. Démarche du MSP (2008-2010)
Évaluer le potentiel de l’approche logiciel libre
Hybride de solution libre et propriétaire
Ajout de composante Logiciels libres
6
MapServer, OpenLayers, PostGIS, et autres
Passage à Linux Open/Suse Serveur au lieu de Windows
Banque de données Oracle vers PostgreSQL
Développement par étape et livraison rapide sans coût excessif

7. Situation actuelle
Services existants et offerts au MSP et à nos partenaires
Accès à plus de 400 couches de données (services Web : WMS / WFS)
Affichage et navigation
Service de localisation GLO (Adresses, lieux, repères/bornes, GPS)
Analyse spatiale
Ajout de couches externe
Fond de carte (à la Google) Gouv-Qc
Importation/Exportation de données
GO-Collaboration (clavardage avec partage de carte en temps-réel)
Observateur-terrain
Édition en ligne (Adresse Québec, …)
Sécurité et gestion par profil
Gestion des métadonnées (GeoNetwork)
Blogue / réseaux sociaux
7

8. Types de données
Données provenant de toutes les organisations gouvernementales et
quelques privés – aucune altération des données source
Adresses Québec
Cadastre en service WMS
Centre d’expertise hydrique (CEHQ) pour les débits/niveaux (sites FTP)
WS d’environnement canada et service hydrographique du canada (ADN)
WMS et repères du MTQ, WMS de Gaz Métro
Ententes diverses pour utilisation de données avec plusieurs M/O ou privés (ex.
Hydro-Québec)
8
Types
WMS
Fichiers shapefile, mapinfo, CSV et texte à géocoder, etc.
Volumes
Plus de 500 couches diverses
Bd PostgreSQL de 100 Go
Fichiers divers : 200 Go
Tuiles : 2 To

9. Navigateur G.O.LOC
9

10. Pièces détachées du G.O. LOC
Interface intuitive : application web
Cartes de bases tuilées et pré-générées (à la Google Maps : AQ,
BDTQ, etc.)
+400 couches en service Web (WMS)
Moteur de recherche adresse, lieu, repère du MTQ (GLO)
10

11. Problématiques
Liens logiciels avec l’infrastructure du MSP
Authentification et sécurité
Lien avec le Portail
La configuration nécessite de la programmation
L’analyse spatiale sur une base de donnée locale et une géométrie à
la fois
Pas conçu spécifiquement pour s’intégrer dans une application
existante non-géomatique
11

12. Projet IGO
Évolution du projet G.O.LOC (avant-projet IGO) : complété en 2014
Projet résolument inter-organisation
Les partenaires s’approprient une solution unique
Le MSP n’est plus le seul propriétaire
La responsabilité est répartie
Relève complète
Modèle de gouvernance et processus de développement inspiré de l’open
source
Développement agile
Utilisation de la forge gouvernementale
Architecture modulaire par services (WMS, WFS,TMS/WMTS, CSW,WPS);
Module d’intégration et façade (API);
Configuration sans programmation;
12

13. Enjeux d’un projet
inter-organisation
Engagement des organisations et perspectives d’évolution
partenariats
Besoins communs vs particularités
architecture
Acceptabilité et intégration des technologies utilisées
maturité des outils
Choix des priorités
gouvernance
Coordination inter-organisation
processus
13

14. Partenariats
14

15. Partenaires
IGO (noyau)
MSP, INSPQ, FADQ, MCC, MTQ, CPTAQ (à venir)
Utilisateur IGO
SAAQ, Données ouvertes (Préprod), Navigateur Gouvernemental,
SQ (à venir)
G.O.LOC,
MFFP (inventaire forestier), MTQ, MFA, MSP
Services :
INSPQ, FADQ, MCC, MTQ, MAMOT, MDDEP, CPTAQ, MFA,
SCT, MTO, ACRIgéo, MERN (GéoInfo) , CELL (Forge),
Commission de Toponymie, MSP
À venir :
 MSSS, MESS, Faune, MAPAQ, CSST
15

16. Types d’ententes
Partenaires en sécurité publique par l’application G.O.LOC
Partenariat en impliquant un interne dans un projet de développement
de fonctionnalités (ex : INSPQ, FADQ, MCC)
Partenariat en impliquant un externe (contrat) dans un projet de
développement de fonctionnalités (ex : CSPQ)
Partenariat par un développement exécutés par l’équipe géo du MSP
et l’hébergement des services géo du partenaire (ex : SCT, MFA)
16

17. Architecture
17

18. Objectifs
Un seule solution pour l'ensemble des partenaires
Architecture modulaire par services
Configuration sans programmation
métadonnées centralisée dans la BD et en service (CSW)
Présentation et intégration en XML
Exposition d’une façade logicielle (API) pour intégration dans les
applications
Préservation des acquis pour les utilisateurs actuels
Mapfile et sources de données
Injection de code au besoin (modify_goloc)
18

19. Changements à l’architecture
logicielle
Architecture en services
Normalisation des échanges entre chaque sous-système (WMS,
WFS, WMTS, CSW, WS)
Interopérabilité des services
Favorise les contributions et la réutilisation
Uniformise l’ajout de nouveaux modules
Module d’intégration
Exploitation des fonctions géographiques d'une manière
standardisée dans les systèmes et portails
Façade logicielle
Manière normalisé pour appeler les fonction géographique
Permet au système hôte d’appeler les fonctions géographiques
(sous forme d’action)
Isole l’interface de l’implantation
19
Minimise l’expertise
Stabilité dans le temps

20. Vue d’ensemble
Application ou
20
portail
Serveur IGO
XML
Navigateur
Cartographique
Services de carte
Services
cartographique
WMS
Données
Métadonnées
Couches
Module
d’intégration
Façade
SQL
WS
Déclencheur
action

21. Architecture technologique
Environnements :
Essais, développement, pré-production, production. Interne et
externe.
Ubuntu 14.04 LTS
Sécurité : LemonLDAP et Apache
BD: PostgreSQLPostGIS
Logiciels : MapServer, OpenLayers, MapCache, PHP (Phalcon),
GeoExt, ExtJs, JQuery
GDALl/OGR pour chargement de données
Utilisateurs de serveurs physiques et quelques VM pour des services
très légers (proxy)
Haute disponibilité par :
Serveurs de relève actifs hors site (pré-production) à Montréal
Balance de charge et serveurs de production doublés
21

22. Outils et Logiciels libres
22

23. Choix en fonction du degré de
maturité
Solution établie depuis un certain temps
Plusieurs versions et révisions de la solution
La stabilité et qualité de la solution
Dans le cadre de la démarche MSP
Les produits existaient en moyenne depuis 3-5 ans
Ils étaient tous à des versions 1.0 et +
Ils avaient faits leurs preuves en terme de stabilité puisque déjà en « production »
dans des environnements similaires au nôtre
Solution utilisée par des organisations ayant des similitudes avec le MSP
Documentation présente dans Internet
Utilisation d’un réseau de contacts pour en connaître ses avantages
Services contractuels disponibles au Québec
23

24. Maturité des LLO de G.O.LOC
extrait - étude MTQ
24
Logiciel
(12 points)
Indicateurs de maturité Niveau d'expertise MTQ
Support
(12 points)
Doc
(12 points)
Formation
(12 points)
forte moyenne faible
Score
Apache_Tomcat * : Service applicatif Web 10,66 9,33 8 7 X 72
ExtJS : Framework JavaScript pour applications
riches
10,33 9,00 10 8 X 76
GeoExt : Framework JavaScript applicatif
géospatial)
9,33 5,67 6 8 X 60
GeoNetwork : gestionnaire de métadonnées 11,33 9,67 9 9 X 81
Linux Ubuntu : Systèmes d’exploitation 11,33 10,00 11 11 X 90
Linux open SUSE : Systèmes d’exploitation 11,33 9,67 9 8 X 78
MapCache : Service de tuilage et de cache 11,00 7,33 6 10 X 72
MapServer : Service géographique Web 11,67 9,33 10 10 X 84
OpenLayers : Composante cartographique Web
JavaScript
10,67 9,67 8 8 X 75
PHP * : Langages de programmation 10,33 10,00 10 9 X 81
PostGIS : extension géospatiale de la base de
données relationnelle
11,67 10,67 10 10 X 88
PostgreSQL* : Base de données relationnelle 10,33 10,00 12 12 X 92
Python* : Langages de programmation 11,00 11,00 12 12 X 96

25. Outils de développement
Répertoire du code source
GitLab
25
IDE
NetBeans
Gestion des Issues
GitLab
Clients pour le répertoire du code source
NetBeans, msysGit, TortoiseGit, Git Extensions…
Modélisation
Enterprise Architect
Gestion des Récits Utilisateurs, Tâches
À déterminer

26. Processus
26

27. Méthodologie utilisée au
MSP
Par prototype et utilise des concepts de la méthodologie Agile
Orientée vers les personnes – nos clients
Planification souple et favorable aux changements
Collaboration au lieu de négociation
Livraison rapide et légère = client heureux
Individus : motivés, coopératifs, qui se font confiance
Équipe : qui s’organise, s’interroge, se « challenge »
Projets simples qui grandissent « du Local vers le Global »
Rétroaction suite aux commentaires des clients
NE PAS AVOIR PEUR D’ESSAYER OU DE REFAIRE
Développement par services communs interopérables/standards
Collaboration avec nos partenaires gouvernementaux; « on reçoit et
on redonne »
Partenariat entre organisations (ex:INSPQ-MCC et autres)
27

28. Utilisation de la forge
gouvernementale
Gestion du code source
Gestion des « issues »
Dépôt de documentation
Plate-forme de collaboration
28

29. Constats
Stabilité du code au départ est nécessaire
Travail en personne au préalable favorise la cohésion de l’équipe
Transition vers agile demande un changement de mentalité et de la
formation
29
Les habitudes sont fortes
Les choix d’infrastructure sont déterminants
Le maintien d’une architecture saine est un enjeu central

30. Gouvernance
30

31. Besoin d’une gouvernance
distribuée
Manque de ressources humaines et financières pour l’utilisation de la
géomatique.
Le partage des services est grandement avantageux
Mise en commun des efforts est l’étape suivante.
Refactorisation de l’ensemble des services du G.O.LOC pour le
partage d’un programme source unique.
Le MSP seul n’a aucun intérêt à refaire le G.O. LOC.
Une communauté gouvernementale pour assurer la pérennité du
projet pour tous.
31

32. Communauté
Premier projet officiel en logiciel libre qui met en place une
communauté d’utilisateurs actifs en réalisation provenant de différents
M/O.
Évolution des partenariats déjà existant
Inspirée des communautés existantes dans l’open source
32

33. Acteurs de la communauté
33
Acteurs de la communauté du projet Géo G.O.Loc
( Version béta évolutive )
Comité
Technique
MSP
INSPQ
MCC
FADQ
Autres M/O
Committeurs
MSP
INSPQ
CELL
FADQ**
* *: : a déjà
Implanté
G.O.Loc
Contributeurs
Développeurs, architectes, testeurs, pilotes, autres
MSP, INSPQ, MCC, FADQ
CELL
Et tous les M/Os intéressés

34. Projets par priorité
34
S2LQ 2014-09-17
Priorit
é
Sous projet Effo
rt
MSP FA
DQ
M
C
C
M
T
Q
INS
PQ
Moyenn
e
Responsable
s suggérés
Développeurs suggérés Début
Analyse spatiale Lour
d
1 1 1 1 1 INSPQ MapGears (+ MAT, FADQ, MTQ pour
intégration)
Juillet-Août
Gestion de sécurité, permission Lour
d
1 1 1 1 1 MSP Fred, Nic B., MAB Juillet-Août
Évolution de l'outil de pilotage Lour
d
3 1 1 2 1,75 MSP Simon, Nic B., MAT en continue
Affichage à l'écran dans d'autres projections Lég
er
1 1 3 3 2 MCC-MSP Simon N, Nic. B. Juillet-Août
Outil d'impression à reconduire Lég
er
1 3 1 3 2 2 MSP MAT, MAB Juillet-Août
GetInfo amélioré moy
en
3 2 2 1 3 2,2 MTQ Mathieu,Michael, MAB Août-septembre
Outil de sélection multiple Lour
d
2 2 2 2 3 2,2 MTQ-MSP Mathieu, Michael à déterminer
Fonction d'ajout de données spatiales moy
en
1 3 2 3 2 2,2 FADQ-MSP Michael, MAB à déterminer
Clustering pour affichage d'information moy
en
3 2 1 3 2,25 MTQ Mathieu Août-septembre
Outil d'édition en ligne Lour
d
2 1 3 3 3 2,4 FADQ-MSP Michael, MAT, Fred Août-septembre**
Outil d'itinéraire Lour
d
2 3 2 3 2,5 MTQ-MSP MAB, Mathieu, Nic B. Juillet-Août-sept

35. Constats
Façon de faire radicalement différente
Les gestionnaires doivent être sensibilisés
Les comités doivent être stimulés
L’énergie ne vient pas de nulle part…
Les organisations y trouve leur compte
35

36. Un modèle inspirant
36

37. Avantages
Facilité d’intégration aux applications existantes
systèmes de mission
Standards ouverts
Récupération des économies d’échelles
Fonctionnalités sur mesure
37

38. Facteurs facilitant / freinant
Facilitants
Clé unique
Loi permettant l’agrégation de la donnée
Pas de mise de fond initiale
Pas d’échange d’argent entre organisation
Droit de retrait
Possibilité d’une version sur mesure
Complémentarité des expertises
Leadership fort
Freinant
Préjugés face au libre et au communautaire
Apprentissages requis
38
Développement agile
Gestion de projet différente
Leadership fort

39. Réflexions
Paradigme Plomberie Objectif Organisation du travail
Orienté objet Classe Réutilisation Méthodologie
Orienté service Service Répartition de
39
responsabilité
Gouvernance
Logiciel libre License Mutualisation Communauté

40. Intégration avec les logiciels
propriétaires
La solution de diffusion s’intègre à la solution de production déjà en
place
La solution est modulaire et basée sur des standards ouverts
Les sous-systèmes logiciels principaux peuvent être remplacés
par leur équivalent propriétaire
40
Base de données (SQL)
Serveur de carte (WMS-WFS)
Les autres client cartographiques peuvent consommer la données
(WMS-WFS)
Chaque organisme traite ses contributions comme un projet
Imparti ou non
La solution est intégrable dans un système de mission standard de
l’organisme

41. Vers ou nous allons
41

42. À venir
Organisation du travail
Sensibilisation des gestionnaires
Rodage des comités
Formation aux méthodologies agiles
Fonctionnalités
Analyse spatiale
Sécurité distribuée
Sélection vectorielle multiple
Édition en ligne
Outil d’itinéraire
…
Ouverture
LGPL – Début 2015
42

43. Questions
43