diff --git a/trivial-doc/modules/developement/examples/cd-domain-model.plantuml b/trivial-doc/modules/developement/examples/cd-domain-model.plantuml
index 44dba6aa79c863e503496d4913767864f041812b..07c2f80a0ce54ce43c706fa9a35c932f230605ec 100644
--- a/trivial-doc/modules/developement/examples/cd-domain-model.plantuml
+++ b/trivial-doc/modules/developement/examples/cd-domain-model.plantuml
@@ -1,6 +1,70 @@
 @startuml
-!include cd-plateau-cases.plantuml
-!include cd-cartes-questions-reponses.plantuml
+class Carte
+class Question {
+    intitulé : String [1]
+}
+class Réponse {
+    réponse : String [1]
+}
 
-class Base
+Carte *-left- "[6] questions" Question : \t\t\t\t\t
+Carte *-- "[6] réponses" Réponse
+Question "[1]" -- "[1]" Réponse
+
+class Plateau
+abstract class Case <<abstract>> {
+    nom : String
+    couleur : Couleur
+}
+
+class "Quartier Général" as quartier
+class "Case Simple" as simple
+class "Case Initiale" as initiale
+
+class Catégorie {
+    thème : Thème
+
+}
+
+enum Thème {
+    Géographie
+    Divertissements
+    Histoire
+    Arts et Littérature
+    Sciences et Nature
+    Sports et Loisirs
+}
+
+enum Couleur {
+    Bleu
+    Rose
+    Jaune
+    Vert
+    Violet
+    Orange
+}
+
+Plateau *- "cases [72]" Case : \t\t\t\t\t\t
+Plateau --> "début [1]" initiale : \t\t\t\t\t\t
+simple --> "catégorie [1]" Catégorie
+quartier --> "catégorie [1]" Catégorie
+Case <|-- quartier
+Case <|-- simple
+Case <|-- initiale
+Case --> "voisins [2..6] " Case : \t\t\t\t\t\t
+
+class Partie {
+    nom : String
+}
+
+class Joueur {
+    identifiant : String
+    pion : Couleur
+}
+
+Partie *-> "joueurs\n[2..6]" Joueur : \t\t
+Partie -> "actif [1]" Joueur : \t\t
+Partie --> "[1]" Plateau
+Joueur --> "[1]" Case
+Plateau -left-> "[400]" Carte
 @enduml
\ No newline at end of file
diff --git a/trivial-doc/modules/developement/examples/cd-parties-joueurs.plantuml b/trivial-doc/modules/developement/examples/cd-parties-joueurs.plantuml
new file mode 100644
index 0000000000000000000000000000000000000000..b7b20c234485bd6308fbc9f1b4b032186ee4da0a
--- /dev/null
+++ b/trivial-doc/modules/developement/examples/cd-parties-joueurs.plantuml
@@ -0,0 +1,13 @@
+@startuml
+class Partie {
+    nom : String
+}
+
+class Joueur {
+    identifiant : String
+}
+
+Partie *-> "joueurs\n[2..6]" Joueur : \t\t
+Partie -> "actif [1]" Joueur : \t\t
+Partie --> "[1]" Plateau
+@enduml
\ No newline at end of file
diff --git a/trivial-doc/modules/developement/examples/deployment-diagram.puml b/trivial-doc/modules/developement/examples/deployment-diagram.puml
index df2a5b932f7434d2c567997adc9c5743f8304608..64508500667b1d379c953482c09c388784f15a3c 100644
--- a/trivial-doc/modules/developement/examples/deployment-diagram.puml
+++ b/trivial-doc/modules/developement/examples/deployment-diagram.puml
@@ -1,17 +1,17 @@
 @startuml
 
