Projet Info 2A

École nationale de la statistique
et de l’analyse de l’information
Rapport final
Projet d’Informatique 2A
La Pyramide et le Philosophe
Groupe 17 :
Mohamed ASSILI
Cédric GRANDVAUX
Wajih HAMMOUDA
Lorenzo MATHIEU
Tissine PICHON
Tuteur :
Suliac LE GUILLOU
Responsable du cours :
Rémi PÉPIN
2022
Résumé
Nous vous présentons dans ce rapport l’implémentation de notre application que l’on a
nommé Guess the Wikipedia article. Cette dernière est une revisite et un couplage des jeux La
Pyramide et Le Philosophe.
Projet d’Informatique 2A - ENSAI 1 Groupe 17

Sommaire
1 Introduction 4
2 Étude préalable et organisation 5

2.1 Présentation du système et besoins à satisfaire . . . . . . . . . . . . . . . . . . . 5
2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Gestion prévisionnelle des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Architecture du logiciel 9
3.1 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Package Métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Package DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Package View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Package Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Modèle physique de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Principe de l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Implémentation de l’application 18
4.1 Génération des parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.1 Génération des articles avec ArticleGeneration . . . . . . . . . . . . . . 18
4.1.2 Génération des indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3 Mise en place d’une partie . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Utilisation des bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Inscription et connexion d’un joueur . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Consultation de l’historique . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Fichier main.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Tests et Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Test Métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Test DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Guide d’utilisation de l’application 23

5.1 Comment se créer un compte / se connecter . . . . . . . . . . . . . . . . . . . . 23
5.2 Comment jouer une partie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Comment consulter son historique . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Bilan et pistes d’amélioration 27

6.1 Le code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 L’organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Conclusion 29
2
SOMMAIRE
8 Notes individuelles 30
8.1 Mohamed ASSILI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.2 Cédric GRANDVAUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Wajih HAMMOUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.4 Lorenzo MATHIEU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.5 Tissine PICHON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9 Annexes 35

Chapitre 1
Introduction
Ce projet a pour but de mettre en œuvre un jeu original, mélange de deux jeux existants : la
Pyramide et le Philosophe. La Pyramide est un jeu télévisé se jouant par équipes, dans lequel le
but est qu’un des joueurs fasse deviner un mot à ses coéquipiers à l’aide de synonymes. D’autre
part, le Philosophe est un jeu se jouant sur internet, dans lequel le joueur part d’une page
Wikipédia aléatoire et, en utilisant les liens hypertextes, doit parvenir à la page "philosophie".
Footballeur, Argentin, Records, Espagne ? C’est ce genre d’indices que vous pouvez obtenir
en jouant à notre tant attendu jeu "Guess the Wikipedia article". Notre application se veut
simple d’utilisation et ludique. Elle a été conçue durant le premier semestre de la deuxième an-
née à l’ENSAI. Nous avons utilisé Python pour l’implémentation et GitLab pour le versionnage
de nos versions ; les graphiques ont été réalisés sur draw.io et lucidchart. De plus, nous avons
utilisé SQL pour la persistance de certaines données que nous expliquons dans le paragraphe
Modèle physique de données. Le jeu est directement accessible via le terminal Python.
Nos objectifs ont été multiples : premièrement, nous voulions rendre notre application la plus
fonctionnelle possible. Puis un autre objectif important pour tous était d’apprendre à travailler
en groupe et à tirer le meilleur de chacun ; pour cela, nous avons utilisé plusieurs outils colla-
boratifs tels que GitLab et Teams. Ce rapport de fin de projet vise à mettre en évidence notre
compréhension et notre vision du sujet après une phase d’étude préalable, ainsi que l’implémen-
tation de notre application et son fonctionnement. Dans cette perspective, nous présenterons
dans un premier temps le cahier des charges à respecter ainsi que l’organisation de notre travail
de groupe, puis nous exposerons l’architecture qu’a notre programme. À la suite de cela, nous
expliquerons la façon dont nous avons implémenté le jeu, et comment fonctionne l’application.
Nous finirons par quelques idées de pistes que nous aurions pu suivre pour améliorer notre
programme.
4
Chapitre 2
Étude préalable et organisation
Cette première phase d’analyse consiste en la formalisation des besoins décrits par le cahier
des charges.
2.1 Présentation du système et besoins à satisfaire

Pour commencer, le but de notre application est de faire jouer l’utilisateur au jeu de la
Pyramide revisité. Le joueur aura pour objectif de trouver le titre d’une page Wikipédia grâce
à des indices générés par l’application. Pour ce faire, notre programme devra se baser sur l’en-
semble des articles de Wikipédia, dont il tirera celui à faire deviner aléatoirement parmi les plus
lus. À partir de cette page, notre application utilisera l’ensemble des mots composant l’article
comme indices potentiels. En particulier, les indices correspondront aux mots les plus fréquents,
ou bien ceux donnant les catégories auxquelles appartient l’article, ou encore les portails qui
apparaissent sur la page de l’article cible. À chaque indice donné, le joueur devra proposer une
réponse ; si celle-ci est incorrecte, il recevra un autre indice, et ainsi de suite jusqu’à ce qu’il
propose la réponse attendue et gagne. Si après un trop grand nombre d’essais (11 propositions
erronées) la réponse n’a pas été trouvée, le jeu s’arrêtera et le joueur aura échoué.
Dans un premier temps, l’application proposera le jeu à deux types de joueurs : ceux qui
possèdent un compte et les autres. Dans cette perspective, les joueurs qui ne possèdent pas
de compte pourront à tout moment en créer un, et il suffit ensuite de s’authentifier avant une
partie pour pouvoir sauvegarder son score et l’afficher.
Ensuite, notre programme permettra à l’utilisateur de consulter son historique et ses statis-
tiques et de sauvegarder ses scores s’il possède un compte. Le score sera calculé en fonction du
nombre de tentatives qui ont été nécessaires pour atteindre la bonne réponse.
Concernant le jeu en lui-même, l’application devra filtrer les indices à proposer afin qu’ils
ne soient ni trop courts (c’est-à-dire composés d’au moins cinq caractères), ni trop proches
du titre de l’article à trouver (donc qu’ils ne contiennent pas de mots en communs). Enfin,
les articles cibles proposés ne doivent pas être des articles considérés comme "injouables". Par
exemple, l’application ne devra pas tenter de faire deviner des articles portant sur des sujets
trop peu consultés sur Wikipédia, ou encore dont la longueur n’est pas suffisante pour proposer
un nombre assez important d’indices.
2.2 Diagramme de cas d’utilisation

La Figure 2.1 présente le diagramme de cas d’utilisation de notre application. Il vise à
modéliser les interactions qui vont exister entre l’utilisateur de notre logiciel, dans notre cas le
joueur, et le système.
5
CHAPITRE 2. ÉTUDE PRÉALABLE ET ORGANISATION
Figure 2.1 – Diagramme de cas d’utilisation de notre logiciel
On va ici distinguer deux types de joueurs : ceux qui ont créé un compte et ceux qui
jouent en tant que simples visiteurs. Quel que soit son statut, le joueur aura la possibilité de
commencer une partie, et lors de celle-ci, de proposer des réponses ou bien de demander un indice
supplémentaire. Dans le cas où le joueur s’est créé un compte, il pourra s’authentifier avant une
partie afin que son score soit sauvegardé après la partie, et il pourra consulter l’historique de
ses scores et ses statistiques à tout moment. Concernant les visiteurs, ils pourront se créer un
compte pour obtenir le statut et les fonctionnalités des utilisateurs possédant un compte.

