Simulateur Daffectation Des Ressources H

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
UNIVERSITE DE SOUSSE
‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬
Institut Supérieur D’informatique

Et Des Techniques De Communication – Hammam Sousse
MEMOIRE DE PROJET DE FIN D’ETUDES

Présenté en vue de l’obtention du Diplôme National d’Ingénieur
Spécialité : Téléinformatique
Simulateur d’affectation des ressources

humaines avec proposition d’un système
prédictif
Réalisé au sein de
Réalisé par : Takali Jamel

Encadré par : Mme Hedia Jgham
Mr Aymen Amairia
Année Universitaire
2016 – 2017
Dédicaces
Dédicaces
Je remercie avant tout ALLAH, le tout puissant qui m’a donné les capacités physiques
et intellectuelles nécessaires à la réalisation de ce projet.
A mon cher papa et ma chère maman
Pour tous les sacrifices que vous avez consentis, pour toutes les prières que vous
m’aviez
faites pour tout l’amour, l’affection, le soutien et l’encouragement que vous m’aviez
toujours apportés tout au long de mes études pour faire de moi ce que je suis
aujourd’hui.
Je vous dédie ce travail en signe de mon éternel attachement et de mon amour.
A mon frère
A mes chères petites sœurs
Vous étiez toujours la source de ma motivation. Tous mes remerciements ne
suffissent
pas pour toute l’aide, le soutien et la sympathie.
A toute la famille TAKALI
A tous mes amis du quartier, mes binômes à Tunis
A tous ceux qui ont su m’apporter aide et soutien aux moments propices
A toute la promotion ISITCom’ 2017
A tous mes Amis, pour les agréables moments passés ensemble, pour le soutien moral
et
pour la noblesse de vos actes.
Page | i
Remerciements
Remerciements
Le résultat de mon travail est grâce aux gens qui m’entourent, à leur amour intarissable
et à leur soutien.
Je tiens alors à leur exprimer ma vive reconnaissance et ma gratitude.
Je remercie toute personne ayant contribué, de loin ou de près, le long de mon cursus
académique et spécialement durant ma classe terminale.
Merci infiniment à ma famille, mon pilier du succès, qui m’a tenue tant à cœur.
Un grand merci à Mme Hedia Jegham, mon tuteur de stage, pour l’encadrement et le
suivi dans la rédaction de ce rapport.
Je remercie Mr Aymen Amairia, mon encadrant, qui m’a guidée avec toute sa patience
et sa sagesse à croire en soie pour réaliser ce projet.
J’adresse enfin, ma plus vive reconnaissance à tous mes enseignants de l’Institut

Supérieur d'Informatique et des Technologies de Communication de Hammam Sousse
(ISITCom) pour la formation d’ingénieur qu’ils m’ont procurée.
Page | ii
Table des matières
Table des matières
Dédicaces ......................................................................................................................... i
Remerciements ................................................................................................................ ii
Table des matières ......................................................................................................... iii
Liste des figures ............................................................................................................. vi
Liste des tableaux ........................................................................................................ viii
Introduction générale ......................................................................................................1
Présentation du cadre du projet ..................................................................................... 3
Introduction ................................................................................................................ 3
1. Présentation de l’organisme d’accueil .................................................................. 3
1.1 Présentation générale et services .................................................................. 3
1.2 Secteurs d’activité .......................................................................................... 4
2. Contexte du projet ................................................................................................ 5
2.1 Problématique................................................................................................ 5
2.2 Description du projet ..................................................................................... 6
3. Choix de la Méthodologie de Travail .................................................................... 6
3.1 Les Méthodes Agiles ...................................................................................... 6
3.2 Etude comparative des méthodes agiles ....................................................... 7
3.3 Méthodologie Agile Scrum ............................................................................ 8
3.4 Caractéristiques ............................................................................................. 8
3.5 Planification ................................................................................................... 9
3.6 Processus........................................................................................................ 9
3.7 Équipe et rôle ............................................................................................... 10
Conclusion :................................................................................................................ 11
Analyse et spécification des besoins ..............................................................................12
Introduction ...............................................................................................................12
1. Etude de l’existant ...............................................................................................12
2. Critique de l’existant............................................................................................12
3. Solution ................................................................................................................14
4. Capture des besoins .........................................................................................14
4.1 Besoins fonctionnels .....................................................................................14
4.2 Besoins non fonctionnels..............................................................................19
Page | iii
Table des matières
5. Modélisation des besoins ....................................................................................19

5.1 Les acteurs du système .................................................................................19
5.2 Diagramme de cas d’utilisation global ........................................................ 20
5.3 Diagrammes des cas d’utilisation détaillés ................................................. 22
6. Planification des sprints...................................................................................31
6.1 Product Backlog ........................................................................................... 32
6.2 Scrum Board ................................................................................................ 33
7. Proposition d’un prototype ................................................................................ 34
Conclusion ................................................................................................................. 36
Etude conceptuelle ....................................................................................................... 37
Introduction .............................................................................................................. 37
1. Système expert .................................................................................................... 37
1.1 Définition ..................................................................................................... 37
1.2 Etapes ........................................................................................................... 38
1.3 Exemple d’algorithme .................................................................................. 39
1.4 Architecture d’un système expert ................................................................ 40
2. Architecture globale ........................................................................................... 42
2.1 Architecture physique .................................................................................. 42
2.2 Architecture logique .................................................................................... 43
3. Modélisation UML .............................................................................................. 44
3.1 Vue statique ................................................................................................. 44
3.2 Vue dynamique ............................................................................................ 50
Conclusion ................................................................................................................. 59
Réalisation .................................................................................................................... 60
Introduction .............................................................................................................. 60
1. Environnement de travail................................................................................... 60
1.1 Environnement matériel ............................................................................. 60
1.2 Environnement logiciel ............................................................................... 60
1.3 Technologies utilisées .................................................................................. 63
2. Gestion du projet ................................................................................................ 65
3. Réalisation des sprints ....................................................................................... 66
3.1 Sprint 1 ......................................................................................................... 67
3.2 Sprint 2 ........................................................................................................ 69
Page | iv
Table des matières
3.3 Sprint 3......................................................................................................... 76

3.4 Sprint 4 ........................................................................................................ 80
3.5 Sprint 5......................................................................................................... 81
Conclusion ................................................................................................................. 84
Conclusion générale et perspective .............................................................................. 85
Résumé ......................................................................................................................... 86
Références ..................................................................................................................... 87
Epigraphe ...................................................................................................................... 88
Page | v
Liste des figures
Liste des figures
Figure 1 organigramme de Wevioo................................................................................. 4

Figure 2 le processus de développement SCRUM [4].................................................. 10
Figure 3 prototype de radar des compétences à développés ....................................... 18
Figure 4 digramme de cas d'utilisation global ............................................................. 20
Figure 5 diagramme de cas d'utilisation consulter projet ........................................... 22
Figure 6 diagramme de cas d'utilisation de gestion des besoins ................................. 23
Figure 7 diagramme de cas d'utilisation de gestion des profils ................................... 29
Figure 8 Product Backlog de l'application ................................................................... 32
Figure 9 Planning des Sprints ...................................................................................... 33
Figure 10 Scrum Board de la gestion simulation [2] ................................................... 34
Figure 11 Prototype de la page Dashboard ................................................................... 34
Figure 12 Prototype de la page gestion simulation ...................................................... 35
Figure 13 Prototype de la page plan des charges ......................................................... 35
Figure 14 Prototype de la page gestion profil ............................................................... 36
Figure 15 Les étapes de processus de système expert .................................................. 38
Figure 16 exemple simple sur une fonction du classifieur SVC ................................... 39
Figure 17 architecture physique de l'application ......................................................... 42
Figure 18 architecture MVC [8] .................................................................................... 43
Figure 19 diagramme de classe ..................................................................................... 45
Figure 20 diagramme de classe optimisé ..................................................................... 46
Figure 21 diagramme d'état transition de l’objet projet .............................................. 49
Figure 22 Diagramme de séquence authentification ................................................... 50
Figure 23 diagramme de séquence création simulation ............................................... 51
Figure 24 diagramme de séquence affecter profil........................................................ 52
Figure 25 diagramme de séquence consulter projet .................................................... 53
Figure 26 diagramme de séquence simuler Pré-projet + affectation .......................... 54
Figure 27 diagramme de séquence valider projet ........................................................ 55
Figure 28 diagramme d'activité créer simulation ........................................................ 56
Figure 29 diagramme d'activité simuler Pré-projet ..................................................... 57
Figure 30 diagramme d'activité gérer grille des compétences .................................... 58
Figure 31 logo PhpStorm [9] ........................................................................................ 60
Figure 32 logo WampServer [10] ..................................................................................61
Figure 33 logo MySQL Workbench [11] ....................................................................... 62
Figure 34 logo Star UML [12] ....................................................................................... 62
Figure 35 logo cmder [13] ............................................................................................. 62
Figure 36 logo Pencil [14] ............................................................................................. 63
Figure 37 logo Symfony [15] ......................................................................................... 63
Figure 38 logo de TWIG [16] ........................................................................................ 64
Figure 39 logo de doctrine [17] ..................................................................................... 65
Figure 40 logo de PHP [18] .......................................................................................... 65
Page | vi
Liste des figures
Figure 41 Diagramme de Gantt avec les dates importants .......................................... 66

Figure 42 Page d'authentification ................................................................................ 67
Figure 43 Liste des ressources par profil ..................................................................... 67
Figure 44 Edit d'un profil affecté ................................................................................. 68
Figure 45 Consultation des profils ............................................................................... 68
Figure 46 Burndown Chart de Sprint 1 ........................................................................ 69
Figure 47 Liste des Simulations ................................................................................... 69
Figure 48 Création d'une simulation ........................................................................... 70
Figure 49 Suppression d’une compétence affectée ....................................................... 71
Figure 50 Consultation Simulation .............................................................................. 72
Figure 51Tableau d'adéquation .................................................................................... 73
Figure 52 Taux d'adéquation proposé par le système expert ...................................... 75
Figure 54 Liste comparatifs entre les compétences ......................................................77
Figure 55 Radar des compétences ................................................................................ 78
Figure 56 Grille des compétences................................................................................. 78
Figure 58 Exemple de plan des charges pour un collaborateur .................................. 80
Figure 60 affectation des ressources au mission ......................................................... 81
Figure 61 Détail mission après l'affectation ................................................................. 82
Figure 62 Suppression d'une ressource affectée .......................................................... 83
Figure 63Liste des projets après validation ................................................................. 83
Page | vii
Liste des tableaux
Liste des tableaux
Tableau 1 tableau des choix des méthodologies ............................................................. 7

Tableau 2 prototype de plan des charges ...................................................................... 15
Tableau 3 clé de la ligne charge total............................................................................. 15
Tableau 4 prototype de grille des compétences ............................................................16
Tableau 5 description de gestion d'accès ..................................................................... 18
Tableau 6 description du diagramme de cas d'utilisation global ................................ 22
Tableau 7 description scénariste de la création d'une simulation ............................... 25
Tableau 8 description scénariste de la suppression d'une simulation ........................ 26
Tableau 9 description scénariste de la simulation d'un besoin ................................... 27
Tableau 10 description scénariste de la validation d'une simulation .......................... 28
Tableau 12 description scénariste de l'affectation profil utilisateur ............................ 30
Tableau 13 description scénariste de la recherche ressource .......................................31
Page | viii
Introduction générale
La compétitivité des entreprises repose essentiellement sur leur capacité à utiliser

