Forti Meisen - TPI - Rapport

Winston Forti Meisen Poker Waiting List 15 avril 2021
Travail pratique individuel
Casino arrière de Montreux
Poker Waiting list

Winston Forti Meisen
Page 1 sur 68
Table des matières

1 Résumé du rapport TPI .................................................................................................................... 5
2 Analyse préliminaire ........................................................................................................................ 6
Introduction ............................................................................................................................. 6
Objectif ..................................................................................................................................... 6
Planification initiale.................................................................................................................. 7
Planification finale.................................................................................................................... 7
2.4.1 Analyse de la planification réelle ..................................................................................... 7
Journal de travail ...................................................................................................................... 7
3 Analyse / Conception ....................................................................................................................... 8
Environnement et Waiting list actuelle.................................................................................... 8
Concept .................................................................................................................................. 11
Stratégie de test ..................................................................................................................... 11
Risques techniques ................................................................................................................ 11
Gestion des fichiers importants ............................................................................................. 12
Méthode de gestion de projet ............................................................................................... 13
Langages ................................................................................................................................. 13
Outils utilisés .......................................................................................................................... 14
Framework ............................................................................................................................. 14
Base de données .................................................................................................................... 15
3.10.1 Difficultés rencontrées lors de l’élaboration de la base de données ............................ 15
3.10.2 Modèle Conceptuel de données .................................................................................... 15
3.10.3 Modèle Logique de données .......................................................................................... 16
3.10.4 Modèle Physique de données ........................................................................................ 16
3.10.5 Création de la Base de données ..................................................................................... 16
3.10.6 Dictionnaire de données ................................................................................................ 17
4 Réalisation ...................................................................................................................................... 18
Mise en place du projet ......................................................................................................... 18
Frontend................................................................................................................................. 19
4.2.1 Le « routing » ................................................................................................................. 19
4.2.2 Structure de la vue ......................................................................................................... 20
Backend .................................................................................................................................. 20
Fonctionnement général entre frontend et backend ............................................................ 21
Page 2 sur 68
Création d’une API REST ........................................................................................................ 22

Système de Token .................................................................................................................. 24
Authentification ..................................................................................................................... 25
4.7.1 LDAP et l’authentification avec Active Directory ........................................................... 26
Page d’accueil......................................................................................................................... 29
4.8.1 Page d’accueil non authentifiée ..................................................................................... 30
4.8.2 Page d’accueil authentifiée ............................................................................................ 31
Gestion des tables .................................................................................................................. 35
Affichage ................................................................................................................................ 37
4.10.1 Code actuel .................................................................................................................... 37
4.10.2 Nouveau code ................................................................................................................ 38
4.10.3 Remplacement de l’ancien système .............................................................................. 39
4.10.4 Erreur lors de la mise en production de l’affichage ....................................................... 39
Mise en production ................................................................................................................ 40
Erreur lors de la mise en production ..................................................................................... 41
Difficultés rencontrées pour la réalisation............................................................................. 41
5 Documents livrés............................................................................................................................ 41
6 Tests ............................................................................................................................................... 42
Barre de navigation et pied de page ...................................................................................... 42
Page d’accueil non authentifiée............................................................................................. 42
Authentification ..................................................................................................................... 42
Page d’accueil authentifiée .................................................................................................... 42
Gestion des tables .................................................................................................................. 43
Affichage ................................................................................................................................ 43
Erreurs et corrections ............................................................................................................ 43
Validation des tests ................................................................................................................ 43
7 Conclusion et Bilan personnel ........................................................................................................ 44
8 Glossaire ......................................................................................................................................... 45
9 Ressources ..................................................................................................................................... 47
Personnes ............................................................................................................................... 47
Documentations officielles .................................................................................................... 47
Site web .................................................................................................................................. 47
10 Annexes ...................................................................................................................................... 48
Planification initiale................................................................................................................ 48
Page 3 sur 68
Planification Final ................................................................................................................... 51

Journal de travail .................................................................................................................... 55
Guide utilisateur..................................................................................................................... 61
10.4.1 Premier contact avec l’application................................................................................. 61
10.4.2 Connexion ...................................................................................................................... 61
10.4.3 Gestion de la file d’attente............................................................................................. 62
10.4.4 Gestion des tables .......................................................................................................... 63
10.4.5 Support ........................................................................................................................... 64
Mise en place de l’environnement de développement ......................................................... 65
Fonctionnement de l’application ........................................................................................... 67
Lieux de travail ....................................................................................................................... 68
Page 4 sur 68
1 Résumé du rapport TPI

Situation de départ
Le casino disposait, avant ce projet, d’une application de gestion de la file d’attente à la salle de poker
datant d’il y a plus de 7 ans. Cette application créée en PHP n’avait pas de documentation et ne
respectait pas les contraintes de sécurité imposées dans les jours actuels. De plus, les utilisateurs
relataient souvent des problèmes lors de son utilisation.
En analysant le cahier des charges et en créant une première conception de l’application, j’ai donc
décidé d’en créer une nouvelle depuis zéro, en utilisant le Framework Angular, un backend PHP et une
base de données MySQL.
Mise en œuvre
La création de cette application se base sur 10 étapes principales et plusieurs intermédiaires.
1. Mise en place d’un projet Angular. 6. Page d’accueil pour les utilisateurs
2. Modélisation et création de la base de authentifiés
données MySQL. 7. Gestion des tables de poker
3. Création d’une API REST pour le 8. Adaptation de l’affichage des files
backend. d’attente.
4. Authentification et système de token. 9. Mise en production de l’application
5. Page d’accueil pour les utilisateurs non 10. Tests et validation.
authentifiés
Plusieurs diagrammes et images expliquent ces étapes en détail.
Résultats
Les résultats de ce projet sont :
 Une application moderne, facile à utiliser et sécurisée, permettant la gestion de la file d’attente
aux tables de poker.
 Un affichage aux clients avec un design inchangé, affiché à l’écran à l’entrée de la salle de
poker.
 Une documentation claire et à jour, comprenant, un rapport, un guide d’installation et un
guide utilisateur.
 Un code source correctement conçu et commenté.
Les résultats obtenus sont, à mon avis, très satisfaisants. Toutes les fonctionnalités demandées dans
le cahier des charges sont fonctionnelles et mises en production.
Page 5 sur 68
2 Analyse préliminaire
Introduction
Ce document est destiné aux personnes ayant une connaissance approfondie en informatique. Les
termes techniques et d’autres mots employés dans le texte sont mis dans un glossaire et expliqués
brièvement.
Après la réception du cahier des charges et des consignes d’évaluation de la part de l’expert M. Alain
Roy, une journée de réflexion et de planification a eu lieu. Ces analyses et la planification sont
disponibles dans les chapitres qui suivent.
Objectif
L’objectif de ce projet est de développer une application WEB qui respecte l’ensemble des objectifs
décrits dans le cahier des charges reçu au démarrage de mon Travail Pratique Individuel.
● Analyser les exigences d’une application Web et de la base de données, respectivement des
éléments de données à lier, définir et documenter les techniques utilisées.
● Identifier les informations importantes de protection et de sécurité en tenant compte de la
protection des données, définir et documenter les mesures, en respectant les exigences
décrites dans le cahier des charges.
● Réaliser l’intégration de l’application Web avec la base de données et l’annuaire Microsoft
Active Directory, respectivement aux éléments de données, en prêtant attention aux
transactions, à la protection et la sécurité des données. Documenter les démarches, ainsi que
toute information importante en relation avec la réalisation du projet.
● Mettre en œuvre les souhaits de modifications, justifier et documenter ces changements.
● Définir et exécuter la procédure de test et de remise, la documenter dans un chapitre dédié
du rapport. Si nécessaire, entreprendre les corrections et les documenter
Page 6 sur 68
Planification initiale
La planification initiale a été décidée lors de l’analyse des fonctionnalités à développer. La planification
est vouée à être modifiée tout au long du projet.
Ce document a été créé à l’aide de Google Sheets et fonctionne comme un diagramme de Gantt.
L’axe temporel est défini par blocs de deux heures et les jours travaillés divisés en demi-journées et
affichées au long de deux pages.
Dans un premier temps les jours n’ont pas été explicités dans ce document ce qui a été corrigé après
conseil de l’expert M. Mveng. Voici la comparaison de la correction :
Avant : Après :
Une autre correction est l’heure de début et fin de la première journée. J’ai décidé de laisser l’heure
où je suis arrivé au bureau et celle de mon départ, elles sont compatibles avec l’horaire demandé dans
le cahier des charges.
Les 5 principales étapes du projet sont affichées dans une colonne "Étape" et ses tâches respectives
dans la colonne “Tâches”.
Une troisième page affiche la planification des charges. Cette page permet de comparer le temps prévu
pour chaque tâche et le temps de travail réellement effectué.
Merci de vous référer à l’annexe 10.1 Planification initiale pour voir le document dans son intégralité.
Planification finale
La planification définie au premier a très peu changé au cours du projet, cependant des changements
ont eu lieu et une planification réelle a été créée.
Merci de vous référer à l’annexe 10.2 Planification Réelle pour voir le document dans son intégralité
2.4.1 Analyse de la planification réelle

