Bilan des fonctionnalités manquantes ou incomplètes sur l’outil Geonetwork69

Comme nous venons de l’évoquer, pour décrire les jeux de données la norme 19115 et la directive INSPIRE conseillent d’utiliser des mots clefs dans les métadonnées. Afin de faciliter la saisie et la gestion des mots clefs, l’outil Geonetwork intègre un dictionnaire dans lequel il est possible de les

enregistrer. Seulement la gestion de ce dictionnaire est sommaire. Cela se résume à une simple liste de mots. Pour ma part je souhaite avoir une gestion des thésaurus ; c’est à dire une gestion des mots clefs plus complète gérant

aussi les liens de sens entres eux. L’intérêt étant de faciliter et d’améliorer les recherches. En effet avec l’utilisation des thésaurus la recherche d’un terme général donne accès aux

métadonnées contenants les termes proches.

Ici une illustration d’un thésaurus simple représentant les liens entre le climat, la pluviométrie, la température et le gel. Nous comprenons immédiatement l’intérêt d’un thésaurus face à l’utilisation d’une simple liste de mots clefs inorganisés.

Un autre intérêt est de faciliter la saisie pour les contributeurs en les informant sur l’origine et sur la définition du mot clef qu’ils saisissent dans les métadonnées. C’est important car cela donne à l’auteur l’assurance que le mot utilisé est bien celui recherché. L’accord sur le sens des mots utilisés par les contributeurs et les consultants est un point essentiel pour partager des données.

Afin que les différents points évoqués soient possibles, il est nécessaire de modifier l’outil pour que ce dernier réalise l’auto complétion des mots clefs saisis, et affiche en même temps leurs définitions. Par ailleurs il est aussi nécessaire de modifier le moteur de recherche afin que ce dernier ne gère pas de simples listes de mots, mais bien les thésaurus. Le principe de la modification souhaitée est de faire en sorte que le moteur de recherche effectue

automatiquement la recherche sur les mots clefs proches et liés à ceux recherchés. Pour continuer notre liste des défauts de l’outil, Geonetwork ne fournit pas de fonctionnalités de contrôle et de suivit des modifications des métadonnées. Il est, par exemple, impossible de savoir qui a créé ou modifié un jeu de métadonnées, ni de connaître les dates de créations et de dernières modifications. Or pour notre projet ces informations sont essentielles, car d’un point de vue légal c’est la personne qui publie le contenu qui en est responsable. Il est donc indispensable de modifier l’outil pour faire un suivit des

modifications et prendre en compte l’affichage des dates de création, de modification, ainsi que des noms des propriétaires et du dernier modificateur des métadonnées.

Par ailleurs il n’est pas possible dans la version 2.1 de savoir quelles sont les métadonnées non contrôlées ou modifiées depuis le dernier contrôle. Si on veut que les contrôleurs puissent faire un travail simple et efficace de relecture et de validation des métadonnées, il est nécessaire d’améliorer l’outil sur ce point.

Ensuite la gestion des droits n’est pas adaptée à l’utilisation que nous souhaitons en faire. Actuellement un utilisateur a la possibilité de donner des droits sur un jeu de

métadonnées uniquement aux groupes dont il est membre. L’outil doit être modifié pour qu’il soit possible à un groupe de donner les autorisations de lecture et d’accès aux partages des données à un autre groupe.

Pour finir cette liste il est aussi nécessaire de corriger certains bugs importants de l’outil. A titre d’exemple la recherche par zone géographique ou par groupes d’utilisateurs ne fonctionne pas parfaitement. En effet un jeu de métadonnées est introuvable si la zone

géographique n’est pas correctement définie ou encore l’index piloté par le moteur d’indexation « Lucene » n’est pas remis à jour quand les autorisations d’un jeu de métadonnées sont modifiées. A ces bugs graves s’ajoutent des problèmes déroutant pour l’utilisateur. L’un d’eux concerne l’édition des métadonnées. Par exemple lorsque l’on ajoute ou supprime des éléments dans un jeu de métadonnées, l’ascenseur de la fiche retourne systématiquement en haut, et l’utilisateur doit parcourir la fiche pour retrouver l’endroit où il était en train de travailler. Un dernier problème vient du mécanisme de validation des