efficacement les ressources dont elles disposent afin de satisfaire au mieux la demande
de leurs clients. Selon le contexte, le terme « ressource » peut renvoyer à des notions
très différentes telles que les matières premières, l’outil de production, le personnel.
Nous nous intéressons ici à la gestion efficace du personnel qui est primordiale pour
de nombreuses entreprises.
Bien que les problèmes de planification de personnel soient étudiés depuis plus de
60ans, l’intérêt de la communauté scientifique à leur égard reste très vif encore
aujourd’hui. Cela s’explique tout d’abord par la richesse et la grande diversité des
problèmes théoriques sous-jacents, mais également par les innombrables applications
pratiques. En effet, les problématiques de planification de personnel apparaissent dans
des secteurs variés et touchent un grand nombre d’organisations. De plus, l’activité de
chacune de ces organisations est assujettie à un contexte socio-économique bien
spécifique et en perpétuelle mutation. Cela induit le besoin de développer des outils
d’aide à la décision permettant aux décideurs d’appréhender plus rapidement et plus
efficacement des données de plus en plus complexes pour dégager de nouvelles marges
de productivité.
Avec l’accroissement des capacités de calcul des outils informatiques actuels, il devient
possible d’envisager la résolution de problèmes plus difficiles et plus vastes
qu’auparavant. Par conséquent, de plus en plus d’études abordent simultanément
plusieurs aspects du problème, tels que l’attribution des jours de repos, la construction
des horaires de travail et l’affectation des activités de travail aux employés. En raison
de leur complexité théorique, ces problèmes requièrent des méthodes d’optimisation
dédiées. [1]
A cet égard, les dirigeants de la société WEVIOO ont décidé de mettre l’accent sur leur
processus de sélection et d’affectation des ressources aux projets. Ils se sont vus obligés
d’améliorer leur processus actuel qui réside dans l’utilisation des méthodes
heuristiques ou intuitives pour faire leurs choix, et d’adopter une solution plus efficace
et plus performante permettant l’automatisation du processus.
C’est dans ce contexte que se situe notre projet. Il consiste à développer un module
incluant un outil d’aide à la décision, qui, en intégrant le concept de l'intelligence
artificielle, permettra de faire d’une façon rationnelle et transparente le bon choix en
tenant compte de l'adéquation des compétences des collaborateurs à ceux des missions
et de leur disponibilité par rapport au plan de charge.
Page | 1
Ce projet vise à améliorer le processus de choix et d’affectation des ressources et ce

par la centralisation des différents éléments et actions relatifs à ce processus. Il
permettra également d’assurer une organisation des données, une meilleure
circulation de l’information et de faciliter les tâches des responsables en charge de
recrutement. Le présent rapport repose sur les différentes étapes de la mise en œuvre
du module d’affectation des ressources. Ce rapport comportera cinq chapitres
illustrant ce sujet.
Le premier chapitre « Cadre du projet et Méthodologie » porte sur la présentation du

projet, de l’organisme d’accueil et de la méthodologie de travail adoptée.
Le deuxième chapitre « Analyse et Spécification des besoins » comporte une analyse

de l’existant et décrit les besoins fonctionnels et non fonctionnels de notre application.
Le troisième chapitre « Conception » présente une conception détaillée du projet.

Le quatrième chapitre « Etude technique » est consacré à la présentation de
l’environnement de travail et les technologies utilisées lors de la réalisation de
l’application.
Pour finir, dans le cinquième chapitre, nous présentons les différentes fonctionnalités
de notre application à travers des captures d’écrans.
Nous clôturons le rapport par une conclusion générale dans laquelle nous présentons
une synthèse du travail réalisé ainsi que les éventuelles perspectives du projet.
Page | 2
Présentation du cadre du projet
Introduction
Nous entamons ce premier chapitre par une présentation générale qui va nous
permettre de fonder des connaissances sur l’organisme d’accueil « WEVIOO » et ses
secteurs d’activité. Nous procédons, également, à la présentation générale de notre
sujet ainsi nous apportons quelques indications nécessaires sur la méthodologie
adoptée lors de la réalisation de ce projet.
1. Présentation de l’organisme d’accueil

Afin de situer notre travail dans son environnement de réalisation, nous présentons
dans cette section l’organisme d’accueil en exposant ses secteurs d’activité.
1.1 Présentation générale et services

Avec une présence à Tunis, Alger et Paris, Wevioo est aujourd’hui un leader des
solutions d’externalisation Nearshore1 et des projets internationaux. Depuis 1998, date
de la création, WEVIOO a développé une expérience réelle de projets Nearshore et de
projets internationaux réalisés dans plus de 20 pays de la région EMEA (Europe,
Moyen-Orient et Afrique).
Wevioo a pour mission de concevoir et mettre en œuvre les meilleures solutions
technologiques visant à améliorer la productivité, la rentabilité et la réactivité des
entreprises sur leur marché.
Etant focalisé dans les méthodologies de réalisation logicielle et d’intégration de
solutions, WEVIOO accompagne ses clients sur les différentes étapes de transitions.
Depuis l’analyse de la performance et du positionnement stratégique jusqu’à
l’exploitation des infrastructures informatiques, en passant par la mise en place du
système d’information.
Wevioo apporte à ses clients une offre de services à forte valeur ajoutée :
1 Est le fait de délocaliser une action économique
Page | 3
✓ Consulting : AMO, PMO, ré-engineering des processus et consulting métier.

✓ Ingénierie logicielle : architecture, développement logiciel TMA et TRA.
✓ Solutions d’entreprise : intégration des ERP MS Dynamics AX et NAV, des SI
décisionnels et de solutions verticales métier dans la banque, la finance et la
logistique.
✓ Infogérance : maintien en condition opérationnelle, exploitation, supervision et
administration des Si en 7x24.
La hiérarchie de WEVIOO est présentée par l’organigramme suivant :
Figure 1 organigramme de Wevioo
Dans la figure ci-dessus nous remarquons que l’architecture se décompose en deux

filiales :
Nous sommes en train de faire notre projet fin d’étude au sein de département SE 2 de
Wevioo.
1.2 Secteurs d’activité

WEVIOO touche divers secteurs d’activité tels que :
2 Software Engineering : génie logiciel
Page | 4
✓ Services bancaires et Financiers : WEVIOO apporte son savoir-faire et ses

connaissances fonctionnelles des métiers du Leasing (automobile, mobilier,
immobilier), du crédit, de la micro finance, de l’affacturage et du recouvrement.
✓ Industrie : WEVIOO accompagne ses clients sur l’ensemble du cycle de vie d’un
projet, du conseil à la réalisation complète de la solution y compris le transfert de
compétences
✓ Distribution : WEVIOO met en place des solutions complètes allant du back-office

comptable, financier, et de gestion de ressources humaines, à des fonctionnalités
évoluées de gestion logistique poussée, de gestion partagée des approvisionnements
et de gestion de la relation client.
✓ Secteur Publique : à travers l’assistance à la maîtrise d’ouvrage, le Conseil en

organisation et réingénierie des processus, la réalisation et mise en œuvre de
système d’information sur mesure utilisant des technologies ouvertes tels que l’e-
gouvernent, la téléadministration, les systèmes de gestion, le workflow...
✓ Service : à travers la mise en place des outils d’analyse et d’aide à la décision.
✓ Télécom : WEVIOO accompagne les opérateurs de la région dans leurs projets de

transformation et d’adaptation continue par rapport à l’évolution du marché.
2. Contexte du projet
2.1 Problématique
L’affectation des bonnes ressources aux projets, la mise en place d’un plan d’action
solide et, surtout, la constitution d’une équipe possédant les compétences requises,
toutes ces variables sont maîtrisées avec une bonne planification assurant le succès des
projets.
Mais la plupart des entreprises ont tendance à suivre des méthodes heuristiques ou
intuitives pour faire leurs choix, ce faisant, ils négligent la tâche d’affectation et
tombent dans la mauvaise gestion des ressources par rapport aux projets.
C’est également le cas de Wevioo qui soulève plusieurs difficultés relevant de la

centralisation des différentes informations dispersées liées aux ressources.
Dans ce contexte, Wevioo propose de mettre en place pour ce projet un système d’aide
à la décision, qui, en s’aidant des apports de l'intelligence artificielle et en intégrant un
système expert, permettra de réaliser l’affectation d’une façon rationnelle et
transparente le bon choix en tenant compte de l'adéquation des compétences des
Page | 5
collaborateurs à ceux des missions et de leur disponibilité par rapport au plan de

charge.
2.2 Description du projet

WEVIOO utilise l’application TALENTVIOO pour la gestion des ressources humaines.
Cette solution comprend plusieurs modules dont celui de la gestion des collaborateurs,
des évaluations, des statistiques, des simulations, des formations et des recrutements.
Cependant cette application faute d’identifier les collaborateurs les plus adéquats aux
missions.
Notre projet consistera donc à créer ce module d’affectation des ressources aux
missions qui sera considéré comme étant un outil qui offre la possibilité d’automatiser
le processus de sélection et d’affectation des ressources.
Ce module consiste en une solution permettant d’avoir un produit propre à l’entreprise
qui répond à ses besoins et qui peut s’adapter aux éventuelles évolutions.
En intégrant le concept de l'intelligence artificielle, cet outil permettra de réaliser un
aide à la décision afin d'identifier les ressources clés afin de gérer les priorités sur les
projets au niveau opérationnel, mettre à jour les informations sur les affectations des
ressources afin que toutes les informations soient visibles dans la liste des ressources.
Cela peut aider le responsable de projet ou le Gestionnaire de ressources à vérifier les
problèmes de surutilisation sur plusieurs projets.
Il permet également de faire le bon choix tenant compte de l'adéquation des
compétences des collaborateurs à ceux des missions et de leurs disponibilités par
rapport au plan des charges.
3. Choix de la Méthodologie de Travail

Pour bien mener notre projet, nous avons adopté un processus de développement
itératif et incrémental. En effet, en vue d’obtenir un logiciel qui répond aux besoins du
client nous avons eu recours à une des méthodologies agiles.
Nous nous intéressons donc à en donner un aperçu dans cette partie. Puis nous
entamerons une étude détaillée sur la méthodologie Scrum, celle utilisée dans le
présent projet.
Dans la suite du rapport, nous allons utiliser des termes définis dans cette partie.
3.1 Les Méthodes Agiles

La notion de méthodologie agile a été officialisée en 2001 par un document, le
Manifeste Agile (Agile Manifesto2).
Page | 6
La méthode agile est une approche réactive et itérative d’organisation de travail, qui
est menée dans un esprit collaboratif avec le formalisme qu'il faut. Elle englobe un
ensemble de pratiques pouvant s’appliquer à divers types de projets, mais se
limitant plutôt actuellement aux projets de développement en informatique.
Elle s’intéresse aux individus et aux interactions plutôt qu’au processus et outils.
Elle implique au maximum le client et permet une grande réactivité à ses demandes
et une adaptation au changement plutôt qu’au suivi d’un plan.
Elle génère un produit de haute qualité tout en prenant en compte l'évolution des
besoins des clients et non les termes d’un contrat de développement.
3.2 Etude comparative des méthodes agiles
La meilleure façon d'aborder un problème est de l'attaquer par phase. C'est l'intérêt de
l'utilisation d'une méthodologie agile. Elle regroupe les activités à mener pour
transformer les besoins d'un utilisateur en système logiciel.
Nous procédons maintenant au choix de la méthode agile à adopter pour la réalisation

de notre projet. Pour cela, nous élaborons une comparaison entre les méthodes Scrum,
XP et DSDM qui sont très utilisées dans les entreprises.
Méthode Points forts Points faibles
XP ✓ forte réactivité au changement ✓ Nécessite une forte implication du

des besoins du client. client.
✓ code de qualité. ✓ Approche dénuée de modélisation.
✓ Fait une large place aux aspects ✓ Assez flou dans sa mise en œuvre.
techniques : prototypes, règles de
développement, tests...
DSDM ✓ gestion de projet efficace et un ✓ Client relégué au 2nd plan.
contrôle solide sur le cycle de vie ✓ Documentation assez complexe.
du projet. ✓ Consomme beaucoup du temps.
SCRUM ✓ Découpage du projet en sprints de ✓ L’évolution des besoins amène les

durée allant de deux à quatre clients à exiger de plus en plus de
semaines. fonctionnalités.
✓ Meilleure vue de l'ensemble du ✓ Faible documentation et donc
projet. facile à détourner.
✓ Augmentation de la productivité. ✓ Peu de place pour les étapes
✓ Qualité du produit mise en avant. postérieures ainsi que les étapes
antérieures.
Tableau 1 tableau des choix des méthodologies
Page | 7
Notre choix s'est focalisé sur la méthodologie Scrum qui assure un gain considérable
de temps et l'amélioration de la qualité des développements vu qu'elle permet de
s’adapter aux changements et aux évolutions des besoins, des priorités, ou des équipes.
Elle permet de réduire les risques de problèmes de conception et de collaborer avec le
client à travers les produits livrables à chaque fin de sprint.
Par la suite, nous allons détailler le principe de la méthode Scrum.
3.3 Méthodologie Agile Scrum

Scrum est une méthode agile pour la gestion des projets informatiques. Cette méthode
a pour objectif d'améliorer au mieux la productivité tout en assurant la satisfaction du
client.
Scrum est une méthode itérative et incrémentale structurant le développement en
cycles de travail appelés Sprints de durée allant de deux à quatre semaines.
Dans cette méthode le client participe activement dans le cycle de développement de
projet, ce qui permet :
✓ La définition des fonctionnalités prioritaires.
✓ L’ajout de fonctionnalités en cours de projet (pas pendant un sprint)
La méthode Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un