La mise en place de l'environnement de développement et création du projet Angular a été plus rapide
que je pensais. Elle m’a pris une heure au lieu de deux. Cette heure supplémentaire a été utilisée dans
la partie mise en place de l’API et a été utile pour créer une structure de backend propre.
La tâche API REST – Mise en place a été divisé en deux sous-tâches : API REST – Mise en place et API
REST – Création des classes et des fonctions.
La partie Authentification a été terminée avec deux heures d’avance, pareil pour la gestion des droits
utilisateurs (groupes AD).
La création de la page d’accueil et la gestion des tables ont pris chacune deux heures au lieu de quatre.
La mise en production n’a pas été un problème et a été faite en deux heures au lieu de six de prévu.
Ayant bien avancé la partie « Réalisation », j’ai économisé quatre heures, dont je pourrais m’en servir
pour la partie documentation.
Les tests ont fini plutôt, six heures au lieu de huit et la documentation a pris cinq heures de plus.
Journal de travail
Merci de vous référer à l’annexe 10.3 Journal de travail
Page 7 sur 68
3 Analyse / Conception
Environnement et Waiting list actuelle
L’application actuelle est déployée en mode intranet. Elle n’est pas complète en question de
fonctionnalités. Les utilisateurs doivent pouvoir gérer les tables de jeu eux-mêmes. La base de données
actuelle ne permet pas cette modification, car elle est conçue d’une forme que pour chaque table de
poker une table MySQL doit être créée. Le modèle ci-dessous démontre cette structure.
Le code PHP, à mon avis, n’est pas optimal et ne respecte pas les bonnes pratiques de développement,
comme par exemple, une documentation, un code commenté et une structure claire. En plus, pour
chaque nouvelle table ajoutée plusieurs fichier PHP doivent être créés (delete, deleteAll, insert,
update, pkr), laissant l’application extrêmement statique et dépendante du service informatique.
En plus, la Poker Waiting List actuelle n’est pas sécurisée par un système d’authentification utilisateur,
ce qui doit être corrigé afin de respecter la protection des données.
Le design de l’application est dépassé et prie pour être actualisé. Elle laisse à désirer en question
d’ergonomie et clarté.
Page 8 sur 68
Poker Waiting List, créée en 2014 et utilisée aujourd’hui:
Page 9 sur 68
Affichage à la clientèle
Pour des questions de marketing et afin de respecter les standards définis par le groupe Barrière,
l’affichage des clients en attente ne doit pas être modifié. Je dois utiliser le même format et image
utilisés actuellement.
Je peux adapter le code de création d’affichage, en modifiant la façon dont il récupère les données.
Ou, si ma planification avance correctement, je peux voir pour créer un système d’affichage toujours
en respectant les standards définis par le groupe.
Actuellement, les images sont générées par trois scripts PHP.
 Le fichier Poker_ListPlayers.php récupère les données de la table 1 et de la table 2 et crée

l’image pour l’affichage ;
 Le fichier Poker_ListPlayers3et4.php fait la même chose pour les listes des tables 3 et 4 ;
 Le fichier Poker_ListPlayers5.php pour la liste d’attente de la table 5.
Comme pour les fichiers de l’application, ces scripts ne sont pas dynamiques, si une nouvelle table est
créée, le fichier pour la table 5 doit être modifié et ainsi de suite. Ce système ne respecte en aucun cas
le principe de développement DRY ( don’t repeat yourself).
Ces scripts sont exécutés toutes les minutes par un Cron job configuré sur le serveur Linux WEB01.
Affichage de la file d’attente des tables 1 et 2
Les images sont affichées à l’écran grâce au logiciel d'affichage dynamique Screenly installé sur un
Raspberry PI, il va tourner une page PHP qui parcourt et affiche les images dans un répertoire donné.
J’ai décidé de garder cette méthode d’affichage par Screenly, c’est donc uniquement la création des
images qui sera adaptée au projet.
Page 10 sur 68
Concept
Le concept est décrit dans le cahier des charges qui a été rédigé par le chef de projet, M. Ballestraz.
Les fonctionnalités sont les suivantes :
● Authentification via l’annuaire Active Directory.

● Gestion des droits utilisateurs via des groupes AD.
● La page d’accueil permet aux utilisateurs de choisir les tables affichées.
● Page d’accueil sans authentification affiche uniquement les tables, leurs attributs, leurs statuts
et les noms d’affichage pour les clients en attente.
● Page d’accueil avec authentification affiche les tables et les clients en attente, ainsi que permet
aux utilisateurs de:
○ Modifier la file d’attente (Position, ajout, modification et suppression d’un client).
○ Modifier les données des clients (Nom, Prénom, Téléphone et Nom d’affichage).
● Gestion des tables (Modification, suppression et ajout de table).
● Affichage des listes d’attente aux clients du casino.
Vue globale de l’application : Annexe 10.6 Fonctionnement de l’application
Stratégie de test
Afin de garantir le bon fonctionnement de l’application et permettre la suite du développement, des

tests unitaires seront effectués tout au long du développement.
A la fin du projet, l’application sera testée avant sa mise en production.
Risques techniques
Les bases du développement WEB ont été acquises au cours des différents modules ICT. Ceux-ci m'ont
permis de découvrir le frontend et la conception des bases de données.
Les risques pouvant survenir et pouvant me mettre en retard dans le projet sont :
● Les interactions avec le backend ; le choix d’Angular impose d’utiliser le backend comme API
REST( Representational State Transfer Application Program Interface) . Cela ajoute un niveau
de complexité car toutes les données qui transitent seront alors au format JSON (JavaScript
Object Notation), il faut donc savoir traiter, envoyer et sécuriser ces données. Afin de réduire
le risque de retard, les documentations officielles sont disponibles pour consultation.
● Perte des données importantes dû à une panne : Afin d’éviter les pertes de données, des
sauvegardes périodiques sont faites dans des différents supports de stockage.
● Protocole LDAP. C’est la première fois que je vais intégrer une authentification Active Directory
dans une application web. Le risque de retard est faible, mais il existe.
Page 11 sur 68
Gestion des fichiers importants

La documentation du projet et le code source sont sauvegardés au moins une fois par jour travaillé.
Voici les différents endroits où elle est stockée :
2 One drive
1 Google Drive
3 Ordinateur Local 4 Le code est sauvegardé dans un répertoire GitHub
Page 12 sur 68
Méthode de gestion de projet
Afin de gérer le projet au mieux, j’utilise la méthode “Waterfall” comme méthode de gestion des
charges.
L’ensemble des fonctionnalités de l’application étaient clairement décrites dans le cahier des charges,
ce qui m’a permis de définir l'enchaînement du développement assez facilement. Il est donc plus facile
de mesurer la progression du projet avec cette méthode puisque tout le déroulé du projet est défini
en amont.
Il n’y a pas forcément besoin de flexibilité pour la gestion générale du projet c’est donc cette méthode
que j’ai choisi de suivre.
Langages
Les différents langages utilisés pour ce projet n’ont pas été imposés dans le cahier des charges.
HTML
Le langage HTML (HyperText Markup Langage) est utilisé uniquement pour la partie “vue” de
l’application, c'est-à-dire, la partie affichage à l’écran du côté utilisateur. La “vue” est un élément du
frontend. En l’utilisant dans le Framework Angular, j’ai des différentes possibilités pour l’affichage. Les
fonctionnalités HTML spécifiques à Angular vont être décrites au long de cette documentation.
CSS
Le langage CSS (Cascading Style Sheets) est, pareillement à HTML, utilisé uniquement pour la partie
“vue” de l’application. Ce langage va servir à donner le style des pages web. Dans Angular il existe
plusieurs façons d’utiliser le style CSS, soit directement dans le fichier HTML, dans un fichier dédié à
chaque page ou dans un fichier global de l’application.
TypeScript
J’utilise ce langage pour la partie contrôleur du frontend. Le contrôleur est, comme la vue, exécuté
côté utilisateur et sert à fournir à la vue les données voulues, contrôler les accès, ainsi que d’autres
interactions avec l’application.
TypeScript est développé par Microsoft et sert à améliorer et sécuriser la production de code
JavaScript.
PHP
J’utilise le langage PHP (PHP: Hypertext Preprocessor) pour la partie « backend » du projet. Il a comme
utilité de réceptionner les requêtes faites par le frontend et de les traiter en fonction de l’action voulue.
J’ai décidé de programmer la partie PHP en orienté objet comme le reste du projet. Cela permettra
une meilleure cohérence dans l’organisation du projet et une maintenance facilitée.
L’extension PHP pour LDAP est utilisée pour la partie authentification Active Directory.
SQL
Le langage SQL(Structured Query Language) est utilisé spécifiquement pour la manipulation de la base
de données.
Page 13 sur 68
Outils utilisés
Les différents outils que j'utilise sont :
Visual Studio code

