Premier cycle : Conception préliminaire

5.2.2.1. Formalisation de la phase d’étude du contexte et des besoins

J’ai dans un premier temps réalisé une synthèse de mon étude du contexte qui reprend et formalise ainsi la synthèse précédemment expliquée au sein d’un document écrit. J’ai réalisé ce document dans le but de faire valider ma compréhension du projet par mes supérieurs, et ainsi m’assurer que mon travail prenait la bonne direction.

Ensuite, la phase de conception à proprement parler, a débuté. Au terme de chaque cycle une réunion a eu lieu pour vérifier que mon travail suivait toujours une bonne

orientation. Dans une seconde mesure, ces réunions ont permis de contrôler la qualité de mes travaux. J’ai à ce propos pris en compte quelques corrections apportées par Messieurs

LEFEVRE et PICHOT, ces corrections en amont, même les plus mineures, ont amélioré notablement le résultat final, et ont évité de perdre beaucoup de temps par la suite.

5.2.2.2. Réalisation d'une ébauche de solution

J’ai commencé mon premier cycle de conception en proposant une ébauche de solution très succincte. Cette ébauche liste simplement les actions que le système doit mettre en œuvre pour répondre aux différents besoins, puis énumère ensuite les acteurs et leurs rôles de façon non exhaustive. Enfin, elle propose des exemples de briques techniques qui peuvent être nécessaires à l’implémentation fonctionnelle du système d’information.

Pour présenter cette solution préliminaire, je n’ai pas suivi de standard de présentation tel qu’UML. Pour des raisons de temps, je me suis simplement attaché à faire un document clair et rapide à lire. Cela m’a fourni un support pour facilement discuter avec les décideurs, de la direction vers laquelle je devais orienter mes axes de réflexion pour les futurs cycles itératifs de conception.

Le but de ma première ébauche de solution n’est pas de proposer une solution parfaitement cohérente qui répond à tous les besoins et contraintes. Il n’y a rarement qu’une solution pour répondre à un problème et celle ci n’est ni l’unique, ni la meilleure. Durant la

finale. Cette première solution matérialise simplement ma compréhension du projet sous la forme d’une proposition qui intègre les principaux points formalisés par l’étude des besoins et du contexte.

Avec cette ébauche, mon but principal était de partager cette première réflexion sur l’architecture globale et sur le fonctionnement que peut avoir le système. Et ceci afin de donner une vision globale, et plus concrète du système d’information. Mon but secondaire est aussi de révéler des contraintes et des besoins qui n’auraient pas encore été exprimés du fait par exemple de problèmes de compréhension ou de communication.

5.2.2.3. Présentation de l’ébauche de solution

Le besoin de décrire les données existantes avant de les partager et d'en faire

l'inventaire dans un contexte de grande hétérogénéité de langue, de répartition géographique, de format et de contenu, complété par les contraintes légales de la directive européenne Inspire, m’a amené à utiliser et placer l'utilisation et la gestion des métadonnées au centre du système d'information.

Voici la synthèse de cette ébauche de solution.

J’ai découpé les rôles des utilisateurs en trois grandes catégories :

o Les contributeurs : ils créent ou intègrent dans le système d’information des données pouvant provenir de fichiers, de bases de données ou encore de cartes. Leur travail est de décrire ces jeux de données avec l’aide de

métadonnées.

o Les consultants : ils peuvent en fonction de leurs autorisations accéder aux descriptions des données existantes via les métadonnées. Mais aussi consulter ensuite les données qui sont attachées aux descriptions.

o Les administrateurs : ils gèrent le système d’information contenant à la fois les données et les métadonnées.

Les fonctionnalités principales que j’ai retenues dans cette ébauche sont les suivantes :

o Créer, modifier ou supprimer des données.

o Créer, modifier ou supprimer les descripteurs des données.

o Centraliser les données.

o Centraliser les métadonnées.

o Consulter les descripteurs des données disponibles.

o Consulter les données disponibles.

o Administrer les métadonnées.

o Administrer les données.

Les briques techniques qui m’ont semblé nécessaires pour réaliser le système sont les suivantes:

o Les systèmes de gestion des métadonnées.

o Les systèmes de gestion des bases de données.

o Les systèmes de gestion de cartes SIG (Système d’information Géographique).

o Une interface Web centrale.

o Une interface Web ISS. L’architecture résultante est la suivante :

5.2.2.4. Bilan de l’ébauche

Cette phase de réflexion et de conception préliminaire a duré un mois et s’est terminée le 20 juillet 2007.

