Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientiﬁque
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
RAPPORT DE STAGE DE FIN D’ÉTUDES
Présenté en vue de l’obtention du
Diplôme National de Licence Fondamentale en Sciences et Technologies
Mention : Science de l’Informatique
Spécialité : Science de l’Informatique
Par
Ines HAMROUNI Yasmine LACHHEB
Conception et mise en place d’une
plate-forme de gestion des stagiaires
Encadrant professionnel :
Encadrant académique :
Monsieur Mohamed BAHY
Monsieur Riadh ZAAFRANI
Chef de projet SI
Maître Assistant
Réalisé au sein de la Banque Internationale Arabe de Tunisie BIAT
Année Universitaire 2017 - 2018

J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une
soutenance.
Encadrant professionnel, Mohamed BAHY
Signature et cachet
J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une
soutenance.
Encadrant académique, Riadh ZAAFRANI
Signature

Dédicaces
Du profond de mon cœur, je dédie ce travail
À mes chers parents,
Qui demeurent pour moi un modèle d’intégrité et de rigueur.
Aucune dédicace ne saurait être assez éloquente pour exprimer l’amour et le
respect que j’ai toujours pour vous.
Que ce modeste travail soit pour vous une reconnaissance envers tous vos
sacrifices et vos efforts fournis jour et nuit pour faire de moi ce que je suis,
je dois à vous toute ma réussite.
Puisse Dieu, le tout-puissant, vous gratifie d’une longue vie débordante de santé
et de bonheur.
À mes adorables sœurs Amal et Yasmine,
Qui n’ont jamais cessé de m’assister, de me soutenir et de m’encourager.
En témoignage de mon affection fraternelle, mon attachement éternel et ma
reconnaissance.
Je vous aime mes chéries, et je vous souhaite un avenir brillant.
Que Dieu vous bénisse et vous préserve que de la réussite.
À tous ceux que j’aime,
À tous ceux qui m’aiment et me supportent.
Ines HAMROUNI
i

Dédicaces
Aimablement, je dédie ce modeste travail
À mes chers parents,
Ceux qui représentent pour moi un magniﬁque modèle de labeur et de
persévérance,
nulle dédicace ne peut témoigner de l’amour, de l’estime et du respect que je
leur porte.
À mon frère,
Mon ﬁdèle compagnon, celui qui ne cesse jamais de me rendre heureuse et de
me motiver pour aller en avant.
À mes très chers amis Zied, Alia et Ines
En témoignage de l’amitié et de l’amour qui nous unissent, et des souvenirs des
moments merveilleux que nous avons passés.
À toute ma famille et tous ceux qui m’entourent, que je ne saurai
terminer ma dédicace sans les citer.
Yasmine LACHHEB
ii

Remerciements
Nous avons un grand plaisir de garder cette page en signe de gratitude et de
profonde reconnaissance à tous ceux qui nous ont aidé de près ou de loin à la
réalisation de ce projet.
Nous sommes très reconnaissantes à notre encadrant à l’institut supérieur d’in-
formatique, Monsieur Riadh ZAAFRANI, d’avoir accepté de diriger ce tra-
vail sans oublier ses conseils et sa participation régulière au cheminement de ce
rapport avec rigueur et bienveillance.
Nous tenons à remercier Monsieur Mohamed BAHY, notre encadrant pro-
fessionnel, pour sa disponibilité tout au long de ce stage, ses judicieux conseils et
ses encouragements, qu’il trouve ici notre respectueuse reconnaissance.
Nous tenons à remercier les membres de jury de nous avoir oﬀert l’occasion de
présenter notre projet devant leur honorable assistance et d’avoir accepté d’évaluer
ce travail.
iii

Table des matières
Introduction générale 1
1 Cadre général du projet 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Le Département des Systèmes d’information . . . . . . . . . . . . . . . . 3
1.1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . 4
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Le concept agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Présentation de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . 6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Étude et analyse globale du projet 9
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . 12
2.2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Sprint0 : Mise en place de l’environnement matériel et logiciel 21
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iv

3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Outil de gestion de versions . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5 Outil de manipulation des documents électroniques . . . . . . . . . . . . 24
3.2.6 Environnement de Système de Gestion de Base de Données . . . . . . . . 24
3.3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Protocoles de messagerie utilisés . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.2 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Sprint1 : Authentification et gestion des utilisateurs et des offres 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Sprint2 : Traitement des candidatures des stagiaires 48
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v

5.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Sprint3 : Aﬀectation des stagiaires 65
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Sprint4 : Gestion des stages et statistiques 81
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
vi

7.4 Phase du clôture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Conclusion générale 97
Bibliographie 98
Annexes 99
Annexe A. Fonctions de manipulation des données . . . . . . . . . . . . . . . . . . . . 99
Annexe B. Exemples de fonctions relatives au système « SI Mailing » . . . . . . . . . 100
Annexe C. Authentiﬁcation et génération des ﬁchiers PDF . . . . . . . . . . . . . . . 101
vii

Table des figures
1.1 Logo de la Banque Internationale Arabe de Tunisie BIAT . . . . . . . . . . . . . 3
1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Vue globale « Scrum » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Estimation théorique des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 l’architecture 3-tiers de notre application . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Principe des échanges de messages électroniques . . . . . . . . . . . . . . . . . . 29
3.4 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Diagramme de cas d’utilisation global du sprint1 . . . . . . . . . . . . . . . . . . 34
4.2 Raffinement du cas d’utilisation « Gérer utilisateurs » . . . . . . . . . . . . . . . 34
4.3 Diagramme de séquence du cas d’utilisation « S’authentifier » . . . . . . . . . . 38
4.4 Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur » . . . . . . 39
4.5 Diagramme de séquence du cas d’utilisation « Modifier un utilisateur » . . . . . 40
4.6 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.8 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Interface de la liste des offres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11 Interface de modification d’une offre de stage . . . . . . . . . . . . . . . . . . . . 44
4.12 Interface d’un profil utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 Interface du contenu d’une offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Raffinement du cas d’utilisation « Traiter demandes reçues » . . . . . . . . . . . 51
5.3 Raffinement du cas d’utilisation « Présélectionner candidats » . . . . . . . . . . 53
5.4 Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues » . . . . 55
5.5 Diagramme de séquence du cas d’utilisation « Affecter Candidat » . . . . . . . . 56
viii

Table des figures
5.6 Diagramme de séquence du cas d’utilisation « Afficher profil candidat » . . . . . 57
5.7 Diagramme de classes du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.8 Interface de la liste des demandes reçues et non traitées . . . . . . . . . . . . . . 59
5.9 Interface du profil candidat coté responsable . . . . . . . . . . . . . . . . . . . . 59
5.10 Interface du profil candidat coté encadrant . . . . . . . . . . . . . . . . . . . . . 60
5.11 Interface choisir candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Interface d’affectation des stagiaires . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.13 Mail de réponse à une demande de stage . . . . . . . . . . . . . . . . . . . . . . 62
5.14 Accusé de réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Raffinement du cas d’utilisation « Gérer suggestions » . . . . . . . . . . . . . . . 69
6.3 Raffinement du cas d’utilisation « Gérer propositions d’encadrement » . . . . . . 69
6.4 Raffinement du cas d’utilisation « Gérer affectations » . . . . . . . . . . . . . . 71
6.5 Diagramme d’activité du cas d’utilisation « Consulter demandes suivies » . . . . 73
6.6 Diagramme de séquence du cas d’utilisation « Accepter d’encadrer » . . . . . . . 74
6.7 Diagramme de séquence du cas d’utilisation « Accepter prise de fonction » . . . 75
6.9 Interface de la liste des demandes suivies . . . . . . . . . . . . . . . . . . . . . . 77
6.10 Interface des demandes en attente . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.11 E-mail d’acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.1 Diagramme de cas d’utilisation global du sprint 4 . . . . . . . . . . . . . . . . . 84
7.2 Raffinement du cas d’utilisation « Gérer prolongations » . . . . . . . . . . . . . 85
7.3 Raffinement du cas d’utilisation « Gérer stages encadrés » . . . . . . . . . . . . 86
7.4 Diagramme de séquence du cas d’utilisation « Consulter liste demandes de pro-
longation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.5 Digramme de séquence du cas d’utilisation « Évaluer stagiaire » . . . . . . . . . 89
7.7 Interface de la liste des stages en cours . . . . . . . . . . . . . . . . . . . . . . . 91
7.8 Interface de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.9 Envoi de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.10 Pop-up de prolongation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.11 Interface de la liste des demandes de prolongation . . . . . . . . . . . . . . . . . 93
ix

Table des figures
7.12 Interface des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.13 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.1 Fonction PL/SQL « addDemande » . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2 Fonction d’ajout de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.3 Fonction de récupération des stages non prolongés . . . . . . . . . . . . . . . . . 100
A.4 Fonction de vérification de l’existance d’un rapport dans la base de données . . . 100
B.1 Lecture et envoi des e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.2 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1 Code d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.2 Code de génération du PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
x

