Université de Technologie de Compiègne 
 
 
 
 

LO23 
Plan de management de projet 
 
 
 
 
04 Janvier 2016 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
Sommaire 
 
1.     Introduction 
1.1 Objet du document 
1.2 Contexte du projet 
1.3 Nom du projet 
1.4 Membres de l’équipe 
2.      Le périmètre du projet 
2.1 Les enjeux et objectifs du projet 
2.2 Les domaines traités 
2.3 Les livrables du projet 
2.4 Les contraintes de réalisation 
3.     Découpage du projet 
3.2.2 Work Breakdown Structure (WBS) 
4.     Coordination 
4.1 Gestion de la communication 
5.     Planning du projet 
5.1 Planning prévisionnel 
5.2 Planning réel 
5.3. Planning d’ordonnancement des tâches 
5.3.1 IHM­MAIN 
5.3.2 IHM­Table 
5.3.3 Communication 
5.3.4 Gestion et traitement des données 
6.     Évaluation des charges 
6.1. Réalisation du dossier de conception 
6.3. Développement 
6.4. Intégration 
7.     Gestion des risques 
7.1 Identification, évaluation et quantification des risques 
7.2 Stratégie de gestion des risques 
8.      Gestion de la qualité 
9.      Déroulement du projet 
9.1 Processus décisionnel 
9.1.1 Client­Serveur vs PeerToPeer 
9.1.2 Gestion du profil 
9.1.3 Connexion 
9.1.4 Fenêtre principale 
9.1.4 Lancement d’une partie 
9.1.5 Déconnexion & hearthbeat 
9.2 Liste des autres décisions prises 

1 
 9.2.1 Choix technologiques 
9.2.2 Outils de management 
 
 
   

2 
 1.​ Introduction 
     ​

  
1.1 Objet du document 
  
Ce  document  constitue  le  plan  de  management  de  projet  (PMP)  qui  documente  l’ensemble  
des  actions  nécessaires  pour  définir,  préparer,  intégrer  et  coordonner  l’ensemble  des  plans 
d’action  nécessaires  pour  mener  le  projet  à  bien.  Il  définit  comment  le  projet  sera  réalisé, 
suivi  et  contrôlé,  et  mené  à  bien  jusqu’à  terminaison,  en  lui  associant  les  activités  et 
ressources  nécessaires.  Il  fait  l’objet  d’une  validation  indispensable  à  la  mise  en  œuvre  du 
projet  et  d’actualisations  (révisions)  qui  surviendront  au fil des changements et évolutions du 
projet.  Le  plan  de  management  de  projet  est  toujours  réalisé  avec  les  parties  prenantes  du 
projet  et  les  acteurs  chargés  de  sa  bonne  réalisation  (responsables  des  lots   de  travaux  et 
acteurs  experts)  et  du  suivi   de  sa  gestion  (équipe  projet).  Le  chef  de  projet  devra  savoir 
mobiliser  autour  de  sa  réalisation.  C’est  sa  principale  condition  d’efficacité.  Le  PMP  est 
toujours  associé aux autres documents et plans qui contribueront à la réussite du projet. Parmi 
lesquels  certains  documents  indispensables  (référentiels  périmètre,   ressources,  délais,  coûts) 
et  d’autres  qu’il  est  recommandé  de  lui  associer  :  plan  de  management  des  risques,  de  la 
qualité, des ressources, des délais, des coûts, de la communication, des approvisionnements. 
  
1.2 Contexte du projet 
  
Dans  le  cadre  de  l’UV  LO23,  portant  sur  le  thème  de  la gestion de projet informatique, nous 
devons  réaliser,  en   équipe  d’environ  20  personnes,  une  application  PC  de  jeu  de  poker 
multijoueur. 
  
1.3 Nom du projet 
  
Faisant  partie  d’une  UV  de  notre  cursus  d’ingénieur  à  l’Université  de  Technologie  de 
Compiègne,  le  projet  porte   le  nom   de  la  matière  concernée  ainsi  que  son   utilité  : 
Poker_Game_LO23 
  