2.3 Gestion prévisionnelle des tâches
Figure 2.2 – Diagramme de GANTT
Le projet informatique était axé autour de 4 grandes phases, la première étant la phase
d’analyse pendant laquelle nous avons étudié le sujet en reprécisant les aspects qui nous pa-
raissaient flous et en listant les besoins que notre application devait satisfaire. Puis nous avons
réalisé le diagramme de Gantt qui nous permettait d’identifier les tâches que nous devions ac-
complir dans le but de mener l’implémentation de l’application à bien et dans les délais impartis.
Ensuite, durant la phase de conception nous avons réalisé les diagrammes d’activité, de
classes et le modèle physique de données ; ils nous permettent de répondre aux exigences du
cahier des charges que nous nous sommes fixés pendant la phase précédente.
C’est durant la troisième phase que nous avons implémenté notre application. Comme nous
étions cinq à coder les classes en même temps, nous avons utilisé l’outil de versionnage GIT :
nous avons créé un dépôt sur GitLab. Les classes de la DAO et la création de la base de données
sont en jaune, en vert vous pouvez retrouver l’implémentation des classes se rapportant à la
partie métier, en violet le package service et en bleu toutes les classes du package view.
Enfin la dernière phase du projet a été la préparation du livrable et de la soutenance, pendant

laquelle nous avons rédigé le rapport final et nous nous sommes préparés pour la soutenance
orale.
Au niveau de l’organisation du groupe nous avons codé en même temps, d’où l’utilisation de
GIT, nous communiquions grâce à Teams et faisions un point hebdomadaire afin de partager
notre avancé sur le projet avec les autres membres du groupe et d’organiser les tâches à venir.

Chapitre 3
Architecture du logiciel
Afin de modéliser notre projet avant de le coder, nous avons réalisé un certain nombre de
diagrammes présentant la conception générale de notre application. Ils sont exposés et expliqués
dans cette partie, ainsi que l’architecture générale de notre code.
3.1 Diagramme d’activité

La Figure 3.1 ci-dessous illustre le diagramme d’activité modélisant l’application permettant
de jouer au jeu Guess the Wikipedia article :
9
CHAPITRE 3. ARCHITECTURE DU LOGICIEL
Figure 3.1 – Diagramme d’activité de notre logiciel

Une fois l’application ouverte, sur le menu principal, le joueur a quatre options : quitter et
donc fermer l’application, jouer sans se connecter, s’authentifier ou se créer un compte.
Si le joueur se crée un compte, il sera ensuite redirigé sur ce premier menu pour qu’il puisse se
connecter.
Lorsque le joueur se connecte, il arrive sur un menu lui proposant de consulter son historique,
commencer une partie ou quitter l’application.
Mais si le joueur décide de ne pas se connecter il aura juste le choix entre commencer une partie,
retour au menu principal ou quitter l’application.
Lorsqu’un joueur commence une partie, un article aléatoire va être généré. Pour que le joueur
puisse deviner le titre de cet article, l’application va proposer un premier indice parmi une liste
d’indices générés depuis le texte de l’article, et le joueur peut faire une première proposition. À
la suite de cela, si le titre de l’article est trouvé par le joueur, la partie s’arrête et le joueur peut
voir s’afficher le score qu’il a obtenu. Sinon, un nouvel indice est donné, et ce jusqu’à obtenir la
réponse correcte de la part du joueur, sauf lorsqu’il atteint les 11 propositions ou s’il souhaite
abandonner pendant la partie. Dans ce cas, la partie s’arrête aussi et le joueur a perdu : il
obtient le score de 0 et la réponse s’affiche. Une fois la partie finie, le joueur peut choisir s’il
veut recommencer une nouvelle partie, auquel cas la procédure expliquée précedemment va se
répéter à partir du commencement d’une partie ou alors soit il choisit de quitter l’application
soit il sera reconduit sur le menu principal.
3.2 Diagramme de séquence

Le diagramme de séquence représente les intéractions entre les différents acteurs de notre
application et les parties qui composent le système. Il est présenté ci-dessous (Figure 3.2) :
Figure 3.2 – Diagramme de séquence de notre logiciel
Pour commencer, si l’utilisateur veut se créer un compte, l’interface va prendre en compte sa

demande, et les informations vont être transmises à la base de données où elles seront stockées
via la DAO.
Si le joueur a déjà un compte et souhaite s’identifier, de la même façon les informations

rentrées vont être transmises à la base de données, et vérifier leur exactitude. Si elles sont cor-

rectes, l’authentification est réussie et le joueur peut poursuivre.
Pour consulter un historique, c’est le même processus que précedemment : la demande est
transmise à la DAO, qui va chercher les informations requises dans la base de données et qui
va les afficher via l’interface.
Afin de jouer au jeu en lui-même, lorsque le joueur commence une partie, un article va être
généré aléatoirement et récupéré grâce à l’API. À la suite de cela, la partie Métier va créer les
indices nécessaires à la partie, et conserver le titre de l’article qui est la réponse à trouver. Les
indices vont être un à un transmis au joueur, qui proposera des réponses, et celles-ci seront
vérifiées pour déterminer si elles sont correctes ou non. À la fin d’une partie, le score du joueur
est calculé et affiché pour le joueur, et également sauvegardé dans le base de données par le
biais de la DAO.
3.3 Diagramme de classes

Notre diagramme de classes est constitué de quatre grandes parties :
— Une partie Métier

— Une partie View
— Une partie DAO
— Une partie Service
La partie Métier représente le jeu en lui même, c’est-à-dire qu’elle permet la génération des
indices permettant au joueur de deviner l’article en question.
La partie Service s’occupe de la géneration des aides qui permettent de guider le joueur à
trouver l’article.
Quant à la partie View, elle permet le lien entre le joueur et l’application en lui proposant
des étapes de déroulement grâce à des menus où il aura un choix particulier à faire. Ainsi, cette
classe demandera à ce dernier des informations nécessaires à la mise en œuvre du jeu. Nous
utiliserons la librairie PyInquirer pour ces classes.
Et finalement, la partie DAO donne accès aux informations contenues dans les bases de
données ou les modifie.
Dans les parties suivantes, nous avons séparé le diagramme de classes selon ces quatre
parties, pour plus de lisibilité. La version entière est néanmoins disponible en Annexes 9.1, avec
les liens entre les différentes parties exposées ci-dessous.

3.3.1 Package Métier
Figure 3.3 – Package Métier
Les différentes classes de ce package sont détaillées ci-dessous :
— La classe ArticleGeneration : cette classe a pour rôle de générer les articles, et d’obtenir
leurs caractéristiques, comme leur titre, leurs catégories, leur résumé, leur nombre de
vues, et leur contenu complet. C’est également dans cette classe que l’on vérifie qu’un
article est bien jouable.
— La classe Article : cette classe vise à gérer tous les éléments touchant aux articles issus de
Wikipédia. Elle dispose d’un titre et d’indices. Cette classe contient plusieurs méthodes,
qui permettent notamment de trouver les mots les plus fréquents, de sélectionner les
indices qui pourront être donnés, ou encore de vérifier si un article est jouable ou pas.
La méthode centrale de cette classe est get_clue(). Elle permet de générer une liste
d’indices pertinents.
— La classe Player : c’est la classe qui identifie le joueur. Elle est principalment utilisée
pour instancier un objet Player.
— La classe History : c’est une classe qui permet de définir l’historique d’un Player sur une
partie jouée. Elle est principalement utilisée pour instancier un objet History.
Le choix d’avoir introduit les deux classes History et Player dans le package Métier est
justifié par le fait qu’elles ne peuvent être introduits dans d’autres packages. En effet, elles ne
contiennent pas de méthodes, et elles permettent juste d’instancier des objets qui sont utilisés
dans les classes DAO.

