Développement web sous Symfony

(1)

HAL Id: hal-02798868

https://hal.inrae.fr/hal-02798868

Submitted on 5 Jun 2020

HAL 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 web sous Symfony

Nicolas Rudent

To cite this version:

Nicolas Rudent. Développement web sous Symfony. [Stage] France. Université Toulouse III - Paul Sabatier (UPS), FRA. 2015, 48 p. �hal-02798868�

(2)

Juin 2015 Nicolas RUDENT

Rapport de stage de 2nde_{année du 07/04/2015 au 19/06/2015}

Développement web sous Symfony

Maître de stage : Florent Blaise Tuteur universitaire : Max Chevalier

(3)

(4)

Juin 2015 Nicolas RUDENT

Rapport de stage de 2nde_{année du 07/04/2015 au 19/06/2015}

Développement web sous Symfony

Maître de stage : Florent Blaise Tuteur universitaire : Max Chevalier

(5)

Remerciements

Je tiens à remercier toutes les personnes qui ont contribué au succès de mon stage et qui m'ont aidé lors de la rédaction de ce rapport.

Tout d’abord, je remercie tout particulièrement Florent Blaise, mon maître de stage, pour m’avoir aidé lors de mon développement en se rendant disponible dès que j’avais un

problème.

Ensuite, je souhaite remercier Max Chevalier, mon tuteur universitaire, pour ses conseils pour la rédaction de ce rapport.

Aussi, je remercie Valérie Calvo et Laurent Burnel qui, avec mon maître de stage, m’ont encadré tout au long de ses 11 semaines. Je leur suis reconnaissant d’avoir pris le temps de

répondre à mes questions à n’importe quel moment, notamment pour nos réunions hebdomadaires.

Je remercie Marc Deconchat, Michel Goulard, Sylvie Ladet et encore Valérie Calvo qui ont pris le temps de tester mon outil et de me faire des remarques dessus afin de l’améliorer.

Plus généralement, je remercie l’ensemble de DYNAFOR pour leur accueil et leur générosité qui m’ont fait m’intéresser à des domaines que je ne connaissais pas du tout.

Enfin, je remercie Céline Ottogali, Julien Bataillé et Mélanie Mermet, collègues stagiaires, pour la bonne humeur toujours présente dans le bureau et leurs précieux conseils

(6)

Table des matières

Introduction ... 6

I - Présentation de l’INRA ... 7

A – Au niveau national ... 7

B - Le centre INRA de Toulouse Midi-Pyrénées ... 8

C – DYNAFOR (Dynamiques et écologie des paysages

agriforestiers) ... 9

II - Mission du stage : Développement d’un outil web de

recrutement ... 10

A – Buts et enjeux du stage ... 10

1. Détermination du besoin ... 10

2. Analyse de l’existant ... 10

B – Réalisation de l’outil ... 11

1. En amont : audit et modélisation ... 11

2. Points-clés de la construction ... 13

3. Problèmes rencontrés ... 17

III - Bilan sur la création ... 20

(7)

6

Nicolas RUDENT/Développement web sous Symfony/INRA

Introduction

Dans le cadre de mon enseignement en IUT informatique, un stage conventionné doit être réalisé par chaque étudiant de seconde année afin de mettre en application les compétences acquises durant sa formation.

C’est pourquoi, du 7 avril au 19 juin, j’ai effectué un stage au sein de l’INRA1_{(l’Institut}

National de Recherche Agronomique située à Auzeville-Tolosane). Au cours de ce stage j’étais dans l’unité DYNAFOR (Dynamiques et écologie des paysages agriforestiers).

Lors de mon arrivée, j’ai intégré une équipe constituée de mon maître de stage Florent Blaise, la gestionnaire d’unité Valérie Calvo et un représentant qualité Laurent Burnel qui m’ont rapidement expliqué ma mission. Actuellement, DYNAFOR a recours fréquemment et de plus en plus à des employés à durée temporaire (divers types de contrats : stage, CDD…). Hors, l’unité a une volonté de traitement égalitaire de ces personnes et veut faciliter leur intégration en harmonisant les pratiques administratives afin de faciliter le travail du secrétariat. Cette volonté vient d’une action d’organisation de l’accueil demandée par la référentielle qualité (la qualité étant l’ensemble des techniques pour évaluer le bon fonctionnement d’une entreprise).

Ma mission consiste donc à créer un outil web permettant de gérer ces nouveaux arrivants afin de régulariser la situation. Pour m’aider, Julien Bataillé, stagiaire qualité, fixera avec moi des indicateurs de qualité dans mon application.

Afin de vous montrer le déroulement de ce stage, je vais tout d’abord vous présenter l’INRA puis vous montrer les différentes étapes du développement de mon outil et enfin dresser un bilan sur le travail réalisé.

(8)

7

Présentation de l’INRA

A – Au niveau national

L’INRA (l’Institut National de Recherche Agronomique) a été fondé en 1946 dans le but de « nourrir la France ». Aujourd’hui, ses recherches se concentrent sur 3 domaines : l’alimentation, l’agriculture et l’environnement. L’objectif premier est de développer une agriculture à la fois compétitive, respectueuse de l’environnement et des ressources naturelles et mieux adaptée aux besoins nutritionnels de l’homme.

En 2013, il y avait 17 centres de recherches régionaux et un centre siège, près de 8 500 agents titulaires, 13 départements scientifiques et 6 grands programmes transversaux de recherche avec un budget prévisionnel de 881,61 millions d’euros.

