DYNAFOR (Dynamiques et écologie des paysages agriforestiers)

Télécharger le fichier pdf d’un mémoire de fin d’études

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.

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.

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.

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 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.

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).
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) :
 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(‘destinataire@mail.com’) » (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 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.

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 :
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.
 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.
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.

Table des matières

I – Présentation de l’INRA
A – Au niveau national
B – Le centre INRA de Toulouse Midi-Pyrénées
C – DYNAFOR (Dynamiques et écologie des paysages agriforestiers)
II – Mission du stage : Développement d’un outil web de recrutement
A – Buts et enjeux du stage
1. Détermination du besoin
2. Analyse de l’existant
B – Réalisation de l’outil
1. En amont : audit et modélisation
2. Points-clés de la construction
3. Problèmes rencontrés
III – Bilan sur la création
Conclusion

Télécharger le rapport complet