Ainsi, nous avons décidé de supprimer la classe Game par rapport au diagramme du rapport
intermédiaire. Nous nous sommes dit qu’il suffisait de créer un objet Article afin de dérouler
une partie.
3.3.2 Package DAO
Figure 3.4 – Package DAO
Ce package contient les classes implémentant des requêtes SQL :
— La classe PlayerDao : cette classe permet d’ajouter un joueur grâce à la méthode add_player.
Dans le cas où ce joueur désire modifier ses informations, la méthode update_player
s’en occupera. Les méthodes get_all_players_names et get_all_emails renvoient des
listes de noms de joueurs et une liste d’adresses mail. À cela s’ajoute la condition d’unicité
des adresses mail lors de la création d’un compte. Enfin la méthode find_player_by_id
sera utilisée dans la classe HystoryDao afin d’ajouter des historiques aux joueurs exis-
tants dans la base de données Player.
— La classe HistoryDao : cette classe permet d’enregistrer l’historique d’un joueur. À chaque
partie jouée, la méthode add_history stocke son score, son nombre d’essaie, ainsi que
l’article qu’il devait deviner.
En ce qui concerne la connexion avec la base de données, elle se fait grâce à la classe
DBConnection.

3.3.3 Package View
Figure 3.5 – Package View
Ce package contient des views qui héritent de la classe AbstractView avec les deux méthodes
non implémentées. Pour les classes qui en héritent, la méthode display_info() représente ce
qui sera affiché à l’écran, et la méthode make_choice() permettra de naviguer entre les Views.
Aussi, la méthode play_game de la classe GameView contient un algorithme permettant de
dérouler un partie.
En plus, les attributs utilisés par les Views seront gérés par la classe Session qui est un
singleton. Cela permet de garantir que chaque accès à cet objet retoune la même instance et
donc les mêmes valeurs stockées dans les attributs de la Session.
Nous expliquerons plus en détails dans la partie implémentation la raison pour laquelle la
méthode make_choice() retourne une chaîne de caractères et non un objet de type View.
Nous nous sommes mis d’accord pour utiliser la bibliothèque InquirerPy qui permet d’in-
téragir avec le joueur et de récupérer ses inputs.

3.3.4 Package Service
Figure 3.6 – Package Service
Le package Service permet d’orchestrer le jeu. En effet, la classe GameService permet

de générer les indices lorsque le joueur en fait la demande. Les méthodes first_task() et
next_task() retournent une liste à 2 éléments, le premier est un affichage destiné au joueur et
le deuxième est l’indice en question.
En comparaison au rapport intermédiaire, nous avons supprimé les classes HistoryService et

PlayerService, étant donné qu’il nous semblait plus naturel d’enregistrer les données des joueurs
et leur historique en amont de l’implémentation des LoginView, SignUpview et SaveHistoryView.
3.4 Modèle physique de données
Figure 3.7 – Modèle physique de données
Dans notre projet, nous avons besoin de deux tables. Une table pour les joueurs qui se sont
créés un compte et une autre qui va contenir les informations des parties jouées par ces joueurs.
La table Player contient l’identifiant de chaque joueur (id_player), leur pseudo (player_name),
leur email et leur mot de passe (pass_word), afin qu’ils puissent s’authentifier. L’identifiant des
joueurs servira de clé primaire. Quant à la table History, elle contient un identifiant (id_history)
qui sert de clé primaire et l’identifiant du joueur qui sert de clé étrangère. On retrouve aussi le
score du joueur sur cet article, le nombre d’essais du joueur (attempts) et le titre de l’article
(article).

3.5 Principe de l’API

Dans ce projet, nous avons besoin de scrapper des articles Wikipédia afin de les utiliser dans
notre application. Pour ce faire, nous disposons d’une variété de librairies de scrapping en Py-
thon (notamment Beautiful soup et LXML), mais étant donné que le contenu de chaque article
Wikipédia est modifiable par pratiquement tout le monde (même la structure HTML/CSS peut
changer lors de l’ajout d’une section), nous risquons d’être confrontés à beaucoup de problèmes
avec chaque recharge de l’application. Alors, nous avons opté pour une API.
Une API, Application Programming Interface, est une interface qui donne la possibilité d’échan-
ger des données entre deux applications différentes. Avec une API, nous récupérons directement
les données sans avoir besoin de les scrapper manuellement. En faisant cela, nous évitons tous
les problèmes liés aux changements de structure des articles. De plus, cela est plus efficace au
niveau du code puisque nous n’avons pas besoin de gérer des langages HTML, CSS ou JavaS-
cript. L’API que nous adoptons dans ce projet est le WIKIMEDIA REST API. Cette API
permet d’accéder au contenu et métadonnées du domaine Wikipédia. Tout au long de ce projet,
nous agirons directement sur l’API en utilisant des librairies comme fastAPI ou indirectement
à travers la bibliothèque WIKIPEDIA en Python qui permet de récupérer les articles selon nos
besoins.
Pour ce qui est des méthodes utiles nous avons :
— wikipedia.set_lang(’fr’) qui nous permet de choisir la langue des articles que nous récu-
pèrerons.
— wikipedia.summary(’eu’)) qui nous permet de récupérer uniquement l’introduction de
l’article, utile pour la sélection des indices.
— wikipediapage.title qui nous permet de récupérer le titre de l’article.
— wikipediapage.url pour avoir son url.
— wikipediapage.content pour obtenir le contenu de l’ensemble de la page.
— wikipediapage.links pour récupérer les liens hypertextes.
L’API nous facilite grandement le travail puisqu’il ne nous reste qu’à nous occuper de la
forme et du traitement des données reçues.

Chapitre 4
Implémentation de l’application
Dans cette partie, nous détaillons la façon dont nous avons implémenté notre jeu, notamment
comment notre application génère des parties, et comment sont stockées les données.
4.1 Génération des parties

4.1.1 Génération des articles avec ArticleGeneration
Pour la génération des articles, nous utilisons l’API wikipediaapi qui récupère les 1000
articles les plus vus sur une période donnée. Ici nous avons les 1000 articles les plus vus sur
le mois. Il y a une génération aléatoire du mois et de l’année. Sur ces 1000 articles, nous
prenons seulement les 100 les plus vus pour avoir des articles plus accessibles. Ensuite, la classe
ArticleGeneration se chargera de récupérer le nombre de vues, le titre, le contenu de la page,
les portails et catégories. Une méthode permet de vérifier que l’article récupéré fonctionne bien
avec l’API. La méthode new_rdm permet de choisir un autre article parmi ceux récupérés.
Ensuite nous avons la classe Article qui permet le traitement de l’article reçu pour permettre
de faire une liste d’indices qui sera ensuite utilisée par le programme. Une vérification avec la
méthode validation de ArticleGeneration sera effectuée avant l’initialisation des attributs de
Article.
4.1.2 Génération des indices