1.4 Membres de l’équipe  
 
Le projet ici présenté est découpé en quatre groupes. 
­ IHM­Main  : Victor LECLERC (directeur),  Frédéric CUNI (manageur), Jean­Baptiste 
(développeur), Romain DI FATTA (étude, qualité), Paul Jenny (conception), 
­ IHM­Table  :  Thibault  Brocheton  (directeur),  Yaya  Tambadou  (manageur),  Quentin 
Pena (développeur), Bastien Fremondiere (étude), Gabrielle Rit (conception), 
­ Gestion  et  traitement  des  données  :  Harold  Carrel  Billiard  (directeur), 
Ying(manageur), Rémy(développeur), Jianghan (conception), Marouane (qualité), 

3 
 ­ Communication  ​
:  Guillaume  VASSAL  (directeur),  Jean­Côme  (manageur),  Cedric 
BACHE (développeur), Victor (étude), Raphael K (conception), Raphael B (qualité). 
 
 2.​  Le périmètre du projet 
     ​

  
2.1 Les enjeux et objectifs du projet 
  
Le  projet  a  pour  but  de  réaliser  une  application  de  jeu  de  poker  en  ligne.  Un  utilisateur, 
désirant  jouer  au  poker,  se  connecte  sur  l’application,  s’identifie   et  se  retrouve  sur  la  page 
principale  de  l’application.  Il  peut  voir  ainsi  les  joueurs  connectés  sur  le  même  serveur  que 
lui,  peut  ajouter  et  gérer  une  liste  de  contact  et  peut créer ou rejoindre une partie de poker en 
tant que joueur ou spectateur. 
  
2.2 Les domaines traités 
  
Les  domaines  traités   dans  le  cadre  de  ce  projet  est  en  premier  lieu  la  gestion  d’un  projet 
informatique.  Étant  une   équipe nombreuse, nous devons coordonner nos connaissances, notre  
communication  ainsi  que  notre  aptitude  à  travailler  en  équipe.  De   plus  nous  pourrons 
également renforcer nos connaissances en développement objet et conception UML. 
  
2.3 Les livrables du projet 
  
Le  premier  livrable  du  projet  est  daté  au  13  octobre  et  comprend  tout  ce  qui  est  relatif  à  la 
conception  du  projet,   le  découpage  des  tâches,  les  diagrammes  UML,  ainsi   que  les  futures 
tâches à réaliser. 
  
Le  deuxième  et  dernière  partie  de  livrables,  devra  être  rendue  le  5  janvier  2016.  Celle  ci  est 
constituée  d’une  soutenance  sur  la  fin  du  projet,  du  plan  de  management  final, du dossier de 
réalisation ainsi que des codes sources et des exécutables du projet. 
  
2.4 Les contraintes de réalisation 
  
Comme  évoqué  précédemment,  le  projet  est  réalisé  par  une  équipe  assez  nombreuse,  ce  qui 
peut  rendre  difficile  l’avancement  du  projet  :  problème  de   communication,  d’écoute, 
d’entente. 
Une contrainte de temps est aussi stipulée pour ce projet : 
­ Dossier de conception et plan de management de projet : 19 Octobre 2015 
­ Plan  de  management  final,  dossier  de  réalisation,  codes  sources  et  exécutables  :  5 
Janvier 2016 
­ Soutenance : 5 Janvier 2016 

4 
 3.​ Découpage du projet  
     ​

  
3.1 Découpage temporel  
 
Le  découpage  temporel  nous  a  permis  de  répartir  dans  le  temps,  la  production  ainsi  que  les 
ressources,  c’est  à  dire  le  travail  a  effectuer.  Nous  avons  opté  pour  un  découpage  temporel 
constitué de trois phases à savoir :  
● Phase de conception 
● Phase de développement 
● Phase d’intégration et de tests 
 
Chaque  phase  est  composée  d’activités,  chacune  définie  par  des  tâches  à  effectuer.  Chaque 
élément de la décomposition est associé à un livrable, et des dates de début et de fin. 
 
3.1.1 Phase de conception  
 
