HAL Id: hal-02785464
https://hal.inrae.fr/hal-02785464
Submitted on 4 Jun 2020HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Développement d’une application web permettant la
visualisation de données agronomiques
Julien Claisse
To cite this version:
Julien Claisse. Développement d’une application web permettant la visualisation de données agronomiques. [Stage] France. Université de Lorraine (UL), FRA.; France. Institut Universitaire de Technologie Nancy Charlemagne (IUT Nancy Charlemagne), FRA. 2018, 41 p. �hal-02785464�
IUT Nancy Charlemagne Université de Lorraine 2 ter boulevard Charlemagne BP 55227
54052 Nancy Cedex
Département informatique
Développement d’une application web permettant
la visualisation de données agronomiques
Rapport de stage de DUT informatique
Entreprise : Institut National de la Recherche Agronomique (Inra), Unité de Recherche AgroSystèmes Territoires Ressources (ASTER) Mirecourt (88)
Julien CLAISSE
Tutrice : Amandine DURPOIX Année universitaire : 2017 - 2018
IUT Nancy Charlemagne Université de Lorraine 2 ter boulevard Charlemagne BP 55227
54052 Nancy Cedex
Département informatique
Développement d’une application web permettant
la visualisation de données agronomiques
Rapport de stage de DUT informatique
Entreprise : Institut National de la Recherche Agronomique (Inra), Unité de Recherche AgroSystèmes Territoires Ressources (ASTER) Mirecourt (88)
Julien CLAISSE
Tutrice : Amandine DURPOIX Année universitaire : 2017 - 2018
Remerciements
Je tiens à remercier l’équipe pédagogique du département informatique de l’IUT Charlemagne de Nancy qui, au long de mes deux années de formation, m’a apporté les connaissances et les compétences requises afin de m’ouvrir les portes du monde de l’informatique.
Je tiens également à remercier l’équipe ASTER de Mirecourt pour leur accueil durant ma période de stage.
Je remercie précisément ma tutrice Amandine DURPOIX qui m’a accompagné et dirigé, tout au long de mon stage, sur le projet informatique qui m’a été désigné ainsi que Jean-Marie TROMMENSCHLAGER par lequel le projet a été initié, Steven WILMOUTH qui m’a aidé à mieux comprendre les outils utilisés et donné des conseils sur les évolutions possibles du projet et enfin, Jean-François MARI, parrain de stage ayant pu m’aider et me conseiller sur l’avancement du projet.
Table des matières
Introduction 7
I - Présentation de l’entreprise 8
I - 1. Institut National de la Recherche Agronomique 8
I - 2. L’unité AgroSystèmes TErritoires Ressources 8
II - Présentation du projet 10
II - 1. Découverte du projet 10
II - 2. Plan temporel du projet 10
II - 3. Données exploitées 12
II - 3. A. ASTER-ix 13
II - 3. B. Système d’Information Géographique 14
III - Travail réalisé 14
III - 1. Étude approfondie 14
II - 1. A. L’application et son environnement 14
II - 1. B. Structure de l’existant 15
II - 1. B. a. Organisation des données stockées 15
II - 1. B. b. Application Javascript 16
II - 1. B. c. API PHP 18
II - 1. C. Réalisation de la documentation technique 18
II - 1. D. Vers un nouveau système d’exploitation 19
III - 2. Améliorations et ergonomie 20
III - 2. A. La réunion 20
III - 2. B. Logiciel de gestion de versions 22
III - 2. C. La barre d’outils 23
III - 2. D. Le plein écran 23
III - 2. E. Menu détaillé de la parcelle 24
III - 3. Nouvelles fonctionnalités 25
III - 3. A. Sélection de l’année 25
III - 3. B. Gestion de fond de carte en local 26
III - 3. C. Climat 30
III - 3. D. Couche effluent 32
IV - Réunions et entretiens hebdomadaires 33
Perspectives d’évolution 34
Table des sigles 37
Table des illustrations 38
Table des tableaux 39
Glossaire 40
Bibliographie 41
Introduction
Dans le cadre de mon Diplôme Universitaire Technologique (DUT) Informatique, je dois, au cours de mes 10 dernières semaines de formation, effectuer un stage en entreprise. Celui-ci permet de mettre en application les connaissances et compétences acquises durant les deux premières années de formation et ce, au travers d’un un projet informatique. Plusieurs demandes de stages ont été faites, et plusieurs entreprises ont accepté mes demandes mais mon choix s’est porté vers l'Institut National de Recherche Agronomique (Inra) afin d’obtenir davantage de connaissances sur l’agriculture et le monde rural qui m’entoure et avoir une idée sur l’organisation du travail d’un institut de recherche.
L’objectif de mon stage est de reprendre le travail d’un ancien étudiant en informatique, travail se basant sur le développement d’une application web et permettant la visualisation de données, issues d’une base de données expérimentale agronomique. Cette application doit être facile d’accès afin de permettre à des ingénieurs et des techniciens de terrain de les exploiter. Cette application sera un outil utilisé lors de visites sur l’Installation Expérimentale afin de répondre aux questions posées par les visiteurs et servira également d’appui oral pour les intervenants. Plusieurs réunions ont été programmées pour que les intervenants puissent prendre en main, s'approprier et constater l’évolution, tout en donnant leur avis sur l’application et ainsi me donner une directive dans le respect maximum du cahier des charges du projet.
Dans la suite de ce document, je vais, dans un premier temps, décrire la structure dans laquelle j’ai travaillé durant ma période de stage. Ensuite, j’expliquerai ma manière de travailler et comment j’ai réagi face au travail qui m’a été demandé. Enfin, je terminerai par décrire une évolution possible du projet.
I - Présentation de l’entreprise
I - 1. Institut National de la Recherche Agronomique
L’Institut National de la Recherche Agronomique (Inra) est un organisme public de recherche agronome fondé en 1946. L’Inra est sous la double tutelle du Ministère de la Recherche et de l’Agriculture. Il est actuellement le premier institut de recherche agronomique en Europe et deuxième dans le monde en nombre de publications. L’Inra est conduit par plusieurs grandes missions à réaliser tel que produire et diffuser des connaissances scientifiques ou encore former des chercheurs agronomes.
I - 2. L’unité AgroSystèmes TErritoires Ressources
L’Unité de Recherche AgroSystèmes TErritoires Ressources (ASTER) est une unité de recherche rattachée au centre de l’Inra de Nancy. Localisée à Mirecourt au cœur de l’Ouest vosgien (88), l’unité est composée de 30 agents titulaires Inra. Elle accueille chaque année plusieurs doctorants, post-doctorants, ingénieurs contractuels ou stagiaires.
L’équipe de l’unité SAD-ASTER est pluridisciplinaire, elle associe sciences agronomiques, sociales et informatiques. Le projet de l’unité est centré sur les relations entre les agricultures et territoires pour accompagner les transformations des systèmes sociotechniques agricoles vers une meilleure durabilité environnementale. L’unité est porteuse de plusieurs réseaux interdisciplinaires de recherche et maintien des partenariats avec des organismes de développement agricole et de gestion des ressources naturelles.
Elle possède une Installation Expérimentale constituée d’une exploitation de polyculture-polyélevage de 240 hectares (détails Illustration 1). Les chercheurs ont choisi de s’intéresser aux formes d’agriculture qui privilégient l’économie d’intrants et valorisent les ressources du milieu et les mécanismes biologiques naturels. Leurs recherches sont donc spécialisées sur les relations entre l'agriculture et les territoires afin d’accompagner les transformations des systèmes socio-techniques agricoles vers une meilleure durabilité environnementale.
Illustration 1 : Schéma représentant le projet de l’Installation Expérimentale de l’Unité de Recherche ASTER
II - Présentation du projet
II - 1. Découverte du projet
Le premier jour de mon stage, pendant l'entretien avec les responsables du projet, le sujet m’a été présenté et décrit. Ainsi, j’ai pu m’adapter à l’environnement dans lequel est inscrit le projet mais aussi les dépendances que constitue ce dernier.
L’objectif de mon stage est donc de continuer la réalisation d’une application web dynamique et simple d’utilisation permettant la visualisation de données expérimentales agronomiques dédiée à des techniciens et des ingénieurs de l’Unité de Recherche ASTER. De plus, j’ai documenté l’application afin que les chercheurs puissent comprendre mon travail. J'ai également dû m’informer auprès du personnel utilisant cette application afin de me permettre de réfléchir à un avis constructif sur l’avancée du travail déjà réalisé.
II - 2. Plan temporel du projet
Le stage s’est organisé en trois grandes étapes. La première étape a été dédiée à la compréhension du projet existant ; c’est-à-dire, maîtriser les outils utilisés au développement de l’application tout en comprenant le code. De même, savoir gérer sa structuration notamment les mécanismes mis en place pour faciliter l’ajout de nouvelles fonctionnalités en formalisant cette appropriation par la rédaction d’un document technique expliquant le fonctionnement de l’application. La deuxième consistait, à partir du compte rendu de la première réunion faite avec les techniciens et les ingénieurs, à obtenir une application stable et correspondant à la demande des utilisateurs. La dernière partie, quant à elle, visait à ajouter de nouvelles fonctionnalités à l’application. Chaque semaine, une réunion avait lieu avec les utilisateurs de l’application afin de constater l’avancée du projet et de donner de nouveaux avis sur les modifications et les ajouts faits entre chaque réunion. L’ Illustration 2, ci-après,
Avril Mai Juin Sem aine 15 Sem aine 16 Sem aine 17 Sem aine 18 Sem aine 19 Sem aine 20 Sem aine 21 Sem aine 22 Sem aine 23 Sem aine 24 Découverte de l'objectif du stage
Prise en main de l'application et de ses outils
Débogues majeurs et optimisation de l'existant
Développement de la fonctionnalité« sélection de l'année»
Développement de la fonctionnalité « fond de carte en locale » Développement de la fonctionnalité «
Climat : bilan hydrique, précipitations, températures » Développement de la fonctionnalité «
Ajout de la couche effluent » Adaptation de l'interface aux besoins
des utilisateurs
Rédaction des commentaires / document technique / document de
développement Rédaction du rapport de stage
Réunions et entretiens
II - 3. Données exploitées
Le Système d’Information de l'Installation Expérimentale d’ASTER ( Illustration 3)
est constitué de bases de données conçues et développées par ASTER (ASTER-ix, PARTUR-ix, PHOTO-ASTER), d’autres unités Inra (Aladin) et d’un Système d’Information Géographique (SIG) adapté aux spécificités d’une expérimentation système, pluri-annuelle en polyculture-polyélevage et interopérable avec des systèmes d’informations animaliers de l’Inra (Aladin).
Illustration 3 : Système d’Information de l’Installation Expérimentale de l’Unité de Recherche ASTER [Durpoix, 2018]
Les deux parties suivantes décrivent les deux éléments utilisés pendant mon stage à savoir ASTER-ix et le Système d’Information Géographique (SIG).
II - 3. A. ASTER-ix
La mise en place en 2004 de l’expérimentation système de l’unité ASTER Mirecourt s’est accompagnée d’un besoin fort d'acquisitions de données très diversifiées. C’est pourquoi, la création de la base de données ASTER-ix (Application pour la Saisie et le Traitement des Événements Recensés sur l’Installation eXpérimentale) a été nécessaire pour permettre la collecte des données issues des expériences et des relevés effectués sur ces installations. ASTER-ix a pour principaux objectifs d’organiser les données, c’est-à-dire inventorier les données disponibles, les regrouper et les structurer mais aussi de rendre accessibles ces données aux utilisateurs en permettant la saisie et les extractions par des requêtes SQL.
Plusieurs types de données sont regroupés dans ASTER-ix dont principalement :
● les Itinéraires Techniques (ITK) : ils caractérisent les différentes manières de conduire une culture, selon les objectifs fixés. Par exemple : toutes les opérations nécessaires à aboutir à la semence d’une céréale, à savoir, le labour du sol et le semis en lui-même.
● les pâturages : indiquant les prairies où se situent les animaux de l’unité ASTER. ● les analyses physico-chimiques : regroupant tous les résultats d’analyses sur les sols
de l’installation, les produits récoltés et consommés, les effluents utilisés et les échantillons de recherches examinés.
● les données de recherche : contenant tous les relevés effectués sur la faune et la flore. Par exemple : des relevés sur les adventices présents dans les cultures, mais aussi sur les maladies ravageuses des cultures ou encore le taux d’arthropodes trouvé sur le sol d’une culture.
À ce jour, ASTER-ix est stockée, manipulée et extraite grâce au logiciel Microsoft Access 2003®. Ce sont plusieurs techniciens et ingénieurs de l’unité qui enrichissent la base de données et qui permettent de rendre exploitable, par différents ingénieurs et chercheurs externes à l’unité ASTER, cette même base de données. [Trommenschlager et al, 2010].
II - 3. B. Système d’Information Géographique
Le Système d’Information Géographique (SIG), recueille des données spécifiques aux parcelles de l’Inra. On peut y retrouver les parcellaires ainsi que leurs zones de mesures reliées à divers protocoles de recherches. Ces données sont créées et utilisées par l’unité ASTER grâce au logiciel ARCGIS®. Ainsi, afin d’établir des liens entre la base de données ASTER-ix et le SIG, l’unité ASTER a décidé que les parcelles devraient avoir un identifiant unique aux deux systèmes, le « NOM_COURT » de la parcelle ou le nom de la zone de fertilité.
III - Travail réalisé
Le projet étant initié par un ancien stagiaire du DUT Informatique de l’IUT Charlemagne, j’ai dû, dans un premier temps, analyser chaque outil et conception utilisés sur l’application pour en connaître son fonctionnement. En peu de temps, ma tutrice et moi nous sommes rendus compte que le déroulement de stage allait s’effectuer en trois grandes parties : réaliser une étude approfondie de l’application, puis travailler l’ergonomie de l’application afin d’en faciliter l’utilisation et enfin, ajouter plusieurs fonctionnalités.
III - 1. Étude approfondie
II - 1. A. L’application et son environnement
Tout d’abord, il m’a fallu connaître l'environnement sur lequel repose l’application. L’application sur laquelle je travaille est donc une application web basée sur un serveur WAMP. Elle peut donc être exécutée depuis un navigateur web une fois l’application installée, en suivant l’URL ci-contre : http://inra-aster.mirecourt/. Toutes les interactions de l’application avec l’utilisateur sont gérées par le langage Javascript. La manipulation des fichiers Microsoft AccessⓇ se fait par l’intermédiaire d’une API écrite en PHP retournant des jeux de données sous forme JSON. L’affichage des couches SIG et du fond de carte se
font grâce à la librairie JavaScript Leaflet. Nous pouvons schématiser les interconnexions des outils comme le montre l’Illustration 4 :
Illustration 4 : Schéma des interactions entre chaque entité de l’application II - 1. B. Structure de l’existant
II - 1. B. a. Organisation des données stockées
L’application comprend beaucoup de jeux de données : plusieurs librairies Javascript, des images, la base de données, … L’application doit être tenue structurée et organisée en ayant une cohérence dans le regroupement des données. À la racine de l’application, nous pouvons trouver trois dossiers principaux et un fichier HTML contenant la structure principale de l’application. Les trois dossiers principaux sont :
● api : comprenant les fichiers nécessaires au fonctionnement de l’API PHP afin de traduire les données de la base.
● assets : contenant les fichiers nécessaires à l’affichage et le design de la page web comme par exemple, les scripts Javascript, les polices d’écritures, les images et les fichiers CSS afin d’organiser l’affichage des éléments sur la page.
● data : organisant toutes les données externes stockées telles que la base de données, des photos de la parcelle à afficher ou encore les fichiers SIG nécessaires à l’affichage des polygones des parcelles.
II - 1. B. b. Application Javascript
Le cœur de l’application repose sur le développement des scripts Javascript qui s’occupe de l’affichage et des interactions des éléments affichés à l’écran, de la récupération des données contenues dans les fichiers Access® indirectement par le biais de l’API PHP et grâce à la librairie Leaflet.js s’occupe de l’obtention et de la manipulation de la carte disponible au démarrage de l’application (Illustration 5).
Le script principal se nomme app.js. Il a pour but d’initialiser l’application et de répondre aux interactions de base de l’application, comme ouvrir un menu ou encore interagir avec la carte. De plus, chaque couche de la carte est guidée par un plugiciel, permettant d’afficher les couches SIG sur la carte ou encore initialiser les interactions avec les polygones affichés sur la carte, une fois le clic ou le passage de la souris effectué sur ceux-ci. À noter que le plugiciel principal initialisé est utilisé au démarrage de l'application pour afficher le parcellaire mais aussi utilisé pour l’affichage de son menu ( Illustration 6) afin d’afficher les
informations de la parcelle extraite de la base de données.
II - 1. B. c. API PHP
L’API PHP a pour rôle de traduire les données extraites de la base de données en format JSON afin que les programmes Javascripts puissent interpréter facilement les résultats des requêtes effectuées. Le développement de l’API a été conçu en respectant le patron de conception Modèle-Vue-Contrôleur (MVC). Ici, le modèle correspond aux requêtes simplifiées présentes dans la base de données. La vue correspond au format JSON retourné après l’appel d’une route de l’API. Le contrôleur a pour tâche de charger les données de la base et de les structurer avant de les renvoyer à l’application. Il m’est facile d’ajouter de nouvelles routes sur l‘API PHP car ce dernier a été programmé en langage objet qui me permet facilement de créer de nouveaux modèles et de nouveaux contrôleurs.
II - 1. C. Réalisation de la documentation technique
À l’arrivée de mon stage, la documentation de l’application n’était pas assez complète, seul un manuel d’installation et d’utilisation de quelques fonctionnalités était réalisé. C’est pourquoi, sur les conseils de ma tutrice, j’ai remis à niveau la documentation nécessaire à comprendre, installer et utiliser l’application. Plusieurs cas d’installations avaient été oubliés lors de sa rédaction comme, par exemple, l’installation sur une autre plateforme et les étapes nécessaires à ajouter pour faire fonctionner l’application. Les pilotes permettant de lire les fichiers Access® ne portaient pas le même nom sous un système Windows 7 qu’un système Windows 10.
De plus, j’ai rédigé un rapport expliquant le fonctionnement interne à l’application grâce à l’appui de diagrammes de séquences permettant de savoir pour chaque fonctionnalité de l’application connaître, la fonction appelée, la route envoyée par l’application Javascript vers l’API PHP pour obtenir les informations nécessaires à la fonctionnalité désirée et enfin, les requêtes appelées de l’API PHP vers la base de données Microsoft AccessⓇ. Ce document peut être modifié à l’avenir car l’introduction et la dernière partie indique un code couleur à respecter afin de faciliter la compréhension du lecteur de ce document. Six pages extraites de ce document sont disponibles en annexe.
II - 1. D. Vers un nouveau système d’exploitation
Utilisateur quotidien de Linux, je me suis renseigné pour adapter l’application sur ce système. Je souhaitais ainsi obtenir des outils de développement plus pratiques sur celui-ci et anticiper l’utilisation de l'application sur un système d’exploitation gratuit – l’Inra possède des ordinateurs portables sous Linux. Après analyse de la structure et grâce à l’expérience acquise durant mes cours de programmation web côté serveur, cela m’a été simple de retrouver les structures de l’application, beaucoup de clones de programmes propriétaires existent sous Linux.
Tout d’abord, l’application étant basée sur un navigateur web, il suffisait de réinstaller un serveur HTTP sur la machine. On retrouve un logiciel semblable à WAMP adapté sous Linux appelé LAMP qui retrouve les outils nécessaires au fonctionnement de l’application : un serveur HTTP (Apache) et un langage serveur (PHP). Mais un problème persiste, la base de données étant structurée avec des fichiers sous Access®, aucun pilote de base n’existe pour lire correctement ces fichiers sous Linux. Et ne pas avoir de pilote, ne nous fournit aucune donnée issue de la base ce qui bloque beaucoup de fonctionnalités sur l’application.
Après plusieurs recherches sur le web, j’ai trouvé un outil permettant de lire des fichiers Access® nommé MDBTools et qui possède le pilote souhaité pour pouvoir lire ces fichiers. Très peu de documentation adaptée à ma situation m’indique comment le configurer et l’utiliser pour l’application. Cela n’étant pas une priorité dans les charges qui m’ont été fournies, j’ai abandonné mes recherches pour laisser, si possible, un développeur les poursuivre et arriver au but final : une application multiplate-forme. N’ayant aucune machine à disposition sous le système Mac OS, je ne me suis pas renseigné sur l’installation de l’application sur un de ces systèmes.
III - 2. Améliorations et ergonomie
L’objectif principal de mon stage est d’obtenir une application stable et répondant à leurs besoins, à partir des commentaires de la réunion faite avec les futurs utilisateurs de l’application. De plus, l’ergonomie de l’application doit être respectée notamment sur la tablette faite pour une utilisation sur le terrain. Dans la suite de cette partie, je vais décrire les améliorations majeures que j’ai développées et modifiées au cours de mon stage.
III - 2. A. La réunion
La réunion avec les futurs utilisateurs de l’application s’est organisée pendant la 2e semaine de mon stage. Cette réunion avait 3 objectifs principaux : (i) valider les informations déjà présentes dans l’application, (ii) repérer les défauts de l’application et (iii) donner des idées d’amélioration de l’application à l’avenir. Toutes les remarques ont été prises en compte et m’ont servi d’appui pour le développement de l’application pour la suite de mon stage.
Avec ma tutrice nous avons organisé cette réunion. Nous avons décidé ensemble de diviser la réunion en 3 parties sur une durée de 2 heures. D’abord, après l’accueil des personnes, une présentation de l’application a été faite. Ensuite ces personnes se sont rassemblées en plusieurs petits groupes de 3 maximum avec accessibilité à l’application en question pour la tester, soit sur tablette, soit sur ordinateur. Et enfin, la réunion s’est terminée par un compte rendu, permettant de relever les défauts majeurs de l’application et de prioriser les tâches nécessaires à la correction d’ergonomie ou d’ajout de fonctionnalité importante.
Durant la phase de test, j’ai suivi un groupe de 3 personnes afin de les aider à connaître les bases pour naviguer sur l’application. Nous avons ensemble échangé sur les points techniques, et j’ai pu développer mon vocabulaire autour du monde de la recherche agronomique. Quant à ma tutrice, connaissant mieux les personnes invitées à cette réunion, elle s’est chargée des 3 groupes restants. À nous deux, nous avons pu voir en direct les habitudes qu’essayait de prendre l’utilisateur sur l’application. C’est en regardant comment ils souhaitaient l’utiliser que nous avons pu corriger d’autres défauts de l’application.
Afin de servir d’appui à la relève de bogues ou d’idées d’amélioration de l’application, une feuille contenant un tableau avec les différentes fonctionnalités était fournie à chaque groupe. Ces feuilles nous ont servi à établir un compte rendu des défauts de l’application, par thèmes abordés dans l’application avec entre parenthèses les numéros des diapositives correspondantes lors de la présentation de l’application en première partie de réunion. Le tableau (Illustration 7) détaille ces éléments, en donnant un exemple de feuille saisie. On retrouve sur ce support chaque fonctionnalité de l’application, le nom et prénom du groupe pour pouvoir les contacter en cas d’incompréhension sur les commentaires apportés, une zone pour indiquer les modifications à apporter en face de la fonctionnalité désirée. Et enfin une indication sur une précision à apporter à chaque commentaire, déterminer si le commentaire est destiné au point de vue du PF (Point de Fertilité) ou de la parcelle. Les données issues de la base étant différentes dans ces deux cas, il était nécessaire de détailler ceci pour accéder à d’autres types d’affichage sur le mode PF ou parcelle de l’application.
Tous les groupes ont renseigné ces tableaux de manière très détaillé ce qui peut nous informer sur l’intérêt qu’il porte à cet outil.
Nom - Prénom : Indiquer si modifications à la parcelle ou au PF
Fonctionnalité (n° diapo) Commentaires apportés
Page d’accueil (5 – 13) Succession (14 – 15) Sols (16) Effluents (17) Semis (18) Adventices (19) Travail du sol (20) Récoltes (21)
Illustration 7 : Tableau de support d’aide aux relevés de défauts de l’application et exemple de feuille renseigné
III - 2. B. Logiciel de gestion de versions
Le projet a pris une grande ampleur sur son développement et aucun logiciel de gestion de versions n’était accessible pour l’application. Le premier stagiaire en avait utilisé un mais ne l’avait pas rendu public.
Pour éviter de reproduire cette erreur, j’ai proposé à ma tutrice de créer un dépôt git dont elle sera l’administratrice de celui-ci et les stagiaires continuant le développement de l’application sont ses contributeurs. Par choix, elle voulait utiliser un dépôt sous Bitbucket assurant le caractère privé de ce dépôt, c’est-à-dire empêcher à tout public de visionner et/ou de développer l’application.
Ne connaissant pas le concept de gestion de versions d’un projet informatique, j’ai formé ma tutrice sur les principes de base, et son utilité. Ce qui a renforcé son choix d’utiliser cet outil. De plus, après configuration de celui-ci, je lui ai appris les commandes de bases permettant de mettre à jour l’application sur sa machine et de mettre à jour les bases de données qu'elle aura elle-même mises à jour.
III - 2. C. La barre d’outils
Plusieurs détails ont dû être corrigés, principalement sur l’agencement des outils sur le menu détaillé de la parcelle. Le titre a été retiré pour laisser plus d’espace à la barre d’outils et les informations ont été réorganisées. Le schéma de l' Illustration 8, montre
l’évolution de l’application :
Illustration 8 : Schéma de l’évolution de la barre d’outil
Ici, nous pouvons voir que les informations concernant la parcelle sont situées vers le centre de la barre laissant ainsi aux extrémités, les fonctionnalités sur lesquelles l’utilisateur peut cliquer s’il le souhaite. La nouvelle disposition permet de mieux distinguer les boutons cliquables des boutons informels.
III - 2. D. Le plein écran
Le désavantage d’utiliser une application via un navigateur web est la perte d’espace d’affichage. Effectivement, l’interface du navigateur prend de la place, à cause des barres de navigation et de recherche, la liste des favoris, etc. Cette illisibilité est encore plus accentuée sur la tablette obligeant l’utilisateur à zoomer sur l’application. C’est pourquoi j’ai décidé d’ajouter une fonctionnalité plein écran, aidant à l’utilisation de l’application en particulier sur tablette.
III - 2. E. Menu détaillé de la parcelle
Plusieurs remarques pendant la réunion ont été faites sur le menu détaillé de la parcelle laissant penser que le menu manquait d’informations ou d’automatismes sur certains points. Il fallait donc rendre plus accessible et simple d’utilisation la navigation du menu. Dans un premier temps, à l’affichage du menu, pour accéder aux fonctionnalités situées à droite, il fallait tout d’abord choisir une culture en fonction de son année depuis le graphique des successions. Or l’application ne confirmait pas la sélection de l’utilisateur. J’ai donc décidé d’encadrer la culture choisie par un cadre bleu représentant un carré de sélection. Ceci laisse alors une vue de la dernière culture sélectionnée.
De plus, d’autres remarques ont été fournies sur l’affichage des interventions qui n'affichaient pas exactement les interventions à l’année de la culture sélectionnée. Ainsi j’ai créé une fonction qui permet de trier les interventions en fonction de l’année de culture choisie. J’ai opté pour un algorithme de tri fusion, qui par sa faible complexité permet en peu de temps, effectuer le tri.
III - 3. Nouvelles fonctionnalités
III - 3. A. Sélection de l’annéeL’application possède des données stockées des couches du parcellaire de l’Installation Expérimentale de 2004 jusqu’à aujourd’hui. Mais aucun moyen rapide ne permettait de changer la couche du parcellaire en fonction de l’année choisi depuis la carte. C’est pourquoi, ajouter cette première fonctionnalité était importante pour l’intérêt de cette application.
L’utilisateur peut, où qu’il soit dans l’application, changer d’année en cliquant sur la date affichée en haut à droite de l’application lui permettant d’afficher une fenêtre de sélection des années 2004 à aujourd’hui (Illustration 9).
En cliquant sur l’année, l’utilisateur verra le nouveau parcellaire chargé. S’il se trouve sur le menu détaillé de la parcelle, il sera redirigé vers la carte. Dans le cas contraire, s’il est déjà sur la carte, le chargement s'effectue sur le mode où est l’utilisateur actuellement. Par exemple, s’il est sur la couche des sols, l’utilisateur obtiendra la couche des sols sur l’année sélectionnée.
III - 3. B. Gestion de fond de carte en local
Sur tablette, le fond de carte posait problème car, étant utilisée sans connexion internet, le fond de carte ne se chargeait pas et on obtenait l’écran sur l’Illustration 10.
Illustration 10 : Affichage carte sans fond hors connexion
On remarque que l’utilisateur, sans fond de carte, a du mal à repérer les parcelles sur lesquelles il souhaite connaître les informations. C’est pourquoi développer un gestionnaire de fond de carte en local était l’une des priorités. L’idée était de pouvoir faire une API indépendante permettant d’aller chercher des tuiles stockées sur l’ordinateur. L’API intègre un système de mises à jour des tuiles des fonds de cartes. Cette dernière fonctionnalité n’est accessible que si l’utilisateur possède une connexion internet disponible.
Dans un premier temps j’ai dû structurer la fonctionnalité. À la racine du projet se trouve un dossier map encadrant tous les fichiers nécessaires à sa conception. Dans ce dossier on retrouvera principalement un dossier img contenant toutes les tuiles des fonds de cartes organisées par : nom de fond carte, niveau de zoom sur la carte (par défaut l’application à un zoom minimal de 14 et maximal de 18), coordonnées des abscisses sur la carte et par coordonnées des ordonnées. Le format de fichier des tuiles est en PNG. Si une carte est référencée, elle sera classée dans le dossier data. Par exemple, le fond de carte nommé Satellite, possède une tuile de zoom 14 d'abscisses 1455 et d’ordonnées 8656 sera positionné selon ce chemin de destination : /map/img/data/Satellite/14/1455/8656.png.
De plus, le dossier map possède un fichier PHP permettant de faire ces manipulations d’images et de fichiers, mais aussi des fichiers de configuration comprenant le nom des cartes et le serveur sur lequel aller le chercher. Toutes les routes de la fonctionnalité sont définies et répertoriées dans le fichier index.php.
Ce fichier interagit comme un petit serveur organisant et facilitant la gestion des tuiles à distribuer du fond de carte. On peut y retrouver les routes avec ses fonctions suivantes :
● Une route donnant le lien vers le fichier de la tuile correspondant aux paramètres de route donnés, retourne l’image par défaut not_found.png si les paramètres ne permettent pas de trouver la tuile correspondante. Le résultat des limites du fond de carte se trouve sur l'Illustration 11.
● Une route permettant d’ajouter un nouveau lien dans le fichier url_map.conf, retourne l’image par défaut updated.png indiquant que le lien a bien été enregistré.
● Une route permettant de télécharger les tuiles à partir des liens dans le fichier
base_url_map.conf, du type de carte téléchargé (nom de la carte dans le fichier
map_conf.json) et du zoom donnée. Les tuiles sont enregistrées dans le dossier data structuré de la même manière vue dans le titre précédent.
● Une autre route, répondant au même besoin que précédemment mais à partir des liens trouvés dans le fichier url_map.conf
● Une dernière route retournant un JSON contenant les caractéristiques des fichiers prêts à être téléchargés et l’état de la connexion de l’utilisateur (s’il est en ligne ou non).
Illustration 11 : Carte locale et ses limites
Afin que l’utilisateur puisse manipuler les fonds de cartes facilement, j’ai développé une interface (Illustration 12) lui permettant d’en choisir un. Par exemple, il peut opter entre une carte routière et des images satellites, mettre à jour une zone de fond de carte, télécharger les tuiles depuis le serveur distant stockant les fonds de cartes et enfin choisir entre utiliser les tuiles disponibles sur la machine de l’utilisateur ou alors depuis le serveur distant.
La dernière fonctionnalité possède, pour chacune des propositions, ses avantages et ses inconvénients : les chercher depuis la machine de l’utilisateur est rapide (à l’ordre de la milliseconde) et ne nécessite pas de connexion à internet tandis que les chercher depuis le serveur distant demande un peu plus de temps (à l’ordre de la demi-seconde) mais permet d’obtenir toutes les tuiles de fond de carte même en dehors de la zone délimitée du parcellaire.
Illustration 12 : Menu gestion des fonds de cartes
Ainsi, le développement de cette fonctionnalité a changé la structure et les interactions entre les divers programmes de l’application. L’état de l’application a changé par rapport au schéma représenté à l’ Illustration 4. L’Illustration 13 montre les nouvelles
Illustration 13 : Schéma des interactions entre chaque entité de l’application après le développement du gestionnaire de carte
III - 3. C. Climat
L’Unité de Recherche ASTER possède une station météo ayant pour but de relever, par exemple, les températures, l’humidité et les précipitations. Suite à la réunion programmée avec les techniciens, ces derniers ont eu l’idée d’intégrer ces relevés dans l’application.
Les données sur le climat sont réparties en trois catégories par saison et par année : ● Les températures : indiquent si la saison a eu des températures normales, plus
chaudes ou plus froides que des températures moyenne sur les 20 dernières années (1986-2015).
● Les précipitations : indiquent si la saison a eu des averses normales, excédentaires ou déficitaires par rapport à la moyenne sur 1986-2015.
● Les bilans hydriques : indiquent si la saison a eu des bilans hydriques normaux, excédentaires ou déficitaires par rapport à la moyenne sur 1986-2015.
Afin d’avoir un point de vue global, j’ai affiché les données de telle manière à ce qu’elle soit disponible n’importe où sur l’application. Afficher trois icônes dans la barre d’outils m’a semblé être une bonne idée. L’interface de la fonctionnalité ( Illustration 14) se présente de la manière suivante :
Les données du climat sont extraites de la base de données dans lequel on peut y retrouver, une légende un code couleur pour chaque attribut, le tout classé par saison, par année. À noter que l’hiver n’est pas représenté dans le jeu de données, car ces données sont issues d’un travail réalisé par un ingénieur sur le pâturage (les animaux ne pâturent pas en hiver). De plus, on peut remarquer que l’année où l’utilisateur se situe par rapport à l’application et mise en avant pour une lecture plus rapide des résultats.
III - 3. D. Couche effluent
Une autre remarque ayant été faite à la réunion concernait le manque de vision global sur le parcellaire des épandages des effluents. L’idée fut alors de reprendre les couches SIG du parcellaire de chaque année et d’indiquer dans la base de données le type d’effluent déposé sur chaque parcelle. Ainsi on arrive à obtenir l’affichage de l’ Illustration 15, ce qui permet maintenant d’avoir un point de vue global sur les effluents déposés sur le parcellaire à une année donnée.
Illustration 15 : Affichage de la couche effluent sur le parcellaire de 2018
Il faut savoir que les couleurs ont été extraites depuis la base de données, ce qui permet à tout moment de changer une couleur sur la parcelle s’il le faut depuis la base de données. De plus l’utilisateur peut cliquer à tout moment sur une parcelle colorée lui permettant d’accéder directement sur le menu effluent de la parcelle sélectionnée.
IV - Réunions et entretiens hebdomadaires
L’Unité ASTER accueille chaque année plusieurs stagiaires accomplissant plusieurs missions de recherche données. Durant ma période de stage plus de 9 autres stagiaires dont 2 autres stages informatiques étaient présents dans les bureaux.
Chaque semaine, principalement le vendredi, nous nous retrouvions ensemble entre stagiaires informaticiens avec nos tuteurs afin de faire une réunion ayant pour objet le compte rendu du travail effectué la semaine et du travail à effectuer pour la semaine suivante pour chacun d’entre nous. Cette réunion avait pour but aussi de donner des idées d’amélioration au projet de chacun. C’est ainsi que j’ai découvert et aidé à améliorer le projet de Florent COCHET qui avait pour objectif la mise en structure d’une base de données et d’une application web pour permettre des insertions de données provenant d’enquêtes agricoles via un questionnaire. Mais aussi le projet de Stéphane MAIRESSE qui consistait à continuer le développement d’un site web sur les captages d’eau du Grand Est.
Je trouve l’idée de se réunir chaque semaine intéressante. Il est vrai qu’à chaque réunion on devait synthétiser un travail accompli au bout d’une semaine, ceci nous exerçait à nous exprimer sans rentrer dans le détail trop technique de l’informatique (nos tuteurs n’étant pas des informaticiens d’origine). Cet exercice nous oblige à adapter notre vocabulaire jusqu’à la limite de la compréhension de l’interlocuteur. Ainsi, sur 10 semaines, nous nous sommes entraînés à adapter notre langage, exercice qui sera sûrement à renouveler dans notre vie professionnelle, afin de se faire comprendre par le client.
J’ai pu m’intéresser à d’autres outils, notamment à ceux de Florent qui avait pour restriction de programmer une base de données sous PostgreSQL afin de développer plus facilement une géodatabase. Quant aux outils utilisés par Stéphane, ceux-là m’étaient familiers (site web sous PHP) car je les utilisais déjà lors de mon stage ou pour certains projets effectués en cours.
Perspectives d’évolution
Le projet ayant été initié l’année dernière, plusieurs perspectives d’évolution ont déjà été énoncées. Certaines ont été résolues, d’autres restent encore en développement. Je parle principalement de deux fonctionnalités à développer dans le menu détaillé de la parcelle (Gestion des prairies et intercultures) qui n’ont pas pu l’être, dû aux incertitudes des techniciens sur la présentation et l’utilisation de la fonctionnalité.
Personnellement, je pense que d’autres fonctionnalités peuvent avoir leur utilité quant à l’utilisation de l’application. Je vois, par exemple, l’utilisation d’un balisage GPS depuis la tablette de terrain. Cette fonctionnalité permettrait de situer l’utilisateur à l’aide d’un repère sur la carte. Il peut également permettre de donner une indication sur le chemin à prendre pour aller vers une parcelle ou un point de fertilité.
De même, l’application est très complexe à installer. Par conséquent, je pense que trouver un moyen de déploiement d’application simple serait judicieux, afin de permettre à n’importe quel utilisateur avancé ou non, d’installer l’application. Par exemple, si un utilisateur non expérimenté cherche à installer l’application par l’appui d’un fichier exécutable, la non-nécessité de configurer WAMP, éviterait un risque d’abandon trop rapide de la part de l’utilisateur à cause de la difficulté d’installation.
Aussi, d’après une conversation avec ma tutrice, l’outil Docker permettrait de faciliter le déploiement de l’application sur plusieurs machines de systèmes d’exploitation différents. Il permettrait également de créer un environnement appelé container qui viendrait se greffer au système d’exploitation de l'utilisateur. Nous pourrions donc, pour cette application précisément, créer un environnement contenant un serveur LAMP et l’application préinstallée.
Finalement, l’application n’est disponible que sur une seule plateforme (Windows) dû à la manipulation de fichiers Access®, facilement configurés sur le système d’exploitation Windows. Des recherches ont été faites pour l’installation et la configuration de l’application sous un système de noyau Linux, mais n’ont pas abouti.
Un problème récurrent arrive souvent avec les fichiers Microsoft Access®, ces fichiers ont une limite de capacité empêchant les requêtes d’être exécutées correctement. De plus, les données recueillies par ces fichiers sont en grandes quantités et ne cesseront d’augmenter. Je pense par là qu’il faudrait trouver un moyen de convertir ces fichiers en fichier textes d’extension sql. Ces fichiers permettront de créer une base de données SQL plus facilement, repousseront la limitation de capacité des données et supprimeront la nécessité de l’utilisation d’un pilote permettant de lire des fichiers Access®. Si réussite de cette fonctionnalité il y a, il sera davantage facile de rendre l’application multiplate-forme.
Par ailleurs, un peu de travail d’optimisation serait à revoir dans le code, ainsi que l’optimisation de graphe à partir d’un jeu de données. Malheureusement, le temps m’a manqué pour la réalisation de ces derniers points.
Conclusion
L’objectif de mon stage était de continuer le développement d’une application web, permettant de visualiser des données issues de résultats d’analyse de chercheurs agronomes. L’objectif était également de rendre faciles d’accès et compréhensibles ces données, par l’appui de graphiques et de rendus visuels des données. Une réunion avec l’équipe ASTER a permis de mettre au point l’affichage des données à améliorer et les fonctionnalités prioritaires à programmer. L’aide d’Amandine DURPOIX m’a permis d’avancer sur le projet et d’acquérir les termes des données et du vocabulaire agronomique et enfin, d’en comprendre l’intérêt.
Cette expérience professionnelle m’a donné un avant-goût du monde du travail. D’un point de vue relationnel, elle m’a permis de m’exprimer devant un groupe de personnes inexpérimentées en informatique, certes, mais motivées dans l’utilisation de l’outil que je développais. Pour cela j’ai dû m'adapter à celles-ci es en adoptant un vocabulaire moins technique. De plus, ce stage m’a permis d'approfondir mes connaissances sur différents langages déjà vus en cours et me donner des notions sur la cartographie. En effet, ce stage m’a d’autant plus appris le fonctionnement du monde agricole notamment sur la recherche. Mon travail apporté pour ce projet m’a permis d’être embauché pour les 6 semaines qui suivent mon stage. Je continuerai, alors, le développement de l’application afin d’améliorer davantage ses fonctionnalités et, si possible, en ajouter.
Enfin, cette expérience, bien que très enrichissante, m’aura donné l’occasion de confirmer que mon projet professionnel en informatique se situait davantage vers une spécialisation scientifique que le développement Web, la sécurité informatique ou le développement de logiciels plus complexes me conviendraient.
Table des sigles
API Application Programming Interface
ASTER AgroSystème TErritoire Ressources
CSS Cascading Style Sheets
DUT Diplôme Universitaire Technologique
GPS Global Positioning System
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
INRA Institut National de Recherche Agronomique
IUT Institut Universitaire Technologique
JSON JavaScript Object Notation
LAMP Linux Apache MySQL PHP
PF Point de Fertilité
PHP PHP : Hypertext Preprocessor
PNG Portable Network Graphics
MVC Modèle-Vue-Contrôleur
MySQL My Structured Query Language
SIG Système d’Information Géographique
URL Uniform Resource Locator
Table des illustrations
Illustration 1 : Schéma représentant le projet de l’Installation Expérimentale de l’Unité de
Recherche ASTER 9
Illustration 2 : Chronogramme des tâches effectuées à la semaine durant ma période de stage
11
Illustration 3 : Système d’Information de l’Installation Expérimentale de l’Unité de
Recherche ASTER 12
Illustration 4 : Schéma des interactions entre chaque entité de l’application 15
Illustration 5 : Interface graphique de l’application à son démarrage 16
Illustration 6 : Interface du menu détaillé à la parcelle 17
Illustration 7 : Tableau de support d’aide aux relevés de défauts de l’application et exemple
de feuille renseigné 22
Illustration 8 : Schéma de l’évolution de la barre d’outil 23
Illustration 9 : Menu du choix de l’année 25
Illustration 10 : Affichage carte sans fond hors connexion 26
Illustration 11 : Carte locale et ses limites 28
Illustration 12 : Menu gestion des fonds de cartes 29
Illustration 13 : Schéma des interactions entre chaque entité de l’application après le
développement du gestionnaire de carte 30
Illustration 14 : Interface climat 31
Glossaire
Adventice : plante qui pousse spontanément dans une culture et dont la présence est plus ou moins nocive à celle-ci. A pour même terme que « mauvaises herbes » ou « herbes folles » dans le langage courant.
Bilan hydrique : résultat chiffré de la comparaison entre le total de précipitations tombées et de l’évaporation de l’eau du sol (appelé aussi évapotranspiration).
Librairie : ensemble de fonction programmé, regroupé et mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire.
Multiplate-forme : se dit d’un logiciel conçu pour fonctionner sur plusieurs systèmes
d’exploitation différents. Exemple : La suite Libre Office est multiplate-forme car elle est disponible sur les systèmes Windows, Linux et Mac OS.
Parcellaire : ensemble des parcelles de l’Installation Expérimentale.
Pilote : programme informatique destiné à communiquer avec un autre périphérique, fichier. Dans notre cas, le pilote a pour but d’interpréter les données issues des fichiers Access®.
Plugiciel : module complémentaire à un programme permettant d'interpréter un nouveau format de données, ici les données sont les couches SIG.
Point de fertilité : point central d’une zone de suivi de fertilité correspondant à un type de sol. Exemple : sol argileux.
Zone de suivi de fertilité : zone carrée de 30 mètres de côté. Cette zone appartient à une seule parcelle agricole.
Bibliographie
[Durpoix, 2018] Durpoix Amandine (Avril 2018). Le Système d’Information de l’Installation
Expérimentale (IE) : Des bases de données … à l’application sur tablette …, Poster
[Trommenschlager et al, 2018] Trommenschlager Jean-Marie, Gaujour Etienne, Emilie Fontana, Harmand Marc, Foissy Damien, Huguet Jean, Bazard Claude (2010). Gérer et organiser les données agricoles et de recherche d’un site expérimental, Cahier des
Techniques de l’Inra Bulletin de Liaison Interne.
![Illustration 3 : Système d’Information de l’Installation Expérimentale de l’Unité de Recherche ASTER [Durpoix, 2018]](https://thumb-eu.123doks.com/thumbv2/123doknet/12321464.325586/13.894.120.774.458.656/illustration-système-information-installation-expérimentale-unité-recherche-durpoix.webp)