groupe de personnes qui travaillent ensemble pour atteindre un but commun.
3.4 Caractéristiques
Scrum se différencie des autres méthodes de développement par ses avantages qui font
d’elle une réponse pragmatique aux contraintes actuelles des chefs de produits :
Propriété et Autonomie :
Pendant l’exécution du sprint, tout le monde peut prendre une tache quelconque. Cela
offre une excellente opportunité d'apprentissage pour les membres de l'équipe
lorsqu'ils choisissent des tâches au-delà de leur zone de confort.
L’attitude de l’équipe :
Avec Scrum, les équipes s'efforcent d'atteindre un but commun : elles gagnent ou
perdent ensemble comme un sport d'équipe. La victoire n'est pas possible sans
collaboration et confiance.
Amélioration continue :
Les réunions rétrospectives permettent d’identifier et de résoudre les problèmes les
plus critiques auxquels l’équipe est confrontée. Cela oblige également les équipes à
réfléchir plus fort et à découvrir des problèmes moins évidents avant de devenir des
monstres.
Page | 8
De Point de vue visibilité pour l’équipe et le client :

La méthode Scrum offre une bonne visibilité et une bonne prévisibilité sur le logiciel
en cours de développement. Cela motive les gens et crée des équipes ultra-
productives. À l'inverse, les clients bénéficient de la méthode car ils peuvent voir,
toucher et sentir le logiciel à chaque étape. Il est beaucoup plus facile de regarder le
logiciel en cours d'exécution et de décider des exigences en cours de route, plutôt que
d'essayer de les imaginer tout d'abord [6]
3.5 Planification
Scrum propose une planification opérationnelle à trois niveaux : release/projet, sprint
et quotidien.
✓ Sprint : Un sprint est une période de temps déterminée pendant laquelle le

travail spécifique doit être complété et préparé pour une évaluation finale.
Il regroupe un ensemble des taches élémentaires qui portent sur le même but.
Chaque sprint commence par une réunion de planification organisé par tous les
membres de l’équipe appelé « Planning Poker 3»
✓ Release : Pour mieux organiser l’avancement de projet, la Release regroupe un

ensemble de sprints et représente une version livrable prêt à être évalué et tester.
✓ Quotidien : (Daily Meeting) : c’est une réunion quotidienne se fait au début de la

journée, dure entre 15 et 20 minutes, son objectif c’est de répondre à 3 question :
Qu’est-ce que j’ai fait ? Qu’est-ce que je pense faire ? Quels problèmes j’ai
rencontré ? organisé généralement entre le PO4, le SM5,et le Team6, au niveau de
mon cas, je fais chaque matinée des réunions de stand-up avec mon encadrant de
la société.
3.6 Processus
Scrum est un processus, résumé dans le schéma suivant :
3 L’estimation de la complexité des taches avec l’intervention de toute l’équipe Scrum

4 Product owner :Mr Rami Gadacha
5 Scrum Master : Mr Aymen Amairia
6 L’equipe de travail : Jamel Takali
Page | 9
Figure 2 le processus de développement SCRUM [4]
Scénario principal :
La figure 2 montre la production d’une version du logiciel, ce qui se fait en général en

quelques mois. Les fonctionnalités demandées sont collectées dans le Backlog de
produit et classées par priorité. Le propriétaire du produit est responsable de
l’insertion des changements dans ce Backlog. La release est produite par une série des
Sprints.
Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit, en tenant
compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires
pour réaliser les fonctionnalités sélectionnées pour le Sprint.
Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des
mêlées quotidiennes. Cela permet au Scrum Master de déterminer l’avancement par
rapport aux engagements du Sprint et de conseiller des ajustements pour assurer le
succès du Sprint.
A la fin de chaque Sprint, l’équipe produit un incrément potentiellement utilisable,
dont l’évaluation permet d’ajuster le Backlog pour le Sprint suivant.
3.7 Équipe et rôle

L’équipe Scrum définit trois rôles qui sont :
✓ Le Product Owner : ou bien le propriétaire du produit, C’est celui qui représente
le bout client dans le système de notre projet, son rôle principal est la définition
des différents besoins de produit qui sera développé par la suite.
Ces besoins sont traduit ensuite à des user story aux membres de l’équipes.
Dans notre cas le Product Owner est Mr Rami Gadacha
Page | 10
✓ Le Scrum Master : ou bien le directeur de produit, C’est le leader de l’équipe

scrum, son rôle principal est d’assurer la bonne gestion du Product Backlog, et
l’aide de tous les ressources à être autonomes et plus productives
Dans notre situation le Scrum Master sera Mr Aymen Amairia.
✓ Le Scrum Team : ou bien l’équipe de Scrum, elle est composée par des
professionnels de différents profils tel que les développeurs, les testeurs, les
infographistes, leur rôle c’est de préparer pour chaque sprint un incrément de
produit qui doit être une sorte de livrable.
L’équipe est formée par moi-même concernant le module affectation et le
reste de l’équipe pour les autres parties de l’application.
Conclusion :
Ce chapitre a donné l’occasion de présenter dans un premier temps la société
“WEVIOO” au sein de laquelle nous avons réalisé ce projet, puis le cadre du sujet, les
objectifs que notre travail vise à atteindre ainsi que la méthodologie utilisée.
En vue de suivre un avancement logique dans ce rapport, nous allons établir une étude
des solutions existantes au niveau de la société, puis nous présenterons les besoins
fonctionnels et non-fonctionnels de notre solution.
Page | 11
Analyse et spécification des besoins
Introduction
L’étude de l’existant permet d’évaluer la situation actuelle de l’organisme à prendre en
charge.
D’où, il s’agit d’analyser, évaluer et critiquer les procédures de travail courantes et
proposer des solutions, les discuter et choisir la plus adéquate et la plus optimisée.
Cette analyse va nous aider à cerner les détails fonctionnels, présenter les détails de
système que doit couvrir l’application à développer.
Nous rappelons que notre application intitulée « Affectation des ressources » est une
application qui consiste à réaliser le processus de l’affectation des ressources humaines
depuis la création du projet jusqu’à la remise en place du plan des charges.
1. Etude de l’existant
Au sein de Wevioo ou n’importe quelle société, lors de l’acceptation de nouveau projet

sur lequel ils vont travailler, les chefs techniques de plateau sont ceux qui prennent en
charge la tache de l’affectation des effectifs au projets proposé.
Pour cela, des réunions de négociation se fait pour étudier les compétences et les
charges des effectifs de leurs équipes.
Plusieurs facteurs sur lesquels ils tiennent compte, mais ils ne sont pas vraiment
calculés pour une meilleure adéquation.
2. Critique de l’existant
L’analyse de la solution adoptée par la société pour la gestion de l’affectation des
ressources nous a permis de constater quelques insuffisances. En effet, la solution
existante ne satisfait pas les besoins de la société.
Page | 12
La notion de charge qui représente un facteur très important dans une application
avancée de gestion ressource humaine tel que TalentVioo n’est pas mentionné.
L’absence de terme charge ressource par projet peut générer plusieurs problèmes tel
que :
✓ La possibilité de surcharge une ressource par rapport à d’autres.
✓ La possibilité de décharger une ressource par rapport à d’autres.
✓ Un faux calcul d’adéquation
Afin d’exécuter l’enchainement des actions d’affectation plusieurs filtrage sont mise en
valeurs :
1er filtrage :
Lors de la création d’un nouveau projet, les chefs techniques doivent consulter les
compétences de chaque ressource une par une, les étudier et rapprocher le maximum
possible les ressources les plus adéquats.
La solution n’est pas informatisée,

Gaspillage de temps dans l’action de recherche des compétences de chaque ressource.
En cas de rapprochement entre les collaborateurs, il sera plus difficile de prendre la
décision de l’adéquation.
L’action de comparaison n’est pas assez facile surtout dans le cas où le projet nécessite
plusieurs compétences.
2ème filtrage :
Dans un deuxième lieu, ils consultent leurs charges en termes de projet, calculer leurs
charges totales et estimer leurs disponibilités.
Le calcul manuel des charges ressource par ressource pour les différents projets peut
facilement générer des erreurs de calcul.
La possibilité d’affecter la fausse ressource au projet.
Un déséquilibre en termes de taux de travail entre les ressources.
3ème filtrage :
Ensuite, nous avons constaté qu’il existe une certaine priorité des projets mise aussi en
considération par les décideurs afin de pouvoir choisir lequel il faut lui ajouter des
ressources et lequel il faut lui enlever.
Pour finir nous avons noté que ces filtres sont calculés manuellement mais plutôt
mentalement pour faire une affectation finale.
Page | 13
3. Solution
Pour remédier aux inconvénients du système actuel, WEVIOO a décidé de créer un
produit propre à elle, qui répond à ses besoins et que nous pouvons faire évoluer et
modifier selon l’évolution de ses besoins.
C’est pour cela rappelons un principe absolu : qui dit stratégie, donc objectifs, dit en
même temps mesure de la réalisation des objectifs.
De ce fait notre projet consiste à développer une application sous forme d’un « ADD
ON 7» permettant l’affectation des ressources aux missions selon l’adéquation de leurs
compétences à la mission et leur disponibilité par rapport au plan de charge.
4.Capture des besoins

L’objectif de ce projet est la conception et la réalisation d’un module de gestion
d’adéquation.
Notre solution doit répondre à certains besoins et exigences dégagés suite à des
réunions avec les responsables de l’entreprise.
Nous allons passer maintenant à définir les différents besoins de notre application.
4.1 Besoins fonctionnels

4.1.1 Plan des charges :
Filtre de recherche : L’utilisateur de notre application doit avoir la possibilité de

rechercher par collaborateur, par entité de l’organigramme, par projet, par mois.
Tableau à n colonnes.
✓ 1ère colonne : liste des collaborateurs
✓ 2ème colonne : projet [liste des projets]
Le reste des colonnes : les 12 mois de l’année calendaire en cours fractionnés par
semaine. (Affichage du mois en cours et des 3 prochains mois et possibilité de naviguer
entre les mois)
Chaque ressource peut travailler sur plusieurs projets, donc une ligne peut être
fractionnée en x projets.
La « charge totale » est la somme de la charge sur chaque projet. Le reste des lignes
d’une ressource peuvent être réduites
7 Module complémentaire indépendant et installable pour TalentVioo
Page | 14
Novembre Décembre
Ressource Projet
S1 S2 S3 S4 S5 S1 S2 S3 S4 S5
Charge 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Totale
Projet 1
Abderraouf Chaouch Projet 2
Projet 3
Projet n
Charge 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
Totale
Projet 1
Ahmed Wahabi Projet 2

Projet 3
Projet n
Tableau 2 prototype de plan des charges
Possibilité de saisir la charge de chaque ressource sur un projet donné à une semaine
donnée.
Charge totale = somme des charges sur chaque projet
La charge totale est coloriée selon sa valeur :
Couleur codes
ressources
<= 50%
Entre 51% et 85%
Entre 86% et 105%
>105%
Tableau 3 clé de la ligne charge total
4.1.2 Grille des compétences
Il s’agit d’une Base de données regroupant les compétences de chacun des

collaborateurs. Elle sert à l’identification des ressources à affecter à des missions.
Tableau à n colonnes.
Page | 15
✓ Colonne 1 : type de compétences

✓ Colonne 2 : famille de compétences
✓ Colonne 3 : catégorie de compétences
✓ Colonne 4 : compétences
✓ Colonne 5….n : prénom nom collaborateur
A n lignes :
✓ Ligne 1 : poste (hérité de la fiche collaborateur)
✓ Ligne 2 : nombre d’années d’expériences (numérique)
✓ Ligne 3 : Besoin de visa [Oui ; Non]
Collaborateur Rami Gadacha Ahmed Wahabi Chawki Ellouze

Poste Pilote processus Ingénieur logiciel Ingénieur logiciel
Nbre d'année d'exp. 2 1 1
Besoin en visa Oui Non Oui
Type de Famille de Catégorie de
Compétences Niveau
compétences compétences compétences
SE Développement logiciel
Java/J2EE SpringBatch 0 4 5
SE Développement logiciel
Java/J2EE Junit 2 1 2
SE Testing Outil de test +ISTQB 3 3 4
MC Compétences métiersConseils en organisation
Gestion du capital humain 5 5 4
IS Système Messagerie Office 365 2 2 4
Tableau 4 prototype de grille des compétences

