ProGeSer Sujet 11 : Réécriture du logiciel pour en faire une application web

Université des Sciences et Technologies de Lille ProGeSer Sujet 11 : Réécriture du logiciel pour en faire une application web Rapport de projet Master I soutenu le 9 juin 2011 par Titouan COMPIEGNE Sylvain THERY Encadrants : Auteur : Mr Laurent AMSELLEM Responsable informatique : Mme Patricia PLENACOSTE

i Remerciements Nous voulons remercier Mr Laurent AMSELLEM, de sa confiance pour l affectation du projet et de son suivi tout au long de cette expérience. Nous remercions également Mme Patricia PLENACOSTE, pour son suivi sur le projet et les conseils apportés en terme d ergonomie de l application web.

Résumé La première année du Master Informatique à l Université de Lille I, inclut au second semestre une matière nommée PJI (Projet Individuel). Il s agit de soumettre aux étudiants un projet important se déroulant sur l ensemble du semestre. Parmi la diversité des sujets, nous avons décidé de réaliser le projet de Monsieur Laurent AMSELLEM. Mr Laurent AMSELLEM, Maître de conférence en biologie et dynamique des invasions, a eu l idée en 2004, d implémenter un logiciel de gestion de l espace et du temps des serres de l Université de Lille 1. Le développement d un tel logiciel nommé ProGeSer a été effectué par des etudiants du M1 Informatique et d IUP Génie Mathématiques et Informatique (GMI) de l Université de Lille 1, entre 2004 et 2010. ProGeSer écrit en Java et XML est actuellement quasi-finalisé, mais malgré l application apportée à la conception de ce programme, ce dernier souffre d une erreur depuis son architecture même. Pour des raisons pratiques et d aisance d emploi, il a été décidé finalement de réécrire le logiciel sous la forme d une application web et accessible directement depuis un navigateur Internet par les utilisateurs. Nous avons accepté de réaliser ce projet sur une période de quatre mois entre janvier et mai 2011. Les différentes tâches à effectuer ont été de s approprier le logiciel existant afin de relever l ensemble des fonctionnalités que propose ProGeSer : réfléchir à la conception d une nouvelle base de données et réaliser cette dernière et enfin développer une nouvelle application web reposant sur cette base de données. Ce travail réalisé tout au long du semestre a été l occasion d être confrontés à un projet de taille conséquent nécessitant une bonne organisation. Il nous a permis également de découvrir de nouveaux outils, d améliorer nos connaissances apprises sur l ensemble de notre formation universitaire.

Table des matières Introduction 1 1 Le laboratoire GEPV et les serres de Lille I 2 1.1 Présentation du laboratoire GEPV............................... 2 1.2 Présentation des serres de l Université de Lille I........................ 2 1.3 Besoin logiciel........................................... 3 2 Présentation de l application actuelle 4 2.1 ProGeSer............................................. 4 2.1.1 Module demandeur.................................... 4 2.1.2 Module serriste...................................... 5 2.1.3 Etat actuel........................................ 7 3 Travail effectué 8 3.1 Mise en place........................................... 8 3.2 La base de données........................................ 9 3.3 Framework PHP : Symfony................................... 9 3.3.1 Qu est ce que Symfony?................................. 10 3.3.2 Pourquoi un framework, pourquoi Symfony?..................... 10 3.4 Développement.......................................... 12 3.4.1 Module demandeur.................................... 12 3.4.2 Module administration.................................. 20 3.4.3 Module serriste...................................... 24 3.4.4 Résumé.......................................... 34 4 Bilan de cette expérience 36 Conclusion 37 A Maquettes du module demandeur 38 B Modèle Conceptuel de Données (MCD) 46 C Modèle Logique de Données (MLD) 48 iii

Introduction La formation informatique de l Université de Lille I demande aux étudiants de réaliser un projet conséquent sur des sujets des laboratoires de recherches mais également des entreprises. Un sujet émanant de Mr Laurent AMSELLEM, enseignant-chercheur du laboratoire GEPV (Génétique et Evolution des Populations Végétales) de l Université de Lille I a retenu notre attention. L objectif principal de ce projet a été de réécrire un logiciel de gestion des serres, nommé ProGeSer, initialemment écrit en Java, sous forme d application web. Dans ce présent rapport, nous commencerons par une description du laboratoire GEPV, de l état et les fonctionnalités proposées actuellement par le logiciel ProGeSer. Nous détaillerons ensuite les différentes tâches que nous avons réalisées pendant ce projet et enfin réaliserons une conclusion sur les enseignements que nous a apportés cette expérience. 1

