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 SIE.DE@ecologie.gouv.fr 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