4.1.3 Besoin du client
Saisie des données relatives à la mission :
✓ Compétences requises pour la mission : [liste des compétences]
✓ Niveau requis : [1 ;2 ;3 ;4 ;5]
✓ Expérience requise : [numérique]
✓ Nombre requis : nombre de ressources
✓ Besoin du visa : [Oui ; Non]
✓ Date de début/date fin : période de la mission
Résultat : Tableau de l’adéquation des ressources trié par score.

✓ Colonne 1 : liste des ressources
✓ Colonne 2 : Adéquation (%) : nombre de critère satisfait/nombre total de critères
(toutes les compétences y comprises)
✓ Colonne 3 : score= (-1)* nombre de critères (excepté nombre d’années
d’expériences) + bonus
✓ Colonne 4 : charge de la ressource dans la période de la mission
*Bonus :
Page | 16
✓ +1 si critère atteint
✓ +2 si compétence dépassée de 1
4.1.4 Choix de la ressource
Champ ressource : liste déroulante de toutes les ressources

% adéquation : adéquation de la ressource sélectionnée par rapport aux critères de la
mission.
Tableau à 7 colonnes :
Colonne 1 : Type de compétence
Colonne 2 : Famille de compétence
Colonne 3 : Catégorie de compétence
Colonne 4 : compétence [hérité du besoin]
Colonne 5 : Niveau requis [hérité du besoin]
Colonne 6 : Niveau de la ressource [hérité de la grille de la compétence]
Colonne 7 : Conformité de la ressource :
Si score < 0 : en deca du besoin
Si score =0 : conforme au besoin
Si score > 0 : au-delà du besoin
Si la ressource est validée, son plan de charge lors de la période de la mission est mis à
jour à 100% (mais reste modifiable dans l’écran plan de charge).
4.1.5 Radar des compétences
Affichage du radar des compétences [compétences ressources VS compétences

requises]
Page | 17
Figure 3 prototype de radar des compétences à développés
Identification des acteurs :

Tableau 5 description de gestion d'accès
Profil Droits Rôle
Administrateur Tous les droits sur l’application. A part les fonctionnalités

qu’il hérite de simulateur, il
peut affecter les profils
Simulateur Ajouter des compétences à la C’est celui qui lance une
grille des compétences simulation, affecte les
ressources et valide les Pré-
Modifier le plan de charge
projet.
Lancer une simulation
Page | 18
Superviseur Visualiser le plan de charge Il peut consulter les

Visualiser la grille de compétence simulations, les plans des
charges, les grilles des
Visualiser l’historique des compétences sans affecter
missions aucune opération.
4.2 Besoins non fonctionnels

Les différents besoins non fonctionnels de l’application à réaliser peuvent être résumés
par les points suivants :
Sécurité :
L’application utilise des informations sensibles elle doit obligatoirement fournir une
garantie de sécurité aux utilisateurs.
En plus elle doit respecter la hiérarchie d’accès à l’application.
Performance :
L’application doit fonctionner dans les meilleures conditions sans s’interrompre pour
ceci il faut minimiser les fréquences des pannes, gérer les erreurs et les exceptions et
la montée en charge en cas de plusieurs connexions à la fois.
Le temps de réponse doit être le plus court possible.
Ergonomie :
L'application doit disposer d'une certaine clarté et simplicité d'utilisation.
Les interfaces offertes doivent être conviviale, ergonomique, facile à manipuler par les
utilisateurs.
Evolutivité :
Le code doit être clair pour permettre de futures évolutions ou améliorations.
Fiabilité :
L’application doit garantir l’intégrité et la cohérence des données à chaque mise à jour
et à chaque insertion.
5. Modélisation des besoins

Nous allons modéliser les besoins de notre application à travers un diagramme de cas
d’utilisation qui nous permet d’avoir une vision globale du fonctionnement de notre
application.
5.1 Les acteurs du système

Dans notre application on peut trouver trois types d’acteur différents :
Page | 19
L’administrateur :
C’est l’acteur qui a l’accès total sur le module affectation, il peut affecter un ou plusieurs
profils pour chaque ressource, en plus il hérite les fonctionnalités de simulateur et de
superviseur.
Le simulateur :
C’est un acteur ayant les fonctionnalités de simuler les pré-projets, supprimer,
consulter les détails de simulation, accéder aux actions d’affectation, et il hérite les
taches de superviseur.
Le superviseur :
C’est l’acteur qui a pour rôle de consulter :
✓ Le plan des charges
✓ Les simulations et leurs détails
✓ Les grilles des compétences
✓ Les radars comparatifs
5.2 Diagramme de cas d’utilisation global

Les besoins fonctionnels de notre module peuvent se résumer par le diagramme de cas
d’utilisation général illustré par la figure :
Figure 4 digramme de cas d'utilisation global

Page | 20
Par la suite nous allons présenter une brève description des différents cas d’utilisation
à travers le tableau ci-dessous :
Cas d’utilisation Description

Consulter Dashboard L’utilisateur a le droit de consulter un menu
Dashboard contenant des raccourcis à
l’application.
Consulter projet L’utilisateur peut consulter la liste des projet ,
voir leurs détailler afin d’assurer que une
simulation validé est devenu un projet consistant
Gérer plan des charges L’utilisateur a la possibilité de consulter un plan
de charge globale de tous les ressources par
rapport au projet affecté selon un calendrier
fractionné.
Il peut également affecter une recherche par
collaborateur, par projet ou par date.
Gérer grille des compétences L’acteur a la possibilité de consulter une grille qui
représente une base de données regroupant les
compétences de chacun des collaborateurs qui
sert par la suite à l’identification des ressources à
affecter à la mission.
Gérer les Simulations Le simulateur peut créer une simulation (pré-

projet) l’affecter des compétences avec leurs
niveau requis, et saisir ses besoins,
Il peut aussi la supprimer, la consulter, lister et
simuler.
En plus il peut faire toute une simulation afin
d’affecter les ressources convenables.
Gérer les profils L’administrateur doit gérer les profils de

l’application en donnant pour chaque acteur un
rôle spécifique pour qu’on puisse accéder au
module.
Page | 21
Tableau 6 description du diagramme de cas d'utilisation global
5.3 Diagrammes des cas d’utilisation détaillés

5.3.1 UC détaillé : consulter projet
Figure 5 diagramme de cas d'utilisation consulter projet
Description textuelle : consulter projet
Sommaire
Titre Consulter projet
Résumé Le superviseur doit consulter une liste des projets pour assurer
qu’une simulation validée est devenue un projet consistant
Acteur • Superviseur
• Simulateur
• Administrateur
Description des enchainements

Pré condition
Page | 22
• Authentification
• Autorisation d’accès.
Scénario nominal
1. L’utilisateur accède à la liste des simulations.
2. Le système retourne une liste des simulations qui sont stockées
3. L’utilisateur clique sur l’icône « détail » qui correspond à la simulation voulue.
4. Le système affiche les détails du projet sélectionné.
5. L’utilisateur retourne vers la page initial en cliquant sur le bouton « retour ».
6. Le system effectue l’opération et renvoie la page liste de nouveau.
Enchainement alternatif
Enchainement 1 : démarre au point 2 et retourne au point 3
2.1 L’utilisateur choisit d’affecter une recherche sur la liste des projets en saisissant un
nom ou un type de projet
2.2 Le système affiche une liste de projet selon le filtre saisi
5.3.2 UC détaillé : gestion simulation
Figure 6 diagramme de cas d'utilisation de gestion des besoins
Page | 23
Description textuelle : créer simulation
Sommaire
Titre Créer simulation

Résumé L’acteur doit introduire les informations nécessaires pour avoir un
pré-projet crée (une simulation).
Acteur ✓ Simulateur
✓ Admin
Pré condition
Authentification
Autorisation d’accès.
Post condition
La simulation sera enregistrée comme étant du code JSON (et non pas comme entité).
La simulation sera affichée dans une liste par la suite.
Scénario nominal
1. L’utilisateur accède à la liste des simulations et choisit le bouton ajouter.
2. Le système affiche le formulaire d’ajout d’une simulation.
3. L’utilisateur saisie les attributs nécessaires.
4. L’utilisateur choisit d’affecter une compétence au projet en cliquant sur le bouton
« associer compétence/pré-projet ».
5. Le système affiche une ligne correspond au formulaire de compétence.
6. L’utilisateur remplie les champs.
7. Le système valide les champs
8. L’utilisateur enregistre la simulation
Enchainement Alternatif
Enchainement A1 : démarre au point 4 et reprend au point 5 du SN
4.1 L’utilisateur choisit une deuxième, une troisième, ... une nième compétence en
cliquant sur le bouton « associer compétence/pré-projet »
Enchainement A2 : démarre au point 4 et reprend au point 5 du SN

4.1 L’utilisateur choisit de supprimer une ligne de compétence en cliquant sur l’icone
« trash » de ligne choisie.
4.2 Le système affiche un popup de confirmation,
Enchainement A2.1 : démarre au point 4.2 et reprend au point 7 de SN
Page | 24
4.2.1 L’utilisateur confirme la suppression

4.2.2 Le système supprime la ligne de compétence
Enchainement A2.2 : démarre au point 4.2 et reprend au point de SN
4.2.1 L’utilisateur annule la suppression
4.2.2 Le système renvoie l’utilisateur vers le formulaire.
Enchainement A3 : démarre au point 7 et reprend au point 3 de SN
7.1 Champs obligatoires vides
7.1 Le système affiche un message d’erreur « Accès refusé »
Enchainement 3 : démarre au point 7

7.1 L’utilisateur choisit d’annuler l’opération d’ajout
7.2 Les données seront perdues et il sera renvoyé vers la page contenant la liste des
simulations
Tableau 7 description scénariste de la création d'une simulation
Description textuelle : supprimer simulation
Sommaire
Titre Supprimer la simulation

Résumé L’acteur doit sélectionner une simulation pour pouvoir la
supprimer
✓ Administrateur
Pré condition
Authentification
Post condition
La liste des simulations sera mise à jour après l’opération.
La ligne correspondante dans la base de données sera supprimée.
Scénario nominal
2. L’utilisateur clique sur l’icône de suppression qui correspond à la simulation
voulue.
Page | 25
3. Le système affiche un popup de confirmation.

4. L’utilisateur confirme la suppression.
5. Le system effectue l’opération et renvoie la page liste de nouveau.
Enchainement A1 : démarre au point 3 et reprend au point1 de SN
3.1 L’utilisateur choisit d’annuler l’opération de suppression.
3.2 L’utilisateur clique sur le bouton annulation de l’opération
3.3 Le système ferme le popup et retourne au page liste
Tableau 8 description scénariste de la suppression d'une simulation
Description textuelle : simuler un besoin (simulation)
Sommaire
Titre Simuler Besoin

Résumé L’acteur doit affecter toute une analyse sur un besoin qui se
représente sous forme d’une simulation.
✓ Administrateur
Pré condition
Authentification
Simulation déjà crée.
Dans le cas d’affectation de la ressource, le nombre total demandé par la simulation ne
doit pas encore atteint.
Post condition
La données d’une certaine simulation sera mise à jour après l’affectation de ressource.
La ligne correspondante dans la base de données sera modifiée
Scénario nominal
2. L’utilisateur clique sur l’icône de simulation qui correspond au pré-projet voulue.
3. Le système affiche une table triée des ressources avec leurs pourcentage
d’adéquation leurs scores et les chartes graphiques correspondants.
Page | 26
4. L’utilisateur choisit de consulter la table des choix pour une ressource voulue de la
table d’adéquation en cliquant sur le bouton « plus ».
5. Le system affiche un tableau comparatif des compétences et au-dessous un radar
représentant ces comparaisons en termes de niveau.
6. L’utilisateur choisit d’affecter cette ressource au simulation courante.
7. Le système retourne au page de consultation de la simulation avec un message
flash de la réussite d’affectation et ajout de la ressource dans la table des
collaborateurs affectés.
3.1 L’utilisateur choisit de retourner en arrière en cliquant sur le bouton « retour ».
3.2 Le système affiche la liste des simulations de nouveau.
Enchainement A2 : démarre au point 3 et reprend au point 7 de SN
3.1 L’utilisateur choisit d’affecter 1, 2 … n ressource à la simulation en cliquant sur
l’icône « plus ».
3.2 Le système affiche l’écran des choix.
3.3 L’utilisateur affecte la ressource correspondante
Enchainement A3 : démarre au point 5 et reprend au point 3
5.1 L’utilisateur choisit de retourner vers la page précédente en cliquant sur le bouton
« retour »
5.2 Le système renvoie l’écran initial de la simulation
Tableau 9 description scénariste de la simulation d'un besoin
Description textuelle : valider une simulation
Sommaire
Titre Valider simulation