Les activités de la phase de conception, réalisée dans un premier temps sont :  
● Étude du cahier des charges ainsi que du besoin 
● Réalisation des diagrammes use­cases 
● Réalisation des diagrammes de séquences 
● Réalisation des maquettes 
 
3.1.2 Phase de développement 
 
Après  la  phase  de  conception,  chaque  sous­groupe  a  identifié  des  tâches  à  effectuer  et  à 
développer.  Un  compte­rendu  hebdomadaire de l'avancement a été réalisé en chaque début de 
séance.  Ce  dernier  nous  a  permis  d’évaluer  la  charge  de  travail  restante  pour  chaque 
sous­groupe et de régler des difficultés inter­groupe et intra­groupe.  
 
3.1.3 Phase d’intégration et de tests 
 
Nous  avons  opté  pour  une  intégration  continue  après  trois  semaines  de  développement. 
Comme  évoqué  précédemment,  en  début  de  séance  un  compte   rendu  des  fonctionnalités 
réalisées  par  module  est évoqué pour mettre en exergue les fonctionnalités que nous pouvions 
intégrer durant la séance.  
Pour  ce  faire,  les   membres  intégrateurs  de  chaque  groupe   se  réunissaient  pour  intégrer  le 
travail  précédemment  sélectionné.  Ainsi,  nous  avons  définis  également  un  planning   de 
développement  afin  d’intégrer  des  blocs  fonctionnels,  et  permettre  de  sortir  des  versions 
pre­alpha. 
L’intérêt  de l’intégration continue est de pouvoir intégrer tout le code de manière progressive, 
et  ainsi  de  rendre  accessible  à  tous  les  groupes  ce  qui  a  été réalisé par les différents groupes. 

5 
C’était  notamment  primordial  concernant  les  classes  d’objets  crées  par  l’équipe  Data,  qui 
étaient  nécessaires à chacun des groupes. En contrepartie, l’intégration continue a mobilisé au 
moins  un  membre  de  chaque  équipe pendant tous les TD consacrés au développement, ce qui 
est coûteux en terme de charge de travail.  
 
Durant  l’intégration,   des  tests  d’intégration  ont  également  été  effectué  pour  vérifier  la 
cohérence  et  la  fonctionnalité  du  travail.  En  cas  de  problème  de  fonctionnement,  le  code 
relatif à ces fonctionnalités a été modifié, intégré et testé.  
 
3.1.4 Cycle de développement 
 
L’ensemble  ordonnancé  des  phases  du  projet  s’appelle  le  cycle   de  vie  du  projet.  Ainsi  le 
cycle de vie est par conséquent un cycle en spirale. 
 

 
Le  développement  en  spirale  reprend  les  différentes  étapes  du  cycle  en  V.  Par 
l'implémentation  de  versions  successives,  le  cycle  recommence  en  proposant  un  produit  de 
plus en plus complet et robuste. 
En  effet,  compte  tenu  des  intégrations  successives  au  sein  du  projet,  nous  avons  réalisé  par 
conséquent  plusieurs  cycle   en  V,  proposant  ainsi  une  version  de  l’application  plus  complète 
et fonctionnelle après chaque intégration.  
6 
 
3.2 Découpage structurel 
 
Le  découpage  structurel  permet d’organiser le travail en  fonction de la structure du produit. Il 
a été fait de la manière suivante : 4 sous groupes ont été créés : 
● IHM­Main 
● IHM­Table 
● Gestion et traitement des données 
● Communication 
 
Chaque sous groupes est constitué à son tour : 
● d’un directeur de projet 
● d’un manageur 
● d’un concepteur 
● d’un développeur 
● d’un responsable qualité 
● d’un responsable d’étude 
 
3.2.1 Organisation : Ressource Breakdown Structure (RBS) 
 
Le  découpage  structurel  normalisé  ci­dessous  réprensente  le  découpage  du  projet  en  sous 
groupe, chacun découpé à leur tour. 
 

 
 
 
 
 
 

7 
 3.2.2 Work Breakdown Structure (WBS) 
 
