Architecture du Système d information sur l eau

Transcription

1 Architecture du Système d information sur l eau Livre Vert Titre Architecture du Système d Information sur l Eau. Livre vert Créateur Système d information sur l eau Sujet Architecture ; convention d'århus ; eau ; géoservices ; information environnementale ; interopérabilité ; RNDE ; Sandre ; SIE ; système d'information ; web Description Livre vert, objet d'une consultation des parties intéressées, en vue de la définition d'une architecture commune pour le Système d'information sur l'eau Éditeur Ministère de l écologie et du développement durable Contributeur René Lalement, Pierre Lagarde Date Type Text Format PDF Identifiant MEDD/DE/SIE Langue fr Couverture France Droits Ministère de l écologie et du développement durable Version Finale

2 L objectif de ce Livre vert est d entreprendre une consultation des parties intéressées à l information environnementale publique dans le domaine de l eau afin de parvenir à la définition et à la mise en œuvre d une architecture technique commune pour le Système d information sur l eau. Ce Livre vert s inscrit dans les orientations définies par le Comité national du Système d information sur l eau, réuni le 30 avril 2003, selon lesquelles l architecture du SIE devait «viser comme cible l interopérabilité entre les différents outils constitutifs du système d information» et comporter des préconisations «pour l adaptation des outils existants et pour l élaboration des nouveaux outils». Dans un premier temps, une étude sur l état de l art des solutions techniques d interopérabilité a été conduite en 2004, dans le but de déterminer les technologies appropriées et de les tester sur des cas d utilisation réels. La rédaction de ce Livre vert constitue la seconde étape, et précède l écriture des spécifications techniques de l architecture et des applications qui s y intégreront. La mise en œuvre de ces spécifications devra d abord bénéficier aux programmes de surveillance de la directive cadre sur l eau, opérationnels dès la fin 2006, selon une approche progressive et décentralisée. En présentant les principales questions, ainsi que des éléments de proposition, ce Livre vert entend susciter un engagement constructif des parties intéressées en vue de la réalisation, dans les années à venir, d un réel «système d information» à la hauteur des nouveaux enjeux. Cette démarche bénéficiera de la pratique de la concertation, acquise par les partenaires du RNDE, le réseau national des données sur l eau, depuis sa création en Toutes les parties intéressées sont donc invitées à commenter les questions traitées dans le présent document. Les commentaires devront parvenir à l adresse suivante, par courrier postal ou électronique, avant le 1 er mars 2005 : Mission du Système d information sur l eau, Direction de l eau, Ministère de l écologie et du développement durable, 20 avenue de Ségur Paris [email protected] 2

3 Table des matières 1 CONTEXTE Le Système d information sur l eau Du RNDE au SIE Les parties intéressées et les processus métiers L infrastructure et les processus de gestion des données Le constat actuel La surveillance Le contrôle L évaluation Le rapportage L information sur les risques Banques et accès aux données La diffusion de l information Les enjeux de l architecture Les enjeux pratiques Les enjeux politiques Les enjeux de gouvernance DOUZE QUESTIONS PRINCIPALES Architecture répartie et subsidiarité Non-intrusion Unicité de la donnée Interopérabilité sémantique Interopérabilité technique : représentations et protocoles Normes ouvertes et pérennité de l information Cadre d interopérabilité Utilisation de l information géographique Données à voir et données à utiliser Couplage faible par des services Métadonnées Une architecture fondée sur le Web ÉLÉMENTS DE PROPOSITION Les ressources Le point de vue métier Les données Les métadonnées Les services Les URI Les acteurs du système d information L usager Le producteur de données Le diffuseur de l information Le producteur du référentiel Le gestionnaire des catalogues Cas d utilisation du SIE Syndication de contenus web Publication et mise à jour de données du référentiel Saisie des données Diffusion des informations Accès à des géoservices Schéma général de l architecture Mise en œuvre ANNEXE : TECHNOLOGIES UTILISÉES Les canaux de communication L'infrastructure des services Le style REST Le protocole SOAP Les géoservices Représentation de l information Représentation des métadonnées Services d annuaire Déploiement Sécurité Performances Supervision

4 1 CONTEXTE 1.1 Le Système d information sur l eau Du RNDE au SIE Le Système d information sur l eau (SIE) est formé par des jeux de données, des métadonnées et des services et par l infrastructure sous-jacente, organisés dans le but de répondre aux besoins des parties intéressées en matière d information environnementale publique dans le domaine de l eau. Sa mise en œuvre résulte, dès 1992 (l année de la seconde loi sur l eau), de la création du Réseau national des données sur l eau (RNDE) visant à une gestion cohérente des données sur l eau, notamment au travers : d un protocole d accord : le protocole RNDE ( ), d un service chargé de la normalisation des données (sémantique) et des échanges informatiques de données (syntaxe) : le Sandre 1 (créé en 1993), de recommandations sur l architecture d échange des banques de données ainsi que du guichet RNDE, animé par l Office international de l eau (créé en 1992). Trois bonnes idées sont alors mises en œuvre : un réseau de partenaires (administrations, établissements publics, entreprises et associations, signataires d un protocole), une interopérabilité sémantique, l association étroite de compétences dans les domaines de l eau et des systèmes d information. Cette organisation résultait d une volonté partagée par la Direction de l eau (créée également en 1992) et par ses partenaires. Plus récemment, le système d information se place dans un contexte plus exigeant, non seulement volontaire, mais aussi juridique : la Convention d Århus de 1998 (entrée en vigueur le 6 octobre 2002) et la directive cadre sur l eau 2. C est pourquoi la Direction de l eau a entrepris de renforcer l organisation du SIE et son fonctionnement : la circulaire du 26 mars 2002 répartit les rôles entre les différents acteurs publics, fixe les modalités de financement de leurs actions et prescrit la réalisation d un schéma directeur des données sur l eau (SDDE) dans chaque bassin ; le protocole du Système d Information Eau (protocole SIE), signé en juin 2003, succédant au protocole RNDE, définit les obligations des acteurs de l eau qui ont déclaré y adhérer 3, en matière de production, de conservation et de mise à disposition des données ; il précise également le mode d organisation au niveau national (comité national et groupe de coordination) et au niveau de chaque bassin ; la Mission du Système d information sur l eau (Mission SIE), mise en place courant 2004, est responsable de la mise en œuvre du SIE et de la coordination des projets qui le composent. Enfin, l'avant-projet de loi sur l eau et les milieux aquatiques, qui vient d'être transmis au Conseil d'état, se propose de donner un cadre juridique au système d'information sur l'eau et de permettre aux collectivités locales de participer à sa constitution ; il prévoit également de confier à un nouvel établissement public de l État, l Office national de l eau et des milieux (1) Service national d'administration des données et des référentiels sur l'eau ( (2) Directive 2000/60/CE du Parlement européen et du Conseil, du 23 octobre 2000, établissant un cadre pour une politique communautaire dans le domaine de l'eau. (3) Les signataires sont à l'heure actuelle : les six agences de l'eau, le BRGM, le CSP, la Direction de l'eau, la Direction de la pollution et de la prévision des risques, EDF, l'ifen, l'ifremer et l'office international de l'eau. 4