Résumé L’acteur doit valider une simulation pour devenir un projet
consistant.
✓ Administrateur
Pré condition
Authentification
Page | 27
Le nombre des ressources demandés est égal à celle des ressources affectées.
Post condition
La simulation est devenue un projet consistant.
La liste des projets sera mise à jour après l’opération de validation.
Scénario nominal
2. L’utilisateur clique sur l’icône de consultation de la simulation spécifiée.
3. Le système affiche les détails qui correspond à la simulation.
4. L’utilisateur choisit de valider la simulation.
5. Le system affiche un popup de confirmation sur l’opération de validation.
6. L’utilisateur choisit de confirmer la validation.
7. Le système redirige vers la page de liste des projets avec un message flash de
succès de validation.
3.1 L’utilisateur choisit d’annuler la validation.
3.2 Le système affiche la page de consultation de nouveau.
4.1 L’un des ressources affectées n’est plus dans la base de l’application.
4.2 Un popup affichant un message d’erreur s’affiche.
4.3 L’utilisateur confirme le message.
Tableau 10 description scénariste de la validation d'une simulation
Page | 28
5.3.3 UC détaillé : gestion profil
Figure 7 diagramme de cas d'utilisation de gestion des profils
Description textuelle : affecter profil utilisateur
Sommaire
Titre Affecter profil utilisateur
Résumé L’administrateur doit affecter des profils pour pouvoir accéder à

l’application
Acteur Administrateur
Pré condition
Authentification
Post condition
Toute ressource de TalentVioo doit avoir un profil pour accéder à l’application après
affectation par l’administrateur.
Page | 29
Scénario nominal
1. L’administrateur accède à la liste des ressource en cliquant sur le menu gestion

profil.
2. Le système affiche la liste de tous les ressources de TalentVioo qui sont avec et sans
profil.
3. L’utilisateur choisit d’affecter un profil bien déterminer en cliquant sur l’icône
modifier.
4. Le système retourne un formulaire avec le champs profil activé et le reste
insaisissables.
5. L’administrateur affecte le profil choisi et enregistre l’opération.
6. Le système retourne la page liste.

4.1 L’utilisateur choisit d’annuler l’opération d’affectation profil
4.2 L’utilisateur clique sur le bouton annuler
4.3 Le système retourne au page liste
Tableau 11 description scénariste de l'affectation profil utilisateur
Description textuelle : rechercher ressource
Sommaire
Titre Rechercher ressource
Résumé L’administrateur doit affecter un filtrage des ressources pour

minimiser sa recherche.
Acteur Administrateur
Pré condition
Authentification
Post condition
Une liste des ressources sera affichée selon le filtrage choisi.
Page | 30
Scénario nominal
1. L’administrateur accède à la liste des ressource en cliquant sur le menu gestion

profil.
2. Le système affiche un menu pour appliquer le filtrage.
3. L’administrateur saisi ses données pour la recherche et lance l’opération.
4. Le système affiche la liste des ressources qui correspond à la recherche.

3.1 L’utilisateur choisit d’annuler l’opération de recherche
3.2 L’utilisateur clique sur le bouton annuler
3.3 Le système affiche la liste de toute les ressources de TalentVioo.
Tableau 12 description scénariste de la recherche ressource
6.Planification des sprints

Après la définition des besoins du client, il est temps de diviser le travail tout au long
de la période du stage, c’est pour cela Scrum offre plusieurs concepts sur ce sujet, donc
on a pensé tout d’abord à concevoir notre Product Backlog.
Page | 31
6.1 Product Backlog
Figure 8 Product Backlog de l'application
Page | 32
Figure 9 Planning des Sprints
Dans les figures ci-dessus nous avons présenté notre Product Backlog de l’application
avec un planning de chaque sprint.Chaque sprint dure environ de 3 semaine, avec une
livraison à la fin de chaque sprint, sachant que le sprint 0 a duré presque un mois.
La complexité de chaque tâche est évaluée selon la suite Fibonacci : 1,2,3,5,8,13,20 ….
1 2 3 5 8 13 20 40 100
Facile ->simple->normal->difficile->très dur->délirant
L’état de la tâche est présenté selon 3 valeurs :
✓ TO DO : En état d’attente pour la réalisation
✓ DOING : Entrain de réalisation
✓ TEST : Déjà réalisée et encours de test
Remarque : le premier sprint a duré plus que de 3 semaine car j’ai passé par une phase
d’apprentissage et je n’ai pas encore commencé la réalisation.
6.2 Scrum Board

Après la préparation de Product Backlog, j’ai commencé la réalisation en respectant le
plan établi, c’est pour cela j’ai dressé un Scrum Board pour chaque sprint, contrôlé par
mon encadrant, qui est le Scrum Master de projet.
La figure ci-dessous représente un Scrum Board sur le sprint 2 capturé en
22/03/2017 :
Page | 33
Figure 10 Scrum Board de la gestion simulation [2]
7. Proposition d’un prototype

A ce niveau, nous somme astreints à citer un exemple de prototype pour donner une
vision globale des certaines interfaces graphiques de notre application.
Figure 11 Prototype de la page Dashboard

Page | 34
Au niveau de ce menu, l’application doit offrir une vision globale sur certaines
fonctionnalités globale, présenté quelque raccourci et afficher un radar des
compétences globales.
Figure 12 Prototype de la page gestion simulation
Dans cet écran, l’utilisateur doit pouvoir visualiser les différentes simulations, affecter
une analyse, et la valider dans une dernière étape pour devenir un projet consistant.
Figure 13 Prototype de la page plan des charges
Page | 35
L’utilisateur doit avoir l’accès de consulter une grille des plan des charges de toutes les
ressources présentées dans un calendrier.
Figure 14 Prototype de la page gestion profil
L’administrateur doit pouvoir donner l’accès à toutes les ressources en leurs affectant
des profils spécifiques
Conclusion
Dans ce chapitre, nous nous sommes intéressés à l’analyse des besoins fonctionnels et
non fonctionnels de notre application. Nous avons identifié les acteurs intervenant
dans le système et décortiqué les différents cas d’utilisation. Nous n’avons pas manqué
aussi de détailler notre méthodologie de travail. Dans le chapitre qui suit, nous allons
entamer la partie conception.
Page | 36
Etude conceptuelle
Etude conceptuelle
Introduction
Le but de ce chapitre est de présenter une architecture comportementale et structurelle
orienté objet qui permet de décrire le futur système à partir de différents diagrammes
tel que le diagramme de classe, le diagramme d’activité …
En effet elle définit la phase intermédiaire entre la partie spécification des besoins et la
partie réalisation.
Mais avant ça il faut mettre en valeur et parler de notre système expert proposé, en fait
c’est celui qui va jouer le rôle d’un calculateur intérieur sur le taux d’adéquation entre
les requis de la simulation et les acquis des collaborateurs.
1. Système expert
Afin d’optimiser notre application nous avons proposé un système expert pour donner
une valeur plus exacte au niveau du taux d’adéquation dans l’écran de la simulation.
Au niveau de chapitre nous aurons l’occasion aussi de mettre en valeur notre
composant système expert. Ce composant est proposé en fait, pour jouer le rôle d’un
calculateur interne prédictif du taux d’adéquation entre les requis de la simulation et
les acquis des collaborateurs
1.1 Définition
Avant de commencer plusieurs concepts sont dégagés dans ce domaine, il faut les
mettre en valeur et connaitre ses définitions tel que :
Système expert :
Un système expert est un outil ou logiciel informatique capable d’apporter une réponse
sur des questions qui nécessitent un traitement mental humain, basé sur un
raisonnement à partir des faits et des règles définis au départ.
Il peut servir comme un moyen d’aide à la décision.
Page | 37
Etude conceptuelle
Intelligence artificielle :
L’IA ou l’intelligence artificielle est le fait de créer un programme informatique
permettant de résoudre des problèmes qui sont pour le moment accomplies de façon
plus satisfaisante par les êtres humains parce que ‘ils demandent certaines
compétences mentales avec un niveau de réfléchi bien spécifique tel que :
✓ Raisonnement critiquée
✓ Apprentissage automatique
✓ Organisation de l’information.
Système d’aide à la décision :

C’est un ensemble de processus qui conduit à faciliter à l’être humain de prendre la
décision au niveau de l’entreprise.
En outre il permet de simplifier le chemin cognitif suivi par l’homme en donnant des
raccourcis à ses algorithmes mentaux.
A partir des données brutes, des modèles métier, ou de connaissance il dégage des
informations utiles à résoudre des problèmes et prendre des décision.
1.2 Etapes
Figure 15 Les étapes de processus de système expert
Le fonctionnement de notre système expert suit quelques étapes principales pour être
bien exploiter, on commence par la création des données de formation sur laquelle les
algorithmes de prédiction vont commencer, et puis une boucle se produit pour chaque
prédiction qui génère un son tour des données supplémentaire au modèle.
Page | 38
Etude conceptuelle
1.3 Exemple d’algorithme

Il existe plusieurs approches sur les algorithmes de prédiction, dans les exemples ci-
dessous on cite quelque portion de code (PHP) sur ces approches avec des valeurs de
test [7]:
SVC (Support Vector Classification) :
Exemple de test :
$ groupe = [[1, 3], [1, 4], [2, 4], [3, 1], [4, 1], [4, 2]];
$ groupeAssocié = ['a', 'a', 'a', 'b', 'b', 'b'];
$classifier = new SVC(Kernel::LINEAR, $cost = 1000);
$classifier->train($groupe, $ groupeAssocié);
$classifier->predict([3, 2]);
// return 'b'
✓ Ce type d’algorithme est utilisé spécialement dans les problèmes de discrimination,
c’est-à-dire décider à quelle classe appartient une valeur donnée.
✓ Basé sur la construction d’une fonction H qui a un vecteur d’entré X et une sortie
Y : Y=H(X)
Figure 16 exemple simple sur une fonction du classifieur SVC
Page | 39
Etude conceptuelle
k-Nearest Neighbors
Exemple de test :
$ groupe = [[1, 3], [1, 4], [2, 4], [3, 1], [4, 1], [4, 2]];
$ groupeAssocié = ['a', 'a', 'a', 'b', 'b', 'b'];
$classifier = new KNearestNeighbors();
$classifier->predict([3, 2]);
// return 'b'
C’est un algorithme qui consiste à prendre en compte les échantillons d’apprentissage,
et selon leurs distances appliquer une méthode de plus proche voisin pour estimer une
sortie associée à une nouvelle entrée.
NaiveBayes Classifier
Exemple de test :
$groupe= [[5, 1, 1], [1, 5, 1], [1, 1, 5]];
$groupeAssocié = ['a', 'b', 'c'];
$classifier = new NaiveBayes();
$classifier->predict([3, 1, 1]);
// return 'a'
C’est une méthode de classification Bayésienne probabiliste fondé sur le théorème de
Bayes.
Elle appartient au type des classifieurs linéaires.
1.4 Architecture d’un système expert

1.4.1 Composants
Page | 40
Etude conceptuelle
Base de connaissance
Base de règles Base de faits
Moteur d’inférence
Conclusion
Logique
Base de connaissance :
Une base de connaissances, est composée des données relatives aux faits des ordres
constitutifs du domaine.
Base de règles :
C’est l’ensemble des relations entre les données de base des faits, à partir desquelles on
peut établir des nouvelles informations par déduction.
(Si on a prouvé A1 etA1⇒A2 alors on a prouvé A2)
Dans notre cas c’est l’ensemble des caractéristiques affectées aux ressources, car notre
système va rapprocher les exigences de Préprojet aux caractéristiques de chaque
ressource et puis il génère un taux d’adéquation.
Base de faits :
C’est l’endroit où on stocke les données élémentaires qui sont considérés comme des
états vrais.
Ils sont une sorte des hypothèses de travail.
En fait, le système expert est constitué d’un ou plusieurs faits, à partir d’eux il peut
répondre aux requêtes de l’utilisateur.
Page | 41
Etude conceptuelle
Dans notre cas la base de faits est spécifié à l’ensemble des caractéristiques et les
exigences d’un Pré-projet tel que : les compétences affectés et leurs niveau, le besoin
de visa, nombre d’année d’expérience …
Moteur d’inférence :
Le moteur d’inférence est un interpréteur, sous système, permet à partir de la base de
connaissance d’appliquer les règles et déduire un résultat à la requête demandé par
l’utilisateur.
Dans notre cas : c’est service offert par Google qui s’appelle « google API Prediction »
1.4.2 Type de chainage
Chainage avant :
C’est un raisonnement dirigé par les données
✓ Si X et Y sont des faits déjà déduits
✓ {X, Y} est le déclencheur chaînage avant.
Chainage arrière :
C’est un raisonnement dirigé par des buts :
✓ Si le système cherche à démontrer soit le but X, soit le but Y
✓ {X} et {Y} sont deux déclencheurs chaînage arrière.
2. Architecture globale
2.1 Architecture physique
Figure 17 architecture physique de l'application
Page | 42
Etude conceptuelle
L’architecture globale représenté par l’image ci-dessus se décompose essentiellement

