Ce document, rédigé par Rémy Tourment, a fait l'objet d'une communication aux Rencontres Nationales de l'Annonce des Crues en septembre 2001.
Dans le cadre d’un marché passé par le Ministère de l’Environnement en 1987, la société Centralp Automatismes a développé un système destiné à équiper les réseaux automatiques pour la collecte et le traitement des données pluviométriques et limnimétriques en annonce de crues.
Ce système, dit « système NOE » comprend :
· une unité de traitement logiciel sous UNIX (il s'agit d'un poste micro informatique et de logiciels associés),
· une unité de collecte ou frontal (il s'agit également d'un poste micro informatique, accompagné de logiciels spécifiques, mais dans ce cas sans interactivité),
· des stations de mesure,
· un outil de maintenance dénommé piptel,
· un logiciel de traitement des données hydrologiques (WINNOE)
Actuellement, une trentaine de services sont équipés du système NOE.
Deux des trois éléments fondamentaux de ce système ont connu des évolutions récentes :
· les stations de mesure compatibles avec le système sont désormais des stations répondant aux spécifications PLQ 2000, dénommées les stations NOE 2000 ;
· le frontal a été modifié pour être capable d'interroger les stations PLQ 2000.
Actuellement, de nombreux services d’annonce des crues rencontrent des difficultés sérieuses dans l’utilisation du poste central NOE, qui demande une évolution rapide.
On peut sérier les problèmes parmi les deux types suivants :
· problèmes de fiabilité et de continuité du service ;
· problèmes d'insatisfaction par rapport au fonctionnement normal actuel.
Les problèmes de fiabilité sont dûs aux difficultés de remplacement d'une ou de plusieurs parties matérielles du système, principalement à cause de l'ancienneté (obsolescence) du matériel, et de difficultés d'approvisionnement à l'heure actuelle en matériel compatible avec les anciennes versions de logiciel utilisées. On peut pallier à ces problèmes en assurant un remplacement du matériel à l'identique, par des moyens à trouver (fins de stocks de fournisseurs, utilisation de matériels déclassés par d'autres services, ...). L'obsolescence des versions du système d'exploitation (Unix SCO système V) et de la base de données (Informix v. 4.10) qui ne sont plus compatibles avec les PC en vente actuellement, fait qu'en cas de panne matérielle sur un poste central, il est très difficile de le remplacer.
Dans l'ensemble, les problèmes d'insatisfaction sont liés principalement au(x) poste(s) central (et graphique). Pour pallier à ces problèmes il est nécessaire de faire évoluer le système (développements à prévoir, éventuellement changement de système).
Devant les difficultés rencontrées par les SAC utilisateurs de NOE, la Direction de l'Eau du MATE a confié au CETE Méditerranée une mission d'état des lieux : compte tenu des nombreux problèmes rencontrés par les utilisateurs du système NOE, ainsi que des besoins d'évolution recensés, il a été ressenti le besoin de faire un bilan de ces problèmes, et de faire un état des lieux des solutions existantes ou à développer pour les évolutions futures du système.
Dans un premier temps, une synthèse des éléments techniques a été établie, avec la participation de services utilisant le système NOE. En parallèle, des systèmes de collecte de mesures autres que NOE (CRISTAL, LISAH, SIRCADE, ...) ont été étudiés.
Un rapport présentant l'ensemble de ces éléments a été établi par le CETE Méditerranée. Une réunion à laquelle étaient invités l'ensemble des services utilisateurs de NOE, ainsi que la société Centralp, s'est tenue à Paris le 9 novembre 2000. Une version provisoire de ce rapport a été diffusée à cette occasion. Un questionnaire a été adressé à l'ensemble des services pour recenser les principaux problèmes rencontrés, ainsi que les fonctionnalités ressenties comme nécessaires par les services. Le rapport, dans sa version finale, intégrait les réponses à ce questionnaire, ainsi que les éléments (pistes de solutions) qui se sont dégagés lors de la réunion du 9/11/2000.
Une des pistes d'évolution pressentie consistait en une évolution du frontal NOE vers une unité plus intelligente, intégrant une base de données et pouvant être utilisée dans une architecture client-serveur avec différents outils d'exploitation, l'ensemble actuel "poste central / poste graphique" pouvant être abandonné au profit d'applicatifs plus modernes et ouverts.
Le SAC SNRS a décidé de se charger de la Maîtrise d'Ouvrage de la réalisation de cette évolution, assisté, pour la définition des éléments techniques, d'un groupe de travail composé de représentants de :
· la Direction de l'Eau (DE) du Ministère de l'Aménagement du Territoire et de l'Environnement (MATE) ;
· la Direction Régionale de l'Environnement (DIREN) Rhône Alpes, Délégation de Bassin (DB) Rhône Méditerranée Corse ;
· le SAC de l'Ardèche ;
· le SAC du Vaucluse ;
· le CETE Méditerranée.
Il a fallu prendre en compte l’existant. En effet, il n'est pas possible, pour la majorité des services, de remplacer directement et entièrement l'ensemble de leur réseau NOE (PC + stations). Il a donc été privilégié une solution permettant l'évolution du système NOE, au détriment du développement ex nihilo d'un nouveau système, ou bien encore de l'adoption par tel ou tel service d'une ou l'autre des solutions développées par d'autres services ou sociétés (comme LISAH, CRISTAL ou SIRCADE).
Pour remédier aux défauts constatés de la version actuelle, et pour préserver l'avenir, les éléments suivants ont été choisis comme contraintes à imposer à la nouvelle version du système :
· modularité : architecture de programmation plus moderne (plus de souplesse pour des évolutions ultérieures)
· architecture Client / Serveur pour l'accessibilité des applicatifs aux données
· base de données SQL (exploitable par de nombreux applicatifs standard du commerce)
· ouverture vers d’autres médias (radio numérique, téléphone satellite, TCP/IP)
· ouverture du système : possibilité de concurrence entre fournisseurs et développeurs pour l'aval de la chaîne (applicatifs clients, traitements, serveurs secondaires, ...)
De manière apparemment paradoxale, il a été décidé de faire évoluer en priorité le frontal et non pas le poste central, bien que le frontal ait bénéficié d'évolutions plus récentes que le poste central, et bien que les problèmes rencontrés à l'heure actuelle concernent principalement le poste central.
Mais l'ouverture du frontal (par une intégration d'une base de données, ainsi que par son fonctionnement autonome) et la modularité de l'architecture d'un système client serveur permettent justement de s'affranchir du poste central actuel.
Le frontal actuel, sorte de "boite noire" de communication, ne permettait en aucun cas d'arriver à une architecture Client Serveur satisfaisante.
Les fonctions de base du futur frontal sont :
· les communications avec les stations (NOE et PLQ 2000). Il s'agit là de conserver les fonctions actuelles du frontal
· un fonctionnement possible de manière autonome, ce qui est rendu possible par l'introduction d'une base de données locale contenant la configuration réseau, ainsi que les données (mesures) brutes. Il s'agit là de l'évolution essentielle.
De plus un grand soin est pris à préserver la modularité de l'architecture de programmation, l'ouverture du système, ainsi que la possibilité de développements ultérieurs (prise en compte de nouveaux médias de communication ou d'évolutions des stations PLQ 2000).
En parallèle aux évolutions du frontal, il est bien évident qu'il existe le besoin de développer des applicatifs clients utilisant les données recueillies auprès des stations par le frontal.
On peut, entre autres, lister les clients suivants :
· calculs
· sorties : visualisation graphiques, impression de tableaux et de graphiques
· exportations vers d’autres formats de fichiers
· alarmes
· aide à la production des messages réglementaires de crues
· communication de données vers le public (Minitel, WEB,...)
Il sera, de plus, toujours possible ultérieurement (grâce à l'architecture choisie) de développer des fonctionnalités non prévues, par exemple la communication entre les bases de données de deux services (bases de données des frontaux respectifs, ou bien plutôt entre les bases de données élaborées).
Maître d’ouvrage : SNRS
Définition des besoins : SNRS + DIREN DB RMC + SAC 07/84 + MATE/DE + CETE
Consultations ponctuelles (au moins une fois pour chaque grande étape) de l'ensemble des services utilisateurs de NOE, ainsi que des services responsables du développement des autres "grands systèmes" de collecte (DIREN DB Seine Normandie, DIREN DB Loire Bretagne, DIREN DB Adour Garonne).
A l'heure actuelle cette opération respecte assez bien le calendrier envisagé initialement :
Le cahier des charges des évolutions du frontal a été achevé et transmis à la société Centralp début juillet 2001. La proposition soumise par cette dernière est en cours d'audit par un cabinet spécialisé en assistance en maîtrise d'ouvrage dans le domaine de l'informatique. Le marché devrait être passé en octobre
En parallèle, débute en septembre la définition par le groupe de travail des logiciels clients de 1ère urgence. Cette phase de définition ne devrait pas dépasser fin 2001. Elle sera suivie d'une mise en concurrence de différentes sociétés pour la réalisation de ces logiciels clients.
Le but est de disposer à la fin du premier semestre 2002 d'un ensemble fonctionnel (frontal et logiciels clients) et opérationnel.
Le SNRS, en tant que maître d'ouvrage, sera bien entendu le premier service disposant du futur système. Les services associés à la définition du futur système (DIREN DB RMC, SAC 07, SAB 84) figureront également parmi les premiers utilisateurs. Ils seront de plus mis à contribution dans les phases de tests, permettant de valider le futur système dans différentes configurations matérielles.
Il est néanmoins prévu la possibilité d’utiliser le futur logiciel frontal par d’autres services utilisateurs de NOE. Il est en effet prévu dans le marché que la propriété intellectuelle des développements soit acquise au maître d’ouvrage, le marché prévoyant un prix pour l'installation et la formation.
En ce qui concerne les applicatifs clients, les mêmes dispositions seront prises : tout service utilisateur de NOE pourra bénéficier de licences d'utilisation. Mais tout service ayant des besoins de traitement non satisfaits par les applicatifs clients pourra également faire développer à la demande des applicatifs spécifiques, grâce à l'architecture retenue.