E5er Version 1

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis el Manar
Faculté des Sciences de Tunis
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National d’Ingénieur en Génie Informatique
Spécialité : Système d’information d’aide à la décision
Par
M. Raed KCHAOU
Mise en place d’une platforme RH afin

d’optimiser les performances du capital
humain de Talan
Encadrant professionnel (Talan) : M. Marwen CHNITI

Encadrant académique (FST) : Mme. Zouhour BEN DHIAF
Réalisé au sein de Talan
Année Universitaire : 2021-2022

Encadrant professionnel
M. Marwen CHNITI
Signature et cachet
Encadrant académique
Mme. Zouhour BEN DHIAF
Signature
i
Dédicaces
Je dédie ce travail à celles et ceux qui sont les plus chèr.e.s dans ce monde.
À la mémoire de ma grand-mère Chedliya et de mon grand-père Taoufik qui
nous ont quitté trop tôt.

À la mémoire de mon ami Imam Chorbaji qui nous a quitté à la fleur de l’âge.
A ma mère, Sihem, à mon père Rabeh,

Pour leur soutien moral et affectif durant ma vie
Pour leurs sacrifices et leurs qualités humaines

Que Dieu leur réserve une bonne santé.
À ma chère sœur Rania qui m’a toujours souhaité le meilleur.

À toute la famille Kchaou et Abdelmouleh
À mon cher département ‘SAIYANS’ au sein d’AIESEC, au bureau exécutif de

AIESEC Medina 21.22 et à toute la famille de AIESEC Medina auxquels je suis
reconnaissant.
À mes enseignants
À tous mes amis

À tous ceux qui m’aiment et à tous ceux qui me connaissent
Sincèrement, Raed
Remerciements
Il m’est agréable, avant de présenter ce travail, d’exprimer toute ma gratitude envers

tous ceux qui sans eux ce projet n’aurait jamais été mené à son terme.
Mes sincères remerciements à Mr. Behjet BOUSSOFARA, Directeur Général de Talan Tunisie
Consulting, qui m’a permis d’entreprendre et de mener à bien mon travail au sein de son
établissement.
Ma parfaite reconnaissance à Mme. Imen SEBEI, directrice du département Talan Salesforce,

pour ses remarques très constructives et ses conseils avisés.
Ma profonde gratitude à Mr. Marwen CHINITI, à qui je tiens à exprimer toute ma gratitude,
pour l’aide qu’il m’a apportée durant ce stage. Sa disponibilité, sa modestie et sa gentillesse
n’ont d’égale que ses grandes qualités professionnelles. Qu’il soit assuré de l’expression de mes
remerciements les plus sincères.
Ce projet a pu être porté à terme grâce à l’aide et au soutien de Mme. Zouhour BEN DHIAF,
qui a accepté de le suivre en détail : qu’elle reçoive ici ma reconnaissance et ma gratitude pour
sa disponibilité, sa pédagogie et ses précieuses directives tout au long du projet.
Mes vifs remerciements, accompagnés de toute ma gratitude, s’adressent également à Mme

Nouha MADDEH pour ses encouragements et ses précieux conseils.
Il m’est aussi agréable d’exprimer ma reconnaissance respectueuse à tous les enseignants de