en trois grandes partie :
✓ Client
✓ Serveur d’application
✓ Serveur base de données
Le client dans un premier lieu demande l’autorisation à travers des requêtes http
envoyé par le navigateur, par la suite notre cœur Symfony consulte le serveur cache si
la page est déjà chargée sinon il va se communiquer avec le serveur de donnée à partir
à des requêtes SQL, qui envoie à son tour une réponse de données, transféré au client
par des réponses http.
2.2 Architecture logique
Figure 18 architecture MVC [8]
Dans la figure ci-dessus, nous apercevons que l’architecture logique de l’application

respecte le concept de MVC qui se décompose à son tour en 3 principales couches :
✓ Le Modèle : cette partie de l’architecture est celle qui contient les données de
l’application qui sont arrangé sous forme d’entités à l’aide de l’« ORM ».
Elle interagie directement avec la base des données, présente les méthodes de
création, suppression, et consultation…
Page | 43
Etude conceptuelle
Par la suite ces données sont exposées pour le contrôleur qui va les traiter selon le
besoin.
✓ Le Contrôleur : c’est la couche intermédiaire entre le modèle et la vue, reçoit les

requêtes de l’utilisateur et choisit quelle méthode doit être déclenché. Comme son
nom l’indique, c’est celui qui contrôle les données, faire ses traitements et les
envoyés par la suite à la vue adéquate.
✓ La vue : manipule les interfaces que nous voyons dans notre navigateur web, elle
correspond à la partie homme machine (IHM). Elle aide l’utilisateur à interagir avec
le système et de lui présenter les rendus demandés.
3. Modélisation UML
UML (Unified Modeling Language) est définit comme le langage de modélisation pour
notre application.
L’UML est un langage qui peut être associé à toute démarche de conception avec
différents environnements de programmation. Il permet de limiter les ambiguïtés et
faciliter l’analyse des développeurs.
L’étude de conception offre une manière élégante pour représenter le système selon
différentes vues complémentaires grâce à plusieurs diagrammes. On peut distinguer
deux types de vues :
✓ Des vues statiques qui permettent de représenter la partie physique du système tels
que :
• Diagramme de classe
• Diagramme d’état transition
✓ Des vues dynamiques qui présentent la partie fonctionnelle du système, citons à

titre d’exemple :
• Diagrammes de séquences
• Diagrammes d'activités
3.1 Vue statique

3.1.1 Diagramme de classe de l’application
Le diagramme de classe est une sorte de modèle sert à représenter les composants d’un
système tout en modélisant leurs relations.
La figure ci-dessus traduite celle de notre application.
Page | 44
Etude conceptuelle
Bloc à optimisé
Bloc à optimisé
Figure 19 diagramme de classe
Page | 45
Etude conceptuelle
Figure 20 diagramme de classe optimisé
Page | 46
Etude conceptuelle
Les deux modélisations de diagramme de classe sont correctes mais on a pensé à

l’optimiser afin de développer avec une certaine qualité de code.
les trois classe Catégorie, Famille, Type possèdent le même attribut « libelle » avec la
migration des clés étrangers, c’est pour cela on a pensé à les rendre à une seule classe
avec une relation réflexive.
Description des classes :

Project : cette classe définit les informations reliées au projet.
Priorité : cette classe définit les différentes priorités que peut posséder un projet tel
que basse, haute, moyenne.
ProjectType : est la classe qui contient les différents types des projets qu’on peut
trouver :
✓ Projet
✓ Mission
✓ Forfait
✓ Centre de service
ProjectClient : c’est la classe qui contient les informations relatives au client d’un
projet tel que son nom, adresse, téléphone, email ...
Collaborateur : cette classe contient toutes les informations relatives à une

ressource.
ProjectHasCollaborator : C’est une classe associative entre les deux classes Project
et Collaborateur, elle contient des attributs supplémentaires tel que charge, date
début… , elle fait correspondre chaque projet à la ressource.
Charge : Cette classe donne des informations concernant la charge de chaque
ressource dans le projet ou elle est affectée.
Compétence : cette classe permet de définir les compétences à la fois requises dans
les projets et acquises par les ressources.
ProjectHasCompetence : c’est une classe d’association entre les classes « Projet »
et « Compétences ». Elle fait donc correspondre chaque projet aux multiples
compétences qu’il nécessite.
CollaboratorHasCompetence : c’est une classe d’association entre les classes «
Collaborateur » et « Compétence ». Elle fait correspondre chaque collaborateur aux
multiples compétences qu’il possède.
Rôle : cette classe définit les rôles affectés aux utilisateurs de l’application.
CollaboratorDetailCompetence : c’est une classe qui contient toute les
informations détaillées reliés aux compétences des collaborateurs.
Page | 47
Etude conceptuelle
Poste : cette classe représente les caractéristiques d’un poste qu’il peut occuper un
certain collaborateur.
CompetenceHierarchy : chaque compétence appartient à une arborescence comme

le suit : chaque type de compétence comporte des familles, et chaque famille comporte
à son tour un ensemble de catégorie, et chaque catégorie possède plusieurs
compétences.
Cette architecture est traduite par cette classe à l’aide d’une relation réflexive (parent
de)
Simulation : Dans cette table nous avons enregistré les simulations qui sont stockées
avec l’architecture d’un projet sous forme du code JSON, sur laquelle on va faire
l’analyse et la simulation complète afin d’arriver à affecter les ressources et le valider
pour devenir un projet consistant.
3.1.2 Diagramme d’état transition
Nous avons utilisé ce diagramme car il décrit l’allure et le comportement dynamique
d’une entité et ses transition …, c’est exactement que nous avons besoin car l’entité
projet passe par plusieurs états avant d’être un objet consistant dans la base de
données.
Page | 48
Etude conceptuelle
Figure 21 diagramme d'état transition de l’objet projet
Page | 49
Etude conceptuelle
3.2 Vue dynamique

3.2.1 Diagramme de séquence
Authentification :
Figure 22 Diagramme de séquence authentification
La figure au-dessus représente le diagramme de séquence système d’authentification

qui suit le scénario suivant :
✓ L’authentification d’un utilisateur exige son identifiant et son mot de passe.

✓ Le système est chargé de la vérification de ces valeurs qui doivent être propices
aux celles de la base de données. Alors, un fragment alternatif se divise en deux
parties.
✓ Si l’authentification est réussite, l’utilisateur est permis d’accéder à l’application et
le menu principale sera affiché.
✓ Sinon le système redirigera l’utilisateur vers l’écran de connexion pour une autre
essai.
Page | 50
Etude conceptuelle
Créer Simulation :
Figure 23 diagramme de séquence création simulation

Page | 51
Etude conceptuelle
Lors de besoin le simulateur et l’admin ont l’accès de créer une simulation qui peut être
traduit à la fin de l’enchainement en un projet consistant.
Pour cela ce diagramme de séquence décrit une interaction entre ces acteurs et le
système :
✓ L’utilisateur demande en premier lieu d’ajouter une simulation, puis il saisit les
données nécessaires.
✓ Lors d’ajout des compétences, l’acteur a le choix de supprimer une ligne affectée
ou pas, d’où la présence d’un fragment alternatif.
✓ Dans l’action de l’enregistrement le système vérifie si les valeurs saisies sont
correctes ou pas, pour traiter l’opération en arrière-plan.
Affecter profil :
Figure 24 diagramme de séquence affecter profil
Pour pouvoir accéder au module affectation de TalentVioo , l’administrateur doit

donner pour chaque ressource un profil spécifique.
Page | 52
Etude conceptuelle
Pour cela il y a un menu spécifique à son rôle, dans lequel :

✓ Une liste de toute les collaborateurs sera affichée, il peut affecter un filtre sur
cette liste, et par la suite il a l’accès soit d’affecter ou de modifier le profil de la
ressource désiré.
✓ L’utilisateur doit sélectionner parmi les 4 profils affichés.
✓ Dans un étape final, l’administrateur peut soit annuler ou enregistrer
l’opération.
Consulter projet :
Figure 25 diagramme de séquence consulter projet
Soit après l’affectation final de simulation ou après le choix de menu gestion des
projets, une liste de tous des projets de TalentVioo est affiché, dans lequel l’utilisateur
peut choisir une ligne et appuyer sur l’icône détail.
Ensuite le système le redirige vers la page désirée qui est la page de consultation.
Page | 53
Etude conceptuelle
Simulation Pré-projet :
Figure 26 diagramme de séquence simuler Pré-projet + affectation
Le cas d’utilisation simuler Pré-projet représente une parmi les cas les plus important
dans notre application, car au cours duquel le système va traiter son analyse en
Page | 54
Etude conceptuelle
background pour faire afficher à l’utilisateur le résultat de l’adéquation avec les chartes
correspondant.
Plusieurs contraintes sont mises en considération lors de l’action de simulation.
On prend par exemple le cas où il existe certaine ressource sont déjà affecté, l’analyse
se fait donc sur les autres ressources qui sont indépendants de cette simulation.
Valider Simulation :
Figure 27 diagramme de séquence valider projet
Page | 55
Etude conceptuelle
L’action de validation est la dernière étape dans le cycle des processus de la simulation,
elle ne peut pas se déclencher sauf si :
✓ Le nombre des ressources affectées est égal à celle de nombre des ressources
demandées
✓ Les ressources affectées existent encore dans la liste des ressources de
TalentVioo.
3.2.2 Diagramme d’activité
Le diagramme d’activité représente l’interaction entre les processus de notre

évènement choisi sur laquelle une séquencement d’actions sont déclenchés pour
atteindre un besoin bien déterminé dans un état final.
Pour cela on a choisi quelque cas d’utilisation afin de les traduire dans ce type de
diagramme tel que :
Créer simulation :
Figure 28 diagramme d'activité créer simulation
Page | 56
Etude conceptuelle
La tache de création d’une simulation est une tache incrémentale, dans un premier lieu
l’utilisateur remplie les champs nécessaires, puis il choisit d’affecter les compétences
désirées, sachant qu’il peut à tout moment supprimer une ligne de compétences tant
qu’il n’a pas encore enregistrer.
Simuler Pré-projet :
Figure 29 diagramme d'activité simuler Pré-projet
Le diagramme ci-dessus a mis en évidence les différentes actions que l’utilisateur peut
l’affecter au niveau de cas d’utilisation « simuler Pré-projet », cependant il présente les
enchainements possibles pour chaque action.
Page | 57
Etude conceptuelle
Consulter plan des charges :
Figure 30 diagramme d'activité gérer grille des compétences
Au niveau de ce cas, l’utilisateur possède l’accès de visualiser une grille présentant les
caractéristiques de chaque collaborateur dans l’application en termes des compétences
(avec leurs niveau), de post, de nombre d’années d’expériences et de la possibilité
d’avoir un visa, sachant qu’il a le choix d’affecter un filtre de ressource ou de
compétence.
Page | 58
Etude conceptuelle
Conclusion
Dans ce chapitre nous avons défini une idée générale sur le concept de l’intelligence
artificielle qui était proposé dans notre application, les architectures de l’application,
nous avons aussi conçu notre système en utilisant les différents diagrammes tel que, le
diagramme de classe, le diagramme d’activité, le diagramme de séquence, le
diagramme d’état transition de la modélisation UML.
Dans le chapitre suivant nous allons attaquer la partie réalisation de notre système.
Page | 59
Réalisation
Réalisation
Introduction
Le chapitre réalisation représente le dernier volet de notre rapport.
Il a pour but d’exposer le travail réalisé tout au long de ce projet. Il sera dédié à
présenter les principales interfaces de l’application à travers des captures d’écrans
organisé suivant des sprints.
Donc nous allons présenter le déroulement du processus affectation ressources
humains à l’aide d’un enchainement de capture écran.
1. Environnement de travail
1.1 Environnement matériel
Un pc portable pour le développement ayant les caractéristiques suivantes :
Un PC dell Inspiron 15
✓ Processeur Intel core i3, 1.8 GHz
✓ 4 Go de mémoire vive
✓ Disque dur de capacité 500 Go
✓ Système d’exploitation Microsoft Windows 10
1.2 Environnement logiciel