Visual Studio Code est un éditeur de texte développé par Microsoft. C’est sur cet éditeur qu’est
développé le frontend et backend. Je l’ai déjà utilisé plusieurs fois et il a toujours bien fonctionné.
D’autres applications comme Atom, Sublime Text ou même Notepad++ pourraient être utilisées dans
ce projet, cependant, je trouve Visual Studio Code plus complet.
NodeJS
NodeJS est un environnement d’exécution JavaScript construit sur le moteur JavaScript V8 de Chrome.
Il est ainsi le point central qui va permettre d'exécuter des programmes écrits en javascript côté
serveur.
XAMPP
XAMPP est une distribution d’Apache qui contient MySQL et PHP, entre autres outils. Ce logiciel fournit
un environnement de développement local idéal. Dans ce projet j’utilise spécialement MySQL,
Apache+PHP et PhpMyAdmin.
J’aurais pu utiliser d’autres environnement de développement web, comme WAMP, MAMP ou LAMP,
cependant, j’ai choisi d’utiliser XAMPP car je l’ai utilisé plusieurs fois au cours de mon apprentissage
et, vu que je ne vais pas utiliser cet outil en production, il me suffit largement.
G Suite
G Suite est une suite d’outils basée sur le cloud développée par Google et destinée aux professionnels.
J’utilise principalement Docs et Sheets afin de créer les différents documents souhaités comme le
rapport ou le Gantt. L’application Diagrams a aussi été utile pour la conception des modèles de
données. La suite Google m’a aussi permis, grâce à Drive, de créer un espace de stockage cloud. Cela
me permet d’accéder facilement aux documents du projet à tout moment. J’ai choisi d’utiliser G Suite
car c’est l’outil qu’utilise le Groupe Barrière.
D’autres applications pourraient être utilisées pour créer la documentation, comme : Microsoft
Github
L’application Github est utilisée principalement en tant que sauvegarde du code. Elle permet aussi une
mise en place simplifiée du projet sur d’autres appareils, permettant ainsi un travail dynamique en
question de codage. GitHub permet une utilisation gratuite et est adapté à ce projet.
Framework
Bootstrap
Bootstrap est un Framework qui simplifie la création du design de site ou d’application web. Il a été
développé par « Twitter » et mis à disposition gratuitement. Il contient du code HTML, CSS et Javascript
Bootstrap possède une documentation complète et facilement compréhensible. Il a été choisi afin de
faciliter la création de la partie graphique de l’application.
Page 14 sur 68
Angular
L’application actuelle, comme le cahier des charges décrit, est basée sur un Framework PHP Yii (Yes,It
is), même si Yii est un Framework PHP puissant, j’ai préféré utiliser un système de développement dont
je me sens à l’aise. J’utilise donc la dernière version stable d’Angular, la version 11, sortie en novembre
2020.
Angular est un Framework open source développé par Google et par la communauté Angular. Il est
basé sur le langage TypeScript qui a été développé par Microsoft et qui sert à améliorer et sécuriser la
production de code JavaScript. Nous pouvons donc dire qu’Angular est un Framework Javascript.
Ayant déjà travaillé avec, j’ai choisi donc d’utiliser Angular afin de créer la partie frontend du projet.
Angular agit du côté client, c’est donc le navigateur qui interprétera l’ensemble du code. Il dispose
d’une documentation complète et des nouvelles versions et correctifs sont mis en place constamment.
Base de données
La base de données a été réalisée avec MySQL.
Étant une application ayant un but très spécifique et simple, la base de données suit cette même
structure.
Actuellement elle comporte 3 tables, mais peut évoluer après la fin du projet.
3.10.1 Difficultés rencontrées lors de l’élaboration de la base de données

Afin de garder la connexion de l’utilisateur, il est préférable d’utiliser un système de token. Ce système
a été défini au milieu du projet et une table UsersToken a été rajoutée aux modèles de données.
3.10.2 Modèle Conceptuel de données
Voici le modèle conceptuel de données.
Le MCD permet de plus facilement voir les liens entre chaque table et d’afficher les notions d'entité et
d'association.
La base de données actuelle est à mon avis mal conçue, car pour chaque table de poker on doit créer
une nouvelle table avec les mêmes attributs dans MySQL. Dans mon analyse il est plus pertinent de
créer une table pour les tables de poker et une pour les joueurs.
Page 15 sur 68
3.10.3 Modèle Logique de données
Voici le modèle logique de données.
Le MLD permet d’avoir une vision plus détaillée de la base de données et des relations directes entre
chaque table.
3.10.4 Modèle Physique de données
Voici le modèle physique de données.
Le MPD permet de définir la mise en œuvre de structures physiques et de requêtes portant sur les
données.
3.10.5 Création de la Base de données

La base de données a été créée en local avec l’outil PhpMyAdmin.
Différemment de l’analyse initiale, la base de données comporte 3 tables.
Une table T_UsersToken a dû être rajoutée afin de garder la connexion des utilisateurs connectés. Le
système de token est décrit dans le chapitre 4.6.
Page 16 sur 68
3.10.6 Dictionnaire de données
3.10.6.1 Table « T_Tables »

La table «T_Tables » sert à stocker les tables de poker
Nom Type Description
ID_Table INT (11) Clé primaire
TableNumber Tinyint (3) Numéro de la table de jeu
BuyIn Decimal (10,2) Valeur du BuyIn
BigBlind Tinyint (3) Valeur du BigBlind
SmallBlind Tinyint (3) Valeur du SmallBlind
TableStatus Boolean Statut de la table, ouverte ou fermé
3.10.6.2 Table « T_Players »

La table «T_Players » sert à stocker les clients qui attendent une place pour le poker.
ID_Player INT (11) Clé primaire
Name VARCHAR (100) Prénom de la personne
Lastname VARCHAR (100) Nom de la personne
Phone VARCHAR (20) Téléphone de la personne
ViewName VARCHAR (100) Nom d’affichage
Position Tinyint (3) Position dans la file d’attente
FK_Table INT (11) Foreign key
3.10.6.3 Table « T_UsersToken »

La table «T_UsersToken » sert à stocker les tokens des utilisateurs connectés à l’application.
ID_UserToken INT (11) Clé primaire
Username VARCHAR (100) Nom d’utilisateur
Token VARCHAR (100) Chaîne de caractères aléatoire de contrôle
TokenValidity DateTime Date et heure de la mise à jour du token
Page 17 sur 68
4 Réalisation
Mise en place du projet
La mise en place de l’environnement de développement et la gestion du projet se fait par l’installation

et configuration des outils décrits dans le sous-chapitre 3.7. La procédure d’installation de cet
environnement est disponible en annexe. Voici dessous quelques commentaires concernant
l’installation de chaque application :
● Visual Studio Code : Le téléchargement de VS Code est gratuit et le logiciel simple à installer,
configurer et utiliser. Il est important d’installer les extensions appropriées pour chaque
Framework ou langage utilisé. Voici les extensions installées :
o Angular essentials (Version 11) o PHP Intelephense
● XAMPP : L’installation faite est celle par défaut. Une fois l’application installée il faut démarrer
les modules utilisés, dans ce cas, Apache et MySQL.
o LDAP PHP : Dans le fichier php.ini supprimer le « ; » de la ligne où on trouve
l’extension LDAP pour l’activer. Redémarrer Apache.
● G Suite : Création d’un dossier « TPI » sur Drive. Les fichiers y sont créés et téléchargés pour
servir de sauvegarde.
● GitHub : Installation par défaut. Le répertoire du projet appelé Poker-Wainting-List-V2
contenant le frontend et le backend sont synchronisés sur l’application.
● NodeJS : Voici la liste des commandes utilisées pour ce projet :
Commande Action Utilisation
Pouvoir utiliser les
npm install -g @angular/cli Installation d’Angular CLI commandes Angular et
utiliser ce framework
npm install --save-dev Installation du devkit Angular Utile pour la mise en
@angular-devkit/build-angular build production et pour la
compilation du code.
npm install Installation du module Créer des vues
@fortawesome/fontawesome- FontAwesome personnalisées avec des
svg-core icônes FontAwesome
npm install @angular/cdk Installation du module Angular Utiliser la fonctionnalité
Material Drag and Drop de Glisser et déposer
 Angular : Quelques commandes mises à disposition par Angular (commandes ng)

permettent d’utiliser ce Framework de manière intuitive :
o ng g c <Nomducomposant> : Génère un composant Angular dans le dossier actuel,
utilisez CD pour changer de dossier.
o ng g service <Servicename> : Génère un service Angular.
o ng update : Met à jour les packages Angular.
o ng serve -o : Compile et lance l’application.
o ng build --prod : Compile le projet pour la mise en production.
Page 18 sur 68
Frontend
Voici une liste descriptive des principaux dossiers et fichiers