la Faculté des Sciences de Tunis, qui sont à la base de ma formation.
Enfin, je voudrais, à cette occasion, exprimer à tous les membres du jury mes vifs remerciements.
iii
Table des matières
Introduction générale 1
1 Contexte du projet 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Talan Tunisie Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Organigramme de Talan . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Secteurs d’activités de Talan . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Talan Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Choix de la méthodologie de développement . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Concepts fondamentaux de Salesforce 10

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Présentation de Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Gestion des relations clients (CRM) . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Le PaaS de Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.4 Le CRM de Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Architecture Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Modélisation des données dans Salesforce . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Les principaux objets standards dans Salesforce . . . . . . . . . . . . . . 15
2.3.2 Relation entre compte, contact, piste et opportunité . . . . . . . . . . . . 15
2.4 Langages de programmation, workflows et les langages de requêtes de Salesforce 16
2.4.1 Les langages de programmation de Salesforce . . . . . . . . . . . . . . . . 16
iv
2.4.2 Les langages de requêtes de Salesforce . . . . . . . . . . . . . . . . . . . . 18
2.4.3 Les workflows de Salesforce . . . . . . . . . . . . . . . . . . . . . . . . . 19
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Analyse 23
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.3 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . 27
3.2.3 Identfication des user stories et du backlog de produit . . . . . . . . . . . 28
3.3 Modélisation des besoins sous forme de diagramme de cas d’utilisation général . 30
3.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Conception 32
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Sprint 1 : Gérer les offres de travail . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2 Diagramme de cas d’utilisation du sprint . . . . . . . . . . . . . . . . . 35
4.2.3 Diagramme de classes du sprint . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Sprint 2 : Gérer la première phase de recrutement . . . . . . . . . . . . . . . . . 45
4.3.3 Diagrammes de séquences du sprint . . . . . . . . . . . . . . . . . . . . 55
v
4.3.5 Diagramme d’activités du sprint . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Sprint 3 : Gérer la deuxième phase du recrutement . . . . . . . . . . . . . . . . 60
4.4.3 Diagramme de séquences du sprint . . . . . . . . . . . . . . . . . . . . 72
4.4.5 Diagramme d’activités du sprint . . . . . . . . . . . . . . . . . . . . . . 74
4.5 Sprint 4 : Pilotage du reporting et tableau de bord / Gérer les utilisateurs et les
droits d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5.3 Diagramme de classe complet . . . . . . . . . . . . . . . . . . . . . . . . 79
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5 Réalisation 80
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1 Choix technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.1 Outils et langages de développement . . . . . . . . . . . . . . . . . . . . 80
5.1.2 Outils de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.3 Outils d’intégration des données . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.4 Outils de gestion du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Description de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.1 Gestion des postes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.2 Première phase de recrutement . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.3 Deuxième phase de recrutement . . . . . . . . . . . . . . . . . . . . . . 91
5.2.4 Les tableaux de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.3 Planification du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Webographie 101
vi
Table des figures
1.1 Organigramme de Talan Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Processus SCRUM [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Classement des outils de CRM [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Classement des outils de CRM [5]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 L’architecture de base de Salesforce [6] . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Analogie ente Salesforce et un tableur [7] . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Conversion d’une piste [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Architecture du composant Lightning [10]. . . . . . . . . . . . . . . . . . . . . . 18
2.7 Exemple de Workflow [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Exemple de Process Builder [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Exemple de Flow Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 L’application Byblos [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Diagramme de cas d’utlisation général . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Architecture physique [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Architecture logicielle [17]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Diagramme de cas d’utilisation "Gérer les offres de travail" . . . . . . . . . . . . 36
4.4 Diagramme de cas d’utilisation "Gérer les départements" . . . . . . . . . . . . . 36
4.5 Diagramme de cas d’utilisation "Gérer les stages" . . . . . . . . . . . . . . . . . 39
4.6 Diagramme de cas d’utilisation "Gérer les emplois" . . . . . . . . . . . . . . . . 42
4.7 Diagramme de classes du sprint "Gérer les offres de travail" . . . . . . . . . . . 45
4.8 Diagramme de cas d’utilisation "Gérer la première phase du recrutement" . . . . 47
4.9 Diagramme de cas d’utilisation "Postuler pour un stage ou un emploi" . . . . . 48
4.10 Diagramme de cas d’utilisation "Gérer candidats de la première phase" . . . . . 50
4.11 Diagramme de cas d’utilisation "Passer un test" . . . . . . . . . . . . . . . . . . 53
4.12 Diagramme de cas d’utilisation "Consulter les tests" . . . . . . . . . . . . . . . . 54
4.13 Diagramme de séquences "Postuler dans un stage ou poste de travail" . . . . . . 56
4.14 Diagramme de séquences "Passer un test" . . . . . . . . . . . . . . . . . . . . . 57
vii
Table des figures
4.15 Diagramme de classes du sprint "Gérer la première phase du recrutement" . . . 58

4.16 Diagramme d’activités du sprint "Gérer la première phase du recrutement" . . . 59
4.17 Diagramme de cas d’utilisation "Gérer la deuxième phase du recrutement" . . . 62
4.18 Diagramme de cas d’utilisation "Affecter des interviews" . . . . . . . . . . . . . 62
4.19 Diagramme de cas d’utilisation "Gérer les interviews" . . . . . . . . . . . . . . . 64
4.20 Diagramme de cas d’utilisation "Gérer les feedbacks" . . . . . . . . . . . . . . . 68
4.21 Diagramme de cas d’utilisation "Gérer candidats de la deuxième phase" . . . . . 69
4.22 Diagramme de cas d’utilisation "Envoyer un feedback" . . . . . . . . . . . . . . 71
4.23 Diagramme de séquences "Envoi de feedback" . . . . . . . . . . . . . . . . . . . 73
4.24 Diagramme de classes du sprint "Gérer la deuxième phase du recrutement" . . . 74
4.25 Diagramme d’activités du sprint "Gérer la deuxième phase du recrutement" . . 75
4.26 Diagramme de cas d’utilisation "Gérer les utilisateurs et les droits d’accès" . . . 77
4.27 Diagramme de cas d’utilisation "Gérer les utilisateurs" . . . . . . . . . . . . . . 78
4.28 Diagramme de cas d’utilisation "Pilotage du reporting et tableau de bord" . . . 78
4.29 Diagramme de classe complet" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1 Interface interne contenant la liste des départements . . . . . . . . . . . . . . . . 82

5.2 Détails d’un département . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3 Interface contenant la liste des offres de travail . . . . . . . . . . . . . . . . . . . 83
5.4 Formulaire de création de poste . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 Interface liste des départements pour le candidat . . . . . . . . . . . . . . . . . . 84
5.6 Interface Postes de travail pour le candidat . . . . . . . . . . . . . . . . . . . . . 85
5.7 Formulaire de recrutement pour le candidat . . . . . . . . . . . . . . . . . . . . 85
5.8 Notification lorsque le candidat postule . . . . . . . . . . . . . . . . . . . . . . . 86
5.9 Interface de la liste des candidats . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.10 Détails d’un candidat à la première phase . . . . . . . . . . . . . . . . . . . . . . 87
5.11 Premier email envoyé au candidat . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.12 Email du test technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.13 Contrôle d’accès à l’interface du test technique . . . . . . . . . . . . . . . . . . . 88
5.14 Interface du test technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.15 Emails des résultats du test technique . . . . . . . . . . . . . . . . . . . . . . . . 89
5.16 Tableaux des tests techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
viii
5.17 Exemple d’un CV de candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.18 Etapes de candidature de la deuxième phase . . . . . . . . . . . . . . . . . . . . 91
5.19 Formulaire de création d’un entretien . . . . . . . . . . . . . . . . . . . . . . . . 91
5.20 Emails envoyés après l’entretien . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.21 Interface du feedback pour le candidat . . . . . . . . . . . . . . . . . . . . . . . 92
5.22 Interface de la liste des feedbacks . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.23 Contrat du candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.24 Email du contrat envoyé au candidat . . . . . . . . . . . . . . . . . . . . . . . . 94
5.25 Signature numérique du contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.26 Email envoyé après la signature . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.27 Exportation des données Talend . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.28 Tableau de bord des candidats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.29 Tableau de bord des départements . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.30 Tableau de bord des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.31 Tableau de bord des feedbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.32 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
ix
Liste des tableaux
2.1 Description des principaux objets standards . . . . . . . . . . . . . . . . . . . . 15

2.2 Différence entre SOQL et SOSL [11] . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Les acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Description détaillée du cas d’utilisation "Ajouter département" . . . . . . . . . 37
4.3 Description détaillée du cas d’utilisation "Consulter liste des départements" . . . 38
4.4 Description détaillée du cas d’utilisation "Modifier département" . . . . . . . . . 38
4.5 Description détaillée du cas d’utilisation "Supprimer département" . . . . . . . . 39
4.6 Description détaillée du cas d’utilisation "Ajouter stage" . . . . . . . . . . . . . 40
4.7 Description détaillée du cas d’utilisation "Consulter liste des stages" . . . . . . . 40
4.8 Description détaillée du cas d’utilisation "Modifier stage" . . . . . . . . . . . . . 41
4.9 Description détaillée du cas d’utilisation "Supprimer stage" . . . . . . . . . . . . 42
4.10 Description détaillée du cas d’utilisation "Ajouter emploi" . . . . . . . . . . . . 43
4.11 Description détaillée du cas d’utilisation "Consulter liste des emplois" . . . . . . 43
4.12 Description détaillée du cas d’utilisation "Modifier emploi" . . . . . . . . . . . . 44
4.13 Description détaillée du cas d’utilisation "Supprimer emploi" . . . . . . . . . . . 44
4.14 Backlog de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.15 Description détaillée du cas d’utilisation "Afficher la liste des stages et des emplois" 48
4.16 Description détaillée du cas d’utilisation "Postuler pour un stage ou emploi" . . 49
4.17 Description détaillée du cas d’utilisation "Ajouter candidat" . . . . . . . . . . . 50
4.18 Description détaillée du cas d’utilisation " Consulter liste des candidats à la
phase une " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.19 Description détaillée du cas d’utilisation "Modifier candidat à la première phase" 52
4.20 Description détaillée du cas d’utilisation "Supprimer candidat à la première phase" 52
4.21 Description détaillée du cas d’utilisation "convertir un candidat" . . . . . . . . . 53
4.22 Description détaillée du cas d’utilisation "Passer un test" . . . . . . . . . . . . . 54
x
4.23 Description détaillée du cas d’utilisation "Gérer la première phase du recrutement" 55
4.24 Description détaillée du cas d’utilisation "Afficher les détails d’un test" . . . . . 55
4.25 Backlog de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.26 Description détaillée du cas d’utilisation " Affecter des interviews " . . . . . . . 63
4.27 Description détaillée du cas d’utilisation "Ajouter interview" . . . . . . . . . . . 65
4.28 Description détaillée du cas d’utilisation " Afficher les données relatives à un
interview " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.29 Description détaillée du cas d’utilisation "Supprimer interview" . . . . . . . . . 66
4.30 Description détaillée du cas d’utilisation "Modifier interview" . . . . . . . . . . . 67
4.31 Description détaillée du cas d’utilisation "Noter un interview" . . . . . . . . . . 67
4.32 Description détaillée du cas d’utilisation " Afficher la liste des feedbacks " . . . . 68
4.33 Description détaillée du cas d’utilisation "Supprimer feedback" . . . . . . . . . . 69
4.34 Description détaillée du cas d’utilisation "Supprimer candidat à la deuxième phase" 70
4.35 Description détaillée du cas d’utilisation " Consulter liste des candidats à la
deuxième phase " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.36 Description détaillée du cas d’utilisation " Consulter les données relatives à un
candidat " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.37 Description détaillée du cas d’utilisation "Envoyer un feedback" . . . . . . . . . 72
4.38 Backlog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
xi
Introduction générale
Dès le début du XXIème siècle, le monde évolue grâce à la digitalisation et aux technologies
modernes que l’être humain est en train de développer. Aujourd’hui, tout est digital, il devient
possible de réaliser des tâches, qui étaient très complexes auparavant, en seulement quelques
clics. La science de l’informatique facilite aujourd’hui tous les domaines, en fournissant des
services et des solutions confortables pour les utilisateurs et les clients. Ces services nécessitent
un capital humain important pour les maintenir et les développer, surtout que le besoin des
solutions et services dans le monde n’a jamais cessé d’augmenter. Pour cela, les entreprises
informatiques dans le monde ont toujours manifesté leur besoin de recruter de nouveaux talents
compétents pour dominer le marché, avoir plus de clients et plus de solutions fiables.
Cet avancement technologique a encouragé les étudiants dans le monde à suivre les
besoins du marché, en s’orientant vers les sciences de l’informatique. Cette évolution de l’offre et
de la demande dans le domaine de l’informatique nécessite la création d’un système performant
de recrutement et de gestion des ressources humaines, capable de supporter et de gérer un
nombre énorme de candidats. Ceci est désormais possible grâce aux applications de type CRM,
qui permettent de gérer un nombre énorme de clients et assurer un suivi de qualité.
Aujourd’hui, il existe plusieurs plateformes CRM, chacune a sa manière de gérer les
activités des clients et de centraliser les données. De tous ces CRM, Salesforce est considéré
comme le leader mondial des applications, grâce à son innovation, à sa capacité importante et à
sa flexibilité de s’adapter aux différents besoins de ses clients. Il offre une expérience hautement
supérieure par rapport aux autres plateformes CRM. Cet outil a révolutionné la gestion des
relations avec les clients dans le monde. Un nombre important d’entreprises l’utilise pour gérer
leurs différents services.
C’est dans ce contexte que s’inscrit notre projet de fin d’études au sein de l’équipe Talan
Salesforce, qui consiste à concevoir et développer une solution Salesforce qui permettra d’assurer
le bon déroulement et garantira la réussite du processus de recrutement.
Notre objectif consistera à personnaliser la plateforme de gestion des relations avec les
clients, en faisant l’analogie entre les clients et les candidats qui vont postuler pour rejoindre
l’équipe de Talan. Nous envisageons d’utiliser les fonctionnalités que Salesforce offre et nous
intégrerons nos propres fonctionnalités dans cette plateforme. Ceci ne sera possible qu’après
1
Introduction générale
une bonne compréhension de Salesforce et de ses langages de programmation, frameworks et

technologies internes, ces derniers seront utilisés tout au long du développement de notre projet.
Notre solution sera donc un CRM, personnalisé et développé, sur la plateforme Salesforce, qui
aidera la société Talan à gérer, optimiser et simplifier son processus de recrutement, et de le
rendre plus efficace.
Ce rapport présente un résumé de notre travail, structuré en six chapitres :
— Dans le premier chapitre "Contexte du projet", nous présentons le cadre général
du projet, à savoir l’organisme d’accueil, le contexte du projet, la problématique et les
objectifs du travail ainsi que les choix méthodologiques.
— Le deuxième chapitre "Concepts fondamentaux de Salesforce" présente les notions

théoriques qui seront utilisées lors de la réalisation de ce projet
— Le troisième chapitre intitulé "Analyse" sera consacré à l’analyse, dans lequel nous
présentons l’étude de l’existant et sa critique, les acteurs de l’application, le backlog
produit, les besoins fonctionnels et non fonctionnels, la modélisation des cas d’utilisation
ainsi que la planification des différents sprints.
— Le quatrième chapitre intitulé "Conception" détaillera, en premier lieu, l’architecture

globale de la solution et offrera, en second lieu, la conception détaillée de l’application à
développer.
— Le cinquième chapitre qui a pour titre "”Mise en œuvre" présentera l’environnement

de réalisation du projet ainsi que la description de l’application illustrant les différentes
interfaces projetées.
Enfin, la conclusion générale présentera un bilan récapitulatif de notre solution et d’éventuelles

perspectives du projet.
2
Chapitre 1
Contexte du projet
Introduction
Ce chapitre a pour objectif de mettre le projet dans son cadre général. Nous commençons,
tout d’abord, par une présentation de l’organisme d’accueil, de son organigramme et de ses
domaines d’activités. Ensuite, nous définissons la problématique du projet et les objectifs
envisagés. Enfin, nous présentons la méthodologie utilisée pour développer la solution proposée.
1.1 Présentation de l’organisme d’accueil

Il nous semble utile de présenter, de prime abord, la société d’accueil et ses secteurs
d’activités.
1.1.1 Talan Tunisie Consulting
Depuis sa création en 2002, Talan assiste les entreprises et les administrations à mettre
en œuvre leurs projets de développement en France et à l’international. Présent sur quatre
continents, le groupe, qui renferme près de 3000 collaborateurs, a atteint, fin 2017, un chiffre
d’affaires de 185 millions d’euros. Talan met l’innovation au centre de ses activités. Elle intervient
dans les domaines liés aux mutations technologiques des grands groupes, comme le Big Data,
l’IoT, la Blockchain, l’Intelligence Artificielle, etc.
Talan compte plus de 1500 consultants, implantés dans les différents pôles de développement
en France, au Luxembourg, au Royaume-Uni, à New York et à Hong Kong. Elle offre un cadre
novateur et motivant pour fidéliser et épanouir ses collaborateurs. Le centre de développement
"Nearshore" de Tunisie a été créé en 2008. Il regroupe actuellement plus de 100 ingénieurs .
Ses compétences sont réparties entre :
— Le développement Java EE, Open source et .Net.
3
Chapitre 1. Contexte du projet
— Le développement d’applications Mobile.
— L’intégration de progiciels de Billing et CRM [1].
1.1.2 Organigramme de Talan
La figure 1.1 présente l’organigramme de la société Talan.
Figure 1.1 : Organigramme de Talan Tunisie
1.1.3 Secteurs d’activités de Talan
Les principales activités de Talan consistent aux conseil et assistance à la maîtrise

d’ouvrage ; à la refonte et optimisation des processus métiers ; au support aux grands projets
de transformation ; à l’alignement des systèmes d’information aux changements d’organisation
et à l’accompagnement au changement. Ces activités touchent, essentiellement, les secteurs de
services suivants :
— Le secteur de finance : Dans ce secteur, Talan est leader sur le marché en France, elle
intervient sur la majorité des places financières mondiales. Elle assiste et accompagne les
principaux acteurs des marchés financiers ;
— Le secteur d’assurance : Talan s’appuie sur une solide connaissance des métiers de
l’assurance pour traiter les principales problématiques du secteur : évolutions réglementaires,
4
rapprochements de moyens et digitalisation ;
— Le secteur d’énergie et de services publics : La présence de Talan dans ce secteur

est principalement orientée dans le domaine régulé. Elle est reconnue aussi par sa capacité
à adresser les enjeux propres à l’ouverture du marché, et à intervenir sur des sujets de
type SI ;
— Le secteur de transports et de logistique : Talan a développé une forte expertise

dans le secteur ferroviaire et logistique. Elle accompagne les acteurs dans leurs projets de
transformation et d’optimisation de leurs organisations ;
— Le secteur de télécom et de médias : La présence de Talan dans ce secteur est le

résultat de 10 années de progression continue. Talan admet une capacité à intervenir sur
des sujets avancés de type SI, mais aussi en appui aux équipes de gestion des offres. [1]
1.1.4 Talan Salesforce
Salesforce s’est imposé comme un leader technologique au service de la transformation et

de la croissance des organisations en proposant une solution innovante de gestion de la relation
client (CRM) basée sur le cloud. Talan a donc fait le choix de devenir partenaire de Salesforce
en 2012. Aujourd’hui, Talan Salesforce est composée de plus de 150 experts et accompagne ses
clients dans leurs projets.
Talan associe ses expertises secteurs, métiers et technologiques à la puissance de la plateforme

Salesforce Customer 360 pour adresser l’ensemble des départements et métiers des organisations
avec pour objectifs de :
• Capitaliser sur les technologies émergentes (Intelligences Artificelles, IoT, smart

automation, ...) pour proposer des solutions innovantes et adaptées aux enjeux des organisations
de demain, intelligentes et connectées.
• Révolutionner la relation clients en leur proposant des expériences pertinentes et

personnalisées.
• Transformer les métiers en les rendant plus efficaces et en développant leur valeur
ajoutée.
• Favoriser la collaboration des équipes, quels que soient les métiers, départements
ou zones géographiques grâce à une vue unifiée à 360° des clients sur une plateforme
intégrée [1].
5
1.2 Contexte du projet
1.2.1 Problématique
De nos jours, la révolution digitale poursuit son expansion dans le monde. Par conséquent,
on constate un grand besoin de solutions informatiques sur le marché international. Talan, l’un
des leaders du domaine, doit s’adapter à ce changement en renforçant son capital humain pour
augmenter son quote-part de ce marché. Pour enrichir et diversifier son capital humain, Talan
doit disposer d’un système adéquat de recrutement. Un système qui permettra d’organiser ce
processus, de gérer les projets et les postes proposés, ainsi que le nombre important de candidats
pour chaque opportunité.
En général, il existe plusieurs processus de recrutement classiques. Ces approches non
optimisées ne sont pas vraiment la meilleure alternative. En effet, ces solutions exigent plus
de temps et de ressources surtout avec le nombre important de candidats. Ces solutions, qui
ne sont pas performantes, exigent un temps assez long pour traiter le nombre important de
candidats, qui ne cesse d’augmenter, avec des risques de non équité entre eux. Par conséquent,
certains candidats sont insatisfaits de la manière dont ont été traitées leurs demandes. En effet,
certains postulants ne reçoivent même pas un simple retour ( rejet, réception,..) et ne sont pas
tenus informés de l’état d’avancement du traitement de leurs dossiers.
Pour cela, les sociétés doivent centraliser et uniformiser l’ensemble des données sur les
candidats, afin d’avoir une vision dynamique à 360° et organiser leur processus de recrutement,
qui présente une étape primordiale pour le développement du capital humain de toute société.
1.2.2 Objectifs
L’objectif de ce projet est de concevoir et d’implémenter une solution pour optimiser

le processus de recrutement de Talan. Cela aidera la société à revoir le processus existant en
fournissant des moyens d’automatisation du processus, de gestion et de manipulation d’une
masse importante de données. Il s’agit donc de centraliser et de manipuler ces données d’une
manière efficace. Cette solution doit permettre d’atteindre les objectifs spécifiques suivants :
-Accélérer et faciliter le traitemnt des dossiers des candidats.
-Automatiser le processus de recrutement,
6
- générer automatiquement des contrats en intégrant une signature électronique,
- Etudier le niveau de satisfaction des postulants vis-à-vis de la solution, en centralisant leurs

feedbacks et en les analysant,
-Avoir un système de communication automatique avec les candidats,
1.3 Choix de la méthodologie de développement

La sélection du processus de développement est une étape primordiale. Elle permet
d’assurer le bon déroulement du projet et d’obtenir les meilleurs résultats, aussi bien sur le
plan qualité, que productivité. En effet, le choix entre un modèle de processus de développement
et un autre dépend de la nature et de l’ampleur du projet. Lorsque le projet ne collecte pas
de données dès le début et que les exigences sont incomplètes ou équivoques, il propose des
méthodes itératives et incrémentales. Les méthodes AGILE sont parmi les méthodes largement
utilisées dans la réalisation des projets. Notre projet sera basé, donc, sur une méthode de type
AGILE, et plus précisemment Scrumban, en raison de sa facilité d’adaptation aux changements
et aux évolutions. Cette méthode élimine l’effet tunnel et donne plus de visibilité au client qui
sera présent dès le début du cycle du projet.
1.3.1 Scrum
Scrum est la méthode AGILE la plus adéquate aujourd’hui. Elle se caractérise par
des répétitions courtes et réduites. Elle traduit et organise les projets de manière simple,
transparente et pragmatique. Nous avons choisi cette approche car elle nous permet de nous
adapter à l’évolution des besoins tout au long du processus de conception et de développement.
La méthode Scrum définit trois rôles distincts : Product Owner, Scrum Master et équipe
opérationnelle. Chacun des acteurs s’occupe uniquement de son domaine d’actions sans
empiéter sur celui des autres. Le cycle de vie de cette technique est présenté dans la figure
1.2.
7
Figure 1.2 : Processus SCRUM [2].
L’établissement de cette relation de confiance permet l’accomplissement d’un but unique

et commun : l’aboutissement du projet qui est confié à l’équipe du projet. Dans notre projet,
l’équipe Scrum se compose de :
• Product owner : Sebai Imen
• Scrum master : Chniti Marwen
• Team member : Kchaou Raed
1.3.2 Langage de modélisation
Un langage de modélisation sert à décrire un système spécifique à un domaine et/ou

à un contexte par ses composants et leurs relations. Dans notre projet, nous avons choisi
d’utiliser le langage de modélisation UML. UML (Unified Modeling Language, ou langage de
modélisation unifié), est pensé pour être un langage de modélisation visuelle commun et riche. Il
est constitué d’un ou de plusieurs diagrammes, chacun donnant une vision différente du projet
sur lequel nous travaillons. Par conséquent, notre UML fournit des diagrammes pour représenter
le fonctionnement et les actions qui peuvent être effectuées par le logiciel. La génération de ces
diagrammes fait donc partie de la modélisation logicielle qui doit être développée.
8
Conclusion
Dans le premier chapitre, nous avons exposé le contexte général du travail, en présentant
l’hébergeur Talan, la problématique du projet, ainsi que les solutions proposées. De plus, nous
avons présenté la méthodologie et le formalisme adoptés pour la mise en place du projet. Nous
nous intéressons, dans le chapitre suivant, aux concepts de base de Salesforce.
9
Chapitre 2
Concepts fondamentaux de
Salesforce
Introduction
Nous avons intégré l’équipe Salesforce au sein de Talan, pour cela nous avons opté pour
l’utilisation de cette plateforme dans la mise en place de notre solution. Nous nous intéressons
donc, dans ce chapitre, aux concepts théoriques liés à Salesforce. Nous allons présenter cette
plateforme, son architecture, ses concepts clés, ses différents langages de programmation et ses
outils déclaratifs.
2.1 Présentation de Salesforce
2.1.1 Gestion des relations clients (CRM)
CRM sont les initiales de Customer Relationship Management, c’est-à-dire la gestion des
relations clients. Cette technologie permet de gérer les relations avec les clients et de suivre les
données associées à l’ensemble des interactions.
Elle permet également, aux équipes, de collaborer, en interne et en externe, de rassembler
des informations à partir des réseaux sociaux, de suivre les métriques importantes, et de
communiquer par e-mail, téléphone, via les réseaux sociaux, etc.
Elle est définie comme étant une stratégie de développement liée à la vente, au marketing et
aux services clients en permettant de créer des relations rentables et de long terme avec les
clients et aussi l’ensemble des parties prenantes de l’entreprise.
10
Chapitre 2. Concepts fondamentaux de Salesforce
2.1.2 Salesforce
Salesforce est une entreprise de software dont le siège est à San Francisco aux États-Unis.
Elle diffuse des logiciels de gestion sur Internet et des hébergements d’applications professionnelles.
La compagnie est surtout réputée au plan mondial pour ses solutions de management de la
relation client. Cette entreprise dispose d’un CRM qui porte le nom de Salesforce. Celui-ci offre
à toutes les équipes, notamment de marketing, de ventes, de commerce et services, une vue
partagée des clients grâce à une plateforme CRM intégrée.
2.1.3 Le PaaS de Salesforce
La plate-forme en tant que service, ou PaaS, fournit un ensemble de services cloud

permettant aux utilisateurs professionnels et aux développeurs de créer des applications à une
vitesse telle qu’une solution sur site ne peut pas être rivalisée.
Comme il s’agit d’un service cloud, il est inutile de s’assurer de la configuration et de la
maintenance des serveurs, des correcteurs, des mises à jour, de l’authentification, etc. Le seul
souci des utilisateurs est de créer la mesure d’utilisation possible.
Le PaaS offre un ensemble de services supplémentaires, comme des outils de workflow et de
conception, ou des API complémentaires visibles à aider les utilisateurs professionnels et les
développeurs à créer des applications qui enchantent les utilisateurs [3].
2.1.4 Le CRM de Salesforce
Selon une étude effectuée par l’entreprise APPS RUN THE WORLD, qui est une société
d’études du marché technologique, Salesforce est en tête du classement et en tête du peloton,
avec une part du marché de 32,2 %, grâce à une augmentation de 14 % des revenus du CRM.
Adobe était numéro 2, suivi d’Oracle, SAP et Microsoft, comme le montre la figure 2.1. [4].
11
Figure 2.1 : Classement des outils de CRM [4].
Il est aussi intéressant de mentionner que Salesforce a été reconnu en 2021 en tant que
leader des CRM au niveau de l’engagement du client par Gartner pour la 13ème fois consécutive.
En fait, plus des deux tiers (68 %) des clients potentiels contactés par Gartner ont sélectionné
Salesforce Service Cloud comme leur premier, deuxième ou troisième choix de produit, comme
on le remarque dans la figure 2.3 [5].
Figure 2.2 : Classement des outils de CRM [5].
12
2.2 Architecture Salesforce

La bonne utilisation de Salesforce nécessite la compréhension de son architecture. Cette
architecture est composée d’une série de couches superposées illustrées par la figure 2.3.
Figure 2.3 : L’architecture de base de Salesforce [6]
• Multi-tenant : Pour minimiser les coûts de développement et de maintenance, Salesforce

utilise le concept de multi-tenant qui permet aux différents utilisateurs de partager plusieurs
applications, dans une même infrastructure, dont la maintenance est centralisée. Le concept
multi-tenant est basé sur une architecture mutualisée dont le principal avantage est qu’elle
est rentable, vu que les applications sont partagées par plusieurs clients et les coûts sont
répartis entre eux. De plus, si le développeur ou le fournisseur envisage de réaliser une
mise à jour du logiciel fourni, il pourra effectuer cette opération à un seul endroit et tous
les utilisateurs auront l’accès à cette version révisée. [6]
• Meta-data : La plateforme Salesforce utilise un modèle de développement basé sur

les métadonnées. Une métadonnée est une donnée servant à définir ou décrire une autre
donnée indépendamment de son support. Cette architecture est basée sur le stockage
des données à différents niveaux, dans des bases de données partagées. Les métadonnées
pointent vers les données d’un client particulier dans une base de données partagée. Cette
architecture, qui assure une bonne sécurité du système, permet aux développeurs de se
focaliser sur la création d’applications. Ceci augmente le rendement des développeurs. [6]
• API : Une API, est une interface utilisateur de programmation et d’application.Elle
13
offre aux différents développeurs de logiciels, et aux utilisateurs, la possibilité de partager

et d’échanger des données. Salesforce est une source très puissante d’API. Ces API
permettent à divers éléments de programmation de s’interfacer et d’échanger des données.
[6]
2.3 Modélisation des données dans Salesforce

Les données au sein de Salesforce sont organisées d’une manière spécifique. Elles sont
structurées sous forme d’objets, d’enregistrements et de champs :
Les objets : Salesforce classe les objets en deux catégories : des objets standards tels que piste,
devis, opportunité, contrat et des objets personnalisés, créés par l’utilisateur, pour des besoins
spécifiques.
Les enregistrements : Ce sont les données d’un objet. Ils sont comparables aux lignes de
données d’une feuille de calcul, qui représente notre objet dans cette analogie.
Les champs : En continuant dans notre analogie, illustrée ci-dessous par une figure, un champ
est équivalent à une colonne contenant un type bien déterminé de données.
La figure 2.4 illustre l’analogie entre un tableur et Salesforce.
Figure 2.4 : Analogie ente Salesforce et un tableur [7]
14
2.3.1 Les principaux objets standards dans Salesforce
Pour standardiser les applications créées sur sa plateforme et offrir plus de fonctionnalités
pour ses utilisateurs, Salesforce fournit des objets standards. Le tableau 2.1 présente les principaux
objets ainsi que leurs descriptions.
Objet Standard Description

Toutes les personnes qui montrent un intérêt pour les
Piste produits ou services de l’entreprise sont des pistes. Elles
peuvent devenir des clients.
Salesforce nous fournit deux types de comptes : ceux
qui sont associés à des entreprises qu’on appelle comptes
Compte
professionnels et ceux qui sont relatifs à des individus
qu’on appelle comptes personnels.
C’est un objet fourni par Salesforce qui permet le stockage
Contact des noms et des coordonnées des personnes travaillant
dans une société avec laquelle l’entreprise a des affaires.
Après le passage des pistes en clients, les affaires entre
les clients et l’entreprise s’appellent opportunités. C’est le
Opportunité
nom de l’objet standard de Salesforce pour les affaires en
cours.
Tableau 2.1 : Description des principaux objets standards
2.3.2 Relation entre compte, contact, piste et opportunité
A l’origine, les pistes sont des personnes qui montrent un intérêt pour les produits ou
services proposés par l’entreprise. L’entreprise doit essayer de convertir ces pistes en appliquant
son processus prévu. Les pistes seront converties selon l’un des deux scénarios suivants :
— Si l’enregistrement de la piste ne comprend pas de nom de société, elle sera convertie

en compte personnel et en une opportunité.
— Si l’enregistrement de la piste contient un nom de société, elle sera convertie en

compte professionnel, un contact et une opportunité.
15
Les informations disponibles dans l’enregistrement des pistes sont utilisées pour créer les
objets résultant de la conversion. La figure 2.5 illustre les deux types de conversion d’une piste.
Figure 2.5 : Conversion d’une piste [7].
2.4 Langages de programmation, workflows et les langages
de requêtes de Salesforce
La plateforme Salesforce n’offre pas uniquement un CRM standard, mais elle donne aussi
la possibilité de personnaliser le CRM et d’utiliser ses fonctionnalités et objets selon le besoin
de l’utilisateur. Cette plateforme fournit aux utilisateurs non seulement ses propres frameworks
et langages de programmation, mais aussi des outils puissants d’automatisation et des langages
de requêtes.
2.4.1 Les langages de programmation de Salesforce
2.4.1.1 Apex
Apex est un langage de programmation orienté objet, fortement typé, qui permet aux
développeurs d’exécuter des instructions de contrôle de flux et de transactions sur le serveur
Lightning Platform, conjointement à des appels à l’API Lightning Platform.
À l’aide d’une syntaxe semblable à Java et qui agit de la même façon que des procédures
stockées dans une base de données, le code Apex permet aux développeurs d’ajouter une logique
métier à la plupart des événements système, notamment aux clics de bouton, aux mises à jour
d’enregistrements associés et aux pages Visualforce.
Le code Apex peut être initialisé par des demandes émanant de services Web et de déclencheurs
16
d’objets. Apex peut être stocké sur la plate-forme sous deux formes :
-Une classe est un modèle ou plan directeur, à partir duquel les objets Apex sont créés. Les
classes sont constituées d’autres classes, de méthodes définies par l’utilisateur, de variables, de
types d’exception et d’un code d’initialisation statique.
-Un déclencheur est un Apex qui s’exécute avant ou après certains événements de langage de
manipulation de données (DML), par exemple avant l’insertion d’enregistrements d’objet dans
la base de données ou après la suppression d’enregistrements. Les déclencheurs sont stockés en
tant que métadonnées dans Salesforce [8].
2.4.1.2 VisualForce
Visualforce est une infrastructure de développement Web. Elle permet aux développeurs
d’élaborer des interfaces utilisateurs sophistiquées et personnalisées pour des applications mobiles
et de bureau, qui peuvent être hébergées sur Lightning Platform.
Visualforce permet aux développeurs d’étendre les fonctionnalités intégrées de Salesforce,
de les remplacer par de nouvelles fonctionnalités et d’élaborer de nouvelles applications.
Dans Visualforce, le développement d’applications est familier pour toutes les personnes
qui ont élaboré des applications Web. Les développeurs créent des pages Visualforce, en assemblant
des composants, des balises HTML et des éléments de style facultatifs. Visualforce peut intégrer
n’importe quelle technologie Web standard, ou infrastructure JavaScript, pour créer une interface
utilisateur, plus animée et plus riche. Chaque page est accessible via une URL unique. Lorsqu’une
personne accède à une page, le serveur exécute le traitement de données requis par la page,
restitue la page en HTML et renvoie les résultats au navigateur, qui les affiche. [9]
2.4.1.3 Lightning Component
L’infrastructure de composants Lightning est un framework de développement d’interface

utilisateur pour ordinateur de bureau et appareil mobile. Comme son nom l’indique, cette
approche de développement d’interface utilisateur s’appuie sur des composants. À l’aide de
composants Lightning prédéfinis et personnalisés, il est possible de développer rapidement des
interfaces utilisateurs performantes et cohérentes pour diverses applications. Deux modèles de
programmation sont disponibles pour créer des composants Lightning à savoir : lightning Web
Component et Aura.
Lightning Web Component a été créé essentiellement pour surmonter les lacunes du framework
17
Aura, mais sans éliminer la puissance des composants Lightning. Ces deux modèles permettent
aux développeurs de créer rapidement des applications performantes sécurisées et fournissant
une bonne convivialité. La figure ci-dessous présente l’architecture du composant Lightning liée
aux méthodes d’action Apex sur le PaaS de Salesforce [10]. La figure 2.6 présente l’architecture
du composant lightning et sa liaison avec Apex.
Figure 2.6 : Architecture du composant Lightning [10].
Cette figure met en évidence de nombreuses caractéristiques d’une architecture de composants

Lightning :
— Les différents composants communiquent entre eux grâce à un système de messagerie

qui les unit sous forme d’une seule application.
— Tous les composants sont placés dans un seul conteneur.
— Il est possible de créer un composant à partir d’autres composants.
— Il existe une liaison entre les composants lightning et les classes Apex.
— Une API Javascript côté client, fournit un service pour gérer le transport de données,
pour un traitement côté serveur. [10].
2.4.2 Les langages de requêtes de Salesforce
Le traitement de données dans Salesforce est réalisé à partir des requêtes exécutées sur
les enregistrements. La plateforme Salesforce dispose de deux langages de requêtes : Salesforce
Object Query (SOQL) et Salesforce Object Search Language (SOSL) [11]. Le tableau
2.2 représente la différence entre les deux types de langage de requête.
18
SOQL SOSL
Le mot clé ”SELECT” est utilisé pour Le mot clé ”FIND” est utilisé pour
récupérer les enregistrements. récupérer les enregistrements.
Il faut savoir dans quels objets ou champs Nous ne savons pas dans quels objets ou
les données résident champs les données résident
Il est possible de récupérer plusieurs
Il est possible de récupérer des données
objets et valeurs de champ lorsque les
à partir d’un seul objet ou de plusieurs
objets sont liés ou non liés les uns aux
objets liés
autres
Peut être utilisé dans les déclencheurs de Ne peut pas être utilisé dans les
classes déclencheurs de classes
Tableau 2.2 : Différence entre SOQL et SOSL [11]
2.4.3 Les workflows de Salesforce
Salesforce nous offre aussi la possibilité d’automatiser le processus métier, comme l’envoi
des e-mails aux pistes, précisant une mise à jour d’un candidat, ou par exemple notifier un
utilisateur lors de la création d’une nouvelle opportunité. Grâce aux outils workflow, Process
Builder, Flow Builder et Approval Process, Salesforce facilite la mise en œuvre de ces workflows.
2.4.3.1 Workflow
Afin de gagner du temps dans l’organisation, workflow est l’un des outils les plus puissants
disponibles dans le PaaS Salesforce. Il permet d’automatiser les processus internes standard. Les
instructions de workflow sont conditionnelles if/then. La partie if est un critère, il doit être vrai
pour que le workflow déclenche des actions associées. Par contre, la partie then correspond aux
actions qui doivent être exécutées quand le critère est vrai. Parmi les fonctions des workflows,
on cite :
— La mise à jour d’un enregistrement.
— La création d’une tâche.
— L’envoi d’un message sortant (communication avec un autre système).
— L’envoi d’un e-mail instantané [12].
19
La figure 2.7 présente un exemple de workflow.
Figure 2.7 : Exemple de Workflow [13]
2.4.3.2 Process Builder
Process Builder est une extension de workflow contenant plus de fonctionnalités. Process
Builder peut mettre à jour n’importe quel champ de n’importe quel enregistrement associé,
alors que Workflow ne peut mettre à jour que certains champs d’un enregistrement. De plus,
Process Builder fournit aux administrateurs la possibilité de définir l’ordre exact des opérations,
tandis que Workflow n’offre pas cette possibilité. La figure 2.8 illustre un exemple de Process
Builder [12].
20
Figure 2.8 : Exemple de Process Builder [14].
Le processus démarre lorsqu’un champ d’un enregistrement de l’objet case est mis à
jour. Dans ce cas, le Flow Builder modifie un champ d’un enregitrement de l’objet account, qui
est en relation avec l’objet case. Ce processus est réalisé automatiquement à l’aide de Process
Builder. En plus de tout ce qu’un workflow peut faire, Process Builder est capable de :
- Créer un enregistrement ( non seulement des tâches).
- Mettre à jour les enregistrements.
- Appeler un code Apex.
- Appeler un autre processus existant.
2.4.3.3 Flow Builder
Le flow Builder est l’outil le plus puissant dans les workflows de Salesforce. Il est utilisé
pour créer des flux qui nécessitent l’intervention des utilisateurs. A la différence des autres outils
qui s’exécutent en arrière- plan, Flow Builder prend en charge des écrans de flux, en utilisant
des composants Lightning, permettant la participation des utilisateurs.
La figure expose un exemple de Flow Builder [12].
21
Figure 2.9 : Exemple de Flow Builder
Le flux dans la figure permet de simplifier la mise à jour d’un Account à partir d’un
objet utilisateur.
2.4.3.4 Approval Process
Pour approuver des enregistrements, Salesforce fournit Approval Process. Il s’agit d’un
outil automatisé qui comprend un ensemble d’étapes, à approuver ou à rejeter, par un utilisateur
disposant d’une fonction bien déterminée dans l’organisation [12]. Dans Approval Process, il
faut définir :
— Les étapes nécessaires pour l’approbation d’un enregistrement et la personne qui est
chargée par la validation de chaque étape.
— Les actions qu’il faut exécuter en fonction du contenu du processus d’approbation.
Conclusion
L’objectif de ce chapitre consiste à éclaircir les éléments de base aidant à bien comprendre
notre projet. Nous avons défini en détails les concepts clés de Salesforce. Dans le chapitre
suivant ”Analyse”, nous présentons une étude plus profonde des besoins, afin de garantir le bon
fonctionnement et la bonne gestion de l’application.
22
Chapitre 3
Analyse
Introduction
À ce niveau, nous entamons la phase d’analyse, afin de répondre à la question : Comment
fonctionne notre système ? Ce chapitre sera consacré à l’étude de l’existant et à sa critique.
Ainsi, nous allons identifier les acteurs, préciser les besoins fonctionnels et non fonctionnels que
notre solution doit satisfaire et présenter notre backlog produit. Par la suite, nous présentons le
diagramme de cas d’utilisation général, afin de cerner la relation entre nos acteurs et l’application.
Finalement, nous exposons la planification des sprints.
3.1 Etude de l’existant

L’étude de l’existant représente une étape primordiale dans un projet. Elle permettra
d’identifier et de comparer le produit actuel dans le but de connaître ses caractéristiques et
ses fonctionnalités. Dans cette partie, nous étudions la solution existante et nous présentons
les limites des opérations entretenues et émettons les critiques afin de pouvoir développer une
application efficace, performante et fiable.
3.1.1 Description de l’existant
Un ERP est un ensemble de logiciels permettant la gestion des processus opérationnels

d’une entreprise, en intégrant plusieurs fonctions de gestion et en utilisant une base de données .
De nos jours, plusieurs entreprises utilisent les ERP pour centraliser la gestion de leurs processus
internes. Talan utilise une application “Byblos”, qui est une application d’ERP interne. Elle
englobe toutes les informations des ressources humaines des projets, des missions et tout ce qui
concerne l’organisation de la société. L’une des fonctionnalités de base de “Byblos” est de gérer
le processus de recrutement. Cet ERP est illustré dans la figure 3.1.
23
Chapitre 3. Analyse
Figure 3.1 : L’application Byblos [15]
Les principaux utilisateurs de cette application sont une équipe RPO qui peut visualiser
tous les candidats dans un espace consacré au recrutement, comme le montre la figure ci-dessus.
Chaque membre de l’équipe aura à traiter un certain nombre de candidats. Les tâches à réaliser
sont les suivantes :
— L’étude du CV et l’organisation d’un entretien RH.
— L’organisation d’un entretien technique avec le responsable du poste auquel le

candidat a postulé.
— L’envoi d’un test préparé avec la plateforme “codingame” en s’appuyant sur les
informations trouvées dans le CV.
Ce processus n’est pas uniforme pour tous les candidats. A titre d’exemple, dans le cas des
projets de PFE, les CV ne seront pas analysés. Pour une première sélection, des tests préparés
par un outil externe contenant des questions générales sont envoyés par mail.
3.1.2 Critique de l’existant
La méthodologie de recrutement adoptée actuellement par Talan présente certaines

lacunes.
Il est vrai que l’utilisation de “Byblos” permet à l’équipe RH de centraliser les candidatures,
24
Chapitre 3. Analyse
ce qui facilite la gestion des postulants, mais ce n’est pas tout ce qu’on cherche dans un
recrutement. En fait, certaines fonctionnalités jugées importantes n’existent pas.
Tout d’abord, on remarque un manque d’automatisation. L’équipe RPO est amenée à gérer le
processus manuellement, ce qui peut être épuisant et nécessite beaucoup de temps, surtout avec
un nombre important de candidatures. On constate aussi l’absence de communication avec les
candidats dans certains cas, et notamment en cas de refus. De plus, les données fournies par les
candidats peuvent être mieux exploitées, dans des tableaux de bords, permettant une meilleure
analyse du processus.
Pour toutes ces raisons, Talan Tunisie Consulting a pensé à migrer vers une nouvelle application
de recrutement qui satisfait ses besoins et ses objectifs futurs.
3.1.3 Identification des acteurs
Un acteur est une entité externe qui interagit avec le système (opérateur, centre distant,
autre système...). L’étude de l’existant nous a permis d’identifier les acteurs suivants :
25
Chapitre 3. Analyse
Acteur rôle
Il s’agit de la personne qui a un accès illimité à l’application. Il

a l’avantage de gérer les utilisateurs et leurs profils.
Responasble
RH
Cet utilisateur contrôle tout ce qui est en relation avec son

département, que ce soit les stages, les offres d’emplois et les
candidats.
Manager
C’est la personne qui gère les entretiens des candidats affectés

par le manager.
Interviewer
C’est l’acteur qui accéde aux sites externes, visualise les

départements, leurs postes et stages et peut postuler dans le site
externe pour qu’il puisse se transformer en piste.Il peut aussi
passer un test, remplir un formulaire de feedback et signer un
Candidat
contrat.
Tableau 3.1 : Les acteurs du système
26
Chapitre 3. Analyse
3.2 Analyse des besoins

Dans cette section, nous allons présenter les besoins fonctionnels et non fonctionnels,
ainsi que les users stories de notre projet.
3.2.1 Identification des besoins fonctionnels
Notre projet vise à développer et à améliorer une nouvelle plateforme de recrutement.

La solution adoptée a les fonctions suivantes :
• Gestion des rôles de l’équipe recrutement.
• Gestion des départements projets et des postes fournies par la société.
• Gestion des candidatures et suivi des candidats via mail.
• Avoir un processus bien déterminé de recrutement.
• Automatisation du processus de recrutement.
• Gestion des feedbacks des candidats.
• Avoir des statistiques et un tableau de bord sur les données de recrutement.
• Avoir un moyen de signature numérique.
• Import et export des données.
3.2.2 Identification des besoins non fonctionnels
En plus des exigences fonctionnelles, le système doit respecter aussi certaines conditions
pour garantir son bon fonctionnement. Notre application doit vérifier les contraintes suivantes :
• Sécurité : chaque acteur, dans le processus de recrutement, doit avoir son propre
profil et ses propres privilèges .
• Ergonomie : les différentes interfaces doivent être faciles à manipuler et offrir une
expérience fluide.
• Performance : le temps d’exécution d’une opération doit être réduit pour être
satisfaisant aux utilisateurs.
• Maintenabilité : l’application doit être conçue de manière à ce qu’il soit facile de

l’améliorer et de la mettre à jour, en ajoutant de nouvelles fonctionnalités, dans les plus
brefs délais.
27
Chapitre 3. Analyse
3.2.3 Identfication des user stories et du backlog de produit
Nous allons établir le backlog du produit, qui regroupe les user stories, formulées par le
product owner avant chaque Sprint.
Le backlog de produit est présenté dans le tableau 3.2 et comprend les colonnes suivantes :
— ID : l’identifiant unique de la fonctionnalité.
— fonctionnalité : il s’agit d’une fonction ou d’un service du produit.
— User Story : description simple d’une fonctionnalité ou d’une exigence définie par le
product owner.
— IDU : un numéro auto-incrémenté relatif à chaque User Story.
ID Fonctionnalité IDU User Story

1 Gérer les utilisateurs 1.1 En tant que Responsable RH, je veux gérer
et les droits d’accès les utilisateurs, afin de limiter l’accès à
l’application
1.2 En tant que Responsable RH, je veux gérer
les droits d’accès afin de garantir la sécurité
de l’application.
2 Gestion des offres de 2.1 En tant que responsable RH, je veux gérer
travail les départements, afin d’organiser les offres
de travail.
2.2 En tant que manager,je veux gérer les stages
afin de les organiser.
2.3 En tant que manager, je veux gérer les
emplois afin de les organiser
3 Gestion de la première 3.1 En tant que candidat, je veux postuler dans
phase du recrutement une offre de travail.
3.2 En tant que responsable RH, je veux gérer
les candidatures à la première phase de la
procédure de recrutement, afin d’assurer le
bon déroulement du processus.
28
Chapitre 3. Analyse
3.3 En tant que candidat, je peux passer un test

technique afin de continuer le processus.
3.4 En tant que responsable RH, je veux
consulter les tests afin d’organiser le
processus.
4 Gestion de la 4.1 En tant que manager, je peux affecter les
deuxième phase interviewers à des candidats afin d’assurer le
du recrutement bon déroulement du processus.
4.2 En tant qu’interviewer, je veux gérer les
interviews afin de bien sélectionner les
candidats.
les contrats afin de finaliser la procédure de
recrutement.
les feedbacks afin d’analyser les avis des
candidats.
4.5 En tant que Manager, je veux gérer
les candidats de la deuxième phase, afin
d’organiser la procédure de recrutement.
4.6 En tant que candidat de la 2ème phase, je
peux envoyer un feedback, afin d’exprimer
mon avis sur le processus.
5 Pilotage du reporting 5.1 En tant que responsable RH, Manager
et tableau de bord ou Interviewer, je veux consulter tous les
tableaux de bord.
Tableau 3.2 : Backlog Produit
29
Chapitre 3. Analyse
3.3 Modélisation des besoins sous forme de diagramme
de cas d’utilisation général

Le diagramme de cas d’utilisation est exploité afin de permettre une modélisation entière
du comportement fonctionnel du système. Il permet d’identifier les acteurs et de présenter leurs
relations avec le système. La figure 3.2 présente le diagramme de cas d’utilisation général qui
explique le comportement de l’application.
Figure 3.2 : Diagramme de cas d’utlisation général
30
Chapitre 3. Analyse
3.4 Planification des sprints

Le développement du projet sera décomposé en différents sprints. Le tableau 3.3 illustre
les sprints triés par un ordre chronologique et chaque sprint admet une période bien déterminée
(en semaines). Au début de chaque sprint, une réunion aura lieu entre l’équipe du projet dans
lequel nous identifions la période de chaque sprint.
Sprint Nom du sprint Estimation

Sprint 1 Gérer les offres de travail 3 semaines
Gérer la première phase du recrutement
Sprint 2 3 semaines
Sprint 3 Gérer la deuxième phase du recrutement 4 semaines

Pilotage du reporting et tableau de bord /
Sprint 4 2 semaines
Gérer les utilisateurs et les droits d’accès
Tableau 3.3 : Planification des sprints
Conclusion
Ce chapitre a été consacré à l’analyse des besoins fonctionnels et non fonctionnels de
notre solution et du backlog produit. Nous avons décelé le cas d’utilisation général ainsi que
les différents acteurs qui y interviennent. Le chapitre suivant ”Conception” sera consacré à une
étude plus profonde des besoins, afin de garantir la bonne gestion et le bon fonctionnement de
notre solution.
31
Chapitre 4
Conception
Introduction
Dans ce chapitre, nous présentons la phase de conception, considérée comme une phase
primordiale pour la construction de toute application. L’élaboration de notre projet s’appuie,
en fait, sur les résultats de cette phase. Nous exposons, dans ce qui suit, l’architecture mise en
place et la conception détaillée contenant les diagrammes associés à chaque ”Sprint”.
4.1 Architecture du système

Pour comprendre le fonctionnement de notre application, il faut d’abord avoir une idée
globale sur l’architecture utilisée. Nous présentons dans cette partie, l’architecture physique
puis logicielle de la solution adoptée.
4.1.1 Architecture physique
L’architecture physique de Salesforce est l’ensemble des composants nécessaires pour que
notre système fonctionne correctement et fournit tous les besoins non fonctionnels demandés.
L’architecture physique de Salesforce présenté par la figure 4.1 se compose de :
• Un niveau de présentation : c’est la partie où l’utilisateur final interagit avec l’application.
• Un serveur d’application : c’est celui qui va gérer la couche service, c’est le cœur du
système.
• Un serveur de base de données : c’est l’endroit où les informations sont gérées et

stockées.
32
Chapitre 4. Conception
Figure 4.1 : Architecture physique [16]
4.1.2 Architecture logicielle
Salesforce met toujours l’utilisateur au centre de ses intérêts. Ceci se manifeste dans son
architecture logicielle. Cette architecture VCCM (Vue-Contrôleur-Contrôleur-Modèle), illustrée
par la figure 4.2 est décomposée en couches dont l’objectif est de garantir la maintenabilité.
Figure 4.2 : Architecture logicielle [17].
L’architecture logicielle est divisée en deux parties :
• La partie client qui contient son interface (Vue) avec un contrôleur Javascript.
33
• La deuxième partie est la partie serveur chargée du traitement des données en arrière-plan.
Elle contient un autre contrôleur Apex, qui joue le rôle d’intermédiaire avec la base de
données.
Les contrôleurs de notre système agissent donc comme une interface de liaison entre les composants
Modèle et Vue pour traiter toute la logique métier.
4.2 Sprint 1 : Gérer les offres de travail

Au niveau de cette section, nous allons présenter le premier sprint ayant comme objectif
la gestion des offres de travail. Nous allons détailler le backlog du sprint, suivi des diagrammes
réalisés durant ce sprint.
4.2.1 Backlog de sprint
Le backlog du sprint expose les tâches identifiées par les membres de l’équipe Scrum et
qui devront être réalisées au cours de cette itération. Le backlog de ce sprint est présenté dans
le tableau 4.1. Nous notons que l’unité d’estimation du temps dans le Sprint Backlog est le
jour.
IDF User Stroy ID Tâche Estimation

2 2.1 En tant que 2.1.1 Création d’un département. 3 jours
responsable RH,
je veux gérer les
départements afin
d’organiser les offres
de travail.
2.1.2 Affichage des détails des 2 jours
départements.
2.1.3 Suppression d’un département. 1 jour
2.1.4 Mettre à jour les informations d’un 4 jours
département.
34
2.2 En tant que 2.2.1 Création d’un stage. 1 jour

manager, je veux
gérer les stages afin
d’organiser les offres.
2.2.2 Affichage des détails des stages. 1 jour
2.2.3 Suppression d’un stage. 1 jour
stage.
2.3 En tant que 2.3.1 Création d’un emploi. 1 jour
manager, je veux
gérer les emplois afin
d’organiser les offres.
2.3.2 Affichage des détails des emplois. 1 jour
2.3.3 Suppression d’un emploi. 1 jour
2.3.4 Mettre à jour les informations d’un 1 jour
emploi.
Tableau 4.1 : Backlog du sprint 1
4.2.2 Diagramme de cas d’utilisation du sprint
Le responsable RH et le manager interagissent avec l’application afin de gérer les offres

de travail. Cette gestion est représentée dans le diagramme de cas d’utilisation illustré par la
figure 4.3.
35
Figure 4.3 : Diagramme de cas d’utilisation "Gérer les offres de travail"
4.2.2.1 Raffinement du cas d’utlisation "Gérer les départements"
Gérer les départements comprend un certain nombre de scénarios à savoir : ajouter

département, consulter la liste des départements afin de mettre à jour et supprimer un département.
La figure 4.4 décrit d’une manière détaillée le cas d’utilisation "Gérer les départements” suivi
par les tableaux décrivant le scénario de chaque cas d’utilisation.
Figure 4.4 : Diagramme de cas d’utilisation "Gérer les départements"
36
Cas d’utilisation Ajouter département

Acteur Responsable RH
Authentification réussie
Pré-condition
Département ajouté
Post-condition
1/ Le responsable RH demande d’afficher la liste des

departements.
2/ Le système affiche la liste des départements.
3/ Le responsable RH demande d’ajouter un département.
Scénario principal 4/ Le système affiche le formulaire de création.
5/ Le responsable RH remplit les champs du formulaire.
6/Le système vérifie les champs.
7/Le système ajoute un département et envoie un message de
succès.
Le système affiche un message d’erreur lorsqu’il trouve des
Scénario d’exception données manquantes ou invalides.
Tableau 4.2 : Description détaillée du cas d’utilisation "Ajouter département"
Cas d’utilisation Consulter liste des départements

Pré-condition
La liste des départements est affichée

Post-condition

scénario principal departements.
37
Aucun.
Scénario d’exception
Tableau 4.3 : Description détaillée du cas d’utilisation "Consulter liste des départements"
Cas d’utilisation Modifier département

Pré-condition
Département modifié
Post-condition

departements.
3/ Le responsable RH demande de modifier un département.
Scénario principal 4/ Le système affiche le formulaire de modification.
7/Le système met à jour le département et envoie un message
de succès
Tableau 4.4 : Description détaillée du cas d’utilisation "Modifier département"
Cas d’utilisation Supprimer département

Pré-condition
Département supprimé
Post-condition
38

departements.
Scénario principal
3/ Le responsable RH demande de supprimer un département.
4/Le système supprime le département et envoie un message
de succès
Aucun.
Tableau 4.5 : Description détaillée du cas d’utilisation "Supprimer département"
4.2.2.2 Raffinement du cas d’utlisation "Gérer les stages"
Gérer les stages comprend un certain nombre de scénarios à savoir : ajouter stage,
consulter la liste des stages afin de mettre à jour ou supprimer un stage. La figure 4.5 décrit
d’une manière détaillée le cas d’utilisation "Gérer les stages” suivi par les tableaux décrivant le
scénario de chaque cas d’utilisation.
Figure 4.5 : Diagramme de cas d’utilisation "Gérer les stages"
39
Cas d’utilisation Ajouter stage

Pré-condition
Stage ajouté
Post-condition
1/ Le responsable RH demande d’afficher la liste des stages.

2/ Le système affiche la liste des stages.
3/ Le responsable RH demande d’ajouter un stage.
7/Le système ajoute un stage et envoie un message de succès
Tableau 4.6 : Description détaillée du cas d’utilisation "Ajouter stage"
Cas d’utilisation Consulter liste des stages

Pré-condition
La liste des stages est affichée

Post-condition

Scénario principal
Aucun.
Tableau 4.7 : Description détaillée du cas d’utilisation "Consulter liste des stages"
40
Cas d’utilisation Modifier stage

Pré-condition
Stage modifié
Post-condition

3/ Le responsable RH demande de modifier un stage.
Scénario principal 4/ Le système affiche le formulaire de modification.
7/Le système met à jour le stage et envoie un message de succès
Tableau 4.8 : Description détaillée du cas d’utilisation "Modifier stage"
Cas d’utilisation Supprimer stage

Pré-condition
Stage supprimé
Post-condition

Scénario principal
3/ Le responsable RH demande de supprimer un stage.
4/Le système supprime le stage et envoie un message de succès
Aucun.
41
Tableau 4.9 : Description détaillée du cas d’utilisation "Supprimer stage"
4.2.2.3 Raffinement du cas d’utlisation "Gérer les emplois"
Gérer les emplois comprend un certain nombre de scénarios à savoir : ajouter emploi et
consulter la liste des emplois afin de mettre à jour et supprimer un emploi. La figure 4.6 décrit
d’une manière détaillée le cas d’utilisation "Gérer les emplois”, suivie par les tableaux décrivant
le scénario de chaque cas d’utilisation.
Figure 4.6 : Diagramme de cas d’utilisation "Gérer les emplois"
Cas d’utilisation Ajouter emploi

Pré-condition
Emploi ajouté
Post-condition
42
1/ Le responsable RH demande d’afficher la liste des emplois.

2/ Le système affiche la liste des emplois.
3/ Le responsable RH demande d’ajouter un emploi.
Scénario principal 4/ le système affiche le formulaire de création.
7/Le système ajoute un emploi et envoie un message de succès
Tableau 4.10 : Description détaillée du cas d’utilisation "Ajouter emploi"
Cas d’utilisation Consulter liste des emplois

Pré-condition
La liste des emplois est affichée

Post-condition

Scénario principal
Aucun.
Tableau 4.11 : Description détaillée du cas d’utilisation "Consulter liste des emplois"
Cas d’utilisation Modifier emploi

Pré-condition
Emploi modifié
Post-condition
43

3/ Le responsable RH demande de modifier un emploi.
4/ Le système affiche le formulaire de modification.
Scénario principal
7/Le système met à jour l’emploi et envoie un message de
succès
Tableau 4.12 : Description détaillée du cas d’utilisation "Modifier emploi"
Cas d’utilisation Supprimer emploi

Pré-condition
Emploi supprimé
Post-condition

Scénario principal
3/ Le responsable RH demande de supprimer un emploi.
4/Le système supprime l’mploi et envoie un message de succès
Aucun.
Tableau 4.13 : Description détaillée du cas d’utilisation "Supprimer emploi"
4.2.3 Diagramme de classes du sprint
Le diagramme de classes d’analyse est une manière statique de représenter les éléments
qui constituent un système et leurs relations. Le diagramme de classes correspondant au sprint
44
”Gérer les offres de travail” est illustré par la figure 4.7.
Figure 4.7 : Diagramme de classes du sprint "Gérer les offres de travail"
4.3 Sprint 2 : Gérer la première phase de recrutement

Durant cette section, nous présentons le deuxième sprint ayant comme but la gestion de la
première phase du recrutement. Nous allons élaborer le backlog du sprint, suivi des diagrammes
réalisés durant ce sprint.
45
Le backlog de ce sprint est exposé dans le tableau 4.14. Nous notons que l’unité d’estimation
du temps dans le Sprint Backlog est le jour.

3 3.1 En tant que 3.1.1 Afficher la liste des départements 5 jours
candidat, je veux pour le candidat
postuler pour une
offre de travail.
3.1.2 Affichage de la liste des stages pour le 3 jours
candidat
3.1.3 Affichage de la liste des emplois pour 1 jour
le candidat
3.1.4 Création d’une candidature 4 jours
3.2 En tant que 3.2.1 Création d’une candidature. 1 jour
responsable RH,
je veux gérer les
candidatures à la
première phase de
la procédure de
recrutement afin
d’assurer le bon
déroulement du
processus.
3.2.2 Affichage des détails des 1 jour
candidatures.
3.2.3 Suppression d’une candidature. 1 jour
3.2.4 Mettre à jour les informations d’une 1 jour
candidature.
3.2.5 Convertir un candidat dans la 2 jours
première phase.
46
3.3 En tant que 3.3.1 Passer le test par le candidat 3 jours

candidat, je peux
passer un test
technique afin
de continuer le
processus.
3.4 En tant que 3.4.1 Afficher la liste des tests validés et 1 jour
responsable RH, je non validés
veux consulter les
tests afin d’organiser
le processus.
3.4.2 Afficher les détails d’un test 1 jour
Tableau 4.14 : Backlog de sprint 2
Le candidat postule pour un stage ou emploi puis passe un test. De l’autre côté, le
responsable RH interagit avec l’application, afin de gérer les candidats dans la première phase
et consulte les tests passés. Ces cas d’utilisation sont représentés dans le diagramme de cas
d’utilisation de la figure 4.8.
Figure 4.8 : Diagramme de cas d’utilisation "Gérer la première phase du recrutement"
47
4.3.2.1 Raffinement du cas d’utlisation "Postuler pour un stage ou un

emploi"
Postuler pour un stage ou un emploi comprend un scénario expliqué par le diagramme

de cas d’utlisation présenté dans la figure 4.9 ainsi que les deux tableaux 4.15 et 4.16.
Figure 4.9 : Diagramme de cas d’utilisation "Postuler pour un stage ou un emploi"
Cas d’utilisation Afficher la liste des stages et des emplois

Acteur Candidat
Ouvrir le catalogue des offres
Pré-condition
Liste des stages ou emplois affichée.

Post-condition
1/ Le candidat demande d’afficher la liste des départements.

3/ Le candidat demande d’afficher la liste des offres de stages
Scénario principal
ou d’emplois
4/ Le système affiche la liste des offres de stages ou d’emplois
Aucun.
Tableau 4.15 : Description détaillée du cas d’utilisation "Afficher la liste des stages et des
emplois"
48
Cas d’utilisation Postuler pour un stage ou emploi

Acteur Candidat
Liste des stages ou emplois affichée
Pré-condition
Candidature acceptée
Post-condition
1/ Le candidat choisit un stage ou emploi

2/ Le système affiche le formulaire de création d’une
candidature.
Scénario principal 3/ Le candidat remplit les champs du formulaire.
5/ Le système accepte la candidature et envoie un message de
succès
Le système affiche un message d’erreur lorsqu’il trouve l’une
Scénario d’exception des conditions de création d’une candidature non vérifiéé.
Tableau 4.16 : Description détaillée du cas d’utilisation "Postuler pour un stage ou

emploi"
4.3.2.2 Raffinement du cas d’utlisation "Gérer les candidats de la première

phase"
Gérer les candidats de la première phase comprend un certain nombre de scénarios à

savoir : ajouter un candidat, consulter la liste des candidats afin de mettre à jour et supprimer
un candidat. La figure 4.10 décrit d’une manière détaillée le cas d’utilisation "Gérer les candidats
de la permiére phase ” suivie par les tableaux décrivant le scénario de chaque cas d’utilisation.
49
Figure 4.10 : Diagramme de cas d’utilisation "Gérer candidats de la première phase"
Cas d’utilisation Ajouter candidat

Pré-condition
Candidatajouté
Post-condition
1/ Le responsable RH demande d’afficher la liste des candidats

de la première phase.
2/ Le système affiche la liste des candidats.
3/ Le responsable RH demande d’ajouter un candidat.
7/Le système ajoute un candidat et affiche un message de
succès
Tableau 4.17 : Description détaillée du cas d’utilisation "Ajouter candidat"
50
Cas d’utilisation Consulter liste des candidats de la première phase

Pré-condition
La liste des candidats de la première phase est affichée

Post-condition

Scénario principal à la phase une.
2/ Le système affiche la liste des candidats à la première phase.
Aucun.
Tableau 4.18 : Description détaillée du cas d’utilisation " Consulter liste des candidats à
la phase une "
Cas d’utilisation Modifier candidat à la première phase

Pré-condition

à la première phase.
3/ Le responsable RH demande de modifier un candidat.
Post-condition 4/ le système affiche le formulaire de modification.
7/Le système met à jour le candidat et envoie un message de
succès
51
Tableau 4.19 : Description détaillée du cas d’utilisation "Modifier candidat à la première

phase"
Cas d’utilisation Supprimer candidat à la première phase

Pré-condition
Candidat à la première phase supprimé

Post-condition

Scénario principal
3/ Le responsable RH demande de supprimer un candidat.
4/Le système supprime le candidat et envoie un message de
succès
Aucun.
Tableau 4.20 : Description détaillée du cas d’utilisation "Supprimer candidat à la

première phase"
Cas d’utilisation convertir candidat

Pré-condition
52

3/ Le responsable RH demande d’afficher les donnés relatives
à un candidat.
Post-condition
4/ Le système affiche les détails d’un candidat.
5/ Le responsable RH demande la conversion d’un candidat
6/Le système vérifie la possibilité de conversion.
7/Le système met à jour le candidat et retourne un message
de succès
Scénario d’exception données manquantes ou un flow qui freine le processus.
Tableau 4.21 : Description détaillée du cas d’utilisation "convertir un candidat"
4.3.2.3 Raffinement du cas d’utlisation "Passer un test"
Passer un test comprend un scénario expliquer dans le diagramme de cas d’utlisation

présenté par la figure 4.11 et le tableau 4.22.
Figure 4.11 : Diagramme de cas d’utilisation "Passer un test"
53
cas d’utilisation Passer un test

Acteur Candidat
Email contenant le test envoyé
Pré-condition
Test soumis.
Post-condition
1/ Le candidat demande d’afficher le test

2/ Le système affiche un petit formulaire.
3/ Le candidat remplit le formulaire.
Scénario principal 3/ Le système vérifie les données.
4/Le système affiche le test.
5/ Le candidat remplit le test.
6/ Le système ajoute un test et envoie un message de succès.
Le système affiche un message d’erreur si l’email du candidat
Scénario d’exception à été déja utilisé pour passer un test.
Tableau 4.22 : Description détaillée du cas d’utilisation "Passer un test"
4.3.2.4 Raffinement du cas d’utlisation "Consulter les tests"
Consulter un test comprend un scénario expliquer, dans le diagramme de cas d’utlisation,

illustré par la figure 4.12 et les deux tableaux ci-dessous.
Figure 4.12 : Diagramme de cas d’utilisation "Consulter les tests"
54
Cas d’utilisation Afficher la list des tests

Pré-condition
Liste des tests affichée.

Post-condition
1/ Le responsable RH demande d’afficher la liste des tests.

Scénario principal 2/ Le système affiche la liste des tests.
Aucun.
Tableau 4.23 : Description détaillée du cas d’utilisation "Gérer la première phase du

recrutement"
Cas d’utilisation Afficher les détails d’un test

Pré-condition
Détails de test affichée

Post-condition
1/ Le responsable RH demande l’affichage de la liste des tests.

2/ Le système affiche la liste des tests.
Scénario principal 3/ Le responsalbe RH choisit un test spécifique.
4/Le système affiche les détails du test spécifique.
Scénario d’exception Aucun.
Tableau 4.24 : Description détaillée du cas d’utilisation "Afficher les détails d’un test"
4.3.3 Diagrammes de séquences du sprint
Dans cette section, nous présentons les diagrammes de séquence, objet des cas d’utilisation
de ce sprint. De ce fait, les diagrammes de séquence objet sont la visualisation graphique des
55
échanges entre les acteurs et les objets dans un ordre chronologique.
4.3.3.1 Diagramme de séquences "Postuler dans un stage ou poste de

travail"
La figure 4.13 représente le scénario du diagramme de cas d’utilisation "Postuler dans

un stage ou poste de travail".
Figure 4.13 : Diagramme de séquences "Postuler dans un stage ou poste de travail"
4.3.3.2 Diagramme de séquences "Passer un test"
La figure 4.14 représente le scénario du diagramme de cas d’utilisation ”Passer un test".
56
Figure 4.14 : Diagramme de séquences "Passer un test"
Le diagramme de classes correspondant au sprint ”Gérer la phase une du recrutement”

est illustré par la figure 4.15.
57
Figure 4.15 : Diagramme de classes du sprint "Gérer la première phase du recrutement"
4.3.5 Diagramme d’activités du sprint
Les diagrammes d’activités sont employés pour représenter les flux de travail au sein
d’un système, du niveau métier au niveau opérationnel. Ils permettent de décrire tout type
de processus tels que : les processus métier, les processus industriels, le déroulement d’un cas
d’utilisation, etc. Dans ce cadre, nous avons conçu un diagramme d’activité, présenté par la
figure 4.16, pour montrer le processus de recrutement dans sa première phase.
58
Figure 4.16 : Diagramme d’activités du sprint "Gérer la première phase du recrutement"
59
4.4 Sprint 3 : Gérer la deuxième phase du recrutement

Dans cette partie, nous présentons le 3ème sprint dont la finalité est de piloter la 2ème
phase du recrutement. Nous détaillons le backlog du sprint suivi des diagrammes réalisés durant
ce sprint.
Le backlog pour ce sprint est illustré dans le tableau 4.25. Nous remarquons que l’unité
de mesure dans le Sprint Backlog est en jours.

4 4.1 En tant 4.1.1 Affecter un interviewer à un candidat 1 jour
que manager, je
peux affecter les
interviewers à des
candidats afin
d’assurer le bon
déroulement du
processus.
4.2 En tant qu’ 4.2.1 Création d’un interview. 2 jours
interviewer, je
veux gérer les
interviews afin de
bien sélectionner les
candidats.
4.2.2 Affichage des détails d’un interview. 1 jour
4.2.3 Suppression d’un interview. 1 jour
interview.
4.2.4 Noter un interiew 1 jour
60
4.3 En tant que 4.3.1 Génération d’un contrat 6 jours

responsable RH,
je veux gérer les
contrats afin de
finaliser la procédure
de recrutement.
4.3.2 Suppression d’un contrat. 1 jour
4.3.3 Envoi d’un contrat 4 jours
4.4 En tant que 4.4.1 Affichage de la liste des feedbacks 2 jours
responsable RH,
je veux gérer
les feedbacks afin
d’analyser les avis
des candidats.
4.4.2 Suppression d’un feedback 1 jour
4.5 En tant que 4.5.1 Suppression d’un candidat 1 jour
Manager, je veux
gérer les candidats
de la deuxième phase
afin d’organiser
la procédure de
recrutement.
4.5.2 Consulter la liste des candidats 2 jours
4.5.3 Consulter les détails d’un candidat 1 jour
4.6 En tant que 4.6.1 Envoyer un feedback 7 jours
candidat de la 2ème
phase, je peux
envoyer un feedback
afin d’exprimer mon
avis sur le processus.
Tableau 4.25 : Backlog de sprint 3
61
La 2ème phase du recrutement est gérer par l’interviewer, le responsable RH et le

manager.Cette phase est illustrée par le cas d’utilisation de la figure 4.17.
Figure 4.17 : Diagramme de cas d’utilisation "Gérer la deuxième phase du recrutement"
4.4.2.1 Raffinement du cas d’utlisation "Affecter des interviews"
L’affectation d’un interviewer à un candidat comprend un scénario expliqué dans le

diagramme de cas d’utlisation ci-dessous et le tableau 4.26.
Figure 4.18 : Diagramme de cas d’utilisation "Affecter des interviews"
62
Cas d’utilisation Affecter des interviews

Acteur Manager
Ouvrir la liste des candidats convertis
Pré-condition
Interviewer affecté.
Post-condition
1/ Le candidat demande la liste des candidats en 2ème phase.

3/ Le Manager choisit un candidat et demande la modification
Scénario principal des données du candidat.
4/ Le système affiche le formulaire de modification.
5/ Le manager demande d’affecter un interviewer au candidat.
6/ Le système affecte l’interviewer.
Aucun.
Tableau 4.26 : Description détaillée du cas d’utilisation " Affecter des interviews "
4.4.2.2 Raffinement du cas d’utlisation "Gérer les interviews"
Gérer les interviews comprend un certain nombre de scénarios, à savoir ajouter un

interviewer, consulter la liste des interviews afin de mettre à jour ou supprimer un interview.
La figure 4.19 décrit d’une manière détaillée le cas d’utilisation "Gérer les interviews”, suivie
par les tableaux décrivant le scénario de chaque cas d’utilisation.
63
Figure 4.19 : Diagramme de cas d’utilisation "Gérer les interviews"
Cas d’utilisation Ajouter interview

Acteur Interviewer
Pré-condition
Interview ajouté
Post-condition
1/ L’interviewer demande d’afficher la liste des candidats de la

deuxième phase.
2/ Le système affiche la liste des candidats dans la deuxième
phase.
3/ L’interviewer demande d’afficher les détails d’un candidat.
4/ Le système affiche les données relatives à un candidat.
Scénario principal
5/ L’interviewer demande de créer un interview.
6/Le système affiche le formulaire de création
7/L’interviewer remplit le formulaire.
8/Le système vérifie les données.
9/Le système ajoute un interview et envoie un message de
succès
64

Tableau 4.27 : Description détaillée du cas d’utilisation "Ajouter interview"
cas d’utilisation Afficher les données relatives à un interview

Acteur Interviewer
Liste de candidats de la deuxième phase affichée
Pré-condition
Les détails d’interview affichés.

Post-condition
1/ L’interviewer demande d’afficher les données relatives d’un

candidat à la deuxième phase.
Scénario principal
3/ L’interviewer demande d’afficher les données relatives de
l’interview en liaison avec le candidat.
4/ Le système affiche les données relatives à l’interview.
Aucun.
Tableau 4.28 : Description détaillée du cas d’utilisation " Afficher les données relatives à
un interview "
Cas d’utilisation Supprimer interview

Acteur Interviewer
Liste des candidats affichée
Pré-condition
Interview supprimé
Post-condition
65
1/ L’interviewer demande d’afficher les détails d’un candidat

à la deuxième phase.
3/ Le système affiche les détails du candidat.
Scénario principal 3/ L’interviewer demande de supprimer l’interview relié au
candidat.
4/Le système supprime l’interview et envoie un message de
succès
Aucun.
Tableau 4.29 : Description détaillée du cas d’utilisation "Supprimer interview"
Cas d’utilisation Modifier interview

Acteur Interviewer
Pré-condition
Post-condition Interview modifié

deuxième phase.
2/ Le système affiche la liste des candidats dans la deuxième
phase.
3/ L’interviewer demande d’afficher les données relatives à un
candidat.
Scénario principal
5/ L’interviewer demande de modifier un interview.
6/Le système affiche le formulaire de modification
9/Le système met à jour l’interview et envoie un message de
succès
66

Tableau 4.30 : Description détaillée du cas d’utilisation "Modifier interview"
Cas d’utilisation Noter un interview

Acteur Interviewer
Interview modifié
Pré-condition
Post-condition Interview modifié

deuxième phase.
2/ Le système affiche la liste des candidats dans la phase deux.
3/ L’interviewer demande d’afficher les détails d’un candidat.
4/ Le système affiche les détails du candidat.
5/ L’interviewer demande de noter un interview.
Scénario principal
6/Le système affiche le formulaire de modification
9/Le système met à jour l’interview noté et envoie un message
de succès

Tableau 4.31 : Description détaillée du cas d’utilisation "Noter un interview"
4.4.2.3 Raffinement du cas d’utlisation "Gérer les feedbacks"
Gérer les feedbacks comprend un certain nombre de scénarios, à savoir : afficher la liste
des feedbacks et supprimer un feedback. La figure ci-dessous décrit d’une manière détaillée le
cas d’utilisation "Gérer les feedbacks” présenté par la figure 4.20, suivie par deux tableaux
67
décrivant le scénario de chaque cas d’utilisation.
Figure 4.20 : Diagramme de cas d’utilisation "Gérer les feedbacks"
Cas d’utilisation Afficher la liste des feedbacks

Authentification réussite
Pré-condition
Liste des feedbacks affichés

Post-condition
1/ Le responsable RH demande d’afficher la liste des feedbacks

Scénario principal
2/ Le système affiche la liste des feedbacks.
Aucun.
Tableau 4.32 : Description détaillée du cas d’utilisation " Afficher la liste des feedbacks "
Cas d’utilisation Supprimer feedback

Acteur responsable RH
Liste des feedbacks affichée
Pré-condition
Feedback supprimé
Post-condition
68
1/ L’interviewer demande d’afficher les détails d’un feedback.

3/ Le système affiche les détails du feedback.
3/ Le responsable RH demande de supprimer le feedback relié
Scénario principal
au candidat.
4/Le système supprime le feedback et envoie un message de
succès.
Aucun.
Tableau 4.33 : Description détaillée du cas d’utilisation "Supprimer feedback"
4.4.2.4 Raffinement du cas d’utlisation "Gérer candidats de la deuxième

phase"
Gérer les candidats de la deuxième phase comprend un certain nombre de scénarios, à

savoir : consulter la liste des candidats afin d’afficher les détails et supprimer un candidat. La
figure 4.21 décrit d’une manière détaillée le cas d’utilisation "Gérer les candidats de la deuxième
phase” suivi par les tableaux décrivant le scénario de chaque cas d’utilisation.
Figure 4.21 : Diagramme de cas d’utilisation "Gérer candidats de la deuxième phase"
69
Cas d’utilisation Supprimer candidat à la deuxième phase

Acteur Manager
Pré-condition
Candidat à la deuxième phase supprimé

Post-condition
1/ Le Manager demande d’afficher la liste des candidats à la

deuxième phase.
Scénario principal
3/ Le Manager demande de supprimer un candidat.
4/Le système supprime le candidat et envoie un message de
succès
Aucun.
Tableau 4.34 : Description détaillée du cas d’utilisation "Supprimer candidat à la

deuxième phase"
Cas d’utilisation Consulter liste des candidats à la deuxième phase

Acteur Manager
Pré-condition
La liste des candidats de la deuxième phase est affichée

Post-condition

Scénario principal deuxième phase.
2/ Le système affiche la liste des candidats à la deuxième phase.
Aucun.
Tableau 4.35 : Description détaillée du cas d’utilisation " Consulter liste des candidats à
la deuxième phase "
70
Cas d’utilisation Consulter les données relatives à un candidat

Acteur Manager
Pré-condition
Les détails du candidat sont affichés

Post-condition

deuxième phase.
2/ Le système affiche la liste des candidats à la deuxième phase.
Scénario principal
3/ Le Manager demande d’afficher les données relatives à un
candidat.
Aucun.
Tableau 4.36 : Description détaillée du cas d’utilisation " Consulter les données relatives
à un candidat "
4.4.2.5 Raffinement du cas d’utlisation "Envoyer un feedback"
Envoyer un feedback comprend un scénario expliquer dans le diagramme de cas d’utlisation

présenté par la figure 4.22 suivi par le tableau 4.37.
Figure 4.22 : Diagramme de cas d’utilisation "Envoyer un feedback"
71
Cas d’utilisation Envoyer un feedback

Acteur Candidat
Email contenant le formulaire envoyé
Pré-condition
Test soumis.
Post-condition
1/ Le candidat demande d’afficher le formulaire

2/ Le système affiche un champ à remplir.
3/ Le candidat remplit le champ.
3/ Le système vérifie les données.
Scénario principal
4/ Le système affiche le formulaire du feedback.
5/ Le candidat remplit le formulaire du feedback.
6/ Le système ajoute un feedback et envoie un message de
succès.
Aucun
Tableau 4.37 : Description détaillée du cas d’utilisation "Envoyer un feedback"
4.4.3 Diagramme de séquences du sprint
La figure 4.23 représente le scénario du diagramme de cas d’utilisation ”Envoi de feedback"
72
Figure 4.23 : Diagramme de séquences "Envoi de feedback"
Le diagramme de classes correspondant au sprint ”Gérer la deuxième phase du recrutement”

est présenté par la figure 4.24.
73
Figure 4.24 : Diagramme de classes du sprint "Gérer la deuxième phase du recrutement"
4.4.5 Diagramme d’activités du sprint
Nous avons élaboré un diagramme d’activité, présenté par la figure 4.25, pour mieux
visualiser le processus de recrutement dans sa deuxième phase.
74
Figure 4.25 : Diagramme d’activités du sprint "Gérer la deuxième phase du recrutement"
75
4.5 Sprint 4 : Pilotage du reporting et tableau de bord
/ Gérer les utilisateurs et les droits d’accès

Dans cette section, nous exposons le 4ème sprint dont l’objectif est la gestion des droits
d’accès et la manipulation de la partie reporting illustrée par des tableaux de bord. Suite à la
présentation du backlog du sprint, nous exposons les diagrammes réalisés lors de ce sprint.
Le backlog de ce sprint est indiqué dans le tableau 4.38. Nous constatons que l’unité de
mesure du Sprint Backlog est le nombre de jours.
IDF User Stroy ID tâche Estimation

1 1.1 En tant que 1.1.1 Ajouter un utilisateur. 2 jours
Responsable RH,
je veux gérer les
utilisateurs afin de
limiter l’accès à
l’application
1.1.2 Modifier un utilisateur. 0.5 jour
1.1.3 Activer un utilisateur. 0.5 jour
1.1.4 Désactiver un utilisateur. 0.5 jour
1.2 En tant que 1.2.1 Ajouter les profils 0.5 jour
Responsable RH,
je veux gérer les
droits d’accès afin de
garantir la sécurité
de l’application.
1.2.2 Ajouter les rôles. 0.5 jour
1.2.3 Ajouter les groupes utilisateurs. 0.5 jour
1.2.4 Ajouter les autorisations d’accès. 1 jour
76
5.1 En tant 5.1.1 Consulter le tableau de bord des 1 jour

que responsable candidats
RH, Manager ou
Interviewer, je veux
consulter tous les
tableaux de bord.
5.1.2 Consulter le tableau de bord des tests 4 jours
5.1.3 Consulter le tableau de bord des 1 jour
stages et des emplois
5.1.4 Consulter le tableau de bord des 1 jour
feedbacks
Tableau 4.38 : Backlog du sprint 4
4.5.2.1 Raffinement du cas d’utlisation "Gérer les utilisateurs et les

droits d’accès"
Le responsable RH est celui qui admet un accès illimité à l’application. Ainsi, il peut
gérer les utilisateurs et les droits d’accès. Cette gestion est représentée dans le diagramme de
cas d’utilisation de la figure 4.26.
Figure 4.26 : Diagramme de cas d’utilisation "Gérer les utilisateurs et les droits d’accès"
77
-Raffinement du cas d’utlisation "Gérer les utilisateurs"

L’administrateur est celui qui permet de gérer les utilisateurs de l’application. Il peut ajouter,
consulter la liste des utilisateurs afin de modifier, activer ou désactiver un utilisateur. La figure
4.27 représente le diagramme de cas d’utilisation "Gérer les utilisateurs”
Figure 4.27 : Diagramme de cas d’utilisation "Gérer les utilisateurs"
-Raffinement du cas d’utlisation "Pilotage du reporting et tableau de bord"

Les responsables interagissent avec l’application afin de consulter les différents tableaux de bord
et visualiser les informations. La figure 4.28 représente ce diagramme de cas d’utilisation.
Figure 4.28 : Diagramme de cas d’utilisation "Pilotage du reporting et tableau de bord"
78
4.5.3 Diagramme de classe complet
Le diagramme global de notre projet est repris dans la figure 4.29.
Figure 4.29 : Diagramme de classe complet"
Conclusion
Nous avons traité dans ce chapitre les divers aspects conceptuels de l’application. Nous
avons commencé par présenter l’architecture globale, à savoir l’architecture physique et l’architecture
logicielle. Ensuite, nous avons détaillé les différents sprints du projet. Le prochain chapitre sera
dédié à la partie réalisation.
79
Chapitre 5
Réalisation
Introduction
Après avoir exposé la conception de notre solution, nous traitons dans ce chapitre
la dernière partie de ce travail, qui vise à exposer la phase de réalisation. Cette phase est
considérée comme la concrétisation définitive de la démarche de conception. Tout d’abord,
nous présentons l’environnement de développement où nous indiquons les ressources logicielles
utilisées. Ensuite, nous présentons certaines interfaces réalisées pour expliquer le déroulement
de certaines opérations de l’application développée.
5.1 Choix technique
5.1.1 Outils et langages de développement
• Apex : Apex est un langage de développement orienté objet, qui enregistre, compile et
exécute sur le serveur Lightning Platform.
Il admet une syntaxe semblable à Java et se comporte comme des procédures stockées
dans une base de données.
Il permet aux développeurs d’exécuter des instructions de contrôle de flux et de transactions

sur le serveur de la plateforme Salesforce [8].
• Visualforce : Visualforce est un framework permettant aux développeurs d´élaborer des

interfaces utilisateur personnalisées qui peuvent être hébergées sur Lightning Platform.
Il comprend un langage de balisage fondé sur des balises, similaire à HTML et peut être
intégré avec n’importe quelle technologie Web standard ou infrastructure JavaScript pour
créer une interface utilisateur plus animée et plus riche [9].
• Lightning web component : C’est un nouveau modèle de programmation pour la
80
Chapitre 5. Réalisation
création des composants Lightning qui sont des éléments HTML personnalisés construits
à l’aide du HTML et du JavaScript moderne [10].
• Visual Studio Code : Visual Studio est un éditeur de code source livré avec un support
intégré pour JavaScript, TypeScript et Node.js et possède un riche écosystème d’extension
pour d’autres langages (tels que C ++, C , Java, Python, PHP, Go) et des runtimes (.NET
et Unity) [18].
5.1.2 Outils de modélisation
• StarUML : est un logiciel de modélisation UML, qui a été publié, en open source, par
son éditeur, au moment de l’exploitation commerciale sous licence GNU GPL [19].
5.1.3 Outils d’intégration des données
• Talend Data Integration :C’est un éditeur de logiciel spécialisé dans l’intégration des
données. Il permet de créer un ETL et de visualiser son architecture de façon graphique.
La particularité de ETL est qu’il génère le code Java pour chaque traitement d’intégration
de données. Nous avons utilisé cet outil afin d’intégrer les données des prospects provenant
de différents partenaires dans l’application [20].
5.1.4 Outils de gestion du projet
• GitLab : GitLab est une plateforme de développement collaborative, elle se présente

comme une alternative de GitHub . Cependant, ce dernier peut être utilisé s’il n’existe
pas une collaboration avec des développeurs externes à l’équipe. Donc il permet d’accélérer
le flux de travail de l’équipe.
Nous avons utilisé GitLab dans notre projet afin de réaliser des dépôts et de gérer les
versions de nos codes sources [21].
• Trello : Trello est un outil en ligne qui facilite la planification et la gestion des tâches du
projet. Il permet de présenter les tâches du projet, comme étant un tableau de bord, en
classant les activités de l’équipe selon leur état (en cours, terminée, suspendue, etc.) et
avec la mention des personnes qui travaillent sur ces activités et une estimation du temps
nécessaire.
Vu que nous avons travaillé avec la méthodologie SCRUM, nous avons eu recours à cet
81
outil pour bien planifier les tâches entre les membres de l’équipe [22].
5.2 Description de l’application

Dans cette partie, nous allons présenter les différentes interfaces du projet. En effet, le
projet consiste en 4 parties réparties comme dans les sprints. La première partie concerne la
gestion des offres de travail qui contient la gestion des départements, offres de travail et stages.
La deuxième partie concerne le site externe où les candidats peuvent postuler, ainsi que la
gestion des candidats dans leur première phase. La troisième phase contient la deuxième phase
des candidatures avec les différentes étapes qui sont les entretiens, les feedbacks et les contrats.
La quatrième partie concerne la partie des tableaux de bord.
5.2.1 Gestion des postes
Le responsable RH gère les départements. La liste des départements est affichée dans un
tableau comme le montre la figure 5.1.
Figure 5.1 : Interface interne contenant la liste des départements
Tous les acteurs peuvent consulter les départements, les stages et les emplois et accéder
à leurs détails en consultant l’interface conformément à la figure 5.2 ci-dessous.
82
Figure 5.2 : Détails d’un département
. De même pour les stages et les offres d’emplois, le manager peut gérer les postes affichés
dans la figure 5.3.
Figure 5.3 : Interface contenant la liste des offres de travail
Il peut aussi consulter la liste des stages et offres d’emplois dans les détails, comme le
montre la figure ci-dessus. L’interface indiquant les détails d’un poste contient la liste de des
postulants concernés. L’ajout d’un offre de travail par exemple se fait à l’aide du modal présent
dans la figure 5.4.
83
Figure 5.4 : Formulaire de création de poste
5.2.2 Première phase de recrutement
La première phase commence par le candidat, qui va consulter l’interface, qui contient
la liste des départements exposée dans la figure 5.5.
Figure 5.5 : Interface liste des départements pour le candidat
Le client va choisir de voir soit la liste des stages, soit la liste des offres d’emplois d’un
département, comme l’indique la figure 5.6.
84
Figure 5.6 : Interface Postes de travail pour le candidat
Il va ensuite remplir le formulaire présenté par la figure 5.7 pour postuler.
Figure 5.7 : Formulaire de recrutement pour le candidat
En postulant, une nouvelle candidature va être créée. Une notification sera envoyée à
l’équipe de recrutement comme le montre la figure 5.8.
85
Figure 5.8 : Notification lorsque le candidat postule
Le candidat va être affiché dans le tableau des candidats exposé dans la figure 5.9 qui
contient tous les candidats filtrés selon leur étape actuelle.
Figure 5.9 : Interface de la liste des candidats
Tous les acteurs peuvent consulter les candidats et les données qui leur concernent.
Seul le responsable RH peut créer, modifier ou supprimer un candidat. En consultant les
données relatives à un candidat à la première phase, on constate que les étapes du processus de
recrutement de cette phase sont affichées dans un composant, qui indique aussi l’étape actuelle
du postulant. Le parcours de ces étapes se fait automatiquement au cours du processus comme
le montre la figure 5.10.
86
Figure 5.10 : Détails d’un candidat à la première phase
Au cours de la phase ‘open-email sent’, un email présenté par la figure 5.11, est envoyé
au candidat pour l’informer de la réception de sa candidature.
Figure 5.11 : Premier email envoyé au candidat
Après 12 heures du premier email, un deuxième contenant un test technique sera envoyé,
comme l’indique la figure 5.12.A l’instant, le candidat sera automatiquement converti à l’étape
‘Working - Test Sent’.
87
Figure 5.12 : Email du test technique
En accédant au mail, le candidat peut passer le test. Avant tout, en accédant sur
l’interface, le candidat doit saisir son email comme le montre la figure 5.13 et le système doit
vérifier l’existence d’une candidature ayant cette adresse.
Figure 5.13 : Contrôle d’accès à l’interface du test technique
Si la candidature existe, l’interface ci-dessous va être affichée et le candidat passera le

test présent dans la figure 5.14.
88
Figure 5.14 : Interface du test technique
Selon le résultat, si le candidat réussit son test, il sera converti à un candidat de la phase
2 sinon il ne sera pas converti et il va sortir du processus. Sa phase est dans ce cas ‘Failed-Not
Converted’. Un email sera transmis dans les deux cas.La figure 5.15 montre les emails envoyés.
Figure 5.15 : Emails des résultats du test technique
Deux tableaux accessibles à l’équipe de recrutement montrant les candidats qui ont passé
le test technique en précisant leurs résultats, ainsi que ceux qui ne l’ont pas encore fait. Ces
tableaux sont présentés par la figure 5.16.
89
Figure 5.16 : Tableaux des tests techniques
Un dernier point important à mentionner dans la première phase est le CV du candidat,

affiché dans les données relatives à un candidat avec la possibilité de téléchargement du document,
comme présent dans la figure 5.17.
Figure 5.17 : Exemple d’un CV de candidat
90
5.2.3 Deuxième phase de recrutement
Les candidats qui passent à la deuxième phase sont gérés par l’interviewer, le responsable
RH et le manager. Ce dernier affecte un interviewer à une opportunité. La candidature va ensuite
passer par des étapes présentes dans la figure 5.18.
Figure 5.18 : Etapes de candidature de la deuxième phase
L’interviewer va donc arranger un entretien avec le candidat en remplissant le formulaire

de la figure 5.19.
Figure 5.19 : Formulaire de création d’un entretien
Le candidat va passer alors après la création d’un entretien à la phase suivante qui est
‘interview scheduled’ .
Après l’entretien, le statut du candidat sera ‘interview passed’. L’interviewer va alors
évaluer le candidat et selon cette évaluation le candidat va, soit passer à l’étape suivante, qui
est ‘Applicant Accepted’, soit être éliminé du processus et son statut sera ‘Closed Lost’. Dans
les deux cas, un email sera envoyé contenant un lien vers l’interface du feedback.Les emails
envoyés sont présentés dans la figure 5.20.
91
Figure 5.20 : Emails envoyés après l’entretien
Les candidats peuvent donc accéder à l’interface des feedbacks pour donner leurs avis
sur le processus de recrutement.Ceci est présenté par la figure 5.21.
Figure 5.21 : Interface du feedback pour le candidat
Les feedbacks sont gérés par le responsable RH qui accède aux feedbacks, à l’aide de
l’interface représentée dans la figure 5.22.
92
Figure 5.22 : Interface de la liste des feedbacks
Le responsable RH va gérer les candidatures acceptées en générant leurs contrats.La

figure 5.23 présente un exemple de contrat généré.
Figure 5.23 : Contrat du candidat
Après, il va envoyer le contrat au candidat accepté, comme le montre la figure 5.24. Le

statut du candidat change et devient ‘Contract Sent’.
93
Figure 5.24 : Email du contrat envoyé au candidat
.
Quand le candidat signe le contrat tel que le montre la figure 5.25, il passera au statut
‘Contract Signed’.
Figure 5.25 : Signature numérique du contrat
Si le candidat ne signe pas le contrat, le statut sera ‘Closed Lost’.

Dans le cas de signature, un email sera envoyé pour annoncer au candidat qu’il a
officiellement rejoint l’équipe comme le représente la figure 5.26.
94
Figure 5.26 : Email envoyé après la signature
Toutes les données des candidatures seront stockées une fois par semaine grâce à un job
sur Talend, représenté par la figure 5.27, qui relie Salesforce avec un fichier excel.
Figure 5.27 : Exportation des données Talend
5.2.4 Les tableaux de bord
Les tableaux de bord sont consultés par le responsable RH, le manager et l’interviewer
pour avoir une idée globale sur le processus. Dans la page d’accueil présentée la figure 5.28, on
trouve les statistiques sur les candidats.
95
Figure 5.28 : Tableau de bord des candidats
Dans la page contenant la liste des départements, on trouve le tableau de bord sur les
postes de travail de Talan représenté par la figure 5.29.
Figure 5.29 : Tableau de bord des départements
L’interface des tests contient des statistiques sur les tests et les candidats qui ont passé
le test, comme le montre la figure 5.30.
96
Figure 5.30 : Tableau de bord des tests
Enfin, l’interface des feedbacks visualise les données des feedbacks dans un tableau de
bord présenté par la figure 5.31.
Figure 5.31 : Tableau de bord des feedbacks
5.3 Planification du projet

Pour ordonnancer les tâches et visualiser l’avancement des différentes activités qui constituent
notre projet, il est nécessaire de réaliser un diagramme de Gantt. La figure 5.32 représente la
répartition des tâches faites tout au long de notre stage.
97
Figure 5.32 : Diagramme de Gantt
Conclusion
Dans ce chapitre, nous avons donné une brève description de l’environnement matériel et
logiciel du travail. Ensuite, nous avons présenté quelques interfaces graphiques de notre projet.
Enfin, nous avons présenté le déroulement de notre travail en utilisant le diagramme de Gantt.
Dans ce qui suit, nous clôturons ce rapport par une conclusion générale qui va résumer notre
travail ainsi qu’un aperçu sur les éventuelles perspectives qui peuvent l’enrichir.
98
Conclusion générale et perspectives
Tout au long de ce projet de fin d’études, nous avons été amenés à concevoir et implémenter
une solution Salesforce pour le processus de recrutement interne de Talan.
Ce projet a été réalisé en plusieurs phases. Suite à une première phase de recherche et d’apprentissage
relatives à Salesforce, nous avons spécifié les différents besoins de notre application, enchaînée
par une étude conceptuelle dans laquelle nous avons exposé les architectures utilisées et les
différents ”Sprints” réalisés. Ensuite, nous avons identifié les choix technologiques pour mettre
en œuvre enfin notre application.
Le résultat de notre travail est l’élaboration d’une application exécutable qui centralise les
données et gère le processus de recrutement sur la plateforme de Salesforce. Nous avons créé
également trois sites externes liés à cette application. Notre projet est réalisé conformément
aux standards de conception et de développement.
Le projet développé permet de gérer le nombre important de candidatures et les données
massives qui en découlent. Il permet aussi, de communiquer avec les candidats par email,
d’organiser, faciliter et automatiser le processus de recrutement, dès la réception de la candidature
jusqu’à la signature du contrat. Cette signature qui se fait d’une manière numérique et reçue
immédiatement dans notre application au moment où le candidat signe, témoigne de l’automatisation
de notre solution et du gain de temps qui en résulte. L’application permet de visualiser et
interpréter les données relatives au recrutement. Elle permet également de collecter les feedbacks
des candidats et offre ainsi à Talan la possibilité d’améliorer la qualité du processus.La réalisation
de ce projet n’était pas facile, puisque notre solution a été développée sur le PaaS de Salesforce.Ceci
a nécessité la personnalisation des fonctionnalités existantes et la création de nouvelles fonctionnalités
avec les langages et outils de Salesforce.
Ce stage a été une expérience riche aussi bien sur le plan technique que personnel, puisqu’il
a constitué une véritable préparation au monde professionnel. Il nous a permis de découvrir
la plateforme Salesforce et de s’intégrer au sein de l’équipe TALAN. Il nous a offert aussi une
bonne opportunité pour mettre en œuvre et consolider nos connaissances et notre formation
théorique acquises tout au long de notre cursus académique. D’un point de vue pratique, ce
travail nous a donné l’occasion de découvrir le fonctionnement des systèmes de configuration
et de développement de la plateforme Salesforce.
99
Enfin, comme perspectives à ce projet, nous proposons de :
• Développer la partie Talend de l’application, en offrant la possibilité d’extraire les données

de candidats potentiels à partir des réseaux sociaux tel que LinkedIn, pour les attirer aux
opportunités offertes par Talan.
• Enrichir la partie des tests dans la première phase de recrutement en les personnalisant
en fonction du niveau du postulant et l’opportunité proposée.Nous pensons aussi à offrir
la possibilité de générer des tests différents pour les candidats d’une même opportunité.
• Ajouter un module d’intelligence artificielle qui permet de filtrer les CVs selon les mots-
clés spécifiques à l’offre d’emploi proposée.
100
Webographie
[1] présentation Talan. [Disponible sur www.talan.com (consulté le 27 février 2022)].
[2] Scrum. [Disponible sur https ://medium.com/@vishal.marakana/agile-scrum-methodology

(consulté le 1 mars 2022)].
[3] PaaS de Salesforce. [Disponible sur https ://www.salesforce.com/fr/learning-centre/tech/paas/

[4] Statistique Salesforce App Run the world. [Disponible sur

https ://www.appsruntheworld.com/top-10-crm-software-vendors-and-market-forecast/
[5] Statistique Salesforce Gartner. [Disponible sur https ://www.salesforce.com/news/stories/

[6] architecture Salesforce. [Disponible sur Davis, Andrew. "Salesforce."Mastering Salesforce

DevOps. Apress, Berkeley, CA, 2019.15-25.].
[7] Modélisation de données. [Disponible sur Harris, Parker. ”Salesforce. com.” (consulté le
20 mars 2022)].
[8] Apex. [Disponible sur Appleman, Dan. Advanced Apex Programming in Salesforce.
Desaware Publishing, 2018.(consulté le 21 mars 2022)].
[9] Visualforce. [Disponible sur https ://trailhead.salesforce.com/fr/content/learn/modules/

visualforcef undamentals(consultle21mars2022)].
[10] Lightning. [Disponible sur https ://trailhead.salesforce.com/fr/content/learn/modules/

lexd evl cb asics/lexd evl cb asicsi ntro(consultle21mars2022)].
[11] manipulation des données. [Disponible sur Wicherski, Michael. ”Structure of Data.”
Beginning Salesforce Developer. Apress,Berkeley, CA, 2017. 39-64.(consulté le 24 mars
2022)].
[12] workflows. [Disponible sur https ://trailhead.salesforce.com/content/learn/modules/

businessp rocessa utomation(consultle24mars2022)].
[13] workflow exemple. [Disponible sur https ://www.newfangled.com/

creating-salesforce-workflow-rules/ (consulté le 27 mars 2022)].
101
Webographie
[14] Process builder. [Disponible sur https ://focusonforce.com/configuration/

salesforce-process-builder-example/ (consulté le 27 mars 2022)].
[15] Byblos. [ disponible dans un rapport interne de l’ERP Talan ].
[16] Architecture physique Salesforce. [Disponible sur https ://www.developerforce.com/guides/fr/

apexf r(consultle10avril2022)].
[17] Architecture logicielle Salesforce. [Disponible sur https ://developer.salesforce.com/forums

(consulté le 10 avril 2022)].
[18] Visual Studio Code. [Disponible sur https ://code.visualstudio.com/ (consulté le 28 avril
2022)].
[19] StarUML. [Disponible sur https ://staruml.io/(consulté le 28 avril 2022)].
[20] Talend. [Disponible sur BOWEN, Jonathan. Getting started with talend open studio for
data integration. Packt Publishing Ltd, 2012. (consulté le 30 avril 2022)].
[21] Gitlab. [Disponible sur ENGWALL, Keith et ROE, Mitchell. Git and GitLab in library
website change management workflows. Code4Lib Journal, 2020, no 48. (consulté le 1 may
2022)].
[22] Trello. [Disponible sur https ://trello.com/ (consulté le 1 may 2022)].
102
Résumé
Ce rapport est le résultat de notre travail effectué dans le cadre du stage de fin d’études pour
l’obtention du diplôme national d’ingénieur en informatique.Il a été réalisé au sein de Talan
Tunisie Consulting. Notre projet consiste à concevoir et développer une solution Salesforce
interne à Talan pour l’organisation des différentes phases de recrutement. Cette solution permet
l’automatisation et le bon déroulement de ce processus important pour le développement des
ressources humaines et la continuité de la société. Les principaux objectifs de l’élaboration de
cette solution, est de mettre en place un processus de recrutement enchaîné, de préserver la bonne
image de Talan auprès des postulants et de gérer un nombre très important de candidatures en
assurant des recrutements de qualité.Pour la réalisation de cette solution, nous avons utilisé
différents outils d’automatisation et langages de programmation de Salesforce.
Mots clés : Recrutement, Automatisation, Satisfaction candidats, Salesforce.
Abstract
This report is the result of our work as part of the internship for the National Diploma in
Computer Science Engineering, which was conducted within Talan Tunisia Consulting. Our
project consists in designing and developing a Salesforce internal solution to Talan in order to
organize,optimize and automate the recruitment phase. The goal behind the creation of this
Salesforce application is to set up a clear and chained recruitment process, to preserve Talan’s
brand and to manage the massive number of applications while ensuring a good quality of
recruitment. To make this project happen,we used different automation tools and programming
languages of Salesforce.
Keywords : Recruitment, automation,candidates satisfaction,Salesforce.

PÌl
xdnh AhJ Yl wOl TF Cd T§Ah ¤rK CAV ¨ znm m` r§rqt @¡ Pl§
r§wW ¤ CwO ¨ ¤rKm @¡ mt§¤ . Hwt- ¯AV TrK £EA ©@ Ty®³ ¨
rm y\nt Ð¤ xCwfsAF A\ Yl dmt`§ ©@ ¤ Hwt- ¯AV TrK QA ¨l
,Tmhm Tlrm £@¡ Yl HlF d` ºAfR³ Trb £@¡ dh ¤ .yZwt Tylm` Tfltm
.TsF¥m Twm§ AmR¤ T§rKb C wm r§wW Ð¤ ,yZwt Tlr ¨¡¤ ¯
Yl T\Am ¤ ,slst yZw A\ zyr ¨ ,Trb £@h Tysy¶r d¡± mt ¤
K AW ryb d C ³¤ K yAb «d Hwt- ¯AV TrK dy Cw}
Tfltm ¨µ yKt ¤ Am`tF¯ At ,TqybWt £@¡ EA³¤ .yKt w AmR
xCwfsAF TOn Yl rwtm Trb A¤
,yJrtm ARC ,¨µ yKt ,yZwt ,xCwfsAF y Afm Amlk

E5er Version 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

E5er Version 1

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Université de Tunis el Manar

Faculté des Sciences de Tunis

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Génie Informatique

Spécialité : Système d’information d’aide à la décision

Mise en place d’une platforme RH afin

Encadrant professionnel (Talan) : M. Marwen CHNITI

Réalisé au sein de Talan

Année Universitaire : 2021-2022

Mme. Zouhour BEN DHIAF

nous ont quitté trop tôt.

A ma mère, Sihem, à mon père Rabeh,

Pour leurs sacrifices et leurs qualités humaines

À ma chère sœur Rania qui m’a toujours souhaité le meilleur.

À mon cher département ‘SAIYANS’ au sein d’AIESEC, au bureau exécutif de

À tous mes amis

Il m’est agréable, avant de présenter ce travail, d’exprimer toute ma gratitude envers

Ma parfaite reconnaissance à Mme. Imen SEBEI, directrice du département Talan Salesforce,

Mes vifs remerciements, accompagnés de toute ma gratitude, s’adressent également à Mme

Il m’est aussi agréable d’exprimer ma reconnaissance respectueuse à tous les enseignants de

2 Concepts fondamentaux de Salesforce 10

1.1 Organigramme de Talan Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Classement des outils de CRM [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 L’application Byblos [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Architecture physique [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.15 Diagramme de classes du sprint "Gérer la première phase du recrutement" . . . 58

5.1 Interface interne contenant la liste des départements . . . . . . . . . . . . . . . . 82

2.1 Description des principaux objets standards . . . . . . . . . . . . . . . . . . . . 15

3.1 Les acteurs du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

une bonne compréhension de Salesforce et de ses langages de programmation, frameworks et

— Le deuxième chapitre "Concepts fondamentaux de Salesforce" présente les notions

— Le quatrième chapitre intitulé "Conception" détaillera, en premier lieu, l’architecture

— Le cinquième chapitre qui a pour titre "”Mise en œuvre" présentera l’environnement

Enfin, la conclusion générale présentera un bilan récapitulatif de notre solution et d’éventuelles

1.1 Présentation de l’organisme d’accueil

1.1.1 Talan Tunisie Consulting

— Le développement Java EE, Open source et .Net.

— Le développement d’applications Mobile.

— L’intégration de progiciels de Billing et CRM [1].

1.1.2 Organigramme de Talan

La figure 1.1 présente l’organigramme de la société Talan.

Figure 1.1 : Organigramme de Talan Tunisie

1.1.3 Secteurs d’activités de Talan

Les principales activités de Talan consistent aux conseil et assistance à la maîtrise

rapprochements de moyens et digitalisation ;

— Le secteur d’énergie et de services publics : La présence de Talan dans ce secteur

— Le secteur de transports et de logistique : Talan a développé une forte expertise

— Le secteur de télécom et de médias : La présence de Talan dans ce secteur est le

1.1.4 Talan Salesforce

Salesforce s’est imposé comme un leader technologique au service de la transformation et

Talan associe ses expertises secteurs, métiers et technologiques à la puissance de la plateforme

• Capitaliser sur les technologies émergentes (Intelligences Artificelles, IoT, smart

• Révolutionner la relation clients en leur proposant des expériences pertinentes et

1.2 Contexte du projet

L’objectif de ce projet est de concevoir et d’implémenter une solution pour optimiser

-Accélérer et faciliter le traitemnt des dossiers des candidats.

-Automatiser le processus de recrutement,

- générer automatiquement des contrats en intégrant une signature électronique,

- Etudier le niveau de satisfaction des postulants vis-à-vis de la solution, en centralisant leurs