5 aquatiques (ONEMA), sa coordination technique et la constitution de son infrastructure commune Les parties intéressées et les processus métiers Rappelons d abord que l information environnementale publique est définie par la convention d Århus 4 et la directive sur l'accès à l'information 5 ; cette notion englobe l ensemble des informations détenues par des autorités publiques ou pour leur compte qui ont trait à l état de l environnement, aux pressions qu il subit, aux impacts de ces pressions, aux mesures adoptées et à l impact de ces mesures, aux analyses économiques, à l évaluation des politiques publiques, etc. À ce titre, le système d information sur l eau s intégre dans un système d information global pour l environnement, qui est également en cours de constitution. Les parties intéressées sont a priori : le public, qui se voit reconnaître un droit d accès à cette information ; les autorités publiques, qui doivent répondre aux demandes d information et doivent progressivement rendre l information accessible au moyen des technologies de l information ; l État, qui est en outre le garant de l exercice de ce droit et qui doit réaliser et publier des catalogues de métadonnées pour l ensemble des données publiques. Parmi ces parties intéressées, seules les autorités publiques (dont l État) ont des obligations. Dans le cas des informations détenues «pour le compte d une autorité publique» (c est le cas d une délégation de service public), ces obligations incombent à cette autorité publique. Dans le domaine de l eau, les parties intéressées sont plus particulièrement les parties représentées dans les instances de concertation (comité national de l eau, comités de bassin, commissions locales de l eau, ), notamment les associations de protection de l environnement, les usagers de l'eau et les élus. Les données concourant à cette information environnementale publique sont, en ce qui concerne l eau, définies principalement par la directive cadre sur l eau et d autres textes de la législation communautaire ou nationale (par exemple, la directive «eaux résiduaires urbaines», la loi «risques»). L ensemble de ces textes prescrit à l État et aux autorités publiques des activités liées à l information (qu elle soit produite, traitée ou utilisée) qui constituent, dans la terminologie des systèmes d information, des processus métier : surveiller l état de l environnement ; contrôler les activités ayant des impacts sur l état de l environnement ; évaluer les politiques publiques qui ont une incidence sur l environnement ; rapporter au Parlement, à la Commission européenne ou à des organismes d évaluation (OCDE, Agence européenne de l'environnement, Eurostat, OSPAR) les données requises par ceux-ci ; informer les populations des risques naturels auxquels elles sont exposées ; (4) Convention sur l'accès à l'information, la participation du public et l'accès à la justice en matière d'environnement (convention d'århus), adoptée le 25 juin (5) Directive 2003/4/CE du Parlement européen et du Conseil du 28 janvier 2003 concernant l accès du public à l information en matière d environnement et abrogeant la directive 90/313/CEE du Conseil. 5

6 bancariser 6 les données pour les conserver de manière pérenne et en permettre l accès ; diffuser l information environnementale publique. Il faut noter que la plupart de ces processus sont partagés entre plusieurs autorités publiques, ce qui justifie l existence d une architecture commune du système d information. Plusieurs de ces processus sont requis par la directive cadre sur l eau, qui fixe au 22 décembre 2006 la date à laquelle les «programmes de surveillance» doivent être opérationnels ; ceci implique que ses résultats peuvent dès lors être intégrés dans des bases de données, rapportés à la Commission européenne et diffusés auprès du public L infrastructure et les processus de gestion des données L infrastructure du système d information est un ensemble de dispositifs informationnels : ce terme très général s applique aussi bien à des objets techniques, matériels ou logiciels (les composants : des capteurs, des réseaux de communication, des ordinateurs, des bases de données, des sites web), aux instances de coordination et de décision et aux instruments juridiques ou administratifs qui règlent leur usage. Ces dispositifs sont employés pour réaliser des processus de gestion de données : l acquisition des données (à partir de capteurs, de mesures, de questionnaires, de déclarations, etc.) ; la collecte des données (par un réseau de mesure, une enquête, une procédure administrative, etc.) ; la validation des données (par des experts ou des procédures automatisées) ; la sauvegarde des données (dans des bases de données, entrepôts de données, etc.) ; le traitement et la valorisation des données (à des fins d évaluation, de modélisation, de synthèse, de statistiques, ) ; la publication des données. Les dispositifs sont fréquemment associés à un processus de gestion de données particulier (d acquisition, de collecte de données, etc.) qui les emploie : par exemple, une base de données est un dispositif de sauvegarde des données, un site web est un dispositif de publication des données. Chaque processus métier fait appel à un ou plusieurs processus de gestion des données. Par exemple, la surveillance fait appel à l acquisition, la collecte, la validation et la sauvegarde ; l évaluation suppose que la surveillance et la bancarisation sont réalisées et fait appel à la collecte de données supplémentaires (par exemple statistiques) et à leur sauvegarde ainsi qu au traitement des données ; le rapportage et l information du public supposent que la surveillance, le contrôle et la bancarisation sont réalisés et font appel au traitement et à la publication des données. Le rôle du système d information est d organiser l emploi des dispositifs informationnels afin de permettre à l État et aux autres autorités publiques de réaliser leurs processus métier (c est-à-dire, de faire leur métier). L architecture du système d information consiste à décrire les principes de cette organisation, notamment la façon dont les processus de gestion des données interagissent (6) Cette terminologie «bancaire» semble être un legs du RNDE et une préfiguration de la notion de service apparue plus récemment.. Une banque de données permet à de multiples «clients» de déposer ou d'extraire des données, à la différence d'une simple base de données ; «bancariser» un certain type de données, c'est intégrer l'ensemble des données de ce type dans une ou plusieurs banques de données. 6

7 entre eux et avec les utilisateurs et comment ils répondent aux besoins des processus métier. 1.2 Le constat actuel Les principes fondateurs du RNDE (réseau de partenaires, interopérabilité sémantique, association des compétences métier et informatique) se sont révélés efficaces et restent pertinents. Cependant, le constat s'avère mitigé dès que l on examine les possibilités actuelles du système d information au regard des processus métiers qu il doit effectuer. À ce constat s ajoute l évolution technologique des systèmes d information : la généralisation des technologies du Web et des standards ouverts pour l interopérabilité des systèmes ont tardé à être utilisés. À ce jour, peu de partenaires ont réellement investi dans cette voie. Il faut souligner que l architecture recommandée du RNDE ne constituait pas à proprement parler une architecture de système d information ; c était plutôt la définition de dispositifs de gestion des données, organisés pour permettre des échanges entre partenaires, condition essentielle qui a effectivement contribué à son succès. La standardisation des données par le Sandre et les échanges selon ces spécifications ne se sont pourtant pas suffisamment généralisés, hormis pour les échanges nationaux. L adoption et l usage effectif de XML en tant que format d échanges ont été tardifs (2004). On peut observer que le développement d outils spécifiques par les partenaires permet de répondre au mieux aux besoins de leurs utilisateurs directs, mais ne prend pas toujours en compte les besoins communs du SIE, notamment la réutilisation des fonctionnalités ou la notion de service à la disposition des tiers parce que ces besoins n ont pas été clairement formulés. Les mêmes fonctionnalités sont alors développées plusieurs fois en proposant à l utilisateur des interfaces proches mais diverses, ce qui peut être déroutant : par exemple, la multitude d interfaces cartographiques sur les sites web, des atlas de stations ou des outils de consultation des référentiels du Sandre. La difficulté de prendre en compte les besoins des usagers a conduit des partenaires à développer en commun des outils supplémentaires, mais hors du Système d information sur l eau les «serveurs producteurs» pour l hydrométrie, l application GDES pour la qualité des eaux de surface continentales, l application BDERU pour le rapportage en matière d assainissement urbain alors que des applications existaient dans chacune de ces thématiques et ne rendaient pas les services attendus. Sans prétendre dresser un bilan du système d information, le reste de cette section présente un éclairage du point de vue métier sur la situation actuelle La surveillance C est ici que l interopérabilité mise en place grâce au Sandre a été la plus efficace, permettant la coopération de nombreux organismes et rendant possible l évaluation et la diffusion de l information. Cependant, ce n est que récemment que l on a pu constituer des métadonnées sur le millier de réseaux d observation existants en France, les coûts de ces réseaux sont mal connus. Leur optimisation, visée par les schémas directeurs de données sur l eau des bassins, en vue des programmes de surveillance de la directive cadre sur l eau, sera sans doute difficile à obtenir. La mise en place des programmes de surveillance, d'ici la fin 2006, est l'un des enjeux de la gouvernance du système d'information Le contrôle Le contrôle des activités ayant un impact sur l environnement, qu il s agisse de rejets (impact qualitatif), de prélèvements ou de régulation hydraulique (impact quantitatif) est trop souvent 7

8 réalisé par chaque organisme pour ses propres besoins (réglementation, redevances) sans réel souci de partage d information. De ce fait, des circuits d information parallèles existent (par exemple, les données d autosurveillance des stations d épuration sont envoyées à la fois aux Missions inter-services de l'eau et aux agences de l eau), avec des processus de validation variés, ce qui peut conduire, non seulement à la redondance, mais à la divergence des données publiées ultérieurement, avec des conséquences en terme de contentieux européens. Le SIE n a pas encore su prendre en compte à la fois les besoins de la surveillance et du contrôle (qui est lié aux missions opérationnelles des services). Ceci a conduit par exemple plusieurs services à développer en commun, mais hors du SIE, les «serveurs producteurs» pour l hydrométrie. Une approche plus cohérente des processus de surveillance et de contrôle est souhaitable L évaluation La situation a été nettement améliorée depuis le démarrage du RNDE, avec la généralisation de méthodes d évaluation de la qualité (SEQ eau 7, indice IBGN 8, ), adoptées à l échelle nationale. Ceci a surtout profité à l application des procédures locales d évaluation sur des données locales, par exemple au sein des agences de l eau ou de l Ifremer. L évaluation à l échelle nationale est facilitée par l existence de banques de données nationales : c est le cas en hydrométrie, en piézométrie et en météorologie, ce qui permet une évaluation mensuelle ou bimestrielle de l état de la ressource (bulletin de situation hydrologique). Quand ce n est pas le cas, notamment pour des études de synthèse sur la qualité des eaux (réalisées par l IFEN ou par l Office international de l'eau), l évaluation se heurte à la difficulté de réunir les données à partir de banques de données multiples, voire inexistantes, et dans des délais raisonnables. L évaluation à d autres échelles, par exemple à l échelle régionale, a conduit des services de l État à développer en commun des applications en marge de l infrastructure du SIE, comme GDES. Cet outil montre par ailleurs que la nécessité d un référentiel unique à l échelle nationale n est pas toujours comprise : chacun de ses utilisateurs peut créer ses propres paramètres, taxons, etc., alors que ces éléments doivent être identifiés par le Sandre. Le calcul de l IBGN est aujourd hui réalisé par une multitude d outils sans qu il soit possible de réutiliser cette fonctionnalité dans un outil tiers. Le partage des outils n ayant pas été une préoccupation des partenaires, des outils ont pu être développés à partir d initiatives locales, sans objectif de mutualisation et de partage à l échelle du SIE (c est le cas de NOPOLU, développé pour l IFEN). Les dispositifs dédiés à l évaluation et à la modélisation doivent certainement être revus dans la perspective d une architecture globale du SIE Le rapportage Le rapportage, que ce soit sous forme d indicateurs demandés par le Parlement, de notification à la Commission européenne, pour le suivi de conventions internationales, ou encore de contributions à des organismes d évaluation (Agence européenne de l'environnement, OCDE, Eurostat, etc.), se fait généralement en marge de l infrastructure du SIE. Ainsi, pour le rapportage exigé par la directive «eaux résiduaires urbaines» (ERU), la Direction de l eau a dû mettre en place un outil de remontée d information (BDERU) pour s assurer de la disponibilité rapide des données sur les stations d épuration, qui ne se (7) Système d'évaluation de la qualité. (8) Indice biologique global normalisé. 8

9 trouvent pas dans les banques de données du SIE. Les transmissions d information par l IFEN à des organismes internationaux utilisent des données du SIE, mais pas son infrastructure. Signalons que la Commission européenne et les Directeurs de l eau des États membres ont décidé la constitution d un Water information system for Europe (WISE) dont l objectif prioritaire est de faciliter le rapportage à l échelle de l Europe. La prise en compte des besoins du rapportage est un axe d amélioration impératif L information sur les risques Ce type d information n était pas jusqu à présent dans le périmètre du SIE. L application de la loi «risques» et la réforme des services de prévision des crues devraient introduire ce processus dans le SIE Banques et accès aux données La mise en œuvre de banques de données nationales a généralement réussi : ADES (eaux souterraines), Quadrige (eaux littorales) et Hydro (hydrométrie patrimoniale) sont trois exemples de banques thématiques nationales. Le transfert de données depuis la base de données SISE eaux vers ADES est très satisfaisant. Le fait de confier une banque de référence 9 à un organisme ayant les compétences à la fois métier et en systèmes d information (cas d ADES, de Quadrige et des bases de métadonnées du Sandre) a été positif, alors que le recours à un infogérant généraliste (cas d Hydro) peut clairement être identifié comme un obstacle à l évolutivité. La disponibilité des données collectées au sein de banques de bassin reste par contre hétérogène : l accès aux données qualitatives sur les cours d eau est variable à la fois en terme d informations mises à disposition (brute ou interprétée) et en terme de données géographiques ; les délais nécessaires pour la réalisation de synthèses nationales par extraction de bases locales (faites par l IFEN ou par l OIEau) sont excessifs. De nombreuses bases de données restent inaccessibles, même quand elles sont considérées comme bases de référence pour une certaine thématique, comme celles du CSP concernant les aspects piscicoles ou celles des agences de l eau concernant l assainissement. La constitution de banques de données accessibles reste un objectif La diffusion de l information L ensemble des partenaires s est engagé dans une démarche active de diffusion de l information, par des sites web ou par l édition de documents de haute qualité. Les accès cartographiques se sont généralisés, avec une grande variété d outils, d ergonomie très variable, ce qui n est pas très confortable pour l usager. La présentation des données interprétées est homogène, à quelques exceptions près (le «RBDE» Loire-Bretagne préférait le rose au rouge comme code de couleur des classes de qualité SEQ-eau!). Le Web a été utilisé assez tôt comme moyen de présentation des données, mais pas comme un véritable système d information : les échanges de données au sein du RNDE n ont utilisé ni les protocoles du W3C, ni ses formats de données, ni ses potentialités de navigation en termes d URI. Nombre de «sites web» sont «optimisés» pour un client web particulier et ne sont pas conformes aux normes du W3C : autrement dit, ce ne sont pas des (9) Banque de données nationale, centralisée ou répartie, gérée par un acteur identifié pour le compte des partenaires du SIE et unique source reconnue pour un type de donnée. 9

10 sites web. Les sites web sont étroitement couplés aux bases de données, ce qui rend difficile l accès aux données depuis un autre site web (c est le cas de Quadrige). Seul le portail du Sandre propose actuellement un service de syndication de contenu. Le Web est utilisé de façon extensive et variée, mais ses potentialités en tant que système d exploitation ne sont pas suffisamment exploitées. 1.3 Les enjeux de l architecture Outre les objectifs du système d information, décrits précédemment ( 1.1.2), les enjeux propres à son architecture peuvent être approchés par plusieurs points de vue : l usager, le citoyen, les organisations Les enjeux pratiques Du point de vue de l usager, l architecture du système d information doit masquer la complexité technique et préserver la sécurité des données. L architecture doit permettre un accès simple aux données et aux services malgré la complexité des systèmes et des organisations : l usager doit pouvoir naviguer aisément dans le système d information. Le grand public a d ailleurs pris l habitude d utiliser des services (bancaires, de réservation, etc.) que l administration tarde à lui offrir. La multiplicité des points d entrée et l interconnexion des systèmes augmentent les risques liés à la sécurité. L architecture doit donc préserver la sécurité des données de l utilisateur, qu il s agisse de données personnelles, ou des données de l organisation à laquelle il appartient ; ceci implique un confinement des données de sous-systèmes qui ne doivent pas être exposées Les enjeux politiques Du point de vue du citoyen, l architecture du système doit faciliter le partage de l information en tant que bien public. Quand les informations sont considérées comme publiques, il est nécessaire qu elles soient accessibles à tous, sans discrimination, afin de permettre la participation effective des citoyens aux processus de décision. Dans le domaine de l eau, la directive cadre fait de la participation et de la consultation du public l un de ses piliers (article 14). Cette exigence d accessibilité implique que les obstacles dus au coût, à la compréhension ou à la technologie doivent être évités : le coût doit être gratuit, ou du moins raisonnable, si l on tient compte des coûts d accès aux réseaux ; la qualité de l information et le type de validation doivent être connus ; une information aisément compréhensible doit être disponible et une aide pour accéder à des informations plus techniques doit être fournie ; la présentation de l information doit respecter des normes reconnues, notamment pour permettre l accès des personnes handicapées. L'architecture doit également faciliter le partage de l'information sur l'eau avec d'autres systèmes d'information en cours de constitution, notamment le système d'information pour l'environnement ou ceux prévus par le plan national santé-environnement Les enjeux de gouvernance Du point de vue des organisations, l architecture relève de la gouvernance. 10

11 Le choix de l architecture est un acte important de la gouvernance du système d information, qui participe directement à la gouvernance des organisations : il doit être traité à un niveau stratégique et non délégué à un niveau technique. En effet, l adoption d une architecture commune suppose la coopération des organisations qui participent aux processus métier du système d information ; ceci implique l emploi des instruments de gouvernance qui règlent cette coopération. L implication souhaitable d un nombre croissant d organisations (en particulier les collectivités territoriales) va entraîner la croissance des flux de données et le développement de nouveaux systèmes d information. Face à la prolifération des applications, l architecture doit viser à la rationalisation des processus et une réduction des coûts, en favorisant la mutualisation des développements et la réutilisation des composants, la maintenabilité et la capacité à supporter des développements futurs à moindre coût. Cependant, l architecture ne doit pas être vue comme une contrainte. L organisation répartie de la politique publique de l eau en France entraîne de fait une gestion répartie des données par de nombreuses organisations, à toutes les échelles du territoire. Ceci conduit à valoriser leur complémentarité à travers l architecture du système d information, en reconnaissant les compétences de chacune d entre elles et en recherchant leur adhésion. 2 DOUZE QUESTIONS PRINCIPALES Le Livre vert présente dans cette section les principales questions qui se posent et qui doivent être traitées par la définition de l architecture. Elles sont rédigées comme des thèses soumises à discussion, préfigurant de futures recommandations, plutôt que comme des interrogations : c est particulièrement sur ces questions que les contributions des parties intéressées sont attendues. 2.1 Architecture répartie et subsidiarité L infrastructure du SIE doit reposer sur l infrastructure des partenaires. Le SIE repose d une part sur l infrastructure des partenaires (qui existe de façon indépendante du SIE), d autre part sur une infrastructure commune (propre au SIE). L infrastructure commune peut être vue, au moins logiquement, comme une infrastructure centralisée, administrée par l ensemble des partenaires du SIE. Développée pour le moment au sein du «portail SIE», l infrastructure commune devrait être confiée à l ONEMA à sa création. Il n est pas envisagé de transférer sur cette infrastructure commune des processus qui sont ou qui doivent être assurés par les infrastructures des partenaires. Au contraire, il s agit d appliquer un principe de subsidiarité et de proportionnalité : des dispositifs communs sont mis en oeuvre seulement si leur partage améliore l efficacité du système d information ou s il est logiquement nécessaire ; les partenaires doivent compléter leurs infrastructures pour s intégrer dans l architecture du SIE seulement dans le but de réaliser des processus métier partagés et de façon proportionnée à cet objectif. Le fait que le SIE repose sur les infrastructures des organismes participants ne signifie pas qu elle les englobe. Chacun des partenaires dispose évidemment de son propre système d information, dont seul un sous-ensemble participe au SIE et peut être vu comme un soussystème de celui-ci. L architecture du SIE doit définir précisément comment ces soussystèmes interagissent entre eux et avec l infrastructure commune du SIE, en s appuyant sur l organisation partenariale du SIE et sur des mécanismes d interopérabilité. En outre, l utilisation par les partenaires des éléments communs de l infrastructure doit permettre une meilleure qualité de service globale, mais ne doit pas avoir un caractère obligatoire. Par exemple, si l infrastructure commune facilite l accès aux données d un 11

12 partenaire à partir de sites web qui lui sont externes, elle ne doit évidemment pas empêcher ce partenaire de publier ses données sur son propre site web : l enregistrement des services des partenaires dans un catalogue commun de métadonnées ne doit pas remettre en cause la fourniture locale de ces services. 2.2 Non-intrusion Les partenaires ne doivent pas être contraints à remettre en cause leurs choix techniques ni à installer des composants qui dégradent le fonctionnement et la sécurité de leurs systèmes. L infrastructure du SIE fonctionne et devra continuer à fonctionner dans des systèmes informatiques hétérogènes. Les partenaires seront sans doute conduits à développer des composants supplémentaires (par exemple pour permettre l accès aux données de l extérieur), mais ceux-ci ne devraient pas se substituer aux dispositifs existants, notamment aux bases de données. Ce principe sera d autant plus facile à respecter que l architecture locale des applications est déjà sur un schéma à n tiers avec n > 2. Compte tenu de la multiplicité des plates-formes applicatives, chaque partenaire devra prendre à sa charge les développements correspondants. Il peut cependant être envisagé de rendre disponibles certains développements dans l une de ces plates-formes, afin que les partenaires puissent rapidement s intégrer dans l architecture commune du SIE. Dans tous les cas, ces composants supplémentaires ne doivent pas avoir d effet intrusif se manifestant par une dégradation du fonctionnement du système d information existant, notamment de ses performances et de sa sécurité. L interface entre le système d information du partenaire et le sous-système local du SIE doit être précisément décrite, particulièrement en termes d encapsulation des données par des services et d exposition sélective des services. 2.3 Unicité de la donnée La réplication de la donnée doit être évitée. Depuis sa création, une même donnée peut être stockée physiquement en plusieurs lieux et sa valeur peut subir diverses transformations (validation, normalisation, etc.), avant et même après sa publication. En outre, un producteur de données peut avoir à fournir ses données à plusieurs utilisateurs différents qui vont à leur tour les stocker pour leurs propres usages, les traiter et éventuellement les publier. Cette situation est inévitable, compte tenu du droit de réutilisation des données publiques par des tiers, et rend absolument indispensable l emploi de métadonnées indiquant la traçabilité des données. Cependant cette situation ne devrait pas se produire au sein du SIE, tout au moins pour les données validées. En ce qui concerne la production de la donnée, il faudrait proposer un point d entrée dans le SIE auquel accéderait l ensemble des producteurs de données et qui serait la source de données unique pour une banque de donnée désignée. Ce point d entrée pourrait être installé au niveau du bassin, pour une thématique donnée, ou bien de façon nationale et globale ; cette dernière possibilité est plus simple dans le cas de producteurs de données intervenant dans plusieurs bassins. 12

13 sous-système point d'entrée site web En ce qui concerne la mise à disposition des données, la désignation d une banque de référence pour chaque type de données doit garantir l unicité de la donnée publiée ; plusieurs niveaux de publication devraient être requis pour satisfaire les besoins à la fois du public et des autres acteurs. Quand il existe une banque de référence, les producteurs de données ne doivent pas publier eux-mêmes leurs données. Entre le point d entrée et la banque de référence, les données, qui peuvent faire l objet d un traitement ou d une validation, doivent être inaccessibles. Ce schéma a pour but d éviter une réplication incontrôlée de la donnée. Ceci n interdit pas une réplication contrôlée (synchronisation de bases de données, caches), souhaitable pour des raisons de performances ou de sécurité : ce type de réplication doit rester invisible pour l utilisateur. La généralisation du découplage entre les bases de données et les portails d accès doit limiter la tentation de recopier des banques de référence ou de se procurer les données directement auprès du producteur afin de les faire figurer sur son site. 2.4 Interopérabilité sémantique Les sous-systèmes du SIE doivent être sémantiquement interopérables. L interopérabilité sémantique, qui porte sur la signification des données, a deux volets : l interopérabilité conceptuelle, qui permet d avoir une compréhension commune des objets, de leurs relations et de leur comportement (par exemple, pour décrire ce qu est une station de mesure, en quoi un prélèvement est lié à une station de mesure ou quelle suite d opérations est réalisée depuis la création de la donnée jusqu à sa publication) ; l interopérabilité référentielle, qui permet de définir et d utiliser un système commun d identification, de sorte qu un même nom soit partout employé pour identifier la même ressource (par exemple, pour identifier une station de mesure ou un paramètre). Ce niveau sémantique repose largement sur le Sandre (dictionnaires de données, nomenclatures, listes de références), éventuellement de façon décentralisée (les codes de réseau sont attribués par les bassins, les codes de station Hydro sont attribués localement), ainsi que sur d autres référentiels (par exemple le code ISO 3166 des pays, les codes INSEE des zones administratives, le code SIRET des entreprises, le code BSS des points d eau, etc.). L interopérabilité conceptuelle, qui repose d abord sur des dictionnaires de données (forme lisible par des utilisateurs), peut ensuite être formalisée, par exemple à l aide de diagrammes UML, de schémas XML, de graphes RDF ou d ontologies OWL ; ces modèles formels ont à leur tour des représentations textuelles sous forme de documents XML, forme traitable par des logiciels. 13

14 L interopérabilité référentielle peut également être formalisée de multiples façons, le modèle de base étant la table associant un nom à une ressource ; ces tables peuvent être représentées par des documents XML, et en particulier comme des schémas XML (comme le sont les nomenclatures INSEE, voir ce qui permet de les utiliser directement dans la validation des documents XML. Dans tous les cas, l interopérabilité sémantique doit être spécifiée par des documents formels (et s il faut se ramener à un format unique, c est XML), ce qui leur permet d être échangés et surtout d être considérés comme des ressources référençables. Ce référencement constitue un élément de métadonnées nécessaire à une interprétation correcte et commune de l information. L ensemble des documents spécifiant l interopérabilité sémantique constitue, par définition, le référentiel du SIE. Il est impératif de veiller à une interopérabilité sémantique dans un cadre plus large, notamment pour assurer le rapportage européen : les travaux en cours de conception du WISE doivent être pris en compte. 2.5 Interopérabilité technique : représentations et protocoles L interopérabilité technique repose sur des protocoles et des formats de représentation communs. L interopérabilité technique doit permettre aux sous-systèmes de réaliser l interopérabilité sémantique indépendamment de la façon qu a chacun d entre eux pour représenter l information. Contrairement à l interopérabilité sémantique, qui est propre au niveau «métier» et qui fait donc appel pour une grande part au Sandre, l interopérabilité technique des processus de gestion de données repose sur les normes usuelles des technologies de l information, relatives à la représentation de l information (par exemple PNG, XML ou les formats de compression) et aux protocoles d interaction (par exemple, HTTP, SMTP ou SOAP). Il n y a aucune raison d aller au delà de ces normes. Par exemple, les bases de données concernant une thématique particulière ne sont pas tenues d adopter le même modèle physique des données, mais elles doivent pouvoir échanger des données dans un même format, afin de réaliser l interopérabilité conceptuelle souhaitée ; s agissant de nouvelles bases de données, un même modèle physique peut toutefois faciliter leur déploiement rapide à partir d un prototype développé dans un bassin. L interopérabilité technique est indépendante de l interopérabilité sémantique : celle-ci doit être préservée même si les formats et les protocoles évoluent. Les cycles de vie de ces deux interopérabilités sont indépendants. 2.6 Normes ouvertes et pérennité de l information Seules des normes ouvertes peuvent assurer la pérennité de l information, malgré une hétérogénéité technique inévitable. Même si une certaine homogénéité technique pouvait être atteinte à un moment donné par l ensemble des systèmes, des évolutions ultérieures la rompraient nécessairement. La pérennité de l information doit donc être impérativement recherchée : une information ne doit pas risquer d être perdue parce que sa représentation cesserait d être compréhensible du fait de l évolution technologique. Alors que la possibilité de réaliser un service interopérable exprime une condition sur l état simultané des systèmes d information, celle de pouvoir échanger de l information, de la conserver et de la réutiliser exprime une condition de nature diachronique. La représentation de l information (son codage, son format) est susceptible de varier selon le lieu et le moment, en fonction de la technologie des supports de conservation et de communication. 14

15 Une interopérabilité durable ne peut pas être obtenue par le choix imposé d un outil technique commun aux différents systèmes. C est seulement par le choix et le strict respect de normes communes et ouvertes que l interopérabilité technique peut être atteinte et préservée. Par norme ouverte, on entend une norme technique dont la spécification, résultant d un processus de décision ouvert, est publiée et accessible à un coût raisonnable ; dont les droits liés à la propriété intellectuelle ne sont pas exploités dans un but lucratif ; dont l usage est libre ; dont il existe au moins une implémentation conforme et libre. Cette dernière condition, qui n impose pas l utilisation d une implémentation libre, est requise pour deux raisons. D une part, parce qu il s agit de données publiques, l exigence d accessibilité oblige les autorités qui mettent les informations à la disposition du public à une stricte neutralité : elles ne doivent pas contraindre les usagers à contracter une licence et à en acquitter les droits. D autre part, dans l approche graduelle qui est favorisée ici, les implémentations libres peuvent être testées à moindre coût et librement distribuées aux partenaires. Concernant la représentation de l information, contrairement aux normes ouvertes, les formats sous licence propriétaire ne satisfont pas à une condition essentielle : à tout moment le décodage de la représentation des données et leur transcription dans un autre format sans perte d information doivent être possibles et aisées. Ceci n interdit pas les logiciels propriétaires, à condition qu ils soient capables d échanger des données selon une norme ouverte et sans perte d information. Les normes ouvertes considérées sont celles des organismes suivants : IETF, W3C, OGC, DCMI, OMG, WS-I, OASIS, JCP, etc. 2.7 Cadre d interopérabilité La recherche de l interopérabilité doit être conduite dans un cadre multilatéral, et doit adopter des règles qui recueillent le consensus le plus large possible. L interopérabilité pourrait être traitée sur une base restreinte, par des accords bilatéraux. Cependant, leur portée serait limitée et leur extension à de nouvelles organisations exigerait de celles-ci qu elles se plient à des règles qu elles n ont pas négociées. C est pourquoi, concernant l interopérabilité sémantique, le cadre multilatéral a été retenu à travers le protocole SIE, qui est extensible à de nouveaux partenaires. Concernant l interopérabilité technique, le SIE doit adhérer à des cadres d interopérabilité, guides contenant des recommandations et des spécifications, qui sont publiés par des instances nationales ou internationales, notamment l ADAE 10 et l IDA 11, aux niveaux français et communautaire. Il est préférable de les appliquer sans chercher à les réécrire spécialement pour le Système d information sur l eau. 2.8 Utilisation de l information géographique Le SIE doit généraliser et faciliter l usage de l information géographique, en se plaçant dans le contexte d INSPIRE. La plupart des données relatives à l eau (et plus généralement à l environnement) sont géoréférencées, c est-à-dire sont relatives à un point du territoire ou à une entité géographique (rivière, zone administrative, etc.). En outre, cet attribut de géoréférence (10) Cadre commun d interopérabilité, seconde version, septembre (11) European Interoperability framework for pan-european egovernment services, IDA, janvier

16 permet de relier des informations provenant de sources diverses, ayant trait à des analyses différentes, mais concernant la même zone géographique (par exemple une corrélation entre l état des eaux de surface et celui des eaux souterraines, ou avec l usage des sols) ; ceci permet à l usager de «découvrir» les informations environnementales disponibles relatives à une zone du territoire. L information géographique, reconnue comme un enjeu majeur de l information environnementale, est l objet du projet de directive INSPIRE 12, qui crée une infrastructure européenne d information géographique. Les principes de cette infrastructure, qui sont pertinents pour le SIE, sont rappelés ici : la collecte, la validation et la mise à jour des données doivent s effectuer au niveau où elles s opèrent avec le maximum d efficacité ; il doit être possible de combiner des informations géographiques cohérentes à partir de différentes sources à travers le territoire et de les partager avec de nombreux utilisateurs et applications ; l information recueillie à un niveau doit pouvoir être partagée entre les différents niveaux : détaillée en vue de recherches approfondies et générale à des fins stratégiques ; l information géographique nécessaire pour une bonne gouvernance à tous les niveaux doit être disponible en abondance dans des conditions qui n en restreignent pas l utilisation étendue ; il doit être facile de trouver quelles sont les informations géographiques disponibles et adaptées aux besoins d une application particulière et sous quelles conditions elles peuvent être obtenues et utilisées ; les données géographiques doivent devenir faciles à comprendre et à interpréter du fait qu elles peuvent être visualisées dans le contexte approprié de manière conviviale. Le système d information sur l eau doit intégrer ces principes dans la définition de son architecture. 2.9 Données à voir et données à utiliser Les deux modes d accès aux données, en consultation et en déchargement, doivent être proposés. La présentation des données dans une page web contenant du texte et des images ou dans un document PDF permet à l usager de «voir» une information, éventuellement de la conserver pour la re-voir ultérieurement, ou de l imprimer pour la voir sur un autre support, mais ne lui permet aucune autre utilisation. Certains usagers peuvent avoir besoin des données pour les «utiliser» : leur appliquer un traitement particulier, pour les comparer à des données provenant d autres sources, pour publier les résultats de ces traitements ou comparaisons. Il faut donc distinguer deux modes d accès aux données, la consultation pour «voir» les données et le déchargement (du «serveur» vers le «client») pour les «utiliser». Toutes les données brutes doivent être disponibles au moins sous une forme «à utiliser» et de préférence sous les deux formes, «à voir» et «à utiliser». Toutes les données élaborées doivent être disponibles au moins sous une forme «à voir», surtout si elles sont accompagnées de commentaires, et de préférence sous les deux formes, du moins pour leurs aspects quantitatifs. Les formes à voir doivent inclure un lien vers une forme à utiliser. Les métadonnées, qui bénéficient toujours d une représentation formelle, doivent être accessibles sous les deux formes. (12) Projet de directive, juillet

17 Les données à utiliser devraient être accessibles en format XML, ou en format texte à séparateurs («format sandre simplifié») pour être exploitées dans un tableur ; dans les deux cas, le format proposé doit être documenté. Pour les données géographiques, le format GML est recommandé à moyen terme, les formats propriétaires Shapefile (ESRI) ou MIF/MID (Mapinfo) pouvant être utilisés dès maintenant Couplage faible par des services Les sous-systèmes du SIE doivent être faiblement couplés par des services. Tout ce qui précède conduit à une infrastructure dont les composants logiciels sont faiblement couplés par des services, qui forment une nouvelle sorte de ressources du système d information : les composants logiciels ne sont eux-mêmes soumis à aucune autre contrainte que de communiquer entre eux en fournissant ou en utilisant des services. Plus précisément, seuls les composants qui communiquent entre eux de part et d autre de la frontière des sous-systèmes sont tenus de le faire par l intermédiaire de services : ce sont les agents, fournisseurs ou utilisateurs de services. La conception d une architecture passe par le choix d un style : il s agit donc ici d une architecture de services et non d une architecture de composants. L organisation interne des systèmes d information des partenaires, et même des soussystèmes du SIE, n est pas concernée par ce choix d architecture. Néanmoins, une architecture interne à faible couplage sera plus à même à s intégrer dans l architecture du SIE. Par exemple, une architecture applicative 3-tiers (ou 4-tiers) permet déjà un couplage faible, notamment entre la source de données et l application métier, et entre celle-ci et l interface avec l utilisateur : ce type d architecture est donc recommandable, alors qu une architecture client-serveur, qui présente un couplage fort, ne l est pas. La nature du couplage faible doit être déterminée plus particulièrement par les questions examinées précédemment. Le principe de non-intrusion (notamment pour des raisons de sécurité) conduit ainsi à privilégier des services fonctionnant en mode descendant 13 : l agent fournisseur de service publie une description du service et l agent utilisateur obtient au moyen de ce service des données dont il contrôle l usage ultérieur. Le mode ascendant, où l agent utilisateur a la possibilité d ajouter ou de modifier des données chez le fournisseur, ne peut être utilisé que de façon limitée Métadonnées L emploi des métadonnées pour la découverte, la localisation et la qualification des données doit être systématisé. Les données, qu elles soient à voir ou à utiliser, ainsi que les services, doivent d abord pouvoir être découverts. Dans une architecture de services, découvrir, c est localiser les descriptions publiques des ressources qui satisfont certains critères fonctionnels. Un service de découverte joue dans une architecture de services un rôle analogue à un moteur de recherches pour le Web. Cependant, à la différence du Web, la description d un service ne peut pas être obtenue en analysant le service comme on analyse lexicalement une page web. Il en est de même pour des données non textuelles, notamment géographiques. Ceci suppose qu une description des ressources et de leurs fonctionnalités a été faite et publiée, et de façon formalisée de manière à pouvoir être traitée par un programme : cette description formelle est une métadonnée. Dans le cas des services, cette métadonnée donne les informations nécessaires à la découverte et l utilisation du service (notamment sa localisation, les opérations proposées et les paramètres qui doivent être utilisés). Dans le cas des données, elle permet d identifier les jeux de données disponibles et leurs caractéristiques (notamment leur origine et leur niveau de validation). (13) pull plutôt que push. 17

18 2.12 Une architecture fondée sur le Web Le Web et ses protocoles, y compris pour l information cartographique, devraient être à la base de l architecture du SIE. Il se trouve que le Web, en tant que système d information, répond complètement au style d architecture envisagé et aux critères examinés précédemment, et que ses capacités n ont cessé d être étendues tout en préservant sa structure, notamment par la récente addition des services web. Du point de vue de l interopérabilité, l Internet est déjà un exemple de réussite, par l emploi de protocoles communs (TCP/IP) et d un système d identification des ressources qui a fait ses preuves (adresses IP, noms de domaine, numéros de ports, etc.). Basé sur l Internet, le Web constitue un autre exemple d interopérabilité réussie, à la fois référentielle et technique, basée sur : l'identification des ressources par des URL, l interaction entre client et serveur selon une interface et des formats de message déterminés par le protocole HTTP, la représentation des ressources par des documents hypertextes HTML et d autres types MIME. Le fait de fonder l architecture du SIE sur le Web, en retenant le «canal web» comme le mode d interaction privilégié, doit permettre de bénéficier du même degré d interopérabilité. Cependant, l'utilisation du Web ne suffit pas à assurer l'interopérabilité s'il est seulement vu comme une facilité, notamment en tant qu'interface universelle ; c'est ainsi que le recours à des sites web fortement couplés aux sources de données (figure suivante, cas a) ne tire aucun bénéfice de l'architecture du Web. base de données portail de services site web (a) (b) (c) (d) (e) Le SIE doit au contraire s orienter vers des «portails de services» qui assurent un couplage faible entre les sources de données et les sites web par l'intermédiaire de services web (dont les géoservices) : le site web utilise un service fourni par un portail de services, et c'est celui-ci qui interagit avec la source de données (cas b). Deux portails de services peuvent être couplés par des services (cas c). Une même source de données doit être accessible à partir de différents sites web distants (cas d), un même site web doit pouvoir accéder à différentes sources de données distantes (cas e). Les sites web sont eux-mêmes faiblement couplés entre eux par des services de syndication de contenus. 3 ÉLÉMENTS DE PROPOSITION 18

19 L architecture du système d information consiste à décrire les principes de son organisation technique, notamment la façon dont les processus de gestion des données interagissent entre eux et avec les utilisateurs et comment ils réalisent les processus métier ; elle formalise aussi les principaux choix technologiques. Ce Livre vert ne prétend pas définir l'architecture du SIE, qui résultera d'un travail collectif à l'issue de la présente consultation. La définition d une architecture n est d'ailleurs pas une chose facile : il aura ainsi fallu 3 ans de discussions pour que le W3C publie, près de 15 ans après la naissance du Web, une spécification de son architecture. Cette section présente des éléments de proposition pour une architecture commune du SIE. Elle décrit les «ressources» du système d'information, ses acteurs et leurs relations mutuelles sous forme de cas d'utilisation sommaires et propose un schéma général d'organisation. Elle n a pas pour objet de définir l organisation spécifique dans chaque domaine thématique de l eau, ni dans les systèmes d information des partenaires. 3.1 Les ressources Conformément à l'architecture du Web, on considère qu'une ressource est tout ce qui peut être désigné par un Uniform Resource Identifier (URI). Une ressource peut avoir des représentations et des descriptions, elle peut être soumise à des restrictions d usage ; elle a aussi un propriétaire, qui est un acteur du système d information. La représentation de la ressource n est pas la ressource elle-même. Déjà dans le cas d une page web «statique», sa représentation (qui peut être un document HTML ou XML, une image PNG, etc.) peut résulter d une phase de négociation entre serveur et client qui détermine le format du document, sa langue, la résolution des images, etc. Dans le cas d un service, la ressource est un processus (voire une fabrique de processus) et sa représentation résulte de son exécution Le point de vue métier La caractérisation des ressources sera une étape importante de la définition de l'architecture, car elle résulte d abord du point de vue du métier : les ressources auxquelles on s'intéresse ici doivent avoir un sens pour les processus métier du système d'information (la surveillance, le contrôle, le rapportage, etc.). On peut considérer par exemple les types de ressources suivants : une station de mesure, un réseau d observation, une banque de données, un ouvrage (de prélèvement, de rejet, de traitement, de régulation hydraulique, ), les données acquises sur une station de mesure entre deux dates, un rapport d évaluation, une zone hydrographique, une rivière ou un plan d eau, une masse d eau, une zone protégée, une nomenclature, une liste de paramètres du Sandre, un taxon, un paramètre, un intervenant, un SDAGE, un programme de surveillance, un document de synthèse. Dans chaque cas, il faut se poser la question : pour telle ressource possible, quelle peut être sa représentation, quelle peut être sa description? Par exemple, si une station de mesure est considérée comme une ressource, sa «fiche station» (présentant les caractéristiques 19

20 de la station, la disponibilité des données, les paramètres mesurés, etc.) peut-elle servir de représentation ou de description? Les données Les données métier (c'est-à-dire les données sur l'eau) forment certainement la matière première du système d'information, mais elles ne sont pas considérées comme des ressources. En effet, ces données doivent être encapsulées par des services et des jeux de données ne peuvent être obtenues ou modifiées par les utilisateurs du SIE que par l intermédiaire de services (de consultation, déchargement, création, mise à jour ou suppression de ces jeux de données). Le format de la représentation des données dans les systèmes internes des acteurs n'est donc pas spécifié. Seule leur représentation externe doit l'être, dans la mesure où des données sont transférées par la réalisation d'un service. Par contre, les données du référentiel sont considérées comme des ressources. Ce sont essentiellement des données de nature descriptive, normative et peu évolutive et qui sont rarement utilisables seules : référentiels géographiques (BD Carthage, BD RHF), référentiels de la mesure (paramètre, méthode,..), dictionnaires de données, schémas de données, nomenclatures du Sandre. Ces données doivent donc pouvoir être désignées par des URI. De façon classique, les sites web et leurs documents statiques sont aussi des ressources du SIE, quand ils sont identifiés par des URL Les métadonnées Les métadonnées sont des éléments d information qui servent à identifier, localiser et décrire les jeux de données (qui sont «détenues par une autorité publique») et les services ( 2.11). Les métadonnées sont considérées comme des ressources du SIE, car elles participent à l efficacité d un système réparti dont les ressources sont éclatées auprès de tous les partenaires, donc difficiles à connaître. Les catalogues de métadonnées sont eux-mêmes des ressources du SIE. On distingue parfois les annuaires (de services et d'acteurs), qui contiennent directement les métadonnées (description des services, description des acteurs), les catalogues qui permettent de chercher et de localiser des métadonnées, mais ne les contiennent pas nécessairement, et les atlas, qui permettent des recherches sur des critères géographiques, généralement à travers une interface cartographique. Ces catalogues doivent donc pouvoir être désignés par des URI. Les métadonnées employées doivent être formalisées de manière à faire l'objet de traitements automatisés Les services Les services forment la base d une architecture, dont on peut retracer l origine à trois développements importants dans l histoire de la programmation : la séparation entre l implémentation d une procédure et son interface, qui est seule exposée, de manière à pouvoir modifier l implémentation d une procédure sans devoir modifier les autres procédures qui n utilisent que son interface ; l invocation de procédure distante (RPC) à travers l Internet, ce qui impose la normalisation de l invocation et le conditionnement des arguments d appel et de la valeur de retour pour pouvoir fonctionner dans un environnement hétérogène ; les systèmes d objets répartis (CORBA, DCOM, EJB) qui replacent les deux points précédents dans le contexte de la programmation par objets et introduisent des 20

21 notions importantes comme celle de «courtier» et de «registre». Si l on y ajoute que les communications se font par des messages XML envoyés et reçus par les protocoles du Web (HTTP) et que la forme de ces messages est décrite par des documents XML, on parvient à la notion de service web. Un exemple simple de service web est un canal RSS qui permet usuellement la syndication des contenus d'un site web. On considère actuellement deux approches pour les services web (une présentation succinte en est donnée en annexe) : l approche REST, basée sur HTTP / GET et POST avec des échanges de messages XML, plutôt dédiée à la recherche et la consultation de données ; l approche SOAP, basée sur HTTP / SOAP avec des échanges de messages SOAP, plutôt dédiée aux opérations, d ajout, modification et suppression de données. Dans les deux cas, la forme des messages devra être spécifiée par le Sandre. Les services sont fournis par des portails de services. Du point de vue d'un utilisateur, ces portails apparaissent à travers des sites (portails) web offrant un accès à la fois à des documents et à des services. Les géoservices constituent une famille particulière de services visant à l'interopérabilité de l'information géographique ; ils sont à la base des géoportails qui permettent, entre autres, de sélectionner et de visualiser l'information géographique sous forme de cartes et d'obtenir des informations attributaires sur les objets qu'elles représentent Les services communs Les services communs sont fournis par un ou plusieurs portails de services, dits «portails SIE». Leur caractère commun est justifié, soit par la nécessité d un référentiel unique [R] (c est le portail sandre.eaufrance.fr), soit par une mutualisation des moyens [M] à l échelle du SIE ou d une thématique (par exemple, la vigilance inondations). Certains services sont accessibles au public : [R] Annuaire de services (recherche) [R] Données (recherche, consultation et déchargement des éléments du référentiel) [R] Métadonnées (découverte, dans un catalogue ou un atlas) [M] Géoservices (recherche, sélection, visualisation de cartes) [M] Requête (formation et exécution de requêtes, agrégation des résultats) D'autres services sont accessibles à des utilisateurs enregistrés : [R] Annuaire d utilisateurs (recherche, authentification, contrôle d'accès) [R] Métadonnées (publication) [R] Référentiel (abonnement et notification, pour la mise à jour) [M] Partage de fichiers [M] Déploiement d applications Les services des partenaires Ces services sont fournis sur des portails mis en œuvre et gérés par les partenaires : Géoservices (publication de cartes et d objets géographiques) Données (consultation et déchargement, éventuellement notification) 21

22 Métadonnées (consultation, déchargement) Canal RSS Les services externes Les services externes sont fournis par des agents logiciels déployés chez des acteurs non nécessairement partenaires : Données (saisie, chargement, traitement) Ces services ne sont pas nécessairement des services web, mais doivent être basés sur des protocoles de l Internet. Contrairement aux services communs et aux services des partenaires, ces services peuvent être fournis par des agents logiciels mis à la disposition d acteurs non partenaires de manière à les inciter à intégrer leurs données au SIE à moindre coût. Ces agents devraient au minimum associer des composants de saisie et de sauvegarde de données (dans une base locale) et un composant client d un service commun de partage de fichiers Les URI L utilisation des URI Les URI (Uniform Resource Identifier), définies par la norme Internet RFC 2396, sont les «noms» du Web : ils servent à identifier ses ressources. Une forme particulière est l URL (Uniform Resource Locator), qui sert à localiser une représentation d une ressource sur le Web. Un URI est une chaîne de caractères lisible, qui peut non seulement apparaître comme lien dans une page web, mais peut aussi être envoyée par courrier électronique, insérée dans une base de données, ou figurer comme valeur d un élément de métadonnée. L emploi d URL obscurs (par exemple, compliqués par un identifiant de session) n est donc pas recommandable. Un URI a comme première vocation d être employé comme un nom pur, sans devoir être déréférencé en vue obtenir une information. L intérêt de ce nom pur est d'abord d identifier de façon unique une ressource, et non de la localiser ou d en inférer le format (informations qui peuvent être lues à partir d un URL). En outre, quand une ressource est un service ou un document, ou plus généralement a au moins une représentation, son URI peut être utilisé pour en obtenir une représentation. L URI de la ressource ne doit par contre pas être utilisée pour obtenir sa description, c est-àdire ses métadonnées (par exemple la description d un service web) L allocation des URI L'architecture du SIE doit comporter un schéma d'allocation des URI. L allocation d URI aux ressources du SIE a pour autorité principale la Direction de l eau qui gère le domaine eaufrance.fr, crée ses sous-domaines et en délègue la gestion ; elle est décentralisée par sous-domaine. Les sous-domaines peuvent être affectés aux bassins (par exemple loirebretagne.eaufrance.fr) ou à d autres échelons territoriaux, à des banques de référence (ades.eaufrance.fr, hydro.eaufrance.fr, quadrige.eaufrance.fr, economie.eaufrance.fr, etc.) ou à des ressources communes (sandre.eaufrance.fr, doc.eaufrance.fr, etc.). La gestion de ces sous-domaines est déléguée par la Direction de l eau. L allocation d URI aux ressources communes du SIE a pour autorité le Sandre, qui gère le sous-domaine sandre.eaufrance.fr. Le Sandre peut se voir confier la gestion d autres sousdomaines. L allocation des autres URI du SIE se fait par sous-domaine et a pour autorité le gestionnaire du sous-domaine. Sans aller jusqu à un plan de nommage commun pour les 22

23 URI, une certaine cohérence devrait être recherchée entre les sous-domaines Proposition de nommage Une attention particulière doit être portée au choix des URI, afin de les rendre facilement utilisables. Voici quelques exemples d URI qui pourraient être proposés pour désigner des éléments du référentiel (paramètres, intervenants, etc.) Les URI suivants désignent des services d'accès aux données (de la banque Hydro, de la future banque des données hydrométriques en temps réel, des données de qualité d'une banque de bassin) : station= &periode= %2f station= &parametre=238&periode= %2f La syntaxe des URI permet l identification d une ressource secondaire en faisant suivre l URI de la ressource primaire par un «#» et par l identifiant de la ressource secondaire ; dans l exemple suivant la ressource primaire est la nomenclature des bassins, la ressource secondaire est la définition du bassin identifié par le code «05» : Les acteurs du système d information Un acteur est une personne ou un organisme qui participe aux processus du système d information en assumant un rôle, c est-à-dire un ensemble de responsabilités. Quand un rôle est défini de façon contractuelle (notamment par le protocole SIE), un acteur qui assume ce rôle est appelé un partenaire. Un même acteur peut assumer plusieurs rôles ; un rôle peut être assumé par plusieurs acteurs. Un acteur peut posséder des composants logiciels, appelés agents, qui fournissent ou utilisent des services en son nom : on dit dans ce cas que l acteur fournit ou utilise ces services. Un utilisateur est une personne qui interagit avec un agent, pour son propre compte ou pour le compte d un organisme acteur du système d information ; on dit alors qu il tient le rôle correspondant de l acteur concerné. Dans le cadre de l architecture générale du SIE, les rôles suivants sont définis L usager Un acteur participe à un processus en tant qu usager quand il ne fait qu utiliser des services. C est le cas du public (le «citoyen»), qui ne peut assumer que ce rôle ; c est aussi le cas des autres acteurs (administrations, entreprises, associations) quand ils utilisent des 23

24 services. Ce rôle ne comporte pas de responsabilités. Un utilisateur qui tient ce rôle d usager est appelé utilisateur final. Plus que de récupérer de la donnée, l usager «consomme» des services : recherche de données disponibles, consultation sur le Web et déchargement d'un jeu de données, calcul d un IBGN, La conception de l architecture doit être résolument centrée sur les besoins de l usager. Il faut souligner que la position symétrique d un acteur qui ne participe à un processus qu en tant que fournisseur de services n est pas considérée Le producteur de données C est un acteur qui est responsable de la création de la donnée, de sa signature et de sa mise à la disposition de l acteur qui la lui a demandée et selon des modalités requises ; la signature de la donnée peut valoir validation (même si d autres procédures de validation peuvent être effectuées par d autres acteurs ultérieurement). Un producteur de données peut faire appel à des tiers pour la production de données mais ceci doit rester transparent sous sa responsabilité, c est-à-dire non exposé au système d information. On distingue généralement : le producteur de données élémentaires ; il peut être difficile de définir exactement ce qu est une donnée élémentaire, car toute donnée s appuie souvent sur une donnée plus élémentaire ; intuitivement, cette notion est définie par le métier considéré : pour un hydrologue, un niveau piézométrique est élémentaire, mais c est une donnée élaborée à partir d une intensité électrique pour l ingénieur qui a fabriqué l instrument de mesure. le producteur de données élaborées, qui résultent d un traitement de données élémentaires par des procédures d agrégation, d interpolation ou d interprétation, de présentation, etc. ; à la différence du producteur de données élémentaires, le producteur de données élaborées est aussi un usager, puisqu il consomme des données du SIE. Un producteur de données est également responsable de la création des métadonnées correspondantes ; ces métadonnées peuvent être enrichies ultérieurement par d'autres acteurs, notamment pour assurer la traçabilité des données. Les producteurs de données interviennent particulièrement dans les processus de surveillance et de contrôle (données élémentaires) et d'évaluation (données élaborées) Le diffuseur de l information C est un acteur qui est responsable de la publication de l information (données élémentaires ou élaborées). Il offre des services de consultation et de déchargement de ces données sur le Web. Un diffuseur de l'information est également responsable de la validation des métadonnées correspondantes et de leur publication dans des catalogues publics. La diffusion de l'information est l une des modalités de la mise à disposition du public des informations environnementales qui incombe à toutes les autorités publiques détentrices de ces informations, en application de la directive 2003/4/CE. L'information des populations exposées aux risques ainsi que le rapportage peuvent aussi être considérés comme des variétés de diffusion de l'information. 24

25 3.2.4 Le producteur du référentiel C est à la fois un producteur et un diffuseur particulier. Il est responsable de la constitution du référentiel du SIE, c est-à-dire de l ensemble des données nécessaires à l interopérabilité sémantique (conceptuelle et référentielle) du SIE. Certaines de ces données sont produites par le Sandre pour les besoins propres au SIE, d'autres sont plus générales et proviennent par exemple de l'insee du BRGM, de l'ign, etc. La particularité de ce rôle est de fournir des données utilisables obligatoirement par l ensemble des fournisseurs de services, en particulier par les autres producteurs de données. Par suite, le producteur du référentiel a des responsabilités supplémentaires : sa validation est finale (aucun autre acteur n aura à valider ses données) et il doit assurer lui-même la mise à disposition de ses données de tous les autres acteurs, notamment à chaque fois qu elles sont modifiées. Il offre donc des services de notification pour la mise à jour du référentiel. Compte tenu de ces responsabilités, le producteur du référentiel assure une mission d'intérêt général dont l'état doit garantir la pérennité Le gestionnaire des catalogues C est un fournisseur de services qui est responsable de la gestion des catalogues de métadonnées. Les services fournis permettent de rechercher, comparer, créer, modifier ou supprimer des entrées du catalogue. Le rôle du gestionnaire des catalogues est double. C'est une autorité d'enregistrement qui offre aux fournisseurs de services et aux producteurs de données des services d'enregistrement et de publication de leurs métadonnées. C'est aussi un courtier qui offre à tous les acteurs un service de découverte et de consultation des métadonnées : la description des services exposés au sein du SIE ; la description des données exposées au sein du SIE ; les acteurs et les utilisateurs autorisés du SIE ; la description des stations de mesure, zonages réglementaires, etc.. La particularité de ce rôle est de fournir des services utilisables par l ensemble des acteurs. Tous les partenaires doivent utiliser les services d'enregistrement des métadonnées qu ils produisent. La constitution de ces catalogues de métadonnées est une obligation pour l État, en application de la directive 2003/4/CE, car ils permettent de connaître l existence d une information environnementale et l identité de l autorité publique qui la détient. 3.3 Cas d utilisation du SIE Cette section présente quelques cas d utilisation du SIE Syndication de contenus web Ce service, auquel participent les diffuseurs de l'information, est facile à mettre en oeuvre. Chaque site web fournisseur de ce service publie un document XML qui décrit un ensemble de ressources (pages web) sous forme de canal RSS (qui contient notamment le titre, l'url, la date et la description des articles publiés) ; le document XML est généralement produit automatiquement par les systèmes de gestion de contenus usuels (comme SPIP), mais il peut être écrit manuellement, puisque c'est un simple document XML. Un site web utilisateur de ce service consulte les canaux RSS d'un ensemble de sites fournisseurs, éventuellement 25

26 sélectionne parmi les articles de ces canaux ceux qui l'intéressent, puis transforme ces documents XML en une ou plusieurs pages HTML, avec sa propre présentation, de manière à intégrer les titres, descriptions, etc., de ces articles avec des liens sur leur site d'origine ; cette transformation est aussi réalisée par les systèmes de gestion de contenus usuels et peut l'être par une application web. RSS permet une forme d'interopérabilité qui va au-delà de la syndication de contenus web, puisqu'il repose d'une part sur la publication d'une description XML de ressources offertes par un producteur, et d'autre part, par l'utilisation de ces descriptions. L'existence d'un catalogue de canaux RSS favorise l'utilisation de ce service Publication et mise à jour de données du référentiel Figure 1 L objectif : Exposition est de données mettre à de disposition référence des par «canal abonnés WEB,» WS une et mise FTP à jour du référentiel du SIE (par exemple, lors de la création de paramètres ou d une nouvelle station de mesure). Informations de référence non exposées au SIE Producteur du référentiel Portail Web SIE SIE 2 3 Portail de services communs Métadonnées (annuaires, catalogues, atlas) 1 Référentiel exposé (ftp) Portail de services de l usager Usager 1. le producteur du référentiel crée ou modifie dans son système un élément du référentiel et le publie sur son site FTP ; 2. il expose au SIE cette ressource en publiant sa description via une interface web sécurisée du portail SIE ; 3. cette description est insérée dans un catalogue de métadonnées «Référentiel du SIE» ; 4. cette insertion déclenche une notification des abonnés ; 5. cette notification consulte la base des acteurs SIE abonnés au service de notification ; 6. la notification envoie une information aux abonnés sous forme d un message SMTP ou d un topic JMS qui contient une référence à la ressource publiée ; 7. à la réception du message ou du topic, l abonné peut appeler le service de déchargement selon deux canaux : un accès direct par une interface web ou un service web SOAP de mise à jour ; 8. dans le cas de l interface web, l abonné accède à un document HTML contenant l URI de la ressource FTP ; dans le cas d un service web, l abonné obtient automatiquement l URI de la ressource (fichier de mise à jour du producteur du référentiel) ; 26

27 9. l abonné obtient les données via le canal FTP selon l adresse URI fournie par le document ou le service web Saisie des données Le producteur de données saisit ses données, et les sauvegarde localement. Ces données sont ensuite postées au moyen des protocoles FTP ou WebDAV vers un point d entrée du SIE : c'est le seul cas où l accès en écriture se fait sur une base externe. Ce point d entrée est ensuite interrogé par les bases de données cibles et par les acteurs responsables de leur traitement ou de leur validation. Plutôt que de saisir les données à travers une interface spécifique à une application (client lourd, ou interface web), on utilise une interface générique, instanciée pour chaque application par un schéma XML correspondant ; les données sont sauvegardées localement sous forme de documents XML Diffusion des informations La diffusion de l information consiste en le scénario suivant : un diffuseur dispose d informations (données élémentaires ou élaborées) qu il décide de publier sur un site web et de mettre à disposition du portail SIE. un usager découvre l existence de ces informations en consultant le portail du SIE, il accède ensuite à ces données qu il consulte, directement sur le portail du diffuseur ou via le portail du SIE : il les visualise, il peut les exporter sous la forme d un document PDF et il les peut les décharger dans un format textuel, par exemple pour les réutiliser dans un tableur. Données élémentaires non exposées au SIE Diffuseur d informations 1 2 Portail Web SIE 3 Portail de services communs SIE Métadonnées (annuaires, catalogues, atlas) Données exposées Service du diffuseur 5 Site Web du diffuseur 6 Usager Autre diffuseur d informations Service du diffuseur La réalisation du scénario est la suivante : 27

28 1. le diffuseur d informations collecte et valide les données dans son système d information interne ; 2. il les publie sur un site web ainsi que les métadonnées correspondantes ; 3. il les expose au SIE en enregistrant dans les catalogues de métadonnées du SIE la disponibilité des données, leurs métadonnées et les modalités d accès par des services ; 4. un utilisateur se connecte sur le portail SIE et découvre l existence de ces données en consultant le catalogue des métadonnées disponibles ; il sélectionne un jeu de données en formant une requête ; 5. si la requête est simple, il peut obtenir les données directement à partir du site du diffuseur de ces données ; 6. si la requête est plus complexe et si le jeu de données comprend des données présentes sur plusieurs sites, le service de requête du portail SIE, après avoir interrogé l annuaire des services, invoque les services de données disponibles sur les sites identifiés ; 7. les données sont reçues au format XML par le portail SIE ; le portail les assemble en un document XML et construit la représentation requise (HTML, PDF, texte) en appliquant à ce document XML une transformation appropriée (XSLT ou XSL-FO). 8. le portail SIE retourne à l utilisateur la représentation requise correspondant à sa requête Accès à des géoservices L accès à des données géographiques s effectue selon une démarche similaire à celle présentée pour la diffusion des informations : un producteur de données cartographiques dispose des données qu il décide de publier sur son site et de mettre à disposition du SIE ; un usager découvre l existence de ces données en consultant le portail de géoservices du SIE : il sélectionne les couches cartographiques qui l intéressent, puis il affiche une carte regroupant ces couches. La réalisation de ce scénario est la suivante : 1. le producteur de données géographiques publie ses couches cartographiques sous forme de services WMS sur un site web et les métadonnées selon la norme ISO ; 2. le portail SIE met régulièrement à jour ses catalogues de métadonnées en interrogeant les capacités des serveurs WMS et en indexant les métadonnées ISO disponibles auprès des partenaires ; 3. l utilisateur se connecte au portail de géoservices du SIE, il sélectionne les données géographiques en fonction des métadonnées indiquées (emprise géographique, thématique concernée, ) ; 4. ces couches peuvent appartenir à des serveurs WMS multiples ; le portail SIE appelle ces couches cartographiques au moyen de WMS et les présente comme une image à l utilisateur ; 5. l utilisateur peut obtenir des informations attributaires liées à un point de l image reçue en consultant une page web ou par un service web de type REST. 3.4 Schéma général de l architecture 28

29 Le schéma général de l architecture du SIE est relativement simple : il met en relation des fournisseurs de services et des utilisateurs de services via le système d information sur l eau, par l'intermédiaire de sites web et de portails de services. Base de données partenaire Portail de services 3 Portail web Le rôle du portail SIE est de faciliter les demandes des utilisateurs vers les producteurs de données ; c est un «courtier», qui tient des «registres», mais qui ne contient pas de données métier. Il enregistre les ressources exposées par les différents producteurs de données, sous forme de métadonnées ou de services. Les principaux échanges sont les suivants : 7 5 Portail de services communs Référentiel 4 6 Client web Portail web Portail de services communs Métadonnées (annuaires, catalogues, atlas) 1. un usager accède à partir d'un client web à un site web d'un partenaire (c'est la situation actuelle) ; 2. un usager accède au portail de services du SIE, pour découvrir des ressources disponibles (10), pour interroger les bases de données des partenaires (5) ou pour consulter le référentiel (9) ; 3. le site web du partenaire utilise des services fournis par son portail de services (par exemple, consultation de données ou de métadonnées, déchargement de données) ; 4. le site web du SIE et le site web du partenaire sont couplés par un service de syndication de contenus ; 5. le site web du SIE utilise des services fournis par le portail de services du partenaire, par exemple de requêtes sur ses bases de données ; 6. le portail de services communs utilise des services du partenaire (consultation d'une métadonnée) ou lui fournit des services (enregistrement et publication d'une métadonnée) ; 7. le portail de services communs fournit des services au partenaire (consultation et mise à jour du référentiel) ; 8. le portail de services communs utilise certains de ses services (consultation de la base des abonnés à la mise à jour du référentiel) ; 9. le site web du SIE utilise des services fournis par le portail de services du SIE (consultation du référentiel) ; 10.le site web du SIE utilise des services fournis par le portail de services du SIE (consultation des catalogues de métadonnées)

30 3.5 Mise en œuvre La Direction de l'eau réunit un groupe de travail, à partir de janvier 2005, qui examinera ce Livre vert et les commentaires qui lui seront adressés. Il a pour mission de définir les spécifications d'une architecture commune, de déterminer un programme d'actions et d'en suivre la mise en oeuvre. Dans le cas de développements de nouveaux projets dont le lancement est prévu à partir de 2005 (banques de données sur les plans d eau, les eaux de surface continentales, l assainissement, les pressions, l économie, les crues, etc.) ou de refonte d applications existantes (Hydro, Quadrige), on se placera d emblée dans le cadre de l architecture commune du SIE. Pour les services communs, notamment ceux relevant du référentiel Sandre, leur mise en œuvre doit débuter dès 2005 afin d être disponibles pour tous les nouveaux développements. Pour les systèmes existants, on adoptera une mise en œuvre progressive des services chez les partenaires en garantissant des évolutions en fonction des besoins des usagers. 4 ANNEXE : TECHNOLOGIES UTILISÉES Ce chapitre décrit les principales technologies utilisées dans le cadre de l architecture du SIE. Il figure ici afin de donner au lecteur une indication sur les solutions techniques envisagées, sans souci d'exhaustivité ni de rigueur. L ensemble des technologies retenues participe à une architecture de services que l on décrit généralement comme un empilement de couches selon le schéma suivant : Fonctions Qualité de service ORCHESTRATION PUBLICATION / DESCRIPTION DES SERVICES SERVICE DE COMMUNICATION SECURITE TRANSACTION MANAGEMENT TRANSPORT Figure 2 : Constituants de l architecture technique Actuellement, il n'est pas prévu que l architecture du SIE spécifie tous les éléments de ce schéma : l orchestration de services et les transactions à l échelle du SIE ne sont pas envisagées. 4.1 Les canaux de communication Plusieurs canaux de communication sont retenus, tous basés sur l Internet : 30

31 HTTP v1.1 (web non sécurisé) pour la consultation des services, notamment de la part du public ; HTTPS (web sécurisé), notamment pour exposer les données ou les administrer quand les échanges doivent être chiffrés et protégés par l authentification des parties ; SMTP pour les envois de messages, notamment dans le cadre de mécanisme de notification (de mise à jour du référentiel, de disponibilité de données commandées) ; JMS, pour les interactions asynchrones par messages ; FTP pour le chargement ou le déchargement des données ; WebDAV (Web-based Distributed Authoring and Versioning) protocole de l IETF, extension de HTTP, qui permet de déposer, synchroniser et publier des fichiers sur des serveurs distants, de gérer les droits d accès, de contrôler les accès concurrents et de suivre les versions successives d un document. 4.2 L'infrastructure des services Le style REST Le style REST (REpresentational State Transfer) est un style d architecture répartie hypermédia proposé par Roy T. Fielding dans sa thèse «Architectural Styles and the Design of Network-based Software Architectures» (2000). Ce style a été conçu pour décrire (rétrospectivement) l architecture du Web, mettant en exergue le caractère sans état du protocole HTTP, et considérant que les interactions entre un client et un serveur web ont la forme d un changement d état dû au transfert au client de la représentation de la ressource qu il a requise. Ce style repose sur les notions de ressource, qui s applique autant aux pages web qu aux services web, d URI (Uniform Resource Identifier) et de représentation. Le principe de ce changement d état est le suivant : à partir d un état d information initial, le client requiert une ressource web qu il référence en utilisant une URI connue dans cet état ; le Web répond à cette requête en retournant au client une représentation de cette ressource, ce qui place le client dans un nouvel état d information. La représentation d une ressource (qui est transférée du serveur au client) a une nature d hypermédia, c est-à-dire contient des URI d autres ressources. Le client, recevant cette représentation, est donc placé dans un nouvel état qui lui permet de construire et d utiliser de nouvelles URI pour requérir les ressources qu elles désignent, etc. Le client change ainsi d état en «naviguant», mais le serveur n a pas d état : la requête doit contenir toute l information nécessaire à sa compréhension par le serveur (qui oublie les requêtes précédentes). En réalité, le client n interroge pas un «serveur web», mais le «Web» : le protocole HTTP (avec le service de noms de domaines de l Internet) a la capacité d une part de relayer la requête à travers des «proxys» (mandataires de sécurité), d autre part d utiliser des caches pour optimiser l efficacité du réseau. Ceci est un avantage du style REST sur le protocole SOAP, ces possibilités du protocole HTTP n étant pas directement utilisables par SOAP 1.1. Toutes les ressources sont accessibles à travers une interface générique, l une des méthodes GET, POST, PUT ou DELETE du protocole HTTP : GET est utilisée pour obtenir une représentation d une ressource, sans causer d effet de bord ; dans le cas d un service, ceci permet d obtenir ses propriétés ou le 31

32 résultat de l exécution d un processus ; POST est utilisée pour modifier ou créer une représentation d une ressource, sous la forme d un contenu XML de la requête ; dans le cas d un service, ceci permet de transmettre au serveur le contexte de création d un processus (ses paramètres d exécution) ; PUT est utilisée pour créer une représentation d une ressource ; DELETE est utilisée pour supprimer une représentation d une ressource. Aucune contrainte n est imposée au contenu XML des messages POST ou PUT, dès lors qu il est interprétable par la ressource requise par la requête, contrairement à SOAP, qui impose la syntaxe SOAP. La syndication des contenus entre des sites web, au moyen de RSS, est un exemple de service web selon le style REST Le protocole SOAP A la différence de REST, SOAP (Simple Object Access Protocol), est un protocole ; il est destiné à l échange d information structurée dans un environnement réparti. Proposé par Microsoft, SOAP est une spécification du W3C depuis SOAP transporte l information au moyen d une encapsulation XML normalisée, conçue pour être indépendante de tout modèle de programmation et d implémentation. D une manière simplifiée, le protocole SOAP permet d échanger des données (XML selon une sémantique donnée ou d autres formats de données) d un point (émetteur) à un autre point (récepteur) en les encapsulant dans un message contenant : 1. une enveloppe ; 2. un en-tête qui contient des informations spécifiques aux services SOAP et permet notamment de véhiculer des informations liées aux transactions, au routage ou à la sécurité (la plupart des spécifications WS-Agreement, WS-Addressing, WS- Eventing,, s appuient sur cet en-tête pour «compléter» le protocole SOAP) ; 3. un corps contenant toutes les informations sur l appel distant (paramètres, données XML, ) ; 4. éventuellement, des attachements qui permettent de véhiculer des données hors du corps, comme un fichier compressé ou des images. Le message est ensuite échangé dans un quelconque protocole d interaction (HTTP, SMTP, IIOP, voire JMS) conformément à une liaison entre la spécification de SOAP et son implémentation sur l un de ces protocoles. Concrètement, SOAP est toujours utilisé avec le protocole HTTP. Le protocole SOAP est complété par le langage WSDL (Web Service Description Language), dialecte XML dédié à la description de tous les éléments nécessaires pour interagir avec un service web. La norme SOAP 1.2 permet de combiner les deux approches, par le choix d un schéma d échange par «messages de réponse», utilisable pour récupérer l information : la requête est un GET usuel et le message de réponse est un POST avec un contenu SOAP Les géoservices Les géoservices sont des services web ayant trait à l information géographique. Ils font l objet de spécifications élaborées et publiées par l OGC (Open Geospatial Consortium), visant à l interopérabilité de l information géographique, en vue d en faciliter une diffusion et une utilisation la plus large possible. Ces spécifications, résultant de la coopération d industriels et de laboratoires publics, sont des normes ouvertes qui bénéficient 32

33 à la fois d implémentations par les principaux éditeurs de logiciles pour les systèmes d information géographique et d implémentations libres, comme MapServer. Les spécifications présentées ici sont WMS, WFS et SLD. L OGC définit également des services de transformation des coordonnées, d accès aux fonds de carte, de catalogage, etc. et aussi de chaînage et d invocation de ces services. Ces services peuvent être utilisés à partir d un client web ordinaire, Cependant, à l exception de l affichage d une carte, ce qui peut être fait directement par un client web, les autres données ne peuvent être complètement exploitées que par un programme spécifique, généralement reporté sur un serveur web, lui-même client de serveurs OGC WMS (Web Map Service): service de cartes géographiques Cette spécification (ISO 19128) fournit un accès uniforme sur le Web à la représentation de l information géographique sous forme de cartes, c est-à-dire d images (PNG, GIF, etc.). Ce service permet d interroger des serveurs WMS pour connaître les «couches» disponibles, de sélectionner l extension géographique, les couches et leur présentation et de visualiser la carte résultant de la superposition de ces couches. Il permet aussi d interroger les serveurs pour obtenir des informations attributaires en un point de la carte ; celles-ci peuvent alors être utilisées pour obtenir des informations plus détaillées, par exemple à travers un service web WFS (Web Feature Service) : service d objets géographiques Cette spécification fournit un accès uniforme sur le Web aux objets géographiques euxmêmes, qui peuvent être obtenus sous forme de documents GML (Geographic Meta Language), et peuvent être créés, modifiés ou supprimés lors d une transaction SLD (Styled Layer Descriptor) Cette spécification permet de définir le style de présentation des objets géographiques, par des règles basées sur CSS (styles des pages web). Combinée avec WMS et WFS, l utilisateur peut personnaliser les règles de présentation Représentation de l information Les représentations textuelles des ressources sont des documents XML 1.0 (seconde édition) du W3C. Les données métier sont représentés par des documents XML-Sandre, c'est-à-dire des documents XML valides par rapport à un schéma XML spécifié par le Sandre. Les données géographiques sont représentés par des documents GML de l'ogc. Les documents web sont conformes à HTML Version 4.1 ou XHTML 1.0, avec séparation stricte du contenu et de la présentation, sous forme de feuilles de style CSS. Les transformations d un document XML sont spécifiées par des règles XSLT Représentation des métadonnées Les formats suivants de description des ressources sont proposés : WSDL 1.1 pour décrire les services web en REST ou en SOAP ; Dublin Core pour les documents HTML et XML-Sandre ; ISO pour la description des données géographiques ; RDF pour la description des sites web (canaux RSS). 33

34 4.2.6 Services d annuaire Les services d'annuaire utilisent le protocole LDAP de l IETF, dont il existe une implémentation libre, OpenLDAP. Ce protocole permet la réplication et le transfert d appel. 4.3 Déploiement Il peut être souhaitable de fournir, non seulement des services, mais des applications indépendantes, notamment pour inciter des acteurs non partenaires à partager leurs données au sein du SIE. Il est nécessaire dans ce cas de recourir à une technologie indépendante de la plate-forme d exécution et de faciliter le déploiement de l application et de ses mises à jour ultérieures. La technologie Java s impose ici (alors que l architecture de services n impose pas cette technologie). Le déploiement des applications bénéficie alors du protocole JNLP (Java Network Launch Protocol) et de l application JWS (Java Web Start) : l installation de l application se fait à partir d un site web et sa mise à jour est automatique si une nouvelle version est disponible sur ce site. La sécurité d exécution locale d une application déchargée depuis un serveur est alors assurée par le modèle du «bac à sable» (toute opération dangereuse pour le système local est interdite), sauf si l application est signée et accompagnée d une politique de sécurité acceptée par l utilisateur. 4.4 Sécurité L architecture du SIE est basée sur l absence d intrusion du SIE dans les systèmes d information des partenaires. la séparation entre les systèmes internes et le système exposé SIE est la première mesure de sécurité. Ainsi, pour la publication et la consultation des données (géoservices, consultation de données agrégées, ), la problématique sécuritaire est un facteur moins important que le respect des performances. Les extensions de sécurité SSL (v2, v3)/tsl (v1), dont OpenSSL est une implémentation libre, sont recommandées. Néanmoins, certains aspects de la sécurité sont à prendre en considération dans ce cadre : L intégrité des informations échangées L information reçue est-elle identique à celle émise? Les fichiers envoyés sont-ils corrompus? L information est-elle fiable? L utilisation de techniques de contrôle simples est possible : le contrôle des fichiers XML transmis peut être effectué par par des sommes de contrôle ou par le calcul d un digest, techniques simples implémentées dans tous les langages de développement. L autorisation d accès aux services L utilisateur d un service est-il autorisé à le faire? Ici encore des solutions simples peuvent être mises en œuvre. Pour la transmission et la mise à jour du référentiel SIE par le Sandre, la sécurité se révèle un enjeu plus important : la mise à jour des référentiels exige souvent l intégration des nouveaux éléments dans le sous-système du partenaire. Le principe de non-intrusion ne permet pas alors une mise à jour automatisée du référentiel dans ce sous-système. Tant qu une stratégie de sécurité ne sera pas disponible pour le Sandre et les partenaires du SIE, la mise à jour du référentiel devra donc s opérer via une intervention humaine (récupération des fichiers de mise à jour et importation spécifique). Des standards plus complexes peuvent être mis en œuvre lors de services plus sensibles (données non validées, ) : WSS (Web Services Security) d OASIS définit les outils de base 34

35 pour protéger l intégrité et la confidentialité d un message SOAP ainsi que les moyens d associer à un message des mécanismes de sécurité. WSS est construit à partir de technologies de sécurité existantes, notamment la signature numérique XML (XML Digital Signature), le chiffrement XML (XML Encryption) et les certificats X.509 (infrastructure à clé publique). La mise en œuvre d'une architecture de sécurité devra s effectuer en relation avec les projets de l ADAE, notamment le plan de renforcement de la sécurité des systèmes d information (PRSSI). 4.5 Performances Une architecture à base de services répartis et interopérables est souvent confrontée à des problèmes de performances. Les goulets d étranglement sont en effet nombreux : le réseau Internet utilisé pour les échanges ; les services réalisant les traitements demandés dans un contexte multi-utilisateurs ; les bases de données stockant l information ; le portail publiant la donnée via des transformations XSL. Mais si les processus métier n exigent pas des temps de réponse très courts, il est important de veiller à offrir à l usager un service dont la performance soit proche de celui proposé par un site Internet accédant directement à une base de données. Plusieurs approches sont à prendre en compte lors de la mise en œuvre des services : optimisation des requêtes en base de données ; stratégie de cache ou de réplication contrôlée ; échanges des seules données XML réellement nécessaires (les codes, ) ; compression de données XML ; mise en œuvre de services asynchrones. L une des difficultés réside dans la multiplicité des acteurs dans une architecture distribuée : le fournisseur de services offre un service qui est utilisé par un autre acteur, qui peut être luimême fournisseur de services. Si ce service n est pas performant, le système du fournisseur n est pas impacté alors que l utilisateur final subit globalement cette mauvaise performance. Les fournisseurs de services doivent veiller à garantir une performance de leurs services au moins égale à celle de leur propre site web. 4.6 Supervision Tant que le SIE reste un assemblage de modules indépendants par thématique avec un nombre d acteurs très limités, l exigence de supervision reste faible. Par contre, la mise en œuvre d une architecture répartie regroupant de nombreux fournisseurs de services risque d entraîner des difficultés de management. Ceci nécessite la définition de critères de qualité pour la fourniture et l exécution des services ainsi que la supervision de l exploitation. Bien que de nombreux produits 14 existent déjà pour assurer des fonctionnalités de base, les standards de management des services web sont en cours de spécification, notamment WSDM (Distributed Management) de l OASIS et WS-Agreement de la Globus Alliance (GRID). La supervision est basée sur : la mise en œuvre d agents spécialisés par type de ressource (réseau, base de données, serveurs, ) qui sondent la ressource ; (14) Par exemple, Ambertpoint, Actional, Blue Titan, Infravio, Confluent, HP Talking block. 35

36 un outil central de supervision des agents qui joue le rôle de «manager» en communiquant avec les agents pour récupérer les informations sur l état du système et en agissant sur ceux-ci selon les besoins (arrêt d une ressource, changement de l affectation des capacités mémoires ). La supervision est un enjeu fort pour la qualité des services offerts aux utilisateurs. Néanmoins, sa mise en œuvre sera restreinte aux processus métier exigeant un niveau de disponibilité élevé. 36