métadonnées. Ce mécanisme contrôle qu’un jeu de métadonnées soit toujours conforme à la norme ISO 19115 ou plutôt à la norme ISO 19139 qui est le standard d’implémentation en XML de la norme ISO 19115. Le problème de ce mécanisme de validation est qu’il est impossible pour l’utilisateur de connaître la cause d’un refus de validation d’un jeu de métadonnées, car le simple affichage du résultat de non-conformité est insuffisant pour corriger le jeu de métadonnées.

5.3.7. Bilan de projet et réorientation corrective

Je pensais à priori que l’intégration au système d’information de l’outil Geonetwork ne nécessiterait pas tant de travail. Au regard du bilan induit par la pratique de l’outil, force est de constater que je me suis trompé sur ma première évaluation. En tout état de cause, du fait du nombre d’éléments à développer et à améliorer pour la partie description des données, mais aussi de par ma sous-évaluation du temps nécessaire pour communiquer avec les différents partenaires sur le projet ; j’ai du modifier ma planification pour avoir le temps nécessaire au développement des fonctionnalités manquantes ou à améliorer.

Mon planning qui prévoyait un mois pour la personnalisation de l’outil Geonetwork ne donnait pas la possibilité de développer toutes les fonctionnalités précédemment énumérées. J’ai par conséquent du faire un choix dans les fonctionnalités à développer. Pour ce faire j’ai classé les fonctionnalités en deux catégories. Les fonctionnalités critiques d’une part.

J’entends par critique que ces dernières sont nécessaires pour que le système fonctionne de la façon prévue par le dossier de conception. Et d’autre part les fonctionnalités non critiques qui facilitent l’utilisation, la gestion ou encore améliorent l’ergonomie de l’outil. J’ai ensuite établi un sous classement des fonctionnalités critiques, pour déterminer les fonctionnalités nécessairement présentes dans la première version que j’allais mettre à disposition des utilisateurs en test.

Voici ci dessous le résultat de ce classement où nous retrouvons les fonctionnalités et améliorations listées et détaillées dans les quatre paragraphes précédents.

o Fonctionnalités critiques et nécessaires à l’évaluation de l’outil

- Suivit des modifications des métadonnées pour connaître la date et l’auteur de la dernière modification d’un jeu de métadonnées.

- Gestion des mots clefs pendant l’édition pour fournir à l’utilisateur toutes les informations sur le vocabulaire qu’il utilise et faciliter la saisie des descripteurs.

- Gestion des mots clefs pendant la phase de recherche pour trouver les métadonnées contenants ceux proches ou liés à ceux saisis dans les critères de recherche.

o Fonctionnalités critiques mais non nécessaires à l’évaluation de l’outil - Conformité des modèles de métadonnées à la directive INSPIRE

- Suivit des modifications des métadonnées pour lister les métadonnées non contrôlées ou modifiées depuis le dernier contrôle.

- Modification de la gestion des autorisations pour qu’un utilisateur puisse donner les autorisations d’accès aux groupes dont il n’est pas membre

- Correction du bug de l’index Lucene non remis à jour lorsque les autorisations sont modifiées.

o Fonctionnalités non critiques :

- Correction du bug de recherche par groupe d’utilisateur. - Correction du bug de recherche par zone géographique.

- Amélioration des informations relatives à l’impossibilité de valider les métadonnées selon la norme ISO 19115.

- Correction du bug relatif à la disparition des métadonnées dont la zone géographique est mal définie.

- Amélioration de l’interface d’édition pour éviter que l’ascenseur de la fiche ne retourne systématiquement en haut lorsque l’on supprime ou ajoute des éléments dans les métadonnées.