Dans cette partie nous allons présenter les différents logiciels que nous avons utilisé
tout au long de notre projet :
PhpStorm :
Figure 31 logo PhpStorm [9]
Page | 60
Réalisation
C’est notre environnement principale, conçu pour le developpement Symfony

appartient à la sociètè JetBrains, version 2016, realisé avec JAVA , il permet de
compiler du code :
✓ PHP
✓ JavaScript
✓ HTML
✓ CSS
Compatible avec les different système d’exploitation, adaptatif et facile à manipuler la
structure et meme les font de son apparence.
WampServer :
Figure 32 logo WampServer [10]
C’est la plateforme consacré pour le developpement web de notre application

dynamique, composé par 3 element principale :
✓ MySQL
✓ Apache
✓ PHP 7/5
Possède egalement PHPMyAdmin, pour gérer plus facilement les tables de la base de
donnée, il est adapté seulement au système windows.
MySQL Workbench :
MySQL Workbech est un système complexe utilisé essentillement pour manipuler
l’architecture de la base de données, ses services est devisé sur 3 axes :
✓ Conception : il permet de modeliser la base de donnée en generant un diagramme
EER , aussi il permet à affecter le « reverse engineering » …
✓ Administrer : il offre un outil visuel pour la configuration , la modification, le
sauveagrde de serveur
✓ Performance visuel : offre à l’utilisateur la possibilité de génerer un rapport visuel
de performance pour tester leur requetes
Page | 61
Réalisation
Figure 33 logo MySQL

Workbench [11]
Star UML :
Concernant la partie modelisation et conception nous avons utilisé l’outil StarUML
pour multiple raison :
✓ Open source
✓ Licence graduit
✓ Facile à utiliser
✓ Possibilité de manipuler la structure et le font de nos diagrammes
Figure 34 logo
Star UML [12]
CMDER :
C’est un émulateur de console crée spécialement pour Windows, utilisé dans le projet
afin de faciliter la compilation des commande Symfony.
Figure 35 logo
cmder [13]
Page | 62
Réalisation
Pencil :
Outil utilisé dans les premières phases de la période de stage afin de donner une vision
globale sur les interface de l’application, il permet de créer des maquettes sur le
prototype de projet.
Figure 36 logo Pencil [14]
1.3 Technologies utilisées

Symfony 2.6
Symfony est un Framework PHP, lancé par une agence web française (SensioLabs),
utilisé pour le développement des applications web dynamique, c’est une sorte de
philosophie ainsi qu’une communauté.
Ce Framework est dédié spécialement pour les applications complexes, il est basé sur
la notion des couches, en plus il est formé par un ensemble de composants découplés
et réutilisable sur lesquels les meilleurs application PHP sont construites.
Figure 37 logo Symfony [15]
Pourquoi Symfony !
Symfony a reconnu une bonne réputation dans le monde des développeurs, grâce à des
divers raisons, et c’est mis en évidence par les chiffres d’utilisation qu’il attend jour
après jour :
✓ Plus performant : Dès le début, Symfony est conçu pour offrir au développeur une
certaine rapidité en termes de performance, à titre comparatif, il est 3 fois plus
rapide que Zend Framework avec deux fois moins de mémoire.
Page | 63
Réalisation
✓ Très flexible : Symfony est caractérisé par une flexibilité illimité, quel que soit les
besoins de développeur, il sera toujours adaptable, grâce à son injecteur de
dépendance et les évents dispatchers qui le rendent totalement configurable.
✓ Reference : des centaines des sites web très populaire dans le monde entier de toute
tailles et de toute type sont developpé en Symfony.
✓ Documentation : Symfony est un Framework stable et durable, c’est pour ça il est

bien documenté et de façon régulière, essentiellement par son site officiel et
beaucoup autres sites, qui aident énormément les développeurs en cas de besoin.
Les bundles :
Un projet Symfony est composé à un ensemble des bundles, il contient tout ce qui
concerne une fonctionnalité donnée, aide les développeurs à bien organiser les
différentes parties de l’application.
Parmi les bundles utilisés dans notre application :
FOSUser Bundle : pour la gestion des utilisateurs
SonataAdmin Bundle : pour les interfaces admin
JMSSerializer Bundle : pour la sérialisation et la désérialisation des données.
DoctrineFixture bundle : pour la gestion de charge des données lors de livraison
Twig :
C’est un moteur de templating spécifique au Symfony, définit un type de fichier
d’extension « TWIG », et englobant le type « HTML », il donne une grande puissance
de manipulation des vues, et des interfaces html qui sont rendues.
Figure 38 logo de TWIG [16]
Doctrine 2 :
Doctrine représente un ORM par rapport au Framework Symfony, en fait c’est un outil
libre utilisé pour faire un lien entre le monde relationnel de la base de données et le
monde objet, en plus il offre au développeur un ensemble des commandes pour faciliter
sa manipulation.
Page | 64
Réalisation
Figure 39 logo de
doctrine [17]
PHP :
C’est un langage de programmation, orienté objet à partie de sa version 5, dédié pour
les applications web dynamique à travers un serveur HTTP, parmi les fameux site web
avec lequel ils sont développés : Facebook, Wikipédia …
Figure 40 logo de PHP [18]

Html5 :
Est le langage de base pour la création des vues des application web, basé sur le concept
de balisage, qui aide à la structuration de contenu.
Accompagné en général avec une feuille de style CSS.
2. Gestion du projet
Concernant la partie gestion du projet, comme on a mentionné dans le Product
Backlog, on a consacré la 1ère phase de stage à l’autoformation, et l’installation de
l’environnement logiciel, par la suite une semaine au moins pour la conception,
sachant qu’à chaque fois on fait un retour en arrière dans les diagrammes pour faire
des modifications.
Ensuite j’ai démarré la partie développement avec la rédaction du rapport en parallèle,
qui ont duré jusqu’au le dernier jour de projet.
Page | 65
Réalisation
Figure 41 Diagramme de Gantt avec les dates importants
3. Réalisation des sprints
Page | 66
Réalisation
3.1 Sprint 1
Les taches de ce Sprint se focalisent sur le scenario de l’affectation des profils pour
chaque utilisateur de la palteforme « TalentVioo ».
Figure 42 Page d'authentification
C’est la page initiale qui permet d’accéder à l’application suivant le rôle de l’utilisateur
qui va connecter (superviseur, administrateur ou simulateur), et par la suite les meus
qui correspond à son rôle vont être affiché.
Figure 43 Liste des ressources par profil
Page | 67
Réalisation
Dans la figure ci-dessus, une liste des ressources avec leurs profils, situé en haut un
filtre qui affecte un raffinement sur la liste par rapport au nom, prénom au bien au rôle.
Ce menu ne peut être accédé que par l’administrateur pour donner à chaque utilisateur
le rôle correspondant.
Figure 44 Edit d'un profil affecté
Comme le montre cette écran, le champs rôle est le seul champ saisissable pour
modifier ou affecter un profil, le reste ce n’est pas le cas de ce menu.
Figure 45 Consultation des profils
Page | 68
Réalisation
On peut aussi consulter l’état de ressource après le changement de profil.
3.1.1 Burndown Chart
140
120
Reste à Faire (heures)
100
80
Taches Ideales Restantes

60
Taches Actuel Restantes
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Temps (jours)
Figure 46 Burndown Chart de Sprint 1
Au début de sprint 1, la réalisation des taches demandés est avancée de manière idéale,
jusqu’au tache de la gestion d’accès dans laquelle j’ai trouvé quelque difficulté ce qui
est traduit par cette courbe.
3.2 Sprint 2
Le Sprint 2 a mis l’accent sur l’etude de la simulation :
Figure 47 Liste des Simulations
Page | 69
Réalisation
On remaque que la figure ci-dessus represente la liste des simulations avec des actions
devant chaque ligne :
✓ Consulter : pour afficher les details de la simulation selectionnée
✓ Simuler : pour lancer une simulation des ressources les plus adéquats
✓ Supprimer : pour supprimer une simulation selectionnée
✓ Valider : Si la simulation attient la condition8 d’etre un preprojet ,elle devient
dans ce cas prêt a etre validée et devenir un projet consistant
Remarque : on peut trouvé des simulation prêt à etre validée et d’autre pas encore à
cause de nombre des ressources affectées.
Figure 48 Création d'une simulation
8 Nombre des ressources demandées égal au nombre des ressources affectées
Page | 70
Réalisation
La phase de création d’une simulation se fait sur deux étapes, le saisi des champs
nécessaires dans un premier lieu et l’affectation des compétences demandés avec leurs
niveaux dans un deuxieme lieu.
Sachant que chaque ligne de compétence affectée peut être supprimée par l’icône
« trash » qui est traduit par l’écran ci-dessous.
Figure 49 Suppression d’une compétence affectée
Après la creation , le simulateur a le droit de consulter la simulation crée.
Page | 71
Réalisation
Figure 50 Consultation Simulation
Page | 72
Réalisation
Passant maintenant à la phase de la simulation, dans cette étape notre système va

générer une analyse interne à partir de la base des données de tous les ressources de
TalentVioo, et il va chercher celle qui sont les plus adéquats à la simulation
sélectionnée.
Par la suite les courbes et les chartes correspondant vont être générés pour mieux
présenter les informations trouvées par notre moteur interne.
Le taux d’adéquation a été généré par deux méthodes : la première basée sur des
formules interne, et la deuxième sur un système expert externe.
La figure ci-dessous présente la 1ère proposition :
Figure 51Tableau d'adéquation
Page | 73
Réalisation
La 2em proposition :
API Google Prédiction :
Google Cloud Prédiction API fournit une API RESTful exploitable pour créer des
modèles d’apprentissage par machine, (Machine Learning).
Pour bénéficier de ce produit, on a besoin de travailler avec le concept de web service
(REST) c’est pour cela on a cité quelques portions de code sur 3 phase différentes :
Phase d’apprentissage : C’est la faite de remplir la base de faits et règles de notre
Système.
$user = $this->getDoctrine()-
>getRepository('ApplicationSonataUserBundle:User')->findAll();
$userJson=json_encode($user,true);
POST
https://www.googleapis.com/prediction/v1.6/projects/MLTestJamel/trainedmode
ls
{
"id": "ressource-identifier",
"storageDataLocation": $userJson
}
Phase de test : c’est d’envoyer une requête pour tester la machine Learning :
$object = $this->admin->getObject($id);
$var1 = $object->getParams();
$sim = json_decode($var1, true);
POST https://www.googleapis.com/prediction/v1.6/projects/prediction-
docs/trainedmodels/ressource-identifier/predict
{
"input": {
"csvInstance": $sim
}
}
Phase de récupération des données : Après le calcul de la requête envoyée il faut

récupérer le résultat obtenu :
{
"kind": "prediction#output",
"id": "ressource-identifier",
"selfLink":
"https://www.googleapis.com/prediction/v1.6/projects/prediction-
docs/trainedmodels/ressource-identifier/predict",
"outputMulti": [
{
"label": "admin",
"score": "66.521000"
},
{
Page | 74
Réalisation
"label": "Gharsallah",
"score": "43.069350"
},
{
"label": "Chebeane",
"score": "26.086200"
},
{
"label": "Ben Mbarek",
"score": "9.15200"
}
]
}
L’affichage finale :
Figure 52 Taux d'adéquation proposé par le système expert
Le système Expert proposé par Google et exploité par notre application a proposé les
valeurs d’adéquation ci-dessus, ils sont plus exacts, car plusieurs valeurs interagissent
sur cette valeur donnée.
Page | 75
Réalisation
3.2.1 Burndown Chart
140
120
100
80
60 Taches Ideales Restantes

40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Temps (jours)
Au niveau de ce Sprint j’ai rencontré un problème dans la traduction de besoin, car il