Pour générer les indices, nous utilisons le texte d’un article Wikipédia. Au départ, nous
avions émis l’idée d’utiliser les mots apparaissant sous forme de liens hypertextes dans l’article
comme indices, mais nous nous sommes rendu compte qu’ils n’étaient pas toujours pertinents
(dates, nombres, ...). Finalement, les types d’indices que nous sélectionnons sont les suivants :
— Les catégories auxquelles l’article appartient, que nous pouvons récupérer grâce à l’API
Wikipedia, via la méthode page.categories.
— Les portails vers lesquels mène l’article.
— Les mots les plus fréquents : ce sont les mots qui sont le plus souvent cités dans
l’article, sans compter les mots de liaison et les mots trops courts.
Alors que récupérer les catégories et les portails est très simple et direct, nous avons dû plus
réfléchir afin d’obtenir les indices correspondant aux mots les plus fréquents. Pour ce faire, nous
avons instancié une méthode frequent_words, qui fonctionne de la façon suivante : lorsque
nous avons récupéré l’ensemble des mots qui composent l’article à faire deviner, nous comptons
18
CHAPITRE 4. IMPLÉMENTATION DE L’APPLICATION
leurs occurences dans le texte, afin de repérer ceux qui sont le plus souvent mentionnés, et qui
sont de ce fait très liés à l’article à faire deviner. Nous stockons ces mots dans un dictionnaire,
auquel nous avons associé le nombre d’apparitions pour chacun. De plus, pour ne donner que
des indices pertinents, nous avons fait attention à éliminer les mots de moins de 4 caractères,
ainsi que plusieurs mots de liaison récurrents que nous avons spécifiés dans le code.
4.1.3 Mise en place d’une partie

Une fois une partie lancée par un joueur, l’application va afficher un premier indice, puis
après la première proposition du joueur, si celle-ci est incorrecte, il va pouvoir refaire une pro-
position, ou bien demander un autre indice.
Au départ, le score du joueur sur la partie est initialisé à 100. À chaque fois qu’un indice
est donné, le joueur perd 10 points. Si le score du joueur atteint 0, alors la partie s’arrête et on
considère que le joueur a échoué, ce qui revient à dire que le joueur a droit à 11 tentatives.
La méthode play_game() dans la classe GameView s’occupe du déroulement de la partie

grâce à une boucle while, tout en utilisant les deux méthodes first_task() et next_task()
du GameService.
Figure 4.1 – Boucle While dans la méthode play_game()
La méthode similar() permet de vérifier la similarité entre le nom de l’article et la réponse

du joueur. Ainsi, la réponse rentrée par le joueur n’a pas besoin d’être exactement la même
que celle attendue pour qu’il gagne, c’est-à-dire qu’une faute d’orthographe ou l’oubli d’une
majuscule par exemple ne sont pas pénalisés. Cela rend le jeu plus souple, selon un seuil que
l’on définit. Dans l’exemple de la Figure 4.1, le seuil est fixé à 0.7, ce qui signifie que la chaîne
de caractères rentrée par le joueur doit être au moins similaire à 70% avec la réponse attendue
pour être acceptée comme bonne réponse.
4.2 Utilisation des bases de données

4.2.1 Inscription et connexion d’un joueur
Une base de données est utile dans ce projet non pas pour stocker les informations relatives
aux articles, qui seront directement récupérées grâce à l’API, mais pour gérer les comptes des
utilisateurs et leur historique. Notre base de données, comme présentée précedemment, contient
deux tables, et est hébergée sur PostgreSQL.
Le stockage des données lors de l’inscription d’un joueur se fait au sein de SignUpView.
En effet, l’interface demande au joueur de rentrer un player_name (identifiant) et une adresse
mail qui doivent être uniques, ainsi qu’un mot de passe (pass_word). L’unicité se vérifie en
confirmant que le player_name ou l’adresse mail n’existent pas déjà dans les listes retournées
par les méthodes get_all_players_name et get_all_emails.
Une fois que le joueur a bien rempli tous les champs, l’objet Player prend en paramètres ses
informations et la classe PlayerDao s’occupe de le rajouter dans la base de données grâce à la
méthode add_player(player:Player) :

Figure 4.2 – Table Players
La méthode utilisée pour le hashage du mot de passe est generate_password_hashest prise

dans la bibliothèque Werkzeug. Pour vérifier que le mot de passe hashé concorde avec celui que
l’utilisateur a rentré, nous utilisons la méthode check_password_hash.
Étant inscrit, un joueur peut maintenant se connecter. La classe LoginView vérifie l’exis-
tence de ce joueur à l’aide de la méthode find_player_by_playername(). En cas de connexion,
l’attribut login_check prend la valeur True.
Dans le cas où le joueur ne met pas le bon identifiant ou mot de passe, il pourra soit
changer son mot de passe ou retenter l’opération. S’il opte pour le changement de mot, la classe
UpdateView s’en occupera en lui demandant son player_name et le nouveau mot de passe qu’il
souhaite avoir.
4.2.2 Consultation de l’historique

Contrairement à un joueur en session invité, un joueur connecté peut consulter son his-
torique, qui regroupe chaque partie jouée. Son score, son nombre de tentatives et le nom de
l’article en question sont stockés dans les attributs de la Session. À chaque fin de partie, l’histo-
rique du joueur est sauvegardé grâce à la classe SaveHistoryView. Tout d’abord, il faudra que
le joueur soit présent dans la base de données Players, ensuite on ajoute les données stockées
par Session (son historique) à l’aide de la méthode de la classe HistoryDao : add_history().
La table qui stocke les informations relatives aux parties jouées et qui constitue donc l’his-
torique du joueur, se présente de la façon suivante :
Figure 4.3 – Table History
Ici, chaque partie jouée a un identifiant unique. Cette table communique avec la table Players
par le biais de id_player, qui correspond à l’identifiant du joueur qui a joué la partie. De plus,
à chaque partie est associée un score et un nombre de tentatives. Enfin, on peut voir le nom de
l’article qu’il fallait deviner.

4.3 Fichier main.py

Étant donné que les vues renvoient des chaînes de caractères, nous avons mis en place un
dictionnaire associant chacune de ses dernières à son objet view :
Figure 4.4 – Fichier main.py
Le choix de retourner des chaînes de caractères a permis de ne pas faire les importations
des autres classes "vues", ce qui nous a permis d’éviter le problème de dépendance circulaire
vu en TP.
Le lancement de ce fichier main.py se fait par le biais de ce bout de code :
Figure 4.5 – Fichier main.py
En effet, la première vue est le menu Start, puis tant que la vue est différente de None on
récupère la chaîne de caractères dans la variable next par la méthode make_choice(). Si elle
prend comme valeur "Quit", le jeu s’arrête, sinon elle stocke un objet View du dictionnaire
ci-dessus.
4.4 Tests et Documentation

4.4.1 Test Métier
Nous avons réalisé plusieurs tests durant et après la phase de code afin de nous assurer
que notre application soit cohérente et fonctionne bien. Nous avons réalisé les tests unitaires
obligatoires sur la classe ArticleGeneration, que vous pouvez trouver dans le module
test/metier_test/test_article_generation. Pour tester une classes qui se base sur l’aléatoire,
nous fixons le hasard avec une sélection d’articles et nous créons un dictionnaire dans la classe
MockGenerator avec 10 articles. La classe MockGenerator est identique à la classe ArticleGe-
neration à la seule différence qu’elle n’a pas une génération aléatoire d’article. Ce contrôle de
l’aléatoire permet par la suite de faire les tests de ArticleGeneration et Article de manière
beaucoup plus simple. Nous avons utilisé les méthodes assert pour vérifier que les données
retournées par nos méthodes correspondaient à ce qu’on attendait.

Par exemple, article.get_title() doit renvoyer les noms des articles ("Cookie (informa-
tique)", "Wikipédia : Accueil principal",...).
La méthode get_views est aussi testée grâce à la méthode test_get_view : le test vérifie que
le nombre de vues de l’article correpond bien au nombre qui a été défini dans le dictionnaire.
Enfin, la méthode test_validation implémente un test unitaire pour la méthode validation.
Pour le test de la classe Article, cela fonctionne exactement de la même manière que pour Ar-
ticleGeneration. La classe MockGenerator est ici utilisée pour pouvoir créer des tests avec des
articles prédéfinis. Cela permet ncore une fois de contrôler l’aléatoire.
4.4.2 Test DAO

