mise en place d`un serveur spatial

JEAN-YVES GARINET
COMMUNICATION & SYSTEMES
M I S E E N P LAC E D ’U N
S E RV E U R S PAT I A L
RETOURS D’EXPERIENCES
S E RV E U R S S PA T I AU X , I D S , S I G – L E C O N T E X T E – L E S Q U E S T I O N S
Il est devenu commun de dire que la mise en place d’un Système d’Information
Géographique est transverse à une organisation, il en est toujours de même au XXIème siècle
quand le SIG se transforme en IDS ... Infrastructure de Données Spatiales.
La définition , le périmètre fonctionnel , l’architecture de ce SIG/IDS fait donc souvent
l’objet de longues discussions, arbitrages et décisions dans un collectif partenarial multiple, que ce
soit entre plusieurs entités ou plusieurs services d’une même collectivité ou entreprise. Lorsque le
projet informatique est enfin défini et consigné dans un cahier des charges, il est réalisé et
déployé selon les termes de ce cahier des charges et il reste alors le travail le plus difficile :
l’adhésion des utilisateurs. Ceux ci se retrouvent t-ils dans le système déployé ? Sont ils satisfaits
de son implémentation ? de ses fonctionnalités ? de son niveau de service ? de ses performances ?
Il y a très souvent une déception exprimée par les utilisateurs, déception qui est d’autant plus
grande au regard du travail partenarial qui a été mené en amont.
Le processus de mise en œuvre d’une IDS , du projet jusqu’à son utilisation opérationnelle
est une succession d’étapes avec transmission et partage d’informations et documents . Le cahier
des charges du système d’information est un document central, point de passage entre les
utilisateurs et l’équipe de réalisation. Le contenu de ce cahier des charges est déterminant pour la
réussite du projet d’IDS. Notre réflexion porte sur ce cahier des charges : critique de choses vues,
conseils , spécifications à ne pas oublier , exigences importantes, etc…
Nous séparerons toutefois deux contextes assez distincts d’utilisation de serveurs spatiaux :
1. Les Infrastructures de Données Spatiales d’une collectivité ou d’une entreprise,
brique géo-informatique au service des applications métiers. L’IDS est interne , au
service de l’activité interne de la collectivité ou entreprise, l’ouverture externe de
cette IDS s’exerce dans le cadre de ses missions auprès du public. On parle souvent
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
1
de cartographie et urbanisation des SI, voire quelquefois d’orchestration ou
chorégraphie du système d’information !!
2. Les IDS multipartenariales , entrepôt mutualisé de données et services que l’on
trouve généralement au niveau régional , mais aussi en interne aux grandes
administrations. Ces IDS ne sont pas des briques internes à quelque chose de plus
grand, mais une fin en soi , s’articulant bien sûr avec des contextes externes, mais
pas dans la réflexion d’un systèmes d’information plus global.
Le retour d’expérience, exposé ci-après, se base sur quatre situations distinctes :
La réalisation de composants de systèmes d’information intégrant un serveur spatial
pour un client
L’analyse de cahiers des charges lors de réponses à appel d’offre intégrant la mise en
place d’un serveur spatial
Le parcours critique de sites publics internet, composantes d’une IDS.
Les questions posées par Internet sur le forum Georezo dans les domaines BD et
Webmapping.
LE CAHIER DES CHARGES IDEAL
Il n’y a pas de modèle unique de cahier des charges pour toutes les situations , mais il existe 5
rubriques indispensables (pour tout système d’information) , dont la teneur peut évidemment
varier selon les contextes. Le rédacteur du cahier des charges doit obligatoirement se plonger
dans les 5 rubriques suivantes :
Les spécifications Fonctionnelles
Ce que doit faire mon système et ce qu’il ne fait pas. Les spécifications
fonctionnelles sont souvent organisées hiérarchiquement , quelquefois classées et
numérotées. Elles doivent faire l’objet d’une rédaction soignée et peuvent être
illustrées.
Cette section est généralement présente, mais souvent imprécise avec des concepts
aux contours trop lâches. Ceci a pour conséquence la mise en place d’un système
très compliqué à comprendre pour les utilisateurs.
Les spécifications Opérationnelles
Qui utilise mon système ? Quels sont les différents profils ? Quels sont leurs
privilèges ? Combien sont ils ? Quelles sont les horaires de service ?
Cette section est souvent absente ou bien très peu détaillée . Les conséquences à
terme sont multiples … Fonctions interdites … Situations de blocage … Serveur
fermé le week-end … indisponible pour maintenance ….
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
2
Les spécifications d’Interface
Avec qui mon système doit-il communiquer ? Quel protocole ? Quel formats de
données doivent être supportés ?
Section souvent oubliée, beaucoup pensent qu’un serveur spatial est capable d’
absorber toutes sortes de choses dans des formats les plus exotiques et surtout
s’adapter à tous les modèles de données !!!
Les spécifications d’Architecture et de Réalisation
Mon système doit s’inscrire dans un schéma directeur avec telle technologie
(.NET, J2EE). Mon système doit être réalisé en OpenSource (ou le contraire avec tel
éditeur !!).
C’est dans cette section que l’on trouve souvent beaucoup trop de choses !!! Au
détriment de la rubrique fonctionnelle. Les conséquences d’une mauvaise réflexion
ou de mauvais choix peuvent être dramatiques. Dans beaucoup de situations, il vaut
mieux laisser l’intégrateur faire ce choix et le responsabiliser sur le moyen terme.
Les spécifications de Performances
Quel est le nombre d’accès simultanés ? Quel délai maximal d’affichage de ma
carte ? …Quel volume de données ?
Cette section est quelquefois rédigée , rarement vérifiée en recette , mais on regrette
trop souvent de ne pas l’avoir imposée. Combien de sites géographiques sont
inexploitables par défaut de performances ?
Notons que ces cinq rubriques sont rarement indépendantes. Dans de très nombreuses
situations (IDS de petites tailles) , les études préalables pourront faire converger les spécifications
fonctionnelles avec ce proposent les éditeurs et ainsi rechercher une solution « sur étagère »
plutôt que laisser un intégrateur proposer une solution.
Il y a toutefois deux types de danger (situations déjà rencontrées) :
-
Le marché est orienté directement vers un éditeur alors que la
problématique d’intégration dans un SI (architecture, interfaces,
performances) aurait nécessité l’expérience d’un intégrateur. Cette situation
se retrouve souvent dans les collectivités.
-
Le marché est confié à un intégrateur qui ré-invente et re-développe des
fonctions déjà existantes sur étagère. Cette situation arrive souvent lors de
choix OpenSource trop peu consolidés.
En plus des 5 rubriques associées à la description du système à réaliser , il existe trois autres
rubriques , qu’il ne faut absolument pas négliger : Les plans de développement (phases du projet)
de formation et de maintenance. Il n’y a pas de spécificités particulières relatives aux IDS. Mais
l’expérience fait très souvent apparaître des défauts dans les dispositifs de maintenance.
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
3
Q U E L Q U E S C R I T I Q U E S E T C O N S E I L S PA R R U B R I Q U E
LES SPECIFICATIONS FONCTIONNELLES
Parmi toutes les fonctions de systèmes s’articulant autour d’un serveur spatial, il y en a deux
qui méritent d’être creusées plus particulièrement :
Publier … des choses
Consulter des données … et des métadonnées
La fonction de publication , quand elle est imprécise, peut amener des défauts
« structurels » du système :
Que publie-t-on ? des cartes ou des données ? Qu’est-ce qu’une carte ? Qu’est-ce
qu’une donnée ?
Où publie-t-on ces choses (cartes ou données) , sur le serveur ou sur Internet ?
Pour certaines personnes, une carte est un ensemble de couches de données avec une
symbologie choisie, pour d’autres, c’est un résultat final, issu d’une rédaction ayant pu avoir en
entrée du travail de rédaction un ensemble de couches. Les confusions peuvent être amplifiées si
la solution technologique utilise le mot map , layer etc..
Et plus fondamentalement … pour « présenter » une donnée, ne faut-il pas obligatoirement
faire une « carte » ?
Ce manque de réflexion et de précision se retrouve dans les IDS qui ont pour mission le
partage d’information géographique : la limite entre l’entrepôt de données partagées et le
« WebSIG » est floue. Le manque de réflexion est souvent du à une précipitation des acteurs vers
des solutions technologiques (pour ne pas citer MapServer) , transférant le centre de gravité de la
discussion sur des problèmes techniques.
Dans le domaine de la consultation de données, nous souhaitons tout d’abord pointer les
effets désastreux du terme Webmapping mal approprié. Ce terme peut être utilisé pour décrire
une fonction du système (une volonté de diffuser des cartes sur intranet/internet) et ainsi
soulever deux effets collatéraux constatés :
La carte affichée sur internet n’est que la partie émergée d’un iceberg
appelé système d’information (basé sur un serveur spatial) , système occulté
dans le cahier des charges. Si des cartes sont publiées sur le Net, c’est à
partir de données qui doivent être gérées dans un serveur de données, ce
serveur de données doit être administré et mis à jour des informations
provenant de systèmes d’informations internes etc… La volonté de mettre
en place des cartes consultables sur Internet fait donc apparaitre l’absence
de l’étape préalable et nécessaire consistant à mettre justement en place un
serveur spatial et ses services associés (administration, mises à jour, etc ..).
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
4
L’utilisation directe de solutions sur étagère met à disposition des
utilisateurs des interfaces de consultation de type SIG (gestionnaire de
couches) , peu conviviales et très éloignées de leur métier.
Une dernière critique dans la spécification fonctionnelle est relative aux accès « WMS » où là
encore, le discours technologique prend le pas sur l’expression de besoins fonctionnels. Pour les
IDS ouvertes , as-t-on réellement besoin de nommer « WMS » les sources externes accessibles à
l’utilisateur final et ainsi les ranger dans un compartiment spécial ? Cet utilisateur final a-t-il
réellement besoin de savoir que les sources utilisées par le serveur cartographique qu’il consulte
sont internes ou externes au serveur ?
LES SPECIFICATIONS D’INTERFACE, ARCHITECTURE ET DE REALISATION
Dans ces domaines, les cahiers des charges peuvent être extrêmement différents selon :
La taille de l’IDS en jeu (de quelques utilisateurs à plusieurs centaines simultanés).
L’IDS d’une communauté de communes ne s’aborde pas de la même façon que le
Géoportail IGN.
La forte connotation métier, qui est en opposition avec la « pure » donnée
géographique (si celle-ci existe vraiment ?). L’infrastructure de données
géographiques de la Police Nationale ou de RFF n’a pas la même vocation qu’un
CRIGE …
La présence et les compétences d’une équipe informatique en charge de
l’exploitation et de la maintenance du système. Ceci peut contraindre ou orienter
fortement le cahier des charges.
Malgré ces disparités, nous pouvons apporter quelques conseils :
Dans la mesure où l’infrastructure de données spatiales s’inscrit dans un système
d’information plus large , au service des métiers de la collectivité ou de l’entreprise, il
nous apparaît nécessaire et vital que les normes et standards du schéma directeur
informatique de la collectivité ou de l’entreprise soient applicables à l’information
géographique. Pour parler autrement , l’IDS ne doit pas, à long terme, être bricolée dans
un coin avec du PHP/MapServer/OpenLayers quand l’organisme construit son SI dans
une infrastructure Java/J2EE.
Dans la même veine et dans le même contexte mais en terme d’interface et de modèle :
L’information géographique doit se plier aux règles de définition et de gestion du modèle
de données de l’entreprise. Celle-ci nécessite au « géomaticien » de mettre ses lunettes
d’informaticien pour changer d’angle de vue. Pour l’informaticien en charge du design de
son système d’information, la structure de la base de données est « drivée » par un
modèle (UML, MERISE, MEGA,…) alors que pour le « géomaticien » , la structure de
la base de données est souvent souple, « drivée » par les formats d’entrée, voire
modifiable par un utilisateur…
Toujours dans le domaine de l’infrastructure « lourde » de type Java/J2EE, faire bien
attention au souci de performances : En imposant l’utilisation de couches multiples pour
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
5
respecter le modèle MVC et l’utilisation de middleware de type Hibernate, on peut se
retrouver devant une machinerie complexe et lente => Confier au SGBD/Serveur la
complexité des requêtes.
SPECIFICATIONS DE PERFORMANCES
C’est souvent le manque de performances qui limite l’adhésion des utilisateurs … Les
exemples sont ici très nombreux…. Tout l’effort de construction d’une IDS s’effondre dès
les premiers jours d’utilisation… Et pourtant, c’est rarement le bout de la chaine qui est en
cause (la ligne finale ADSL ou le réseau intranet) … Comment faire ?
Une des causes les plus souvent constatées provient de l’hébergement du (ou des
serveurs) insuffisamment dimensionné, l’hébergement qui trop souvent fait les frais
des contraintes budgétaires. Les solutions d’hébergement externalisées, voire le
cloud computing sont des solutions à analyser sérieusement même pour une
collectivité ou une entreprise. Cette ligne budgétaire doit être anticipée très tôt, la
performance passe presque avant les fonctionnalités.
Sur le plan organisationnel, il faut au maximum responsabiliser l’intégrateur sur les
performances du système par l’expression de spécifications de performance et la
tenue de tests de réception. Attention, l’intégrateur ne pourra s’engager que s’il
maitrise toute l’installation et les conditions d’hébergement du système, il ne peut y
avoir d’engagement de performances si le client impose son propre hébergement.
En amont, il est intéressant pour l’intégrateur de disposer d’estimations d’accès au
système. Ces estimations doivent être précises et renseignées sur le comportement
des opérateurs (nb d’accès à une carte, déplacements ? , zoom ?). Dans certains cas,
l’architecture même du serveur peut dépendre de ces comportements (caches,
vectoriel sur poste client, etc..).
SPECIFICATIONS DE MAINTENANCE
La maintenance, c’est un peu comme la performance, la dernière roue du carrosse …Et
pourtant, la correction des anomalies , les évolutions, sont des signes de dynamique de
l’application et contribuent à l’adhésion des utilisateurs. Voici ci-dessous quelques conseils :
Le choix de solutions (Opensource ou éditeur) doit se mesurer à moyen terme, en
intégrant un paramètre de pérennité et dynamique de la communauté (dans le cas de
l’Opensource). Dans ces temps de technologie évolutive et chaotique, l’obsolescence
guette et peut tomber rapidement sur un produit ou composant.
Le management de la maintenance n’est souvent pas assez rigoureux et tout comme
l’hébergement, il doit est budgetisé très tôt dans le processus d’estimation des coûts.
CONCLUSIONS
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
6
Mettre en place une Infrastructure de Données Spatiales … ou un serveur spatial dans sa
collectivité ou entreprise , c’est un projet de système d’information, régi par les règles et codes
et standards de l’informatique , le « géo » qui précède ne justifie pas un traitement particulier. Le
cahier des charges , document phare de transmission d’information entre les utilisateurs et le (ou
les) prestataires de réalisation, doit suivre les 3 principes énoncés ci-dessous :
Il doit être précis et cohérent : Les concepts employés (cartes, données, publication,
consultation, services, ..) doivent avoir la même signification pour tous les acteurs du
projet.
Il doit être complet et aborder les 5 thèmes cités (fonctions, opérations, interfaces,
architecture/réalisation, performances).
Il doit rester proche du besoin des utilisateurs et éviter de verser trop tôt dans la
technologie.
Jean-Yves Garinet – Rencontres SIG La Lettre – Mai 2010
7