Le  découpage  temporel  normalisé  ci­dessous  correspond  à  une  décomposition  sous  forme 
arborescente des différentes activités à mener pour parvenir au produit final. 
  

   
  
4.     Coordination 
  
4.1 Gestion de la communication 
 
La  communication  du  projet  est   gérée  sur  différents  niveaux.  Tout  d'abord,  au  niveau  de 
l’ensemble  du  groupe,  nous  communiquons   par  mail  et  via  le  drive  pour les informations les 
plus  importantes  que  tout  le  monde  doit  recevoir.  Nous  avons  également  mis  en  place  un 
slack,  un  chat  instantané  comportant  un  channel  général  et  des  channels  propres  à  chaque 
sous­groupe.  
Ensuite,  au  sein  des  différents  groupes de développement, le manager est en  charge de mettre 
en  place  une  communication  efficace  pour  permettre  la  transmission  d'information  la  plus 
efficace  possible.  En  général,  le  manager  dispose  des  numéros  de  téléphone  de  chaque 
membre de son équipe. 
Enfin,  il  existe  aussi  une  communication  entre  les  différents  groupe  qui  est  réalisée  par  les 
directeurs. 
Les outils utilisés sont : 
­ Les mails (Mailing list) 
­ Un slack 
­ Les  outils  de  communication  du  drive  sur  lequel  sont  rassemblés  nos  documents  de 
gestion de projet. 
 
   

8 
 5.​ Planning du projet 
     ​

  
  5.1 Planning prévisionnel 
  
15/09/2015  Répartition en sous­groupes, planification 
22/09/2015  Diagramme cas d'utilisation + Séquence 
29/09/2015  Séquence 
06/10/2015  Séquence + Classe 
13/10/2015  Finalisation du rendu  Conception 

20/10/2015    
27/10/2015  Vacances 

03/11/2015    
10/11/2015  Mardi transformé en Samedi 

17/11/2015    

24/11/2015     Développement 

01/12/2015    

08/12/2015    

15/12/2015     Intégration 

22/12/2015  Préparation soutenance    

29/12/2015  Vacances    

05/01/2016  Soutenance    
  
   
   

9 
 5.2 Planning réel 
  
15/09/2015  Répartition en sous­groupe, planification 
22/09/2015  Diagramme cas d'utilisation + Séquence 
29/09/2015  Séquence 
06/10/2015  Séquence + Classe 
13/10/2015  Finalisation du rendu  Conception 

20/10/2015  ­ 

27/10/2015  Vacances 

03/11/2015  ­ 

10/11/2015  Mardi transformé en Samedi 

17/11/2015  ­ 

24/11/2015  ­ 

01/12/2015  ­ 

08/12/2015  ­ 
Développement + 
15/12/2015  ­  Intégration 

22/12/2015  ­  intégration finale 

29/12/2015  Vacances    

05/01/2016  Soutenance    
  
 
 
   
   

10 
 5.3. Planning d’ordonnancement des tâches 
  
5.3.1 IHM­MAIN 
 
 Diagramme de GANT sur l’ensemble du projet. 
 

 
 
   

11 
  
5.3.2 IHM­Table 
 
Diagramme de Gantt du développement 
 
 
  Oct  Nov    Dec    Janv 

Tâches  20  3  10  7  24  1  8  15  22  5 

Configuration Git     
Interface de la table     
Formulaire création de 
table     
Intégration     
Interfaces     
Animation des cartes     
Ajout des images de 
l'interface     
Chat     
Bouton Lancement de 
la partie     
Placement des joueurs     
Mise en forme 
graphique (CSS)     
Ajout emplacement de 
l'avatar des joueurs     
Rédaction des livrables     
 
 
 
   

12 
 5.3.3 Communication  
 
Diagramme de Gant du développement. 
 

 
 
5.3.4 Gestion et traitement des données 
 
Diagramme de GANTT sur l’ensemble du projet. 

 
 
 
6.​ Évaluation des charges 
     ​

  
L'évaluation  des  charges  est  réalisée  en  plusieurs  parties.  Une  première  partie  générale 
comprenant  essentiellement  la  réalisation  du  dossier  de  conception.  Ensuite,  une  seconde 