Nous avons aussi réalisé des tests pour les classes DAO. Pour la classe PlayerDao, nous nous
sommes assurés que la méthode add_player() renvoie bien True quand un joueur est ajouté
dans la base de données. Idem pour la méthode update_player() quand les informations du
joueur sont modifiées.
Nous avons fait de même pour la méthode add_history() dans la classe HistoryDao.
Figure 4.6 – Exemple de test pour la méthode add_history()
De même, nous avons réalisé la documentation sur toutes nos classes et toutes nos méthodes,
car nous pensons qu’une documentation complète est indispensable pour la compréhension de
nos méthodes.

Chapitre 5
Guide d’utilisation de l’application
Dans ce chapitre, nous allons expliquer comment utiliser notre application dans ses diffé-
rentes étapes.
5.1 Comment se créer un compte / se connecter

Pour commencer, lorsqu’on lance notre application, nous arrivons sur le menu représenté par
la Figure 5.1. Plusieurs choix s’offrent à l’utilisateur. Supposons que c’est sa première connexion
et qu’il souhaite de ce fait se créer un compte avant de jouer, dans la perspective de pouvoir
sauvegarder ses scores et statistiques. Pour ce faire, le joueur doit sélectionner l’option "Sign
Up" avec le curseur, et appuyer sur Entrée pour valider.
Figure 5.1 – Menu principal du jeu pour un joueur non connecté
L’utilisateur va ensuite voir apparaître les trois questions ci-dessous, à savoir son pseudo,
son adresse email et son mot de passe :
Figure 5.2 – Informations à remplir pour se créer un compte
Une fois toutes ces informations renseignées, le joueur a réussi à se créer un compte. Il arrive
alors sur le menu principal pour joueurs authentifiés (Figure 5.4).
Si un joueur revient sur le jeu alors qu’il s’était déjà préalablement créé un compte, il devra
choisir l’option "Log In" dans le premier menu (Figure 5.1). À la suite de cela, il aura accès à
l’interface lui permettant de remplir son pseudo et son mot de passe, afin de s’authentifier (voir
Figure 5.3).
23
CHAPITRE 5. GUIDE D’UTILISATION DE L’APPLICATION
Figure 5.3 – Interface permettant à un joueur déjà enregistré de se connecter
Finalement, que le joueur vienne de se créer un compte ou qu’il se soit connecté à un compte
créé par le passé, il va dans tous les cas se retrouver sur le menu ci-dessous, qui est le menu
apparaissant lorsqu’un joueur est connecté. À la différence du menu de départ, ici le joueur a
la possibilité de consulter son historique, de jouer en tant que joueur connecté et non plus en
tant qu’invité, et de se déconnecter :
Figure 5.4 – Menu principal
5.2 Comment jouer une partie

Une partie peut se jouer par un joueur connecté ou non. Si l’utilisateur n’est pas authentifié,
il peut choisir "Play Without Logging In" dans le premier menu (Figure 5.1). Il verra alors
l’interface suivante s’afficher :
Figure 5.5 – Confirmation : jouer sans se connecter
Il peut alors choisir de jouer, de retourner au menu précédent, ou bien de lire les instructions
du jeu. Les instructions affichées sont les mêmes que le joueur soit connecté ou non, et prennent
la forme suivante :
Figure 5.6 – Instructions du jeu
Si le joueur choisit "play" pour commencer une partie, la partie va se lancer et il aura à
chaque fois la possibilité de recevoir un indice et/ou de faire une proposition de réponse. À
chaque étape, le score actuel va être affiché.

Ainsi, dans l’exemple de la Figure 5.7, le joueur a obtenu comme premier indice le mot
"numérotation". Son score est à 90, c’est-à-dire que c’est son premier indice car chaque indice
donné fait baisser le score de 10 points, et le score de départ vaut 100. Dans cette situation, le
joueur peut choisir d’obtenir un indice supplémentaire ou pas, ou bien d’abandonner la partie,
ce qui le reconduira au menu.
Figure 5.7 – Obtention d’un indice
Dans l’exemple de la Figure 5.8 ci-dessous, après avoir obtenu l’indice "continent", le joueur
propose la réponse "europe".
Figure 5.8 – Essai d’une réponse
Si la réponse correcte n’est pas trouvée à la suite des 11 tentatives autorisées, le message
suivant va s’afficher :
Figure 5.9 – Game over
La réponse correspondant au titre de l’article qu’il aurait dû trouver est affichée, dans cet
exemple c’était "Liste des indicatifs téléphoniques en France". Le joueur peut alors retenter sa
chance et rejouer une nouvelle partie, ou bien retourner au menu, ou encore quitter l’application.
En revanche, si la réponse est devinée, c’est le message suivant que le joueur va voir s’afficher :

Figure 5.10 – Partie gagnée
Le score final est annoncé, et le joueur a ensuite les mêmes possibilités qu’en cas d’échec,
à savoir jouer une nouvelle partie ("Replay"), retrouner au menu ("Back to menu") ou quitter
l’application ("Quit").
5.3 Comment consulter son historique

Si le joueur veut consulter son historique, il doit être connecté et sélectionner "My history"
dans le menu principal (Figure 5.4).
Figure 5.11 – Consulter son historique
Ensuite, l’utilisateur a deux possibilités : consulter son historique, c’est-à-dire les articles
qu’il a eu à deviner, ainsi que le score associé à chacune de ses parties, ou bien voir ses statis-
tiques. Les statistiques regroupent deux informations : le meilleur score du joueur sur toutes les
parties qu’il a jouées, ainsi que le plus petit nombre de propositions qu’il a eu à faire avant de
trouver une bonne réponse.

