Soutenance mémoire
Une application naturaliste à l’origine d’un besoin de synthétisation et de validation scientifique de données
GeoNature, une application open source et générique de gestion de données naturalistes
Une application mûrie pendant plusieurs années permettant de saisir, organiser et visualiser des données de faune et de flore
Dans les années 2000, le pôle SI du Parc national des Écrins a amorcé un travail de réflexion au sujet des besoins liés à la gestion des données naturalistes. Dans un contexte de diversification des protocoles scientifiques, de diffusion des données et d’innovations informatiques, notamment avec l’arrivée de l’extension PostGIS pour PostgreSQL, la volonté de créer une base de données spatiale multiple a émergé. Au fil des années, plusieurs petites applications ont été développées en interne pour répondre aux différents protocoles de suivi des espèces, chacune contenant son propre modèle de données. La totalité des informations était agrégée dans une base de données plus globale appelée « synthèse faune-flore ». Peu à peu, un système d’information structuré a vu le jour. Le développement d’une application baptisée GeoNature a ainsi été initié en 2012 par les parcs nationaux des Écrins et des Cévennes.
En plus des protocoles particuliers de suivi de certains taxons, les agents notent quotidiennement les espèces qu’ils observent de manière aléatoire sur le territoire du Parc. Un inventaire des données informatisées, réalisé en ja nvier 2019 par le PNE, a permis de lister 187 données de biodiversité (faune et flore), représentant plus de 5 000 espèces différentes observées sur le territoire des Écrins (Maillard, 2019). GeoNature permet de saisir ces observations, de les stocke r de manière organisée dans une base de données, et de les visualiser dans un module « Synthèse » sous la forme suivante : « tel observateur a aperçu telle espèce, à tel endroit, à tel moment, à l’aide de tel protocole ».
Une application en pleine expansion à l’échelle nationale
Le projet GeoNature a entraîné un engouement important et la formation d’une communauté d’utilisateurs et de développeurs (animée par le PNE) provenant de différentes structures utilisant l’application, et mutualisant leurs ressources autour de ce logiciel libre. Par ailleurs, certains modules ont été développés par d’autres structures que le PNE, à l’image du module « Validation OneByOne » qui est actuellement en cours d’élaboration par l’association Picardie Nature.
Depuis la loi pour la reconquête de la biodiversité, de la nature et des paysages promulguée en 2016, les bureaux d’études environnementaux sont contraints de rendre publiques les données générées lors de leurs études d’impact. Ces données doivent donc être remontées à l’INPN en répondant aux formats standards du SINP. GeoNature a été sélectionnée pour aider les bureaux d’études à réaliser cette tâche. Ainsi, une instance nationale de l’application est actuellement déployée par le PNE, le Ministère de la Transition Écologique, le Muséum National d ’Histoire Naturelle (MNHN), l’Agence Française pour la Biodiversité (AFB) et l’IGN pour proposer aux maîtres d’ouvrage un outil de saisie des données brutes de biodiversité (Monchicourt, 2018).
Une nécessité de synthétisation et de valorisation des données brutes de GeoNature
Un module « Tableau de bord »
Les données intégrées à la « Synthèse » de GeoNature peuvent provenir de divers modules de saisie et partenaires. Ces données sont donc variées et hétérogènes, en termes de périmètres taxonomiques et géographiques par exemple. Dans le cadre de la refonte de l’application vers une version 2, la création d’un module « Tableau de bord » a été envisagée, l’objectif étant de fournir une vision d’ensemble des données de la base à travers des graphiques et des cartes appropriés qui répondent aux besoins des utilisateurs.
Une telle démarche de synthétisation des données avait déjà été entreprise dans la versio n 1 de GeoNature à travers la représentation de statistiques simples, telles que des histogrammes du nombre total d’observations selon les années, selon les différents groupes taxonomiques ou selon les différents programmes scientifiques (Annexe 1). Ces graphiques avaient été implémentés sans réelle consultation au préalable de la communauté. La mission de stage a donc consisté à :
Prolonger ce travail en réalisant une analyse des besoins complète, afin que les représentations graphiques et cartographiques soient génériques, en accord avec les attentes de tous les utilisateurs internes au PNE, mais également adaptées au grand public. En effet, le nouveau module sera, à termes, accessible à tous sans authentification dans une optique de sensibilisation et de diffusion.
Réaliser un état de l’art des outils existants pour répondre à ces besoins et déterminer la solution la plus adaptée.
Développer une première version fonctionnelle de ce module avec la mise en place de quelques graphes et cartes correspondant aux besoins identifiés.
Un système de détection automatique des données naturalistes atypiques
Depuis une dizaine d’années, la tendance nationale est à la valorisation et la diffusion auprès du grand public des données de biodiversité. En effet, la méconnaissance de l’état et de la localisation des richesses naturelles entraîne l’installation d’aménagements souvent néfastes pour la biodiversité.
De ce fait, il semble indispensable de diffuser ces données naturalistes afin que celles-ci soient considérées dans les projets de conservation, par la recherche et pour l’information du public (INPN, 2016c).
Des besoins à la fois communs et spécifiques
Recueil de l’opinion du maître de stage
Selon lui, les agents qui déposent des données sur GeoNature ont besoin d’un retour direct sur ces données, d’avoir une vision d’ensemble et concrète de la base. Cela pourrait les influencer par exemple pour aller prospecter des zones où certaines espèces ont été peu observées.
En outre, certains jeux de données de l’INPN sont accompagnés d’analyses statistiques représentées sous forme de graphiques (Annexe 2). Les graphes à implémenter sur le module « Tableau de bord » pourraient s’inspirer de ces exemples intéressants.
Recueil des propositions de la communauté GeoNature
Certains développeurs ont manifesté, sur le GitHub de GeoNature, leur volonté de mettre en évidence la pression d’observation et donc l’effort de prospection pour chaque espèce au sein de GeoNature-Atlas. Cet outil étant majoritairement destiné au grand public, ces idées sont plutôt vouées à être mises en place dans le module « Tableau de bord » qui sera davantage professionnel.
Donovan MAILLARD, anciennement chargé de mission invertébrés au PNE, a beaucoup pris part au projet GeoNature lors de ses fonctions au Parc. Il s’agit, encore aujourd’hui, d’un membre particulièrement actif de la communauté GeoNature. C’est pourquoi un entretien téléphonique a été conclu avec lui afin de récolter son avis sur l’intérêt d’un tel module ainsi que ses suggestions de contenus à inclure. Ces informat ions sont considérées dans la partie regroupant tous les besoins.
Recueil des besoins des utilisateurs directs
Le questionnaire complet soumis aux utilisateurs du groupe de travail « données faune flore » est présent en Annexe 3. Les questions posées ont été orientées vers la conception d’un module supposé très flexible avec la mise en place de nombreux filtres, afin de prendre en compte les profils variés des utilisateurs. Ces informations sont considérées dans la partie regroupant tous les besoins.
Prise en compte des besoins présumés du grand public
Le grand public représentant un type d’utilisateur à part entière du futur module « Tableau de bord », il est nécessaire de considérer ses besoins. Une étude complète n’a pas pu être menée faute de temps, mais il a été supposé que ces utilisateurs seraient davantage intéressés par une interface simple d’utilisation, esthétique et interactive. Les connaissances en biodiversité pouvant varier considérablement d’un utilisateur à l’autre pour ce type de profil, il a également été convenu que l’outil devrait être particulièrement intelligible, avec l’insertion d’encarts explicatifs concernant certains termes et contenus scientifiques.
Un système automatique pour la validation des données ayant déjà été alimenté par des réflexions sur les plans théorique et technique
Recueil des attentes des naturalistes du service scientifique du PNE
La collecte de ces besoins a été réalisée à travers les interviews de deux naturalistes utilisant GeoNature, ayant participé par ailleurs à l’alimentation des réflexions concernant le module « Tableau de bord ». Il s’agit de Ludovic IMBERDIS, chargé de mission vertébrés, et Michel BOUCHE, technicien patrimoine, travaillant au PNE. Leurs avis étant très similaires, il a été possible de les regrouper et les synthétiser.
Il serait nécessaire de faire ressortir toutes les observations atypiques saisies dans la base de données. Pour cela, l’analyse doit se centrer au niveau de l’espèce et considérer trois échelles :
Calendaire : Une donnée doit être mise en valeur si la date d ’observation diffère de celles des autres données déjà récoltées pour le taxon concerné.
Géographique : Une donnée doit être mise en valeur si la zone d’observation diffère de celles des autres données déjà récoltées pour le taxon concerné.
Altimétrique : Une donnée doit être mise en valeur si la plage d ’altitude de l’observation diffère de celles des autres données déjà récoltées pour le taxon concerné.
Un avertissement pourrait être affiché à l’écran lors de la saisie d’une observation anormale par un utilisateur. Ce dernier serait libre d’en tenir compte en corrigeant les informations, ou non. Afin de vérifier la fiabilité des données dès leur production, il serait également intéressant de mettre en place un système d’alerte (notification sur l’application ou mail) destiné à un réseau de validateurs, déclenché lors de la détection d’une donnée hors normes. Ces validateurs pourraient par la suite avoir accès aux éléments précis de la donnée et déterminer manuellement le type d ’erreur, si nécessaire. Il est très important de ne pas supprimer les données identifiées comme atypiques. En effet, en raison du changement climatique, des observations dîtes exceptionnelles se produisent de manière plus régulière, comme la présence d’oiseaux américains en Europe.
Par ailleurs, afin de détecter plus facilement les adaptations comportementales des espèces dues au climat, il serait notamment pertinent de mettre en évidence les observations pour lesquelles les informations sont situées dans les valeurs extrêmes (5%) des données d ’altitude et de période d’observations habituelles pour un taxon donné. Ces données remarquables pourraient être soulignées à travers un autre type d’alerte.
Analyse des travaux déjà réalisés au sein du pôle SI du PNE
GeoNature ne comportant pas de jeu de données identifiées comme erronées, il avait été convenu par le pôle SI du Parc que les observations saisies devraient plutôt être comparées aux données qualifiées comme correctes. Pour ce faire, un « profil type » par taxon avait été amorcé en base de données. Cela a été réalisé à travers une vue matérialisée fournissant différents éléments pour chaque taxon (une entrée par taxon) sur la base des données de la « Synthèse » : zone de répartition estimée avec des fonctions de calcul spatiales, jours minimal et maximal d ’observation dans l’année, altitudes minimale et maximale d’observation, nombre total d’observations. Le travail doit être complété et amélioré, mais ces « fiches d’identité » par espèce servant de référence permettraient de mettre en évidence les données hors normes. En outre, certaines données anciennes sont très peu précises et peuvent fausser les résultats. Par exemple, certaines observations sont seulement associées à une année et non à une date exacte. Il serait nécessaire d’implémenter des seuils de précision pour exclure ces données dans l’élaboration des « profils types ».
Une autre démarche intéressante consisterait à retourner un pourcentage de confiance ou une note de validité pour chaque donnée saisie, étant donné que le PNE n’a pas paramétré de niveaux de validation dans GeoNature. Les critères pris en compte dans ce calcul pourraient être associés à des poids différents, selon leur importance. Ils pourraient notamment concerner, par analogie avec les « fiches d’identité », la date d’observation, la localisation de l’observation, l’altitude de l’observation, l’observateur.
Bilan des besoins
L’idéal pour le PNE serait de pouvoir combiner l’élaboration d’un profil type par espèce et l’attribution d’un pourcentage de confiance pour chaque donnée. Il serait possible, par exemple, de comparer chaque nouvelle donnée au profil type du taxon concerné, et de déterminer un pourcentage de correspondance. Les données ne seraient pas supprimées quel que soit le résultat obtenu, mais les notes calculées seraient associées aux observations dans la base de données et visualisables sur GeoNature. Un système d’alerte, déclenché lors de la saisie mais aussi après soumission de la donnée par l’observateur, permettrait d’informer les utilisateurs sur le doute détecté.
Les réflexions sont déjà bien amorcées, mais elles nécessiteraient d’être davantage cadrées et complétées par une analyse de l’existant. En effet, des méthodes tout à fait différentes pourraient également s’avérer efficaces et pertinentes pour le PNE.
Un module « Tableau de bord » impliquant des besoins précis et variés difficilement accessibles avec des solutions externes
Kibana et Metabase : deux outils open source permettant la création de tableaux de bord interactifs
Kibana d’ElasticSearch
ElasticSearch est un moteur de recherche permettant l’indexation et la recherche de données personnalisées. Ce logiciel, écrit en Java et distribué sous licence Apache, est gratuit, libre et open source. Concrètement, il s’agit d’une base de données NoSQL pouvant stocker de gros volumes de documents (sous format JSON), que l’on peut interroger de manière précise grâce à un langage de requêtes HTTP (architecture REST) offrant de nombreuses fonctionnalités. Ainsi, cet outil met à disposition des utilisateurs une API d’accès aux données et s’utilise donc avec n’importe quel langage de programmation.
ElasticSearch utilise la bibliothèque Lucene, également open source et écrite en Java. Elle offre la possibilité d’indexer et de chercher des données, essentiellement de type texte. Il s ’agit d’une couche intermédiaire entre les données et les programmes. Les index attribués aux documents, de formats divers et variés, permettent d’accélérer et d’améliorer la recherche de contenu.
ElasticSearch s’inscrit dans la suite Elastic qui comprend également le module Kibana. Cette interface permet de visualiser les données ElasticSearch sous forme de représentations graphiques créées par l’utilisateur lui-même : histogrammes, graphes linéaires, diagrammes en secteurs… sans une seule ligne de code. Il est également possible de visualiser des données géographiques sur une carte. Les diagrammes réalisés peuvent être regroupés au sein de tableaux de bord personnalisés, destinés à être partagés.
Enfin, le module Logstash, qui a également été testé dans cette étude, est un logiciel capable d’importer des données en provenance d’un grand nombre de sources, de les uniformiser en les remaniant et de les envoyer vers un système de stockage ( ElasticSearch en l’occurrence). Metabase Metabase est un outil de reporting de données qui se différencie des autres solutions similaires notamment par sa simplicité d’installation et d’utilisation. Cette application open source repose sur un système de questions/réponses : l’utilisateur interroge ses données sous forme de « questions » (formatées par l’application grâce à des filtres), qui sont en réalité des requêtes SQL cachées, et obtient des « réponses » simples sous forme de tableaux tout d’abord, puis au moyen de graphiques en tout genre selon ses envies. Cette solution est très pratique pour les utilisateurs qui ne possèdent pas de compétences en SQL. Toutefois, il est possible de produire des requêtes SQL pour accéder à des résultats plus avancés.
Les données peuvent provenir de bases de données variées : MySQL, PostgreSQL, SQL Server, Oracle… Comme pour Kibana, les diagrammes créés peuvent être exposés dans des tableaux de bord et partagés, grâce à des liens, dans d’autres programmes.
Un module « Tableau de bord » et un protocole de détection automatique de données naturalistes atypiques développés en interne par le Parc national des Écrins
Des mises en œuvre techniques réfléchies et cadrées
Un module GeoNature nécessitant des technologies et outils spécialisés
Après l’installation de l’application GeoNature sur mon poste en local, une partie du stage a consisté à amorcer le développement du module « Tableau de bord » avec la solution identifiée durant la phase précédente. Les sections suivantes décrivent la méthodologie qui a été adoptée pour répondre à cette mission.
Choix des graphes à implémenter
La sélection des représentations graphiques et cartographiques à mettre en place était fonction de leur facilité de déploiement et de leur correspondance avec les besoins identifiés les plus importants. Trois représentations ont été imaginées avant le lancement du développement : un histogramme du nombre d’observations et du nombre de taxons identifiés par année, une carte du nombre d’observations et du nombre de taxons identifiés par zonage, et un diagramme en secteurs de la répartition des observations par rang taxonomique. Ces éléments seront décrits plus précisément dans la présentation du module final. Ils ont été codés de manière successive, les uns après les autres.
Le temps accordé à cette phase de développement a été suffisamment long pour permettre la réalisation de deux autres graphes : des courbes du nombre d’observations par année pour chaque cadre d’acquisition et un camembert de la répartition des taxons recontactés, non recontactés et nouveaux par année.
Mise en forme des données
La première étape du développement consiste à réfléchir aux données indispensables pour la construction de chaque graphe et de l’interface en générale. Le but est d’identifier les cas pour lesquels il est nécessaire de créer une vue mat érialisée en base de données. En effet, une vue matérialisée correspond au stockage des résultats d’une requête SQL sous la forme d’une table. A la différence d’une vue standard, les données sont enregistrées, ce qui implique que la requête n’est pas exécutée à chaque consultation des résultats. En revanche, une vue matérialisée nécessite d ’être rafraîchie régulièrement pour rester à jour. Ce type de vue permet d ’augmenter les performances de manière considérable lorsque la requête concernée est complexe, qu’elle comporte plusieurs jointures ou fonctions de calcul. Trois vues matérialisées, qui seront décrites par la suite, ont été créées.
|
Table des matières
Introduction
I. Une application naturaliste à l’origine d’un besoin de synthétisation et de validation scientifique de données
1. GeoNature, une application open source et générique de gestion de données naturalistes
a) Une application mûrie pendant plusieurs années permettant de saisir, organiser et visualiser des données de faune et de flore
b) Une application complexe, à la fois adaptée aux standards nationaux et personnalisable par chaque organisme utilisateur
c) Une application basée sur des technologies open source
d) Une application en pleine expansion à l’échelle nationale
2. Une nécessité de synthétisation et de valorisation des données brutes de GeoNature
a) Un module « Tableau de bord »
b) Un système de détection automatique des données naturalistes atypiques
3. Des besoins identifiés selon plusieurs sources
a) Une analyse des besoins complète pour la mise en place d’un module de reporting de données
b) Une analyse des besoins partielle concernant la validation scientifique des données
4. Des besoins à la fois communs et spécifiques aux différents types d’utilisateurs
a) Un module « Tableau de bord » nécessitant de la flexibilité pour répondre à l’ensemble des besoins recueillis
b) Un système automatique pour la validation des données ayant déjà été alimenté par des réflexions sur les plans théorique et technique
II. Une analyse de l’existant proposant des outils « clé en main » pour la création de tableaux
de bord et des protocoles variés de validation automatique de données pour GeoNature
1. Des états de l’art destinés à explorer les fonctionnalités offertes par des solutions susceptibles de répondre aux besoins identifiés
a) Un module « Tableau de bord » pouvant être développé en interne ou élaboré à partir d’une
solution open source existante
b) Une analyse de l’existant pour la validation automatique de données reposant sur un travail réalisé par le SINP
2. Un module « Tableau de bord » impliquant des besoins précis et variés difficilement accessibles
avec des solutions externes
a) Kibana et Metabase : deux outils open source permettant la création de tableaux de bord interactifs
b) Des solutions externes ne permettant pas de répondre de manière optimale aux besoins identifiés
3. Des méthodes diverses de validation automatique de données naturalistes basées sur des
réflexions et traitements similaires
a) Une analyse de l’existant basée sur six systèmes d’information traitant des données naturalistes
b) Des protocoles de validation automatique structurés par une démarche commune
III. Un module « Tableau de bord » et un protocole de détection automatique de données naturalistes atypiques développés en interne par le Parc national des Écrins
1. Des mises en œuvre techniques réfléchies et cadrées
a) Un module GeoNature nécessitant des technologies et outils spécialisés
b) Des protocoles de validation automatique permettant de renforcer la réflexion entamée par le Parc national des Écrins
2. Un module « Tableau de bord » interactif et paramétrable, destiné à connaître de nombreuses évolutions
a) Un module comportant différents graphiques et cartes flexibles
b) Une volonté d’optimisation des performances du module
c) Un module perfectible voué à être enrichi par la communauté GeoNature
3. Un protocole automatique de notation des données saisies élaboré dans la base de données de GeoNature
a) Les profils types de taxon, des référentiels pertinents
b) Un calcul de score qui nécessite d’être précisé
c) Un protocole automatique exécuté par des actions déclenchées en base de données
Conclusion
Bibliographie
Liste des annexes
Télécharger le rapport complet