13 
partie  comprenant  le  développement  qui  doit  être  faite  par  chacun  des  groupes,  et  enfin  une 
partie intégration et lancement de projet qui est générale. 
 
 
6.1. Réalisation du dossier de conception 
 
● Diagramme de cas d'utilisation : 1 TD ce qui représente 3h/étudiant 
● Diagramme de séquence : 3 TD ce qui représente 9h/étudiant 
● Diagramme de classe : Réalisé par le groupe "DATA" => 4h/étudiant du groupe 
● Diagramme de classe des autres groupes => 1h/étudiant du groupe 
● Ecriture du dossier de conception => 2h/responsable conception 
● Relecture du dossier => 4h 
 
6.3. Développement 
 
La  phase  de  développement  a  durée  8  TD  +  une  séance  de  2  heures  supplémentaires,  ce  qui 
représente  dès  lors  26h/étudiant,  +  des  séances d’intégrations prévus le jeudi soir + du travail 
personnel.  
 
    Groupe IHM Main 
 
Pour  l’ensemble  des  membres  du  groupe,  le  travail  personnel  réalisé  en  dehors  des  séances 
est estimé à 2h/semaines. 
Des réunions tout au long du semestre durent également effectuées pour avancer au mieux sur 
le  projet.  Généralement,  ces réunions se déroulaient le mardi avant la  séance de TD, durant la 
séance du deuxième groupe de TD.  
Donc, en moyenne, l’évaluation des charges est portée à 47h/étudiant. 
 
    Groupe IHM Table 
 
  Nous  estimons  la  charge  de  travail  des  membres  à  3h/semaine  lors  des  4  dernières 
semaines,  ce  qui  en  plus  des  3  heures  par  TD  nous  amène  à 48h/etudiant. Cependant, il est à 
noter que notre directeur s’est particulièrement investi dans ce projet, et a donc beaucoup plus 
travaillé que ne l’indique cette moyenne. 
 
    Groupe Communication 
   
Nous  avons  tout  d’abord  réalisé   plusieurs  réunions  tous  ensemble  au  début  du  projet  pour 
réaliser  le  modèle  conceptuel  et  le  serveur.  Nous  pouvons  comptabiliser  que  ces  réunions 
nous prenaient 3h/personne par semaine en début de réalisation (7 semaines). 
Ensuite,  une  fois  le  serveur  et  le  client  mis  en  place,  notre  travail  était  simplifié,  nous avons 
alors  travaillé   chacun  de  notre  coté,  nous  pouvons  donc  estimer  ce  travail  à  1h  par  semaine. 

14 
S’ajoute  à  cela  les  séances  d’intégration  supplémentaires,  que   l’on  peut  compter  comme  1h 
par semaine jusqu'à la fin de la réalisation.  
En moyenne, l’évaluation des charges par personne est de 44h/étudiant.  
 
 
    Groupe Data 
 
Nous  avons  effectué  des  réunions  de  2  heures  chaque  lundi  soir,  lors  de  laquelle le directeur 
et  les  responsables  qualité  et  conception  étaient  présent,  ainsi  qu’une  présence  partielle  des 
autres  membres  du  groupe.  A  cela  s’ajoute  le  travail  personnel  effectué  par  chaque membre,  
variant  en  fonction  des  semaines,  mais  estimé  à  environ  2h  par  semaine  sur  l’ensemble  du 
projet pour chaque membre. 
Cela amène le total à environ 49h/étudiant en moyenne. 
 
6.4. Intégration 
 
L’intégration  était  réalisée  par  les responsable intégrateur pendant  les séances de TD, au total 
6  TD,  mais  également  pendant  la  séance  supplémentaire  de  2h  le   mardi  22  décembre,  ainsi 
que deux jeudi en soirée durant 2h.  
L’évaluation des charges de l’intégration est donc portée à 24h/responsable intégration. 
 
 7.​ Gestion des risques 
     ​

  
7.1 Identification, évaluation et quantification des risques 
 