Chapitre 6
Bilan et pistes d’amélioration
6.1 Le code
Avant ce projet, nous n’avions que peu d’expérience en programmation orientée objet, outre
le projet de l’année précédente, et encore moins dans tout ce qui touche aux webservices, aux
DAO ou aux Views. Ainsi, nous n’avions pas vraiment d’idées précises sur comment nous allions
instancier ces parties. En revanche, nous avons très vite compris le sujet et la façon dont nous
allions coder le jeu en lui-même, donc ce qui allait devenir la partie Métier de notre code. En
effet, dès la première séance tous ensemble, nous avons eu une idée précise de comment générer
les articles et comment dérouler une partie. D’ailleurs, les premiers jets de nos diagrammes de
cas d’utilisation et d’activité n’ont été que très peu modifiés par la suite.
En ce qui concerne les autres parties, nous avons au fur et à mesure des cours et TP de
Compléments d’Informatique eu une meilleure vision sur l’intégralité de l’architecture de notre
code. Grâce à cela, nous avons pu produire un diagramme de classes pour le rapport intermé-
diaire qui a lui aussi été très peu modifié à la lumière de la mise en place de l’implémentation.
Ce qui nous a posé le plus de problèmes a été la partie Service de notre application. En effet,
pendant la première partie du projet, nous avions du mal à cerner le rôle concret des classes
qu’elle contient. Mais finalement, après réflexion, nous avons réussi à la coder et à ce que tout
fonctionne correctement. Aussi, le fait de devoir lier les différente parties du code (View, Service,
DAO, Métier) n’a pas été évident pour nous, car nous n’en avions pas l’habitude. Travailler sur
ce point nous a notamment permis d’avoir une meilleure vision d’ensemble de notre application,
ce qui a été très utile.
Ainsi, l’architecture finale de notre programme est proche de ce à quoi nous nous attendions
au début, tout en contenant des méthodes dont nous avons compris l’utilité durant leur implé-
mentation.
Toutefois, quelques points auraient pu être améliorés, ou bien ajoutés à notre code dans la
perspective de le perfectionner et d’ajouter des fonctionnalités optionnelles. C’est principale-
ment par manque de temps que ce qui va être cité par la suite n’a pas été implémenté.
Tout d’abord, les indices que nous proposons pourraient être améliorés, dans la mesure où,
parfois, des indices non pertinents sont proposés. Cela vient du fait que les mots les plus fré-
quents d’une page ne sont pas toujours liés au mot à trouver (mots de liaison, verbes, ...). Nous
avons mis au point une liste des mots à ne pas prendre en compte en tant qu’indices, en plus
des mots trop courts, mais cette liste ne peut pas être exhaustive car faite à la main. Peut-être
aurions nous pu automatiser la détection d’indices non-pertinents, mais nous n’avons pas pu
27
CHAPITRE 6. BILAN ET PISTES D’AMÉLIORATION
approfondir cette question dans les délais.
D’autre part, nous aurions aimé proposer un classement des joueurs connectés en fonction
de leur score, classement qui aurait été visible par l’ensemble des utilisateurs du jeu. Nous re-
grettons de ne pas avoir eu le temps de l’implémenter car cette fonctionnalité aurait ajouté du
challenge à notre jeu. De plus, nous voulions aussi calculer les scores de manière plus complexe.
En effet, actuellement, le joueur part avec un score de 100 points, dont on en retranche 10 à
chaque indice donné. Quelques idées pour calculer ce score différemment ont été évoquées, de
façon à ce qu’il soit rare que plusieurs joueurs aient le même score, mais nous n’avons pas eu
l’occasion de les mettre en place.
De plus, nous voulions au départ implémenter un maximum des fonctionnalités optionnelles

proposées dans le sujet, comme par exemple le mode deux joueurs ou le choix de la langue de
jeu. Malheureusement, ces fonctionnalités n’ont jamais vu le jour. Néanmoins, nous avons eu
le temps d’intégrer quelques unes de ces fonctionnalités optionnelles, telles que la détection des
articles injouables.
Pour finir, nous avions pensé à réaliser une interface graphique à la toute fin du projet,
cela aurait rendu notre application beaucoup plus esthétique qu’actuellement, mais nous avons
abandonné l’idée car ce n’était pas du tout une attente du sujet.
Ainsi, outre quelques difficultés et un manque de temps sur la fin pour perfectionner notre
code, notre application répond à toutes les demandes du sujet et marche de façon satisfaisante.
6.2 L’organisation
De manière générale, l’organisation au sein du groupe a été fluide et efficace. Chacun savait
ce qu’il avait à faire, et effectuait son travail dans les délais. Des réunions pour faire un point
sur l’avancé des travaux étaient mises en place régulièrement, à savoir toutes les semaines, sauf
les semaines de partiels.
Tout au long du projet, les tâches ont été réparties de façon à ce que chacun travaille sur
ce qui l’intéresse le plus, et là où il a le plus de facilités. Cette organisation a permis de rendre
le travail le plus agréable possible pour tous. En revanche, cette organisation aurait pu être
améliorée dans la mesure où il y avait toujours des tâches qui n’étaient les plus intéressantes
pour personne, et qui ont donc été réalisées au dernier moment.
Il nous arrivait parfois de bloquer sur un point particulier, mais en demandant de l’aide et
en nous entraidant au sein du groupe, nous avons pu surmonter toutes les difficultés auxquelles
nous avons été confrontés.
Malgré tout, le projet a été fini dans les temps, et nous sommes satisfaits de notre rendu
car il répond à toutes les attentes que nous avions et a été réalisé dans de bonnes conditions.

Chapitre 7
Conclusion
En conclusion, notre application est un mélange entre le jeu télévisé pyramide et du jeu le
philosophe. Les deux premières phases du projet nous ont permis de modéliser notre application
avec un cahier des charges et différents diagrammes, mais surtout de nous donner une première
idée du sujet et de nous familiariser avec avant la phase suivante. Grâce à cette première phase,
nous avons ensuite pu coder efficacement l’application qui permet de jouer à ce jeu. Toutes les
étapes qui nous ont amené à ce rendu final sont détaillées dans ce rapport.
À travers ce projet, nous espérions tous réussir à acquérir de nouvelles capacités autant
au niveau technique qu’humain, et cela a été le cas. Le travail en groupe, dont nous n’avons
pas choisi les membres, nous permet de simuler le monde entrepreneurial, où nos collègues
nous seront imposés. L’ensemble du projet s’est très bien déroulé, avec un groupe actif et des
membres travailleurs. Grâce à la complémentarité des membres de l’équipe, et à l’investissement
de chacun, les principaux objectifs que nous nous étions fixés ont été atteints avec succès, c’est
pourquoi nous sommes fiers de notre travail sur ce projet.
Certes, nous aurions pu aller plus loin, et quelques pistes d’amélioration ont été proposées,
mais nous considérons que le travail que nous rendons est largement satisfaisant dans la mesure
où le jeu est ludique et fonctionnel, et du point de vue technique, nous avons su trouver des
solutions pour par exemple générer des indices pertinents, gérer l’intéraction entre le joueur et
l’application, stocker les informations à conserver, et même prendre en compte les potentielles
fautes de frappe des utilisateurs dans leurs réponses. Ainsi, même si nous regrettons de n’avoir
pu mettre en œuvre la totalité des fonctionnalités que nous aurions voulu, le travail accompli
tout au long du projet, et la réussite qui en a découlée, nous ont fait apprécier ce projet dans
sa globalité.
29
Chapitre 8
Notes individuelles
8.1 Mohamed ASSILI

Le projet informatique de cette a été une bonne formation pour moi qui m’a permis d’amé-
liorer mes compétences de programmation. Je me suis occupé de plusieurs parties de code et
j’ai contribué aussi dans la rédaction du rapport.
Durant la première partie du projet, je me suis occupé du diagramme de classe. Au début, il

n’était pas évident à réaliser vu qu’il devait prendre la forme d’un MVC (Modèle-vue-contrôleur)
alors que je ne suis pas habitué à faire un tel diagramme de classe. Cela, m’a poussé à demander
de l’aide de la part de notre tuteur et de monsieur Rémi Pepin qui nous a énormement aider
à le faire tout en nous nous éclaircissant cette nouvelle notion. Ainsi cela a permis d’avoir un
rapport intermédiaire répondant à tous nos attentes.
Ensuite, durant la partie du code je me suis occupé en premier lieu des packages View et
Service. Le code des classes view était un peu complexe à faire vu que d’une part fallait gérer
plusieurs cas particuliers surtout dans la GameView, d’autre part fallait aussi gérer l’authen-
tification des joueurs. Pour la partie Service, elle était réalisé afin que la GameView peut s’en
servir de ses méthodes. Je me suis aussi retrouvé à refaire les classes DAO que mon collègue
Wajih a commencé et à rajouter des méthodes qui m’ont servit dans les vues permettant la
connexion et l’inscription des joueurs.
Ainsi, ce projet était l’occasion que j’apprenne Git. Contrairement, à l’année dernière où
personne de notre groupe savait comment l’utiliser et se trouvait obligé à créer des version de
code à la main ce qui réduisait l’efficacité du travail.
En ce qui concerne mon ressenti, j’ai trouvé que le travail en groupe était agréable chacun
d’entre nous connaissait ses tâches et arrivait à les realiser dans les délais. Et ce que j’ai beau-
coup apprécié c’était l’entraide au sein du groupe vu qu’à chaque fois qu’un membre bloquait
dans une partie on essayait tous d’agir afin de résoudre le problème le plus tôt possible.
Enfin, comme j’avais mentionné tout en haut, ce projet m’a été d’une grande utilité vu qu’il
m’a permis de progresser terme de progrommation orienté objet. Et je le considère comme une
bonne expérience qui me rapporterait beaucoup de bénefices durant ma carrière professionnelle.
30
CHAPITRE 8. NOTES INDIVIDUELLES
8.2 Cédric GRANDVAUX