Liste des tableaux
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Équipe et rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Description des machines de développement . . . . . . . . . . . . . . . . . . . . 22
4.1 Backlog du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Description textuelle du cas d’utilisation
« Ajouter un utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
« Modifier un profil utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Types d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Test fonctionnel du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
« Affecter candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
« Afficher profil candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Test fonctionnel du deuxième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 63
« Accepter d’encadrer » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
« Accepter prise de fonction » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 Test fonctionnel du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 79
xi

Liste des tableaux
« Consulter liste demandes de prolongation » . . . . . . . . . . . . . . . . . . . 85
« Évaluer stagiaire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 Test fonctionnel du quatième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 94
xii

Glossaires
— AJAX = Asynchronous JavaScript And XML
— BIAT = Banque Internationale Aarabe de Tunisie
— CSS = Cascading Style Sheets
— DC = Document Cloud
— DSI = Département du Systèmes d’Information
— HTML = HyperText Markup Language
— IMAP = Internet Message Access Protocol
— IT = Technologies de l’Information
— JS = Java Script
— MVC = Modèle Vue Contrôleur
— MoSCoW= Must Should Could Won’t
— NT = Nouvelle Technologie
— PDF = Portable Document Format
— PHP = Hypertext Preprocessor
— PL = Procedural Language
— RH = Ressources Humaines
— SASS = Syntactically Awesome StyleSheets
— SE = Système d’Exploitation
— SGBD = Système de Gestion de Base de Données
— SGBDR = Système de Gestion de Base de Données Relationnelle
— SI = Système Informatique
— SMTP = Mail Transfer Protocol
— SQL = Structured Query Language
— UC = Use Case
— UML = Uniﬁed Modeling Language
— URL = Uniform Resource Locator

Introduction générale
À l’époque actuelle, et grâce à l’évolution des nouvelles technologies d’information et de
communication, rares sont les personnes qui nient que la digitalisation des documents et la
diffusion de l’information en mode numérique améliorent la flexibilité et l’agilité des entreprises.
Dans cette perspective, la Banque internationale arabe de Tunisie (BIAT), s’est dit prête
à abandonner la manière archaïque de gestion manuelle des stages, et à s’investir afin d’avoir
une solution informatique permettant d’élargir les canaux de communication avec les stagiaires,
et de suivre régulièrement les nombreux changements effectués sur leurs candidatures, ce qui
permettra d’améliorer les conditions de travail au sein du service des ressources humaines. C’est
dans ce contexte que la direction d’ingénierie IT réseau et sécurité de la BIAT, nous a confié la
tâche de mise en place d’une solution permettant la dématérialisation du processus de gestion
des stagiaires, en réalisant une plate-forme qui collabore avec un service de messagerie, ce qui
permettra de simplifier le traitement des demandes des candidats envoyées sous la forme de
courriers électroniques.
Le présent rapport se subdivise en sept chapitres présentant les différents stades par lesquels
nous allons passer pour accomplir ce projet.
Le premier chapitre sert à situer le projet dans son contexte général, à savoir, l’organisme
d’accueil, la description des contraintes conduisant à l’élaboration de cette solution, ainsi que
la spécification de la méthodologie adaptée. Dans le second chapitre, nous allons dévoiler les
besoins métiers et nous allons mettre en place le backlog produit tout en le clôturant avec
une planification des sprints. Dans le troisième chapitre intitulé « Sprint 0 », nous allons nous
intéresser à la présentation de l’environnement de travail ainsi que l’architecture de notre projet.
C’est à ce niveau que nous allons exposer les choix techniques et la description du système « SI
Mailing ». Quand aux trois derniers chapitres, nous allons les consacrer à la présentation des
autres sprints de notre projet. Chaque sprint, comporte trois phases majeures : la phase de la
préparation, celle de la mise en oeuvre et celle dediée à la finalisation.
La dernière partie du rapport sera dédiée à la conclusion générale qui résume les grands
traits de ce travail et présente les perspectives futures de perfectionnement de la plate-forme
élaborée.
1

Chapitre 1
Cadre général du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapitre 1. Cadre général du projet
Introduction
Avant d’aborder l’étude approfondie de notre stage de fin d’études, nous allons décrire
brièvement à travers ce premier chapitre l’organisme au sein duquel se déroule notre stage.
Nous allons présenter par la suite une critique de l’existant afin de dévoiler notre solution
proposée, et pour clôturer, nous allons consacrer la dernière partie à la présentation de la
méthodologie adaptée pour la gestion de ce travail.
1.1 Organisme d’accueil
Au bout de quarante années d’existence, la banque internationale arabe de Tunisie « BIAT
», lancée le 24 février 1976, est devenue l’une des plus importantes institutions financières en
Afrique du Nord et un acteur de référence en Tunisie en termes de part de marché et de ré-
sultats financiers. Banque universelle offrant à sa clientèle de particuliers, tunisiens résidents à
l’étranger, professionnels, petites, moyennes, grandes entreprises et institutionnels, une gamme
de produits et services à la fois complète et innovante. La BIAT constitue aujourd’hui un groupe
bancaire diversifié dans les domaines de l’assurance, de la gestion d’actifs, du capital investisse-
ment, de l’intermédiation boursière et du conseil à l’international. Appuyant son développement
sur la proximité et l’engagement sociétal, elle met son expertise au profit de ses clients, de ses
partenaires et de l’économie du pays. [1]
Figure 1.1: Logo de la Banque Internationale Arabe de Tunisie BIAT [1]
1.1.1 Le Département des Systèmes d’information
La BIAT est constituée d’une direction générale qui comporte 11 départements ainsi que 4
pôles renfermant 41 directions. Et parmi ces départements, on trouve le département Systèmes
d’information (DSI), et plus précisément la direction ingénierie IT réseau et sécurité où notre
stage s’est déroulé.
Grâce à ses solutions proposées, Le DSI jouit d’une grande importance au sein de la banque,
il a comme objectifs de :
• Développer des solutions informatiques ;
3

• Assurer la bonne planification des ressources, le partage des connaissances et l’enrichis-
sement des compétences ;
• Assurer en permanence la sécurité technique des systèmes informatiques ;
• Produire des applications destinées aux clients et aux différents services de la banque ;
• Exploitation de l’infrastructure informatique au sein de la BIAT.
1.1.2 Organigramme hiérarchique du DSI
Une hiérarchisation du DSI est illustrée dans la figure 1.2 suivante :
Figure 1.2: Organigramme hiérarchique du DSI
1.2 Étude de l’existant
1.2.1 Description de l’existant
Depuis ses débuts, la BIAT accueille plusieurs stagiaires de différentes spécialités pour ac-
complir soit un stage ouvrier, soit un stage de fin d’études dans le but de contribuer activement
à leurs formations.
Actuellement, il est nécessaire que les candidats se présentent au sein de la banque pour
postuler leurs demandes de stage sous la forme d’un dossier contenant un CV, une copier de la
CIN, ses relevés de notes, etc.
Ce dossier est traité, puis archivé par le responsable des ressources humaines dès que le
stagiaire termine son stage.
4

Compte tenu de l’absence d’un outil informatique, la sélection des stagiaires et la gestion
de leurs candidatures se fait manuellement.
1.2.2 Problématique
La mission de gestion des stages au sein de la BIAT est devenue très compliquée vu le
nombre important des candidatures reçues.
Ainsi, nous avons recensé une liste de problèmes :
• Recherche fastidieuse des documents des stagiaires ;
• Consultation non périodique des candidatures ;
• Risque d’incohérence et de perte d’informations très élevé ;
• Ralentissement du suivi des stages ;
• Redondance de l’information ;
• Énorme perte de temps ;
• Absence des statistiques ;
• Classement des dossiers compliqué.
1.2.3 Solution proposée
Les problèmes dégagés lors de l’analyse de la situation actuelle rendent nécessaire l’élabo-
ration d’une solution informatisée aﬁn de faciliter la gestion des stagiaires.
Cette solution consiste à développer une plate-forme de gestion collaborative, qui a comme
principaux objectifs :
• De faciliter l’accès et la consultation des informations de chaque stagiaire ;
• De faciliter le contact entre le responsable RH et les stagiaires en réalisant un système
permettant l’échange des e-mails ;
• De garder toujours une trace de chaque dossier et de chaque demande de stage, pour
pouvoir générer par la suite des statistiques.
Étant donné que les stagiaires ne doivent pas avoir un accès direct à la plate-forme pour
des raisons de sécurité, nous avons opté pour les courriers électroniques comme un outil de
communication.
5

