Création d'une plateforme de test pour l'équipe de recrutement - ARBLAY Thomas Mars à août 2019 - fil
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Création d’une
plateforme de test pour
l’équipe de recrutement
ARBLAY Thomas
Mars à août 2019
Référent université : M. Giuseppe LIPARI
Référent entreprise : M. Yasser MOUDOUANI
Table des matières
1. Smile 2
1.1. Processus de recrutement 2
1.2. Méthode actuelle pour l’évaluation 3
1.3. Limites de cette méthode 4
2. Les besoins de l’équipe recrutement 5
2.1. Les besoins à courts termes 5
2.2. Les besoins sur le long terme 6
3. Plan de mise en œuvre 7
3.1. Chronologie de la mise en œuvre 7
3.2. Méthodologie de mise en œuvre. 8
4. Choix technologiques 9
5. Une plateforme fonctionnelle et évolutive 12
5.1. Utilisation de la plateforme par un recruteur 12
5.2. La plateforme vue par un candidat 19
5.3. Présentation du schéma de données 22
6. Indicateurs de validation 26
6.1. Une vérification constante du code 26
6.2. Vers une amélioration de la qualité du code 28
6.3. Une plateforme déjà en service 29
Conclusion 31
Bibliographie 32
Master IAGL 2018-2019
1. Smile
J’ai effectué mon stage de deuxième année de Master au sein de l’entreprise Smile,
cette société est le leader européen de l’intégration et de l’infogérance de solutions open
source.
Fondée en 1991 par 4 amis issus de Grandes Écoles, la société a fait le pari de se
distinguer en proposant des applications web à l’heure où beaucoup se contentaient de pages
statiques. S’appuyant sur des technologies open source, Smile a réussi à se distinguer de la
concurrence et ainsi devenir le leader européen du secteur. Cette philosophie se retrouve par
l’intermédiaire de livres blancs que Smile met en ligne et portant principalement sur le thème
de l’open source.
Aujourd’hui, la société dispose d’une quinzaine d’agences principalement en France
mais aussi en Europe. Elle se compose actuellement d’environ 1700 collaborateurs dont une
cinquantaine pour l’agence de Lille.
J’ai effectué mon stage au sein d’une équipe composée de deux développeurs : moi-
même et Romain Lamoot, également stagiaire issu du Master informatique de l’université de
Lille. À cette équipe viennent s’ajouter deux collaborateurs pour le suivi du projet : un coach
en méthodologie agile et d’un membre de la direction technique expert en Symfony[1].
Le rôle de cette équipe est de mettre en place une plateforme dédiée à l’équipe de
recrutement en vue de simplifier et de fluidifier le processus de recrutement de l’entreprise.
1.1. Processus de recrutement
Le recrutement au sein de la société Smile suit un processus assez standard dans les
sociétés du secteur informatique. La première étape consiste en un entretien avec un membre
de l’équipe de recrutement afin de vérifier que le candidat correspond au poste pour lequel il
postule. Si l’entretien est concluant, le candidat est invité à passer un test pour évaluer son
Page 2
Master IAGL 2018-2019
niveau technique sur les technologies correspondant au poste. Enfin, si le test est concluant,
la dernière étape est constituée d’un deuxième entretien avec un expert technique pour
vérifier les compétences techniques du candidat.
Entretien avec un
membre de Passage d’un test Entretien avec un
l’équipe de technique Si les résultats expert technique
recrutement du test sont
concluant
Fig 1 : Modélisation du processus de recrutement
1.2. Méthode actuelle pour l’évaluation
Afin de faire passer le test technique à un candidat, les recruteurs utilisent deux façons
différentes selon les cas. Si le candidat postule pour une agence où se trouve une équipe de
recrutement, il est invité à se déplacer à l’agence pour réaliser le test au format papier dans
une salle. Si le candidat vise une agence où il n’y a pas d’équipe de recrutement (comme c’est
le cas à Lille par exemple), le candidat passe son test via un système de messagerie en ligne
comme Hangout ou Skype.
Une fois le test passé, les réponses du candidat sont rassemblées dans un fichier Excel
qui permet de calculer le score que le candidat. Comme nous pouvons le voir sur l’exemple
ci-dessous, le fichier suit un modèle simple avec une question par ligne et le barème de
chaque réponse est indiqué dans les colonnes correspondantes. La dernière colonne sert à
indiquer le résultat obtenu pour la question. À la droite du barème, nous pouvons voir la zone
indiquant les résultats globaux et par catégorie du candidat.
Si les résultats sont suffisamment bons pour que le candidat obtienne un entretien
technique, ce fichier peut être communiqué à la personne en charge de cet entretien. Cela lui
permet d'avoir un aperçu des compétences du candidat qui se trouve en face d’elle.
Page 3
Master IAGL 2018-2019
Fig 2 : Exemple de fichier servant à la correction
1.3. Limites de cette méthode
Cette méthodologie de passage de tests possède de multiples limites que ce soit en
version papier ou via un service de discussion en ligne. Le principal problème du
questionnaire en version papier est la limitation dans les horaires de passage d’un test. En
effet, le candidat doit se présenter à l’agence aux horaires d’ouverture pour réaliser son test.
Si ce dernier a déjà un poste dans une autre société, les horaires ne sont pas forcément
compatibles.
Pour ce qui est de la version passée via un service de messagerie, les contraintes sont
plutôt du côté l’équipe de recrutement. En effet, cela permet d’être plus souple pour le
candidat mais le recruteur doit faire des copier-coller dans le service de messagerie, la tâche
est donc répétitive et demande du temps au recruteur. Ce temps pourrait être consacré à
d’autres tâches plus pertinentes. De plus, cette méthode est souvent utilisée par les recruteurs
en dehors de leurs heures habituelles de travail pour s’adapter aux candidats.
Si on regarde les deux méthodes précédemment citées, nous pouvons constater
qu'elles présentent des limites qui leur sont communes. Premièrement, les deux méthodes
nécessitent la présence du recruteur durant l'intégralité du passage du test. Cela représente
une perte de temps importante. Si l'on ajoute à cela la nécessité de saisir manuellement les
résultats qui engendre non seulement une autre perte de temps mais également un risque
d'erreurs lors de la saisie.
Page 4
Master IAGL 2018-2019
Le fichier servant au stockage des résultats présente aussi des défauts. Premièrement,
il n'est pas possible de connaitre le détail des réponses du candidat, seul le total des points par
question est saisi. La personne en charge de l'entretien technique ne peut donc pas savoir
exactement les réponses choisies (plusieurs combinaisons de réponses peuvent donner le
même total). Deuxièmement, il est également impossible de connaitre l'intitulé de la question
à partir de ce fichier. Cela impose donc de se reporter constamment à l'énoncé du test. Enfin,
le stockage des résultats sous forme de fichiers Excel implique une multiplication des fichiers
au cours du temps ce qui s'avère peut pratique à gérer sur le long terme. Il semble également
difficile de faire des statistiques et de les maintenir à jour avec ce système.
2. Les besoins de l’équipe recrutement
2.1. Les besoins à courts termes
Après avoir effectué ces constatations, il est nécessaire de définir les besoins de
l’équipe de recrutement. Pour nous aider dans cette tâche, un cahier des charges nous a été
fourni par un des membres de l’équipe. Celui-ci se compose de plusieurs pages, montrant à la
fois des exemples d’écran comme ci-dessous ou des indications sur les fonctionnalités
désirées.
Fig 3 : Cahier des charges de la page de création du candidat
Page 5
Master IAGL 2018-2019
On peut constater d’après le cahier des charges qu’un des besoins essentiels est la
simplicité d’utilisation, l’interface se compose de peu de boutons. En effet, la plateforme sera
manipulée par des personnes n’étant pas nécessairement expertes en informatique. Un autre
besoin important se dégage fortement : le besoin de l’automatisation. En effet, tout l’intérêt
d’une telle plateforme est de pouvoir laisser la charge des tâches répétitives à l’application.
La correction des tests sera donc automatisée ainsi que l’envoi des mails. Le candidat devra
recevoir un mail une fois qu’on lui affectera un test. Le recruteur pourra également être
notifié une fois que les résultats seront disponibles.
Les résultats étant disponibles immédiatement, un retour pourra être fait
immédiatement au candidat à la fin de son test. Ces résultats pourront également servir à
créer des statistiques plus poussées que celle qui sont actuellement générées avec le fichier
Excel. Nous pouvons par exemple imaginer calculer des moyennes de résultats selon certains
critères comme le nombre d’année d’expérience. Un export des résultats au format PDF est
aussi prévu pour les collaborateurs faisant passer les entretiens techniques.
2.2. Les besoins sur le long terme
Une fois la plateforme fonctionnelle pour l’équipe de recrutement, il est prévu
d'ajouter de nouvelles fonctionnalités sur la plateforme. Dans un premier temps, il est prévu
de permettre à un candidat de répondre à des questions avec des morceaux de code qui seront
exécutés afin de valider des tests unitaires. Le principe de fonctionnement serait similaire à
des sites comme Coding Game[2] ou HackerRank[3]. L'objectif est d'ajouter plus
d'interactions entre la plateforme et le candidat. De plus, l'équipe de recrutement aura plus
d'information sur le candidat. En effet, le fait de devoir coder pour répondre à une question
mobilise plus de compétence qu'un simple questionnaire de connaissance.
La deuxième fonctionnalité additionnelle serait l'ouverture de la plateforme aux
collaborateurs Smile. Elle servirait alors à l'évaluation des collaborateurs afin de pouvoir
planifier des formations, d'adapter le niveau de ces dernières ou bien de vérifier que le
collaborateur a assimilé les notions vues au cours de la formation.
Page 6
Master IAGL 2018-2019
3. Plan de mise en œuvre
3.1. Chronologie de la mise en œuvre
La mise en place s’est effectuée selon un ordre qui suit la logique d’utilisation de la
plateforme. La première étape a consisté à mettre en place la partie utilisée par les recruteurs.
Cette partie permet de gérer les tests, les candidats et les administrateurs de la plateforme.
Une fois que les données nécessaires au passage d’un test sont disponibles, il est temps de
mettre en place l’interface pour que le candidat. Cette partie du développement permet à
l’utilisateur de répondre aux questionnaires qui lui sont soumis par le recruteur. Par la suite,
le recruteur aura besoin de consulter les résultats du candidat. La troisième phase consiste
donc en une amélioration de la partie pour les recruteurs avec l’affichage des résultats et une
gestion plus avancée des tests, candidats et résultats.
Amélioration de la
Partie destinée au Partie destinée au partie pour le
recruteur candidat recruteur
(gestions des tests (passage d’un (gestion avancée
et utilisateurs) test) des utilisateurs et
résultat des tests)
Fig 4 : Modélisation de la chronologie de développement
Ce plan de mise en place s’accompagnera également de la prise en compte des
remarques faites par les différents utilisateurs de la plateforme. Il sera également nécessaire
de mettre la plateforme en conformité avec Règlement Général sur la Protection des Données
(ou RGPD[4]). Ces améliorations se feront tout au long du développement de la plateforme, à
mesure que les demandes arriveront.
Page 7
Master IAGL 2018-2019
3.2. Méthodologie de mise en œuvre.
Le cycle de développement d'une fonctionnalité de l'application peut être découpé en
quatre étapes successives :
• Conception : lors de cette étape, nous imaginons les différents aspects de la
fonctionnalité. Nous pouvons par exemple citer les actions qu'il sera possible de faire
sur une page, le design de la page ou encore les informations qui doivent être
présentes sur un export au format PDF.
• Proposition : il s'agit de la phase durant laquelle nous proposons aux autres membres
de l'équipe afin de pouvoir échanger sur la fonctionnalité. Si un membre de l'équipe a
une idée de design ou d'interaction qui n'a pas été pensée durant la phase de
conception. Cela permet de détecter certains problèmes avant même d'avoir
commencé à coder.
• Implémentation : cette phase s'explique d'elle-même puisqu'il s'agit de la phase de
réalisation de la fonctionnalité.
• Validation : la dernière phase permet de valider une fonctionnalité. Cela se fait au
niveau du code via une merge request sur Gitlab[5] afin de s'assurer de la qualité du
code. Une suite de test assure également une vérification du code. Cette phase se
termine par une démonstration à la personne en charge du projet pour avoir ses
remarques sur les fonctions développées.
Conception
Validation Proposition
Implémentation
Fig 5 : Modélisation du
processus de développement
Page 8
Master IAGL 2018-2019
4. Choix technologiques
La première étape dans la réalisation d’une application consiste à choisir les
technologies qui seront utilisées pour la réalisation du projet. Nous avons été laissés libre de
choisir les technologies que nous allions utiliser. Nous nous sommes rapidement tournés vers
des technologies que nous connaissions tous les deux. Cela nous a permis de commencer
rapidement à développer les premières fonctionnalités d'un produit minimum viable
(Minimum Viable Product ou MVP[6]). Il s'agit de proposer une application comportant les
fonctionnalités jugées essentielles. Toutefois, il ne s'agit pas de fournir une application où des
bugs subsistent. La réalisation d'un MVP est souvent liée à l'utilisation de la méthode Agile
qui est utilisée pour ce projet. En effet, il est facile d'apporter des améliorations à l'application
à chaque itération de développement.
Afin d'avoir une architecture de projet la plus clair possible, nous avons choisi
d'utiliser l'architecture Modèle/Vue/Contrôleur (ou MVC[7]). Cette architecture d'application
découpe les rôles selon trois entités distinctes : le modèle, la vue et le contrôleur.
Navigateur
1 4
3
Contrôleur Vue
2
1. Action utilisateur via une requête HTTP
2. Consultation et/ou mise à jour du modèle (facultatif)
3. Le contrôleur décide de la vue à afficher
Modèle
4. La vue renvoi le code HTML au navigateur
Fig 6 : Fonctionnement du modèle MVC
Page 9Master IAGL 2018-2019
Le modèle contient les données manipulées par l'application. Il assure la gestion de
ces données et garantit leurs intégrités. Dans le cas typique d'une base de données, c'est le
modèle qui la contient. La vue fait l'interface avec l'utilisateur. Sa première tâche est
d'afficher les données qu'elle a récupérées auprès du modèle. Sa seconde tâche est de recevoir
toutes les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons…). Ses
différents évènements sont envoyés aux contrôleurs. Le contrôleur est chargé de la
synchronisation du modèle et de la vue. Il reçoit tous les évènements de l'utilisateur et
déclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle et ensuite avertit la vue que les
données ont changée pour que celle-ci se mette à jour. Certains évènements de l'utilisateur ne
concernent pas les données mais la vue. Dans ce cas, le contrôleur demande à la vue de se
modifier.
L'avantage de cette architecture est son découpage. Chaque entité possède ses propres
fichiers. On peut donc simplement faire évoluer ou maintenir une seule des entités ce qui
implique un gain de temps. La séparation des fichiers permet de simplifier le travail
simultané d'un développeur front-end et d'un développeur back-end puisqu'ils ne travaillent
pas sur les mêmes fichiers. Toutefois, cette séparation des entités n'a pas que des avantages et
implique une augmentation conséquente du nombre de fichiers. Cela peut s'avérer gênant sur
des projets de petite taille. La complexité de l'architecture ne serait plus en accord avec celle
du projet.
Pour la partie « contrôleur », nous avons décidé d’utiliser le framework Symfony en
version 4. Il s’agit de la dernière version disponible au moment du développement de la
plateforme. Nous avions des bases dans l’utilisation de ce framework et nous souhaitions tous
les deux approfondir nos connaissances. Ce framework est par ailleurs largement documenté
ce qui est un avantage indéniable lorsque l’on souhaite progresser dans la maîtrise d’un
framework. De plus, un membre de la direction technique de Smile possède un excellent
niveau de maîtrise de Symfony, il nous a été d’une grande aide tout au long du
développement.
Page 10Master IAGL 2018-2019
La partie « vue » est réalisée grâce à Twig[8]. Il s’agit d’un moteur de template pour
le langage PHP et qui est le moteur par défaut de Symfony. Ce choix n’a pas été fait par
défaut mais a été réfléchi. En effet, Twig est très simple d’utilisation. On pourrait le comparer
à de l’HTML amélioré avec des fonctions et des éléments de contrôle (boucles, conditions,
etc.). L’apprentissage est donc simple et nous avions déjà de bonnes connaissances sur ce
sujet. Le démarrage du projet est donc accéléré. La deuxième option aurait pu être d’utiliser
une interface en ReactJS[9] mais cela nécessitait trop de temps pour maitriser la technologie.
Afin de rendre les pages interactives avec l'utilisateur, nous avons utilisé plusieurs librairies
Javascript tel que Jquery[10], SortableJS[11], ChartJS[12] ou HighlightJS[13]. L'utilisation
de Bootstrap[14] nous a permis d'obtenir plus facilement les designs voulus pour les pages de
la plateforme.
Nous avons choisi le gestionnaire de bases de données MySQL[15]. Ce choix s’est
imposé de lui-même. Nous connaissions l’utilisation des bases de données relationnelles et
MySQL est un des gestionnaires les plus utilisés. De plus, il s’intègre parfaitement à
Symfony par l'intermédiaire de Doctrine[16]. Il s'agit d'un ORM (object-relational mapping)
qui permet de faire le lien entre la base de données et l'application. Ce programme permet de
simplifier la gestion des données en simulant une base de données orientée objet.
1 4
3
2
1. Action utilisateur via une requête HTTP
2. Consultation et/ou mise à jour du modèle (facultatif)
3. Le contrôleur décide de la vue à afficher
4. La vue renvoi le code HTML au navigateur
Fig 7 : Fonctionnement du modèle MVC avec les
technologies utilisées
Page 11Master IAGL 2018-2019
5. Une plateforme fonctionnelle et évolutive
5.1. Utilisation de la plateforme par un recruteur
Pour cette partie, nous supposerons que l'utilisateur est le premier à avoir accès à la
plateforme. Il n'y a donc aucune donnée enregistrée dans la plateforme. Un administrateur
présent sur la plateforme va, de façon générale, l'administrateur va suivre le schéma
d'utilisation décrit ci-après.
La première étape consiste à se connecter à la plateforme. Cette étape se fait via la
page suivante.
Fig 8 : Page de connexion de l’application
Cette page est commune à l'administrateur et au candidat. Une fois les identifiants
saisis, la plateforme procède aux différentes vérifications : l'utilisateur est-il connu,
l'utilisateur a-t-il encore le droit d'accéder à la plateforme. Une fois ces vérifications faites,
l'administrateur arrive sur la page d’accueil.
Page 12Master IAGL 2018-2019
Fig 9 : Page d’accueil
À partir de cette page, l'administrateur peut accéder à l'intégralité de la plateforme. Il
dispose pour cela de cinq boutons au centre de la page permettant chacun d'accéder à une des
entités principales du site. Une barre de navigation se trouve sur la partie supérieure de
l'écran. Elle est disponible sur toutes les pages visitées par l'utilisateur et reprend les éléments
disponibles sur l'accueil.
Afin de pouvoir tester un candidat, il est nécessaire de créer un test, lui-même
composé de questions. Pour cela, l'administrateur peut se rendre sur le formulaire de création
d'une question via la barre de navigation.
Page 13Master IAGL 2018-2019
Fig 10 : Page de création d’une question
Cette page permet à l'utilisateur de saisir toutes les informations nécessaires.
Premièrement, il est invité à saisir l'intitulé de sa question dans le premier champ. Par la suite,
il peut saisir le type de sa question : question à réponse unique ou question à choix multiples.
Cela permet de déterminer si le candidat pourra sélectionner plusieurs réponses ou non.
Ensuite, il est nécessaire de saisir une catégorie pour la question. Ces catégories
devront être créées au préalable via une page dédiée. Cette page se compose uniquement d'un
champ pour permettre la saisie d'une nouvelle catégorie et d'une liste reprenant celles déjà
existantes. Cette catégorisation est avant tout utilisée pour le calcul des résultats d'un test (cf.
page 18).
Le champ suivant à un rôle plus spécifique, il s'agit du "cas". Ce champ, optionnel, est
à déplier en cliquant sur le label pour faire apparaitre une zone de texte. Elle permet de saisir
du texte supplémentaire principalement du code, qui sera affiché au candidat.
Page 14Master IAGL 2018-2019
Il faut ensuite saisir les différentes réponses qui seront proposées au candidat ainsi
que leurs scores. Ces scores permettent une pondération des réponses mais aussi de
déterminer si une réponse est bonne ou non. Une réponse a score strictement positif sera
considérée comme bonne, elle sera fausse dans les autres cas.
Enfin, l'utilisateur peut saisir des tags. La saisie est libre et non obligatoire. Ces tags
sont là pour aider à la recherche rapide de questions dans la liste ou à la création d'un test. Le
bouton "Sauvegarder" enregistre la question et renvoie sur la liste des questions déjà
existantes. Si l'on souhaite saisir une autre question, le bouton "Sauvegarder et continuer"
enregistre la question et charge un nouveau formulaire vierge.
Maintenant que la plateforme contient une ou plusieurs questions, il est nécessaire de
créer un test pour les candidats. Pour cela, l'administrateur se rend sur la page dédiée. Cette
page comporte plusieurs champs assez similaires à ceux de la page de création d'une
question : titre du test, informations complémentaires et tags. Un autre champ permet la saisie
de la durée indicative du test. Enfin, le champ principal de la page est la sélection des
questions qui composeront le test. La colonne de gauche propose l'intégralité des questions
disponibles. Il est possible de sélectionner une question en utilisant le mécanisme de glisser-
déposer. Il est possible de glisser plusieurs questions en même temps en les sélectionnant via
un clic. Il est aussi possible d'afficher les détails d'une question grâce au petit symbole
d'information dans le carré de la question. Deux champs de recherche permettent pour
chacune des colonnes de rechercher les questions par tag.
Page 15Master IAGL 2018-2019
Fig 11 : Page de création d’un test
Après avoir créé le premier test, il faut créer le profil du candidat pour qu'il puisse
passer le test. Cette page est extrêmement classique dans sa première partie : nom, prénom,
mail, nombre d'années d'expérience. Pour le champ des technologies visées, il s'agit d'un
champ disposant d'une autocomplétion. Cela permet de garder une certaine uniformité dans la
saisie des données par les différents administrateurs. Enfin, la dernière étape permet
d'associer directement un ou plusieurs test(s) au candidat qui va être créé.
Page 16Master IAGL 2018-2019
Fig 12 : Page de création d’un candidat
Il existe une page permettant l'association d'un test à un candidat déjà existant. Cette
page peut être utilisée si l'administrateur veut associer un test supplémentaire à un candidat
ou s'il ne l'a pas fait durant la création du profil. Cette page se compose de deux champs
disposant de l’auto complétion : à gauche le nom du test, à droite le nom du candidat.
Fig 13 : Page d’association d’un candidat
Page 17Master IAGL 2018-2019
Lorsque le candidat a terminé de passer son test, les résultats sont disponibles
immédiatement pour le recruteur. Lorsqu’il se rend sur la page des résultats, le recruteur a
accès à de multiples informations. Premièrement, il peut voir le score global du candidat, en
nombre de points et en pourcentage. Sur la droite, on retrouve les résultats par catégories en
nombre de points. En dessous, on trouve un diagramme en barres horizontal. Il permet de
comparer le temps mis par le candidat pour finir le test avec le temps prévu par les recruteurs.
En dessous, on peut voir les temps indiqués de façon plus précise. À la suite de cela, on
trouve un diagramme « radar » ou « en toile d’araignée ». Celui-ci donne les résultats du
candidat par catégorie en pourcentage. Il est ainsi très simple de se rendre compte des forces
et faiblesses du candidat. Enfin, en bas de la page se trouve le détail des réponses du candidat.
Pour chaque question, on retrouve l’énoncé, les réponses du candidat mais aussi la correction
du test. C’est page peut-être exporté au format PDF afin de la partager à la personne qui sera
en charge de l’entretien technique.
Fig 14 : Page des résultats
Page 18Master IAGL 2018-2019
Une fois la plateforme en phase de production, cette page sera enrichie avec des
statistiques. On pourra visualiser le temps moyen mis par les candidats pour finir le test et
aussi leur score moyen dans le graphique présentant les résultats par catégorie.
5.2. La plateforme vue par un candidat
Le premier contact avec la plateforme pour le candidat passe par la réception d'un
mail l'invitant à accéder à la plateforme. Ce mail lui indique qu'il a un nouveau test à passer et
lui fournit un lien de connexion. Ce lien comporte un token d'accès valide pendant une
semaine.
Fig 15 : Mail reçu par le candidat
Si le candidat souhaite pouvoir revenir sur la plateforme une fois le token expiré, il est
invité à changer son mot de passe lors de la première connexion. Sur la page d'accueil, le
candidat dispose d'une liste de ses tests, à passer ou déjà terminé. Il peut consulter les
résultats de ceux qu'il a passés ou démarrer les nouveaux.
Page 19Master IAGL 2018-2019
Lorsqu'il démarre un nouveau test, le candidat accède à une page d'information. Elle
lui indique le nombre de questions dans le test, la durée estimée du test et, éventuellement, les
informations complémentaires saisies à la création du test.
Fig 16 : Page de démarrage d’un test
Pour chacune des questions, le candidat aura une page lui permettant de répondre. Sur
cette dernière, on peut trouver deux éléments permettant au candidat de suivre sa
progression : un chronomètre (bleu s'il est sous le temps prévu, orange sinon) et une barre de
progression.
Il trouve ensuite une zone lui indiquant l'énoncé de la question ainsi que les
éventuelles informations complémentaires avec une coloration syntaxique pour le code.
Enfin, il peut voir une zone avec les différentes réponses possibles et un bouton pour passer à
la question suivante. S’il ne souhaite pas répondre pour ne pas perdre de points, il peut
simplement cliquer sur le bouton pour passer à la suite. Il ne pourra toutefois pas revenir en
arrière.
Page 20Master IAGL 2018-2019
Fig 17 : Page de réponse du candidat
Une fois que le candidat a répondu à toutes les questions de son test, il peut retourner
à l'accueil ou accéder à la page de résultats. Cette dernière se compose d'un graphique qui
affiche les pourcentages de points obtenus par catégorie. À côté, se trouve le pourcentage
global obtenu par le candidat.
Fig 18 : Page de résultat du candidat
Page 21Master IAGL 2018-2019
5.3. Présentation du schéma de données
Afin de stocker les données de l'application, il a été nécessaire de développer un
schéma pour la base de données. Ce schéma est en réalité généré automatiquement par
Symfony en se basant sur les entités de l'application. Une entité est un objet, donc la
sauvegarde est confiée à un ORM (comme Doctrine par exemple). La conception de la base
de données a donc été relativement simple. Il a en effet suffit de suivre les besoins de
l'application pour créer nos objets. Le schéma de la base de données a ainsi évolué tout au
long du développement de l'application. Si on prend l'objet Test, on peut voir que l'object
correspond à la table générée.
Fig 19 : Comparaison entre la classe Test et son schéma en base de données
La variable "questions" étant une collection de questions, il est nécessaire d'avoir une
table intermédiaire "test_question" pour pouvoir stocker cette association. Pour la variable
"candidatesTests", la valeur est en réalité stocker dans la table "candidate_test" car chaque
objet CandidateTest possède un attribut de type Test. Les autres attributs de l'objet "Test"
contiennent les informations saisies par l'administrateur : le nom du test, la durée prévue, les
tags, les informations complémentaires ainsi que les questions qui composent le test.
Page 22Master IAGL 2018-2019
Fig 20 : Schéma complet de la base de données
Si on regarde l'intégralité de la base de données, on peut remarquer 4 tables qui se
détachent des autres par leurs tailles. Ces quatre tables correspondent aux entités principales
de l'application. Il s'agit de :
• user
• question
• test
• candidate_test
L'entité User contient toutes les informations en relation avec l'utilisateur, qu'il
s'agisse de l'administrateur ou du candidat. Elle implémente l'interface utilisateur du
composant de sécurité de Symfony. On peut noter l'identifiant, le rôle (administrateur ou
candidat), l'email, si l'utilisateur s'est déjà connecté, si le compte est verrouillé ainsi que la
date de création pour les champs qui sont communs. Si l'utilisateur est un candidat, les
champs indiquant la date de naissance, le nombre d'années d'expérience, les technologies
ciblées et l'agence ciblée seront remplis. Pour un administrateur, on ne sauvegarde que la
fonction (expert technique, recruteur ...) en plus des informations communes.
Page 23Master IAGL 2018-2019
Fig 21 : Classe représentant l’utilisateur
L'entité représentant la question est découpée en plusieurs classes. Il y a une classe
abstraite pour les informations communes à tous les types de questions. Chaque type de
question possède sa propre classe pour le représenter. Actuellement, nous avons les questions
à choix unique et à choix multiple. Ces deux classes étendent la classe abstraite "Question".
Afin de stocker les bonnes et mauvaises réponses, les réponses ont été séparées en deux
attributs : "right" et "wrong". Les réponses ainsi que les scores associés sont stockés dans un
object séparé.
Fig 22 : Classe représentant les questions
Page 24Master IAGL 2018-2019
Pour stocker les informations relatives au passage d'un test par le candidat, il a été
nécessaire de créer une nouvelle entité : le "CandidateTest". Cette entité fait le lien entre
l'utilisateur et le test, un champ est donc consacré à chacune de ces informations. Nous
sauvegardons également l'utilisateur qui a affecté le test au candidat afin de pouvoir le
notifier. Les questions étant affichées dans un ordre aléatoire, il est impératif de sauvegarder
cet ordre, nous retenons également la question courante. Enfin, nous enregistrons la date de
création, de démarrage et de fin du test. Pour enregistrer les réponses du candidat, nous avons
un attribut "candidateAnswers" qui contient des objects du même nom. Ces derniers sont des
associations entre une question et les réponses de cette dernière qui auront été sélectionnées
par le candidat.
Fig 23 : Classe représentant le test assigné au candidat
Page 25Master IAGL 2018-2019
6. Indicateurs de validation
6.1. Une vérification constante du code
Afin de s’assurer que la plateforme reste fonctionnelle tout au long de son évolution,
une intégration continue a été mise en place. Pour cela, nous utilisons la plateforme Gitlab
qui héberge le code source et plus particulièrement l’outil Gitlab CI. Ainsi, l’intégration
continue se déclenche à chaque mise à jour du code sur la plateforme.
Cette intégration est composée de deux étapes. La première vise à vérifier que le code
source répond au standard de qualité de la société. Pour cela, nous lançons une série
d’analyseurs de code pour le langage PHP comme PHP Mess Detector[17] par exemple. Nous
lançons également une vérification des failles de sécurité des packages utilisés via le security-
checker[18] de Symfony. Cela permet d’éviter d’utiliser des librairies dans des versions ayant
des failles de sécurité connues.
La seconde étape de l’intégration continue lance la suite de tests PHPUnit[19] qui
vérifie le bon fonctionnement de l’application. Afin d’être certains que l’application
fonctionne toujours après l’implémentation d’une nouvelle fonctionnalité, la suite de tests ne
comporte que des tests fonctionnels. Ces tests exécutent des requêtes sur la plateforme
comme le ferait un utilisateur lambda. Chaque fonctionnalité est testée par une classe de test
qui essaie les différentes actions possibles. Ces tests sont réalisés sur des données aléatoires.
Ainsi, il est impossible de prévoir quelles données seront présentes à l’avance. Si la capture
d'écran ci-dessous, on peut voir que la plupart des classes sont colorées en vert. La couverture
de test est donc globalement bonne. Toutefois, une partie des tests apparait en orange ou
rouge. Ceci s'explique par le fait que cette couverture de test ne comporte qu'une partie des
tests, ceux codés avec le WebTestCase.
Page 26Master IAGL 2018-2019
Fig 24 : Couverture des tests fonctionnels
La majorité de ces tests est réalisée avec l’outil de test fonctionnel de Symfony : le
WebTestCase. Toutefois, cela ne permet pas de tester les pages où il est nécessaire d’exécuter
du code javascript. Pour cela, nous avons utilisé Panther[20]. Il s’agit d’une librairie qui
permet d’exécuter des tests en pilotant un navigateur internet comme Chrome ou Firefox. La
javascript est alors exécutée par le navigateur. Cependant, l’utilisation de cette librairie ne
nous a pas donné entière satisfaction.
On peut noter deux points négatifs à l’utilisation de Panther. Premièrement, il y a le
temps d’exécution. Un test qui utilise Panther s’exécute en une quinzaine de secondes. À titre
de comparaison, un test avec WebTestCase passe en moins d'une demi-seconde. Avec la suite
de tests actuelle, qui comporte environ 200 tests, il faudrait un peu moins d’une heure pour
faire passer l’intégralité des tests. Nous avons donc utilisé Panther uniquement lorsque c’était
nécessaire.
Page 27Master IAGL 2018-2019
L’autre problème de Panther est sa relative jeunesse. Le projet a environ un an et
demi. Il reste donc certains bugs ou cas qu’il n’est pas possible de tester. Premièrement, lors
de la création d’un test, nous utilisons la mécanique du « drag and drop » afin de sélectionner
les questions qui le composent. Or, la méthode permettant de demander la libération de
l’élément ne fonctionne pas correctement. Il est donc impossible de tester cette fonctionnalité.
Il en va de même pour l’export des résultats d’un candidat dans un fichier PDF. Panther ne
supporte pas le téléchargement de fichier. Enfin, le point le plus problématique est
l’instabilité. Panther rencontre une erreur lors de la déconnexion du navigateur piloté. Les
assertions dans le test sont validées mais la suite de test s’arrête malgré tout. Il nous est donc
impossible de lancer les tests Panther dans l’intégration continue ou dans les tests de
couverture. Cette dernière perd donc en intérêt, même si une grande partie des tests sont
rédigés en WebTestCase.
La solution pour palier à ce problème serait de réécrire les tests nécessitant
l’utilisation du javascript avec un autre framework de test comme Cypress[21] par exemple.
Les tests seraient alors écrits non plus en PHP mais en Javascript. Ce framework permet de
créer des tests fonctionnels dont il est possible de suivre l’exécution et de debugger depuis le
navigateur. De cette façon, nous pourrions avoir l’intégralité des fonctions de l’application
testée à chaque mise à jour sur le dépôt GitLab.
6.2. Vers une amélioration de la qualité du code
Afin que la plateforme puisse entrer en service, il est nécessaire que le code soit
validé par la direction technique de Smile. Pour cela, nous avons été suivis par un membre
spécialisé en Symfony de cette direction technique. N’étant que deux développeurs juniors
dans l’équipe, il nous était impossible de faire valider nos demandes de fusion par d’autres
membres de l’équipe plus expérimentés. Nous postions donc nos demandes sur l’outil de
discussion du groupe : Mattermost. Durant les premiers temps, nous avions beaucoup de
remarques sur des éléments de programmation basiques. Cela pouvait être l’utilisation d’une
méthode de PHP, un comportement ou une bonne pratique de Symfony. À mesure que le
Page 28Master IAGL 2018-2019
projet avançait, nous avons donc pu emmagasiner ces remarques afin de monter en
compétence.
Cette montée en compétence se fait sentir dans le nombre et la nature des remarques
qui sont faites sur le code. En effet, en plus d’être moins nombreuses, elles se concentrent
d’avance sur des éléments plus pointus de programmation comme de l’optimisation par
exemple. Nous avons également profité de cette montée en compétence pour repasser sur le
code que nous avions écrit dans les premières étapes du développement. Ainsi, la création
d’une question ainsi que l’édition ont été complètement retravaillées. Les formulaires étaient
écrits en HTML pur. Le traitement se faisait entièrement dans le contrôleur correspondant.
Cela donnait des contrôleurs faisant environ 500 lignes chacun. Dorénavant, nous utilisons
les formulaires Symfony ce qui réduit considérablement le volume de code et augmente la
maintenabilité du code.
6.3. Une plateforme déjà en service
Un des moyens les plus efficaces pour savoir si une application répond au besoin des
utilisateurs est de la faire tester par ces derniers. Ainsi, la plateforme de test a subi plusieurs
phases de test successives.
La première phase fut une phase de test en interne. L'interface pour les
administrateurs ayant été validé tout au long du développement par une seule personne, il fut
nécessaire de la faire valider par un plus large panel d'utilisateur. Nous avons donc fait une
démonstration de la plateforme à la directrice des ressources humaines afin d'avoir son avis.
Nous avons eu de nombreux retours de sa part ainsi que d'autres recruteurs. Ces retours ont
été rassemblés dans un fichier Excel. Nous avons ainsi pu apporter de multiples améliorations
à la plateforme.
Page 29Master IAGL 2018-2019
Pour la partie candidat, nous avons donné l'accès à plusieurs experts techniques de
différentes agences. Nous avons donc récupéré des retours sur cette partie de l'application.
Les remarques étaient toutefois peu nombreuses, l'interface étant relativement simple et
limitée.
Fig 25 : Fichier regroupant l’ensemble des retours
Pour la deuxième partie de la phase de test, une partie de l'équipe de recrutement de
l'agence de Lyon a commencé à utiliser la plateforme pour faire passer des tests à de vrais
candidats. Durant cette phase, l'envoi automatisé de mail n'était pas encore disponible (le relai
d'envoi n'étant pas encore configuré par le système interne). Nous devions donc générer les
mots de passe des candidats et les communiquer à l'équipe de recrutement. Néanmoins,
l'expérience pour le candidat est extrêmement similaire. Le problème était donc
principalement le manque d'autonomie pour l'équipe de recrutement. Les retours de cette
phase de test sont très positifs pour le moment. Quelques améliorations ont été apportées à
l'export en PDF afin de gérer la pagination et d'afficher les exemples de code. Cette phase de
test est toujours en cours à l'heure actuelle. Il est prévu qu'elle dure jusqu'à la mise à
disposition d'un serveur dédié à l'application.
Page 30Master IAGL 2018-2019
Conclusion
Ce mémoire présente le travail effectué sur le projet de développement d'une
plateforme pour l'équipe de recrutement de la société Smile.
Cette mise en place s'est articulée autour de différents points : Réaliser un back-
office pour la gestion de la plateforme — Réaliser un front-office pour le passage des tests
— Créer une suite de test pour vérifier le bon fonctionnement de la plateforme — Déployer
la plateforme pour obtenir des retours de la part des utilisateurs finaux. Par la suite, la
plateforme devrait permettre de proposer des questions où il faut répondre en proposant des
morceaux de code pour évaluer le candidat sur des cas réels, et non uniquement sur des
questions de connaissances.
Le développement de l'application pour le recrutement aura également permis la mise
en place de projets pour les nouveaux arrivants. À l'heure actuelle, il en existe un pour
Symfony et un autre pour Magento[22]. Celui portant sur Symfony se compose des premières
tâches de développement de la plateforme pour l'équipe de recrutement. Un canal de
discussion dédié à la revue de code dans l'outil de communication de la société a également
été mis en place. Son objectif initial était de nous permettre d'avoir plus de revue de code sur
notre application. Par la suite, il a également été utilisé pour la revue de code des projets pour
les nouveaux arrivants. Cette initiative m'a ainsi donné l'occasion de pratiquer et de
m'améliorer dans la pratique de la revue de code.
Ce stage m'a permis d'améliorer mes compétences dans la compréhension du besoin
d'un client. Partir d'un cahier des charges simple pour le transformer en une plateforme
complète, qui sera utilisée sur la durée, est une expérience enrichissante aussi bien
techniquement qu'humainement.
Page 31Master IAGL 2018-2019
Bibliographie
1. Symfony. URL : https://symfony.com/
2. Coding Game. URL : https://www.codingame.com/
3. Hacker Rank. URL : https://www.hackerrank.com/
4. RGPD (Règlement général sur la protection des données). URL : https://www.cnil.fr/fr/
rgpd-par-ou-commencer
5. Gitlab. URL : https://about.gitlab.com/
6. MVP (Minimum Viable Product). URL : https://www.agilealliance.org/glossary/mvp/
7. MVC (Modèle Vue Contrôleur). URL : https://en.wikipedia.org/wiki/Model-view-
controller
8. Twig. URL : https://twig.symfony.com/
9. ReactJS. URL : https://fr.reactjs.org/
10. JQuery. URL : https://jquery.com/
11. SortableJS. URL : https://github.com/SortableJS/Sortable
12. ChartJS. URL : https://www.chartjs.org/
13. HighlightJS. URL : https://highlightjs.org
14. Bootstrap. URL : https://getbootstrap.com/
15. MySQL. URL : https://www.mysql.com/fr/
16. Doctrine. URL : https://www.doctrine-project.org/index.html
17. PHP Mess Detector. URL : https://phpmd.org/
18. Security Checker. URL : https://github.com/sensiolabs/security-checker
19. PHP Unit. URL : https://phpunit.de/
20. Panther. URL : https://github.com/symfony/panther
21. Cypress. URL : https://www.cypress.io/
22. Magento . URL : https://magento.com/
Page 32Vous pouvez aussi lire