utilisés pour le frontend Angular.
- e2e : ce dossier contient des scripts pour effectuer des
tests.
- node_modules : c’est dans ce dossier que sont installés
tous les plugins Node
- src : dossier contenant l’ensemble des pages du projet
ainsi que toutes ces fonctionnalités
- app/components : là où tous les components du site sont
stockés.
- app/helpers : Dossier utilisé pour stocker les classes
pouvant être utilisées dans des différents endroits.
- app/models : y sont stockés l’ensemble des « models », ils
servent à créer des objets des données que l’application
reçoit de l’API.
- app/services : tous les classes « services » sont présentent
dans ce dossier. Elles vont servir à effectuer les requêtes
vers l’API ou bien à effectuer des tâches récurrentes.
- app/app.component… : sont les fichiers de bases dans
lesquelles les composants seront importés lors de la
navigation.
- src/assets : y sont stockés l’ensemble des icônes et des
images statiques de l’application, ainsi que les fichiers
JavaScript de librairie de style.
- src/environments : y figurent les variables, comme les
chemins d’accès de l’API ou des images. Ces chemins sont
différents en mode développement ou en production.
4.2.1 Le « routing »
Cette partie est propre au Framework Angular.
C’est le routage qui va permettre à l’application de gérer la

navigation au sein du site. Toutes les routes sont présentes dans
le fichier « app/app-routing.module.ts ».
Une route est la relation entre un chemin et un composant.
Page 19 sur 68
4.2.2 Structure de la vue

Toutes les pages de l’application disposent d’un “header” et d’un “footer”. Entre deux, un container
affiche les pages selon le choix de l’utilisateur (Routage).
 L’élément HTML « header » va afficher la barre de navigation de l’application avec ses
menus.
 L’élément « Article » affiche les pages d’accueil, la page de connexion et la page de gestion
de tables.
 Le « footer » affiche un pied de page avec quelques informations aux utilisateurs.
Voici le code de cette structure :
Backend
Le backend composé, dans sa majorité, par des fichiers PHP crée

une API. L’approche Orientée Objet fait de ces fichiers des
classes.
- _Helpers : Ce dossier contient des classes utiles pouvant être
utilisées plusieurs fois tout au long du projet.
- Entities : contient toutes les classes permettant de traiter ou
récupérer des données sur la bdd.
- .htaccess : dans ce cas, il va servir à gérer les paramètres des en-
têtes HTTP.
- Start.php : page d’accès par défaut de l’API. C’est par là que
toutes les requêtes passent et sont traitées.
Page 20 sur 68
Fonctionnement général entre frontend et backend
Frontend
Backend
Les services Angular contactent l’API via des requêtes HTTP. L’API traite les requêtes et distribue les
données vers ses classes qui, avec ses fonctions, communiquent avec la base de données et l’AD,
ensuite elles retournent les données demandées par le frontend au format JSON en tant qu’un objet
préalablement définis dans les Models Angular. Dans l’échec, elle retourne les erreurs dûment
identifiées. Les données sont transmises aux contrôleurs TS et, si aucune erreur n’est retournée, ce
dernier les met à disposition de la vue. Si le frontend reçoit une erreur, il va afficher des messages
préalablement définis dans les fichiers TS.
Page 21 sur 68
Création d’une API REST
Le choix d’utiliser Angular comme technologie de frontend implique de créer un système qui puisse
retourner des données sous un certain format. Le format de retour est le JSON. Je dois donc créer une
interface pour interpréter ces données et les envoyer dans le bon format. Cette API est développée en
PHP version 7.4.16.
Les principes d’une API REST ont été appris lors des modules ICT, cependant c’est la première fois que
je crée moi-même cette architecture. Après quelques recherches et lectures (sources disponibles dans
le chapitre ressources) voici les principaux standards concernant l’architecture de programmation API
REST :
● Une architecture client-serveur constituée de clients, de serveurs et de ressources, avec des