1.3 Méthodologie de travail
Une méthodologie est essentiellement un outil de planification qui aide à la mise en œuvre
d’un projet, elle nous fournit un cadre et des instructions précises pour gérer efficacement notre
équipe et assurer un bon déroulement des différentes phases du projet.
Pour réussir à mener à bien le processus de développement et par conséquent l’aboutissement
d’un bon résultat, il est important de suivre une méthodologie adaptée.
1.3.1 Le concept agile
Le choix d’une méthodologie appropriée dépend de nombreux paramètres tels que les ca-
ractéristiques du projet et ses contraintes. De ce fait, nous avons choisi d’adapter une méthode
incrémentale et itérative plutôt qu’une méthode classique, vu que le processus de la réalisation
de notre projet était imprévisible et nécessite les réorientations du Product Owner.
Parmi les méthodes basées sur le pragmatisme et le développement itératif, nous pouvons
distinguer les méthodes agiles très populaires en usage aujourd’hui à travers le monde. [2] Une
méthode agile définit un cadre moins rigide que les méthodes traditionnelles, elle met l’accent
sur la pratique de la réalisation du produit plus que sur la théorie, ce qui permet de détecter
les pénalités et les problèmes pour entreprendre des actions correctrices le plus tôt possible.
Grâce à l’agilité, on se retrouve aussi avec un focus sur la simplicité, l’intelligence collective
et également sur la communication et la collaboration concrétisées par la présence du client au
cœur du projet et par l’esprit d’équipe partagé par les acteurs métiers et les développeurs.
1.3.2 Présentation de la méthodologie Scrum
La méthode Scrum fait partie du groupe des méthodes agiles. Elle représente un Frame-
work de gestion et d’organisation de projets, reconnu pour sa flexibilité, son efficacité et son
empirique. L’utilisation de ce Framework vise à satisfaire au mieux les besoins du client en
s’appuyant sur plusieurs points :
La planification des événements :
• Le Sprint :
Il s’agit d’un incrément qui consiste à développer une partie du logiciel en une période
6

inférieure à 30 jours. Durant cette itération l’équipe de développement se concentre sur
la réalisation les fonctionnalités demandées ;
• Planification du Sprint (Sprint Planning) :
Avant chaque sprint, une réunion de planification s’organise. Ce planning sélectionne dans
le backlog du produit les exigences les plus prioritaires pour le client ;
• Mêlée quotidienne (Daily Scrum Meetings) :
C’est une réunion quotidienne de 15 minutes qui vise à évaluer l’avancement du travail et
à garder l’équipe concentrée sur l’objectif du sprint ;
• Revue du Sprint (Sprint Review) :
À chaque fin de sprint, l’équipe présente l’incrément logiciel développé au client, celui-ci
valide les différents points du backlog et indique les changements à opérer ; [3]
• Rétrospective du Sprint (Sprint Retrospective) :
C’est une pratique qui permet d’améliorer l’équipe et le processus de développement quo-
tidiennement.
La définition des artefacts Scrum :
• Backlog du produit :
Il s’agit d’un référentiel des exigences et des fonctionnalités, fourni et tenu à jour par le
Product Owner ; [3]
• Backlog du sprint :
Un sous ensemble du backlog produit qui contient les fonctionnalités à mettre en oeuvre
durant le sprint ;
• Incrément du produit :
La sommation de toutes les fonctionnalités terminées pendant un sprint ;
• Le burndown chart du sprint(Sprint Burn-Down Chart) :
Diagramme indiquant les tâches restantes avant la fin du Sprint sur un axe du temps. [3]
La figure 1.3 présente une vue globale du cycle de vie de la méthodologie « Scrum ».
7

Figure 1.3: Vue globale « Scrum » [4]
Conclusion
Après avoir présenté l’organisme d’accueil, introduire la solution proposée et expliquer la
méthodologie optée pour le travail, nous allons maintenant essayer de répondre à la question
« qui fait quoi dans le système et comment ? » qui fera l’objet du deuxième chapitre étude et
analyse globale du projet.
8

Chapitre 2
Étude et analyse globale du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapitre 2. Étude et analyse globale du projet
Introduction
Au niveau de ce chapitre, nous allons aborder dans un premier temps la partie de la capture
des besoins, où nous allons identifier les différents acteurs et dégager les besoins fonctionnels
et non fonctionnels auxquels doit répondre notre solution. Dans un second temps, nous allons
modéliser toutes les fonctionnalités par un diagramme de cas d’utilisation global. Enfin, nous
allons piloter notre projet avec la méthodologie Scrum.
2.1 Capture des besoins
2.1.1 Identification des acteurs
Chaque système informatique met des fonctionnalités et des informations pertinantes à la
disposition de ses acteurs qui leur permettent d’interagir avec.
Ces acteurs peuvent être classés comme l’indique le tableau 2.1 :
Tableau 2.1: Identification des acteurs
Acteurs secondaires
SI Mailing Cet acteur n’interagit pas directement avec le système, mais sollicité
pour des informations complémentaires.
Acteurs principaux
Administrateur C’est l’acteur le plus haut dans la hiérarchie dans le système, il gère les
responsables et les encadrants en leur affectant les rôles nécessaires.
Responsable RH Cet acteur se charge principalement de gérer les stages en faisant l’étude
des demandes des stagiaires et des offres déposées par les encadrants.
Encadrant Cet acteur a pour rôle de déposer les offres de stage, d’accepter ou de
refuser les affectations et d’évaluer les stagiaires.
On peut présenter l’environnement de notre système et préciser le nombre d’instances de chacun
de ces acteurs par un diagramme de contexte statique illustré par la figure 2.1 ci-dessous.
10

Figure 2.1: Diagramme de contexte statique
2.1.2 Identification des besoins fonctionnels
La phase de la spécification des besoins fonctionnels est indispensable pour que les résultats
de la réalisation de notre plate-forme soient conformes aux attentes du « Product owner ».
Ainsi, Les différentes fonctionnalités que nous envisageons de mettre en place dans le cadre
de ce projet, peuvent être regroupées dans les points suivants :
• Permettre aux encadrants de gérer les propositions d’encadrement, entre autres l’accep-
tation ou le refus d’une demande en attente ;
• Permettre aux administrateurs de gérer les utilisateurs et leur associer des privilèges ;
• Permettre à tous les utilisateurs de consulter les notifications ainsi que les statistiques ;
• Permettre aux responsables RH et aux encadrants de consulter les demandes refusées et
de visualiser leurs contenus ;
• Permettre aux responsables RH de traiter les différentes demandes reçues envoyées de la
part des stagiaires ;
• Permettre aux responsables RH de gérer les suggestions de stages des encadrants ;
• Permettre aux responsables RH d’accepter ou de refuser d’affecter un candidat ;
• Permettre aux encadrants de présélectionner des candidats dans le but de les encadrer ;
• Permettre aux chacun des encadrants et des responsables RH de consulter les stages
archivés et interrompus ;
• Permettre aux responsables RH d’accepter ou de refuser les demandes de prolongation
des encadrants ;
• Permettre aux encadrants de gérer les stages qu’ils encadrent et de suivre leurs avance-
ments ;
11

• Permettre aux encadrants de déposer, de modifier ou de supprimer des offres de stage ;
• Permettre aux responsables RH de consulter toutes les offres de stages publiées.
2.1.3 Identification des besoins non fonctionnels
Les besoins non fonctionnels permettent l’amélioration de la qualité logicielle de notre sys-
tème. Ils agissent comme des contraintes à prendre en considération pour mettre en place une
solution adéquate à ce qui est attendu, et pour éviter plusieurs incohérences dans le système.
Notre application doit nécessairement répondre aux besoins suivants :
Convivialité :
L’application doit être facile à utiliser. Elle devra offrir des interfaces conviviales, simples et
ergonomiques.
Performance :
Vu l’ampleur des données qu’on va stocker, l’application doit répondre aux besoins des utili-
sateurs d’une manière optimale en termes de temps de réponse, de traitement et de chargement
des données.
Maintenabilité :
Le code doit être lisible, commenté et bien structuré afin d’obéir à l’évolution et aux différents
changements des besoins.
2.2 Modélisation des besoins
c Diagramme de cas d’utilisation global
Le diagramme illustré par la figure 2.2 décrit les différents besoins fonctionnels de notre
application, chaque cas d’utilisation représente une fonctionnalité offerte par le système à ses
utilisateurs.
12

Figure 2.2: Diagramme de cas d’utilisation global
2.3 Pilotage du projet avec Scrum
2.3.1 Équipe et rôles
La méthodologie Scrum fait intervenir trois rôles principaux qui sont :
• Product owner : C’est le représentant des clients, il déﬁnit l’ordre dans lequel les
fonctionnalités seront développées ;
• Scrum Master : Il agit comme un « Coach » et non pas comme un dirigeant, son
rôle est d’aider l’équipe à avancer de manière autonome en cherchant en permanence à
s’améliorer ; [5]
• Équipe : l’équipe est constituée des personnes qui seront chargées d’implémenter les
13

besoins du client. Elle doit tout faire pour délivrer le produit dans les délais prévus ;
• Intervenants : ils observent et donnent des conseils à l’équipe.
Ces participants sont illustrés par le tableau 2.2 :
Tableau 2.2: Équipe et rôles Scrum
Personnes Rôles Scrum
Mr. Mohamed BEHY Product Owner
Mr. Mohamed BEHY Scrum Master
ines HAMROUNI, yasmine LACHHEB Équipe
Mr. Riadh ZAAFRANI Intervenant
2.3.2 Backlog du produit
Le backlog du produit est l’artefact le plus important de Scrum, il consiste à présenter la
liste des fonctionnalités ou encore les « User Stories » constituant le produit souhaité. Chaque
fonctionnalité est caractérisée par un numéro ID, un thème, une priorité et une estimation de
l’effort nécessaire à une équipe pour l’implémenter. Nous choisissons de représenter l’estimation
sous la forme de points relatifs en utilisant la suite de Fibonnacci afin d’éviter les confusions
dues aux estimations trop proches et de représenter la priorité suivant la méthode « MoSCoW
» qui a pour signification :
• M : « Must have », toutes les fonctionnalités qui sont indispensables et nécessaires ;
• S : « Should have », les tâches qui sont essentielles, mais pas obligatoires, elles seront
développées une fois que celles de la catégorie Must ont été livrées ;
• C : « Could have », se sont des tâches qu’ont les fait seulement s’il reste assez de temps ;
• W : « Won’t have this time but would like in the future », se sont les tâches supplémen-
taires, très secondaires.
Le tableau 2.3 résume le backlog du produit de notre application.
14