J’étais très impatient à l’idée de réaliser le projet informatique de deuxième année, d’une
pafrt parce que j’aime beaucoup la programmation, d’autre part parce qu’implémenter une
application dans son entièreté représentait un réel challenge. J’ai donc voulu m’engager dans
toutes les phases du projet.
Ainsi, au début du projet j’ai participé avec tous les autres membres du groupes à l’élabora-
tion du cahier des charges et à la rédaction du dossier d’analyse. Puis une fois ce dossier rendu,
je me suis concentré sur le code notamment avec la création le dépôt du git, j’ai contribué à
l’implémentation de la DAO et de certaines views, j’ai ajouté le gitignore et le singleton.
Enfin, j’ai participé à la rédaction du rapport final et à la conception ou modification des
diagrammes UML. J’ai aussi nettoyé le code (suppression des espaces et des lignes superflus) et
j’ai rédigé le README, créé le requirements et ajouter la banière de démarrage.
Cependant, ce n’était pas seulement un rendu informatique, mais bien un projet de groupe.
C’est pourquoi au-delà des acquis théoriques et de la pratique de la programmation, je retire
des enseignements concernant la gestion de projet.
C’était par exemple très important pour moi de maintenir un lien entre les différentes séances
de suivi, et notamment lors des vacances. J’ai donc proposé des réunions Teams pendant les
vacances pour que nous puissions faire des points sur l’avancement de nos tâches, et que per-
sonne ne perde le fil.
J’ai bien aimé la diversité des tâches que j’ai effectué, c’est à dire faire un peu de code mais
aussi programmer des réunions de groupes et vérifier au bon avancement du projet. C’est une
différence majeure du projet informatique de première année, lors duquel j’avais énormément
codé mais sans profiter du fait d’être en groupe. J’utiliserai cette position multi-tâche dans tous
mes futurs projets car elle me correspond mieux qu’une position trop spécialisée. De plus, je
pense que ça m’a permis parfois de prendre du recul par rapport au code, et paradoxalement
de réussir à le rendre plus efficace.
D’un point de vue personnel, j’ai eu du mal au début à comprendre comment mettre en
place le motif modèle-vue-contrôleur. Le fait de réaliser l’application m’a permis de pousser plus
loin les connaissances exposées en CM et TP de compléments d’informatique, et de réellement
les assimiler.
Comme évoqué ci-dessus, j’ai pu découvrir la gestion de projet. Une chose que je voudrai
changer est peut être l’utilisation du diagramme de Gantt que j’ai eue. Il a été rédigé lors du
dossier d’analyse, mais nous nous sommes vite laissés dépasser par le quotidien. Je pense qu’il
serait intéressant d’inclure ce diagramme dans un planning plus global, avec les échéances sco-
laires et personnelles. Cela me permettrait de gagner en efficacité, en organisation, mais aussi
d’avoir une vue globale du projet et du code, de son avancement.
Le projet de groupe s’est dans l’ensemble bien passé, je n’ai pas observé de tensions parti-
culières dans le groupe car tout le monde était actif dans le groupe et tout le monde pouvait
trouver de l’aide dès qu’il en avait besoin.

8.3 Wajih HAMMOUDA

En tant qu’étudiant étranger admis sur titre ce projet m’avait beaucoup aidé à améliorer
mon niveau à programmer en Python et l’importance de conception d’une part et intégrer l’EN-
SAI d’une autre part.
Au début, j’étais un peu sceptique sur la conception et j’ai sous-estimé son rôle mais au cours
du projet j’ai réalisé son importance surtout sur le plan d’organisation de code et répartition
des travaux ( les parties que nous avons bien conçues ont été les parties les plus faciles à coder
et générer le moins de problèmes).
Côté code, j’ai contribué dans tous les classes sauf les tests. En premier temps, j’ai commencé
à coder les DAO mais après Mohamed les est modifié. Après, j’ai codé la méthode qui permet
de retourner un dictionnaire de mots avec leur nombre d’occurrences ( frequentswords ) pour
donner les mots qui se répètent le plus comme des indices ( l’idée de Lorenzo ). J’ai également
codé la méthode qui permet de donner les indices aux joueurs. Finalement, j’ai codé startview
et signupview.
J’avais d’autres idées à ajouter dans les méthodes getclue et frequentswords pour optimiser
les indices mais je les ai pas codés principalement parce que j’ai commis une erreur de git ven-
dredi soir que nous a perdu beaucoup du temps ( j’ai fait un push d’une version ancienne du
code alors que le pull n’a pas passé avant). Grâce à Lorenzo et Mohamed, la version correcte
du code était restaurée.
Chacun entre nous avait un rôle clair et important à jouer. Cédric et Tissine ont organisé
des réunions et répartit les tâches avec des dates limites pour qu’on respecte les délais et ils
ont bien documenté la plupart du code et beaucoup avancé le rapport. Lorenzo avait beaucoup
d’idées et une vision pour le projet ce qui a accéléré à l’avancement du code. Mohamed était
persistant et rigoureux jusqu’à la fin pour que le code marche impeccablement.
Enfin, ce projet a été ma première expérience de travail en équipe et je suis fier que cette
première expérience ait été avec ce groupe et qu’elle ait été couronnée de succès.

8.4 Lorenzo MATHIEU

J’attendais beaucoup de ce projet informatique. Je n’ai pas été déçu. En effet c’était pour
moi la première fois que je m’investissais pour le développement d’une application jusqu’à son
terme. En effet j’ai jusqu’ici coder quelques mini-programmes mais rien de vraiment important.
Le projet informatique de l’année dernière n’était pas aussi intéressant. J’aurais aimé avoir plus
de temps pour développer d’avantages de fonctionnalités ou corriger certaines imperfections
qui persistent mais la deuxième année demande trop de travail personnel pour que je puisse
m’investir plus...
J’ai développé la majeure partie de la partie métier, et plus particulièrement les classes
Article et ArticleGénération sur lesquelles je devais apporter du soin car elles étaient la base
de toute chose pour notre projet. J’ai modifié quelques lignes de code dans les views et fait les
tests des classes Article et ArticleGeneration. Les tests m’ont posé problème car les éléments
étaient pratiquement tous aléatoire. J’ai du créé une classe Mock pour pouvoir contrôler cela.
Ces problèmes m’auront apporté pas mal de connaissances. En effet j’ai pu discuter avec le
tuteur des notions d’injection de dépendances et d’inversion de contrôle. J’ai aussi pu mettre
en place de fonction de normalisation et de similarité pour les chaînes de caractères.
J’ai apprécié travailler avec ce groupe. En effet chacun a pu faire ce qui lui plaisait au niveau
du code et l’entente était bonne. Le niveau en informatique était assez hétérogène mais chaque
personne a su s’investir du mieux qu’il pouvait avec ses compétences. J’ai surtout été utile dans
ce groupe en tant que développeur. En effet cela a presque été mon unique fonction avec la
rédaction de quelques parties dans le rapport final.
Pour conclure, je voudrais dire que je suis heureux du travail que l’on rend même si j’aurais
aimé avoir quelques semaines en plus pour pouvoir ajouter des fonctionnalités telles que la
difficulté du jeu ou encore la langue. La qualité des indices laissent parfois à désirer et avec plus
de temps nous aurions pu régler ce problème. Ce projet m’aidera, j’en suis sur à l’avenir pour
d’autres projets que j’entreprendrai.