requêtes gérées via HTTP
● Des communications client-serveur sans état, c'est-à-dire que les informations du client ne
sont jamais stockées entre les requêtes, qui doivent être traitées séparément, de manière
totalement indépendante
● La possibilité de mettre en cache des données afin de rationaliser les interactions client-
serveur
● Une interface uniforme entre les composants qui permet un transfert standardisé des
informations Cela implique que :
o Les ressources demandées soient identifiables et séparées des représentations
envoyées au client ;
o Les ressources puissent être manipulées par le client au moyen de la représentation
reçue, qui contient suffisamment d'informations ;
o Les messages auto descriptifs renvoyés au client contiennent assez de détails pour
décrire la manière dont celui-ci doit traiter les informations ;
o L’API possède un hypermédia, qui permet au client d'utiliser des hyperliens pour
connaître toutes les autres actions disponibles après avoir accédé à une ressource.
● Un système à couches, invisible pour le client, qui permet de hiérarchiser les différents types
de serveurs (pour la sécurité, l'équilibrage de charge, etc.) impliqués dans la récupération des
informations demandées
● Du code à la demande (facultatif), c'est-à-dire la possibilité d'envoyer du code exécutable
depuis le serveur vers le client (lorsqu'il le demande) afin d'étendre les fonctionnalités d'un
client
Une API REST permet de manipuler de la donnée via une interface applicative
Page 22 sur 68
La structure de l’API créée pour ce projet est la suivante :
● Start.php : Comme déjà mentionné, Start.php sert à trier les requêtes faites par le frontend. Il
sert aussi à, selon les requêtes, renvoyer les bonnes erreurs en cas d’échec.
Lorsqu’une requête http arrive, elle va être validée et va ensuite appeler la classe
correspondante.
● Entity.php : La classe Entity.php a plusieurs rôles. Le premier est de fournir des attributs
globaux aux classes enfants. Elle fait aussi la connexion à la base de données MySQL. Pour finir,
elle vérifie la validité des tokens.
● Table.php : Classe contenant les fonctions de sélection, ajout, suppression, entre autres. C’est
cette classe qui va retourner les données des tables de poker, demandées par le frontend.
● Player.php : Classe contenant les fonctions de sélection, ajout, suppression, entre autres. C’est
cette classe qui va retourner les données des clients en attente, demandées par le frontend.
● User.php : Classe dédiée à l’authentification des utilisateurs. Elle fait des requêtes SQL ainsi
que des requêtes LDAP vers l’AD.
Page 23 sur 68
Système de Token
Afin de garder la connexion de l’utilisateur entre les rafraîchissements j’ai décidé de créer un système
de token. Le token généré est une chaîne de caractères aléatoires crypté en MD5 (Message Digest 5).
Le token est unique par utilisateur et a une validité d’une minute et si l’utilisateur reste connecté plus
que ça, le token est crédité de 60 minutes, après ça il doit être mis à jour. Après la connexion, le token
créé est stocké aussi en « LocalStorage » et doit être identique à celui en base de données.
Page 24 sur 68
Authentification
La connexion d’un utilisateur est faite par moyen d’une page de connexion dédiée. Cette page est
accessible uniquement si l’utilisateur n’est pas connecté. Cette vérification est demandée au backend
par le service Angular, AuthenticationService. L’affichage des boutons de connexion ou déconnexion
est gérée par Angular ngIf, qui affiche le bon bouton pour les utilisateurs connectés ou non connectés.
La page de connexion contient un formulaire avec deux champs : Nom d’utilisateur et mot de passe,
ainsi qu’un bouton de connexion.
Une validation du formulaire est faite une fois le bouton « Connexion » cliqué. Si les champs sont vides
ou si les identifiants sont incorrects, l’utilisateur reçoit un avertissement.
Une fois le formulaire validé et envoyé, le service AuthenticationService est appelé, il envoie les
identifiants vers le backend qui va, à l’aide du protocole LDAP, vérifier que l’utilisateur et mot de passe
sont corrects. Le backend retourne les données de l’utilisateur en format JSON au frontend. Pour finir
l’utilisateur est redirigé vers la page voulu ou vers la page d’accueil.
Page 25 sur 68
4.7.1 LDAP et l’authentification avec Active Directory
4.7.1.1 Introduction au protocole LDAP

LDAP signifie : Lightweight Directory Access Protocol (Protocole léger d'accès aux annuaires). C’est un
protocole utilisé pour se connecter à des annuaires. Dans ce projet l’annuaire Active Directory est
interrogé par ce protocole et retourne des données en forme de tableaux.
Les annuaires utilisent un système d’arborescence pour stocker les données. Pour utiliser LDAP nous
devons donc savoir comment interroger le serveur et trouver les données voulues.
Pour identifier un fichier dans votre disque, vous utilisez un chemin tel que
Sur des systèmes de fichiers habituels nous utilisons les chemins comme :
/usr/local/User/documents ou C:/Windows/…
Le slash indique une division dans la référence, et la séquence est lue de gauche à droite.
Page 26 sur 68
L’équivalent d’un chemin complet en LDAP est appelé un " distinguished name " (Nom distingué), aussi
appelé "dn". Un exemple de dn serait :
cn=Winston Meisen,ou=Informatique,o=Casino,c=CH
La virgule marque la séparation de chaque division comme référence, et la séquence est lue de droite
à gauche.
PHP met à disposition plusieurs méthodes pour interroger un annuaire, voici les principales :
● Ldap_connect : Connexion à un annuaire
● Ldap_bind : Authentification à un annuaire
● Ldap_search : Recherche sur un annuaire
● Ldap_get_entries : Lit toutes les entrées d’un résultat
● Ldap_read : Lit une entrée
● Ldap_Unbind : Déconnecte du serveur d’annuaire.
Documentation PHP disponible depuis le lien dans le chapitre Ressources.
4.7.1.2 Mise en place du processus d’authentification avec LDAP

Mon idée de base était de, lors d’une connexion, envoyer le mot de passe encrypté avec CryptoJS au
backend qui serait capable de comparer le mot de passe envoyé avec celui dans l’annuaire. La
problématique trouvée est que l’AD doit recevoir des mots de passe en plein texte pour faire
l’authentification.
En lisant la documentation PHP LDAP je n’ai trouvé aucune méthode pour comparer un mot de passe
encrypté avec celui de l’annuaire. Pour avoir une sécurité appropriée j’ai mis en place un certificat SSL
auto-signé.
Pour la création du certificat J’ai utilisé le code suivant (server est remplacé par le nom du serveur):
L’authentification et la gestion des droits sont faites lors de l’appel à la fonction Login disponible dans
la classe User. Cette fonction fait la connexion à l’AD et teste si les identifiants sont correctes. Si tout
est ok, un token est créé ou mis à jour dans la base de données. Ensuite, elle retourne le nom
d’utilisateur et le token en format JSON au frontend.
Page 27 sur 68
4.7.1.3 Vérification des droits utilisateurs

Avant de donner accès à l’application, l’utilisateur est contrôlé et doit faire partie d’un groupe de
sécurité préalablement définis. Ce contrôle est fait à l’aide du protocole LDAP qui envoie le DN
(« distinguished name ») au serveur d’annuaire et reçoit une réponse avec tous les groupes desquels
l’utilisateur est membre. A l’aide d’une boucle, les réponses sont parcourues et chacune est comparée
au nom de groupe défini. Cette boucle est de type récursif afin de chercher dans les groupes qui sont
membres d’un groupe duquel l’utilisateur est membre.
Voici le groupe qui a été créé dans l’annuaire AD.
Page 28 sur 68
Page d’accueil
La page d’accueil est générée par le composant Angular HomepageComponent. Ce composant fait
appel à TableCardComponent pour chaque table de poker. Pour le faire, Angular dispose de ngFor, qui
va lire chaque item d’un tableau à la fois et le stocker dans un objet.
Ici, HomepageComponent récupère toutes les tables de poker en base de données dans un tableau.
Avec ngFor, je crée un TableCardComponent pour chaque table. J’utilise le paramètre « @Input » afin
de partager les données de sa table avec le composant enfant.
Chaque composant TableCard est divisé en deux parties. Une première pour les utilisateurs non
authentifiés et autre pour ceux avec un token de connexion valide. Angular ngIf va vérifier à l’aide
d’AuthenticationService s’il existe un utilisateur actuel. Si c’est le cas, ngIf va afficher la vue
correspondante.
La page d’accueil permet à l’utilisateur de cacher ou afficher les tables.
Ces boutons sont générés automatiquement, tant qu’il existe des tables dans la base de données. Ce
système est créé par Bootstrap Collapse. Pour chaque bouton créé et pour chaque table affichée, un
identifiant unique est créé. En utilisant l’attribut « attr.aria-controls » plus son numéro de table, il va
contrôler la table de même numéro.
Page 29 sur 68
4.8.1 Page d’accueil non authentifiée

La page d’accueil non authentifiée ne permet aucune action de l’utilisateur sur les tables. Elle affiche
toutes les tables, ses statuts et ses attributs, ainsi que les noms d’affichage des clients en attente.
Le cahier des charges dit qu’un utilisateur ne peut pas voir le menu Gestion des tables, cependant,
pour donner à l’utilisateur une meilleure visibilité sur les possibilités de l’application j’ai décidé
d’afficher le lien vers cette page dans le header. Ce lien est protégé par AuthGuard.
J’ai créé AuthGuard pour sécuriser cette route. Cette classe est appelée par AppRoutingModule pour
une ou plusieurs routes. AppRoutingModule utilise la propriété CanActivate de la route pour faire
appel à AuthGuard, celui-ci va vérifier que l’utilisateur soit authentifié.
Si l’utilisateur n’est pas authentifié et clique sur Gestion des tables AuthGuard garde l’URL de
destination en paramètre et affiche la page de connexion. Une fois la connexion réussie l’utilisateur
est renvoyé vers la page Gestion des tables grâce à ce paramètre d’url.
Page 30 sur 68
4.8.2 Page d’accueil authentifiée

Une fois l’utilisateur authentifié, la page d’accueil affiche les tables et les données personnelles des
clients. La structure d’affichage des tables est la même que celle d’un client non authentifié.
L’utilisateur peut procéder à plusieurs actions:
Changer le statut d’une table

Le statut stocké en base de données peut être modifié en cliquant sur un bouton dédié à cette finalité.
Ce bouton fonctionne comme un “switch”. Si la table est fermée le bouton affiché est de couleur rouge
et affiche le message “Table fermée”. Si la table est ouverte le bouton est de couleur verte et affiche
le message “Table ouverte”.
Le contrôleur TypeScript du composant TableCard utilise une fonction updateTableStatus pour

contrôler le statut actuel et en envoyer le nouveau vers le backend. Tout dans un objet de type Table,
contenant les informations de la table mise à jour. Une fois la requête SQL bien exécutée, le composant
est rafraîchi.
Page 31 sur 68
Ajouter un client dans la file d’attente d’une table

Pour ajouter un client dans une file d’attente, l’utilisateur dispose d’un bouton avec le symbole “+”.
En appuyant sur ce bouton une boîte de dialogue

ici appelée Modal est affichée. Le contenu de ce
Modal est défini dans le fichier html du
composant avec l'élément Angular “ng-
template” et est généré par le module Bootstrap
Modal.
Bootstrap Modal propose des attributs de base
pour la création d’une boîte de dialogue, comme
la position à l’écran et la taille.
Comme pour la partie Authentification, les

champs ne peuvent pas être vides. Si le nom
d’affichage saisi est déjà utilisé par un autre
client, le backend envoie le code d’erreur 409 et
l’utilisateur reçoit un message d’erreur. Cette
vérification n’est pas demandée dans le cahier
des charges, cependant je la trouve essentielle
pour éviter que la file d’attente affiche plusieurs
fois le même nom.
Une fois le formulaire envoyé, le bouton “Enregistrer” est désactivé pour empêcher une éventuelle
mauvaise manipulation.
Modifier un client existant

Chaque client dans la file d’attente dispose de deux boutons. Le premier à gauche (en jaune sur l’image
ci-dessous) permet à l’utilisateur de modifier les informations personnelles du client depuis un Modal.
Page 32 sur 68
Au moment où l’utilisateur clique sur le bouton

de modification une fonction est appelée et
demande comme paramètres un objet de type
Player et le Modal cible. La fonction reçoit les
paramètres et assigne les données du client à
chaque champ du formulaire respectivement,
ensuite fait appel au module Bootstrap Modal
qui ouvre la boîte de dialogue avec le formulaire.
Ces informations peuvent être modifiées et enregistrées. Comme pour l’ajout d’un client, le nom
d’affichage doit être unique.
Supprimer un client existant

Le dernier bouton à droite (en jaune sur l’image ci-dessous), permet à l’utilisateur de supprimer un
client de la file d’attente.
Cette suppression est permanente et l’utilisateur doit confirmer l’action via une boîte de dialogue.
Comme pour d’autres interactions avec la BDD, le frontend envoie une requête HTTP au backend qui
va exécuter la requête SQL appropriée.
Changer un client de position

Afin de créer une application dynamique, le changement de position d’un client se fait par l’action de
le glisser et déposer.
Après avoir sélectionné un client et le déposer dans une nouvelle position, le contrôleur du composant
TableCard appelle la fonction reorderList et déclenche un événement CdkDragDrop du module CDK (
Component Dev Kit) qui fournit des animations aux composants qui l’importent. Cet événement
récupère le client, son ancienne position et la position où il vient d’être déposé. Toutes ces
informations sont envoyées au backend PHP qui va vérifier vers quel sens sa position a changé.
Page 33 sur 68
Le Diagramme ci-dessous démontre le fonctionnement de la fonction PHP qui fait ce changement de

position:
Vider la table
Pour supprimer tous les clients d’une table, l’utilisateur n’a qu'à cliquer sur le bouton rouge avec un
symbole de poubelle.
Une fonction va envoyer une requête SQL pour supprimer tous les clients ayant cette table comme FK.
Page 34 sur 68
Gestion des tables
Comme expliqué précédemment, la page de gestion des tables n’est accessible que si l’utilisateur s’est
authentifié sur l’application. Elle affiche toutes les tables et donne à l’utilisateur plusieurs possibilités:
Ajouter une table
Pour ajouter une table, l’utilisateur doit cliquer sur le bouton qui contient le symbole de “+” en haut à
gauche de la page.
Ensuite un formulaire est affiché et doit être complètement rempli pour procéder à l’ajout de la table.
Si le formulaire est incomplet l’utilisateur est averti:
Si l’utilisateur essaie d’ajouter une table déjà existante, le backend fait la vérification et retourne un
code 409 et l’utilisateur est averti:
Page 35 sur 68
Modifier une table

Pour modifier une table, l’utilisateur clique sur le bouton d’édition. Le formulaire rempli avec les
informations actuelles de la table s’ouvre. L’utilisateur peut donc modifier et enregistrer les nouvelles
informations.
Une fois le formulaire envoyé au backend, le numéro de table est d’abord vérifié qu’il s’agit bien d’un
numéro de table unique.
Le changement de statut d’une table fonctionne de la même manière qu’en page d’accueil
authentifiée.
Supprimer une table
La suppression d’une table est irréversible et doit être validée une fois le bouton de suppression cliqué.
Pour gagner du temps, j’utilise une fonction « confirm() » disponibilisé par Angular, elle demande à
l’utilisateur sa confirmation via une boîte de dialogue créée par le navigateur, ensuite retourne vrai
s’il clique sur « Ok », ou stop l’action s’il clique sur annuler.
Page 36 sur 68
Affichage
L’affichage actuel utilise un plug-in Maximage pour afficher les images d’un répertoire en boucle.
Maximage est un plug-in jquery utilisé afin de créer des diaporamas. Une page PHP dédiée aux jeux de
tables envoie le chemin du dossier contenant les images et Maximage les affichent une par une en
boucle. Ce système reste inchangé.
4.10.1 Code actuel
Dans la partie analyse j’ai expliqué le fonctionnement de la création des images qui affichent les listes
d’attentes. Le but est désormais de n’utiliser qu’un seul script PHP pour générer les images.
La structure des fichiers était la suivante :
Cette séquence se répète encore 2 fois. Totalisant 3 fichiers contenant du code presque identique.
Ces fichiers seront disponibilisés dans le rendu final.
Page 37 sur 68
4.10.2 Nouveau code

Structure du dossier pkr_images :
- Dossier OLD : Anciens scripts PHP de génération
d’images.
- CMB_ecranPoker_1080.png : Image de fond, base
pour créer les images avec les tables.
- Db.php : Connexion à la base de données.
- Poker_ListPlayer.php : Nouveau script de génération
d’images.
Le nouveau et unique script de génération des images a été conçu depuis l’ancien code. Il a été adapté
d’une façon qu’il récupère toutes les tables de poker et ses clients. A l’aide de quelques boucles et des
validations dans le code, les images PNG sont créées avec au maximum 2 tables et ses clients. Le
diagramme ci-dessous démontre ce fonctionnement.
Page 38 sur 68
Avec un peu plus de temps, j’aurais créé une classe dans le backend qui mettrait les images à jour à
chaque changement dans la base de données et non à chaque minute via un Cron job. Ce changement
est toujours possible en dehors de ce TPI.
Le rendu final est le même que l’ancien et les images créées seront enregistrées dans le répertoire
destiné à l’affichage aux écrans casino.
Voici les files d’attente de tables 1 et 2 générées depuis l’environnement de développement :
4.10.3 Remplacement de l’ancien système

Avant de mettre en place la nouvelle structure qui génère les images, les trois scripts précédents ont
dû être désactivés dans les Cron jobs Apache via Webmin, ensuite les trois scripts ont été placés dans
un dossier appelé « Old ». Le nouveau dossier « prk_images » a été placé dans le répertoire
« generation » du serveur web.
Avant la mise en production la base de données doit être accessible sur le serveur de production et le
fichier php de connexion « db.php » doit être modifier pour communiquer avec cette BDD.
4.10.4 Erreur lors de la mise en production de l’affichage

Une petite erreur a été affiché lors du test de génération d’image :
imagettftext() could not find/open font
Après une recherche Google, j’ai trouvé un incident sur StackOverflow .com qui explique comment
résoudre cette erreur. La solution proposée est, lors de la création de la variable qui spécifie le fichier
de police de caractères IMPACT, de spécifier le chemin complet du fichier, soit :
/var/www/***/generation/include/font/IMPACT.TTF
Après cette modification, les images sont correctement créées.
Une erreur de frappe a ajouté une apostrophe simple dans le nom des fichiers png, cette erreur faisait
que les images ne s’affichent pas dans la page qui fait tourner les images des files d’attente. Cette
erreur m’a coûté au moins 15 minutes de recherche.
Page 39 sur 68
Mise en production
La mise en production d’une application Angular n’est pas compliquée, cependant il y a des points à
faire attention.
Tout au long du projet, le langage TypeScript a été utilisé pour créer les interactions avec l’application.
Cependant l’application en production ne contient pas ce langage, elle utilise le langage Javascript.
C’est pour ça que, une fois le projet en développement terminé, une commande doit être exécutée
depuis le dossier base du projet Angular. La commande utilisée est : ng build.
Ng build transforme le projet Angular en une application web basée sur trois fichiers Javascript, ainsi
que le fichier index.html et d’autres fichiers utiles, comme les fichiers de style.
La commande ng build peut être accompagnée d’un paramètre « --prod », celui-ci va remplacer la
variable d’environnement pour un backend de développement par celle du backend de production.
Une fois cette commande exécutée, un dossier nommé avec le nom de l’application est créé dans un
dossier « Dist » et peut être copié directement dans le serveur web de production.
Quelques points importants avant la mise en production :
 Le chemin de base dans le fichier Index.html doit être modifié afin de pointer vers le dossier
de prod du nouveau serveur.
 Dans le backend, mettre à jour la connexion à la base de données pour communiquer avec le
serveur de prod.
 Remplacer le système d’authentification de test par celui qui s’authentifie avec l’annuaire AD.
Le Raspberry PI utilisé étant déjà sur place et avec l’application Screenly installée, il a dû uniquement
être branché correctement et mis en route. Voici l’appareil connecté :
Câble Ethernet
RJ45
Câble d’alimentation
Page 40 sur 68
Erreur lors de la mise en production
Une erreur rencontrée à cause de la différence de version de PHP avec le serveur de prod. Le serveur
de production a une version PHP dépassée ( 5.5.9). En utilisant PHP 7 dans l’environnement de
développement j’ai utilisé une fonction PHP qui n’existait pas en version 5, la fonction
« random_bytes » utilisée pour la création du token MD5. Cette fonction a été remplacé par
l’alternative « openssl_random_pseudo_bytes ».
Le câble d’alimentation du Raspberry PI a dû être remplacé car il était cassé.
Difficultés rencontrées pour la réalisation
La partie API REST et la partie Authentification ont été sans doute un défi. Plusieurs essais ont été fait
et beaucoup de lecture technique et des moments de réflexion.
5 Documents livrés
La liste des livrables demandé est : Une planification initiale, un rapport de projet, un journal de travail,
un guide utilisateur et le code source complet. Voici la liste des documents fournis :
 Un rapport de projet.  Un guide utilisateur ( en annexe).
 Une planification initiale ( en annexe).  Code source (en annexe ).
 Une planification réelle ( en annexe).  Mise en place de l’environnement de
 Un journal de travail ( en annexe). développement (en annexe).
Vous trouverez en annexes des photos montrant mes deux places de travail, une à la maison pour le
télétravail et autre au Casino de Montreux. Mes deux bureaux sont adaptés et bien éclairés.
Page 41 sur 68
6 Tests
Chaque fonctionnalité de l’application doit être testée et validée comme fonctionnelle dans ce
chapitre. Les problèmes ou bugs identifiés doivent être corrigés ou la fonctionnalité doit être
désactivée pour les utilisateurs si une solution n’est pas trouvée. Après correction, la fonctionnalité
doit être à nouveau testée et validée comme fonctionnelle.
Voici après, les tests effectués pour chaque partie de l’application.
Barre de navigation et pied de page
La barre de navigation affiche les menus et redirectionne l’utilisateur vers la bonne destination.
 Logo -> Page d’accueil.
 Affichage -> Diaporama des images affichées.
 Utilisateur non authentifié :
o Gestion des tables -> Page de connexion.
o Se connecter -> Page de connexion.
 Utilisateur authentifié :
o Gestion des tables -> Page de gestion des tables.
o Se déconnecter -> Page d’accueil non authentifié.
Affichage d’un bouton d’affichage par table.
En cliquant sur un bouton, la table de même numéro est enlevée de la page.
En cliquant sur un bouton d’une table qui n’est pas affichée, celle-ci devient visible.
Un lien dans le pied de page renvoie l’utilisateur vers le guide de l’application.
Page d’accueil non authentifiée
Affichage exhaustif de toutes les tables et ses informations. Ces informations ne peuvent pas être
modifiées.
Affichage exhaustif de tous les clients des tables, en affichant uniquement nom d’affichage et position
et ne peuvent pas être modifiés.
Authentification
Affiche le formulaire de connexion.

Si tous, ou un des champs est vide, ne connecte pas à l’application et avertit l’utilisateur.
Si les identifiants sont incorrects, il ne connecte pas à l’application et avertit l’utilisateur.
Si le formulaire est correctement rempli et envoyé, enregistre le token en local Storage et
redirectionne l’utilisateur vers la page d’accueil authentifiée
Page d’accueil authentifiée
Affichage exhaustif de toutes les tables et ses informations. Le statut des tables peut être modifié.
Affichage exhaustif de tous les clients des tables, en affichant la position, le prénom, le nom et le
téléphone de chaque client.
Ajout d’un client, tous les champs doivent être remplis, sinon un message d’erreur est affiché. Si le
nom d’affichage saisi est déjà utilisé par autre client, affiche un message.
Page 42 sur 68
Les clients peuvent être modifiés ou supprimés de la liste. Le nouveau nom d’affichage doit être
unique.
Un client peut être changé de position en le glissant et en le déposant. Le changement de position des
autres clients se fait automatiquement.
Gestion des tables
Affichage exhaustive de toutes les tables et ses attributs

Ajout de table via un formulaire, tous les champs doivent être remplis. Le numéro de table doit être
unique.
Modification de table. Le numéro de table doit rester unique.
Suppression de table. Confirmation de l’action par l’utilisateur.
Affichage
L’écran à l’entrée de la sale de poker affiche les tables et ses files d’attente.
Erreurs et corrections
Un problème au moment de l’affichage. Les images créées n’étaient pas affichées à l’écran(écran
blanc). Après quelques minutes de recherches j’ai découvert une apostrophe simple dans le nom des
fichiers image générés. Après avoir corrigé la génération des noms des fichiers, le problème a disparu.
Un problème lors du changement de position des clients. La requête qui fait la modification des
positions des clients au-dessus et au-dessous du client déplacé a dû être modifiée.
Validation des tests
Après avoir testé les fonctionnalités de l’application, je peux dire qu’elle est à 100 % utilisable. Des
petites vidéos ont été enregistrées au moment de chaque test et peuvent être visionnées depuis ce
lien :
https://drive.google.com/drive/folders/1gxjEliTh02BR9_OgdWJqciN3PYX-1DfI?usp=sharing
Page 43 sur 68
7 Conclusion et Bilan personnel

Au moment du démarrage de ce projet je n’avais jamais développé une application web tout seul,
cependant il y a environ une année, moi et un collègue de classe avons créé un site e-commerce lors
d’un projet en école. Dans ce projet nous avons pu utiliser toutes nos connaissances et capacités
d’adaptation pour le réussir. Mes connaissances ont été approfondies dans cette branche de
l’informatique et j’ai pu les appliquer lors de ce TPI.
Depuis le début je sentais que le projet avançait comme je l’espérais, dès l’analyse à cette conclusion,
beaucoup de connaissances et savoir-faire ont été acquis. Je me suis adapté au temps donné pour le
développement de cette application et je suis sûr de trouver des améliorations à faire en question de
fonctionnalité ou de design.
L’application développée est facilement modifiable et peut évoluer au fil des années. Elle peut aussi
servir de base pour la création d’autres applications plus élaborées.
La documentation a été quelque chose d’important lors de ce projet, c’est un élément de la gestion de
projet dont je dois m’habituer. J’ai eu l’impression que les 22 heures destinées à la documentation
n’étaient pas suffisantes pour le niveau de travail que je me suis imposé. Je me suis permis d’utiliser
les heures économisées de la partie réalisation pour créer une documentation la plus complète
possible.
Ce projet m’a plus énormément, j’ai été très engagé et maintenant j’ai un sentiment
d’accomplissement et je suis content du résultat final de mon travail.
Page 44 sur 68
8 Glossaire
Terme Définition
AD Active directory – Annuaire Microsoft pour la gestion de domaine.
Apache Serveur logiciel HTTP .
API REST Interface de programmation d'application qui respecte les

contraintes de l'architecture REST.
Backend Partie d’une application dédiée à fournir au frontend des

ressources.
BDD Base de données .
BigBlind Plus grosse des deux mises obligatoires lors du début d’une partie.
Boolean Type de données avec uniquement deux valeurs, 1 ou 0.
BuyIn Droit d’entrée à payer pour jouer.
CLI Command-Line Interface est une interface uniquement en ligne de

commande.
Code HTTP 200 Succès.
Code HTTP 401 Non autorisé .
Code HTTP 404 Ressource non trouvée.
Code HTTP 406 Non accepté.
Code HTTP 409 Conflit .
Commandes npm Node Package Manager sert à gérer les dépendances d’une
application Typescript.
Compiler L’acte de traduire le code informatique en langage machine.
Contrôleur Contient la logique concernant les actions effectuées par

l'utilisateur.
Cron job Tâche planifiée dans un programme Unix appelé Cron.
CryptoJS Librairie de algorithmes JavaScript utilisés pour la cryptographie.
DateTime Type de données pour les Date et heure.
Decimal Type de données pour les numéros avec virgule.
FK Foreign Key – Clé étrangère est une contrainte de référence entre

deux tables SQL.
Fonction Ensemble d'instructions avec le but de réaliser une certaine tâche .
Page 45 sur 68
Footer Pied de page – Partie affichée à la fin de la page.
Framework Ensemble de composants logiciels ou bibliothèque logicielle.
Frontend Partie d’une application dédiée à la partie graphique et interactions

utilisateur.
Header En-tête – peut avoir plusieurs significations en informatique. Dans

ce projet, il fait référence à la barre de navigation dans l’en-tête de
la page.
HTTP Hypertext Transfer Protocol - Protocole de communication client-

serveur.
INT Type de données pour les numéros entiers.
Intranet Réseau informatique privé utilisé par les employés d’une

entreprise.
JavaScript Langage de script orienté objet.
Jquery Bibliothèque JavaScript multiplateforme créée pour faciliter

l’écriture de scripts.
JSON JavaScript Object Notation - Format de données textuelles.
Langage Langage de programmation informatique.
LDAP Lightweight Directory Acces Protocol est un protocole qui permet à

une application d’interroger et modifier les services d’annuaire.
LocalStorage Stockage des données en local, côté utilisateur. Ces données n’ont
pas de durée de vie
MCD Modèle conceptuel des données - Méthodologie Merise de modèle

de données, première étape du modelage des données.
Md5 Message Digest 5 – Fonction de hachage cryptographique.
MLD Modèle Logique des données - Méthodologie Merise de modèle de

données, étape intermédiaire du modelage des données.
Model Un modèle (Model) contient les données à afficher.
Page 46 sur 68
9 Ressources
Personnes
9.1.1 Chef de Projet M. Ballestraz

07.04.2021 - 30 minutes d’échange avec le chef de projet par rapport aux limites de la partie
affichage (Voir la partie Analyse/Conception)
Documentations officielles
PHP :
https://www.php.net/docs.php
Angular :
https://angular.io/docs
https://www.ganatan.com/tutorials/demarrer-avec-angular
Bootstrap :
https://getbootstrap.com/docs/
Site web
Sites utiles :
https://stackoverflow.com/
https://magento.stackexchange.com/
https://github.com/darkslayer92/E-Commerce-Application-Nodejs-Angular-8-MYSQL
API REST :
https://fr.wikipedia.org/wiki/Representational_state_transfer
https://www.redhat.com/fr/topics/api/what-is-a-rest-api
https://practicalprogramming.fr/api-rest
LDAP :
https://jonlabelle.com/snippets/view/php/check-ldap-group-membership-in-php
https://www.php.net/manual/fr/book.ldap.php
Certificat SSL :
https://github.com/RubenVermeulen/generate-trusted-ssl-certificate
Page 47 sur 68
10 Annexes
Planification initiale
Page 48 sur 68
Page 49 sur 68
Page 50 sur 68
Planification Final
Page 51 sur 68
Page 52 sur 68
Page 53 sur 68
Page 54 sur 68
Journal de travail
Page 55 sur 68
Page 56 sur 68
Page 57 sur 68
Page 58 sur 68
Page 59 sur 68
Page 60 sur 68
Guide utilisateur
Ce guide est aussi disponible depuis le lien « Documentation officielle » dans l’application.
10.4.1 Premier contact avec l’application
La nouvelle application Poker Waiting List dispose d’une barre de navigation qui vous accompagne
tout au long de son utilisation.
Le premier item à gauche est le Logo Barrière Poker qui vous retourne à la page d’accueil.
Le deuxième menu affiche les images qui seront affichées à l’écran.
Le prochain est le menu Gestion des tables, il vous redirectionne à la page pour gérer les tables de
poker.
Le dernier menu vous envoie à la page de connexion ou vous déconnecte de l’application.
La page d’accueil vous affiche les tables, leurs statuts (vert si la table est ouverte ou rouge si fermée),
les informations de la table ( Buy in, Big Blind et Small Blind) et les noms d’affichage à l’écran des
clients.
Elle vous permet aussi de cacher ou afficher les tables de cette page. Il vous suffit de cliquer sur les
boutons en haut de page.
10.4.2 Connexion
Pour pouvoir gérer les files d’attente et les table vous devez vous authentifier d’abord.
Une fois le bouton « Se connecter » de la barre de navigation activé, la page de connexion est affichée.
Vous devez donc saisir vos identifiants du domaine (Les identifiants du domaine sont les mêmes utilisés
pour ouvrir votre session sur l’ordinateur).
Les deux champs sont obligatoires*
Page 61 sur 68
Après avoir saisi votre nom d’utilisateur et mot de passe cliquez sur le bouton « Connexion ».
Vous allez être redirigé vers la page d’accueil d’utilisateur connecté.
10.4.3 Gestion de la file d’attente
La page d’accueil d’un utilisateur connecté vous affiche toutes les tables et leurs statuts, ainsi que les
clients qui sont en attente. Depuis cette page vous pouvez procéder à plusieurs actions.
10.4.3.1 Ajouter un client en attente

Pour ajouter un client en file d’attente, vous devez
cliquer sur le bouton « + » dans la partie inférieure de
la table.
Un formulaire s’ouvre et doit être rempli dans son
intégralité.
Important : Le nom d’affichage doit être unique.
Cliquez sur « Enregistrer pour terminer.
10.4.3.2 Modifier un client

Pour modifier un client vous devez cliquer sur le bouton d’édition à droite du nom du client.
Comme pour l’ajout d’un client, un formulaire est affiché et doit être rempli totalement.
Important : Le nom d’affichage doit être unique.
Cliquez sur « Enregistrer pour terminer.
10.4.3.3 Déplacer un client de position
Le changement de position fonctionne via l’action de glisser et déposer.
 Sélectionnez un client en laissant le bouton gauche de la souris pressé.
 Déplacez-le vers le haut ou vers le bas puis lâchez le bouton de la souris.
Page 62 sur 68
10.4.3.4 Supprimer un client

Pour supprimer définitivement un client d’une file d’attente, cliquez sur le bouton le plus à droite du
nom du client.
Confirmez la suppression pour enregistrer l’action.

10.4.3.5 Vider la table
Pour supprimer définitivement tous les clients d’une table vous devez cliquer sur le bouton rouge dans
la partie inférieure de la table.
Confirmez l’action en cliquant sur « Ok ».

10.4.4 Gestion des tables
La page de gestion des tables permet à l’utilisateur connecté plusieurs actions.
10.4.4.1 Ajouter une table
Pour ajouter une nouvelle table de poker, cliquez sur le bouton avec le symbole « + » dans la partie
supérieure gauche de la page.
Vous devez remplir le formulaire affiché correctement et dans son intégralité.

Ensuite, cliquez sur le bouton « Enregistrer » pour terminer.
Important : Le numéro de table doit être unique.
10.4.4.2 Modifier une table

Pour modifier une table vous devez cliquer sur le bouton d’édition dans la partie inférieure de la table.
Le formulaire d’édition s’ouvre et vous pouvez le modifier.

Ensuite, cliquez sur le bouton « Enregistrer » pour terminer.
Important : Le numéro de table doit rester unique.
Page 63 sur 68
10.4.4.3 Supprimer une table

Pour supprimer une table définitivement, cliquez sur le bouton rouge dans la partie inférieure.
Ensuite confirmez l’action en cliquant sur « Ok ».

10.4.4.4 Changer le statut d’une table
Pour changer le statut d’une table, cliquez sur le bouton dans la partie supérieure droite de la table.
Ce changement peut aussi être fait depuis la page d’accueil d’un utilisateur connecté.
10.4.5 Support
Pour avoir du support sur cette application, vous pouvez envoyer un ticket informatique à
simontreux@casinodemontreux.ch.
Page 64 sur 68
Mise en place de l’environnement de développement

Si vous avez déjà une plateforme de développement Web de type XAMPP, MAMP, WAMP ou autre
installée, passez à l’étape 2.
10.5.1 Installation de XAMPP

10.5.1.1 Téléchargez XAMPP depuis le lien https://www.apachefriends.org/fr/index.html
10.5.1.2 Exécutez le fichier d’installation téléchargé
10.5.1.3 Poursuivez l’installation par défaut ou adaptez-la si besoin
10.5.1.4 Une fois l’application installée, ouvrez le panneau de contrôle XAMPP et démarrez les
modules Apache et MySQL.
10.5.2 Copie des fichiers de l’application

Une fois le projet téléchargé, déplacez le dossier Projet-Poker-Waiting-List-V2 dans le dossier
C:/xampp/htdocs/ ou équivalent, selon votre plateforme de développement web.
10.5.3 Base de données
Depuis votre outil de gestion de bases de données, exécutez le Dump SQL fourni dans le dossier livré,
afin de créer la base de données de l’application.
Dans Projet-Poker-Waiting-List-V2/backend/entities/entity.php : vérifier que les informations
concernant la base de données sont bel et bien correctes (nom de la bdd, utilisateur, mot de passe
et serveur).
10.5.4 Mise en place du Framework Angular 11

10.5.4.1 Installation de NodeJS
Téléchargez la dernière version stable de NodeJS (la version LST) sur https://nodejs.org
Installez les options par défaut.
10.5.4.2 Installation des modules Angular

Depuis un terminal de ligne de commande, lancez les commandes :
Page 65 sur 68
 npm install -g @angular/cli

 npm install --save-dev @angular-devkit/build-angular
 npm install @fortawesome/fontawesome-svg-core
 npm install @angular/cdk
10.5.4.3 Compiler et lancer l’application en mode dev

Avec la commande "CD", déplacez-vous dans le répertoire Projet-Poker-Waiting-List-
V2/PokerWaitingListV2/, ensuite lancez la commande "ng serve -o" pour démarrer le projet. Le projet
devrait alors être compiler et ouvert sur votre navigateur par défaut.
Vous pouvez aussi vous rendre à l’adresse locahost:4200 depuis un navigateur.

Une fois le mode de développement lancé, l’application se mettra à jour à chaque enregistrement
des changements dans le code.
Page 66 sur 68
Fonctionnement de l’application
Page 67 sur 68
Lieux de travail
Ma maison à Clarens Bureau Informatique, Casino de Montreux
Page 68 sur 68

Langue

Forti Meisen - TPI - Rapport

Transféré par

Informations du document

Titre original

Copyright

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 :

Forti Meisen - TPI - Rapport

Titre original :

Transféré par

Droits d'auteur :

Winston Forti Meisen Poker Waiting List 15 avril 2021

Travail pratique individuel

Casino arrière de Montreux

Poker Waiting list

Table des matières

Création d’une API REST ........................................................................................................ 22

Planification Final ................................................................................................................... 51

1 Résumé du rapport TPI

2.4.1 Analyse de la planification réelle

Merci de vous référer à l’annexe 10.3 Journal de travail

Poker Waiting List, créée en 2014 et utilisée aujourd’hui:

Actuellement, les images sont générées par trois scripts PHP.

 Le fichier Poker_ListPlayers.php récupère les données de la table 1 et de la table 2 et crée

Affichage de la file d’attente des tables 1 et 2

Les fonctionnalités sont les suivantes :

● Authentification via l’annuaire Active Directory.

Vue globale de l’application : Annexe 10.6 Fonctionnement de l’application

Afin de garantir le bon fonctionnement de l’application et permettre la suite du développement, des

A la fin du projet, l’application sera testée avant sa mise en production.

Gestion des fichiers importants

3 Ordinateur Local 4 Le code est sauvegardé dans un répertoire GitHub

Méthode de gestion de projet

Les différents outils que j'utilise sont :

Visual Studio code

La base de données a été réalisée avec MySQL.

3.10.1 Difficultés rencontrées lors de l’élaboration de la base de données

3.10.2 Modèle Conceptuel de données

Voici le modèle conceptuel de données.

3.10.3 Modèle Logique de données

Voici le modèle logique de données.

3.10.4 Modèle Physique de données

Voici le modèle physique de données.

3.10.5 Création de la Base de données

Différemment de l’analyse initiale, la base de données comporte 3 tables.

3.10.6 Dictionnaire de données

3.10.6.1 Table « T_Tables »

Nom Type Description

ID_Table INT (11) Clé primaire

TableNumber Tinyint (3) Numéro de la table de jeu

BuyIn Decimal (10,2) Valeur du BuyIn

BigBlind Tinyint (3) Valeur du BigBlind

SmallBlind Tinyint (3) Valeur du SmallBlind

TableStatus Boolean Statut de la table, ouverte ou fermé

3.10.6.2 Table « T_Players »

Nom Type Description

ID_Player INT (11) Clé primaire

Name VARCHAR (100) Prénom de la personne

Lastname VARCHAR (100) Nom de la personne

Phone VARCHAR (20) Téléphone de la personne

ViewName VARCHAR (100) Nom d’affichage

Position Tinyint (3) Position dans la file d’attente

FK_Table INT (11) Foreign key

3.10.6.3 Table « T_UsersToken »

Nom Type Description

ID_UserToken INT (11) Clé primaire

Username VARCHAR (100) Nom d’utilisateur

Token VARCHAR (100) Chaîne de caractères aléatoire de contrôle

TokenValidity DateTime Date et heure de la mise à jour du token

La mise en place de l’environnement de développement et la gestion du projet se fait par l’installation

 Angular : Quelques commandes mises à disposition par Angular (commandes ng)

Voici une liste descriptive des principaux dossiers et fichiers

C’est le routage qui va permettre à l’application de gérer la

Une route est la relation entre un chemin et un composant.

4.2.2 Structure de la vue