1 Le laboratoire GEPV et les serres de Lille I 1.1 Présentation du laboratoire GEPV L Université de Lille I comprend plusieurs UFR (Unités de Formation et de Recherche) dont l UFR de Biologie. Au sein de cette UFR, le laboratoire GEPV (Génétique et Evolution des Populations Végétales) installé dans le bâtiment SN2, réunit une quarantaine de personnes travaillant sur quatre thèmes de recherche à propos des populations végétales : Evolution des systèmes de reproduction, diversité génétique, et histoire évolutive de la section Beta ; Evolution de l auto incompatibilité ; Evolution des traits d histoire de vie et biologie de la conservation ; Génétique et évolution de l adaptation aux environnements pollués par les métaux lourds. Ce laboratoire a besoin de disposer de plantes particulières pour ses activités de recherches comme par exemple : Beta Vulgaris (Betterave), Arabidopsis Thaliana, Senecio Unequidens ou encore Biscutella Nuestriaca. Deux autres laboratoires ont également des besoins végétaux : l unité de glycobiologie structurale et fonctionnelle et le laboratoire stress abiotique et différenciation des végétaux cultivés. En plus des laboratoires, l enseignement est également consommateur de plantes pour la réalisation de travaux pratiques pour les étudiants de l UFR de biologie. 1.2 Présentation des serres de l Université de Lille I Les différents laboratoires végétalistes de l Universite de Lille I (Bâtiment SN2) nécessitent de travailler constamment avec du matériel frais pour leurs activités de recherche et d enseignement. Toutes les plantes sont donc cultivées selon les besoins dans des serres communes à chaques laboratoires situées près de ceuxci sur le site de l Université de Lille I (face au bâtiment SN1) et qui se chargent de fournir le matériel végétal aux différentes entités qui en ont besoin. 2

1.3. Besoin logiciel 3 Les différents espaces de culture sont utilisés par les équipes de recherche des laboratoires pour le maintien en collection du matériel végétal, la production des matériaux sur lesquels sont réalisées des analyses en aval et la réalisation d expérimentations sur les matériaux d étude. Le personnel chargé de la gestion technique et administratiive des serres ne représente que quatre personnes qui gèrent à elles seules l ensemble des serres comprenant : Une serre Hors-gel (maintenant la température au dessus de 5 C) de 200 m 2 ; Une serre maintenant la températue au dessus de 20 C en hiver de 4 * 72 m 2 ; Une serre norme S2 (confinement) de 2 * 35 m 2 ; Une serre de culture (contrôle température, hygrométrie, éclairement) de 2 * 30m 2 ; Une serre de 72 m 2 contenant le matériel d enseignement en biologie végétale ; Trois terrains extérieurs d expérimentation. Chaque serre citée ci-dessus est divisée en plusieurs pièces ou structures contenant des paillasses. 1.3 Besoin logiciel La gestion des serres nécessite d effectuer différentes tâches complexes à savoir la gestion des espaces de culture en fonction du temps, la gestion des programmes concernés, des stades attendus, de la destination du matériel, des impératifs de dates... Avec le temps et l évolution régulière de l agencement et l organisation des serres, le besoin d un logiciel de gestion de l espace et du temps s est fait de plus en plus pressant. Monsier Laurent AMSELLEM a donc imaginé en 2004 un logiciel informatique qui permettrait aux enseignants et chercheurs d effectuer des demandes de culture et de gérer facilement les cultures au sein de la serre par le personnel. Ainsi est né le logiciel ProGeSer dont on identifie deux modules : un module demandeur et un module serriste.

2 Présentation de l application actuelle 2.1 ProGeSer ProGeSer signifie Programme d aide à la Gestion des Serres. Le développement de ProGeSer a débuté en 2004 et depuis, sept groupes d étudiants en Master Informatique et GMI (Génie Mathématiques et Informatique) ont permis sa réalisation. Le programme a été réalisé en Java afin de le rendre multi plateforme afin qu il puisse s exécuter sur système Windows, Linux ou MacOs. Le logiciel est divisé en deux modules, le module demandeur et le module serriste dont voici une description des fonctionnalités qu il propose. 2.1.1 Module demandeur Le module demandeur permet à l utilisateur (généralement un enseignant-chercheur) de faire des demandes de culture que ce soit pour une expérimentation ou un enseignement. Les utilisateurs peuvent également enregistrer leurs demandes, les modifier, les supprimer et bien sûr les envoyer aux serristes via l interface suivante : 4

2.1. ProGeSer 5 Figure 2.1 Module demandeur - Menu Principal. 2.1.2 Module serriste Le module serriste s occupe quand à lui de recevoir les demandes de culture. Il permet de créer de nouvelles structures au sein des serres ainsi que les tables ou paillasses à l intérieur, mais aussi de créer une fiche de culture à partir d une demande reçue et de l affecter à une table libre. Le serriste peut également obtenir une vue d ensemble de la serre. Plusieurs vues sont disponibles : journalières, mensuelles ou encore la liste des tâches à effectuer dans la semaine en cours à travers les interfaces suivantes :