Les risques que nous avons identifié au sein du projet sont : 
● La  répartition   des  charges  de  travail:  Déséquilibre  des  charges  de  travail  (mal 
évaluées) entre les groupes amenant un retard de certains groupes sur les autres. 
● La communication :  
○ Problèmes  d'intégration  au  moment  de  rassembler  les  différents  projets  des 
différents groupes par manque de communication. 
○ Non  communication  au  sein  d'un  même  groupe réduisant donc sa productivité 
fortement. 
●   Les technologiques: 
○ Non respect des normes de développement et des technologies choisies 
○ Mauvaise utilisation des outils de versionnage (ici GitHub) 
● Autres : 
○ Accidents  naturels/humain  à  l'un  des  membres  du  groupe  ou  aux  outils 
permettant le développement du logiciel 
○ Non  aboutissement  de  la  réalisation  de  toutes  les  fonctionnalités  demandées 
dans le cahier des charges 

15 
   
 
7.2 Stratégie de gestion des risques 
 
La  première  chose  à  considérer  pour  ce  projet  est   la  communication.  Si  celle­ci  est  mise  en 
place correctement, une partie des problèmes peuvent être résolus. 
En  effet,  dès  qu'un  problème  est  détecté,  il  doit  être  rapidement   remonté  et  toutes  les 
personnes  concernées  doivent  être  mises  au  courant.  Ensuite,  si  la  communication  se  fait 
correctement les différentes décisions seront prises de manière plus efficace. 
 
Les solutions pouvant être mises en oeuvre sont: 
● La  rencontre  des  différents  membres  de  chaque  groupe  chaque  semaine  pour  faire  le 
point sur l'avancement du projet. 
● La  rencontre  de  tous  les  directeurs  pour  mettre  en  commun  les  problèmes  rencontrés 
dans chaque groupe et faire passer les messages efficacement. 
● La  rédaction  de   compte  rendu  suite  à  chaque  réunion  et  chaque TD accessible à tous, 
pour que tout le monde puisse être au courant de l'avancement. 
● La  mise  à  l’écart  de  certaines  fonctionnalités  jugées  optionnelles  pour   permettre  de 
finir la réalisation du projet dans les délais.   
 
Ensuite,  en  cas  de  problème  interne  à un groupe, c'est au manageur de tenter au maximum de 
régler  les  conflits.  Étant  donné  que  nous  sommes  dans  une  réalisation  étudiante,  sans  réels 
chefs de projets, il est intéressant d'utiliser un management participatif. 
  Les  décisions  prisent  doivent  être  justifiées  et  notées  sur  le  document  "Décisions  prises" 
présent sur le drive. 
 
 
   

16 
 8.​  Gestion de la qualité 
     ​

 
Pour  la  gestion  de  la  qualité  nous  avons  opté  pour  l’utilisation  de  SonarQube,  qui  est  un 
logiciel en libre service permettant de mesurer la qualité du code source en continu.  
Le logiciel de qualité précédent permet :  
● d’identifier des ​duplications de code 
● de mesurer le niveau de ​ documentation 
● de vérifier le respect des ​règles de programmation 
● de détecter des ​bugs​ potentiels 
● d’évaluer la ​couverture du code​  par les ​
tests unitaires 
● d’analyser la répartition de la complexité 
● d’analyser le design et l'architecture de l’application 
 
Au  sein  de  chaque  sous­groupe,  des  responsables  qualités  ont  été  sélectionné  dans  le  but  de 
travailler continuellement sur les facteurs de qualités suivants :  
 
● Fonctionnel 
❖ pertinence : aptitude à répondre au problème posé 
❖ adéquation : adéquation du produit à l'organisation cliente 
❖ généralité : aptitude à répondre à des problèmes plus larges 
● Utilisation 
❖ maniabilité : aptitude à être convivial et facile d'emploi 
❖ fiabilité : aptitude à accomplir ses fonctions sans défaillance 
❖ efficience : aptitude à minimiser les ressources utilisées 
❖ confidentialité  :  aptitude  à  être  protégé  contre  tout  accès  à  des  personnes 
non­autorisées 
❖ couplabilite : aptitude à interagir avec d'autres systèmes (interopérabilité) 
● Maintenance 
❖ maintenabilité : facilité à localiser et corriger des erreurs résiduelles 
❖ adaptabilité : aptitude à évoluer facilement 
❖ portabilité : facilité à transférer dans un autre environnement 
● Economique 
❖ efficacité : rapport des coûts effectifs et d'utilisation par rapport au gain 
 
