ENSG

Introduction à l'architecture des SI

ENSG

Plan

ENSG

Introduction

ENSG

Définition d'un SI

« Le système d'information (SI) est un ensemble organisé de ressources qui permet de collecter, stocker, traiter et distribuer de l'information, en général grâce à un réseau d'ordinateurs. »

Source fr.wikipedia.org

Le SI se décompose en un système organisationnel et un système technique : Le système informatique (le matériel informatique, les logiciels, les données, les services, les réseaux,...)

ENSG

Introduction

Les différents types de SI

Nous trouverons plusieurs types de systèmes d'information :

  • Des Systèmes d'Information des Ressources Humaines (SIRH) pour gérer les absences, les paies, les recrutements...
  • Des systèmes d'entreprise ou ERP (Enterprise Resource Planning) pour gérer les processus et les ressources.
  • Des systèmes d'aide à la décision s'appuyant sur des analyses de données internes ou externes
  • ...
ENSG

Introduction

Le système d'information géographique (SIG)

Le SIG sera un type de SI se focalisant sur la gestion des données spatiales :

« Un système d'information géographique ou SIG est un système d'information conçu pour recueillir, stocker, traiter, analyser, gérer et présenter tous les types de données spatiales et géographiques »

(Source : fr.wikipedia.org - Système d'information géographique)

ENSG

Introduction

Par où commencer? (1/2)

En pratique, nous traiterons des sujets d'architecture à plusieurs échelles :

  • Une application
  • Une solution
  • Une entreprise
ENSG

Introduction

Par où commencer? (2/2)

Or :

  • L'architecture des SI est une discipline qu'il est difficile d'aborder sans une expérience à l'échelle des applications et des solutions.
  • Il y a de nombreux de points intéressants à traiter (c.f. roadmap.sh - Software Architect)...
ENSG

Introduction

Comment allons nous procéder? (1/2)

Dans cette introduction, nous chercherons à poser une vision claire de l'architecture des SI en abordant :

  • Les principaux défis à relever.
  • Les objectifs visés, définis à travers différents critères qualités.
  • Les principes d'architecture qui guideront dans la conception des solutions.
  • Les styles d'architecture classiques et leurs usages.
ENSG

Introduction

Comment allons nous procéder (2/2)

Nous ferons ensuite un focus sur l'architecture logique des systèmes d'information géographique (SIG) en abordant :

  • Les spécificités des données géographiques.
  • L'architecture d'une infrastructure de données géographique (IDG)

Les éléments relatifs à l'architecture technique et à la gestion du cycle de vie des applications seront traités dans le cours DevOps.

ENSG

Les principaux défis

ENSG

Hétérogénéité des acteurs (1/3)

La conception d'une architecture devra prendre en compte de nombreux acteurs :

  • Les utilisateurs (internes ou externes)
  • Les métiers ("MOA")
  • Les développeurs ("MOE")
  • La sécurité (RSSI, DPO,...)
  • Les décideurs
  • Les partenaires
  • Les prestataires
  • ...
ENSG

Hétérogénéité des acteurs (2/3)

En particulier, il conviendra de :

  • Répondre aux objectifs et intérêts souvent divergents de ces différents acteurs.
  • Préciser les rôles et responsabilités des différents acteurs (ex : rédiger un RACI)
ENSG

Hétérogénéité des acteurs (3/3)

Aussi, il conviendra de traiter des injonctions techniques qui ne seront pas toujours optimales :

  • Confusion fréquente entre l'expression d'un besoin fonctionnel (ex : je veux partager des fichiers) et la proposition d'une solution technique (ex : je veux utiliser dropbox, google drive ou équivalent)
  • Lien étroit entre la politique et des décisions techniques structurantes (1).

(1) Nous verrons quelques exemples (à l'oral).

ENSG

Les principaux défis

Documentation de l'architecture (1/3)

Pour avoir vision complète et partagée du système et pouvoir discuter les évolutions, il sera important de documenter l'architecture tant sur :

  • Le plan métier (les produits et leurs fonctionnalités)
  • Le plan organisationnel (les équipes, les processus, les procédures,...)
  • Le plan logique (les outils, les services, les traitements,...)
  • Le plan technique (les centres de données, les zones, les réseaux, les machines...)
ENSG

Les principaux défis

Documentation de l'architecture (2/3)

Nous noterons qu'il est théoriquement possible de documenter l'intégralité d'un SI avec des schéma UML. C'est l'objet du modèle 4 + 1 vues proposé par Philippe Kruchten en 1995 :

Source : www.irisa.fr - Représentation des vues d’architecture avec UML - Pierre-Alain Muller

ENSG

Les principaux défis

Documentation de l'architecture (3/3)

Toutefois :

  • La maintenance d'une documentation UML complète et rigoureuse à l'échelle d'un SI est utopique au regard de la fréquence des évolutions
  • Présenter le bon niveau de détail aux différents acteurs ne sera pas évident d'où :
    • Des approches hiérarchiques telles C4 model
    • L'intérêt d'utiliser des approches modernes en matière de documentation

Nous détaillerons ce point dans le cours DevOps mais en substance, il sera plus intéressant de produire et générer de la documentation au format HTML (décomposition, liens, multiple niveau de lecture,...) que de s'évertuer à maintenir des documents classiques (.docx, .pdf, .odt).

ENSG

Les principaux défis

Documentation des services

Il conviendra de documenter précisément les interfaces des différents services du SI.

Pour les API REST/JSON, nous systématiserons par exemple la rédaction de spécifications au format OpenAPI.

Nous utiliserons l'éditeur en ligne editor.swagger.io pour voir concrètement de quoi il est question. Nous verrons un cas concret avec le service d'autocomplétion de la Géoplateforme.

ENSG

Les principaux défis

Gouvernance et agilité (1/4)

La nécessité d'assurer la cohérence et de rationaliser (éviter les silos technologiques et la multiplication des solutions) à l'échelle du SI induit un besoin de standardisation.

ENSG

Les principaux défis

Gouvernance et agilité (2/4)

Des cadres méthodoliques tels TOGAF (The Open Group Architecture Framework) permettent de structurer la gouvernance du SI et piloter les évolutions de manière cohérente.

ENSG

Les principaux défis

Gouvernance et agilité (3/4)

Toutefois :

  • TOGAF est difficilement applicables à toutes les échelles d'un SI.
  • Un cadre technique trop strict ou figé comporte deux risques majeurs :
    • Le blocage de l'innovation
    • Le recours au Shadow IT.
ENSG

Les principaux défis

Gouvernance et agilité (4/4)

À ce titre, il est préférable de :

  • Mettre en place des standards flexibles (éviter les règles trop prescriptives ou trop précises)
  • Décrire le cadre technique sans le figer (recensement et cartographie des solutions)
  • Poser un cadre pour gérer les évolutions, par exemple via des Architecture Decision Records (ADR).

En substance, la gouvernance du SI ne doit pas brider l'agilité. Elle doit l'encadrer pour assurer la cohérence des choix à l'échelle du SI.

ENSG

Les principaux défis

Sécurité et conformité (1/2)

La conception d'une architecture devra prendre en compte le besoin de :

Il conviendra de prendre en compte ces exigences :

  • Dès la conception et dans le cycle de vie des projets.
  • En priorisant par rapport à la réponse aux besoins métiers.
ENSG

Les principaux défis

Sécurité et conformité (2/2)

💭 Un doute sur la nécessité de prioriser ?

À votre avis :

  • Pourquoi le formulaire permettant de laisser un commentaire permet parfois de télécharger la liste des utilisateurs et leurs mots de passe (injection SQL)?
  • Pourquoi ouvrir un simple fichier bureautique peut-il parfois chiffrer tout un disque dur ?

🔎 Un indice : Vous connaissez tous le concept d'user story? Et celui d'abuser story?
⚙️ Qu'est-ce qui peut poser problème avec ce formulaire de contact?

ENSG

Les principaux défis

Gestion des systèmes hérités (legacy)

Les organisations possédent souvent des systèmes anciens ou obsolètes qui jouent un rôle central dans le SI.

Il conviendra de refactorer propressivement le SI afin de traiter cette dette technique au cas par cas :

  • Moderniser les mécanismes d'authentification (ex : login/password -> OIDC)
  • Remplacer d'un service obsolète par un nouveau composant (1)
  • ...

(1) Voir le patron figuier étrangleur qui illustre cette approche progressive.

ENSG

Les principaux défis

Prioriser les critères qualités

Concevoir un système parfait est une utopie. Sans objectifs clairs, nous risquons de concevoir des systèmes trop complexes ou trop coûteux par rapport au contexte (ex : 10 utilisateurs maximum, indisponibilités acceptables, perte totale des données acceptée...).

Il est donc crucial de définir et prioriser ces objectifs dès le départ afin que les choix architecturaux soient guidés par des critères mesurables et pertinents.

Toutefois, cet exercice sera loin d'être évident...

Par exemple, il faudra expliquer qu'un système résistant indéfiniment à la charge peut rapidement se traduire par une facture cloud exorbitante.

ENSG

Les critères qualités

⚠️ Attention : Cette liste n’est pas exhaustive : vous serez invités à proposer d’autres critères !

Conception et intégration :

Robustesse et exploitation :

ENSG

Les critères qualités

Évolutivité

L'architecture doit permettre des évolutions futures sans remettre en cause l'ensemble du système.

ENSG

Les critères qualités

Réutilisabilité

Produire des composants réutilisables permet d'optimiser le développement et d'améliorer la qualité du SI en réduisant les redondances de code.

ENSG

Les critères qualités

Interopérabilité

Les composants doivent être capables de communiquer entre eux même s'ils proviennent de systèmes différents.

ENSG

Les critères qualités

Conformité aux normes

Le respect des standards (ex : standards OGC) et bonnes pratiques de l’industrie (ex : REST/JSON + OpenAPI) facilite l'interopérabilité, la réutilisation, et la maintenabilité.

ENSG

Les critères qualités

Performance

Le système doit être conçu pour répondre à plusieurs objectifs de performance :

  • Minimiser la durée d'exécution des traitements.
  • Minimiser la consommation en ressources systèmes (CPU, RAM, stockage et réseau).
  • Minimiser le coût (1).

(1) Vu la complexité des modèles de facturation dans les environnements infonuagiques, ce dernier point sera l'objet d'une discipline à part entière connue sous le nom FinOps.

ENSG

Les critères qualités

Résilience

Le système doit être conçu pour continuer à fonctionner (ou se dégrader de façon contrôlée) en cas de défaillance d’un ou plusieurs composants.

Par exemple, pour traiter le cas d'une indisponibilité temporaire d'un service tiers, nous trouvons le patron "nouvelle tentative" (retry).

Sinon, pour assurer la disponibilité en cas de problème, nous trouvons principalement deux stratégies qui seront détaillées dans le cours DevOps :

  • Réplication des services.
  • Redémarrage automatique en cas de problème.
ENSG

Les critères qualités

Scalabilité

L'architecture doit être conçue pour supporter la montée en charge (évolution du nombre de clients, du volume des données,...) sans perte de performance.

Nous trouverons deux stratégies :

  • La scalabilité verticale (modification du dimensionnement des machines).
  • La scalabilité horizontale (multiplication du nombre de machines), plus intéressante mais plus complexe à mettre en oeuvre (1).

(1) Nous détaillerons le cas des services sans état dans le cadre du cours DevOps. Le cas des services de stockage sera laissé au cours sur le stockage NoSQL qui abordera à priori la réplication et la distribution du stockage et le théorème CAP

ENSG

Les critères qualités

Observabilité

Le système doit être instrumenté pour permettre l'identification et résolution rapide des problèmes.

Nous détaillerons ce point dans le cadre du cours DevOps.

ENSG

Les critères qualités

Portabilité

Les composants doivent être capables de fonctionner dans différents environnements (ex. cloud, on-premise) sans nécessiter de modifications majeures.

Nous verrons dans le cadre du cours DevOps que le respect des 12 facteurs y contribue grandement.

ENSG

Les critères qualités

À vous maintenant!

  • Quels critères ajouteriez-vous?
  • Comment priorisiez-vous :
    • Pour un démonstrateur / POC?
    • Pour un service transverse de géocodage?
    • Pour un service transverse d'authentification?
ENSG

Les principes d'architecture

ENSG

Les principes d'architecture

Séparation des préoccupations (Separation of Concerns)

A l'échelle du système, chaque composant doit avoir une responsabilité claire et unique.

Nous retrouvons ce principe en P.O.O. dans le S de SOLID avec le principe de responsabilité unique (Single responsibility principle).

ENSG

Les principes d'architecture

Modularité

Le système est décomposé en plusieurs modules qui peuvent être développés, testés et maintenus séparément.

ENSG

Les principes d'architecture

Abstraction (1/2)

L'abstraction est un processus consistant à se concentrer sur les caractéristisques essentielles d'un composant ou d'un système tout en ignorant les détails.

ENSG

Les principes d'architecture

Abstraction (2/2)

L'abstraction intervient à toutes les échelles d'un système :

  • Les classes et interfaces d'un composant.
  • Les services d'un système.
  • Les différentes couches du système (interface graphique, logique métier, persistance des données)

La principale difficulté consistera à nommer et modéliser des concepts.

ENSG

Les principes d'architecture

Encapsulation (1/2)

Les interactions entre modules se font uniquement via des interfaces bien définies. Les détails internes sont cachés aux autres modules.

ENSG

Les principes d'architecture

Encapsulation (2/2)

En pratique, nous pourrons encapsuler une fonctionnalité en mettant à disposition une API qui pourra prendre plusieurs formes :

  • Une API WEB.
  • Une application en ligne de commande (CLI).
  • Une interface dans une bibliothèque de programmation.

Nous aborderons en séance les points forts et points faibles de ces différentes approches en analysant quelques cas pratiques (recherche des communes par nom et code postal, simplification des géométries,...).

ENSG

Les principes d'architecture

Couplage faible (1/2)

Les modules doivent être aussi indépendants que possible les uns des autres. Un couplage faible facilite la modification ou le remplacement de modules sans affecter les autres parties du système.

ENSG

Les principes d'architecture

Couplage faible (2/2)

Nous noterons que le couplage pourra prendre plusieurs formes :

  • Message ou événement : producteurs et consommateurs partagant un canal et un format de message (ex : "location_change" pour une flotte de véhicules).
  • Interface : dépendance au contrat d'échange (ex : paramètres d'une API)
  • Données : dépendance au schéma ou au format partagé (ex : schéma BDTOPO).
  • Temporel : dépendance à un ordre ou un moment précis d’exécution (ex : intégration de données après génération d'un export).
ENSG

Les principes d'architecture

Sécurité intégrée dans la conception

Par exemple, l'approche secure by design invite entre autre à :

  • Minimiser la surface d'attaque (minimiser l'exposition de service, utiliser des frameworks évitant les failles courantes,...)
  • Appliquer le principe de moindre privilège.
  • Adopter une stratégie de défense en profondeur (ne pas se contenter de la sécurité périmétrique!).
  • Prendre des précautions vis-à-vis des services tiers.
ENSG

Les principes d'architecture

Utilisation de protocoles efficaces (1/2)

Pour les performance, il conviendra d'utiliser des protocoles efficaces et adaptés au contexte.

ENSG

Les principes d'architecture

Utilisation de protocoles efficaces (2/2)

Dans le cas des services web, la recherche de l'efficacité se retrouve dans l'évolution des formats et protocoles :

  • Fin des années 90 : le format XML domine avec WSDL et SOAP.
  • Depuis ~2005 : les API REST et le format JSON gagnent du terrain en apportant plus de simplicité et de légèreté.
  • 2011 : WebSocket introduit une communication bidirectionnelle en temps réel.
  • 2015 : gRPC, basé sur Protocol Buffers et HTTP/2, renforce l'efficacité et la compacité des échanges (retour au binaire).

🔗 Voir Les API WEB exposées en HTTP pour plus de détail.
💬 spoiler : Nous retrouverons Protocol Buffers dans les formats géo à la mode.

ENSG

Les styles d'architecture

ENSG

Architecture monolithique (1/2)

"Une architecture monolithique est un modèle de développement logiciel traditionnel qui utilise une base de code unique pour exécuter plusieurs fonctions métier. Tous les composants logiciels d'un système monolithique sont interdépendants en raison des mécanismes d'échange de données au sein du système."

Source : aws.amazon.com - Quelle est la différence entre une architecture monolithique et une architecture de microservices ? :

ENSG

Architecture monolithique (2/2)

Pour illustrer le concept, nous analyserons les avantages et inconvénients avec :

⚙️ Mise en pratique : Nous débuterons l'étude d'un cas concret : IRL - un jeu qui varie les défis dans le monde réel!.

ENSG

Les styles d'architecture

Architecture client/serveur (1/2)

L'architecture client / serveur est la plus simple architecture en couche.

Illustration d'une architecture Client / Server avec QGIS branché directement sur une base de données.

ENSG

Les styles d'architecture

Architecture client/serveur (2/2)

Avec cette approche, le principe de fonctionnement est le suivant :

  • Le serveur attend les connexions sur un port réseau.
  • Le client initie la connexion.
  • Il envoie une requête selon un protocole défini (HTTP, DNS, SMTP...).
  • Le serveur traite la requête et renvoie une réponse.
  • La connexion est fermée (stateless) ou maintenue (connecté).

Mode stateless : chaque requête est indépendante (ex : HTTP/1.1, DNS).
Mode connecté : session persistante (ex : FTP, SSH, WebSocket).

⚙️ Mise en pratique : Phase 2 du cas concret IRL où nous analyserons les avantages et inconvients.

ENSG

Les styles d'architecture

Architecture 3-tiers

L'architecture 3-tiers se matérialisera souvent par la présence d'un intermédiaire entre le client et le stockage.

Illustration d'une architecture 3 tiers avec l'API OSM.

⚙️ Mise en pratique : Phase 3 du cas concret IRL où nous analyserons les avantages et inconvients.
NB : Un même composant jouera alors le rôle de client et de serveur (i.e. l'API joue le rôle de client de la BDD et de serveur pour JOSM).

ENSG

Les styles d'architecture

Architecture n-tiers

En pratique, nous aurons plus souvent des architecture n-tiers avec par exemple une couche pour répartir la charge sur plusieurs instances d'un service :

Illustration du principe des architectures n-tiers avec la répartition de charge.

...ainsi que des couches mettre en cache les réponses, pour filtrer les attaques (WAF),...

ENSG

Les styles d'architecture

Architecture pilotée par les événements (EDA) (1/2)

Dans une architecture pilotée par les événements (ou Event-driven Architecture (EDA)), les composants communiquent entre eux à l'aide de message :

Illustration du principe d'une architecture pilotée par les événements.

ENSG

Les styles d'architecture

Architecture pilotée par les événements (EDA) (2/2)

Nous distinguerons deux approches :

  • Publication/abonnement (Pub/sub) où les consommateurs s'abonnent à un canal pour recevoir les messages.
  • Flux d'événement (Event streaming) où les événements sont journalisées et où les consommateurs peuvent lire les anciens messages.

Nous inspecterons les possibilités offertes par RabbitMQ pour nous faire une idée précise.

Nous discuterons l'intérêt et les défis de ce type d'architecture à travers des cas d'utilisations en séance (partage de position, traitement asynchrone, orchestrateur de traitements,...).

ENSG

Les styles d'architecture

Architecture orientée services (SOA)

⚠️ Ancêtre des microservices — présenté ici pour la culture générale. (nous en discuterons l'intérêt et les limites en séance en faisant le lien avec EDA et pour introduire la partie suivante)

Dans une architecture orientée services (SOA), les applications communiquent entre elles à travers un Enterprise Service Bus qui offre un cadre pour l'interfaçage de services hétérogènes :

Illustration du principe de l'ESB dans les architectures SOA.

ENSG

Les styles d'architecture

Architecture microservices

Dans une architecture en microservice, l'application est décomposée en services légers se concentrant sur une tâche spécifique. Ils sont développés et déployés indépendamment et peuvent communiquer entre eux.

Illustration du principe d'une architecture microservice.

Nous analyserons en séance le cas de GeoServer cloud correspondant à son découpage en microservices. Nous discuterons aussi les avantages et inconvénients.

ENSG

Les styles d'architecture

Architecture serverless

⚠️ Davantage un mode de déploiement qu'un style architectural à part entière.

Dans une architecture serverless, les applications dépendent de services cloud pour exécuter des fonctions, stocker des données et gérer des événements sans que les développeurs aient besoin de gérer directement les serveurs.

En pratique, ce modèle amène souvent à coupler :

  • Une approche par microservices pour structurer les fonctionnalités (1)
  • Une approche basée sur des événements (EDA) pour les traitements asynchrones (ex : traitement long) ou déclenchés par des événements (ex : nouveau fichier déposé).

(1) Hébergement de fonctions simples (AWS Lambda, Azure Functions, ou Google Cloud Functions) ou de conteneurs (ex : Google Cloud Run)

ENSG

Les spécificités liées aux données géographiques

ENSG

Les spécificités liées aux données géographiques

La diversité des données

Les données géographiques prennent différentes formes avec des volumes et des modèles de complexité variables :

  • Des images
  • Des nuages de points
  • Des données vectorielles
  • Des fiches de métadonnées
  • ...
ENSG

Les spécificités liées aux données géographiques

La diversité des acteurs

De nombreux acteurs produisent des données géographiques :

  • Les acteurs collaboratifs (OSM)
  • Les acteurs publics nationaux (INSEE, IGN, BRGM...)
  • Les collectivités territoriales (régions, départements, regroupement de communes, communes,...)
  • Les entreprises privées (Google Maps, Waze, LaPoste,...)
ENSG

Les spécificités liées aux données géographiques

La diversité des modes de production

Cette diversité induit une diversité des modes de production des données avec en particulier :

  • Une production centralisée (dans une base nationale ou mondiale)
  • Une production décentralisée (à l'échelle infra-nationale) nécessitant une agrégation à l'échelle nationale pour être pleinement exploitable.
ENSG

Les spécificités liées aux données géographiques

La directive INSPIRE

Dans ce contexte, nous soulignerons l'importance de la directive européenne INSPIRE du 14 mars 2007 (1) qui impose pour certains thèmes :

  • Le catalogage des données via les métadonnées pour permettre la connaissance de l'ensemble des données déjà produites (2).
  • L'utilisation de standards pour diffusion des données (ex : les standards OGC) pour permettre l'intéropérabilité.

(1) Voir formations-geomatiques.developpement-durable.gouv.fr - La directive Inspire pour les néophytes

ENSG

Les spécificités liées aux données géographiques

Les standards CNIG

Pouvoir rechercher des jeux de données et permettre l'agrégation des jeux de données sont deux choses différentes.

Le Conseil national de l'information géolocalisée (CNIG) se charge à ce titre de la production de standards complémentaires à ceux d'INSPIRE.

Par exemple, la possibilité d'agréger des documents d'urbanisme (PLU, PLUi, CC,...) dans une base nationale au niveau du GéoPortail de l'Urbanisme dépend de l'existence et du respect de ces standards CNIG.

ENSG

Les spécificités liées aux données géographiques

Des formats dédiés

Les données géographiques s'appuient sur des formats dédiés pour :

  • Les données vectorielles (GML basé sur XML, GeoJSON basé sur JSON,...) avec une fâcheuse tendance à réinventer les formats pour mettre en avant la composante spatiale (1).
  • Les fiches de métadonnées (XML / ISO 19115)
  • Les images (ex : GeoTIFF)

(1) GeoJSON ne se contente pas de définir un format pour sérialiser des géométries, GeoJSON introduit le concept de FeatureCollection et de Feature relégant au second plan les properties autres que la geometry.

ENSG

Les spécificités liées aux données géographiques

Des services dédiés

De même, nous avons des services standardisés pour :

  • L'accès aux données images (WMS/WMTS/WCS)
  • L'accès aux données vectorielles (WFS) et aux traitements (WPS)
  • L'accès aux métadonnées (CSW)...

Nous noterons que :

  • Les standards en vigueur ont une forte dépendance aux technologies XML (XSD, WSDL,...) qui étaient à la pointe en 2007.
  • Des travaux de modernisation de ces standards sont en cours avec OGC API
ENSG

Les spécificités liées aux données géographiques

Des services gourmands en ressources (1/2)

Les services manipulant des données géographiques sont souvent gourmands en ressources systèmes :

  • Calcul géométrique
  • Rendu cartographique
  • Calcul d'itinéraire
  • Calcul d'isochrone
  • ...
ENSG

Les spécificités liées aux données géographiques

Des services gourmands en ressources (2/2)

Au niveau de l'architecture, il sera donc important de :

  • Porter une attention particulière à la scalabilité.
  • Mettre en oeuvre des mécanismes de cache.
  • Profiter de l'asymétrie entre la production et la consommation des données en s'appuyant sur des patrons tels CQRS.
  • Distinguer le respect des obligations INSPIRE et la réponse au besoin des utilisateurs (1).

(1) NB : INSPIRE n'impose pas de concevoir ses applications métiers en surcouche de WFS (où il faut télécharger "BDTOPO_V3:batiment" pour compter le nombre de bâtiments pour chaque "nature").

ENSG

Les infrastructures de données géographiques

ENSG

Les infrastructures de données géographiques

Définition

« Une infrastructure de données géographiques est une structure de mutualisation, d’échange et de diffusion de données géographiques à l’échelle d’un territoire et au bénéfice d’acteurs publics, et indirectement des citoyens. »

Source : Afigeo

ENSG

Les infrastructures de données géographiques

Objectifs

La mise en oeuvre d'une IDG répondra à plusieurs objectifs :

  • Centraliser et standardiser la gestion des données géographiques, y compris le catalogage
  • Offrir des services facilitant l'accès, la transformation et l'exploitation des données.
  • Promouvoir le partage et la réutilisation des données géographiques.
  • Se mettre en conformité avec la directive INSPIRE.
  • Mutualiser les coûts liés à l’acquisition et à la gestion des données.
  • Encourager la collaboration autour des données.
ENSG

Les infrastructures de données géographiques

Comment ça marche?

Dans ce cours sur l'architecture des SI, nous allons tâcher d'avoir une vision précise de la conception d'une infrastructure d'une IDG.

Nous allons traiter thèmes par thèmes, du stockage à la diffusion des données.

ENSG

Les infrastructures de données géographiques

Stockage des données (1/2)

Une IDG est amenée à stocker des données sous plusieurs formes :

  • Des fichiers (PDF, ZIP, Excels, CSV,...) avec plusieurs options de stockage :
    • Le stockage classique sur disque.
    • Le stockage en réseau (partage, NFS, FTP,...).
    • Le stockage objet (S3, Google Cloud Storage,...)
  • Des bases de données :
    • SQL (PostgreSQL, Oracle,...) offrant des garanties ACID
    • NoSQL (base orientée document, clé/valeur, recherche plein texte, graphe,...)
ENSG

Les infrastructures de données géographiques

Stockage des données (2/2)

Nous noterons qu'il peut être intéressant de :

  • Partitionner les données en cas de production décentralisée

Nous décrirons en séance le partionnement des données au sein du Géoportail de l'Urbanisme

  • Versionner les données (i.e. conserver l'historique des modifications) pour améliorer la traçabilité des changements, pouvoir les annuler et permettre une réplication incrémentale.

Nous verrons aussi le principe exploité par l'IGN dans le cadre de la production de la BDTOPO. Vous pourrez aussi inspecter le schéma de la base OSM où nous retrouvons une gestion de l'historique ("changeset", "nodes", "current_nodes",...)

ENSG

Les infrastructures de données géographiques

Alimentation en données (1/3)

Pour gérer les données, nous pourrons exploiter les approches suivantes en en cas d'accès direct aux bases de données (1) :

  • Utiliser un SIG
  • Utiliser un ETL (ex : FME, Pentaho,...)
  • Utiliser un programme (ex : ogr2ogr) ou un script (ex : import.py)

(1) Voire en présence d'un protocole donnant un contrôle total sur les données tel WFS-T.

ENSG

Les infrastructures de données géographiques

Alimentation en données (2/3)

Plus souvent, une plateforme proposera de choisir entre deux stratégies :

  • La publication des données (mode "push")
  • Le moissonnage de services tiers (mode "pull") (2)

(1) Nous analyserons en séance le cas de la publication de données vecteurs.

(2) Nous inspecterons le cas de OpenDataSoft qui propose entre autre des moissonneurs

ENSG

Les infrastructures de données géographiques

Alimentation en données (3/3)

En offrant un contrôle limité, la plateforme pourra ainsi traiter un besoin récurrent : Valider les données avant leur intégration afin d'assurer l'intégrité de la base de données.

ENSG

Les infrastructures de données géographiques

Modélisation des données (1/3)

Documenter le modèle (conceptuel) des données permet l'exploitation des données par les utilisateurs.

Mettre à dispositon le schéma (implémentation) des données dans un format exploitable permet d'automatiser :

  • La validation des données dans le cadre des publications de données.
  • La génération des formulaires pour guider dans la saisie.
ENSG

Les infrastructures de données géographiques

Modélisation des données (2/3)

Nous discuterons en séance différentes appproches possibles :

ENSG

Les infrastructures de données géographiques

Modélisation des données (3/3)

Nous insisterons ainsi sur l'importance de la diffusion de schémas exploitables et mentionnerons l'existence d'un référentiel de schémas de données publiques : schema.data.gouv.fr.

ENSG

Les infrastructures de données géographiques

Catalogage (1/3)

Les mécanismes de catalogage mis en oeuvre dans le cadre de la directive INSPIRE se reposent sur :

  • La rédaction de fiche de métadonnées au format ISO 19115 pour les jeux de données et les services.
  • Le moissonnage de ces fiches par le www.geocatalogue.fr.
  • Le moissonnage des catalogues nationaux à l'échelle Européenne ( c.f. inspire-geoportal.ec.europa.eu ).

Nous prendrons le temps d'inspecter quelques fiches de métadonnées et le modèle correspondant (ignf.github.io - Metadata).

ENSG

Les infrastructures de données géographiques

Catalogage (2/3)

En terme d'outils, nous noterons :

Aussi, nous mentionnerons :

ENSG

Les infrastructures de données géographiques

Catalogage (3/3)

Vu la complexité du modèle XML, nous noterons aussi qu'il est possible pour une plateforme de :

  • Collecter les informations à renseigner dans les métadonnées.
  • Générer des fiches conformes.

NB : Si vous demandez aux utilisateurs de remplir des fiches XML, vous avez de bonnes chances qu'ils copient/collent des fiches existants (sans penser à modifier les identifiants...)

ENSG

Les infrastructures de données géographiques

Diffusion vecteur (1/4)

Pour l'accès aux données vectorielles, nous noterons que :

  • La directive INSPIRE amène généralement à mettre en oeuvre le standard WFS.
  • Il est possible de s'appuyer sur des outils libres tels GeoServer ou MapServer pour la mise en oeuvre.
ENSG

Les infrastructures de données géographiques

Diffusion vecteur (2/4)

Nous inspecterons quelques exemples de requête WFS en séance :

ENSG

Les infrastructures de données géographiques

Diffusion vecteur (3/4)

Nous remarquerons ainsi qu'un service WFS est une API REST avec des capacités intéressantes (notamment en présence de l'extension cql_filter de GeoServer).

ENSG

Les infrastructures de données géographiques

Diffusion vecteur (4/4)

Nous mentionnerons toutefois :

  • Le côté vieillissant de GetCapabilities et les travaux de modernisation en cours via OGC API - Features.
  • Les limitations fonctionnelles de WFS par rapport à des API REST/JSON telle l'API Explore d'Opendatasoft (ex : opérateur d'agrégation tels "group by", "sum",...)
  • Le droit d'utiliser des API REST/JSON métiers en complément de WFS dans son système! (pour répondre aux besoins métiers et aux obligations INSPIRE)
  • La possibilité de développer ces API REST/JSON en proxy sur des WFS (c'est l'approche retenue pour apicarto.ign.fr)
ENSG

Les infrastructures de données géographiques

Diffusion cartographique (1/5)

Pour la diffusion cartographique, nous mettrons principalement en oeuvre :

ENSG

Les infrastructures de données géographiques

Diffusion cartographique (2/5)

Nous insisterons sur le fait que :

  • Le rendu cartographique est une opération coûteuse.
  • WMS implique un rendu à la demande.
  • WMTS et TMS permettent la mise en cache ou le pré-calcul des tuiles de la pyramide d'image.
ENSG

Les infrastructures de données géographiques

Diffusion cartographique (3/5)

En matière d'outils :

ENSG

Les infrastructures de données géographiques

Diffusion cartographique (4/5)

Enfin, en matière de symbolisation, nous noterons :

  • La présence d'un standard SLD pour la définition des styles avec des variantes en fonction des outils (c.f. SLD Extensions in GeoServer).
  • L'existence d'un projet ciblant la rédaction de styles génériques : GeoStyler
ENSG

Les infrastructures de données géographiques

Diffusion cartographique (5/5)

Enfin, il est possible de diffuser des cartes sous formes de tuiles vectorielles.

Cette technologie :

  • Offre une grande liberté dans la symbolisation et les intéractions en reportant le rendu côté client.
  • Reprend le principe de la pyramide WMTS avec des données dans un format basé sur Protocol Buffers (c.f. Vector tiles standards)

Mise en garde : Des géométries de taille et de complexité variables ne permettront pas d'exploiter efficacement cette technologie (généralisation cartographique non triviale).

ENSG

Les infrastructures de données géographiques

Services de calcul

Nous trouverons potentiellement des services de calcul dans une architecture. Par exemple :

  • Un service de calcul d'itinéraire
  • Un service de calcul d'isochrone
  • ...

Le standard OGC Web Processing Service (WPS) et de son successeur OGC API - Processes peuvent être utilisés pour mettre en oeuvre de tels services.

Toutefois, nous rencontrerons la plupart du temps des API REST/JSON.

ENSG

Les infrastructures de données géographiques

Exemple d'architecture

Autres critères possibles : - Coût de développement - Coût de déploiement - Facilité de déploiement (rapidité de livraison) - Maintenabilité (temps de prise en main du code) - Simplicité - Sécurité / Traçabilité - Durabilité - Accessibilité - Sobriété numérique / Éco-responsabilité / Éco-conception / RSE - Ergonomie / Expérience utilisateur (UX)

Par exemple : - Nous utiliserons un service dédié pour gérer les authentifications (ex : AD LDAP, Keycloak, DEX,...) - Un service renvoyant l'altitude d'un point ne prendra pas paramètre une adresse mais une position.