2.1. ProGeSer 6 Figure 2.2 Module serriste - Gestion structures. Figure 2.3 Module serriste - Fiche culture.

2.1. ProGeSer 7 Figure 2.4 Module serriste - Vue mensuelle. 2.1.3 Etat actuel Les modules demandeur et serriste peuvent être lancés via des installeurs. Lors de notre première visite avec Monsieur Laurent AMSELLEM, nous nous sommes aperçus que les installeurs ne fonctionnaient pas pour le module serriste. Il était donc impossible de voir les fonctionnalités que proposait ce module. Monsieur Laurent AMSELLEM nous a fait une démonstration du module demandeur et nous a montré des impressions d écrans pour le module serriste. Cependant, afin de nous apercevoir des différents mécanismes implémentés par le module serriste ainsi que ces enchainements d écrans, il a fallu dans un premier temps réparer l installeur du module serriste pour pouvoir l utiliser. Une fois cette étape réalisée, un deuxième rendez-vous a été pris avec Monsieur Laurent AMSELLEM pour nous faire une démonstration du module serriste et nous faire une visite des serres de l Université de Lille I. L installation du module serriste ayant réussi on a rapidement pu percevoir les problèmes que rencontre ProGeSer. En effet, il été impossible de finaliser une fiche de culture. Nous avons constaté par la suite que la réception des demandes était impossible avec notamment comme erreur des fiches au format invalide. La démonstration du module serriste n a donc pas pu se faire. Le contenu du sujet du projet a alors pris tout son sens. En effet, ProGeSer souffre d une erreur de conception depuis son architecture même. Notre mission est donc de repartir sur une nouvelle base solide. Pour des raisons pratiques et d aisance d emploi, il a été jugé finalement préférable que ce logiciel existe sous la forme d une application web. Ces différentes étapes vont être détaillées dans la suite de ce document.

3 Travail effectué 3.1 Mise en place Les premières étapes du projet consistaient à de s emparer du logiciel ProGeSer afin d analyser les fonctionnalités qu il proposait aux utilisateurs. Après quelques utilisations nous avons pu rapidement comprendre le fonctionnement du logiciel et commencer à noter les différentes fonctions qui seront à implementer dans l application web. Le projet étant conséquent nous devons donc avoir une bonne base de travail. Travaillant en binôme, nous devons décidé qui aller gérer telle ou telle fonctionnalité du logiciel. Afin de nous aider dans cette tâche, nous avons décidé d utiliser un serveur SVN. Le serveur SVN (fourni par le LIFL - Laboratoire d Informatique Fondamental de Lille) permet notamment de : garder un historique des différentes versions des fichiers d un projet ; permettre le retour à une version antérieure quelconque ; garder un historique des modifications avec leur nature, leur date, leur auteur... ; permettre un accès souple à ces fichiers, en local ou via un réseau ; permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les mêmes fichiers. Autant d avantages qui nous permettent de travailler sur des tâches distinctes sans se soucier de l avancement du binôme ou encore sans avoir à gérer soi même l intégration des modifications au projet. Nous avons pu débuter le projet avec notamment la réalisation des différentes maquettes du module demandeur disponibles dans les annexes de ce document. Le module demandeur étant correctement développé dans sa version Java, nous avons repris les écrans de l application afin de les adapter à la version internet. Ce travail terminé, la première grande étape du projet allait alors commencer, à savoir l écriture de la base de données. 8