L’informatique à l’INRA est divisée en 3 domaines :

 Informatique scientifique : informaticiens proches des thématiques scientifiques des laboratoires de recherche (bio informaticiens, développeurs, administrateur de SI scientifiques, etc.)

 Informatique d’appui : environ 150 personnes gérant les infrastructures collectives (réseau, salles machines, etc.) et les applications nationales (RH, Finance, Outils collaboratifs, sites Web, etc.)

 Informatique de proximité : environ 130 personnes gérant les postes de travail, les logiciels, les imprimantes, etc.

Le Comité Directeur des Systèmes d’Information (CDSI) pilote l’ensemble des domaines informatique de l’institut.

(9)

8

B - Le centre INRA de Toulouse Midi-Pyrénées

Ce centre comporte 1 400 chercheurs, ingénieurs et techniciens INRA dont 630 titulaires ce qui lui permet de représenter 10% des publications de l’INRA et 12% de ses brevets.

C’est un lieu d’activités scientifiques pluridisciplinaires témoin d’un fort partenariat (400 agents d’établissements partenaires présents dans les 13 unités mixtes de recherche). De plus, il y a énormément de collaboration avec des établissements comme le CNRS et aussi des associations avec les universités toulousaines (UT1 Capitole, UT3 Paul Sabatier), des écoles d’ingénieurs (INP-ENSAT, INP-EI Purpan, INP-ENSIACET) et l’école vétérinaire (ENVT).

Ce centre privilégie des activités de recherche et d’innovation en réponse à trois grands enjeux :

- Des systèmes de production agricoles (végétaux, animaux) et forestiers plus durables et adaptés au changement climatique

- Une alimentation attentive aux questions de santé

- De nouvelles filières de transformation des agro-ressources en faveur d’une valorisation du carbone renouvelable

(10)

9

C – DYNAFOR (Dynamiques et écologie des paysages agriforestiers)

DYNAFOR est une unité mixte de recherche (UMR) qui associe depuis 2003 (sa création) des chercheurs de 2 départements de l'INRA et des enseignants chercheurs de l'ENSAT (Ecole Nationale d'Agronomie de Toulouse) qui fait partie de l'INP (Institut National Polytechnique) de Toulouse.

Depuis 2011, 8 personnes de l'EIPurpan (Ecole d'ingénieur de Purpan) ont rejoint DYNAFOR, à l'occasion de l'intégration de l'EIPurpan dans l'INP.

Les objectifs de cette unité sont d’apporter de la connaissance autour d’un thème central qui est l’écologie des paysages. Les recherches de DYNAFOR sont pluridisciplinaires : elles contribuent à résoudre les problèmes des milieux ruraux, notamment ceux qui concernent la biodiversité qui est un enjeu majeur. Il s'agit aussi de contribuer au développement de l'ingénierie écologique des territoires ruraux comme moyen d'en assurer leur pérennité et leur capacité à fournir les produits et services attendus par la société. De ce fait, les recherches se concentrent sur la biodiversité des espaces ruraux et à sa préservation, sur la dynamique de l’ensemble des activités agricoles et forestières sur un territoire afin d’étudier leurs conséquences écologiques sur différents types de ressources.

Pour cela, DYNAFOR est concentrée sur 3 axes et appuyée par des équipes supports (voir annexe 16). Au niveau de l’équipe d’appui en informatique (ou groupe méthodologique InfoGéom), cette unité dispose de :

 Richard Auriol : gestionnaire de parc informatique

 Florent Blaise : gestionnaire de base de données, mon maître de stage

 François Calatayud : administrateur de systèmes d’information

 Sylvie Ladet : administratrice de systèmes d’information chargée de coordonner le groupe InfoGéom

 Wilfried Heintz : administrateur de systèmes d’information

 Valéry Rasplus : développeur d’applications

De plus, pour aider les chercheurs et les agents de terrain, DYNAFOR se doit d’employer du personnel non temporaire, ce qui nous emmène à expliquer les raisons de mon stage…

(11)

10

Mission du stage :

Développement d’un outil

web de recrutement

A – Buts et enjeux du stage

1. Détermination du besoin

L’UMR DYNAFOR recrute des personnels non titulaires (PNT) tout au long de l’année pour répondre à divers besoins. Hors, cette unité étant composée de trois institutions ayant des statuts différents sur plusieurs implantations, les recrutements entraînent des complications. En effet, le processus de recrutement variant selon les institutions et ce dernier n’étant pas connu de tous, le processus est mal maîtrisé ce qui entraîne des aléas avec parfois des retards pour l’arrivée de ces nouvelles recrues. Ces retards et problèmes administratifs bloquent les projets et nuisent à la productivité de l’unité. C’est pourquoi un outil de recrutement est nécessaire pour fluidifier la procédure et assurer un suivi plus poussé des recrutements.

2. Analyse de l’existant

Ce problème étant connu depuis longtemps, quelques mesures ont déjà été mises en œuvre avant mon arrivée. En effet, pendant deux ans, DYNAFOR a utilisé l’outil « Recruit »2_.