Tableau 2.3: Backlog produit
ID Théme ID User stories Priorité Estimation
1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais m’au-
thentifier pour accéder à mon espace.
M 8
2 Consulter
statistiques
2.1 En tant qu’Utilisateur je voudrais
consulter les statistiques.
S 3
3 Gérer utili-
sateurs
3.1 En tant qu’Administrateur je voudrais
consulter la liste des utilisateurs.
M 2
consulter le profil d’un utilisateur.
S 2
ajouter un profil utilisateur.
M 5
modifier le profil d’un utilisateur.
M 5
supprimer un utilisateur.
M 3
trier la liste des utilisateurs.
W 1
chercher un utilisateur.
C 1
4 Consulter
demandes
refusées
4.1 En tant que Personnel je voudrais
consulter la liste des demandes refusées
S 2
consulter le contenu d’une demande.
C 1
4.3 En tant que Personnel je voudrais cher-
cher une demande.
C 1
5 Consulter
stages archi-
vés
consulter la liste des stages archivés.
M 2
15

consulter le profil d’un stagiaire archivé.
S 1
5.3 En tant que Personnel je voudrais impri-
mer les documents des stagiaires.
W 2
5.4 En tant que Personnel je voudrais cher-
cher un stage archivé.
C 1
6 Consulter
stages inter-
rompus
consulter la liste des stages interrompus.
S 2
consulter le profil du stagiaire inter-
rompu
C 1
7 Traiter
demandes
reçues
7.1 En tant que Responsable RH je voudrais
consulter la liste des demandes non trai-
tées
M 2
consulter le contenu d’une demande re-
çue.
M 5
affecter un candidat à un sujet.
M 3
refuser un candidat.
M 2
actualiser la liste des demandes reçues.
M 13
télécharger un document du dossier can-
didat.
C 3
chercher une demande.
C 1
8 Gérer sug-
gestions
consulter les demandes suggérées.
M 2
16

consulter le profil d’un stagiaire.
S 1
accepter une suggestion d’affectation.
M 5
refuser une suggestion d’affectation.
M 2
9 Gérer affec-
tations
consulter la liste des demandes suivies.
M 13
C 1
trier les demandes.
W 1
visualiser le dossier d’un stagiaire.
S 2
accepter une prise de fonction.
M 8
refuser une prise de fonction.
M 3
10 Présélectionner
candidat
10.1 En tant qu’Encadrant je voudrais
consulter la liste des candidatures re-
çues.
M 2
consulter le profil d’un candidat.
M 2
10.3 En tant qu’Encadrant je voudrais choisir
un candidat.
M 3
10.4 En tant qu’Encadrant je voudrais cher-
cher un candidat.
C 1
11 Gérer propo-
sitions d’en-
cadrement
consulter la liste des demandes en at-
tente.
M 2
17

11.2 En tant qu’Encadrant je voudrais trier
les demandes en attente.
W 1
cher un candidat.
C 1
11.4 En tant qu’Encadrant je voudrais aﬃ-
cher le proﬁl d’un stagiaire .
S 1
11.5 En tant qu’Encadrant je voudrais accep-
ter d’encadrer un candidat.
M 5
11.6 En tant qu’Encadrant je voudrais refuser
d’encadrer un candidat .
M 3
12 Gérer pro-
longations
consulter la liste des demandes de pro-
longation.
M 2
consulter les stages prolongés.
M 2
consulter les stages non prolongés.
M 2
consulter le dossier d’un stagiaire cou-
rant.
S 1
télécharger un document du dossier sta-
giaire.
C 2
accepter une prolongation.
M 2
refuser une prolongation.
M 2
13 Gérer stages
encadrés
consulter les stages en cours d’encadre-
ment.
M 2
18

cher un stage.
C 1
consulter le dossier d’un stagiaire.
S 1
13.4 En tant qu’Encadrant je voudrais inter-
rompre un stage.
M 2
13.5 En tant qu’Encadrant je voudrais de-
mander une prolongation de stage.
M 3
13.6 En tant qu’Encadrant je voudrais éva-
luer un stagiaire.
M 8
14 Gérer sujets
stages
consulter la liste des sujets
M 2
cher un sujet.
C 1
14.3 En tant qu’Encadrant je voudrais ajou-
ter un sujet.
M 3
14.4 En tant qu’Encadrant je voudrais modi-
fier un sujet.
M 3
14.5 En tant qu’Encadrant je voudrais sup-
primer un sujet.
M 2
15 Consulter
notifications
15.1 En tant qu’Utilisateur je voudrais
consulter les notifications reçues
C 5
16 Consulter
offres de
stage
consulter les offres proposées.
M 2
consulter le contenu d’une offre propo-
sée.
M 2
19

2.3.3 Planification des sprints
La réunion de la planification des sprints est l’un des évènements Scrum le plus important,
puisqu’elle rythme tout le projet et sert à bien dérouler les différents sprints.
À travers cette réunion, nous évoquons le planning de notre travail qui s’est étalé sur une
période de trois mois avec une estimation de deux à trois semaines pour chaque sprint.
La Figure 2.3 représente l’estimation théorique des différents sprints.
Figure 2.3: Estimation théorique des sprints
Conclusion
Tout au long de ce chapitre, nous avons détaillé les différents besoins ainsi que l’interaction
des acteurs avec le système. Par la suite nous avons choisi d’identifier l’équipe de travail et
de définir notre backlog du produit qui nous a permis de préparer un terrain favorable pour
les prochaines phases et de déduire la planification des sprints de notre plate-forme. Dans le
chapitre suivant, nous allons commencer par le sprint0 qui présente notre environnement de
travail et décrit notre acteur système « SI Mailing ».
20

Chapitre 3
Sprint0 : Mise en place de
l’environnement matériel et logiciel
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
Introduction
Ce chapitre est consacré à la présentation de l’architecture matérielle et logicielle de notre
application, des différents outils qui constituent l’environnement de travail et des différentes
technologies que nous allons utiliser tout au long de ce projet. Quant à la dernière partie, elle
sera dédiée à la description de l’élaboration du système «SI Mailing», jouant le rôle d’un acteur
secondaire.
3.1 Environnement materiel
Nous allons identifier dans le tableau 3.1 les outils matériels utilisés pour la réalisation de
notre plate-forme :
Tableau 3.1: Description des machines de développement
Ordinateur portable Lenovo
Processeur Intel R CoreTM
i7-7500U CPU @ 2.70GHz 2.90GHz
Mémoire 8,00 Go
Disque dur 1 To
Circuit graphique NVIDIA R GeForce R 940MX
Système d’exploitation Windows 10 Entreprise 64 bit
Ordinateur portable Asus
Processeur Intel R CoreTM
i7-5500U CPU @ 2.40GHz 2.40GHz
Mémoire 8,00 Go
Disque dur 1 To
Circuit graphique NVIDIA R GeForce R 920M
Système d’exploitation Windows 10 Entreprise 64 bit
22

3.2 Environnement logiciel
3.2.1 Système d’exploitation
c Windows 10
Le successeur de Windows 8.1 est un SE de la famille Windows NT
développé par la société américaine Microsoft. [6]
3.2.2 Outils de développement
c PhpStorm
Est un éditeur performant destiné pour PHP, HTML et JS, édité
par JetBrains. Il simpliﬁe l’écriture du code, l’intégration d’un dé-
bogueur et l’interfaçage avec un outil de gestion de versions ou
d’administration de bases de données.
c Oracle SQL Developer
Un environnement de développement intégré multiplate-forme,
fourni gratuitement par Oracle Corporation et utilisant la tech-
nologie Java. C’est un outil graphique permettant d’interroger des
bases de données Oracle à l’aide du langage SQL. [7]
c ShareLaTeX
Un éditeur LaTeX en ligne, permet de créer et de partager un
document latex en temps réel et de le compiler en PDF.
23

3.2.3 Outil de conception
c Visual Paradigm for UML
Est un logiciel permettant aux programmeurs de mettre en place
des diagrammes UML. Disposant d’un outil créant des différents
types de schémas comme les diagrammes de cas d’utilisation, de
séquences et plein d’autres diagrammes. [8]
3.2.4 Outil de gestion de versions
c Bitbucket
Est un service web d’hébergement et de gestion de développement
logiciel utilisant les logiciels de gestion de versions Git. Il permet de
mieux collaborer en distribuant les fichiers à chaque développeur
et en sauvegardant l’historique de chaque modification. [9]
3.2.5 Outil de manipulation des documents électroniques
c Adobe Acrobat DC
Est une famille de logiciels mis au point par Adobe, il permet de
manipuler des documents électroniques au format PDF, de gérer
les processus de signatures électroniques et de créer et numériser
des formulaires interactifs.
3.2.6 Environnement de Système de Gestion de Base de Données
c Oracle Database 11g
Est un SGBD relationnel édité par la société Oracle Corporation,
leader mondial des bases de données. Il permet d’assurer la dé-
finition et la manipulation, la sauvegarde et la restauration des
données ainsi que la gestion des accès concurrents.
24