3.2. La base de données 9 3.2 La base de données Au commencement du projet, deux bases de données existaient, une sous forme de base de données relationnelle et une autre sous forme de fichiers xml. Les étudiants de l année passée ont commencé à travailler sa réécriture. Ils ont notamment permis de réduire la base de données composée des fichiers xml. En effet ceux-ci permettaient de s occuper à la fois de la configuration du logiciel, mais également de la sauvegarde des fiches de demande faites depuis le module demandeur. Les étudiants de l année précédente ont réussi notamment à réécrire la base de données relationnelles afin d intégrer la configuration du logiciel. Cependant, les fiches de demande de culture étaient toujours sous la forme de fichiers xml. Afin d obtenir une base de données unique et solide et afin de se passer des fichiers xml, nous avons décidé de réécrire en partie la base de données proposée par les étudiants de la promotion précédente. La réécriture de cette base de données va notamment permettre de centraliser l ensemble des informations dans une base unique. Ce qui permettra de ne plus jongler entre deux bases de données différentes. La gestion des données en sera donc plus simple. ProGeSer passant d une utilisation mono-utilisateur, notamment pour le module demandeur, à une utilisation multi-utilisateurs due au fait que le logiciel sera accessible à présent depuis un site internet unique. Nous avons également ajouter des informations supplémentaires pour l utilisateur. ProGeSer nécessitant à présent d un compte utilisateur pour y accéder, nous avons rajouter des informations, comme l identifiant ou encore le mot de passe. La description de cette base de données est accessible via les Modèles Conceptuels de Données (MCD) et les Modèles Logique de Données (MLD) disponibles dans les annexes du document. Concernant son implémentation nous avons décidé d utiliser le système de gestion de base de données MySQL. Ce logiciel de gestion de base de données a pour avantage d être gratuit, simple d utilisation et suffisant pour la quantité de données demandées par ProGeSer. Le fait d intégrer les fiches de demandes précédemment sous forme de fichiers XML dans notre base de données, a été une étape assez longue demandant pas mal de réflexion. La base de données a du subir quelques modifications pendant le déroulement du projet afin de permettre le développement de l application web. Une fois la base de données réalisée, le développement de l application proprement parlé a pu débuter. 3.3 Framework PHP : Symfony L une des principales caractéristiques du projet étant de partir sur une base solide nous avons décidé d utiliser ce que l on appel un framework, ici le framework PHP : Symfony.

3.3. Framework PHP : Symfony 10 3.3.1 Qu est ce que Symfony? Symfony est un framework MVC libre écrit en PHP 5. En tant que framework il fournit un ensemble de composants logiciels structurels (généralement des classes PHP), qui servent à créer les fondations ainsi que les grandes lignes de tout ou partie d un logiciel (architecture). En programmation orientée objet, comme le développement de ProGeSer, un framework est typiquement composé de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le framework. La deuxième caractéristique de Symfony c est qu il repose sur une architecture dite en MVC (Modèle Vue Contrôleur). L architecture MVC qui permet notamment la séparation des responsabilités en trois parties distinctes, qui peuvent être indépendemment développées, testées et maintenues. On y retrouve notamment : Le modèle qui est responsable de la structure des données d une application en utilisant les informations prises à partir d une base de données ou d autres sources ; La vue qui représente ce qui est visible pour les utilisateurs, comme une page web. Le contrôleur qui lui fait le lien entre le modèle et la vue, en récupérant les choix d actions fait par l utilisateur à travers une page internet (une vue). A partir de cette action (qui peut être par exemple afficher mon profil) le contrôleur donne les instructions aux modèles et à la vue sur la façon de prendre des mesures, telles que l affichage de la vue appropriée (la page qui résume mon profil). Figure 3.1 Diagramme MVC. 3.3.2 Pourquoi un framework, pourquoi Symfony? Les différentes raisons qui nous ont fait choisir Symfony, ou tout simplement un framework ont été les suivantes :

3.3. Framework PHP : Symfony 11 Couche d abstraction de la base de données : un framework peut générer une couche d abstraction ou interface entre le code de notre application et les appels natifs réalisés vers le serveur de base de données, permettant de prendre en compte les caractéristiques des fournisseurs SQL. Ainsi nous pouvons modifier notre base de données SQL sans avoir à réécrire du code. Par exemple, passer de MySQL à PostgreSQL ou MSSQL. Authentification : la plupart des frameworks sont livrés avec un module d authentification utilisateur générique. Ils gèrent la connexion et déconnexion, l enregistrement, la gestion des sessions et des autorisations. Portabilité : l abstraction de la base de données permet à l application d être utilisée sur de nombreuses configurations de serveurs différents. Si l application est Open Source, un plus grand nombre de personnes seront en mesure de l installer. Sécurité des applications : Les fonctions de sécurité comme l authentification et les autorisations sont gérées par le framework. De plus, les insertions dans la base de données sont automatiquement nettoyées et la plupart des frameworks ont des protections contre les attaques de type Cross-Site Request Forgery. Règles de codage stricts : La plupart des frameworks forcent à suivre des principes de codage, notamment le modèle MVC : Modèle, Vue, Contrôleur. Cela donne une manière de penser sur la façon dont le code doit être structuré avant de l écrire, ce qui le rend de meilleur qualité. Réutilisabilité du code : Les frameworks sont (généralement) bien documentés et testés. Ainsi, si un autre développeur vient travailler sur le projet, ce dernier aura seulement besoin de lire la documentation du framework, pour comprendre le code. Si on avait développé ProGeSer sans framework, les développeurs aurait dû analyser l ensemble du code, le temps mis pour cette étude aurait pris beaucoup de temps. Nous avons étudié différents framework avant de choisir Symfony, mais nous avons décidé de choisir ce dernier pour les raisons suivantes : Certains framework étant vraiment typés pour certains usages, comme par exemple des blogs, des forums, etc..., Symfony avait pour avantage de laisser beaucoup de liberté à l utilisateur. Gestion des formulaires : ProGeSer nécessitant de nombreux formulaires, Symfony possède un système de gestion formulaire puissant avec entre autre un système de validation du formulaire et de sécurité important. Architecture MVC : assure un code structuré et donc une grande fiabilité du code. Symfony reprend l ensemble des caractéristiques citées dans la liste précédente, ce qui en fait un outil très puissant. Le choix d un framework a donc été indispensable pour permettre de développer une application, robuste, stable, sécurisée, performante. Autant de caractéristiques nécessaires au bon développement de ProGeSer. Le choix du framework décidé, le développement des différentes fonctionnalités ou modules a pu débuter.