-node Client {
-    artifact WebClient
+node Navigateur {
+    artifact WebClient as "Client Web"
 }
 node Server {
-    artifact GameServer
+    artifact GameServer as "Serveur TP"
 }
 
 node Database {
-    artifact DBMS
+    artifact DBMS as "SGBD"
 }
 
-WebClient -left- Server : TCP/IP - WebSockets
-Server -up- Database : JPA
+WebClient -right- Server : \t TCP/IP - WebSockets
+GameServer -up- DBMS : JDBC
 
 @enduml
\ No newline at end of file
diff --git a/trivial-doc/modules/developement/pages/analyse-domaine.adoc b/trivial-doc/modules/developement/pages/analyse-domaine.adoc
index eb19a7f9c535f90c22ee052c0c6fbff411af2a74..29324e376694f98b09e03dbf78569b5d47a48bec 100644
--- a/trivial-doc/modules/developement/pages/analyse-domaine.adoc
+++ b/trivial-doc/modules/developement/pages/analyse-domaine.adoc
@@ -25,7 +25,7 @@ Il ne doit pas faire référence à des implémentations techniques telles que d
 
 *{project}* est un jeu de plateau, dans lequel le progrès est déterminé par la capacité d'un joueur à répondre aux questions de culture générale. 
 
-Le jeu est composé d'un plateau de jeu, de 400 cartes de questions, de 6 pions xref:termes.adoc#Camembert[camembert], de 36 xref:termes.adoc#Triangle[triangles] de couleurs différentes et d'un dé.
+Le jeu est composé d'un plateau de jeu, de 400 cartes de questions, de 6 pions xref:termes.adoc#camembert[camembert], de 36 xref:termes.adoc#triangle[triangles] de couleurs différentes et d'un dé.
 
 Les questions sont réparties en 6 catégories différentes, 
 synthétisées dans le tableau ci-dessous{nbsp}:
@@ -60,9 +60,10 @@ synthétisées dans le tableau ci-dessous{nbsp}:
 Un plateau est composé d'une case début et de 72 cases de couleurs différentes.
 Il se présente sous la forme d'une roue avec 1 cercle extérieur et 6 rayons.
 
-Au centre,  à l'intersection des rayions, se trouve la case Départ.
-Aux 6 intersections des rayons avec le cercle se trouvent 6 cases "Quartiers Généraux de Catégorie", sur lesquelles est dessiné à chaque fois un gros triangle de couleur différente.
-
+Au centre,  à l'intersection des rayons, se trouve la case Départ.
+Aux 6 intersections des rayons avec le cercle se trouvent 6 cases "Quartiers Généraux de Catégorie".
+Chacune des 6 cases "Quartier Général" représente une catégorie différence et
+contient un gros triangle de couleur correspondant à la couleur de sa catégorie.
 
 .Plateau et Cases
 [plantuml, cd-plateau-cases]
@@ -86,7 +87,16 @@ inv: self.voisins->forAll(each | each.voisins->contains(self))
 include::example$cd-cartes-questions-reponses.plantuml[]
 ....
 
-// TODO
+=== Parties et Joueurs
+
+Une partie est constituée d'un plateau, de 2 à 6 joueurs, 400 cartes,
+
+.Parties et Joueurs
+[plantuml, cd-parties-joueurs]
+....
+include::example$cd-parties-joueurs.plantuml[]
+....
+
 
 
 == Modèle du domaine
diff --git a/trivial-doc/modules/developement/pages/architecture.adoc b/trivial-doc/modules/developement/pages/architecture.adoc
index aae5fdc05bddd67ff4537418cd44e9e971b3b743..08429f622edda8d681ef47f386beb1bf3856243c 100644
--- a/trivial-doc/modules/developement/pages/architecture.adoc
+++ b/trivial-doc/modules/developement/pages/architecture.adoc
@@ -1,4 +1,4 @@
-:project: 7 Wonders
+:project: Trivial Pursuit
 = Architecture
 
 == Introduction
diff --git a/trivial-doc/modules/developement/pages/exigences.adoc b/trivial-doc/modules/developement/pages/exigences.adoc
index a1bec130430e5e0db89b1e0e7337fc997ea41967..91c244807460e56037f6b6be19a568e3b6229181 100644
--- a/trivial-doc/modules/developement/pages/exigences.adoc
+++ b/trivial-doc/modules/developement/pages/exigences.adoc
@@ -1,34 +1,55 @@
 :project: Trivial Pursuit
-
 = Spécification des exigences
 
 == Introduction 
 
-Ce chapitre décrit les exigences du projet «{project}». Il suit la norme IEEE 830-1998.
+Ce chapitre décrit les exigences du projet «{project}». Il suit la norme ISO/IEC/IEEE https://ieeexplore.ieee.org/document/8559686[29148-2018].
 
-=== Avant-propos
 
-NOTE: Identifier le produit dont les exigences logicielles sont spécifiées dans ce document, y compris le numéro de révision ou de version. Décrire l'étendue du produit couvert par ce SRS, en particulier si ce SRS ne décrit qu'une partie du système ou un seul sous-système.
+=== Avant-propos
 
 L'objectif de ce document est de décrire les spécifications des exigences du projet "{project}" pour les étudiants en génie logiciel.
 
 Le public visé par cette spécification comprend les développeurs potentiels de l'application, ainsi que les personnes chargées de l'évaluation technique.
 
-
 === Définitions, acronymes et abréviations
 
-NOTE: Décrivez toutes les normes ou conventions typographiques qui ont été suivies lors de la rédaction de ce SRS, telles que les polices de caractères ou les mises en évidence qui ont une signification particulière. Par exemple, indiquez si les priorités des exigences de niveau supérieur sont supposées être héritées par les exigences détaillées, ou si chaque énoncé d'exigence doit avoir sa propre priorité.
+Norme ISO/IEC/IEEE 29148-2018:: Ingénierie des systèmes et du logiciel -- Processus du cycle de vie -- Ingénierie des exigences
 
-Aucune jusqu'à présent.
+SRS:: _Software Requirements Specification_, Spécification des Exigences Logicielles
 
-=== Public visé et suggestions de lecture
+// NOTE: Décrivez toutes les normes ou conventions typographiques qui ont été suivies lors de la rédaction de ce SRS, telles que les polices de caractères ou les mises en évidence qui ont une signification particulière. Par exemple, indiquez si les priorités des exigences de niveau supérieur sont supposées être héritées par les exigences détaillées, ou si chaque énoncé d'exigence doit avoir sa propre priorité.
 
-[NOTE]
-====
-Décrire les différents types de lecteurs auxquels le document est destiné, tels que les développeurs, les chefs de projet, le personnel du marketing, les utilisateurs, les testeurs et les rédacteurs de la documentation. 
+.Acronymes
+[%header]
+|===
+| Acronyme | Description
 
-Décrivez le contenu et l'organisation du reste de ce SRS. Suggérer un ordre de lecture du document, en commençant par les sections d'aperçu et en poursuivant par les sections les plus pertinentes pour chaque type de lecteur.
-====
+| JDBC
+| Java DataBase Connectivity
+
+| JPA
+| Java Persistence API
+
+| SGBD
+| Système de Gestion de Bases de Données
+
+|===
+
+.Définitions
+[%header]
+|===
+
+| Terme | Définition
+
+| WebSockets
+| Protocole servant à établir des connexions TCP persistantes entre _serveurs_ et _clients_
+
+|===
+
+=== Public visé et suggestions de lecture
+
+Ce document est à la destination des étudiants de première année du Master Informatique de Nantes Université.
 
 === Portée du projet
 
@@ -40,18 +61,17 @@ Le système {project} permettra à des joueurs de différents endroits de s'affr
 
 === Références
 
-. IEEE Standard 830-1993: IEEE Recommended Practice for Software Requirements Specifications
+. «IEEE Standard 830-1993: IEEE Recommended Practice for Software Requirements Specifications»
 
-[TIP]
-====
-Énumérez tous les autres documents ou adresses Web auxquels ce SRS fait référence. 
-Il peut s'agir de guides de style d'interface utilisateur, de contrats, de normes, de spécifications des exigences du système, de documents de cas d'utilisation ou d'un document sur la vision et la portée. 
-Fournissez suffisamment d'informations pour que le lecteur puisse accéder à une copie de chaque référence, notamment le titre, l'auteur, le numéro de version, la date et la source ou l'emplacement.
-====
+. «Trivial Pursuit -- Genus Edition». Horn Abbot International Limited
+
+. Trivial Pursuit. Article https://fr.wikipedia.org/wiki/Trivial_Pursuit[Wikipedia]
+
+. Les règles du jeu{nbsp}: Trivial Pursuit. https://www.ribambel.com/article/les-regles-du-jeu-trivial-pursuit/5640[Ribambel]
 
 === Vue d’ensemble 
 
-Le reste de ce document contient une description globale du système logiciel {project} (section <<description>>, les exigences fonctionnelles spécifiques (section <<fonctional>>) et les exigences non-fonctionnelles du système (voir <<nonfonctional>>.
+Le reste de ce document contient une description globale du système logiciel {project} (section <<description>>, les exigences fonctionnelles spécifiques (section <<functional>>) et les exigences non-fonctionnelles du système (voir <<nonfunctional>>.
 
 == Organisation du chapitre
 
@@ -60,23 +80,21 @@ Le reste de ce document contient une description globale du système logiciel {p
 
 === Perspectives du produit
 
-{project} est un jeu de cartes où plusieurs joueurs s'affrontent.
+{project} est un jeu de plateau où plusieurs joueurs s'affrontent.
 Le logiciel {project} doit permettre aux joueurs qui sont connectés à Internet d'utiliser leurs appareils connectés pour jouer.
-Ainsi, "{project}" est une version électronique en ligne du jeu de cartes.
+Ainsi, "{project}" est une version électronique en ligne du jeu de plateau.
 
 Bien que le système soit distribué et organisé en différents composants, les joueurs doivent le percevoir comme un seul logiciel.
-La figure <<deployment>> présente l'architecture globale du logiciel.
-Les joueurs interagissent avec un client Web, qui utilise le protocole HTTP pour communiquer avec (au maximum) un serveur de jeu.
-Les serveurs utilisent le protocole TCP/IP pour communiquer avec un serveur de gestion de base de données, qui stocke toutes les données du logiciel.
+La <<deployment>> présente l'architecture globale préconisée du logiciel.
+Il est organisé en trois nœuds logiques distincts.
+Le nœud `Navigateur` contient les artefacts nécessaires à l'exécution du `Client Web`.
+Ce client utilise des _WebSockets_ pour communiquer avec l'artefact `Serveur TP`, déployé sur le nœud `Serveur`.
 
-[NOTE]
-====
-Améliorez le diagramme de déploiement pour qu'il représente le système que vous allez développer.
+Le nœud `Serveur` contient tous les artefacts nécessaires à la gestion de plusieurs parties du jeu.
+Le `Serveur TP` utilise JDBC pour interroger le `SGBD`, qui stocke toutes les données du logiciel.
+Le `SGBD` déployé sur le nœud `Database`.
 
-Pour plus de détails sur les diagrammes de déploiement{nbsp}:
-
-* https://www.uml-diagrams.org/deployment-diagrams-overview.html
-====
+Les joueurs interagissent avec le `Client Web`, qui utilise le protocole les WebSockets pour communiquer avec (au maximum) un serveur de jeu.
 
 [#deployment]
 .UML Diagramme de déploiement 
@@ -85,79 +103,42 @@ Pour plus de détails sur les diagrammes de déploiement{nbsp}:
 include::example$deployment-diagram.puml[]
 ----
 
-[NOTE]
-====
-Décrivez le contexte et l'origine du produit spécifié dans ce SRS.  
-Par exemple, indiquez si ce produit est un membre suivant d'une famille de produits, un remplacement de certains systèmes existants ou un nouveau produit autonome. 
+NOTE: Un *Nœud Logique* est une cible de déploiement qui représente une ressource informatique sur laquelle
+les artefacts peuvent être déployés pour être exécutés. +
+Plusieurs nœuds logiques peuvent s'exécuter sur un même *Nœud Physique* ou *Dispositif*.
 
-Si le SRS définit un composant d'un système plus vaste, faites le lien entre les exigences du système plus vaste et la fonctionnalité de ce logiciel et identifiez les interfaces entre les deux. 
-Un diagramme simple qui montre les principaux composants du système global, les interconnexions des sous-systèmes et les interfaces externes peut être utile.
-====
+{project} sera le premier d'une ligne de produits de type "Jeu de plateau".
+Son architecture servira comme exemple à d'autres produits.
 
 === Fonctionnalités du produit
 
-[NOTE]
-====
-Résumez les principales fonctions que le produit doit exécuter ou doit permettre à l'utilisateur d'exécuter. Les détails seront fournis à la section 3, aussi seul un résumé de haut niveau (comme une liste à puces) est nécessaire ici. 
+Le logiciel {project} doit assurer trois fonctions principales :
 
-Organisez les fonctions de manière à ce qu'elles soient compréhensibles pour tout lecteur du SRS. 
-====
-
-Le logiciel {project} doit assurer deux fonctions principales :
-
-. Création de jeu : permettre à deux joueurs de se découvrir et de commencer une partie.
+. Connexion au serveur{nbsp}: permettre à un joueur de rejoindre un serveur pour ensuite choisir une partie.
+. Création de jeu : permettre aux joueurs de se découvrir et de commencer une partie.
 . Le jeu{nbsp}: permettre aux joueurs de jouer effectivement à {project} jusqu'à la victoire de l'un d'entre eux.
 
-TIP: Il s'agit ici d'une vue générale des fonctionnalités et non de leur description détaillée.
-
-[NOTE]
-====
-Une image des principaux groupes d'exigences connexes et de leurs relations, comme une carte conceptuelle, est souvent utile.
-====
-
-
 === Caractéristiques et classes d'utilisateurs
 
-[NOTE]
-====
-Identifiez les différentes classes d'utilisateurs qui, selon vous, utiliseront ce produit. 
-Les classes d'utilisateurs peuvent être différenciées en fonction de la fréquence d'utilisation, du sous-ensemble de fonctions du produit utilisé, de l'expertise technique, des niveaux de sécurité ou de privilège, du niveau d'éducation ou de l'expérience. 
-Décrivez les caractéristiques pertinentes de chaque classe d'utilisateurs.  Certaines exigences peuvent ne concerner que certaines classes d'utilisateurs. 
-Distinguez les classes d'utilisateurs les plus importantes pour ce produit de celles qui sont moins importantes à satisfaire.
-====
-
-Le logiciel {project} n'a qu'une seule classe d'utilisateurs : les joueurs.
-Les joueurs peuvent avoir différents niveaux : débutants, intermédiaires ou experts.
-Cependant, indépendamment de leur niveau, les joueurs doivent utiliser la même interface utilisateur pour jouer les uns contre les autres.
+Le logiciel {project} a deux classes d'utilisateurs{nbsp}: les joueurs et les administrateurs.
 
-[NOTE]
-====
-TODO: Complétez la description ci-dessus
-====
+Les joueurs peuvent avoir différents niveaux{nbsp}: débutants, intermédiaires ou experts. +
+Cependant, indépendamment de leur niveau, les joueurs utilisent la même interface utilisateur pour jouer les uns contre les autres.
 
-=== Environnement opérationnel
+Les administrateurs peuvent gérer les joueurs et les parties.
 
-NOTE: Décrivez l'environnement dans lequel le logiciel fonctionnera, y compris la plate-forme matérielle, le système d'exploitation et ses versions, ainsi que tout autre composant logiciel ou application avec lequel il doit coexister pacifiquement.
 
-Le logiciel {project} doit fonctionner sur tout système d'exploitation populaire et récent{nbsp}: Linux, Windows, ou MacOS.
-Le client Web devrait fonctionner sur tout navigateur Web récent{nbsp}: Firefox, Chrome, Safari, ou Edge.
+=== Environnement opérationnel
 
-[NOTE]
-====
-TODO: Complétez la description ci-dessus
-====
+Le Serveur doit fonctionner sur tout système d'exploitation populaire et récent{nbsp}: Linux, Windows, ou MacOS.
+Le client Web devrait fonctionner sur tout navigateur Web compatible avec les WebSockets{nbsp}: Firefox (≥ 7.0), Chrome (≥ 5.0), Safari (≥ 5.0), ou Edge (≥ 12.0).
 
 == Contraintes de conception et de mise en œuvre
 
-[NOTE]
-====
-Décrivez tous les éléments ou problèmes qui limiteront les options disponibles pour les développeurs. Il peut s'agir de politiques d'entreprise ou de réglementation, de limitations matérielles (exigences en matière de temps et de mémoire), d'interfaces avec d'autres applications, de technologies, d'outils et de bases de données spécifiques à utiliser, d'opérations parallèles, d'exigences linguistiques, de protocoles de communication, de considérations de sécurité, de conventions de conception ou de normes de programmation (par exemple, si l'organisation du client est responsable de la maintenance du logiciel livré).
-====
-
 === Langages de programmation
 
-. Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le https://spring.io [Spring Framework].
-. Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le https://angular.io [Angular Framework].
+. Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le https://spring.io[Spring Boot] (version ≥{nbsp}3.0.0).
+. Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le https://angular.io[Angular Framework] (version ≥ 16.0).
 
 
 === Langage de conception
@@ -168,96 +149,64 @@ Décrivez tous les éléments ou problèmes qui limiteront les options disponibl
 === Conception
 === Mise en œuvre
 
-. Les tests dynamiques doivent utiliser JUnit (version >= 5.0) et Jasmine (version >= 3.5.0).
-. Le code doit journaliser ses principales opérations en utilisant https://www.slf4j.org [SLF4J].
+. Les tests dynamiques doivent utiliser JUnit Jupiter (version ≥ 5.0) et Jasmine (version ≥ 5.1.0).
+. Le code doit journaliser ses principales opérations en utilisant https://www.slf4j.org[SLF4J] et
+https://www.npmjs.com/package/typescript-logging[TypeScript Logging].
 
-=== Outils de construction
+=== Outils de production
 
-. Tous les artefacts logiciels doivent utiliser un outil de construction : Maven ou Groovy pour Java, npm pour TypeScript.
+. Tous les artefacts logiciels doivent utiliser un outil de production{nbsp}: Maven (version ≥ 3.9.0) ou
+Gradle (version ≥ 8.0) pour Java et npm (version ≥ 9.0.0) pour TypeScript.
 
 === Outils de développement
-=== Bibliothèques et composants logiciels
 
+=== Bibliothèques et composants logiciels
 
 == Vérification
 
-. Les doubles tests doivent être utilisés pour tester chaque composant indépendamment.
-. Chaque test unitaire doit décrire son intention.
+. Les méthodes du projet doivent être vérifiées grâce aux tests unitaires, indépendamment du langage utilisé.
+Chaque test unitaire doit décrire clairement son intention.
+. L'interface (API) des composants ou modules doubles tests doivent être vérifiées grâce aux tests fonctionnels.
+. Les tests des composants/modules doivent être indépendants des autres composants.
+Des doublures de test doivent être utilisées pour assurer l'isolation des tests.
 
 == Documentation utilisateur
 
-[NOTE]
-====
-Dressez la liste des composants de la documentation utilisateur (tels que les manuels d'utilisation, l'aide en ligne et les didacticiels) qui seront fournis avec le logiciel. Identifiez tous les formats ou normes connus de livraison de la documentation utilisateur.
-====
-
-
 Aucune documentation utilisateur n'est requise pour la première version du logiciel.
 
 === Hypothèses et dépendances
 
-[NOTE]
-====
-Dressez la liste de tous les facteurs supposés (par opposition aux faits connus) qui pourraient affecter les exigences énoncées dans le SRS. Il peut s'agir de composants tiers ou commerciaux que vous prévoyez d'utiliser, de problèmes liés à l'environnement de développement ou d'exploitation, ou de contraintes. Le projet pourrait être affecté si ces hypothèses sont incorrectes, ne sont pas partagées ou changent. Identifiez également toutes les dépendances du projet vis-à-vis de facteurs externes, tels que les composants logiciels que vous avez l'intention de réutiliser à partir d'un autre projet, à moins qu'elles ne soient déjà documentées ailleurs (par exemple, dans le document de vision et de portée ou dans le plan de projet).
-====
-
-Aucun jusqu'à présent.
+Aucune jusqu'à présent.
 
 === Exigences reportées
 
-[NOTE]
-====
-Énumérer les exigences qui peuvent être réalisées dans des versions futures du système.
-Les versions futures du système comprendront l’utilisation d’un mécanisme de persistance de données ainsi que différentes interfaces utilisateur: web, IHM classique, etc.
-Elles permettront aussi l’accès distant à travers une interface REST.
-====
+. Les versions futures du logiciel comprendront l’utilisation de différentes interfaces utilisateur{nbsp}:
+Client Lourd, _Smartphones_, etc.
 
 == Exigences en matière d'interface externe
 
-=== Interfaces utilisateur
-
-[NOTE]
-====
-Décrivez les caractéristiques logiques de chaque interface entre le produit logiciel et les utilisateurs. 
+* Aucune
 
-Il peut s'agir d'exemples d'images d'écran, de normes d'interface graphique ou de guides de style de famille de produits à respecter, de contraintes de disposition des écrans, de boutons et de fonctions standard (p. ex., aide) qui apparaîtront sur chaque écran, de raccourcis clavier, de normes d'affichage des messages d'erreur, etc. 
+=== Interfaces utilisateur
 
-Définissez les composants logiciels pour lesquels une interface utilisateur est nécessaire. 
-Les détails de la conception de l'interface utilisateur doivent être documentés dans une spécification d'interface utilisateur distincte.
-====
+* Aucune exigence
 
 === Interfaces matérielles
 
-[NOTE]
-====
-Décrire les caractéristiques logiques et physiques de chaque interface entre le produit logiciel et les composants matériels du système. 
-Cela peut inclure les types de dispositifs pris en charge, la nature des interactions de données et de contrôle entre le logiciel et le matériel, et les protocoles de communication à utiliser.
-====
-
-Le logiciel n'interagit pas directement avec un quelconque dispositif matériel.
+* Aucune, le logiciel n'interagit pas directement avec un quelconque dispositif matériel.
 
 === Interfaces logicielles
 
-[NOTE]
-====
-Décrivez les connexions entre ce produit et d'autres composants logiciels spécifiques (nom et version), y compris les bases de données, les systèmes d'exploitation, les outils, les bibliothèques et les composants commerciaux intégrés. Identifiez les éléments de données ou les messages qui entrent dans le système et qui en sortent et décrivez le but de chacun. Décrivez les services nécessaires et la nature des communications. 
-
-Se référer aux documents qui décrivent les protocoles détaillés des interfaces de programmation d'applications. Identifiez les données qui seront partagées entre les composants logiciels. 
-
-Si le mécanisme de partage des données doit être mis en œuvre d'une manière spécifique (par exemple, l'utilisation d'une zone de données globale dans un système d'exploitation multitâche), spécifiez-le comme une contrainte de mise en œuvre.
-====
-
-La partie client du logiciel doit fonctionner sur des navigateurs web, tandis que la partie serveur doit interagir avec une base de données par le biais de l'API Java Persistence (JPA).
+La partie client du logiciel doit fonctionner sur des navigateurs web, tandis que la partie serveur doit interagir avec
+une base de données par le biais de l'API Java Persistence (JPA).
 
 
 
 === Interfaces de communication
 
-NOTE: Décrivez les exigences associées à toute fonction de communication requise par ce produit, notamment le courrier électronique, le navigateur Web, les protocoles de communication des serveurs de réseau, les formulaires électroniques, etc. Définissez tout formatage pertinent des messages. Identifiez les normes de communication qui seront utilisées, telles que FTP ou HTTP. Précisez les problèmes de sécurité ou de cryptage des communications, les taux de transfert des données et les mécanismes de synchronisation.
+* Les communications entre le client et le serveur de jeu doivent utiliser des Websockets.
 
-Les communications entre le client et le serveur de jeu doivent utiliser des Websockets.
-
-[#features]
+[#functional]
 == Exigences fonctionnelles
 
 [NOTE]
@@ -267,29 +216,15 @@ Décrire les exigences fonctionnelles du système qui peuvent être exprimées e
 Lorsque des outils de développement, tels des référentiels d’exigences ou des outils de modélisation sont utilisés, on peut référer à ces données en indiquant l’endroit et le nom de cet outil]
 ====
 
-[TIP]
-====
-Ici, il ne s'agit plus de décrire le domaine métier, mais de spécifier ce que le système *doit* faire.
-
-N'oubliez pas qu'il s'agit d'une spécification de que le système *doit* faire et non pas de *comment* il le fait.
-====
-
-=== Fonctionnalité A
 
-[NOTE]
-====
-Ajoutez la description de la fonctionnalité "A".
-====
+=== Fonctionnalité «{nbsp}Joindre une partie{nbsp}»
 
-TIP: Ne dites pas vraiment "Fonctionnalité A". Indiquez le nom de la fonctionnalité en quelques mots seulement.
 
 ==== Description et priorité
 
-[NOTE]
-====
-Fournissez une brève description de la fonctionnalité et indiquez si elle a une priorité élevée, moyenne ou faible. 
-Vous pouvez également inclure des évaluations spécifiques des éléments de priorité, comme les avantages, les pénalités, les coûts et les risques (chacun étant évalué sur une échelle relative allant de 1 à 9).
-====
+Cette fonctionnalité permet à un joueur de se connecter au serveur de jeu, pour ensuite participer à une partie.
+
+Priorité:: Haute
 
 ==== Séquences de Stimulus/Réponse
 
@@ -313,25 +248,24 @@ Chaque exigence doit être identifiée de manière unique par un numéro de séq
 
 ==== Description sous la forme d'un cas d'utilisation
 
-.Cas d'utilisation A
-include::partial$uc-a.adoc[]
+.Cas d'utilisation «{nbsp}Joindre une partie{nbsp}»
+include::partial$req-joindre-partie.adoc[]
 
-=== Fonctionnalité B
+=== Fonctionnalité «{project}Rejoindre une partie{project}»
 
 NOTE: Ajoutez la description de la fonctionnalité "B" en vous basant sur la structure de la fonctionnalité "A"
 
 ==== Description sous la forme d'un cas d'utilisation
-.Cas d'utilisation B
-include::partial$uc-b.adoc[]
+.Cas d'utilisation «{nbsp}Rejoindre une partie{nbsp}»
+include::partial$req-joindre-partie.adoc[]
 
-=== Fonctionnalité C
+=== Fonctionnalité «{nbsp}Jouer un tour{nbsp}»
 
-NOTE: Ajoutez la description de la fonctionnalité "C" en vous basant sur la structure de la fonctionnalité "A"
 
 ==== Description sous la forme d'un cas d'utilisation
 
-.Cas d'utilisation C
-include::partial$uc-c.adoc[]
+.Cas d'utilisation «{nbsp}Jouer un tour{nbsp}»
+include::partial$req-jouer-tour.adoc[]
 
 
 [#nonfunctional]
@@ -339,28 +273,16 @@ include::partial$uc-c.adoc[]
 
 === Exigences de performance 
 
-NOTE: S'il existe des exigences de performance pour le produit dans diverses circonstances, indiquez-les ici et expliquez leur raison d'être, afin d'aider les développeurs à comprendre l'intention et à faire des choix de conception appropriés. Spécifiez les relations temporelles pour les systèmes en temps réel. Faites en sorte que ces exigences soient aussi spécifiques que possible. Vous devrez peut-être énoncer des exigences de performance pour des exigences fonctionnelles ou des caractéristiques individuelles.
-
-
 . Le jeu doit être _jouable_, ce qui signifie que les utilisateurs doivent avoir un retour rapide de leurs actions et que les retards dus aux problèmes de communication/connexion doivent être correctement tenus.
 . Le client Web doit pouvoir s'exécuter sur un ordinateur personnel doté de 4 Go de RAM.
 
 
 === Exigences de sécurité
 
-NOTE: Précisez toute exigence concernant les questions de sécurité ou de confidentialité entourant l'utilisation du produit ou la protection des données utilisées ou créées par le produit. Définissez toute exigence en matière d'authentification de l'identité de l'utilisateur. Faites référence à toute politique ou réglementation externe contenant des questions de sécurité qui affectent le produit. Définissez toutes les certifications de sécurité ou de confidentialité qui doivent être satisfaites.
+* Aucune
 
 === Attributs de qualité logicielle
 
-[NOTE]
-====
-Précisez toute autre caractéristique de qualité du produit qui sera importante pour les clients ou les développeurs. En voici quelques-unes : adaptabilité, disponibilité, exactitude, flexibilité, interopérabilité, maintenabilité, portabilité, fiabilité, réutilisabilité, robustesse, testabilité et convivialité. 
-
-Rédigez-les de manière à ce qu'elles soient spécifiques, quantitatives et vérifiables, si possible. 
-
-Au minimum, clarifiez les préférences relatives pour divers attributs, comme la facilité d'utilisation par rapport à la facilité d'apprentissage. 
-====
-
 ==== Extensibilité
 
 NOTE: TODO
@@ -368,30 +290,19 @@ NOTE: TODO
 ==== Maintenabilité
 
 . Le logiciel doit être lisible et facile à maintenir.
-. La source Java doit respecter les directives de Google : https://google-styleguide.googlecode.com/svn/trunk/javaguide.html.
+. La source Java doit respecter les directives de Google{nbsp}: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html.
 
 === Règles métier
 
-NOTE: Énumérez tous les principes de fonctionnement du produit, tels que les personnes ou les rôles qui peuvent remplir telle ou telle fonction dans des circonstances spécifiques. Il ne s'agit pas d'exigences fonctionnelles en soi, mais elles peuvent impliquer certaines exigences fonctionnelles pour faire respecter les règles.
-
 
 == Autres exigences
 
 NOTE: Définissez toute autre exigence non couverte ailleurs dans le SRS. Il peut s'agir d'exigences relatives à la base de données, à l'internationalisation, à la législation, aux objectifs de réutilisation du projet, etc. Ajoutez toute nouvelle section pertinente pour le projet.
 
+[glossary]
 === Annexe A : Glossaire
 
-TIP: https://docs.asciidoctor.org/asciidoc/latest/sections/glossary/
-
-
-NOTE: Définissez tous les termes nécessaires pour interpréter correctement le SRS, y compris les acronymes et les abréviations. Vous pouvez créer un glossaire distinct couvrant plusieurs projets ou l'ensemble de l'organisation, et vous contenter d'inclure les termes spécifiques à un seul projet dans chaque SRS.
-
-=== Annexe B : Modèles d'analyse
-
-Voir le chapitre <<domain>> (analyse du domaine) pour plus de détails.
-
-NOTE: En option, inclure tout modèle d'analyse pertinent, tel que des diagrammes de flux de données, des diagrammes de classe, des diagrammes d'état-transition ou des diagrammes entité-relation.
+include::termes.adoc[]
 
 === Annexe C : Liste à déterminer
 
-NOTE: Recueillir une liste numérotée des références TBD (To Be Done) qui restent dans le SRS afin de pouvoir les suivre jusqu'à leur fermeture.
diff --git a/trivial-doc/modules/developement/pages/termes.adoc b/trivial-doc/modules/developement/pages/termes.adoc
index 749753b597d836bdd02142d90dd999c90e195c61..14f83444072ca5acd535142564dec4d4ac878d6f 100644
--- a/trivial-doc/modules/developement/pages/termes.adoc
+++ b/trivial-doc/modules/developement/pages/termes.adoc
@@ -8,13 +8,13 @@
 |*Signification*
 
 
-| <<Camembert>>
+| [#camembert]#Camembert#
 | Pièce mobile du plateau de jeu
 | Il correspond à la position d'un joueur pendant la partie. 
-Il contient 5 cases vides, qui sont remplies pendant la partie par des xref:#Triangle[triangles] de couleur différente
+Il contient 5 cases vides, qui sont remplies pendant la partie par des <<triangle, triangles>> de couleur différente
 
-| <<Triangle>>
-| Pièce triangulaire qui s'emboite à l'intérieur d'un xref:#camembert[camembert].
+| [#triangle]#Triangle#
+| Pièce triangulaire qui s'emboite à l'intérieur d'un <<camembert, camembert>>.
 | Les triangles ont des couleurs différentes qui correspondent aux différentes catégories de question.
 
 |===
diff --git a/trivial-doc/modules/developement/partials/uc-a.adoc b/trivial-doc/modules/developement/partials/req-creer-compte.adoc
similarity index 98%
rename from trivial-doc/modules/developement/partials/uc-a.adoc
rename to trivial-doc/modules/developement/partials/req-creer-compte.adoc
index 275cd1018e7408543711a44cf14cced2188d1a05..9705337e8ede36b70ea421a82e9441f4d5c0bccb 100644
--- a/trivial-doc/modules/developement/partials/uc-a.adoc
+++ b/trivial-doc/modules/developement/partials/req-creer-compte.adoc
@@ -4,10 +4,10 @@
 | Item | Description
 
 | # 
-| 1
+| 11
 
 | Cas d'utilisation	
-| _à compléter_
+| Créer un compte
 
 | Alias
 | _à compléter_
diff --git a/trivial-doc/modules/developement/partials/req-joindre-partie.adoc b/trivial-doc/modules/developement/partials/req-joindre-partie.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..d4ea5fbfbdad5796d343e9c99b8e166fc40649aa
--- /dev/null
+++ b/trivial-doc/modules/developement/partials/req-joindre-partie.adoc
@@ -0,0 +1,107 @@
+
+[cols="30s,70n",options="header", frame=sides]
+|===
+| Item | Description
+
+| # 
+| 1
+
+| Cas d'utilisation	
+| Joindre une partie
+
+| Alias
+| Connexion
+
+| Objectif contextuel
+|
+
+| Portée	
+| Le système
+
+| Niveau
+| _Summary_
+
+| Condition de succès
+| Le joueur participe à une partie
+
+| Condition d'échec
+| Le joueur n'arrive pas à joindre une partie
+
+| Acteurs principaux:
+| Le joueur
+
+| Acteurs secondaires
+| Le serveur
+
+| Événement déclencheur
+| Le joueur souhaite jouer une partie
+
+
+| Priorité
+| Haute
+
+| Fréquence
+| Une fois par jour
+
+| Pré-conditions 
+a| 
+- Le joueur est connecté à Internet
+- Le joueur a une adresse email valide
+- Le serveur est en ligne
+
+| Post-conditions
+a| 
+- Le joueur est connecté au serveur
+
+
+| Scénario nominal
+a|
+. Le joueur ouvre son navigateur et visite le site {project}
+[#identification]
+. Le joueur informe son identifiant et son mot de passe et se connecte au serveur
+. Le serveur propose une liste de parties disponibles
+. Le joueur choisit une partie et la rejoint
+. Le serveur prévient le joueur que la partie va commencer
+
+| Extensions	
+a|
+* <<identification, [2a]>> Le joueur n'a pas d'identifiant.
+Créer un nouveau compte (Cas d'utilisation 11)
+* <<identification, [2b]>> Le joueur a oublié sont mot de passe.
+Réinitialiser mot de passe (Cas d'utilisation 12)
+
+
+| Alternatives	
+a|
+
+| Cas d'utilisation supérieur
+| Aucun
+
+| Cas d'utilisation subordonnés 
+a |
+* Créer un nouveau compte
+* Réinitialiser mot de passe
+
+| Objectif de performance
+| _à compléter_
+
+| Problèmes ouverts	
+a|
+-
+
+| Échéancier	
+| Version 1.0
+
+| Contraintes
+|
+
+| Annexes
+|
+
+|===
+
+
+
+
+
+
diff --git a/trivial-doc/modules/developement/partials/req-jouer-tour.adoc b/trivial-doc/modules/developement/partials/req-jouer-tour.adoc
new file mode 100644
index 0000000000000000000000000000000000000000..6dfe15b38e1f5aba7afaea43a892d2cc88f8baf1
--- /dev/null
+++ b/trivial-doc/modules/developement/partials/req-jouer-tour.adoc
@@ -0,0 +1,87 @@
+[cols="30s,70n",options="header", frame=sides]
+|===
+| Item | Description
+
+| #
+| 2
+
+| Cas d'utilisation
+| Tour de jeu
+
+| Description
+| Les joueurs jouent leurs tours alternativement, plusieurs fois dans une partie.
+Pendant chaque tour, ils peuvent effectuer plusieurs actions{nbsp}:
+lancer le dée, déplacer le camembert, répondre à une question.
+
+| Niveau
+| Utilisateur
+
+| Portée
+| Système (Le jeu {project})
+
+| Priorité
+| Haute
+
+| Échéance
+| Version 1.0.0
+
+| Acteurs principaux
+a|
+. Un joueur
+
+| Acteurs de soutien
+| Aucun pour l'instant.
+
+| Parties prenantes et intérêts
+| Aucun pour l’instant.
+
+| Pré-conditions
+a|
+- Aucun tour d'un autre joueur n'est entamé.
+- Ce le tour de ce joueur
+- Le paquet de cartes est disponible.
+- La partie est en cours.
+
+| Post-conditions
+| Aucune
+
+| Condition finale de réussite
+a|
+* Le joueur a lancé le dé une our plusieurs fois
+* Le joueur a répondu à une ou plusieurs questions (autant de questions que de lancées de dé)
+
+* Le joueur a mal répondu à la dernière question et le joueur à gauche commence son tour *OU* il a remporté la partie
+
+| Condition finale d'échec
+a|
+- Le joueur n'a répondu à aucune question
+- Le joueur a répondu correctement à la dernière question, mais ce n'est plus son tour
+
+| Garanties minimales
+a|
+- L'ordre des joueurs reste le même
+- Deux joueurs ne jouent pas leur tour en même temps
+- Le jeu passe au tour du joueur suivant
+
+| Événement déclencheur
+| Le joueur précédent termine son tour *OU*  le joueur commence la partie.
+
+
+| Scénario nominal
+a|
+. Le Système prévient le joueur que c'est son tour
+. Le joueur demande au Système de lancer le dé
+. Le Système affiche la valeur obtenue
+. Le Système propose les destinations (cases) possibles
+. Le joueur choisit la destination
+
+
+
+. Le joueur déplace son camembert d'autant de cases qu'indiqué par le dé, sans passer par la même case.
+. Un autre joueur prend une carte et lit la question correspondant à la couleur de la case (chaque couleur correspond à une catégorie).
+. Le joueur répond à la question
+. L'autre joueur compare sa réponse avec celle de la carte{nbsp}
+** Si la réponse est incorrecte, le tour du joueur s'arrête
+**  Si la réponse est correcte, le joueur recommence son tour
+
+|===
\ No newline at end of file
diff --git a/trivial-doc/modules/developement/partials/uc-b.adoc b/trivial-doc/modules/developement/partials/req-reinitialiser-mdp.adoc
similarity index 97%
rename from trivial-doc/modules/developement/partials/uc-b.adoc
rename to trivial-doc/modules/developement/partials/req-reinitialiser-mdp.adoc
index 275cd1018e7408543711a44cf14cced2188d1a05..54a28aa46e58607db7d4c52c2430a477c5ceadb9 100644
--- a/trivial-doc/modules/developement/partials/uc-b.adoc
+++ b/trivial-doc/modules/developement/partials/req-reinitialiser-mdp.adoc
@@ -4,10 +4,10 @@
 | Item | Description
 
 | # 
-| 1
+| 12
 
 | Cas d'utilisation	
-| _à compléter_
+| Réinitialiser mot de passe
 
 | Alias
 | _à compléter_
diff --git a/trivial-doc/modules/developement/partials/uc-c.adoc b/trivial-doc/modules/developement/partials/uc-c.adoc
deleted file mode 100644
index 275cd1018e7408543711a44cf14cced2188d1a05..0000000000000000000000000000000000000000
--- a/trivial-doc/modules/developement/partials/uc-c.adoc
+++ /dev/null
@@ -1,108 +0,0 @@
-
-[cols="30s,70n",options="header", frame=sides]
-|===
-| Item | Description
-
-| # 
-| 1
-
-| Cas d'utilisation	
-| _à compléter_
-
-| Alias
-| _à compléter_
-
-| Objectif contextuel
-| _à compléter_
-
-| Portée	
-| _à compléter_
-
-| Niveau
-| _à compléter_
-
-| Condition de succès
-| _à compléter_
-
-| Condition d'échec
-| _à compléter_
-
-| Acteurs principaux:
-| _à compléter_
-
-| Acteurs secondaires
-| _à compléter_
-
-| Événement déclencheur
-| _à compléter_
-
-
-| Priorité
-| _à compléter_
-
-| Fréquence
-| _à compléter_
-
-| Pré-conditions 
-a| 
-- _à compléter_
-- _à compléter_
-
-| Post-conditions
-a| 
-- _à compléter_
-- _à compléter_
-- _à compléter_
-
-
-| Scénario nominal
-a|
-. _à compléter_
-. _à compléter_
-. _à compléter_
-. _à compléter_
-. _à compléter_
-. _à compléter_
-
-
-| Extensions	
-a| 
-. _à compléter_
-. _à compléter_
-
-| Alternatives	
-a| 
-. _à compléter_
-. _à compléter_
-
-| Cas d'utilisation supérieur
-| _à compléter_
-
-| Cas d'utilisation subordonnés 
-| _à compléter_
-// _optional, depending on tools, links to sub.use cases_
-
-| Objectif de performance
-| _à compléter_
-
-| Problèmes ouverts	
-a|
-- _à compléter_
-- _à compléter_
-
-| Échéancier	
-| _à compléter_
-
-| Contraintes
-| _à compléter_
-
-| Annexes
-| _à compléter_
-
-|===
-
-
-
-
-
-
diff --git a/trivial-doc/modules/developement/partials/uc-preparation-alpha.adoc b/trivial-doc/modules/developement/partials/uc-preparation-alpha.adoc
deleted file mode 100644
index ca2463470a8fa94262fbd55fbed635967b182aa5..0000000000000000000000000000000000000000
--- a/trivial-doc/modules/developement/partials/uc-preparation-alpha.adoc
+++ /dev/null
@@ -1,56 +0,0 @@
-== Cas d'utilisation
-
-=== #1 : Mise en place du jeu
-
-*pré-condition*
-
-* Communication établie entre l'arbitre et chaque joueur.
-* Un mode de jeu à été déterminé.
-
-*postcondition*
-
-* Les joueurs ont le même nombre d'armées.
-* Les joueurs ont un écart maximal de 1 entre leurs nombres de territoires
-* Aucune mission n'est accomplie.
-
-*Scénario*
-
-. #1.1 <<AttributionMissions>>
-. L'arbitre distribue le même nombre d'armées à chaque joueurs selon le nombre total de joueurs : 2 joueurs->40 armées, 3 joueurs->35 armées, 4->30, 5->25, 6-> 20
-. S'il y a 2 joueurs : <<MiseADeuxJoueurs>>, puis ignorer les étapes suivantes
-. L'arbitre attribue une couleur différente à chaque joueur.
-. L'arbitre lance 1d6/joueur.
-Le joueur dont le lancé est le plus élevé est l'initiateur.
-. Si le mode jeu est "secret mission risk" alors l'arbitre ditribue aléatoirement les territoires aux joueurs.
-On ignore les 3 étapes d'attribution des territoires qui suivent.
-. L'initiateur place une de ses armées sur un territoire non occupé qu'il proclame (le territoire lui est attribué).
-. L'arbitre désigne le joueur à gauche du précédent qui doit faire de même.
-. On recommence l'étape précédente jusqu'à-ce que tous les 42 territoires soient occupés.
-. L'initiateur place une armée sur un de ses territoires.
-. Le joueur désigné comme suivant fait de même
-. On recommence l'étape précédente jusqu'à-ce que toutes les armées des joueurs soient placées.
-. L'arbitre mélange les cartes territoires et joker ensemble et en forme une pile cachée.
-. L'initiateur joue le 1er tour de jeu.
-
-[#AttributionMissions]
-==== #1.1 Attribution des missions
-
-. Selon le mode de jeu, l'arbitre attribue à chaque joueur une mission :
-.. Partie à 2 joueurs : défaire l'adversaire, le 3e joueur neutre ne compte pas.
-.. world domination risk : tout les joueurs on pour mission de posséder tout les territoires du monde.
-.. capital risk : capturer toutes les capitales
-.. (4 joueurs) 2 capital risk : capturer 2 capitales en plus de la sienne.
-.. (5 ou 6 joueurs) 3 capital risk : capturer 3 capitales en plus de la sienne.
-.. (3 à 6 joueurs) secret mission risk : être le premier à accomplir la mission secrète indiquée sur la carte donnée au hasard par l'arbitre.
-
-[#MiseADeuxJoueurs]
-==== #1.2 Mise en place à deux joueurs
-
-. L'arbitre crée un troisième joueur (le joueur neutre)
-. L'arbitre attribue une couleur différente à chaque joueur.
-. L'arbitre répartit aux hasard les territoires entre les 3 joueurs (14 territoires par joueur).
-. L'arbitre place une armée sur chaque territoire.
-. L'arbitre choisit au hasard qui des 2 joueurs non neutres est l'initiateur.
-. En commençant par l'initiateur, les joueurs vont tour à tour placer : 2 armées sur leurs territoires et 1 armée sur un territoire neutre ; jusqu'à ce que toutes les armées soient placées.
-. Les cartes territoire et joker l'arbitre mélange en une pile cachée.
-. L'initiateur joue le 1er tour de jeu.
diff --git a/trivial-doc/modules/developement/partials/uc-tour.adoc b/trivial-doc/modules/developement/partials/uc-tour.adoc
index 06fc61f56db7a63476fb982cd1f1717c1e4d2944..e46c1c1ed7715482fdc405a28cad7f0416ca6f57 100644
--- a/trivial-doc/modules/developement/partials/uc-tour.adoc
+++ b/trivial-doc/modules/developement/partials/uc-tour.adoc
@@ -47,9 +47,10 @@ a|
 
 | Condition finale de réussite
 a|
-- Le joueur a lancé le dé une our plusieurs fois
-- Le joueur a répondu à une ou plusieurs questions (autant de questions que de lancées de dé)
-- Le joueur a mal répondu à la dernière question *OU* il a remporté la partie
+* Le joueur a lancé le dé une our plusieurs fois
+* Le joueur a répondu à une ou plusieurs questions (autant de questions que de lancées de dé)
+
+* Le joueur a mal répondu à la dernière question et le joueur à gauche commence son tour *OU* il a remporté la partie
 
 | Condition finale d'échec
 a|
@@ -63,139 +64,39 @@ a|
   - Le jeu passe au tour du joueur suivant
 
 | Événement déclencheur
-| Le joueur précédent termine son tour, *OU*  le joueur commence la partie.
+| Le joueur précédent termine son tour *OU*  le joueur commence la partie.
 
 | Scénario nominal
 a| 
 . Le joueur lance le dé
 . Le joueur déplace son camembert d'autant de cases qu'indiqué par le dé, sans passer par la même case.
 . Un autre joueur prend une carte et lit la question correspondant à la couleur de la case (chaque couleur correspond à une catégorie).
-. Le joeur lit
-
-
+. Le joueur répond à la question
+. L'autre joueur compare sa réponse avec celle de la carte{nbsp}
+** Si la réponse est incorrecte, le tour du joueur s'arrête
+**  Si la réponse est correcte, le joueur recommence son tour
 
+| Alternatives
+a|
+. [Alternative à 5] Le camembert est sur une case «{nbsp}Quartier Général{nbsp}»{nbsp}:
+.. Il remporte un triangle correspond à la couleur de la case, seulement s'il ne possède pas le triangle de couleur correspondant à la case.
+.. Si son camembert est plein{empty}footnote:[C'est son 6e triangle]{nbsp}: il remporte la partie (elle s'arrête)
 
-reçoit ses renforts en relation avec le nombre de territoires conquis par le joueur. S'il le souhaite il peut proposer une combinaison de 3 cartes pour remporter des armées supplémentaires.
-2. Le joueur place tous ses renforts sur le plateau parmi ses territoires.
-3. Le joueur effectue autant d'attaque qu'il le souhaite [.big]##(Use Case 3)##, il peut ne pas attaquer pendant sont tour également.
-4. Si le joueur a gagné au moins un combat, il pioche une seule carte territoire-armée.
-5. Le joueur sélectionne chaque paire de territoires (départ et arrivée) avec lesquels il souhaite faire un échange d'unités ainsi que le nombre d'unités qu'il souhaite déplacer (en prenant soin d'en laisser au moins une dans le territoire de départ).
-7. Le prochain joueur joue [.big]##(Use Case 2)##.
 
 | Extensions
 a|
-* Point 1/
-** a - Le nombre de renforts est défini par l'arbitre en fonction de l'état du plateau à ce moment-là. Le nombre de renforts obtenus par le joueur dépend du nombre de territoires (voire continent(s)) possédés par ce même joueur : +
-   Ce nombre se définit de la façon suivante : pour x territoires possédés par le joueur, celui-ci reçoit n renforts pour x = 3 * n + a, a pouvant valoir 0 (si n est un multiple de 3). +
-   Si n est inférieur à 3, le joueur recevra tout de même 3 renforts à placer. +
-   Si le joueur a conquis complètement un ou plusieurs continents, il peut recevoir des renforts supplémentaires comme indiqué dans le premier tableau suivant. 
-** b - Le joueur peut proposer une combinaison de cartes, avant d'attaquer, pour recevoir des armées supplémentaires comme indiqué dans le deuxième tableau suivant. +
-** c - Si le joueur pose une combinaison de cartes parmi celles ci-dessus, il reçoit des armées supplémentaires en rapport avec i, i étant la ième combinaison proposée dans la partie. +
-   On retrace ce nombre d'armées supplémentaires en fonction de i dans le troisième tableau ci-dessous. +
-** d - Si parmi les 3 cartes territoires-armées impliquées dans la combinaison posée par le joueur, il apparaît au moins un territoire occupé par ce même joueur, celui-ci remporte 2 armées supplémentaires par territoire correpondant. +
+
 
 | Fréquence
 |  Un tour dure environ 3 minutes.
 
 | Hypothèses
-| NA
+| Aucune
 
 | Exigences particulières
 | Aucune
 
 | Questions ouvertes
 a|
-1. Comment l’arbitre sait le nombre de renforts que le joueur doit obtenir ?
-2. Comment l’arbitre sait si le joueur a achevé sa mission ?
-
-
-|===
-
-[cols="5, 2", options="header"]
-|===
-| Continent
-| Nombre de renforts supplémentaires
-
-| Océanie
-| 2
-
-| Amérique du Sud
-| 2
-
-| Afrique
-| 3
-
-| Europe
-| 5
-
-| Amérique du Nord
-| 5
-
-| Asie
-| 7
-|===
- 
-
-[cols="5, 2", options="header"]
-|===
-| Combinaison de cartes possible
-| Nombre d'armées supplémentaires
-
-| 3 fantassins
-| 3
-
-| 3 cavaliers
-| 5
-
-| 3 canons
-| 8
-
-| 1 canon, 1 cavalier, 1 fantassin
-| 10
-|===
-
-
-[cols="2, 2", options="header"]
-|===
-| ième combinaison proposée dans la partie
-| Nombre d'armées supplémentaires
-
-| 1ère
-| 4 
-
-| 2ème
-| 6
-
-| 3ème
-| 8
-
-| 4ème
-| 10
-
-| 5ème
-| 12
-
-| 6ème
-| 15
-
-| 7ème
-| 20
-
-| 8ème
-| 25
-
-| (i+1)ème
-| (nombre d'armées distribuées précédent) + 5
-|===
-
-
-* Point 3/
-** a - Une attaque peut être effectuée avec des armées issus de territoires différents uniquement dans le cas où le pays d'origine attaquant ne possède plus qu'une armée et que le joueur possède un autre pays (que celui d'origine) adjacent au pays attaqué. +
-** b - Le joueur doit laisser au moins une armée sur chacun de ses territoires attaquants tant qu'il n'a pas perdu ses attaques. +
-* Point 4/
-** a - Si il n’y a plus de cartes dans la pioche, l’arbitre intervient pour ramasser les cartes mises de côté et les mélange afin d’en faire une nouvelle pioche. +
-* Point 5/
-** a - Le joueur doit laisser au moins une armée dans chaque territoire qu'il occupe.
-