est demandé de faire une simulation qui ne sera pas encore stocké comme une entité
dans la base de données tant qu’elle n’est pas encore validée, d’où on a pensé de faire
une table simulation dans laquelle on stocke la simulation sous forme de code JSON.
La 1ère phase de sprint est consommée dans la recherche d’une solution pour la tâche
de création d’une simulation et l’emplacement où elle va être stocké. Par la suite j’ai
accéléré dans le reste des taches pour arriver à la date de livraison avec le travail
demandé.
3.3 Sprint 3
Après la génération de la tableau de simulation l’utilisateur doit pouvoir accéder aux
plus de details, il doit donc consulter un rapport comparatif entre les competences
acquis par la ressource selectionnée et celle demandées par le simulation.
D’où on a pensé à l’ecran ci-dessous des choix des ressources accompagné par la
remarque correspondante.
Sachant que l’utilisateur peut consulter le plan des charges de la ressource selectionné
par un lien situé en haut et à droite, pour l’aider à prendre la decision de l’affectation.
Page | 76
Réalisation
Figure 54 Liste comparatifs entre les compétences
Page | 77
Réalisation
Par la suite il est demandé de générer le radar dynamique en dessous pour mettre en
évidence la différence entre les niveaux des compétences des deux bouts.
Figure 55 Radar des compétences
Figure 56 Grille des compétences
Page | 78
Réalisation
La grille des compétences ci-dessus présente une liste des ressources et leurs
compétences affectées accompagné par d’autre informations tel que son poste , le
nombres d’années d’expérience, besoin visa …
3.3.1 Burn down chart
140
120
100
80

60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Temps (jours)
Concernant le Sprint 3 la tâche la plus difficile au niveau de laquelle j’ai passé beaucoup
du temps c’est la génération de Radar des compétences, c’est pour cela on remarque le
pique qui se situe au milieu de la courbe.
Page | 79
Réalisation
3.4 Sprint 4
Figure 58 Exemple de plan des charges pour un collaborateur
Le plan des charges est une sorte de tableau organisé selon une calendrier présente la
charge de chaque ressource par date et par projet.
Comme la figure nous montre , j’ai fait un exemple de filtrage sur le plan des charges
par la ressource Myriam Bourguiba.
Page | 80
Réalisation
140
120
100
80

60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Temps (jours)
L’évolution de travail au cours de ce Sprint est représentée au voisinage de la courbe

des taches idéales effectué, ce qui traduit un bon déroulement de la réalisation.
3.5 Sprint 5
Figure 60 affectation des ressources au mission
Page | 81
Réalisation
Figure 61 Détail mission après l'affectation
Page | 82
Réalisation
Après l’affectation de la ressource comme la figure 59 nous montre, on peut remarquer

dans figure suivante une réussite d’opération par le message en haut, et l’ajout d’une
nouvelle ressource affectée.
Figure 62 Suppression d'une ressource affectée
On a aussi la possibilité de supprimer n’importe quelle ressource affectée.

Dans une dernière étape, si le nombre des ressources demandé est égal au nombre des
ressources affectées alors l’utilisateur peut valider la simulation pour devenir enfin un
projet consistant comme la figue nous montre au-dessous.
Figure 63Liste des projets après validation
Il peut aussi consulter son détail et affecter une recherche avancée sur la liste par type
ou par titre de projet.
Page | 83
Réalisation
140
120
100
80

60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Temps (jours)
A cause du temps serré et de rapprochement de la date de dépôt, j’ai été obligé

d’accélérer le travail et d’achever le Sprint le plus tôt possible, c’est pour cela on
remarque que les nombres d’heures de travail demandés est achevé avant de 3 jours.
Conclusion
En guise de conclusion, nous avons achevé les différentes phases d’analyse, de
conception et de réalisation pour clôturer par une harmonie d’implémentation
graphique permettant de répondre aux besoins de notre cahier des charges proposé
par la société WEVIOO.
Page | 84
Conclusion générale et perspective
Conclusion générale et perspective
Notre projet présente plusieurs objectifs majeurs, tant sur le plan fonctionnel que sur
le plan technique, d’un point de vue fonctionnel, la tâche d’affectation des ressources
au projet, au sein d’une société qui possèdent un nombre d’effectif important présente
un processus décisif et une phase incontournable dans la politique de toute entreprise
qui accepte des grands projets.
Dans ce contexte, notre projet fin d’étude s’est déroulé au sein de la société Wevioo afin
de réaliser un module basé sur un Simulateur d’affectation des ressources humaines
avec proposition d’un système prédictif.
Cette application offre comme service la possibilité de calculer l’affectation des
ressources aux missions selon l’adéquation de leurs compétences à la mission et leurs
disponibilités par rapport au plan des charges.
Afin d’atteindre cet objectif, nous allons tout d’abord faire une étude de faisabilité, une
phase de réflexion a été évoqué pour permettre aux différents acteurs du système de
tracer les lignes directrices du projet et définir la méthodologie du travail.
Suite à ces phases, on est arrivé à établir une analyse approfondie des besoins
fonctionnels et non fonctionnels.
Pour la dernière phase de la partie théorique, on a pu ajuster la conception nécessaire
pour définir les architectures et les modèles nécessaires à l’exécution de la partie
technique.
Par la suite on a attaqué la phase réalisation de ce projet qui a été bénéfique sur deux
plans : professionnel et personnel.
En effet cette expérience nous a donné la possibilité de découvrir le monde de
Symfony2 et ses différents bundles utilisés, en plus il nous a permis d’améliorer nos
connaissances dans le développement web PHP.
Finalement on peut dire que l’application a pu répondre aux différents besoins
demandés, mais hormis ces avantages, une éventuelle évolution consiste à se
concentrer plus dans le système expert, et intégrer le plan des charges dans la base des
faits pour arriver à une estimation d’adéquation plus précise.
Page | 85
Résumé
Résumé
Ce travail s’est inscrit dans le cadre du projet de fin d’études en vue de l’obtention du
diplôme national d’ingénieur en téléinformatique au sein de l’institut Supérieur
d’Informatique et des techniques de communication de Hammam Sousse (ISITCom).
Il consiste à mettre en place une application basée sur simulateur d’affectation des
ressources humaines avec proposition d’un système prédictif.
La solution est développée sous le Framework Symfony 2 avec une base de données
MySQL accompagné de son outil ORM Doctrine 2, sans oublier les langages HTML5,
CSS3 et JavaScript.
Mots-clés : Simulation, Taux d’adéquation, Symfony 2, Doctrine.
Page | 86
Références
Références
[1] : www.theses.fr/2014EMNA0188.pdf [consulté le 01/04/2017]

[2] : http://scrumblr.ca/test [consulté le 30/04/2017]
[3] :http://deptinfo.unice.fr/twiki/pub/Linfo/ABGP/coursABGP-miage-1112-4p1.pdf
[consulté le 05/04/2017]
[4] :http://ineumann.developpez.com/tutoriels/alm/agile_scrum/ [consulté le
06/04/2017]
[5] :http://www.slideboom.com/presentations/104630/CM-processus-agile
[6] : https://www.scrumalliance.org/community/articles/2011/january/why-scrum-
works [consulté le 01/05/2017]
[7] :https://stackoverflow.com/documentation/php/5453/machine-
learning#t=201703140111110416215 [consulté le 05/05 /2017]
[8] : http://prof.bpesquet.fr/cours/modele-mvc/ [consulté le 20/05 /2017]
[9] :https://blog.jetbrains.com/phpstorm/2015/12/phpstorm-10-0-2-bug-fixes-
update-is-available/ [consulté le 19/05/2017]
[10] : https://commons.wikimedia.org/wiki/File:WampServer-logo.png [consulté le
19/05/2017]
[11] :http://www.clubic.com/telecharger-fiche430839-mysql-workbench.html
[12] :https://www.pinterest.com/pin/296393219210777760/ [consulté le
16/03/2017]
[13] :http://gooseberrycreative.com/works/2013-08-Cmder/ [consulté le
16/05/2017]
[14] : http://pencil.evolus.vn/ [consulté le 14/05/2017]
[15] : https://symfony.com/ [consulté le 06/02/2017]
[16] : https://twig.sensiolabs.org/ [consulté le 06/02/2017]
[17] :http://blog.nicolashachet.com/niveaux/confirme/surcharger-vos-entites-
doctrine-en-symfony-2-exemple-avec-le-fosuserbundle/ [consulté le 10/02/2017]
[18] : http://php.net/manual/fr/index.php [consulté le 06/02/2017]
Page | 87
Epigraphe
Epigraphe
« Tu peux tout accomplir dans la vie si tu as le courage de le rêver, l'intelligence
d'en faire un projet réaliste, et la volonté de voir ce projet mené à bien. »
Vauvenargues
Page | 88

Simulateur Daffectation Des Ressources H

Transféré par

Droits d'auteur :

Formats disponibles

Simulateur Daffectation Des Ressources H

Transféré par

Informations du document

Description originale:

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

Simulateur Daffectation Des Ressources H

Transféré par

Droits d'auteur :

Formats disponibles

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

‫المعهد العالي لإلعالمية وتقنيات االتصال بحمام سوسة‬

Institut Supérieur D’informatique

MEMOIRE DE PROJET DE FIN D’ETUDES

Simulateur d’affectation des ressources

Réalisé par : Takali Jamel

Je tiens alors à leur exprimer ma vive reconnaissance et ma gratitude.

J’adresse enfin, ma plus vive reconnaissance à tous mes enseignants de l’Institut

Table des matières

5. Modélisation des besoins ....................................................................................19

3.3 Sprint 3......................................................................................................... 76

Liste des figures

Figure 1 organigramme de Wevioo................................................................................. 4

Figure 41 Diagramme de Gantt avec les dates importants .......................................... 66

Liste des tableaux

Tableau 1 tableau des choix des méthodologies ............................................................. 7

La compétitivité des entreprises repose essentiellement sur leur capacité à utiliser

Ce projet vise à améliorer le processus de choix et d’affectation des ressources et ce

Le premier chapitre « Cadre du projet et Méthodologie » porte sur la présentation du

Le deuxième chapitre « Analyse et Spécification des besoins » comporte une analyse

Le troisième chapitre « Conception » présente une conception détaillée du projet.

Présentation du cadre du projet

1. Présentation de l’organisme d’accueil

1.1 Présentation générale et services

1 Est le fait de délocaliser une action économique

✓ Consulting : AMO, PMO, ré-engineering des processus et consulting métier.

Figure 1 organigramme de Wevioo

Dans la figure ci-dessus nous remarquons que l’architecture se décompose en deux

1.2 Secteurs d’activité

2 Software Engineering : génie logiciel

✓ Services bancaires et Financiers : WEVIOO apporte son savoir-faire et ses

✓ Distribution : WEVIOO met en place des solutions complètes allant du back-oﬃce

✓ Secteur Publique : à travers l’assistance à la maîtrise d’ouvrage, le Conseil en

✓ Service : à travers la mise en place des outils d’analyse et d’aide à la décision.

✓ Télécom : WEVIOO accompagne les opérateurs de la région dans leurs projets de

C’est également le cas de Wevioo qui soulève plusieurs difficultés relevant de la

collaborateurs à ceux des missions et de leur disponibilité par rapport au plan de

2.2 Description du projet

3. Choix de la Méthodologie de Travail

3.1 Les Méthodes Agiles

Nous procédons maintenant au choix de la méthode agile à adopter pour la réalisation

Méthode Points forts Points faibles

XP ✓ forte réactivité au changement ✓ Nécessite une forte implication du

SCRUM ✓ Découpage du projet en sprints de ✓ L’évolution des besoins amène les

Tableau 1 tableau des choix des méthodologies

3.3 Méthodologie Agile Scrum

La méthode Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un

De Point de vue visibilité pour l’équipe et le client :

✓ Sprint : Un sprint est une période de temps déterminée pendant laquelle le

✓ Release : Pour mieux organiser l’avancement de projet, la Release regroupe un

✓ Quotidien : (Daily Meeting) : c’est une réunion quotidienne se fait au début de la

3 L’estimation de la complexité des taches avec l’intervention de toute l’équipe Scrum

Figure 2 le processus de développement SCRUM [4]

La figure 2 montre la production d’une version du logiciel, ce qui se fait en général en

3.7 Équipe et rôle

✓ Le Scrum Master : ou bien le directeur de produit, C’est le leader de l’équipe

Analyse et spécification des besoins

Au sein de Wevioo ou n’importe quelle société, lors de l’acceptation de nouveau projet