3.4. Développement 12 3.4 Développement Ce fut la première fois que nous utilisions le framework Symfony. Il a fallu tout d abord, comprendre comment ce dernier était implémenté. Un tutorial bien détaillé sur le site de Symfony, nommé projet Jobeet était disponible. Nous avons donc travailler sur ce tutorial afin de commencer le développement de ProGeSer. Ce tutorial a été l occasion pour nous d installer tous les outils nécessaires au développement d une application web sous Symfony, à savoir : Installation et configuration d un serveur HTTP : en l occurence Apache ; Installation et configuration de PHP ; Installation d une base de données : en l occurence MySql ; Installation de Symfony avec notamment la mise en place de la relation entre Symfony et la base de données. Ils nous a également enseigné la compréhension des mécanismes développés par Symfony. Toutes ces étapes effectuées nous avons pu alors commencer le développement de ProGeSer en débutant par le module demandeur. 3.4.1 Module demandeur RAPPEL : Le module demandeur doit permettre à l utilisateur (généralement un enseignant-chercheur) de faire des demandes de culture que ce soit pour une expérimentation ou un enseignement, à travers des formulaires. Les utilisateurs peuvent également enregistrer leurs demandes, les modifier, les supprimer et les envoyer aux serristes. De plus l accès au logiciel nécessite à présent un compte utilisateur. Dès à présent l utilisateur accède à ProGeSer par l interface suivante :

3.4. Développement 13 Figure 3.2 ProGeSer - Page d authentification. Le formulaire d authentification vérifie entre autre : que les champs ont bien été saisis, si non les erreurs sont affichées à l utilisateur ; que l utilisateur possède un compte, si non les erreurs sont affichées à l utilisateur. Une fois l utilisateur authentifié, l utilisateur est redirigé soit vers le module demandeur, soit vers le module serriste, selon les droits qu il lui ont été attribués par l administrateur du site (voir module administration). L accueil du module demandeur est accessible via l interface suivante :

3.4. Développement 14 Figure 3.3 ProGeSer - Module demandeur - accueil. La page d accueil du module demandeur permet à l utilisateur d accéder aux fonctionnalités suivantes : Modifier ses informations personnelles ; Créer une nouvelle fiche de demande de culture ; Consulter, modifier, supprimer et envoyer les fiches en cours aux serristes. Voici le détail de ses différentes fonctionnalités. Profil L utilisateur à la possibilité de modifier ses informations personnelles en cliquant sur le lien Modifier mes informations, un formulaire est affiché à l utilisateur (voir ci-dessous) :

3.4. Développement 15 Le formulaire vérifie si : Figure 3.4 ProGeSer - Modification profil. Tous les champs sont saisis ; L email est correctement saisi ; Le numéro de téléphone est une chaîne de 10 caractères ; Les deux mots de passe sont identiques.

3.4. Développement 16 Création d une fiche de demande de culture La création d une fiche de demande de culture se fait en deux étapes. L utilisateur choisit le type de sa demande. Celle-ci peut porter soit sur une expérimentation, soit sur un enseignement. Ce choix se fait après avoir cliqué sur le lien Ajouter une fiche, via l interface suivante : Figure 3.5 ProGeSer - Module demandeur - Choix d une fiche de demande de culture. Une fois le choix du type de fiche effectué, l utilisateur accède à un formulaire pour y faire sa demande, voici un aperçu du formulaire : Figure 3.6 ProGeSer - Module demandeur - Formulaire fiche enseignement partie 1.

3.4. Développement 17 Figure 3.7 ProGeSer - Module demandeur - Formulaire fiche enseignement partie 2. Le formulaire vérifie si : Tous les champs sont saisis ; Les dates sont correctes, c est-à-dire, si elles ne sont pas antérieures à la date de demain ; La date de début est antérieure à la date de fin (fiche expérimentation) ; Le nombre d invididus est bien de type entier ; L email et le numéro de téléphone sont corrects pour le manipulateur (fiche expérimentation). Une fois la demande correctement saisie et validée, l utilisateur peut l enregistrer ou l envoyer directement aux serristes. Une fois cette étape terminée, l utilisateur est redirigé vers l accueil du module demandeur avec un message lui indiquant que l étape s est correctement déroulée. Figure 3.8 ProGeSer - Module demandeur - Message de notification - Création fiche. Gestion des fiches de demande de culture L utilisateur a également la possibilité de réaliser plusieurs actions concernant les fiches qu il a créées, à savoir : Les consulter ; Les modifier ;