Une  Javadoc  est  également  générée  permettant  de  ​créer  une  ​
documentation  d'​ API  en  format  
HTML  depuis  les  ​ commentaires  présents  dans  un  ​ code  source  en  ​ Java​
.  Javadoc  est  le 
standard  industriel  pour  la   documentation  des  ​classes  Java.  La  plupart  des  ​ IDEs  créent 
automatiquement la javadoc HTML. 
 
 
   

17 
  9.​  Déroulement du projet 
     ​

  
9.1 Processus décisionnel 
  
9.1.1 Client­Serveur vs PeerToPeer 
  
Au  début  du  développement,  un  choix  s’offrait  à  nous  entre  une  application  réalisée  en Peer 
To Peer ou bien en client/serveur. 
L’application  en  Peer  To  Peer  avait  pour  avantage de ne réaliser qu’une “application” locale, 
pouvant communiquer avec les autres applications. 
L’application  en  client/serveur  était  plus  simple  à  développer  :  un  seul  serveur  gère  le  jeu et 
synchronise  de  manière  efficace  les  différentes  applications  locales.  Cette  solution  possède 
aussi  des  risques  de  goulot  d’étranglement  en  cas  de  traffic  important,  et  cela  nécessitait  de 
développer deux applications. 
Nous  avions  tout  d’abord  des  connaissances  plus  poussées  pour  la  solution  client/serveur. 
Ensuite,  il  nous  paraissait  plus  logique  qu’un  serveur  fasse  le  maître  du  jeu,  il  ne  nous 
paraissait pas forcément logique qu’un client fasse le déroulement du jeu,  et cela simplifiait la 
synchronisation.  
Nous  avons  fait  le  choix  de  faire  communiquer  le  serveur  seulement  avec  les  interfaces  de 
data, qui elles même communiquent avec les IHM. 

 
Le  serveur  communique   par  le  biais  de  ObjectOutputStream  et  ObjectInputStream   qui  sont 
des classes java permettant des objets sérialisés à travers des socket. 
Nous  avons  crée  un  classe  message,  possédant  deux  méthodes  process().  L’une   est  destinée 
au  serveur,  lorsqu’il  reçoit  un  message  provenant  d’un  client,  il  exécute  le  process  du 
message.  L’autre  est  à  destination  du  client,  lorsqu’il reçoit un message, il exécute  le process 
du  message.  Nous  passons  en  paramètre  de  ces  process  les  thread  qui  envoient  le  message, 
cela  permet  au  serveur  de  répondre  directement  au  client  s’il en a besoin ou bien au client de 
répondre  au  serveur.  Les  messages peuvent aussi avoir en attributs des objets qui doivent être 
sérialisables  pour  pouvoir  transiter  sur  le  réseau.  Nous  avons  donc  décidé  de  rendre  tous  les 
objets sérialisables. 

18 
  9.1.2 Gestion du profil 
 
Le  profil  local   de  l'utilisateur  est  synchronisé  avec  un  profil  temporaire  sur  le  serveur.  A 
chaque  modification  du  profil,  le  serveur  en  est informé. Il n'y a que le profil local stocké sur 
la  machine  de  l'utilisateur.  Dès  qu'un  utilisateur  souhaite  voir  un profil, il envoie une requête 
au serveur qui lui renvoie le profil de l’utilisateur concerné. 
Un  utilisateur  peut aussi modifier son profil. Cela provoquera une modification en local, mais 
aussi informera le serveur de cette modification. 
  
 9.1.3 Connexion 
 