3.3 Archiecture du projet
3.3.1 Architecture matérielle
Le choix de l’architecture physique est d’une importance primordiale, il influencera la per-
formance du système.
C’est pour cette raison, que nous optons pour une séparation de notre plate-forme en diffé-
rentes couches. Nous parlons dans ce cas du modèle multi-tiers plus précisément l’architecture
3 tiers qui est également une extension du modèle Client/Serveur.
En utilisant cette architecture, le système est divisé en trois parties dont le rôle de chacune
est défini comme suit :
• Couche présentation
Elle correspond à la partie visible de l’application , appelée Interface Homme Machine.
Son rôle est de réassembler les services offerts par la couche inférieure et les afficher à
l’utilisateur ;
• Couche métier
Appelé aussi Business, c’est la couche qui exécute la logique métier, elle offre des services
à la couche présentation en utilisant les données accessibles à travers la couche inférieure
d’accès aux données ;
• Couche d’accès aux données
Elle correspond au serveur de la base de données. Sur ce troisième tiers, un SGBD est
installé. Nous avons dans notre cas utilisé le SGBDR, ORACLE 11g, qui a pour rôle de
stocker les données indépendamment de la logique applicative.
Figure 3.1: l’architecture 3-tiers de notre application
25

3.3.2 Architecture logicielle
L’une des étapes importantes dans le processus de la mise en œuvre d’une application est
le choix adéquat d’un motif de conception puisqu’il facilite la communication, fait gagner en
terme de rapidité et diminue d’une manière éminente les coûts.
Dans ce projet, nous avons opté pour le patron de conception MVC. Son principal intérêt
est la séparation des responsabilités en divisant l’interface graphique d’un programme en trois
entités distinctes ayant chacune un rôle précis lors du traitement de l’information, ce qui rend
l’application plus maintenable et plus évolutive.
Les rôles des trois entités sont les suivants : [10]
• Le modèle : Contient les données manipulées par le programme. Il assure la gestion de
ces données et garantit leur intégrité ;
• La vue : Fait l’interface avec l’utilisateur. Son premier rôle est d’afficher les données
qu’elle a récupéré auprès du modèle et son second rôle est de recevoir toutes les actions
de l’utilisateur. Ses différents événements sont envoyés au contrôleur ;
• Le contrôleur : Chargé de la synchronisation du modèle et de la vue. Il reçoit tous les
événements de l’utilisateur et dénclenche les actions à effectuer.
Figure 3.2: Architecture MVC
26

3.4 Choix techniques
c AJAX
Repose sur un ensemble de technologies tels que javascript, xml,
json, html et les requêtes http, destinées à réaliser des transferts
de données et de rapides mises à jour du contenu d’une page Web,
sans procéder au rechargement total de la page.
c Bootstrap
Bootstrap est une collection d’outils utiles à la création du design
des sites et d’applications web. C’est un ensemble qui contient des
codes HTML, CSS ainsi que des extensions JavaScript en option.
[11]
c jQuery
Est un Framework développé en JavaScript, il possède une librairie
qui propose les fonctionnalités de gestion des évènements, d’anima-
tion et de manipulation des feuilles de style.
c HTML5
Un langage de balisage conçu pour représenter des pages web. Son
principal intérêt est le formatage de l’écriture d’un document avec
des balises.
c CSS3
Un langage informatique qui permet de décrire la mise en page des
documents HTML dans le but d’améliorer leur aspect ergonomique
et décoratif.
27

c Sass
Un langage de génération de feuilles de style, basé en grande partie
sur CSS3, en ajoutant de nouvelles règles telles que l’utilisation des
variables et la création des fonctions.
c PHP
PHP est un langage de script, utilisé pour produire des pages Web
dynamiques via un serveur http. il offre des nombreuses possibilités
telles que la gestion des sessions utilisateurs, la gestion de fichiers
PDF, la gestion des e-mails en POP et IMAP et le cryptage MD5
et SHA1 [12]
c PL/SQL
Basé sur les paradigmes de programmation procédurale et struc-
turée. Créé par Oracle et utilisé dans le cadre de bases de données
relationnelles. [13]
c UML
Un langage de modélisation unifié qui s’utilise généralement pour
la conception orientée objet. Il est constitué d’un ensemble de dia-
grammes, leur principal rôle est de présenter les logiciels à déve-
lopper sous une forme graphique.
3.5 Description du système « SI Mailing »
Nous consacrons cette section pour montrer la réalisation du système « SI mailing » déclaré
dans la partie précédente comme étant un acteur secondaire interagissant avec notre système
général.
Le recours à l’implémentation de ce système était notre solution pour remédier au problème
de l’extraction des données à partir des pièces-jointes envoyées par les stagiaires sous la forme
d’e-mails.
28

Ce système permet aussi de concrétiser le processus d’envoi et de lecture des courriers
électroniques ainsi que la récupération des attachements en utilisant les deux protocoles SMTP
et IMAP.
3.5.1 Protocoles de messagerie utilisés
c SMTP
Entre l’utilisateur et son serveur, l’envoi des e-mails sur les réseaux se fait à l’aide du proto-
cole SMTP. Et pour assurer ce transfert, nous avons eu recours à la bibliothèque « PHPMailer
» disponible en PHP qui fournit une collection de fonctions facilitant la construction et la
génération des e-mails.
c IMAP
Pour amener à bien le processus de la lecture des e-mails et arriver à accéder aux diﬀérents
courriers électroniques envoyés de la part des stagiaires, nous avons travaillé avec des fonctions
PHP qui utilisent le protocole IMAP.
Le schéma representé par la ﬁgure 3.3 illustre le fonctionnement des protocoles présentés
ci-dessus.
Figure 3.3: Principe des échanges de messages électroniques [14]
3.5.2 PDF interactif
Tous les problèmes rencontrés lors de la recherche d’une solution pour que le candidat puisse
nous envoyer ses informations sans avoir un accès direct à la plate-forme nous ont amenés à
29

utiliser un formulaire sous la forme d’un PDF interactif. Le formulaire doit être rempli par
chaque candidat, et envoyé par e-mail, dans le but d’en extraire toutes les données nécessaires.
Nous montrons ci-dessous à travers la ﬁgure 3.4 notre PDF interactif.
Figure 3.4: PDF interactif
Conclusion
Dans ce chapitre nous avons présenté l’environnement matériel et logiciel que nous avons
préparé pour la mise en place de notre système, l’architecture physique et logicielle, les diﬀérents
choix techniques ainsi que le système « SI Mailing ». Dans le chapitre suivant, nous allons
entamer le premier pas de la réalisation du projet : le sprint1.
30

Chapitre 4
Sprint1 : Authentification et gestion
des utilisateurs et des offres
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 32
2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 33
3 Phase de post-jeu : ﬁnalisation . . . . . . . . . . . . . . . . . . . . . 45
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Introduction
Le présent chapitre consiste à décrire les différentes étapes de la réalisation du premier
sprint. En premier lieu, nous allons évoquer les histoires utilisateurs. En second lieu, nous
allons exposer les différents diagrammes d’analyse et de conception et par la suite, nous allons
présenter la phase de réalisation ainsi que les scénarios de test.
4.1 Phase de pré-jeu : préparation
4.1.1 But
Le but de ce premier sprint consiste à mettre en œuvre le processus d’authentification qui
à son tour déclenche l’accomplissement de la fonctionnalité gestion des utilisateurs avec leurs
différents privilèges. Ce sprint vise aussi à mettre en place la fonctionnalité de la gestion des
offres de stages qui sont proposées par l’encadrant et consultables par le responsable RH.
4.1.2 Backlog du sprint
Nous présentons à travers le tableau 4.1 le Backlog de ce sprint ainsi que l’estimation d’effort
par jour de chaque fonctionnalité à réaliser.
Tableau 4.1: Backlog du sprint1
ID Théme ID User stories Effort
1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais
m’authentifier pour accéder à mon es-
pace.
5j
3 Gérer utilisateurs 3.1 En tant qu’Administrateur je vou-
drais consulter la liste des utilisa-
teurs.
1j
3.2 En tant qu’Administrateur je vou-
drais consulter le profil d’un utilisa-
teur.
1j
drais ajouter un profil utilisateur.
1.5j
32

drais modifier le profil d’un utilisa-
teur.
1.5j
drais supprimer un utilisateur.
0.5j
drais trier la liste des utilisateurs.
0.25j
drais chercher un utilisateur.
0.25j
14 Gérer sujets stages 14.1 En tant qu’Encadrant je voudrais
consulter la liste des sujets.
1j
chercher un sujet.
0.25j
ajouter un sujet.
1.5j
14.4 En tant qu’Encadrant je voudrais mo-
difier un sujet.
1.5j
supprimer un sujet.
0.5j
16 Consulter offres de stage 16.1 En tant que Responsable RH je vou-
drais consulter les offres proposées.
1j
16.2 En tant que Responsable RH je vou-
drais consulter le contenu d’une offre
proposée.
1j
4.2 Phase de jeu : mise en oeuvre
4.2.1 Modélisation fonctionnelle
Les besoins à réaliser dans notre premier sprint, ont été spécifiés. Nous passons maintenant à
la présentation des diagrammes de cas d’utilisation qui ont pour but de donner une vue globale
33