3.4. Développement 18 Les supprimer ; Les envoyer. Toutes ces étapes sont accèssibles via le tableau de la page d accueil du module demandeur suivant : Figure 3.9 ProGeSer - Module demandeur - Gestion fiches. La consultation de la fiche se fait via la vue suivante : On peut observer que cette page internet fournit deux actions à l utilisateur : Accéder au formulaire de modification de la fiche correspondante ; Exporter la fiche au format PDF. L exportation du fiche expérimentation produit le document suivant :

3.4. Développement 19 Figure 3.10 ProGeSer - Module demandeur - Exportation PDF. Une fois le document généré celui-ci peut très bien être imprimé ou sauvergadé via le logiciel Adobe Reader. A noter également que le nombre de cultures dans la page d accueil du module demandeur est limité à 5 par pages. Un système de pagination a donc été mis en oeuvre afin de permettre à l utilisateur de naviguer à travers les différentes pages. Sécurisation du module Lors de l enregistrement d une demande de culture dans la base de données, celle-ci se voit attribuer un identifiant unique. Ainsi la première demande enregistrée aura l identifiant 1, la deuxième l identifiant 2, etc.... Il en est de même avec les utilisateurs, le premier utilisateur enregistré dans la base aura l identifiant 1 et ainsi de suite.

3.4. Développement 20 Pour pouvoir accéder à une information d une demande ou pour accéder à un profil ; il faut renseigner l identifiant correspondant dans l adresse URL du site internet. Par exemple pour accéder au profil de l utilisateur 1 il faudra saisir l adresse suivante : http ://www.mon-site-internet/profil/1/voir-informations Le problème avec l identifiant visible dans une URL c est que l on peut facilement deviner l adresse d un autre profil. Par exemple, si un deuxième utilisateur est enregistré sur le site internet, on peut y accéder en saisissant l adresse suivante : http ://www.mon-site-internet/profil/2/voir-informations Un autre utilisateur peux alors accéder à tous les utilisateurs du site internet, pas uniquement en lecture mais il peut également modifier les informations d un utilisateur et également modifier son mot de passe ce qui pose bien évidemment des problèmes majeurs de sécurité. Nous avons donc mis en place une protection avec un jeton (encore appelé token). Les identifiants ne sont plus affichés dans l adresse URL, mais seulement le jeton. Les adresses sont à présent visibles de cette façon-ci : http ://www.mon-site-internet/profil/jeton/voir-informations Où JETON est une suite de 40 caractères hexadécimaux (160 bits), ce qui ne permet plus de deviner l adresse d un autre profil. A la création du module demandeur ce dernier était accessible à tous. Un système d authentification des utilisateurs a dû être mis en place. Cela a été fait en modifiant le système d authentification fourni par Symfony. Une fois ce dernier créé, il a fallu développer un outil permettant aux responsables de l application web (les serristes) de gérer ces utilisateurs. Cela a été réalisé dans le module administration. 3.4.2 Module administration On distingue trois types d utilisateurs : Le demandeur : qui fait les demandes de culture et qui a accès exclusivement au module demandeur ; Le serriste : qui a les mêmes droits que le demandeur mais avec le droit d accès aux modules serriste et administration ; Un super admin : qui lui a tous les droits. Le module administration est donc exclusivement réservé aux serristes et au super admin via l interface suivante :

3.4. Développement 21 Figure 3.11 ProGeSer - Module administation - Authentification. Le formulaire vérifie que : Les choix soient remplis ; L utilisateur possède un compte. Le formulaire vérifie également que l utilisateur a les bons privilèges, ainsi si un demandeur essaye de se connecter au module administration il sera redirigé vers cette page ci :

3.4. Développement 22 Figure 3.12 ProGeSer - Module administation - Permissions requises. et sera redirigé à la page précédente. Une fois le bon utilisateur connecté celui-ci se retrouve sur la page suivante : Figure 3.13 ProGeSer - Module administation - Accueil.