Cette réalisation est une bonne chose. D’une part vis à vis de mes responsables, l’ébauche a donné lieu à des discussions, suivit d’un livrable sous la forme d’un document. Cela leur a donc donné l’occasion de mesurer l’avancée de mon travail. Je pense que ce travail les a aussi rassurés sur leurs choix de candidature pour la réalisation du projet. D’autre part cela a mis en lumière un certain nombre de questions qui n’étaient pas ressorties des discussions pendant l’étude du contexte. Certaines d’entre elles, une fois soulevées ont amélioré et accéléré la réalisation des phases suivantes de conceptions : par exemple celles concernant l’emplacement physique des briques techniques.

Faut-il s’orienter vers une solution centralisant les données et les métadonnées ? D’autres questions sont apparues comme notamment :

vis de la capacité de l’infrastructure informatique des ISS. Bien que posée, l’interrogation sur leurs aptitudes à héberger l’interface ISS et à transférer des fichiers restait sans réponses immédiates.

C’est donc à cette étape que j’ai contacté Dieter KOPECKY, Autrichien qui est responsable informatique pour le réseau EVOLTREE. Je lui ai présenté l’ébauche de solution et nous avons discuté de l’hébergement sur le serveur central. Il m’a alors informé qu’un serveur serait à notre disposition en Autriche pour le projet, c’est à dire à l’endroit même où le portail Web EVOLTREE est déjà hébergé.

Il paraissait important pour François LEFEVRE de tenir les différents partenaires au courant de l’évolution de mes travaux et ceci dès cette ébauche. A ce moment du projet, je n’étais pas personnellement très enthousiaste pour communiquer avec les partenaires sur mes travaux et mes avancées. La solution, que j’avais alors, était une ébauche succincte non développée. Par conséquent il ne me paraissait pas judicieux de présenter aux futurs utilisateurs une solution vouée à changer radicalement. Je craignais que les personnes se fassent un à priori, et s’approprie une idée du projet qui ne serait pas le résultat final. Je pensais que la solution finalement proposée aurait tendance à être rejetée car différente de l’impression et des attentes initiales.

J’ai néanmoins suivit le choix de François LEFEVRE. Etant

nouveau dans le réseau, j’en ai profité pour me présenter et j’ai exposé aux partenaires nos réflexions sur le projet. Il fallait que je le fasse de façon globale, mais en même temps j’ai essayé de me focaliser sur les parties qui paraissaient les plus stables à l’époque. Ceci afin d’éviter que ma crainte de rejet final ne se réalise. Il apparaissait déjà clairement pour moi que la gestion des métadonnées serait au centre du futur système d’information. Nous n’avions pas encore défini l’outil de gestion des métadonnées, mais notre choix s’orientait déjà vers Geonetwork (Outil open source gratuit de catalogage orienté pour les données spatialisées ou géoréférencées) ou Geosource (Outils de catalogage hérité de Geonetwork, décliné pour le profil français de la norme ISO19115).

Il m’est apparut nécessaire de les impliquer dès le début et leur ai donc demandé leurs opinions sur les problématiques soulevées, ainsi que sur les choix qui nous apparaissaient comme les plus judicieux. J’ai aussi insisté sur le fait que les choix présentés n’étaient pas arrêtés, et que nous étions ouverts pour accueillir positivement toutes les critiques,

propositions, et questions. Le but étant pour moi d’optimiser les chances de retours concernant les remarques et commentaires.

Cette première présentation du projet était destinée à une partie restreinte des acteurs, à savoir les correspondants des ISS, ainsi que certains responsables du réseau EVOLTREE. Pour présenter le projet de façon plus attrayante à des personnes non ou peu sensibilisées aux problématiques informatiques, j’ai donc choisi de prendre l’outil qui apparaissait le plus adapté pour la gestion des métadonnées, et je l’ai utilisé comme base pour en faire une maquette. Ce travail a ainsi montré graphiquement, ce que pourrait être la partie gestion des métadonnées au sein du réseau des ISS EVOLTREE. Je suis ensuite parti de ce point central pour expliquer la raison de notre choix pour les métadonnées et finalement expliquer les avantages et les contraintes des solutions envisagées.

Avec le recul, j’ai pris conscience des temps de réponses du réseau européen

EVOLTREE, de ses lourdeurs, de sa faible réactivité et du fait qu’il était important de parler du projet aux acteurs dès ce moment, afin de commencer au plus tôt la communication pour

intéresser les acteurs aux problématiques, et aussi pour les sensibiliser aux apports du futur système d’information.

Je souhaite signaler au passage que l’un des buts indirects de la mise en place du système d’information est aussi d’améliorer la réactivité du réseau européen pour les ISS.

5.2.2.5. Réalisation d’une maquette pour l’aspect central de la gestion des métadonnées