C’est un outil puissant permettant la gestion des recrutements avec de nombreuses fonctionnalités complexes. Hors, celui-ci a été abandonné à cause de sa complexité car le personnel de l’unité ne l’utilisait que pour proposer des profils de recrutement et Recruit proposait des fonctionnalités supplémentaires qui perdaient les utilisateurs. De plus, sa prise en main n’était pas évidente et requérait une formation. Enfin, au lieu de fluidifier la procédure de recrutement, il l’alourdissait et coupait le contact humain qui est une grande composante de l’esprit de DYNAFOR.

C’est pour pallier à ces problèmes et à ce cadre que mon stage a été proposé lors du CUMR (Conseil de l’Unité Mixte de Recherche, réunion ayant lieu tous les mois). J’ai dû donc garder en tête pendant tout le développement que mon application devait rester le plus simple possible et devenir un appui au personnel, et non une tâche pénible à réaliser sur un énième outil en ligne.

2_{https://www.zoho.com/recruit/}

(12)

11

B – Réalisation de l’outil

Dans cette partie, je vais vous expliquer ma démarche de développement jusqu’au résultat obtenu en montrant les principales étapes et difficultés rencontrées lors de la création de l’outil.

1. En amont : audit et modélisation

Dans un premier temps, mon tuteur de stage Florent Blaise, un représentant qualité Laurent Burnel et son stagiaire Julien Bataillé, la gestionnaire d’unité Valérie Calvo et moi-même avons fait une réunion afin de préciser les attentes de mon stage. Ils m’ont rappelé le contexte, les besoins et le but de mon stage afin de fixer les bases du projet. Ils m’ont bien précisé que mon outil doit permettre d’alléger la tâche des gestionnaires d’unité et d’harmoniser le système actuel tout en laissant un contrôle total aux gestionnaires. Cette application sera une première dans DYNAFOR puisque jusqu’à présent, aucun outil commun avec l’ENSAT, l’EIPurpan et le site d’Auzeville n’avait été créé.

Pour m’aider dans la compréhension du système de recrutement, mes encadrants m’ont remis une ébauche d’un diagramme de séquence réalisé par leurs soins afin de me montrer le processus de recrutement et le rôle de mon application dans cette démarche. De plus, nous nous sommes fixés un rythme de réunion hebdomadaire afin de suivre au mieux mes avancés et permettre de faire un bilan régulier de l’avancée du projet, celle-ci me permettant également d’aborder les difficultés ou questionnements rencontrés lors du développement et de proposer des solutions.

Partant de là, je me suis tout d’abord penché sur la méthode de développement à appliquer et les outils nécessaires à sa réalisation. M’étant renseigné auparavant et avec l’avis positif de mon tuteur, j’ai décidé de travailler à partir du framework PHP Symfony. Cet outil permet de faciliter et d’accélérer le développement d'un site web en fournissant des fonctionnalités modulables et adaptables. De plus, il permet une sécurisation des données, notamment lors de l’authentification ou lors de la validation de formulaire (par exemple, il peut contrer les injonctions SQL). Ne le connaissant pas du tout, j’ai consacré ma première semaine à me documenter notamment via le manuel de référence3_{afin de découvrir son}

fonctionnement afin d’avoir un avis objectif et précis sur ce que permettait ce framework par rapport à nos besoins pour l’application à développer (voir annexe 1).

Une fois l’outil approprié, j’ai travaillé sur le diagramme de séquence donné au début de mon stage (voir annexe 4) afin de le remodeler. En effet, cette ébauche de diagramme avait surtout été réalisée par Laurent Burnel et Valérie Calvo qui n’avaient jamais suivi de formation portant sur l’UML (Unified Modeling Language), il comportait donc quelques incohérences. C’est pourquoi, j’ai revu ce diagramme en le découpant en plusieurs processus (voir annexes

(13)

12

5, 6, 7, 8, 9) afin qu’il soit plus clair et plus compréhensible. Cette phase m’a permis de bien comprendre l’organisation et la structuration de l’unité et notamment de mieux appréhender le processus de recrutement.

Après la validation de la refonte du diagramme lors d’une des réunions hebdomadaire, nous avons spécifié plus précisément avec Valérie Calvo et Julien Bataillé les champs nécessaires pour chaque formulaire de mon outil afin que je puisse modéliser la base de données en annexe 17.

Une fois toutes ces informations récoltées, j’ai pu commencer à développer l’outil de recrutement

.

(14)

13

2. Points-clés de la construction



La gestion des rôles

Tout d’abord, afin de bien développer sous Symfony, il faut se renseigner sur les « bundles ». Ceux-ci sont des bibliothèques permettant d’intégrer de nouvelles fonctionnalités avec lesquelles il est important de se familiariser afin de gagner du temps de développement et de permettre une meilleure évolution de l’application via la réutilisation de ces « composants » déjà existants. C’est donc en recherchant les bundles pouvant m’être utiles que j’ai découvert FOSUserBundle4_{. Il permet de gérer l’authentification et la gestion des rôles}

très facilement. J’ai donc passé le début de mon développement à le configurer et l’installer afin de l’utiliser pour mon outil. Grâce à lui, j'ai pu créer deux utilisateurs symbolisant un recruteur type et un gestionnaire type afin de tester l'application.

 Le premier formulaire

Après avoir réalisé cela, j’ai pu créer ma première fenêtre de formulaire. Encore une fois, grâce à Symfony, la procédure est simplifiée (voir annexe 2).

4_{https://github.com/FriendsOfSymfony/FOSUserBundle}

(15)

14

Comme vous pouvez le voir sur la page précédente, il y a beaucoup de champs à remplir afin de formuler un profil de recrutement. Avant d’arriver à ce point, il a fallu de nombreuses réunions afin de rajouter, enlever et/ou modifier ces champs (et donc modifier la base de données correspondante) mais aussi, dans une démarche de qualité, de définir les libellés et les « placeholder » c’est-à-dire, ce qui est écrit dans un champ en gris avant la saisie. Par exemple, le champ « Encadrant » ne peut pas être modifiable et il est rempli par défaut par le nom du recruteur connecté (un gestionnaire peut toujours tout modifier). Cela a résulté d’une longue conversation durant laquelle notre équipe s’est demandé si la personne émettant un profil peut désigner un autre encadrant qu’elle-même. Au final, dans le but de responsabiliser le recruteur, le champ ne peut être modifiable.

 L'affichage des données

Après avoir développé ce formulaire et l’avoir lié à la base de données, il était nécessaire de pouvoir consulter les données. Pour cela, j'ai utilisé un autre bundle, KitpagesDataGridBundle5_{. Celui-ci me permet d'afficher sous forme de tableau les données}

d'une table de ma base de données en choisissant les attributs à afficher et en déclarant si la colonne peut être filtrable ou ordonnable (par ordre alphabétique pour du texte, par ordre de grandeur pour les chiffres, etc...). J'ai ainsi créé la fenêtre de récapitulatif des profils de recrutement.



La gestion des privilèges : recruteur/gestionnaire

A partir de là, les utilisateurs pouvaient donc voir tous les profils proposés. Hors, un recruteur ne doit voir que les profils qu'il a lui-même proposé tandis que le gestionnaire doit voir les profils de tous les recruteurs. De ce fait, j'ai dû faire des vérifications côté serveur pour savoir le rôle de la personne connectée afin de pouvoir lui montrer des affichages différents. Par exemple, sur la figure ci-dessous, vous pouvez voir un affichage différent pour les deux mêmes profils de recrutement (voir annexe 12 et 13 pour voir les fenêtres en entier) :

Figure 2: Comparaison entre l'affichage d'un recruteur et d'un gestionnaire

(16)

15



Récupérer les utilisateurs

Afin de permettre un accès plus facile à l’application, les utilisateurs doivent pouvoir utiliser leur compte LDAP INRA, l’application doit donc pouvoir accéder à l’annuaire LDAP national de l’INRA afin de permettre l’authentification des utilisateurs. Mon tuteur m’a communiqué les paramètres de connexion à cet annuaire et il m’a alors été possible de créer un script afin de les insérer dans la base de données.



Gérer les utilisateurs

Tous les utilisateurs ayant le rôle de recruteur par défaut, il fallait maintenant les différencier pour la même raison que lors de la gestion des privilèges précédemment : chaque recruteur a ses propres profils. De ce fait, il a fallu faire des requêtes afin de n'afficher que les profils correspondant à l'utilisateur connecté.



Permettre les envois de fichiers

Lors d’une candidature, le potentiel employé doit pouvoir envoyer son CV et sa lettre de motivation. Pour cela, il faut donc gérer l’envoi de documents, et pouvoir les consulter comme bon nous semble.



Mails automatiques

Le but de cet outil étant notamment d’alléger la tâche du gestionnaire d’unité, l’envoi de mails automatiques était primordial. Mais encore une fois, grâce à Symfony, ce n’était pas très complexe. Il suffit juste de créer un objet Mail et de rajouter le destinataire, l’objet, les personnes en copie grâce à des fonctions simples comme « setTo(‘[email protected]’) » (voir annexe 3). Une fois le système bien compris et le premier mail automatique envoyé, ce fut facile de créer tous les autres nécessaires.



Réunion du Conseil UMR

Chaque mois, DYNAFOR fait une réunion de l’unité afin de prendre des décisions la concernant (validation d’emplois, projets à venir, etc…). On y retrouve le directeur, la gestionnaire et des membres élus représentant les différentes catégories de personnel. Le but de ce conseil est de conseiller le directeur d’unité dans l’administration et la gestion de l’unité. Le CUMR ayant validé mon stage, je suis intervenu au cours de la réunion du 22 mai pour y exposer le travail réalisé au travers d’un diaporama et d’une présentation de l’outil de recrutement tel qu’il était à cette date. Cela m’a permis d’obtenir un premier avis favorable mais aussi de recueillir des remarques des membres du conseil permettant d’avoir des pistes d’amélioration.

Ensuite, à la fin de ma présentation, j’ai sollicité les personnes présentes pour avoir des volontaires afin de tester mon outil pour avoir un premier retour d’expérience et ainsi l’améliorer. Une semaine après, j’ai reçu des réponses avec de très bonnes remarques qui m’ont appris qu’avoir un avis objectif sur notre travail est toujours très important. En effet, étant sur le projet depuis plus d’un mois, je connais le sujet, et notamment la procédure de recrutement, parfaitement. De ce fait, lorsqu’un testeur m’a fait remarquer que dans certains

(17)

16

champs du formulaire, il ne savait pas ce qu’il devait remplir, je me suis rendu compte que mon outil manquait de renseignements et de textes pour aider les utilisateurs.



Déploiement du site sur le serveur, intégration du LDAP

Ces deux points-clés seront évoqués dans la partie suivante car ils ont rencontrés des problèmes que je vais évoquer.

(18)

17

3. Problèmes rencontrés

 Validation de formulaire

Mon premier blocage fut lors de la réalisation de mon premier formulaire. En effet, après l’avoir mis en place, j’ai pu remarquer que je n’arrivais pas à valider mon formulaire lors du clic sur le bouton « Envoyer ». En effet, l’action qui était censée se réaliser lorsque le formulaire était validé, c’est-à-dire l’enregistrement dans la base de données et la redirection de page, n’arrivait jamais. Etant au début de mon stage et mes connaissances sur Symfony étant plutôt théoriques, je ne comprenais pas la raison du blocage.

Au bout de quelques heures, j’ai trouvé : j’avais oublié d’ouvrir et de fermer mon formulaire grâce à des fonctions de Symfony (voir annexe 2). De ce fait, celui-ci ne pouvait se valider puisqu’il n’existait pas, ce n’était que des champs « seuls », sans « attache ».

Malheureusement, ce ne fut pas mon seul problème avec mes formulaires. En effet, plus tard dans mon développement, j’ai fait tester l’outil par mes encadrants afin qu’ils détectent des disfonctionnements ou qu’ils trouvent des éléments à changer. Très vite, j’ai eu un retour inquiétant, Laurent Burnel n’arrivait pas à valider son formulaire… Je suis donc directement allé vérifier si j’ouvrais et fermais bien mon formulaire et c’était bien le cas. J’ai ensuite testé à mon tour sur mon ordinateur de le valider et ça fonctionnait, je ne comprenais pas le problème…

Et puis, j’ai remarqué que Laurent Burnel utilisait le navigateur Firefox. Hors, durant mon développement, j’effectuais mes tests sous Google Chrome. Je savais donc quoi chercher : un problème de compatibilité. Par contre, je ne savais pas où chercher. J’ai relu de nombreuses fois mon code, réfléchi où Firefox et Internet Explorer (qui ne fonctionnait pas non plus après test) pouvaient avoir un problème et puis j’ai trouvé.

En effet, pris d’un doute, j’ai testé sous Firefox un autre formulaire que celui d’émission d’un profil de recrutement et la validation fonctionnait ! C’était donc sur ce formulaire précis qu’il existait un problème de compatibilité. J’ai donc comparé l’affichage du formulaire d’émission de profil entre Firefox et Google Chrome jusqu’à trouver une différence, le champ date :

(19)

18

Comme vous pouvez le voir, Chrome remplissait directement le placeholder et intégrait aussi la sélection du jour avec un calendrier via la flèche vers le bas à droite du champ tandis que Firefox laissait un champ texte. Cela est dû au fait que Firefox (et Internet Explorer) non jamais reconnu le type de champ « Date ». Il n’y a que Google Chrome qui l’a implanté. De ce fait, j’ai dû remplacer ce champ libre sur Firefox par 3 champs de choix comme vous pouvez le voir ci- dessous

.

Figure 5 : Nouveau champ Date compatible entre navigateurs

 Déploiement sur le serveur de DYNAFOR

Une bonne partie du développement de l’outil s’est déroulé sur ma machine, en local. Mais, pour que l’outil soit utilisable par le personnel de DYNAFOR, il a fallu le transférer sur le serveur de l’unité. Pour cela, il faut d’abord vérifier la configuration du serveur, voir si certaines bibliothèques sont à jour et vérifier, une fois transféré, si l’outil fonctionne. Hors, ce n’étais pas le cas car il y avait des problèmes de permissions. En effet, un espace sur le serveur de DYNAFOR était dédié à mon outil, mais n’avait que des permissions d’exécution et de lecture. Hors, lors de l’utilisation de l’outil, Symfony enregistre les « logs »6_{dans des fichiers.}

Pour cela, le framework nécessite le droit d’écriture dans des dossiers spécifiques. Il en aller de même avec le dossier contenant les fichiers obtenus lors d’uploads.

De plus, lors du déploiement de l’outil, j’ai rencontré un problème de configuration de ma base de données. En effet, celle de mon unité étant déjà établie, j’avais oublié de modifier le fichier de configuration afin que la base de données de l’outil soit hébergée sur le serveur et non plus en local comme jusqu’à présent.

 Récupération des données du LDAP

L’outil de recrutement est un outil qui va être utilisé par le personnel de DYNAFOR afin de recruter du personnel. Dans le but d’harmoniser cet outil avec le système déjà en place, j’ai dû faire en sorte que l’on puisse utiliser mon outil avec ses identifiants LDAP (déjà utilisés quotidiennement par le personnel pour se connecter à son poste de travail par exemple). C’est un point très important dans le développement de l’application car sans cela, l’outil ne peut être viable. En effet, les utilisateurs aiment avoir des choses simples et des habitudes et devoir se créer un nouveau compte freinerait leur utilisation de l’outil de recrutement.

(20)

19

Ma première idée pour arriver à faire cela était de créer un script afin de récupérer toutes ses données et de les rentrer dans ma base de données d’utilisateurs. J’ai donc demandé à mon maître de stage de me donner l’adresse pour me connecter au serveur LDAP afin de réaliser mon idée. Mon objectif a été partiellement atteint puisque j’ai récupéré tous les utilisateurs de l’unité mais je n’avais pas accès à certains champs du LDAP, notamment les mots de passe. De ce fait, je ne pouvais pas les enregistrer dans ma base de données… Comme solution temporaire, tous les utilisateurs peuvent se connecter avec leur identifiant ldap mais avec comme mot de passe « toto ».

Après des recherches, j’ai trouvé que je pouvais faire un « bind » sur le LDAP c’est-à-dire, lui envoyer un identifiant et un mot de passe et il me dira si oui c’est le bon mot de passe pour cet identifiant et cet identifiant appartient au LDAP ou non, une des deux conditions précédentes est fausse. A partir de là, il me suffisait juste de, lorsque que la personne s’identifie, de faire cette demande au serveur et de laisser se connecter la personne en cas de réponse positive et de ne pas la laisser se connecter dans le cas inverse. Mais ici, un nouveau problème s’est posé. En effet, comme je l’ai déjà dit au début de ce rapport, l’authentification est faite via FOSUserBundle. De ce fait, je ne gérais pas de moi-même ce qui se passait lors du clic sur le bouton « Connexion », le bundle allait directement chercher dans la base de données configurer s’il y avait un utilisateur correspondant et comparer son mot de passe à celui rentré par l’utilisateur pour vérifier si il correspondait (FOSUserBundle hache les mots de passe selon un système que l’on peut choisir afin d’assurer la sécurité du système d’authentification). J’ai donc cherché dans quel fichier et à quel endroit exactement la vérification était faite mais je n’ai pas réussi à comprendre comment dérouter ce système d’authentification afin de s’identifier grâce au LDAP.

Finalement, j’ai recherché des bundles me permettant de se connecter au LDAP quitte à abandonner mon système d’authentification actuel. Après un moment de recherche, je me suis arrêté sur le bundle « FR3DLDAPBundle »7_{. Il fonctionne en relation avec FOSUserBundle}

et permet une authentification LDAP. Pendant plusieurs jours, je n’ai pas réussi à le faire fonctionner jusqu’à que je trouve une erreur de configuration qui m’avait échappé. Maintenant, tout utilisateur de DYNAFOR peut se connecter avec ses identifiants LDAP à l’outil.

(21)

20

Bilan sur la création

Maintenant, je vais vous dresser un bilan sur les résultats obtenus. Tout d’abord, je vous invite à aller voir l’annexe 10 qui contient un schéma représentatif de l’application. En effet, vous pouvez voir les principales pages de l’outil à travers la barre de navigation.

De plus, par rapport aux diagrammes de séquence que j’ai réalisés, je suis arrivé à la fin du processus 3. De ce fait, la procédure de recrutement est réalisable via l’outil jusqu’à l’arrivée de la personne dans l’unité. Là, les quelques interactions se font encore sans l’outil de recrutement. Ma mission est donc presque terminée même si dès le début de mon stage, mes encadrants m’avaient averti qu’elle serait très conséquente et que mon travail serait repris par la suite pour finaliser l’outil. On peut donc envisager la poursuite de ma mission en ajoutant à l’outil les fonctionnalités nécessaires aux deux processus manquants.

Enfin, ayant formé mon maître de stage sur le fonctionnement de mon application, des modifications simples et rapides pourront être effectués comme notamment l’ajout et/ou la modification d’intitulés, de textes explicatifs, etc…

(22)

21

Conclusion

Ce stage a été pour moi l’occasion de découvrir le monde de la recherche. J’ai dû me former intégralement au framework pour répondre à un besoin important de cette unité qui accueille de plus en plus de personnes non titulaires. J’ai également découvert une autre facette du métier de développeur dans un contexte professionnel à savoir la communication avec des personnes qui ne sont pas des professionnels de l’informatique. Ce sont ces difficultés qui ont fait l’intérêt de ce stage car j’ai pu apprendre une nouvelle façon de développer une application web en améliorant ma manière de communiquer avec mes collègues. En effet, le fait d’avoir des échanges constants avec les autres employés afin d’avoir des retours sur mon outil m’a permis de mieux comprendre la vie en entreprise avec parfois ses aléas.

Cette expérience m’aura donc permis d’améliorer mes savoir-faire et mes savoir-être dans un contexte professionnel. Je pense avoir réussi à m’intégrer dans DYNAFOR, une unité soudée et accueillante, et à avoir participé à son bon développement.

Néanmoins, si j’avais l’occasion de recommencer ce stage, j’aurais modifié mon comportement. En effet, comme vous avez pu le voir lors de ce rapport, je n’ai pas utilisé de méthode de développement et cela a, je pense, ralenti mon efficacité. De plus, j’aurais dû faire un planning prévisionnel qui m’aurait permis de me fixer des étapes. Lors de la prochaine situation professionnelle que je rencontrerai (notamment au cours de ma poursuite d’études longues), je saurais tirer profit de cet enseignement pour travailler plus efficacement.

(23)

22

Annexes

Symfony ... 23

Annexe 1 : Fonctionnement et structure de base ... 23

Annexe 2 : Les classes de formulaire ... 26

Annexe 3 : Les mails automatiques ... 28

Diagrammes de séquence de la procédure de recrutement ... 29

Annexe 4 : Original ... 29

Annexe 5 : Premier processus ... 31

Annexe 6 : Second processus... 32

Annexe 7 : Troisième processus ... 33

Annexe 8 : Quatrième processus ... 34

Annexe 9 : Cinquième processus ... 35

Fenêtres de l’outil ... 36

Annexe 10 : Schéma récapitulatif de la structure de l’outil ... 36

Annexe 11 : Fenêtre d’émission de profil ... 37

Annexe 12 : Fenêtre d’affichage des profils côté recruteur ... 38

Annexe 13 : Fenêtre d’affichage des profils côté gestionnaire ... 39

Annexe 14 : Fenêtre de candidature ... 40

Annexe 15 : Fenêtre de procédure globale ... 41

Autres ... 42

Annexe 16 : Organigramme de DYNAFOR ... 42

Annexe 17 : Diagramme de classe de la base de données ... 43

Annexe 18 : Glossaire ... 44

(24)

23

Symfony

Annexe 1 : Fonctionnement et structure de base

Symfony est un framework permettant de faire du développement web pérenne et sécurisé. Pour cela, il repose sur un noyau, le « kernel ». Enregistré dans celui-ci, il y a des « bundles », ce sont des bibliothèques qui servent de composants : ils peuvent être facilement remplacés et permettent une personnalisation de votre développement, vous n’utilisez que les bundles dont vous avez besoin ! (de base, Symfony comporte des bundles qui gèrent par exemple la gestion des formulaires, ORM pour la base de données…)

Tout d’abord, lorsque l’on commence à utiliser Symfony, il faut créer son projet qui est un bundle. En effet, notre projet devient ainsi un composant de Symfony, facilement exportable. Après avoir fait cela, on peut créer notre première page. Pour cela, il faut réaliser 3 étapes :

- Configurer une route - Créer un « Controller »

- Créer un fichier d’affichage ou « template »

Par exemple, je veux créer une page de mentions légales. Pour cela, je vais dans mon fichier de redirection (de « routing ») et je tape ceci :

(25)

24

Maintenant, le controller :

Comme vous pouvez le voir, le controller est juste une classe qui hérite de Controller. Par convention de nommage, tout controller doit terminer son nom

par « Controller »

comme dans mon exemple ci-dessus. Aussi, chaque fonction doit se terminer par « Action ». Ici, dans showAction(), vous pouvez observer que la fonction retourne juste un autre fichier. En effet, les mentions légales ne sont qu’une page d’affichage, il n’y a donc aucun traitement à effectuer à part appeler le fichier d’affichage ou « template » que vous pouvez retrouver ci-dessous :

Chaque fichier d’affichage hérite du fichier « base.html.twig ». C’est un fichier où sont définis des « blocks » qui permettent de modifier qu’une partie de l’affichage du projet. Globalement, les fichiers d’affichage ne modifient que le « block body » car la structure du site ne doit pas changer. De ce fait, il n’y a que le contenu qui changera mais l’aspect sera le même

Figure 7 : Controller de la page de mentions légales

(26)

25

pour toutes les pages. Donc, il suffit de remplir le « block body » et on obtiendra la page :

(27)

26

Annexe 2 : Les classes de formulaire

Lors d’un projet web, il arrive souvent un moment où l’on doit créer un formulaire. Hors, cela peut-être laborieux de faire toutes les vérifications des types de champ. Avec les classes Symfony, il n’y a plus ce problème !

En effet, les classes de formulaire permettent de générer directement les champs et de laisser l’outil faire les vérifications. Pour faire cela, il faut déjà préparer notre Controller :

Figure 10 : Création d'un formulaire

Un formulaire est forcément basé sur une table de la base de données. De ce fait, aux lignes 15 et 16, on créé un formulaire dans la variable « $form » en le liant à la table PNT. A la ligne 16, on peut voir l’appelle à une autre classe « CandidatureType() », c’est la classe de formulaire correspondante à une candidature d’un PNT que nous observerons par la suite. Tout d’abord, vous pouvez voir que si le formulaire est validé à la ligne 19 (si tous les champs nécessaires ont été remplis et que l’utilisateur à cliquer sur le bouton « envoyer »), on enregistre toutes les données dans notre table simplement (puisque tous les champs sont directement liés aux attributs de la table PNT) et on redirige sur une page de confirmation de l’envoi. Sinon, si le formulaire n’a pas été validé, c’est-à-dire si on vient d’arriver sur la page, on passe en paramètre le formulaire au fichier d’affichage (ligne 26).

Ceci étant fait, on peut maintenant écrire notre classe de formulaire. Encore une fois, comme les controllers et les méthodes, il y a une convention qui consiste à rajouter « Type » à la fin du nom de la classe de formulaire. Maintenant, observons comment créer le formulaire avec la fonction suivante :

Figure 11 : Classe de formulaire de candidature

Comme vous pouvez le voir, il suffit d’ajouter à la variable « $builder » le nom de la colonne de la table (par exemple ici : nom, prenom, cv, ldm) et le type de champ associé (ceci est facultatif car Symfony peut le définir en fonction du type de la colonne présente dans notre base de données). Aussi, vous pouvez remarquer aux lignes 17 et 18 une particularité : le type de la colonne est une autre classe de formulaire. En effet, « cv » et « ldm » sont des attributs

(28)

27

venant d’une autre table, Document, qui permet de gérer l’envoi des fichiers. J’ai donc créé une autre classe de formulaire comportant le nom du fichier (nécessaire pour la consultation) et le bouton d’envoi (qui permet le parcours dans l’ordinateur pour choisir le fichier). De ce fait, j’ai pu imbriquer ces deux formulaires en appelant la classe de formulaire correspondante.

Enfin, pour ce qui est de l’affichage, si l’on ne veut pas de personnalisation, il suffit d’une ligne :

Grâce à cela, tous les champs ajoutés dans la classe de formulaire sont affichés.

Figure 12 : Affichage du formulaire de candidature

Sinon, il faut faire comme ci-dessous

:

Figure 12 : Fenêtre d'affichage de candidature

Ici n’est représenté que le champ « nom ». Il faut bien sûr rajouter les autres champs entre les lignes 5 et 8 qui sont les balises ouvrantes et fermantes du formulaire. La ligne 7 ne doit pas être omise car c’est ce qui permet d’identifier la personne (pour ne pas que des automates pourrissent d’envoi le formulaire).

(29)

28

Annexe 3 : Les mails automatiques

Lorsque l’on fait du développement web, il arrive souvent que des mails envoyés automatiquement soient nécessaires. Symfony a donc implémenté une méthode d’envoi de mail décrite ci-dessous :

Figure 14 : Envoi d'un mail automatique

Cette procédure est donc très simple, le seul élément à faire attention est la ligne 3 car par défaut, le contenu sera au forma texte (c’est-à-dire .txt). De ce fait, le fichier de corps de message devra ne contenir que du texte. Il est plus conseillé de définir le type comme sur cet exemple car on peut mettre de la mise en page dans le mail.

(30)

29

Diagrammes de séquence de la procédure de

recrutement

Annexe 4 : Original

(31)

30

(32)

31

Annexe 5 : Premier processus

(33)

32

Annexe 6 : Second processus

(34)

33

Annexe 7 : Troisième processus

(35)

34

Annexe 8 : Quatrième

processus

(36)

35

Annexe 9 : Cinquième processus

(37)

36

Fenêtres de l’outil

Annexe 10 : Schéma récapitulatif de la structure de l’outil

(38)

37

Annexe 11 : Fenêtre d’émission de profil

(39)

38

Annexe 12 : Fenêtre d’affichage des profils côté recruteur

Figure 23 : Capture d’écran de la fenêtre d’affichage des profils lorsque l’on est un recruteur

(40)

39

Annexe 13 : Fenêtre d’affichage des profils côté gestionnaire

(41)

40

Annexe 14 : Fenêtre de candidature

(42)

41

Annexe 15 : Fenêtre de procédure globale

(43)

42

Autres

Annexe 16 : Organigramme de DYNAFOR

(44)

43

Annexe 17 : Diagramme de classe représentant la base de données

(45)

44

Annexe 18 : Glossaire

 INRA : Institut National de Recherche Agronomique

 DYNAFOR : Dynamiques et écologie des paysages agriforestiers

 INP : Institut National Polytechnique

 ENSAT : Ecole Nationale Supérieure Agronomique de Toulouse

 EI Purpan : Ecole d'Ingénieurs de PURPAN

 ENSIACET : Ecole Nationale Supérieure des Ingénieurs en Arts Chimiques Et Technologiques

 ENVT : Ecole Nationale Vétérinaire de Toulouse

 UMR : Unité Mixte de Recherche

 PNT : Personnel Non-Titulaire

 CUMR : Conseil de l’Unité Mixte de Recherche

 UML : Unified Modeling Language

(46)

(47)

(48)

Fiche « Compétences Stage »

Du : 07/04/15 au : 19/06 Durée : 11 semaines

Entreprise : INRA Fonction occupée : Développeur web Domaine d’activités : Recherche Diplôme : IUT Informatique Etudiant

Nom : Rudent Prénom : Nicolas

Maître de stage

industriel

Nom : F.Blaise

Tuteur de stage IUT Sujet du stage : Développement web sous framework Fonctions : Administrateur de base de données

Nom : M.Chevalier Coordonnées :

florent.blaise@toulous e.inra.fr

05 61 28 54 21

Contexte professionnel

Niveau

de

responsabilité

et

d’autonomie

Travail en autonomie mais possibilité de contacter le maître de stage dès besoin.

Tâches (j’ai fait …)

_{Activités (objectifs des tâches…)}

Rechercher des informations

Activité N°1 : Organiser des réunions

Préparer des éléments à présenter et des questions à poser Demander les champs nécessaires aux personnes concernées

Activité N°2 : Créer une base de données

Etudier le framework Rechercher des idées

Activité N°3 : Faire de la mise en page

Faire valider par des utilisateurs

Réaliser un diaporama Activité N°4 : Présenter le travail effectué

(49)

Les COMPETENCES professionnelles acquises lors du stage

Lister ci-dessous les compétences acquises dans les 4 domaines cités

Non acquises En cours d’acquisi--tion Acquises Maîtrisées

(mettre une croix dans une des 4 colonnes)

1- Organisationnelles :

Préparer et animer des réunions

X

2- Relationnelles :

Communiquer oralement et par mails avec mes collègues, être à l’écoute des futurs

utilisateurs

X

3- Personnelles :

Travail en autonomie, prise de décision

X

4- Méthodologiques (techniques et outils des métiers de l’Informatique) :

Développer en utilisant Symfony, réaliser des diagrammes UML

X

Mise en perspective

Ce stage m’a permis d’utiliser les compétences théoriques apprises au sein de ma formation et de les appliquer dans un contexte professionnel. Cela a été une expérience enrichissante, d’autant plus que j’ai découvert le monde de la recherche qui est plein de questionnements et d’interactions avec différents acteurs.