8.5 Tissine PICHON

Ce projet informatique, qui s’est déroulé de début septembre à fin novembre 2022, a été
une expérience enrichissante sur plusieurs plans. Pour commencer, un aspect essentiel de ce
projet a été la gestion du travail en groupe, d’autant plus que nous n’avions jamais travaillé
avec autant de personnes sur un projet. Cependant, les membres du groupe m’ont tout de suite
paru très motivés, ce qui m’a rassurée sur notre capacité à réussir. J’ai eu la chance d’avoir un
groupe dans lequel il n’y a jamais eu aucune tension, et je tiens à remercier mes coéquipiers
pour cela. Ainsi, le travail collectif a toujours été agréable et fluide. Je me suis proposée pour
assurer le rôle de chef de projet, car je pensais être compétente en termes de gestion de délais,
d’organisation et de communication. Au final, en dehors du remplissage des fiches de suivi heb-
domadaires, ce rôle n’a apporté que très peu de contraintes car les membres du groupe étaient
très autonomes et travailleurs. Pour l’ensemble de l’équipe, mener à terme ce projet dans les
délais et en respectant toutes les contraintes a été un réel challenge, mais nous avons toujours
été là les uns pour les autres quand il s’agissait de s’entraider.
Concernant la partie technique du projet, j’avais un peu d’appréhension à propos de mon

niveau en informatique vis-à-vis de la complexité de ce qu’on nous demandait de produire. En
particulier, au commencement du projet, j’avais une vision très floue de plusieurs concepts pour-
tant centraux pour ce projet, notamment les bases de données SQL liées à Python ou encore
les Views. Heureusement, mes coéquipiers étaient là pour se charger des parties qui me sem-
blaient les plus compliquées. La répartition des tâches a été faite de sorte à ce que chacun fasse
quelque chose qui l’intéresse, afin de ne pas associer le travail lié au projet à une contrainte trop
importante et de prendre du plaisir. Mes principales tâches étaient l’élaboration des rapports
(rapport final et rapport intermédiaire), dans lesquels j’ai assuré une grande partie de la rédac-
tion, ainsi que l’élaboration des diagrammes et du cahier des charges en début de projet. En
termes de code, j’ai contribué à l’implémentation d’une partie des Views, à quelques méthodes
du package Métier qui n’ont finalement pas été utilisées, ainsi qu’à certains premiers tests. En
plus de cela, j’ai rédigé beaucoup de documentation, même pour des méthodes que je n’avais
pas implémentées. L’implémentation du code a été la plus difficile pour moi. Souvent, je n’avais
pas d’idée précise sur comment m’y prendre, en particulier lorsqu’il s’agissait de méthodes avec
lesquelles je n’étais pas familière, les Views par exemple. Ce qui m’a permis d’aller au bout du
code que je devais produire est, je pense, d’avoir été très investie dans le projet informatique de
l’année dernière. Grâce à cette expérience, j’ai appris qu’il fallait persévérer, même si la tâche
à réaliser paraît insurmontable : à force de travail et de détermination, on finit par s’en sortir.
En effet, l’année dernière, j’avais passée beaucoup de temps à coder avant d’y arriver, et cela
m’a été très profitable pour ce projet.
Pour finir, si je devais donner des conseils à des étudiants sur le point de commencer le
projet informatique, je dirais qu’il est important de bien répartir les tâches au sein du groupe,
afin que personne ne soit laissé de côté. De plus, il ne faut pas hésiter à essayer, même si on
ne se sent pas à la hauteur, quitte à demander de l’aide. C’est le meilleur moyen de progresser
et de tirer le plus possible de ce type de projet. Enfin, suivre assidûment les cours et TP de
Compléments d’Informatique est un véritable atout dans la compréhension du projet.

Chapitre 9
Annexes
Figure 9.1 – Diagramme de classes complet
35

Projet Info 2A

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Projet Info 2A

Transféré par

Droits d'auteur :

Formats disponibles

École nationale de la statistique

Projet d’Informatique 2A - ENSAI 1 Groupe 17

2 Étude préalable et organisation 5

5 Guide d’utilisation de l’application 23

6 Bilan et pistes d’amélioration 27

Projet d’Informatique 2A - ENSAI 3 Groupe 17

Étude préalable et organisation

2.1 Présentation du système et besoins à satisfaire

2.2 Diagramme de cas d’utilisation

Figure 2.1 – Diagramme de cas d’utilisation de notre logiciel

Projet d’Informatique 2A - ENSAI 6 Groupe 17

2.3 Gestion prévisionnelle des tâches

Figure 2.2 – Diagramme de GANTT

Enfin la dernière phase du projet a été la préparation du livrable et de la soutenance, pendant

Projet d’Informatique 2A - ENSAI 7 Groupe 17

Projet d’Informatique 2A - ENSAI 8 Groupe 17

3.1 Diagramme d’activité

Figure 3.1 – Diagramme d’activité de notre logiciel

Projet d’Informatique 2A - ENSAI 10 Groupe 17

3.2 Diagramme de séquence

Figure 3.2 – Diagramme de séquence de notre logiciel

Pour commencer, si l’utilisateur veut se créer un compte, l’interface va prendre en compte sa

Si le joueur a déjà un compte et souhaite s’identifier, de la même façon les informations

Projet d’Informatique 2A - ENSAI 11 Groupe 17

rectes, l’authentification est réussie et le joueur peut poursuivre.

3.3 Diagramme de classes

— Une partie Métier

Projet d’Informatique 2A - ENSAI 12 Groupe 17

3.3.1 Package Métier

Figure 3.3 – Package Métier

Les différentes classes de ce package sont détaillées ci-dessous :

Projet d’Informatique 2A - ENSAI 13 Groupe 17

3.3.2 Package DAO

Figure 3.4 – Package DAO

Ce package contient les classes implémentant des requêtes SQL :

Projet d’Informatique 2A - ENSAI 14 Groupe 17

3.3.3 Package View

Figure 3.5 – Package View

Projet d’Informatique 2A - ENSAI 15 Groupe 17

3.3.4 Package Service

Figure 3.6 – Package Service

Le package Service permet d’orchestrer le jeu. En effet, la classe GameService permet

En comparaison au rapport intermédiaire, nous avons supprimé les classes HistoryService et

3.4 Modèle physique de données

Figure 3.7 – Modèle physique de données

Projet d’Informatique 2A - ENSAI 16 Groupe 17

3.5 Principe de l’API

Pour ce qui est des méthodes utiles nous avons :

Projet d’Informatique 2A - ENSAI 17 Groupe 17

4.1 Génération des parties

4.1.2 Génération des indices

— Les portails vers lesquels mène l’article.

4.1.3 Mise en place d’une partie

La méthode play_game() dans la classe GameView s’occupe du déroulement de la partie

Figure 4.1 – Boucle While dans la méthode play_game()

La méthode similar() permet de vérifier la similarité entre le nom de l’article et la réponse

4.2 Utilisation des bases de données

Projet d’Informatique 2A - ENSAI 19 Groupe 17

Figure 4.2 – Table Players

La méthode utilisée pour le hashage du mot de passe est generate_password_hashest prise

4.2.2 Consultation de l’historique

Figure 4.3 – Table History

Projet d’Informatique 2A - ENSAI 20 Groupe 17

4.3 Fichier main.py