sur l’ensemble des fonctionnalités fournies par l’application, ainsi que les descriptions textuelles
qui décrivent les scénarios de chaque cas.
4.2.1.1 Diagramme de cas d’utilisation global du sprint1
Figure 4.1: Diagramme de cas d’utilisation global du sprint1
4.2.1.2 Raffinement du cas d’utilisation « Gérer utilisateurs »
Pour gérer les utilisateurs, un administrateur a la possibilité d’effectuer les fonctionnalités
modélisées dans la figure 4.2 ci-dessous.
Figure 4.2: Raffinement du cas d’utilisation « Gérer utilisateurs »
34

– Description textuelle du cas d’utilisation « Ajouter un utilisateur »
La description textuelle représentée dans le tableau 4.2 montre le scénario du cas cas d’uti-
lisation « Ajouter un utilisateur » illustré dans la figure 4.2.
Tableau 4.2: Description textuelle du cas d’utilisation
« Ajouter un utilisateur »
Sommaire
Titre : Ajouter un profil utilisateur
Auteur : Administrateur
Description d’enchaînement
Pré-conditions : Authentification et consultation de la liste des utilisateurs
Post-conditions : Profil utilisateur ajouté
Scénario Nominal
1. L’administrateur demande d’ajouter un nouveau profil ;
2. Le système récupère les informations des utilisateurs existants à partir de l’annuaire ;
3. Le système affiche les informations au niveau du formulaire à remplir ;
4. L’administrateur saisit les informations demandées pour l’ajout et confirme l’opé-
ration par un clic sur le bouton « Enregistrer » ;
5. Le système valide le nom utilisateur et le mot de passe et ajoute les informations ;
6. Si valide, le système affiche un message de succès ;
7. FIN.
Scénario Alternatif
1. Si l’administrateur entre des données erronées ;
a. GOTO 3.
2. Si l’utilisateur existe déjà ;
a. le système affiche un message d’avertissement ;
b. GOTO 3.
Scénario d’exceptions
35

1. Si l’administrateur ne confirme pas ou annule l’opération d’ajout en cliquant sur le
bouton « Annuler » ;
a. GOTO FIN.
– Description textuelle du cas d’utilisation « Modifier un profil utilisateur »
La description textuelle représentée dans le tableau 4.3 illustre le scénario du cas d’utilisation
« Modifier un profil utilisateur » modélisé dans la figure 4.2.
« Modifier un profil utilisateur »
Sommaire
Titre : Modifier un profil utilisateur
Auteur : Administrateur
Pré-conditions : Authentification et consultation de la liste des utilisateurs
Post-conditions : Profil utilisateur modifié
Scénario Nominal
1. L’administrateur choisit le profil qu’il veut modifier ;
2. Le système récupère et affiche les informations du profil utilisateur choisi ;
3. L’administrateur modifie les données et confirme par un clic sur le bouton « Enre-
gistrer » ;
4. Le système valide l’opération et affiche un message de succès de modification ;
5. FIN.
Scénario Alternatif
1. Si l’administrateur n’a pas renseigné au moins un champ ;
a. Le système affiche un message d’avertissement ;
b. GOTO 2.
36

1. Si l’administrateur refuse de continuer l’opération de modification et l’annule ;
a. GOTO FIN.
4.2.2 Conception
En se basant sur les fonctionnalités modélisées dans la section précédente, nous allons passer
à la conception détaillée des cas d’utilisation principaux. Dans un premier temps, nous allons
élaborer les diagrammes de séquences de quelques cas d’utilisation afin de clarifier le déroule-
ment des événements. Dans un second temps, nous allons détailler le diagramme de classes du
sprint, qui va nous amener au schéma relationnel de notre base de données.
4.2.2.1 diagrammes de séquences détaillés
Pour une bonne compréhension des composantes du premier sprint, il est indispensable
de présenter les diagrammes de séquences des principaux cas d’utilisation. Ces diagrammes
décrivent les scénarios de chaque cas en mettant l’accent sur le facteur chronologique, ainsi que
l’interaction entre les différents objets qui le constituent.
On peut distinguer trois types d’objets illustrés par le tableau 4.4 ci-dessous :
Tableau 4.4: Types d’objets
« Boundary » Représente l’interface affichée à l’utilisateur
« Control » Assure la communication entre le modèle et la vue.
« Model » Représente la persistance des données auprès du système.
– Diagramme de séquence du cas d’utilisation « S’authentifier »
Dans le diagramme de la figure 4.4 ci-dessous, nous détaillons l’interaction entre les utilisa-
teurs et les composants du système afin de pouvoir s’authentifier.
37

Figure 4.3: Diagramme de séquence du cas d’utilisation « S’authentiﬁer »
– Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur »
Dans le diagramme de la ﬁgure 4.4 ci-dessous, nous détaillons l’interaction entre l’adminis-
trateur et les composants du système utilisés au cours de l’ajout d’un utilisateur.
38

Figure 4.4: Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur »
– Diagramme de séquence du cas d’utilisation « Modifier un utilisateur »
Dans le diagramme de la figure 4.5 ci-dessous, nous détaillons l’interaction entre l’adminis-
trateur et les composants du système utilisés au cours de la modification.
39

Figure 4.5: Diagramme de séquence du cas d’utilisation « Modifier un utilisateur »
4.2.2.2 diagramme de classes
Le diagramme de séquence présenté dans la partie précédente nous a permis de voir une vue
dynamique de notre système, et afin de pouvoir présenter les différentes entités qui le composent
avec leurs différentes relations d’une manière statique nous avons consacré cette partie pour
définir un diagramme faisant partie des diagrammes structurels d’Uml qui est le diagramme de
classes illustré par la figure 4.6 ci-dessous.
40

Figure 4.6: Diagramme de classes du sprint 1
4.2.3 Réalisation
Après avoir présenté la solution conceptuelle, nous exploitons dans ce qui suit le fruit de
notre travail en exposant les diﬀérentes interfaces les plus signiﬁcatives, relatives à ce premier
sprint.
41

c Interface d’authentification
Nous commençons par présenter la première interface commune à tous les acteurs de notre
système, celle relative à l’authentification, avec laquelle tous les utilisateurs sont appelés à in-
troduire leurs noms d’utilisateur et leurs mots de passe pour pouvoir accéder chacun à son
espace personnel.
Si les informations sont invalides, le système affiche un message d’erreur, et en cas d’une ten-
tative d’accès à une page de la plateforme via l’URL sans aucune identification, il fait une
redirection automatique vers la page d’authentification (figure 4.7).
Figure 4.7: Interface d’authentification
c Interfaces des listes des utilisateurs et des offres
L’administrateur peut gérer les différents profils disponibles en accédant à la liste des uti-
lisateurs à travers l’interface 4.8, tandis que l’encadrant a la main de gérer et d’examiner la
liste de ses offres présentée dans la figure 4.9. Chacun d’entre eux a la possibilité de faire une
recherche ou un trie sur sa liste selon un critère souhaité.
42

Figure 4.8: Interface de la liste des utilisateurs
Figure 4.9: Interface de la liste des offres
c Interface d’ajout d’un utilisateur
Pour ajouter un nouvel utilisateur, l’administrateur clique en premier lieu sur l’icône d’ajout
présentée dans la figure 4.8. Dès que le pop-up s’affiche, ce dernier sélectionne un personnel
parmi ceux qui sont disponibles et remplit par la suite toutes les informations indiquées dans
le formulaire présenté par l’interface 4.10.
43

Figure 4.10: Interface d’ajout d’un utilisateur
c Interface de modification d’une offre de stage
Dans le cadre de la gestion des offres, un encadrant a le droit de modifier un sujet. La figure
4.11 indique l’interface du pop-up affichant les informations de l’offre à modifier.
Figure 4.11: Interface de modification d’une offre de stage
44

c Interfaces du contenu d’un profil utilisateur et d’une offre
À travers les deux interfaces des figures 4.12 et 4.13 ci-dessous, un administrateur a la
possibilité de consulter le profil d’un utilisateur et tout encadrant peut afficher le contenu
d’une offre déjà publiée.
Figure 4.12: Interface d’un profil
utilisateur
Figure 4.13: Interface du contenu d’une
offre
4.3 Phase de post-jeu : finalisation
Après la réalisation du premier sprint, nous passons maintenant à la présentation des tâches
de finalisation. Nous présentons ici l’avancement du travail pour savoir si nous avons pu at-
teindre les objectifs définis et de se préparer pour le sprint suivant.
4.3.1 Test fonctionnel
Il s’agit dans cette section de mettre l’action sur quelques cas de scénarios de tests fonc-
tionnels relatifs au premier sprint en les présentant dans le tableau 6.4 suivant :
Tableau 4.5: Test fonctionnel du premier sprint
Cas de test Démarche Comportement attendu Résultat
Test d’authentifica-
tion
Après l’accès à l’interface
d’authentification, l’utili-
sateur entre ses coordon-
nées et valide.
Redirection vers la page d’ac-
cueil si l’utilisateur existe. Si-
non un message d’erreur s’af-
fiche.
Conforme
45