Au terme de mon étude des existants pour gérer les métadonnées, j’ai fait un bilan des outils les plus connus tel que MDWeb, RepIso, Geosource et Geonetwork. C’est ce dernier qui m’a rapidement parut être le plus adapté à nos attentes. Il est basé sur une solution pour client universel qui répond parfaitement à notre besoin d’ouverture sur internet. De plus, il suit les dernières normes ISO (International Organization for Standardization ou organisation internationale de normalisation) et notamment la norme ISO 19139 (Cette norme définie l’encodage des métadonnées géographique en XML, ainsi que l'implémentation du schéma XML dérivé de la norme ISO 19115). Mon

avis a finalement été confirmé par la qualité de ses interfaces et par la taille de la communauté qui le développe et qui l’utilise. Bioversity qui est un des partenaires du réseau l’utilise déjà et cette solution est utilisée pour d’autres de leurs travaux. Je suis allé deux jours à Rome du 20 au

21 juin 2007 au tout début de mon contrat à titre prospectif pour discuter de mon projet avec leurs spécialistes et voir comment ils travaillent dans leur collaboration avec le CGIAR (Consultative Group on International Agricultural Research : Groupe consultatif pour la recherche agronomique) pour décrire et partager leurs données et leurs bases de données.

Qu’est ce que Geonetwork? C’est un outil open source financé et majoritairement développé par un ensemble d’organisations membres de l’ONU (Organisation des nations unies) tel que FAO (Organisation des Nations unies pour l'alimentation et l'agriculture) le CGIAR, WFP (Programme alimentaire mondial) ou encore UNEP (Programme environnementale des nations unie). Cet outil est utilisé par une

communauté encore bien plus large qui travaille principalement autour des problématiques environnementales.

Le travail pour effectuer la maquette était relativement simple. Cela a consisté principalement à modifier les feuilles de style de l’application. Il fut aussi nécessaire de modifier une partie de la source dans certains fichiers XML et XSL. Ceci uniquement parce que certaines parties codant pour la présentation graphique sont présentes dans ces fichiers et non pas dans les feuilles de styles.

Au final, pour cette partie, mon temps a plus été consacré à l’installation de l’environnement nécessaire pour faire fonctionner et développer l’outil Geonetwork, qu’à la réalisation de la maquette elle-même. En effet l’environnement nécessaire a demandé la mise en place de l’outil de développement Eclipse, de la machine virtuelle JAVA 1.5 et aussi la mise en place de l’environnement serveur incluant Apache2, Tomcat 5.5, et une base de données

PostgreSQL.

Ci dessus quelques écrans de cette première maquette concernant la partie gestion des métadonnées qui est basée sur la version 2.0.3 de l’outil de catalogage de métadonnées Geonetwork.

La réalisation de cette maquette m’a formé à l’utilisation et à l’administration de l’outil de gestion des métadonnées « Geonetwork ». J’ai ainsi pris à cette occasion

connaissance des possibilités de l’outil, mais aussi de ses limites. Cela m’a amené au passage à voir comment est gérée la partie graphique au sein de l’outil.

5.2.2.6. Retours des acteurs sur la présentation du projet.

Comme nous l’avons vu pendant la présentation de la première ébauche de solution, j’ai tout d’abord présenté le projet à Dieter KOPECKY qui est responsable des systèmes d’informations du réseau EVOLTREE le 09 juillet 2007. Le 22 août 2007, j’ai réalisé une seconde présentation diffusée à une quinzaine de personnes dont les correspondants des ISS : seules trois personnes m’ont donné un retour sur la lecture du document.

Le retour de ces trois acteurs est positif et valorisant pour le travail fourni et sur nos choix. Néanmoins le peu de retour m’a amené à me demander si cela était représentatif de l’opinion générale. Je m’attendais à plus de réactivité de la part des acteurs, pensant que mon document susciterait plus d’intérêts de leur part. A ce moment, l’expérience de mes deux responsables Christian PICHOT et François LEFEVRE a été rassurante pour moi à double titre. D’une part leur retour sur mon travail était à la fois positif et encourageant, et par ailleurs, ils n’étaient nullement surpris du faible taux de retour et du silence de la majorité. Paradoxalement et contre toutes attentes, je me suis rendu compte plus tard que ce travail de communication n’avait pas été vain et la majorité silencieuse n’avait pas ignoré ma

présentation. En effet lors de la présentation de la solution finalement retenue en Suisse, certains des destinataires silencieux étaient présents et avaient imprimé le document

d’ébauche de solution. Ils ont fait des commentaires à ce moment sur les évolutions du système entre la solution retenue et la maquette qui avait été présentée initialement. Cela, je dois l’avouer, m’a agréablement surpris car le document avait bien été lu avec intérêt.

5.2.3. Deuxième cycle : Conception avancée et réalisation de deux propositions