Tout  d’abord,  le  client  doit  choisir   un  serveur. Il en existe un par défaut, mais il peut aussi en 
ajouter un, s’il a connaissance d’un serveur actif. 
Ensuite  lorsqu’il  se  connecte, l’application locale vérifie directement ses identifiants en local, 
puis,  s’ils  sont  bon,  le  connecte  au   serveur.  L'utilisateur  est  reconnu  sur  le  serveur  par  un 
UUID  unique.  Lorsqu’il  est  connecté,  il  reçoit  la  liste  des  tables  actives  et  des  joueurs 
connectés qu’il affiche. 
 
  9.1.4 Fenêtre principale 
 
Dès  qu'il  y  a  une  mise  a  jour  coté  serveur  (création  d’une  table,  lancement  d’une  table, 
connexion  d’un  joueur,  etc..)  on  notifie  tous  les  utilisateurs  du  changement.  Cela  pose  un 
problème  au  niveau  du  nombre  de notifications circulant sur le réseau à chaque modification, 
mais permet une synchronisation efficace. 
 
  9.1.4 Lancement d’une partie 
 
Un  utilisateur  peut  rejoindre  une  table  lorsqu’elle  est  active  mais  qu’elle  n’a  pas débutée. Le 
créateur   de  la  partie  peut  décider  de  lancer  la  table  s’il  y  a  un  nombre  de  joueurs  suffisant 
avec  lui.  Cela   envoie  alors  à  tous  les  autres  utilisateurs  une  demande  pour  savoir   s’ils  sont 
prêts. Si tous les joueurs indiquent qu’il sont prêt, la partie peut commencer. 
 
9.1.5 Déconnexion & hearthbeat 
 
Un  utilisateur  a  plusieurs  possibilités  pour  se  déconnecter.  Il  peut  tout  d’abord  quitter 
l’application  de  manière  conventionnelle  en  appuyant  sur le bouton quitter. A ce  moment, un 
message  est  envoyé  au  serveur,  sa  socket et fermée, et tous les  utilisateurs en sont  informé. Il 

19 
peut  aussi  quitter  l’application  de manière brutale en cliquant sur la croix rouge (alt F4). A ce 
moment  là,  l’action  est  repérée  par  IHM  Main  et  le  serveur  est  pareillement  informé  de  la 
déconnexion  de  l’utilisateur.  Enfin,  si  par  exemple  la  connexion  d’un  utilisateur  se  termine 
(coupure  internet),  le  serveur  doit  avoir  un  moyen  de  savoir  si l’utilisateur est déconnecté ou 
non. Pour cela, nous utilisons le principe du hearthbeat. 
De  manière  régulière,  chaque  client  envoie  au  serveur  un  ping  pour  le  signifier  de  sa 
présence.  Le  serveur  enregistre  ces  ping  et  les  stockent   dans  une  liste.  Si  le   serveur  n’a  pas 
reçu  de  ping  dans  un  intervalle  de  temps  équivalent  à  10  fois  la  fréquence  d’envoi  (cela 
permet  de  réguler  de  manière  correcte  même  s’il   y   a  de  la  latence),  alors  il  considère  que 
l’utilisateur  s’est  déconnecté  et  le  fait  quitter  la  partie/l’application.  Cela  permet  d’avoir  une 
communication dans un seul sens pour gérer les utilisateurs connectés. 
 
9.2 Liste des autres décisions prises 
  
9.2.1 Choix technologiques 
  
Langages de programmation​
 :  Java version : 1.8 
IDE ​
: Intellij IDEA 
Serveur ​
: Développé en java par le groupe COM. (socketServer, thread, objectInputStream) 
UML ​
: Modelio 
  
9.2.2 Outils de management 

  
Gestionnaire de version ​
: Git 
A  chaque  séance,  une  branche  d’intégration  est  crée  pour  mettre  en  commun  le code de tous 
les groupes. A la fin de l’intégration, les besoins sont remontés aux différents groupes. 
Outils de communications: 
Slack utilisé pour échanger des informations relatifs au développement. 
Google Drive pour entreposer des documents 
mails, téléphones 
  
 
 

20