Test d’ajout d’un
profil utilisateur
Après l’accès à la liste
des utilisateurs, l’admi-
nistrateur saisit les don-
nées d’un profil et clique
sur le bouton « Enregis-
trer ».
Si le profil utilisateur est déjà
existant, un message d’erreur
d’ajout s’affiche, sinon un mes-
sage succès apparaît.
Conforme
Test de modifica-
tion d’une offre de
stage
Après l’accès à la liste des
offres, l’encadrant sélec-
tionne le sujet à modifier
et clique sur le l’icône de
modification.
Un formulaire contenant les
données du sujet sélectionné
s’affiche dans un pop-up. Dès
sa confirmation, les informa-
tions modifiées s’enregistrent
et un message de succès de mo-
dification s’affiche.
Conforme
Test de suppression
d’une offre de stage
Après l’accès à la liste des
offres, l’encadrant choi-
sit le sujet à supprimer
en cliquant sur l’icône de
suppression.
Un pop-up de confirmation ap-
paraît. Si l’encadrant confirme
l’opération, un message de suc-
cès s’affiche, sinon, en cas d’an-
nulation, le système effectue
une redirection vers la liste des
offres.
Conforme
4.3.2 Rétrospective du sprint 1
Après avoir fait la revue du sprint et la vérification des différentes fonctionnalités demandées,
nous présentons dans ce qui suit l’évaluation de cet incrément à travers le tableau 4.6.
46

Tableau 4.6: Rétrospective du sprint 1
Rétrospective du sprint 1
Ce qui a bien fonctionné
• Authentification ;
• Ajouter un(e) utilisateur / offre ;
• Modifier un(e) utilisateur / offre ;
• Supprimer un(e) utilisateur / offre ;
• Consulter un profil utilisateur ;
• Consulter un sujet ;
• Chercher un utilisateur / sujet ;
• Consulter une offre de stage ;
• Consulter la liste des offres de stages.
Ce qui n’a pas bien fonctionné rien à mentionner
Ce qui doit être amélioré rien à mentionner
Conclusion
À travers ce chapitre, nous avons présenté la spécification des besoins, la conception illustrée
par des diagrammes de séquences détaillés et un diagramme de classes ainsi que la réalisation
des histoires utilisateurs du premier sprint.
Après avoir testé et validé les fonctionnalités avec le Scrum Master et le Product Owner au
cours de la revue du sprint, nous allons maintenant attaquer la prochaine étape : le sprint 2
47

Chapitre 5
Sprint2 : Traitement des
candidatures des stagiaires
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Introduction
Après avoir entamé le premier sprint de notre système, nous allons maintenant passer à la
présentation de notre deuxième sprint. Tout au long de ce chapitre, nous allons nous intéresser
à la phase du traitement des candidatures des stagiaires. Tout d’abord, nous allons présenter la
première phase de préparation, celle de la réalisation et nous allons terminer enfin par la partie
de la finalisation et des tests fonctionnels.
5.1.1 But
En partant du même principe que le sprint précédent, nous commençons par définir le but
de notre deuxième sprint, qui consiste à mettre en œuvre le processus du « traitement des
candidatures des stagiaires ».
Ce sprint est le plus important et le plus complexe, car il contient les fonctionnalités prin-
cipales du projet, où on doit réaliser le traitement des candidatures ainsi que le processus de la
consultation des notifications.
Avant de commencer le travail, nous allons identifier dans cette partie les fonctionnalités à
réaliser durant cet incrément.
Le tableau 5.1 ci-dessous résume donc le backlog de notre deuxième sprint.
15 Consulter notifications 15.1 En tant qu’Utilisateur je voudrais
consulter les notifications reçues.
2j
7 Traiter demandes reçues 7.1 En tant que Responsable RH je vou-
drais consulter la liste des demandes
non traitées.
1j
drais consulter le contenu d’une de-
mande reçue.
2j
49

drais affecter un candidat à un sujet.
1j
drais refuser un candidat.
0.5j
drais actualiser la liste des demandes
reçues.
5j
drais télécharger un document du
dossier candidat.
1j
drais chercher une demande.
0.25j
10 Présélectionner candi-
dats
consulter la liste des candidatures re-
çues.
1j
consulter le profil d’un candidat.
1j
choisir un candidat.
1j
chercher un candidat.
1.25
La Figure 5.1 ci-dessous, représente le diagramme de cas d’utilisation global qui modélise
les fonctionnalités spécifiques à ce sprint. Et afin de mieux les assimiler nous établissons les
raffinements nécessaires qui nous conduisent vers les descriptions textuelles.
50

5.2.1.1 Diagramme de cas d’utilisation global du sprint2
5.2.1.2 Raffinement du cas d’utilisation « Traiter demandes reçues »
Afin de traiter les demandes reçues, chaque responsable RH a la possibilité de visualiser la
liste des demandes non traitées, de l’actualiser et d’effectuer toutes les fonctionnalités modélisées
dans la figure 5.2 ci-dessous.
Figure 5.2: Raffinement du cas d’utilisation « Traiter demandes reçues »
– Description textuelle du cas d’utilisation « Affecter candidat »
« Affecter candidat » modélisé dans la figure 5.2.
51

« Affecter candidat »
Sommaire
Titre : Affecter candidat
Auteur : Responsable RH
Pré-conditions : Authentification, visualiser la liste des demandes non traitées et
consulter le contenu d’une demande
Post-conditions : Candidat affecté
Scénario Nominal
1. Le cas d’utilisation commence lorsque le responsable RH décide d’affecter un sta-
giaire en cliquant sur le bouton « Affecter » ;
2. Le système récupère la liste des sujets disponibles et la met à la disposition du
responsable RH à travers une vue d’affectation renfermant un formulaire ;
3. Le responsable RH remplit le formulaire et confirme en cliquant sur le bouton «
Enregistrer » ;
4. Le système modifie l’état de la demande à « En attente » ;
5. Le système insère les nouvelles informations dans la table des stages et des messages ;
6. En cas de réussite, le système affiche un message de succès ;
7. FIN.
1. Si le responsable ne confirme pas l’opération ;
a. GOTO FIN.
5.2.1.3 Raffinement du cas d’utilisation « Présélectionner candidats »
Chaque encadrant a la possibilité de préselectionner un candidat. il peut nottament consul-
terla liste des candidatures reçues et effectuer toutes les fonctionnalités modélisées dans la 5.3
ci-dessous.
52

Figure 5.3: Raffinement du cas d’utilisation « Présélectionner candidats »
– Description textuelle du cas d’utilisation « Afficher profil candidat »
« Afficher profil candidat » modélisé dans la figure 5.3.
« Afficher profil candidat »
Sommaire
Titre : Afficher profil candidat
Auteur : Encadrant
Pré-conditions : Authentification et accès à la liste des candidatures reçues
Post-conditions : Profil candidat affiché
Scénario Nominal
53

1. L’encadrant clique sur l’icône « Informations » située au niveau de l’interface des
candidatures reçues ;
2. Le système récupère les informations du profil souhaité et les affiche en créant la
nouvelle vue « Profil candidat » ;
3. L’encadrant choisit un candidat en cliquant sur le bouton « Choisir » ;
4. Le système récupère la liste de tous les sujets disponibles et les affiches ;
5. L’encadrant sélectionne un sujet parmi ces derniers et confirme par un clic sur le
bouton « Enregistrer » ;
6. Le système insère les nouvelles informations dans la table des stages ;
7. Le système modifie l’état de la demande à « Suggérée » ;
8. Si valide, le système affiche un message de succès ;
9. FIN.
1. Si les différentes modifications sur la base ne s’effectuent pas ;
a. Le systeme affiche un message d’erreur ;
b. GOTO FIN.
5.2.2 Conception
Après avoir terminé les raffinements des cas d’utilisation, nous élaborons les diagrammes de
séquences et d’activités afin de mieux structurer et comprendre les interactions entre les objets
manifestés au niveau de ce sprint.
5.2.2.1 diagramme d’activité
Le diagramme d’activité permet de clarifier et de donner une vision sur le déroulement,
l’enchaînement ainsi que le parallélisme des évènements propre à un cas d’utilisation.
– Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues »
Dans la figure 5.4 nous présentons les activités qui aboutissent à l’actualisation des demandes
reçues.
54

Figure 5.4: Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues »
5.2.2.2 diagrammes de séquences détaillés
Pour éclaircir les cas d’utilisation de ce sprint et présenter la succession chronologique des
opérations réalisées par les acteurs de notre système, nous consacrons cette partie pour décrire
les diagrammes de séquences.
– Diagramme de séquence du cas d’utilisation « Affecter Candidat »
Dans la figure 5.5 nous montrons le comportement dynamique du cas d’utilisation « Affecter
Candidat » à travers son diagramme de séquence.
55