3.4. Développement 23 Le module administration permet à l utilisateur (serriste ou super admin) de réaliser les actions suivantes : Créer, modifier, supprimer un utilisateur ; Affecter des droits à l utilisateur (demandeur ou serriste) ; Lister l ensemble des utilisateurs ; Filtrer la liste des utilisateurs par nom, prénom, identifiant. La création et la modification d un utilisateur se font par le biais du formulaire suivant : Figure 3.14 ProGeSer - Module administation - Création/Modification utilisateur - partie 1. Première partie du formulaire qui permet notamment d affecter les autorisations (demandeur ou serriste) à l utilisateur. Figure 3.15 ProGeSer - Module administation - Création/Modification utilisateur - partie 2. Le formulaire vérifie l ensemble des éléments suivants : Tous les champs sont saisis ; L email est valide ainsi que le numéro de téléphone ; Les deux mots de passe sont identiques ; Il n existe pas le même identifiant ou la même adresse email dans la base de données.

3.4. Développement 24 Si des erreurs sont présentes, elles sont affichées de la manière suivante à l utilisateur : Figure 3.16 ProGeSer - Module administation - Création/Modification utilisateur - erreurs. Une fois les différentes tâches effectuées par l utilisateur celui-ci à la possibilité de se déconnecter pour être redirigé à la page d authentification du module administration. 3.4.3 Module serriste RAPPEL : Le module serriste doit permettre à l utilisateur (le serriste) de recevoir les demandes de culture. Il permet de créer de nouvelles structures au sein des serres ainsi que les tables ou paillasses à l intérieur. Il permet aussi de créer une fiche de culture à partir d une demande reçue et de l affecter à une table libre. Le serriste peut également obtenir une vue d ensemble de la serre. Plusieurs vues sont disponibles : journalières, mensuelles, ou encore la liste des tâches à effectuer dans la semaine en cours. Le développement des deux précédents modules a pris un certain temps et nous a amenés vers la fin du projet logiciel. Bien que la base de données soit déjà implémentée afin de recevoir les données nécessaires au bon fonctionnement du module serriste, le développement de ce dernier restait à faire. Le module serriste ayant été source de bogues dans la précédente version de ProGeSer, il nous était impossibles de procéder à son développement tête baissée sans aucune étape de réflexion et de conception au préalable. Nous avons donc effectué l écriture des premières maquettes afin de visualer comment nous allons imbriquer les différentes fonctionnalités du module, voici leur représentation :

Accueil serriste - tâches à effectuer

Onglet gestion des serres

Formulaire de création/modification des serres

Onglet gestion des cellules

Formulaire de création/modification des cellules

Onglet gestion des cultures

Définition des étapes de culture

3.4. Développement 32 Comme on peut le voir sur les maquettes ci-dessus, la navigation entre les différentes possibilités du module serriste se ferait par onglet. La page d accueil du module serriste correspondrait à la liste des tâches à effectuer, par les serristes pendant la semaine courante. Un clic sur chaque tâches permettrait d accéder à l ensemble des informations de la culture concernée. La deuxième fonctionnalité correspondrait à la gestion des serres, à savoir : lister l ensemble des serres créées ; création d une serre ; modification d une serre ; suppression d une serre. Sur la maquette Onglet gestion des serres on peut observer un tableau listant l ensemble des serres créées. L utilisateur a alors la possibilité de modifier ou supprimer une serre en cliquant sur l icône correspondante. La création d une nouvelle serre se fait en cliquant sur le lien Ajouter une serre. Un formulaire apparait alors regroupant les informations suivantes : Nom de la serre ; Localisation ; Ville ; Code postal ; permettant à l utilisateur de créer une nouvelle serre. A noter que le formulaire pour la modification d une serre est le même mais avec les champs déjà pré-remplis. La troisième fonctionnalité correspondrait à la gestion des cellules, à savoir : lister l ensemble des cellules créées ; création d une cellule ; modification d une cellule ; suppression d une cellule. Contrairement à la maquette Onglet gestion des serres, la maquette Onglet gestion des cellules montre le formulaire de création/modification d une structure qui regroupe les informations suivantes : La serre où seront créées les cellules ; Le nom de la cellule ; La cellule est-elle OGM ou non? ; La liste des tablettes présentes dans la cellule.

3.4. Développement 33 A noter que, comme dans la gestion des serres, un tableau est présent dans la gestion des cellules permettant de consulter, modifier et supprimer une cellule, comme on peut le faire notamment sur la page d accueil du module demandeur avec les cultures. La quatrième fonctionnalité concerne la gestion des cultures. Dans cette partie il s agit de récupérer les demandes faites par les demandeurs. Une fois les fiches récupérées il s agit de les compléter en associant les différentes étapes de la culture concernée par la fiche à travers une interface semblable à celle de la première version de ProGeSer. Figure 3.17 ProGeser - module serriste - gestion cultures - ajout étapes. Les deux derniers onglets, concernent la vue des tâches à effectuer sous forme journalière et sous forme mensuelle. Ces vues sont sous la forme de calendrier. Pour cette partie nous avons fait diverses recherches sur internet afin de savoir ce que PHP ou Javascript propose aux développeurs afin d utiliser des calendriers. Nous avons trouvé wdcalendar qui est un plugin jquery vous permettant de créer rapidement un calendrier riche et interactif pour les applications web. jquery étant une bibliothèque JavaScript libre qui porte sur l interaction entre JavaScript et HTML, et a pour but de simplifier des commandes communes de JavaScript. Nous avons découvert aussi sfcalendarppplugin permettant d ajouter facilement wdcalendar à Symfony.

3.4. Développement 34 Figure 3.18 Aperçu wdcalendar. wdcalendar possède une interface proche de celle de Google Agenda, qui propose notamment différents zoom disponibles : Vue du jour, de la semaine ou du mois. Il permet aussi d associer des couleurs aux différents évènements, évènement correspondant aux taches à effectuer pour ProGeSer. Il reste cependant un gros travail d étude de cet outil pour pouvoir l intégrer à ProGeSer et lier les données présentes dans la base de données au calendrier. Le manque de temps ne nous a malheureusement pas permis de pouvoir développer le module serriste, cependant nous avons mis tout en oeuvre pour permettre aux futurs développeurs de pouvoir continuer le travail. La base de données est déjà implémentée pour accueillir les données nécessaires au bon fonctionnement du module. Nous avons également créé les différentes maquettes du module, recherché des outils pour la manipulation de calendriers ou encore rédigé un fichier README en indiquant les différentes étapes à réaliser pour poursuivre le développement de ProGeSer. 3.4.4 Résumé Voici un rappel de tout ce qui a été développé pendant le projet logiciel (PJI) : Réécriture de la base de données, permettant de supprimer les fichiers XML et d obtenir une base unique ;

3.4. Développement 35 Mise en place du framework Symfony ; Implémentation d un système d authentification des utilisateurs ; Gestion des utilisateurs avec le module administration ; Création du module demandeur qui permet notamment à l utilisateur de créer, consulter, modifier, supprimer, exporter au format PDF et envoyer les demandes de culture aux serristes et modifier ses informations personnelles de façon sécurisée ; Réflexion et conception concernant le module serriste avec notamment la création de maquettes.

4 Bilan de cette expérience Le premier bilan que l on peut constater est que le développement d un outil informatique conséquent n est jamais simple. Malgré plusieurs générations d étudiants et un développement en Java achevé, ProGeSer n a pas pu apporter une entière satisfaction aux utilisateurs avec notamment la présence de bogues récalcitrants. Une bonne phase de conception est indispensable avant tout développement d une application afin d envisager les problèmes à venir et les résoudrent au mieux. De plus, le fait de commenter son code, de fournir une documentation, s avère très utile notamment dans la reprise d un projet en cours de développement. Il était donc pour nous indispensable de développer la nouvelle version de ProGeSer sur une base solide, avec notamment la mise en place du framework Symfony ainsi que la réécriture de la base de données. Concernant le développement de ProGeSer, ce fut pour nous le premier projet Web que nous réalisons. C est également la première fois que nous travaillons dans le langage PHP notamment sa version objet. Cependant développant depuis nos débuts universitaire dans le langage Java, l adaptation au langage PHP s est faite rapidement. Certaines parties de l application nécessitant quant à elles des langages orientés internet comme le Javascript ont demandé plus de temps d adaptation. L utilisation du framework Symfony était aussi une première, une longue période d adaptation a été nécessaire afin de maîtriser cet outil, bien que de nombreuses fonctionnalités restent encore à découvrir. Un outil indispensable pour la mise en place de ProGeSer. Au final un bilan enrichissant avec notamment l apprentissage de nouveaux outils et concepts. 36

Conclusion La réécriture de ProGeSer a été l occasion de mettre en place une application web avec notamment l utilisation d un framework qui fut une première pour nous. Nous sommes satisfait d avoir fondé les bases de l application web, avec notamment la réécriture de la base de données et la mise en place de Symfony, le développement des modules demandeur et administration et le travail débuté pour le module serriste. Cependant nous regrettons de ne pas avoir eu le temps de terminer le module serriste de ProGe- Ser, mais espérons avoir fourni une base de travail solide aux prochains développeurs pour faciliter la terminaison du développement de l outil informatique. 37

A Maquettes du module demandeur 38

Login page d'authentification

Backend serriste Le super-utilisateur et les serristes peuvent ajouter d'autres serristes

Liste des fiches

Selection du type de fiche

Formulaire de création/modification d'une demande d'enseignement

Formulaire de création/modification d'une demande d'experimentation

Aperçu d'une fiche

B Modèle Conceptuel de Données (MCD) 46

47

C Modèle Logique de Données (MLD) 48

49