Figure 5.5: Diagramme de séquence du cas d’utilisation « Affecter Candidat »
– Diagramme de séquence du cas d’utilisation « Afficher profil candidat »
Dans la figure 6.7 nous montrons le comportement dynamique du cas d’utilisation « Afficher
profil candidat » à travers son diagramme de séquence.
56

Figure 5.6: Diagramme de séquence du cas d’utilisation « Afficher profil candidat »
5.2.2.3 diagramme de classes
La figure 5.7 représente l’évolution du diagramme de classes par rapport au sprint qui
le précède en indiquant les nouvelles méthodes qui nous ont servi pour arriver à traiter les
demandes de stage.
57

Figure 5.7: Diagramme de classes du sprint2
5.2.3 Réalisation
Pour mener à bien notre projet, les interfaces Homme/Machine doivent être faciles à utiliser
tout en obéissant à des conditions d’ergonomie. Nous présentons dans ce qui suit quelques
interfaces pour expliquer les fonctionnalités oﬀertes par le deuxième sprint.
58

c Interface de la liste des demandes reçues et non traitées
La Figure 5.8 présente l’interface affichant le tableau des demandes reçues et non traitées,
qui donne la possibilité à une recherche spécifique, à la consultation des détails d’une demande,
et à l’actualisation de la liste afin de la mettre à jour.
Figure 5.8: Interface de la liste des demandes reçues et non traitées
c Interface des profils des candidats
Les interfaces 5.9 et 5.10 présentent les différentes actions sur les profils des candidats. Le
responsable RH a le droit de refuser ou d’affecter une candidature à une offre, par contre l’en-
cadrant n’a qu’à choisir une demande, et chacun d’entre eux peut consulter leurs informations
ainsi que leurs documents.
Figure 5.9: Interface du profil candidat coté responsable
59

Figure 5.10: Interface du profil candidat coté encadrant
c Interface choisir candidat
La figure 5.11 présente le pop-up affiché à l’encadrant pour choisir un stagiaire, cette dernière
propose un menu déroulant, contenant les différentes offres de stage qu’il a déposé, avec un volet
pour afficher les informations relatives au sujet suite à sa sélection.
Figure 5.11: Interface choisir candidat
60

c Interface d’affectation des stagiaires
Nous présentons dans cette figure 5.12 l’interface dédiée à l’affectation des stagiaires. À
partir de ces formulaires, le responsable RH a la possibilité de choisir une offre dans le but
d’avoir une idée sur ses informations ainsi que de l’assigner au candidat sélectionné, et pour
accomplir l’opération de l’affectation, il doit indiquer la date du rendez-vous, la durée du stage
et facultativement un message de renseignement.
Figure 5.12: Interface d’affectation des stagiaires
c Interface des e-mails
La figure 5.13 montre l’e-mail envoyé automatiquement suite à la réception d’une demande
de stage. En effet pour inciter les stagiaires à remplir notre PDF interactif et envoyer leurs
documents, nous proposons à travers cette interface un guide et un bouton de postulation afin
de fixer l’objet de l’e-mail pour des utilisations futures. Lorsque le stagiaire respecte toutes
les règles du guide et envoie correctement ses fichiers, un accusé de réception 5.14 s’envoie
automatiquement. Sinon il sera averti par un courrier électronique.
61

Figure 5.13: Mail de réponse à une demande de stage
Figure 5.14: Accusé de réception
62

5.3 Phase de post-jeu : finalisation
Nous réservons cette partie pour la finalisation du présent sprint, en présentant un ensemble
de cas de tests validés auprès du Product Owner.
5.3.1 Test fonctionnel
le tableau 5.4 montre les différents tests fonctionnels effectués sur quelques cas d’utilisations
du deuxième sprint.
Tableau 5.4: Test fonctionnel du deuxième sprint
Cas de test Démarche Comportement attendu Résultat
Test d’affectation
d’un candidat
Après l’accès à la liste
des demandes non trai-
tées, le responsable RH
consulte le contenu d’une
demande, clique sur «
Affecter » et enregistre
l’opération après avoir
rempli le formulaire.
Lors de l’enregistrement, S’il
y a un champ vide dans le
formulaire un message d’erreur
s’affiche, sinon une redirection
vers la liste des demandes non
traitées est effectuée et un mes-
sage de succès d’affectation est
affiché.
Conforme
Test de choix d’un
candidat
Aprés l’accés à la liste des
candidatures reçues l’en-
cadrant choisit de consul-
ter le profil d’un candi-
dat, clique sur le bouton
« Choisir » et lui associe
un sujet.
Un message indiquant la sug-
gestion avec succès est affiché.
Conforme
5.3.2 Rétrospective du sprint 2
La vérification de tout ce qui a été réalisé au niveau de ce présent sprint, a généré l’évaluation
présentée dans le tableau 5.5.
63

Tableau 5.5: Rétrospective du sprint 2
Rétrospective du sprint 2
Ce qui a bien fonctionné
• Actualiser demandes reçues ;
• Consulter contenu demandes ;
• Aﬀecter / Refuser candidat ;
• Choisir candidat.
Ce qui n’a pas bien fonctionné rien à mentionner
Ce qui doit être amélioré la notiﬁcation en temps réel
Conclusion
À travers ce chapitre, nous sommes arrivées à clôturer le deuxième sprint des traitements des
candidatures par la revue d’un second livrable fonctionnel, bien testé et validé par le propriétaire
du produit. De ce fait, nous sommes amenées à étudier les étapes de la mise en œuvre du
prochain sprint que nous allons détailler dans le chapitre suivant.
64

Chapitre 6
Sprint3 : Affectation des stagiaires
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapitre 6. Sprint3 : Affectation des stagiaires
Introduction
Après avoir achevé l’étude et la réalisation du deuxième sprint, nous allons passer à la
présentation des différentes tâches effectuées pour arriver à affecter les candidats à des offres
de stages. Cela constitue l’objet de ce troisième incrément qui suit les mêmes principes des
sprints précédents : nous allons mettre en place son backlog après l’explication de son but et
nous allons évoquer la phase d’analyse, de conception ainsi que celle de la réalisation.
6.1.1 But
Le but de ce troisième sprint est d’entamer le processus d’affectation des candidats en
passant en revue les différents états des demandes. Nous mettons en place la conception et la
réalisation de toutes les fonctionnalités qui conduisent soit à l’acceptation d’un stagiaire tout
en lui créant sa prise de fonction soit au refus de sa candidature.
La planification des différentes fonctionnalités qui constituent le présent incrément est pré-
sentée dans le tableau 6.1 du backlog du sprint
4 Consulter demandes re-
fusées
consulter la liste des demandes refu-
sées.
1j
consulter le contenu d’une demande.
0.5j
0.25j
8 Gérer suggestions 8.1 En tant que Responsable RH je vou-
drais consulter les demandes suggé-
rées.
1.5j
66

drais consulter le profil d’un stagiaire.
0.5j
drais accepter une suggestion d’affec-
tation.
1j
drais refuser une suggestion d’affecta-
tion.
0.5j
9 Gérer affectations 9.1 En tant que Responsable RH je vou-
drais consulter la liste des demandes
suivies.
2.5j
drais chercher une demande.
0.25
drais trier les demandes.
0.25j
drais visualiser le dossier d’un sta-
giaire.
0.5j
drais accepter une prise de fonction.
3j
drais refuser une prise de fonction.
1j
11 Gérer propositions d’En-
cadrement
consulter la liste des demandes en at-
tente.
1j
trier les demandes en attente.
0.25j
chercher un candidat.
0.25j
11.4 En tant qu’Encadrant je voudrais af-
ficher le profil d’un stagiaire .
0.5j
67

11.5 En tant qu’Encadrant je voudrais ac-
cepter d’encadrer un candidat.
1.5j
11.6 En tant qu’Encadrant je voudrais re-
fuser d’encadrer un candidat.
1j
Pour livrer une description sur quelques scénarios possibles liés au troisième sprint, nous
réservons cette partie pour présenter le diagramme de cas d’utilisation global et ses raffinements.
6.2.1.1 Diagramme du cas d’utilisation global du sprint3
6.2.1.2 Raffinement de cas d’utilisation « Gérer suggestions »
Nous présentons au niveau de la figure 6.2 le raffinement du cas d’utilisation « Gérer sugges-
tions » dont le responsable RH a la possibilité d’effectuer toutes les fonctionnalités modélisées
ci-dessous.
68

Figure 6.2: Raffinement du cas d’utilisation « Gérer suggestions »
6.2.1.3 Raffinement du cas d’utilisation« Gérer propositions d’encadrement »
Le diagramme de la figure 6.3 présente le raffinement du cas d’utilisation « Gérer propo-
sitions d’encadrement » en modélisant toutes les fonctionnalités qui sont à la disposition des
encadrants.
Figure 6.3: Raffinement du cas d’utilisation « Gérer propositions d’encadrement »
– Description textuelle du cas d’utilisation « Accepter d’encadrer »
La description textuelle représentée dans le tableau 6.2 montre le scénario du cas d’utilisation
« Accepter d’encadrer » illustré dans la figure 6.3.
« Accepter d’encadrer »
Sommaire
69

Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

Similaire à Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires (20)

Dernier

Dernier (12)

Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires